협업의 기술

제목은 협업의 기술이지만 그것보다는 리더로서의 올바른 역할을 보았는데 메모한 것은 개발자로서의 사회생활?

소스 코드 오픈하기
누군가 내 소스 코드를 보고 나를 판단하려는 것을 두려워하지 말자.
초기 단계에 더 많은 피드백을 얻을수록 더 많은 위험을 줄일 수 있다.

팀과 소통하기
코드 작성에 집중하기 위해 방해받지 않는 시간이 필요한 것은 사실이지만,
그보다 훨씬 더 많은 시간을 팀과 소통하는 데 할애해야 한다.

실패를 문서로 (Postmortem)
실수나 실패를 적절히 문서로 만들면 나 또는 다른 사람이 같은 실수를 반복할 확률이 적어진다.
(요약 / 현상에 대한 시간적 서술 / 발생원인 / 영향 및 피해 / 해결방법 / 재발 방안 / 배운점) 

팀 문화 만들기
가장 성공적인 팀 문화는 팀의 노력을 통해 훌륭한 소프트웨어를 출시하는 것을 가장 중요하게 여기는 문화이다.
생산적이고 건전한 팀 문화를 만들어 훌륭한 코드를 양성할 수 있도록 한다.
이는 자신의 문화를 팀에 정착시키려는 자로부터 팀을 보호하기 위해서도 아주 중요하다.

오픈 프로젝트
이 팀의 구성원이라면 프로젝트의 모든 정보에 접근이 가능하도록 만들어야 노력과 시간을 줄일 수 있다.
또 팀과 함께 소프트웨어를 작성하는 과정에서 주요 의사소통 메커니즘에 대해서도 생각해 본다.

사명(목표)
"GWT 의 목표는 근본적으로 개발자가 자바 도구를 이용, 모든 현대 브라우저에서 사용 가능한 AJAX 기법을 구현하여 사용자의 웹 경험을 향상시키는 것" 과 같이 방향과 범위의 제한이 명확한 사명이 필요하다.
사명은 프로젝트가 진행되는 과정에서도 모든 일이 올바르게 진행되도록 이끈다.

능률적인 회의
회의는 꼭 필요한 인원만 참여하고, 회의 안건을 참석자에게 미리 배포, 모두의 업무가 중단되는 시간 위주로 일정을 잡는다.
일방적이거나 메일 등으로 전파가 가능한 정보라면 회의를 주저없이 취소해야 한다.

디자인 문서
아주 간단한 프로젝트가 아니라면 디자인 문서가 나오기도 전에 코딩부터 무작정 시작하지 않도록 한다.
일단 디자인 문서가 확정되면 일정 조율과 프로젝트의 업무 분배에 대한 좋은 가이드가 될 수 있다.
프로젝트가 성장하고 변화하는 만큼 이 문서 역시 몇번이고 수정되어야 함을 언제나 인식한다.

헌신적인 리더
리더는 겸손과 존중, 그리고 신뢰가 공존하는 분위기 형성에 항상 주력해야 한다.
명확한 목표로 팀을 이끌어야 하며, 구성원의 행복도 관찰하여 팀 구성원이 이상적인 위치에 도달하게 해야 한다.

적게 약속하고 더 많이 주자
사용자들이 앞으로 구현할 기능이나 릴리즈 시점을 묻는다면, 완전히 보수적으로 예측해야 한다.
엔지니어로서 릴리즈에 모든 에너지를 집중할 수 있도록 노력해야 한다.
코드 정리나 리팩토링 같은 방어적인 업무에 시간을 투자하고 있다가는 곤란한 상황을 맞이할 것이다.

 

유지 보수
소프트웨어는 나를 위해 만든 것이 아니다. 사용자들이 사용하고 또 즐거워 해야 한다.
그 과정에서 나오는 사용자의 요구사항들은 좋은 소프트웨어를 만들수 있는 기회이다.
사용자가 없는 소프트웨어를 개발하고 싶지 않다면 이 부분을 유념해야 한다.

 

모든 기능을 제공할 수는 없다.
소프트웨어가 사용자를 위해 너무 많은 것을 제공하려고 하다 보면 배가 산으로 가는 수가 있다.
모든 문제를 형편없이 해결하느니, 대부분의 사용자가 겪는 정말 일반적인 문제들을 잘 풀어야 한다.