긍정적 사고, 음식의 절제, 규칙적인 운동

최고, 최악의 상사를 가르는 체크리스트

http://www.insight.co.kr/news.php?Idx=1883&Code1=002

심리학자 Steve Albrecht 박사가 미국의 심리학 전문 사이트인 Psychology Today에 기고한 칼럼에 따르면 좋은 상사와 나쁜 상사의 유형은 아래와 같다.

■ 좋은 상사

- 팀원들의 의견을 경청한다.

- 모두를 공정하게 대한다.

- 커리어에 대해 멘토링을 해준다.

- 사람들 앞에서 칭찬을 해준다.

- 실수로부터 배울 여유를 준다.

- 경조사, 생일, 아플 때 등 디테일하게 챙겨준다.

■ 나쁜 상사

- 알콜 홀릭

- 업무지시를 번복한다.

- 소리 지른다.

- 무능력하다.

- 부하 직원들의 화장실 가는 시간까지 체크한다.

- 남의 아이디어를 가로챈다.

- 팀원들과 소통하지 않는다.

- 업무에 대해 아무것도 가르쳐주지 않으며, 질문을 귀찮아한다.

- 상부에 나를 깎아내리는 말을 한다.

- 개선책 없이 꾸짖기만 한다.

위와 같이 두 부류의 특징은 완전히 상반된다.

워커홀릭 유능한 상사는 독일까 약일까? ⓒMBC

그렇다면 스스로 질문해보자. “내 보스들은 그들의 리스트를 갖고 있는가?”

그렇다. 그들도 역시 나를 누군가와 비교하고 있을 것이다.

<!--[if !supportEmptyParas]--> <!--[endif]-->

이제 적어놓은 리스트로부터 좋은 상사가 되려면 무엇을 해야 할지, 그리고 하지 말아야 할 것은 무엇인지 배워야 할 시점이다. 

구글다움(Googliness) 을 유지하는 10가지 핵심 가치

1. 최고의 인재와 일하고 싶다.
2. 최고의 인재를 채용하고 직원을 최고로 만들어 줘야 한다.
   똑똑한 사람을 채용해서 바보로 만들지 말자.
3. 공정하게 대하자. 더 좋은 아이디어가 나올 수 있도록 하자.
4. 다양성이 중요하다. 60억 인구를 상대하려면 우리부터 다양해야 한다.
5. 의사결정은 정량적으로 통계에 기반해 한다.
6. 기술적 혁신이 가장 중요하다.
7. 구글에서 일하는 것은 재미있어야 한다.
8. 주인의식을 가져야 한다. 당신이 회사다. 불만이 있으면 직접 고쳐라.
9. 성공은 그냥 오는 것이 아니다. 낮은 자세로 임하고 겸손하라.
10. 옳은 것을 하라. 악마가 되지 말자.
    

사업 개발자(Biz Dev)는 무엇을 잘해야 할까?

바야흐로 개발자의 시대이다. 스타트업의 핵심은 역시 개발이요 개발을 통해 무에서 유를 창조하고 세상을 바꿀 서비스를 만들어 내는 것이야말로 스타트업의 로망이라 하겠다. 그럼 개발자가 아닌 사람들은 무엇을 잘 해야 할까? 보통 인문계 출신의 분들이 사업 개발(Biz Dev) 의 역할을 맡게 되는데, 개발과 제품에 대한 대한 많은 방법론(어자일, 린스타트업, MVP, AARRR 등등등)은 많이 보았지만 Biz Dev의 조건과 역량에 대한 논의는 본 적이 없는 것 같다. 종종 회사의 Biz Dev으로서의 역할을 수행하게 되는 벤처투자자로서 조금이라도 더 도움이 되는 사람이 되려면 무엇을 해야할지 고민하게 되는데, 결과적으로 아래의 역량들이 중요하다.

1. 사람에 강해지자

