IT 15년 썰 - 8
프로젝트 진행 방법론 1부 - 팀을 위한 4원칙
내 경우엔, 지난 7화에 썼던 파이서비스를 개발-론칭하면서,
나름의 프로젝트 진행/리딩에 대한 개념이 잡혔다.
그리고 2005년 개발자 컨퍼런스에서 그중 일부 내용을 발표했는데,
그걸로 컨퍼런스 발표 2등 먹었다. (모호호호)
당시 CTO 께서 들으시고 "이제 어린이가 아니네요? 깜짝 놀랐어요" 라고 해주신 말씀도 아직 기억난다. (모호호호2)
당시 프리젠테이션 표지, 꺄~~ 너무 촌스럽다아~~~~당시엔 프로젝트 진행 방법론이란 게 딱히 있지도 않았고,
지금처럼 사람들이 경험이 많지도, 잘 정리되어 있지도 않은 시절이라, 나름 참신한 내용이었다.
10년이 넘은 내용이긴 하나, 가끔 돌아보는 내용이라 한 꼭지로 다뤄 본다.
(그렇다. 이렇게 길게 설레발치는 것은, 요즘 시대엔 당연하게도 여겨지는 내용들이라 ㅎㅎ)
팀을 위한 4원칙, 시작해 볼까아~
(당시는 '개발'팀이라고 생각하고 정리했으나 프로젝트 팀 전체로 봐도 무방하다)
1. 먼저 보이고, 그 후에 고치자
지금은 모든 개발 방법론의 제 1원칙처럼 대중화된 내용이다.
서로 이게 맞다, 저게 맞다 논쟁하고,
머릿속이나 문서상에 있는 내용을 아무리 고치고 고쳐봤자... 아무 의미 없다.
모두가 같은 생각을 하고 있는 건지,
같은 생각이라고 쳐도, 그 생각대로 만들어질 수는 있는 건지,
생각대로 만들어졌다 해도, 실제로 보면 만족스러운 모습일지,
봤을 때 만족스럽다 해도, 사용해봐도 만족스러울지,
너와 나 말고 이 사람, 저 사람 또 그 사람도 만족스러울지,
생각 외의 사이드 이펙트가 생기는 것은 아닐지,
우린 미리 알 수가 없다.
큰 개념부터 차례로 만들고, 다 같이 보면서 고쳐나가야 한다.
문제가 생기면 바로 해결책을 찾아 길을 틀어야 한다.
그게 가장 효율적, 효과적인 지름길이다.
죽자고 몇 날 며칠 싸운 결과를 실제 만들고 나면,
"하;;;; 생각하고 틀리네, 쏴리" 이런 경우 생각보다 많다.. 그 시간과 정신 소모.. 아깝다.
또, 눈에 보이고 써보면, 다른 아이디어가 생각난다.
써보며 나온 아이디어는, 실제 유저가 된 상황이기 때문에 의미 있는 아이디어일 확률이 높다.
상상으로 미리 다 만든 내용을 구현만 한 것과,
중심기능을 만든 후 쓰면서 살을 붙인 것은 결과가 다르다.
아래 대답에 YES라고 답할 수 있다면 OK.
- 서비스 시작부터 프로토타입을 만들면서 진행하고 있나요?
참고로, 파이 서비스 경우, 개발을 시작한 지 2주 후 개발 버전을 팀에 오픈했다.
그리고 그때부터 써보면서 고치는 것이 시작되었다.
"어디 어디까지 완료되었어요"라는 공유도 필요 없어진다.
2. 테스트 환경을 구축해서, 평화를 찾자
최대한 일찍부터, 실제 서비스가 운영될 구조로 세팅한다.
'테스트 환경 - 리얼 환경' 2단계 이던지,
'테스트 - 스테이지 - 리얼 환경' 3단계 이던지,
무엇이 되었건, 여기서 메시지는,
문제가 생겼을 때 본인이 당황하지 않고 대응할 수 있는 환경이 구성되어 있으면 된다.
그리고, 같은 소스를 가지고 주의 없이 배포를 하더라도(급하게 배포하게 되더라도)
리얼 서버는 리얼 리소스들을 바라보도록, 테스트 서버는 테스트 환경을 바라볼 수 있도록,
환경에 대한 세팅은 소스와 분리되어 동작해야 한다. (소스에 하드 코딩되어 있어서는 안 된다.)
이런 세팅이 사람 손을 거쳐야 할 경우 실수는 반드시! 발생한다.
사람의 '주의'에 의존하도록 구현해서는 안된다.
그때 일어나는 문제는 그 사람이 만든 것이 아니다, 사람에게 의지하도록 만들어둔 시스템(세팅)이 문제다.
요즘은 이런 문제의식에 대한 고민이 시스템에 많이 녹아들어,
쉽게 컨트롤할 수 있는 플랫폼들도 다양하게 생겨났다.
그런 플랫폼들을 왜 사용하고 무엇을 사용해야 할지, 그 개념을 가지고 있으면 된다.
물론 예상 유저가 몇 명 안되는데 이런 환경을 구축할 필요는 당연히 없다.
그 환경은 유저의 규모와 서비스의 특성에 따라 그때그때 다르다.
내가 세운 기준에 따라, 만족스럽게 대응할 수 있는 환경이면 된다.
다만,
'테스트 환경' 이란 것을 생각해 보지 않은 개발자가 있다면,
한 번쯤 곰곰이 고민해볼 필요가 분명히 있다.
이 원칙에 대해서는, 아래 질문에 'YES'라고 대답할 수 있으면 OK.
- 테스트 : 스테이지 : 리얼 환경이 분리되어 있나요?
- 각각의 환경은 소스와 분리된 설정만으로 역할 관리가 되나요?
3. 매일 배포하자
지난 글에도 언급하긴 했으나, 데일리(매일: 상황에 따라 적당한 짧은 기간) 배포는 많은 장점을 가진다.
매일 배포를 하면, 우리 서비스는 이미 오픈할 준비가 다 된 것이나 다름이 없다.
하루 동안 한 일을 돌아보게 되고, 그 일이 일단락 마무리가 되고,
모두 함께 진전된 내용을 눈으로 확인하고 써보게 되고,
써보면 제일 없어서 답답한 기능이 와 닿아서 그것부터 만들게 되고,
최소한의 필요한 기능 요소(Minimum Viable Product, MVP)가 모두 붙은 순간,
오픈 대기 상태나 다름없다.
아직 덜 구현한 부분은 '곧 선뵙니다'라는 메시지가 나오도록 해두면 그만이다.
그런데 실제로 써보면 그런 기능은 애초에 필요 없는 기능이란 걸 깨닫게 되는 경우도 허다하다.
차라리 그 기능을 버리고, 써보면서 아쉬움을 느꼈던 부분을 더 보완하는 것이 낫다.
그리고 매일 배포하는 이점을 최대한 누려야 한다.
즉, 배포본을 보고 있는 사람들의 피드백을 받을 통로를 마련한다.
보통은 귀찮아서 피드백을 하지 않는데,
그 피드백을 받을 방법. 불편함을 느낄 때 바로 피드백을 하게 하려면 어떻게 해야 할지 고민해야 한다.
개인적으로는,
사내 동료들로부터 내가 만들고 있는 서비스에 대해 욕을 먹는 것도 환영한다. 특히나 오픈 전에는.
오픈 전 받는 나쁜 피드백은, 유저들로부터 들을 것을 미리 듣는 것으로, 엄청나게 감사한 일이다.
혹여 동료라고, 동료의 서비스라고 나쁜 피드백에 섭섭해하는 사람들은, 특히나 리더들은,
서비스를 만들 자격이 없다고 생각한다.
물론 서비스를 만드는 이들의 행복과 만족감도 매우 중요한 부분이나,
서비스의 본질은 유저를 위함이다. 피드백이 막힌 서비스 제공자는 존재 의미가 없다.
이 원칙을 잘 지키고 있는지 확인할 수 있는 질문은 아래와 같다. 모두 YES 가 아니라면, 점검이 필요하다.
- 매일 deploy를 하고 있나요? Deploy 노트를 관리하고 있나요?
- 내일 , 데모 버전으로 오픈할 수 있나요?
- 테스터(사용자)로부터 Feedback을 쉽게 받을 통로가 있나요?
4. 내가 유저고, 내가 책임자다
이 프로젝트를 진행하는 이유가 무엇인지 다 같이 주기적으로 짚어본다.
마음에 안 드는 부분이 있으면, 마음에 들 때까지 고친다.
개발자는 개발만, 디자이너는 디자인만 하는 것이 아니다.
모든 멤버가 목표가 뭐였는지, 그것을 향해 가고 있는지 알고 있는 것이 중요하다.
이 부분을 확인할 수 있는 질문은 아래와 같으며,
멤버 중에 No라고 말하는 사람이 있다면, 멈추고 돌아볼 필요가 있다.
- 이 서비스는 성공할 것인가요?
물론, 모두가 한마음으로 서비스의 '성공'을 믿는다는 것은 실로 환상적인 일이다.
매우 행복한 상황이다.
따라서 이 질문은, 아래처럼 활용해 보는 것이 현실적일 수 있겠다.
이전에 '성공'에 대한 질문했던 때보다, 이번 '성공'에 대한 대답이 더 비관적이 되었다면,
멈추고 돌아볼 필요가 있는 것으로.
아 이런 심각한 얘기 말고 잼난 얘기 많은데...
난 너무 진지해서 탈이얌...
2005년 어느 날 그린 낙서2부, 리더를 위한 4원칙은 아래 링크에.
https://brunch.co.kr/@greenful/31
