마지막으로 한 마디 덧붙이자면, 마이크로소프트에서 오랫동안 일하면서 나는 프로젝트를 관리하는 방식이 프로젝트 규모와 추상화 수준에 따라 달라진다는 귀중한 사실을 깨달았다. (10명 정도로 이루어진) 팀이나 기능 수준에서 하는 프로젝트 관리가 있고, (50여 명에서 5,000여 명이 제품 버전 하나에 매달리는) 프로젝트 수준에서 하는 프로젝트 관리가 있고, (경영진의 주도 아래 여러 버전으로 이어지는) 제품 수준에서 하는 프로젝트 관리가 있다. 애자일 방법론은 팀 수준에서 효과를 발휘하고, 정형기법은 프로젝트 수준에서 효과를 발휘하며, 장기적인 전략 기획론은 제품 수준에서 효과를 발휘한다.

우리는 우리 자신이 엔지니어가 아니라 개발자라는 사실을 인정해야 한다. 기존 공학이 수백 아니 수천 년에 걸쳐 쌓아온 경험적 예측성을 소프트웨어 공학에서 기대해서는 안 된다. 이는 컴퓨터가 ‘내가 시키는 일’이 아니라 ‘내가 원하는 일’을 하길 기대하는 행동과 별반 다르지 않다. 우린 아직 그만한 수준이 아니다.

기본적으로, 선별 회의에 문제가 있다면 팀에도 문제가 있음을 뜻한다. 회의 분위기가 나쁘면 팀원 사이도 나빠져서 보복적인 행동이나 파괴적인 행동을 초래하기 십상이다.

거짓말을 가려내려면, 무엇보다 먼저 거짓말하는 근본 원인을 밝혀야 한다. 가장 좋은 방법은 5Whys로, ‘왜Why’라는 질문을 다섯 번 던진다. 왜 거짓말을 하는가? 어떤 고통을 피하려 하는가? 왜 고통을 피하려 하는가? 어떤 위험이 생기는가? 왜 위험이 생기는가? 위험을 줄일 방법이 있는가? 왜 위험을 줄이려고 노력하지 않는가? 어떤 조치가 더 필요한가? 왜 손 놓고 있는가? 당장 행동하라!

구현을 끝내고 열심히 벌레를 잡는 중에 이메일 한 통이 도착한다. 오호라, 새 명세가 나왔네! 확 무시해주겠어! 아니 잠깐, 가만 보니 명세가 없다고 생각했던, 그러니까 소위 “코드가 명세”라 여기고 이미 구현해버린 핵심 기능이잖아.

목적이 뭐죠? 내가 다음으로 던질 질문은 “목적이 뭐죠”다. 결정을 내리려고 하나요? 좋습니다. 결정을 내립시다. 아이디어를 내고, 상태를 점검하고, 소문을 퍼뜨리는 시간이 아닙니다. (상태 보고 회의처럼) 정보를 공유하려 하나요? 좋습니다. 정보 목록을 훑어봅시다. 결정을 내리거나 문제를 풀 필요는 없습니다. 아이디어를 얻으려고 하나요? 좋습니다. 모두 아이디어를 내놓읍시다. 가능성을 따지고 비판할 필요는 없습니다. 마지막에 가장 좋은 아이디어를 선택하면 그만입니다.

왜 이제서야 말하죠? 중요한 사안이라면 핵심 인문들을 놀래키지 말아야 한다. 중대한 사안을 모르고 넘어가도 좋은 사람은 없다. 중대한 사안을 성급하게 결정하고 싶은 사람도 없다. 회의를 원활하게 진행하려면 핵심 인문들과 미리 의논해야한다. 사전에 타협안을 협상하고 모두의 호흡을 맞츤다. 그러면 회의는 협상안을 승인하는 형식에 지나지 않는다. 모든 의사결정 회의는 이렇게 진행하는 편이 바람직하지만, 다소 시간이 걸린다는 단점이 있다. 그러나 중대한 결정이라면 그만한 노력이 필요하다.

혹시 놓쳤을지 모르니 요점을 한 번 더 정리하겠다. 우수한 명세서는 다음 요건을 갖춰야 한다. 쉽고 단순해야 한다. 빈틈이 없어야 한다. 피드백을 주고받기 쉬워야 한다. 품질을 점검할 방법이 있어야 한다.

쉽고 단순하다 명세서는 쓰기 쉽고 읽기 쉬우며, 유지하기 쉬워야 한다. 다이어그램은 UML처럼 표준 표기법을 사용하고, 문장은 상식적인 용어를 사용해야 한다. 너무 많은 내용을 담아서도 안 되고, 주절주절 늘어놓아서도 안 된다. 명세서는 조항 세 개와 메타데이터만 있으면 충분하다. 요구사항 기능이 존재하는 이유는? (시나리오나 퍼소나 persona와 연결한다.) 설계 기능이 동작하는 방식은? (그림, 애니메이션, 다이어그램을 사용하면 좋다.) 문제점 결정이 필요한 사안, 위험, 장단점은?(예, 의존성) 메타데이터 제목, 간단한 설명, 작성자, 기능팀, 우선순위, 비용, 상태이상이다.