사람에 강하다는 것은 무슨 뜻인가? 많은 사람들이 이 경우 카리스마적인 리더의 모습이나 넓은 인간관계를 가진 활동적인 사람의 모습을 떠올린다. 물론 그런 것도 사람에 강한 모습일 수 있겠으나 이것이 핵심은 아니다.

비즈니스 관계에서 사람에 강해진다는 뜻은

• 타인에 대한 기본적인 호의를 가지되 악의를 가진사람을 구분해 낼 수 있고
• 타인이 필요로 하는 것, 원하는 것이 무엇인지를 잘 파악하며
• 이를 제공하기 위해 적극적으로 노력하고 커뮤니케이션 하면서
• 동시에 내가 원하는 것을 적극적으로 요구하고 얻어낼 수 있는 명확한 자기 인식과 용기를 가진다.

이러한 능력을 바탕으로 Biz Dev는 좋은 협상가, 좋은 갈등의 중재자가 되어야 하며 실질적으로 도움이 되는 네트워크를 충분히 확보하고 있어야 한다. 인사가 만사라는 말도 있지 않은가?

2. 명확하게 쓰고 말하자

명확하게 글을 써야한다. 여기서 글이란 이메일, 프리젠테이션, 워드 형식의 보고서 등 모든 비즈니스 라이팅을 말한다. 보고서나 PT 자료를 정리하고 전달하는 일은 Biz Dev 업무의 매우 큰 부분이며 이를 명확하고 빠르게 처리할 수 있으면 생산성은 비약적으로 상승한다.

말하기도 마찬가지다. 여기에 더해 청중 앞에서 좋은 프리젠터가 될 수 있다면 Biz Dev의 가치는 더욱 상승한다. 생각보다 남 앞에 서서 말하기를 어색해하는 사람들이 많으며, 이를 전문적으로 훈련하고 가다듬어 자신의 무기로 만든 사람은 소수다. 하지만 프리젠테이션은 연마될 수 있으며 기본적인 훈련만 해도 바로 큰 효과를 볼 수 있다.

반대로 피해야 할 것이 말과 글을 낭비하는 것이다. 이는 사고를 모호하게 만들고, 쓰는 시간과 읽는 시간을 더 걸리게 만든다. 물론 정황상 때때로 이도저도 아닌 내용을 구구절절 써야하는 경우가 있지만 일단은 명확하게 쓰고 말할 줄 안 다음에 하는 것이 좋다. 정말 기본적인 내용이지만 이만큼 중요한것도 없다.

3. 경영학적 개념에 익숙해지고 이를 잘 응용하자

비즈니스맨에게 있어 경영학은 공부하는것이 아니라 스스로 생각하고 연마하는 것이다. 종종 경영학을 공부한다고 각종 경영 서적을 열심히 읽고 공부하는 분들이 있는데 사실 경영학 개론 책과 몇몇 유명한 책들만 잘 읽어도 중요한 프레임워크와 경영학개념들을 대부분 숙지할 수 있다. 하지만 단순히 지식을 알기만 하는 것은 사업에 도움이 되지 않으며 이러한 개념들을 필요에 맞게 조합하여 각각의 회사에 적합한 분석과 전략을 유연하게 도출하는 것이 중요하다.

예를 들어, ‘협상력’ 이라는 개념을 생각해 보자. 사업 관계에 있어 협상력의 강약은 어디에나 존재하며 상호 교환하고자 하는 재화에 대한 니즈가 더 약한 쪽이 더 강한 협상력을 가지게 된다. 하지만, 이 협상력을 어떻게 강화할지는 상황마다 다 다르다. 여기서 중요한 것은 (1) 협상력 이라는 컨셉을 이해하고 이를 강화하기 위해 노력해야한다’ 라는 방향성을 잡는 것이며 (2) 이를 현재 상황에 맞추어 협상력 강화라는 문제를 집중적으로 해결하는 것이다. 이렇듯, 핵심 개념을 여러가지 상황에 맞추어 자유 자재로 적용하고 분석할 수 있어야 한다.

