소프트웨어 관리자의 개선 우선순위#
- 조엘 테스트: 조엘 스폴스키라는 사람이 만든 ‘개발팀 평가 테스트’
- 소스 컨트롤을 사용하는가?
- 한 번에 빌드를 만들어낼 수 있는가?
- 일일 빌드를 만드는가?
- 버그 데이터베이스를 가지고 있는가?
- 새로운 코드를 작성하기 전에 버그를 고치는가?
- 최신 업데이트된 스케줄이 있는가?
- 스펙(제품 명세)이 있는가?
- 프로그래머가 조용한 작업환경에 일하는가?
- 돈이 되는 한 최고의 툴을 사용하는가?
- 테스터가 있는가?
- 채용 면접 때 후보가 코드를 짜게 해보는가?
- 복도 사용성 테스트를 하는가?
- 이 테스트의 문제점은 관리자나 경영진이 각 질문의 맥락을 이해하지 못한 채 단순히 12가지 질문에 예라고 답하는 것을 목표로하는 경우가 있다.
모든 항목에"예"라고 답하는 것이 무족너 더 낫다고 동의하기 어렵다#
- 프로그래머가 조용한 작업환경에 일하는가?
- 조엘이 강조한건 몰입을 가능하게 하기 위한 조용한 공간이었다.
- 팀원이 상시 대면 의사소통을 할 수 있는 공간이 생산성 향상에 도움이 될 수 있다.
- 조용한 작업환경을 강조하다 보면 자칫 면대면 의사소통을 나쁜 것으로 생각할 수 있다.
- 돈이 되는 한 최고의 툴을 사용하는가?
- 조엘의 이야기는 툴에 돈 아끼지 말고 팍팍 쓰라는 뜻이다.
- 단순히 비싼 툴을 사용하는 것이 아니라, 툴을 고를 때 여러 조건을 고려해야된다.
12가지 질문이 개발팀 평가에서 정말 중요한 요소인가?#
- 와인버그는 배리 보엠의 연구에서 소프트웨어 개발에서 네 가지 해당 영역별로 상당한 개선을 할 경우 실제 비용이 줄어들 수 있는 범주는 아래의 순으로 많았다.
- 조엘 테스트의 절반이 넘는 문항은 ‘도구’ 분류에 들어간다.
- 조엘 테스트는 가장 만만하고 쉬운 것부터 시작하는 관리자의 성향과 비슷하다.
- 이것이 조엘 테스트가 위험할 수 있다고 생각하는 두 번째 이유다.
협력을 통한 추상화#
- 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 커뮤니케이션, 협력 능력이 더 뛰어나다.
- 그냥 협력이라고 다 좋은 것이 아니고 몇 가지 전제 조건이 필요하다.
- 두 사람이 시각화 없이 협력하는 것보다 중간 매개를 두고 협력하는 것이 훨씬 낫다.
- 둘이서 협력하면서 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 된다.
신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가#
- 신뢱 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높다.
- 신뢰 자산이 높다는 것은 조직우너들 간에 높은 수준의 신뢰가 기반되어 있다는 것을 말한다.
- 신뢰를 쌓는데 널리 사용되는 한 가지 방법은 투명성과 공유, 인터랙션이다.
- 공유 조건별 신뢰도 변화 실험
- 하나 공유: 아이디어를 하나만 생각해서 서로 공유하는 법
- 최고 공유: 여러 개의 아이디어를 만들고 그 중 최고라고 생각하는 것을 공유하는 법
- 복수 공유: 모든 아이디어를 공유하는 법
- 최고 공유와 하나 공유는 오히려 하고나면 신뢰도가 떨어진다.
- 복수 공유는 오히려 신뢰도가 올라갔다.
객관성의 주관성#
- 사람들은 설득하기 위해 괙관성이 필요하다고 생각한다.
- 그런데 이 객관성의 개념 자체과 매우 주관적이다.
- 결국 결정하는 것은 사람은 사람이다.
- 인간은 의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 역할을 하고 있으며, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없다.
- 이런 이유로 내가 설득하고 싶은 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야 한다.
이것도 모르세요?#
- 질문을 받았을 때, 공감하면서 들어주고 상대가 어떤 멘탈 모델을 갖고 있는지 파악하려고 해야된다.
- 그 사람이 왜 이런 접근을 할 수밖에 없었는지 알기 때문에 좀 더 정확하고 효과적인 제안을 해줄 수 있다.
- 또한, 다 설명해줄 필요도 없고, 핵심적인 부분만 짚어주면 된다.
- 또한, 다음 행동을 유도하는 코딩까지 나갈 수 있으면 더 좋다.
하향식 접근의 함정#
- 사람들은 전문가일수록 탑다운으로 사고하고 문제를 해결할 것이라 믿는다.
- 이는 잘 정의된 문제인 경우에만 만족한다.
- 전문가들은 자주 접하지 않았던 문제, 어려운 문제, 혹은 잘 정의되지 않은 문제를 접하면 접근법을 바꾼다.
- 조직 내에 모든 레이어를 꿰뚫는 전문가가 있으면 좋겠으나, 현재의 기능적 팀 구분(예컨데 기획팀, 구현팀, QA팀)에서는 이런 효과를 내기가 어렵다.
- 이 문제를 해결하기 위해서는 기본적으로 두 가지 접근이 가능하다.
- 한 사람이 다기능을 갖추도록(협력 빈도를 줄이기)
- 협력이 쉽게 되도록(협력에 드는 비용 줄이기)
- 후자를 잘하다보면 전자가 자동으로 좋아지기도 한다.
- 협력에 드는 비용을 줄이려면 삼투압 모형으로 조직을 구성한다.
- 배어드는 소통방식
- 발신, 수신인이 정해져 있고, 화살을 쏘면 은연중에 서로 간에 정보가 스며드는 것이다.
전문가팀이 실패하는 이유#
- 전문가들 모아서 팀을 만든다고 잘하는 것은 아니고 오히려 성과가 떨어질 수 있다.
- 정보 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하며, 소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다.
구글이 밝힌 탁월한 팀의 비밀#
- 구글에서 공개한 뛰어는 팀의 특징
- 팀에 누가 있는지보다 팀원들이 서로 어떻게 상효작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.
- 5가지의 성공적 팀의 특징을 찾았늗네, 그중 압도적으로 높은 예측력ㅇ르 보인 변수는 팀의 심리적 안전감이다.
- 팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다.
- 심리적 안전감: 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음
쾌속 학습팀#
- 팀 학습 속도는 단순히 기술적 탁월함만을 갖춘 사람보다는 학습 환경을 만들 수 있는 리더가 필요하다.
- 새로운 기술 도입을 빠르게 하는 팀은 개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일한느 새로운 방법을 만들어야 한다고 생각했다.
- 또한 리더는 기회와 가능성, 큰 변환의 흐름에 동참한느 중요성과 즐거움 등을 강조했다.
- 나는 팀장도 아니고, 정치적 힘도 없다면?
- 우선 자신의 학습 환경부터 만들어라.
- 개별 기술 이상으로 일하는 방식에 대해 실험을 해본다.
- 30분만 업무 개선을 시도해본다.
프로젝트 확률론#
- 애자일에서는 되도록 사람들이 섞이도록한다.
- 고전적 방법에서는 내 일은 내 일이고 다른 사람 일은 다른 사람 일이기 때문이다.
- 그래서 마감 시간에 맞춰 끝나도록 일부러 일을 늘리는 경향도 생긴다.
- 하지만 애자일에서는 내가 일이 빨리 끝나면 다른 사람의 일을 도와준다.
- 애자일에서는 지식을 공유하기 때문에 좋은 정보는 모두가 곧 알게 된다.