너는 내 반쪽이야 테스터를 쓰레기 취급하면 십중팔구 쓰레기를 출시하고 쓴맛을 보게 된다. 우수한 제품을 원활하게 출시하려면 테스트팀을 혈맹으로 만들어야 한다.

그들은 우리와 다르다 인문학도는 규칙을 규칙이라 믿는다 인문학도는 권한을 존중한다. 인문학도는 무작정 집적대지 않는다. 인문학도는 만사가 단순하다고 가정한다. 인문학도는 세세한 설명을 개의치 않는다. 인문학도는 순수성을 우려하지 않는다. 인문학도는 감정과 체면을 중시한다.

기업 제품 시장에서 경쟁사는 빵빵한 지원 인력과 컨설턴트 수로 승부했다. 실제로 많은 경쟁없체가 제품 지원과 컨설팅을 가장 큰 사업 분야로 꼽는다. 그러니까 제품이 복잡하고 실패가 잦으면 오히려 돈이 된다는 뜻이다.

용역꾼은 일단 부딪히고 본다. 행동이 먼저고 생각은 나중이다. 누가 뭐라 해야 마지못해 뒤처리를 한다. 평소에 많이 보는 모습이 아닌가? 반면, 공예가는 미리 연구하고, 계획하고, 가장 적합한 기법과 도구를 사용하고, 자기 결과물에 자부심을 가진다. 우수한 소프트웨어 개발자가 여기에 속한다. 하지만 그래도 공예를 공학이라 보기는 어렵다. 결과를 정확히 예측하지 못하기 때문이다. 공예는 확실성과 예측성이 부족하다. 결과를 알기 보다는 최대한 예측하는 수준이다.

… 관리자가 (개인측정)자료를 비교하기 시작하면 팀원들이 측정값을 속인다.

책임자는 누구인가? 브레인스토밍과 ‘공동설계’를 혼돈하지 않도록 주의한다. 아이디어를 내고 토론하는 사람은 여럿이라도 설계 책임자는 하나여야 한다. 최종 권한과 책임은 한 사람에게 있고, 설계 문서에도 이 사람 이름이 올라간다. 책임자를 정하면 설계가 일관성 있으며 명료해진다. 책임자는 설계가 요구사항을 만족하도록 책임질 사람이자 선택한 설계안을 이해하고 방어할 대변인이다. 반면, 줏대 없이 동의한 설계안이 작은 부하에도 깨질 때 다른 사람을 비난하려는 겁쟁이들이 공동 설계를 선호한다.

시갈의 법칙에 따르면, “손목 시계가 하나인 사람은 몇시인지 정확히 알지만, 손목 시계가 두 개인 사람은 절대로 현재 시각을 확신하지 못한다.” (동기화에 관해서…)

성능 때문에 코드와 자료를 복사한다는 사람들에게 한 마디 하겠다. 이제는 처리 속력이 빨라지고 캐시 적중률이 높아지는 탓에, 계산을 다시 하는 편이 계산 결과를 저장해서 가져오는 쪽보다 빠르다는 사실을 기억하기 바란다.

설계가 중요하다는 사실은 누구나 안다. 우수한 설계가 우수한 제품을 내놓는다는 사실도 안다. 그렇지만 빌어먹을, 어느 시점에는 코드를 짜야한다. 어느 시점에는 제품을 내 놔야 한다. 아무리 우수한 설계라도 제시간에 구현하지 못하면 무용지물이다. “시간이 얼마가 들어도 좋으니 맘껏 설계하세요.”하고 말하는 관리자는 많지 않다.

많은 개발자가 아키텍트란 실용성, 효율성, 실천 따위를 무시하고 다이어그램, 추상화, 심오한 사고에 매달리는 사람이라 생각한다. 손발 걷어 붙이고 코드에 뛰어들기보다 순수성과 우아함에 집착하는 아키텍트를 너무 많이 봤기 때문이다. 잘난 체하며 현실에서 동떨어진 아키텍트를 가리키는 이름이 있다. 바로 ‘해고 1 순위’다.

관리자는 여러 가지 요구사항을 한꺼번에 다루는 사람이며, 누군가는 매력이 떨어지는 기능을 맡아야 한다. 그걸 기꺼이 받아들였다면 자기 무덤을 자기가 판 꼴이다. 편히 잠들기를 바랄 뿐이다.

가계부 숫자 맞추기도 힘들어요 ‘일과 삶의 균형 맞추기’ 자신이 선택한 생활 양식을 이해하고 받아들여라. 첫 단계는 ‘자신을 알자’다. 상사와 기본 원칙을 정하라. 아무 말 없이 타협하지 마라. […] 그래서 내가 불만을 표명할 때까지 계속 밀어붙인다. 결국 덜 바람직한 선에서 타협하게 된다. 필요하다면 RAS나 원격 데스크탑이나 OWA를 활용하라. 분리라는 정신분열성 가식을 버려라. […] 집이나 회사나 똑같이 살아가라. 책임 있고 예의 바르게.

프로그래밍 문제를 던지는 이유는 올바른 답안을 구하기 위해서아 아니다. 지원자가 문제에 접근하고 해결하는 방식을 관찰하기 위해서다. 똑똑한 지원자라도 짧은 시간 내에 문제를 해결하지 못하는 경우가 흔다.