Development Team Building Consulting…
소스코드는 어디 있나요? 에서 트랙백 합니다.
Development Team Building Consulting, 거창해 보이지만 그냥 IT 관련 개발 인력들로 부서를 만들어야 하거나 어떻게든 제대로된 유지보수 부서를 꾸려야 하는 곳에 도움을 주는 일입니다.
원문의 내용에 심히 공감하게 됩니다. 1년 반동안 다섯 Team을 컨설팅을 했었고, 두 Team은 내부적인 사정으로 포기를 했고 두 Team은 나름의 결과를 내서 회사 운영 System과 잘 연계되어 정착되었고, 한 Team은 진행 중(?) 입니다.
성공한 경우은 그닥 말할 것이 없는데 (잘 쓰고 계시니까) 포기한 두 Team의 경우에 대해 이야기 해보고자 합니다.
1. 소 잃어야 외양간이 필요한 줄 알게 된다.
그러니까 외양간 자체가 없(!!)는 Case가 많습니다. 즉, ‘SCM(Source Code Management)’ 이나 Test Zone 자체가 없는 조직이 대부분입니다.
Web Site의 예를 들면.. 현재 구동 중인 Web Site의 Code를 그냥 FTP로 Download 받아서 고치고 바로 Upload 합니다. 그러다가 Error가 나면 다시.. 반복..(!!!!)
더 무서운 사실은 대부분의 현장에서는 ‘일상’이라는 것 입니다. 하루 매출 몇백만원 이상에 PM/개발자/서버관리자/웹 디자이너로 구성된 어엿한 IT개발 부서를 가진 Online Mall에서도 SCM이 왜 필요한지 Test Zone은 왜 구축하는지에 대한 생각이 전혀 없더군요. 결국 Renewal 한 Code를 Web Site 한 켠에 두고 Test를 하다가 실수로 그 부분을 삭제( rm -rf ./test ??)하여 담당자가 징계를 당하고(…) 그에 대한 대안을 찾다가 저와 연결이 된 회사가 있..습니다.
저는 그냥 사무실에 PC 1대 더 들여놓고 Subversion 으로 관리하는 요령 몇가지를 알려드리고 활용하는 방법 한 두가지를 제안해 드렸는데.. 다음 번에 다른 계약 문제로 방문하게 되었을 때, 사무실에 PC가 1대 더 들어와 있길래 ‘와 요즘은 잘 사용하시나 봐요’라고 물었더랬습니다. 그랬더니 PM님께서
“그냥 FTP에 있는 것 Copy만 해두는 용도에요. 파일 공유도 같이 하고~ xx씨가 알려준거 PC 새로 밀고 나선 더 안쓰게 되던데 두 번씩 확인 하기도 귀찮고 우리 서버 관리자도 잘 모르고..”
몇 번 더 제안을 하고 처음에 2-3시간만 교육 받고 하루 정도 서버 관리자를 제가 교육하면 될 것 같다고 다시 제안 드렸습니다만… 사장님께선
“뭐 지금도 문제 없고..이제 그럴 여력도 없고..”
그래도 Backup용 PC라도 생긴 걸 다행이라고 생각해야 할까요?…
2. 시작은 방어적인 사회생활.
최근에 포기한 모 회사의 경우입니다. 여기의 경우 일전의 조직보다 훨씬 큰 규모의 IT 관련 회사입니다. 사내에 SCM을 개인적으로 쓰고 계신 분도 있고, 그 분이 Issue Tracker등에 대해 직접 문의도 해오시고 해서 큰 기대가 되었던 곳입니다.
그러나, 그 개인적인 것을 전체로 확장하는 것 에는 실패했습니다. 인식의 문제가 아니라 방어적인 사회생활 태도들이 문제였습니다.
타 부서와의 Co-work가 무척 중요했고, 다양한 Platform에서 다양한 언어로 개발을 진행해야 했었습니다. 다양한 형태의 Co-work Process가 존재 했고 그 존재하는 형태 만큼의 제 각각의 Source Code Set들이 존재하였습니다. 그런 상황에서 지치지 않을 개발자가 어디에 있을까요? 개발 부서에서의 SCM의 필요성은 거의 절대적이였지요.
CTO님도 설득해보고 대표이사님도 설득해 봤습니다만, CTO님도 그리고 개인적으로 쓰고 계시던 분도, 인식을 같이 하시던 분들도 타 부서와의 Co-work 형태가 바뀌어 자신이 비난을 받아야 하는 것에 난색을 표하셨고, 타 부서의 분들도 ‘그냥 지금처럼 하는게 더 좋을 것 같아요~’ 라고 해버리셔서 Drop 되어버린 경우가 있습니다.
결국 난색을 표하시던 개발자분들은 Burn out 되셔서 회사를 떠나신 상태. 회사의 기 구축된 Solution의 기초적인 운영마저 힘들어지고 있는 상황입니다. 누구 하나 나서서 기존의 것을 바꾸지 못한 결과 치고는 너무나 큰 것이였습니다.
소를 사려면 외양간 부터 있어야죠!!!
Source Code가 가져다 주는 결과 물이 ‘소’라면 그 ‘소’가 지낼 ‘외양간’은 있어야 하지 않겠습니까? 지낼 곳 없는 ‘소’가 도망가거나(Code 유실), 추위에 떨다 쓰러지거나(Code 관리가 되지 않아 추가 개발 비용이 대폭 증가/Debug에 기간이 무척 걸림) 하면 안되지 않습니까?
회사를 운영하신다면 계약서, 세금계산서 같은 것들을 함부로 관리하시지는 않으실 텐데, IT 회사, 개발된 Contents를 가지고 계신 회사에서 이런 것들을 관리 안하신다면 계약서, 세금계산서 같은 것들을 관리 안하시는 것과 같지요!
아무리 소가 10마리 20마리 있으면 무엇 하겠습니까? 소가 지낼 외양간이 없어서 언제 다치고 언제 도망갈지 모르는데!