말로 설명하기 참 어려운 부분인데 보다 실제적인 경영/경제학 이슈들을 다룬 책(‘이코노믹 씽킹’ 이나 ‘머니볼’ 같은) 들을 보면 몇 가지 핵심적이고 기본적인 경영학/경제학적 개념을 바탕으로 사업을 분석하고 문제를 해결해 나가는 예시를 많이 볼 수 있다. 중요한 것은 개념을 숙지하는 것 보다 그것을 조합하고 이용하여 현재 비지니스에 특화된 분석과 전략을 도출하는 것이다. 좋은 Biz Dev은 이러한 능력이 뛰어나야 하며 이를 바탕으로 사업에 대한 펀더멘털한 이해하에서 사업 개발에 나서야 한다.

4. 외국어를 하자

이건 자세한 설명이 필요 없다. 영어는 필수다.

무림 고수의 정권지르기 처럼

어찌보면 기본적인 내용이고 측정이 쉽지 않은 역량들이다. 하지만, ’기본중의 기본들에 충실해야 한다’ 는 것이 말하고자 하는 핵심이다. 무림 고수가 30년 연마한 정권지르기와 초보자의 정권지르기가 다르듯, 기본적인 것들의 깊이와 숙련도가 사업 개발을 담당하는 사람의 역량을 좌우하지 않나 싶다. 기본만 하면 된다니 얼마나 좋은가? 새로운 개발 언어를 배울 필요도 없고 유학을 갈 필요도 없으니.

글 : 위현종
출처 : http://goo.gl/6LtNv2

훌륭한 보스의 12가지 사인

1. You get genuine pleasure from helping others do their best work; you measure your own success by theirs.
다른 사람들이 일을 더 잘 할 수 있도록 도와주는데서 진정한 기쁨을 얻는다. 그들의 성공이 당신의 성공이라고 느낀다.

2. You don’t treat everyone the same. You know your people well enough to manage them as individuals.
모든 사람을 똑같이 대하지 않는다. 자신의 부하들을 잘 알고 그들을 각각 하나의 개체로서 이끌어간다.

3. You understand that your title gives you power, but intelligence and integrity give you influence, which is invaluable.
자신의 타이틀이 그대로 조직에서의 권력으로 이어지지 않는다는 것을 이해한다. 대신 자신의 총명함, 명석함과 청렴한 행동, 솔선수범 등이 조직에서 큰 영향력으로 이어진다는 것을 잘 이해하고 있다.

4. Your feedback is specific, sincere and constructive. People know where they stand with you.
구체적이고 진실되며 건설적인 피드백을 준다. 사람들이 당신이 지향하는 바를 이해한다.

5. More than a few people on your team have saved notes of praise you’ve sent them. Your words carry that much impact.
팀의 많은 사람들이 당신이 보낸 칭찬의 메모를 소중하게 간직한다. 당신의 말은 그 정도로 가치를 지닌다.

6.Your constructive response to mistakes and problems leads people to feel they can safely bring you bad news, when necessary.
당신은 사람들의 실수와 문제점에 대해 충실한 답변을 해준다. 그래서 사람들은 필요하면 나쁜 소식이라도 안심하고 당신에게 전할 수 있다고 생각한다.

7. You communicate your plans and goals clearly, and people understand their roles and responsibilities as members of your team.
부하들이 팀멤버로서 자신의 역할과 책임을 잘 이해할 수 있도록 명확하게 목표와 계획을 커뮤니케이션한다.

8. You hire people smarter than you are and aren’t intimidated by their knowledge. You can look out your office door and see your replacement.
자기보다 똑똑한 사람들을 뽑고 그들의 지식에 겁을 먹지 않는다. 자신을 대체할 수 있는 인재가 누구인지 알아본다.

