획일화된 프로세스의 함정
2011/04/03 11:11 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
SW를 개발하는데 있어서 체계화된 프로세스가 필요하다는 것은 당연하다.
대부분의 SW회사가 최소한의 프로세스도 없이 주먹구구식으로 SW를 개발한다. 작은 회사들은 문제가 안되는 것처럼 보이지만 회사가 조금만 커져도 여기저기서 문제가 발생하다.
이런 문제에 시달리다보면 프로세스와 문서화가 이 문제를 해결해 줄것이라고 너무 믿게 된다.
그래서 엄격한 프로세스를 만들고 각 프로세스마다 문서를 꼭 만들게 하고 검사를 하기도 한다. 물론 프로젝트의 종류에 따라서 만드는 필수문서를 다르게 하기도 하지만, 이러한 규정은 개발자들이 요리조리 프로세스를 피해가는데 활용이 되곤 한다.
프로젝트에서 꼭 필요한 문서를 획일적으로 정하는 것은 매우 어렵다. 프로젝트 팀에서 결정하고 이를 존중하는 것이 좋다. 하지만 아직 개발팀의 역량이 부족하고 문화가 부족하다면 개발팀의 결정을 따르기도 어렵다.
가장 좋은 방법은 회사가 작을 때부터 체계적으로 개발하는 방법을 익히고 스펙과 설계를 적절하게 작성해가면서 개발문화를 키워나가고 개발자들의 역량이 같이 커져가는 것이다. 그렇게 되면 회사가 커져도 좀더 복잡한 프로세를 자율적으로 운영할 수 있게 된다.
하지만 대부분이 회사는 이러한 기회를 놓치게 된다.
그래서 택하는 것이 획일화된 프로세스이다. 이 고통스러운 프로세스를 거쳐서 이겨내면 점점 자율적인 프로세스로 바뀌게 되지만 이를 극복하지 못하면 점점 더 복잡하고 엄격한 프로세스를 만들게 된다.
가장 좋은 방법은 회사가 성장함에 따라서 문제가 생기기 이전에 미리 체계를 갖추고 개발자들의 역량을 키우는 것이고, 이미 문제가 발생했다면 최소한의 프로세스만을 만들고 지금이라고 개발자들이 분석, 설계 역량을 키울 수 있도록 회사에서 지원하는 것이다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
RSS Feed
SW를 개발하는데 있어서 체계화된 프로세스가 필요하다는 것은 당연하다.
대부분의 SW회사가 최소한의 프로세스도 없이 주먹구구식으로 SW를 개발한다. 작은 회사들은 문제가 안되는 것처럼 보이지만 회사가 조금만 커져도 여기저기서 문제가 발생하다.
이런 문제에 시달리다보면 프로세스와 문서화가 이 문제를 해결해 줄것이라고 너무 믿게 된다.
그래서 엄격한 프로세스를 만들고 각 프로세스마다 문서를 꼭 만들게 하고 검사를 하기도 한다. 물론 프로젝트의 종류에 따라서 만드는 필수문서를 다르게 하기도 하지만, 이러한 규정은 개발자들이 요리조리 프로세스를 피해가는데 활용이 되곤 한다.
프로젝트에서 꼭 필요한 문서를 획일적으로 정하는 것은 매우 어렵다. 프로젝트 팀에서 결정하고 이를 존중하는 것이 좋다. 하지만 아직 개발팀의 역량이 부족하고 문화가 부족하다면 개발팀의 결정을 따르기도 어렵다.
가장 좋은 방법은 회사가 작을 때부터 체계적으로 개발하는 방법을 익히고 스펙과 설계를 적절하게 작성해가면서 개발문화를 키워나가고 개발자들의 역량이 같이 커져가는 것이다. 그렇게 되면 회사가 커져도 좀더 복잡한 프로세를 자율적으로 운영할 수 있게 된다.
하지만 대부분이 회사는 이러한 기회를 놓치게 된다.
그래서 택하는 것이 획일화된 프로세스이다. 이 고통스러운 프로세스를 거쳐서 이겨내면 점점 자율적인 프로세스로 바뀌게 되지만 이를 극복하지 못하면 점점 더 복잡하고 엄격한 프로세스를 만들게 된다.
가장 좋은 방법은 회사가 성장함에 따라서 문제가 생기기 이전에 미리 체계를 갖추고 개발자들의 역량을 키우는 것이고, 이미 문제가 발생했다면 최소한의 프로세스만을 만들고 지금이라고 개발자들이 분석, 설계 역량을 키울 수 있도록 회사에서 지원하는 것이다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
'개발프로세스' 카테고리의 다른 글
| 문서는 얼마나 적어야 할지? (2) | 2011/10/27 |
|---|---|
| 획일화된 프로세스의 함정 (6) | 2011/04/03 |
| 이번 프로젝트 내일 끝나? (10) | 2011/01/31 |
| 소프트웨어 관료화 (16) | 2009/08/31 |
| 프로세스가 창의성을 저해한다고? (8) | 2009/04/08 |
| 소프트웨어 개발의 극과 극 (0) | 2009/02/18 |
Trackback Address: http://allofsoftware.net/trackback/220
문서 없이도 대부분의 프로젝트들이 별 문제없이 잘 진행되고 있는 상황이기 때문에 개발자들이 필요성을 못느끼고 있는것 같습니다.
개발자들이 무엇인가를 하게 하려면.. 그것이 필요한 이유에 대한 공감대를 먼저 공유하는것이 중요하다고 봅니다.
문서화의 필요성을 느끼게 해 줄 수 있는 방법이 있다면.. 문서 작성을 거부감 없이 회사에 전체에 적용 할 수 있겠지요.
회사가 조금만 커져도 문제가 된다고 하셨는데.. 개발자가 몇 명 정도 되었을때 이런 문서와 프로세스의 부재로 인한 문제가 생긴다고 보시는지요?
사실 회사를 경영하는 사람 입장에서는 문제가 생기기 직전의 규모까지는 문서와 프로세스를 진행하지 않다가 문제가 생길 만한 규모가 될 정도부터 관심을 가지는것이 가장 합리적인 선택이라고 봅니다.
이성열
문화적으로 정착되기 전에는 스스로 필요성을 느끼기 힘듭니다. 문화적으로 정착이 되면 왜 필요한지 생각하지 않고 그냥 당연히 하게 됩니다. 그래서 문화죠.
그래서 대부분 문제가 크게 터진 다음에 필요성을 느끼게 됩니다. 작은 규모의 회사에서 가장 먼저 터지는 경우는 "개발자의 퇴사"입니다. 그리고 "회사의 성장"입니다.
둘다 "공유의 문화", "협업의 문화"가 부족해서 문제가 됩니다. 그 방법이 "문서"와 "프로세스"입니다.
물론 혼자 개발을 해도 이를 지키는 것이 더 빨리 개발할 수 있는 방법이지만 스스로 느끼기는 어렵습니다.
보통 첫번째 "공유"의 문제는 개발자 10명 쯤에 생깁니다.
그리고 "관리"의 문제라고 생각하는 이슈들이 25~30명 쯤에서 생깁니다. 하지만 이 또한 "공유", "협업" 부재의 문제에서 생겨납니다. 대부분의 개발 조직은 관리보다는 "투명한 개발"에서 저절로 관리가 되도록 되어 있기 때문입니다.
관리의 이슈가 되는 것은 100명, 400명 쯤 겪는 이슈입니다. 작은 조직일 때부터 "문화"를 잘 갖춰나간다면 이정도로 커져도 큰 문제가 없습니다. 하지만 "문화"는 엉망인데 "관리"로 해결하려고 하면 문제가 더 커집니다.
이성열님 회사도 문제가 터진 다음에는 어렵습니다. 개발자들을 설득하는 방법은 개발자들에게 "소프트웨어 공학"을 이해시키고 왜 개발자들이 체계적으로 개발을 해야만 성장을 하고 "고급개발자"가 되는지 납득시키는 겁니다. 주먹구구식으로 개발을 하면 10년을 또는 20년을 개발해도 3년차 개발자와 다를 것이 없습니다. 코딩 속도 조금 빨라진 정도입니다. 저는 그런 개발자에게는 절대 연봉을 5,000만원 이상을 주지 않을 겁니다.
연봉 1억, 2억 이상 가치의 개발자가 되려면 스펙, 설계를 잘 쓸줄 알아야 합니다. 자기가 코딩까지 다 해야만 개발을 할 수 있으면 평생 초급 개발자입니다. 개발자들에게 나아가야 할 방향을 자꾸 주지시켜서 세뇌를 시켜야 합니다. 이것이 개발자도 회사도 좋은 길입니다.
저는 문서화를 제가 기억못하기 때문에 합니다.
기억하고 있다면 대화가 가장 커뮤니케이션이 효율이 좋고..
기억하지 못한다면 그때 얼른 적습니다.
그리고 기억하지도 못하고, 문서화도 없다... 그건 무조건 폐기하는 대상입니다.
너무 단순하죠?
안녕하세요. whitekid님
문서화의 첫번째 이유가 자신을 위해서죠. ^^
돈과 시간이 그 실행의 기준이 될것 같습니다.
문서화에는 비용이 드니까요.
저의 생각으로는
만들어지는 모든 함수를 사전처럼 만들어서 사람들이 공유할 수 있게 된다면
문서화'도 되고 재사용도 되고' 개발비용과 불필요한 노력도 줄어 들 수 있을것 같습니다.
더. 나아가. 이 문서화된 데이터가 함수이면서도 UI 에 쓰여질 수 있다면. 엄청난 도구가 될듯합니다.
안녕하세요. shint님
저는 문서화는 비용으로 생각하지 않습니다.
문서화를 비용으로 생각하는
1. 필요 없는 문서를 경우는 문서를 너무 많이 적거나
2. 문서를 작성하는 경험과 실력이 부족하거나
3. 프로젝트가 끝나고 적는 경우입니다.
문서는 필요한 만큼만 필요한 시기에 적어야 합니다.
프로젝트에서 가장 중요한 문서는 스펙(SRS)입니다.