| |||||||||||
지금 이 순간 필요한 것인 탓일까? 책을 읽으며 와닿는 부분이 많았다.
생각해 볼 것들
- 나는 무엇인가? 연구소장, 개발실장, CTO, 팀장, 그 어느 것도 아닌 나.
- 기반 시스템 구축하기.
- 프로세스 정립. 문서화 포함.
- '문화' 만들기. (가장 어려울 듯)
아래는 책을 읽으면서 적어 놓은 것들.
기반 시스템, 조직, 프로세스, 기술, 문화.
1. 소프트웨어 회사가 성공하기 위한 다섯 가지 조건.
혁신하든가, 사라지든가.
경영자가 바꿔야 할 것을 '버리는 것'에 중점을 두고 살펴 보자.
- 하드웨어 마인드를 버려라.
- 소프트웨어는 아무나 개발할 수 있다는 생각을 버려라.
- 관리자나 영업이 개발자를 좌지우지하지 않게 하라.
- 빠른 개발의 경영 전략을 버려라.
- 일정을 협상하지 마라.
- 2% 부족한 것을 간과하지 마라.
- 조급한 생각을 버려라.
개발자가 바꿔야 할 것을 '해야 할 일'에 중점을 두고 살펴 보자.
- 자신의 능력을 정확히 알고 행동해야 한다.
- 급할수록 천천히 가야 한다.
- 처음부터 제대로 배워야 한다.
- 항상 자신을 변화시키려고 노력해야 한다.
미국 회사는 기본이 70점, 한국 회사는 20점에서 시작한다.
개발자가 집중해서 효율적으로 일할 수 있게 해 주는 것이 회사의 의무.
회사의 책임이기도 한 70%에는 기반 시스템 설치, 프로세스 정립, 코딩의 표준화,
문서화 방법, 개발 방법론, 공유 문화 정립 등 많은 일이 있다.
공유를 싫어하는 사람은 소프트웨어 회사에 적합하지 않다.
진정으로 소프트웨어 회사에 중요한 인재는 정해진 프로세스, 개발 원칙을 잘 지키면서
공유하고 협업하며 묵묵히 일하는 사람이다.
한 번 탄생한 영웅 개발자는 경영자에게 계륵과 같아.
한국에 나이 든 개발자가 없는 진짜 이유는 .. 기술 습득에 시간을 사용하지 않고
관리 업무에 시간을 소비하기 때문이다.
시스템 통합 업체는 수많은 단발성 프로젝트를 하므로 각 프로젝트마다 이윤을
창출하는 것이 최대의 목표이고 따라서 단기적이고 효율적인 관리가 더 중요하다.
.. 그런 상황에서 개발자의 미래를 위한 투자는 우선순위에서 밀릴 수밖에 없다.
2. 이슈 관리 시스템을 보면 회사를 안다.
이슈 관리 시스템, 소스 관리 시스템, 테스트 관리 시스템, 빌드/릴리즈 관리 시스템,
프로젝트 관리 시스템, 작업 관리 시스템, 고객 관리 시스템, ERP 등.
전사적으로 보았을 때 가장 중요한 기반 시스템은 이슈 관리 시스템이다.
미리 문서를 작성하고 설계를 하는 것인데 실제 전체 개발 기간이 줄어든다.
이것을 진정 믿어야 한다. 이 믿음이 없으면 문서를 작성하라는 말은 공허한 외침밖에는
안 된다.
SRS (Software Requirement Specification)
비록 개발을 위해서 주어진 시간이 1시간에 불과하더라도 SRS 작성은 가능하며 또
해야 한다.
SRS는 고객이 원하는 품질 좋은 소프트웨어를 최소 시간에 최소 비용으로 개발하기
위해 필요한 모든 것을 '왜'라고 생각하며 적는 것이다.
3. CTO의 역할은 아무나 대신하지 못한다.
벤처 투자가가 벤처 회사에 투자할 때 첫번째 보는 조건이 CTO가 있는가이다.
CTO가 없다면 일단 탈락이다.
간혹 연구소장, 개발실장, R&D 부사장 등의 직함이 CTO와 혼란을 일으킨다.
이들과 CTO를 구별 짓는 가장 중요한 기준은 CTO는 인사 관리를 안 한다는 것이다.
그쪽 CTO가 "..?"라고 물을 때 "나중에 개발자한테 물어 봐서 답해 드릴께요"라고
대답한다면 그건 CTO가 아니다.
아래 직원이 정리해 온 정보를 가지고 결정하는 것은 CTO가 아니라 관리직에 있는
연구소장 같은 사람이 하는 일이다.
CEO나 연구소장과 같은 관리자가 CTO의 결정을 좌지우지하지 않는 조직이
되어야 한다.
당신이 관리자라면 기술적인 판단은 개발자에게 맡기고 그 결정을 존중해 주는 편이
낫다. 개발자만큼의 기술을 쌓으려고 하지 말고, 개발자가 Garbage를 들고 오지
않도록 조직을 관리하는 일이 관리자인 당신이 할 역할이다.
대부분의 회사는 "우리는 개발 일정이 빡빡하고, 고객은 요구사항을 계속 변경하고,
그러니 문서 만들 필요가 없고 만들 시간도 없다"라는 억지 결론을 만들어 내고
자신의 형편을 핑계 삼아 자포자기하고 산다.
소프트웨어 회사에서 프로세스를 만들기는 정말 어려워도 무너지는 것은 한순간이다.
프로세스의 예외 적용은 극약 처방을 하는 것처럼 해야 한다. 자주 사용해서는
독에 중독된다.
4. 신입 사원은 문서 50%, 프로세스 45%, 선배 5%로부터 배운다.
선배이거나 동료이거나 타인에게서 배울 일이 많다. 그리고 회사는 이것을
시스템화시켜야 한다. 이런 지식 공유가 효율적으로 이루어지려면 잘 작성된 문서와
프로세스가 필수 조건이다.
긴급한 일을 줄이는 방법이 바로 중요한 일을 하는 것.
긴급하다고 생각하는 12시간 일 중에서 우선순위를 정해 덜 긴급한 4시간의 일은
다음으로 연기하고 가장 긴급한 8시간만 처리하고 남는 2시간은 중요한 일을
처리하는 식으로 해야 한다.
죄수의 딜레마.
회사는 .. 협업하는 사람에 대한 평가를 높여 주어야 한다. .. 모든 개발자에게 서로
다른 부서 일을 도와 주는 시간으로 20%의 시간을 공식적으로 할애해 달라는 것이다.
우리 회사는 말로만 협업을 권장하는가, 아니면 실제로 협업을 권장하는가?
협업을 위해 20%의 시간을 쓰는 것을 허락하고 있는지 살펴 보면 답이 나온다.
소프트웨어는 하드웨어와 달리, 유지보수라는 부분이 생명 주기의 60-80%를
차지한다.
시간이 없어서 제대로 제품을 만들 시간이 없는데 나중에 고칠 시간은 있는가?
(영업 부서가) 불가능한 것을 요구한다면 못한다고 해야 한다. 대신 가능한
일정이라면 제대로 하면 된다.
머지와 병행 개발은 개발자에게 피할 수 없는 인생의 일부분.
5. 소프트웨어 개발은 기술이 아니라 예술이다.
훌륭한 소프트웨어는 먼저 자신이 감동할 수 있어야 한다. 그러기 위해서는
소프트웨어 개발을 기술이 아닌 예술로 이해하는 자세가 필요하다.
무엇을 하든지 투자 대비 효과가 얼마인가를 숫자상으로 보여 달라는 경영자가
종종 있다. 이는 소프트웨어 회사의 경영자가 갖춰야 할 좋은 태도가 아니다.
.. 소프트웨어는 숫자가 아니고 깨달음이기 때문에 깨달음으로 얻는 혜택을
숫자로 산정하려는 생각은 버려야 한다.
개발자와 프로그래머에 대한 개념의 차이.
코딩을 개발이라고 생각하는 회사, 경영자, 개발자가 많은 이상 3D 업종은
당연한 결과다.
훌륭한 개발자를 보는 눈이 없는 회사에서는 진정한 개발자는 도태되고
Scientist와 Technician이 활개를 친다. 좋은 제품이 나올 리가 없다.
스마트폰, 소프트웨어 공학을 경험할 좋은 기회.
6. 기업 문화란 무엇인가?
직접적인 평가가 되는 KPI는 모두 실패하게 되어 있다.
1. 스펙은 적는가?
2. 동료 검토는 자주 하는가?
3. 자기 관련 문서를 제대로 업데이트하는가?
4. 소스 코드를 체크인할 때 주석을 제대로 남기는가?
5. 모든 버그나 기능 추가 사항은 이슈 관리 시스템에 등록하고 일하는가?
이런 프로세스 관점의 평가 지수를 사용하는 것이 훨씬 효과적이다.
"문서를 작성하고 있습니까?" "언제든지 할 수 있는데 지금은 안 하고 있습니다"
라고 말하는 것은 영원히 안 하겠다는 말의 다른 표현이기도 하다.
경영진이 갖고 있는 미신
- 스펙 문서 작성하느라 개발 일정을 못 맞추는 것이 아닙니까?
- 개발 일정이 늦어지면 개발자를 추가로 투입하지요.
- 우리가 개발할 수 없으면 외주를 주도록 합시다.
고객이 갖고 있는 미신
- 자세한 요구 사항은 나중에 정합시다.
- 소프트웨어의 좋은 점은 변경이 가능하다는 생각.
개발자가 갖고 있는 미신
- 빨리 코딩을 시작합시다. 그래서 빨리 끝냅시다.
- 제품을 만들 때까지 테스트를 못한다.
- 소프트웨어 공학을 적용할 시간이 없다.
소프트웨어 공학도 말과 같이 잘 쓰면 약, 못 쓰면 독이다.
글로벌 경쟁력에 필수인 국제화, 지역화.
댓글