9. Your staff members feel ownership of ideas and initiatives, even those you originate, because you share power and control.
부하들이 새로운 아이디어나 시도에 대해서 자기의 것이라고 생각할 수 있도록 한다. 비록 처음부터 내가 낸 아이디어라도 적절한 권한이양을 통해 부하들이 자신의 일이라고 생각하도록 만든다. 부하들의 공을 빼앗지 않는다.

10. You know the occasions when only a top-down decision will do: times of crisis, high risk or high conflict. And your staff appreciates it.
톱다운결정이 언제 필요한지를 알고 실행한다. 위기가 닥쳤을 때나, 큰 베팅을 해야할 때, 큰 갈등이 있을때가 그렇다. 필요할때 단호한 톱다운 결정을 내린다면 부하들이 믿고 따를 것이다.

11. You’re a continuous learner, always looking to improve your skills and knowledge.
항상 계속해서 공부한다. 언제나 자신의 지식과 역량을 늘리기 위해서 노력한다.

12. Your employees know what you stand for and are proud to stand with you.
당신의 직원들은 당신이 지향하는 바를 알고 당신과 같이 한다는 것에 대해서 자랑스러워한다.

성공하는 소프트웨어를 개발하는 원칙.

 - 소프트웨어 개발 시 요구사항이 계속 변화하는 것에 대해 어덯게 대응할 것인가?

 - 소프트웨어 개발 시 반복되는 작업을 어떻게 최소화 할 것인가?

 - 사용자가 요구한 기능보다 좀더 나은 기능을 구현하는 방법은 없나?

개발 조직이 반드시 고려해야 할 것

1.소프트웨어를 개발한 후 버전 컨트롤을 하는가?

2.자동으로 빌드하고 자동으로 테스트하는 시스템이 있는가?

3.전체적인 소프트웨어 개발을 모니터링하고 있는가?

4.테스터의 롤이 별도로 있거나 테스팅 환경을 구축하고 있는가?

5.버그 트랙킹 시스템을 구축하고 있는가?

소프트웨어 개발이 실패할 경우 그에 대한 책임은 해당 소프트웨어를 개발한 모든 사람에게 있다.

가장 훌륭한 소프트웨어 개발 조직은 똑같은 실패를 다시 반복하지 않는 조직이다.

문제가 있는 상황을 인지하고, 문제를 해결하기 위해 노력하면서 그 상황을 변화시키려는 조직이라야

유기적이고 유동적으로 해당 문제를 해결할 수 있다.

"소프트웨어 개발에 있어서 특정 형식에 얽매이는 행위야말로 삽질이다."

http://wiki.kldp.org/wiki.php/HowToBeAProgrammer#s-3.2.1

목차

Contents

1 도입

2 초보자

2.1 개인적 기능들

2.1.1 디버그 배우기

2.1.2 문제 공간을 나눠서 디버그 하는 방법

2.1.3 오류를 제거하는 방법

2.1.4 로그를 이용해서 디버그 하는 방법

2.1.5 성능 문제를 이해하는 방법

2.1.6 성능 문제를 해결하는 방법

2.1.7 반복문을 최적화하는 방법

2.1.8 I/O 비용을 다루는 방법

2.1.9 메모리를 관리하는 방법

2.1.10 가끔씩 생기는 버그를 다루는 방법

2.1.11 설계 기능을 익히는 방법

2.1.12 실험을 수행하는 방법

2.2 팀의 기능들

2.2.1 시간 추정이 중요한 이유

2.2.2 프로그래밍 시간을 추정하는 방법

2.2.3 정보를 찾는 방법

2.2.4 사람들을 정보의 원천으로 활용하는 방법

2.2.5 현명하게 문서화하는 방법

2.2.6 형편없는 코드를 가지고 작업하기

2.2.7 소스 코드 제어 시스템을 이용하는 방법

2.2.8 단위별 검사를 하는 방법

