조엘 온 소프트웨어에 나온 하나의 글이 돌아다니기에 생각을 적어봅니다. 정말 오랜만에 개인의 생각을  적어본 글이네요…

더 나은 코딩을 만들기 위한 12단계 라는 주제로 아래와 같은 지침을 제시하고 있습니다.

• Source Control(소스 컨트롤)을 사용하십니까?
• 한번에 빌드를 만들어낼 수 있습니까?
• daily build(일별 빌드)를 만드십니까?
• 버그 데이타베이스를 가지고 있습니까?
• 새로운 코드를 작성하기 전에 버그들을 잡습니까?
• up-to-date(최신) 스케줄을 가지고 있습니까?
• spec(설계서)를 가지고 있습니까?
• 프로그래머들이 조용한 작업환경을 가지고 있습니까?
• 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
• 테스터들을 고용하고 있습니까?
• 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
• hallway usability testing(무작위 사용성 테스팅)을 하십니까?

우와 이것을 잘 지키면 정말 더 나은 코딩을 만들기 위한 단계가 될까가.. 저의 얼굴일 살짝 찌뿌려 지더라구요…  뭔가 불편합니다.

왜 이런 생각을 가졌을까요?    뭐가 빠졌다고 생각이 들기 때문입니다. Kent Beck님이 한국에 세미나때.. 하셨든 말들.. 그리고 Linda Rising 누님께서 나눈 말때문이거 같아요.  전 대기업에서 일을 해왔지만, 소마에 프로그램을 통해 많은 스타트업을 보았고. 많은 것을 깨달았습니다.

이것보다 선행되어야 하는게 있습니다.

• 정말 고객이 원하는 소프트웨어 일까요?
• 고객이 짜증내고 불편해 하는 pain point를 개발자도 알고 있나요?
• 고객의 피드백을  다음 전략때 반영할 정도로 고객의 말을 잘 경청하고 우선순위를 매기고 있나요?
• 팀원이 서로를 신뢰하고 있나요?
• 나의 문제가 나만의 문제가 아니라, 팀의 문제이고 같이 고민해줄 동료가 있나요?
• 오늘 팀원들 중에 인상이 안 좋은 팀원에게  무슨 일이 있냐며 안부를 물어 보셨나요?
• 슬픈 일이 있는 동료에게 위로의 메세지나 차라도 한잔 나눌 만큼 조직은 따뜻한가요?

서로를 신뢰하지 못한 팀들에게 망할 분업화에가 더해진 상황에서, 만약 위에 12단계가 실행된다면. 책임 전가에 여러가지 고통.. 다들 아시잖아요..

물론 현실은 차갑지만, 그래도 고객을 보며, 서로 끈끈한 스타트업이 정신건강에는 더 좋습니다..  더 이상 말하지 않겠습니다. 이 바닥에 좀  있으신 분은 아실거에요..  제가 왜 이런 말을 하는지..