2.2.9 막힐 때는 잠깐 쉬어라

2.2.10 집에 갈 시간을 인지하는 방법

2.2.11 까다로운 사람들과 상대하는 방법

3 중급자

3.1 개인적 기능들

3.1.1 의욕을 계속 유지하는 방법

3.1.2 널리 신뢰받는 방법

3.1.3 시간과 공간 사이에서 균형을 잡는 방법

3.1.4 압박 검사를 하는 방법

3.1.5 간결성과 추상성의 균형을 잡는 방법

3.1.6 새로운 기능을 배우는 방법

3.1.7 타자 연습

3.1.8 통합 검사를 하는 방법

3.1.9 의사소통을 위한 용어들

3.2 팀의 기능들

3.2.1 개발 시간을 관리하는 방법

3.2.2 타사 소프트웨어의 위험 부담을 관리하는 방법

3.2.3 컨설턴트를 관리하는 방법

3.2.4 딱 적당하게 회의하는 방법

3.2.5 무리 없이 정직하게 반대 의견을 내는 방법

3.3 판단 능력

3.3.1 개발 시간에 맞춰 품질을 조절하는 방법

3.3.2 소프트웨어 시스템의 의존성을 관리하는 방법

3.3.3 소프트웨어의 완성도를 판단하는 방법

3.3.4 구입과 개발 사이에서 결정하는 방법

3.3.5 전문가로 성장하는 방법

3.3.6 면접 대상자를 평가하는 방법

3.3.7 화려한 전산 과학을 적용할 때를 아는 방법

3.3.8 비기술자들과 이야기하는 방법

4 상급자

4.1 기술적 판단 능력

4.1.1 어려운 것과 불가능한 것을 구분하는 방법

4.1.2 내장 언어를 활용하는 방법

4.1.3 언어의 선택

4.2 현명하게 타협하기

4.2.1 작업 일정의 압박과 싸우는 방법

4.2.2 사용자를 이해하는 방법

4.2.3 진급하는 방법

4.3 팀을 위해 일하기

4.3.1 재능을 개발하는 방법

4.3.2 일할 과제를 선택하는 방법

4.3.3 팀 동료들이 최대한 능력을 발휘하게 하는 방법

4.3.4 문제를 나누는 방법

4.3.5 따분한 과제를 다루는 방법

4.3.6 프로젝트를 위한 지원을 얻는 방법

4.3.7 시스템이 자라게 하는 방법

4.3.8 대화를 잘 하는 방법

4.3.9 사람들에게 듣고 싶어 하지 않는 말을 하는 방법

4.3.10 관리상의 신화들을 다루는 방법

4.3.11 조직의 일시적 혼돈 상태를 다루는 방법

5 참고 문헌

5.1 책

5.2 웹 사이트

6 역사 (2003년 5월 현재) / History (As Of May, 2003)

6.1 피드백 및 확장 요청 / Request for Feedback or Extension

6.2 원본 / Original Version

6.3 원저자의 경력 / Original Author's Bio

국내 ISMS 인증

 한국인터넷진흥원(KISA)이 객관적이고 독립적으로 평가해 기준에 대한 적합여부를 보증해주는 제도로서

 'KISA ISMS' 라고 칭한다.

ISMS 인증제도의 목적

 - 정보자산의 안전, 신뢰성 향상

 - 정보보호관리에 대한 인식 제고

 - 국제적 신뢰도 향상

 - 정보보호 서비스 산업의 활성화

ISMS 인증제도의 특징

 - 국내 실정에 적합한 정보보호관리 모델 제시

 - 공신력 있는 정보보호 전문기관(KISA)에 의한 심사 및 인증

 - 국내 최고의 분야별 전문가들에 의한 인증 심사

 - 국내 정보보호 관련 법제도 반영

참고 사이트

http://www.kisa.or.kr

http://isms.kisa.or.kr

www.sgs.com