우선 그 흔한 조ㅅ소기업은 아니라고 밝혀둡니다.
개발자로 오래 일해오면서 가장 힘든점은 역시 "일정"이죠.
나도 첨해보는 일을 일정짜라는거.
그런데 더 웃긴건 이미 위에서는 출시일정은 정해놓죠. "한달 줄테니 만들어놔. 세부일정은 니가 만들고. 거기에 검증기간도 포함인거 알지?" 이런식이 거의 대부분이었습니다.
요약하면 "내가 원하는 제품을 최대한 짧은 기간에 버그없이(?) 만들어라"죠
여기에 좀더나가서 기존 제품에 문제가 터지면 그거부터 먼저 처리하라고하죠. 개발자 욕은 덤이구요.
"버그가 왜 있는거냐 도데체."
"너 일을 어떻게하는거냐."
그리고 기존일정은 일정대로 지키라고하고. 거기서부터 개발자들의 야근 지옥이 시작된다고 생각합니다.
야근을 계속하다보면 더욱더 버그는 많아지고 일정의 압박이 있다보니 코드는 점점더 이상해지고 유닛테스트코드 같은건 꿈도 못꾸는 일이 발생하죠.
전직 개발자로 위 과정을 겪어온 저희 사장님이 지키는 원칙은.
1. 개발일정은 개발자가 직접 정한다.
2. 고객사의 요청으로 일정이 어쩔수 없을때는 고객사와 협의를 통해 기능을 줄여서 일정을 맞추는 방향으로 한다.
3. 중간에 급한 버그 수정 등이 있으면 기존 일정을 버그 수정 기간 만큼 기존 일정을 늘인다.
이정도만 해도 개발이 편해집니다.
물론 개발이 생각보다 일찍 끝나면 솔직하게 말합니다. 늦게 끝나면 늦게 끝날것 같다고 이야기하구요. 여기서 핵심은 사장님에게 늦게 끝난다고 했을때 개발자를 믿어주고 일정 조정을 고민한다는 겁니다. 개발자 욕을 하는게 아니구요. (사람이 적어서 일수도 있겠죠?)
제가 다녀본 회사중에 가장 규모는 작지만 이러한 이유로 지금까지는 제가 다녀봤던 어떤회사보다 만족감은 높습니다.
제발 이대로 60대까지만 코딩하면서 살면 좋겠네요 ㅎㅎ
그래서 이바닥이 제대로된 경영자 보기가 힘든건가 싶기도 하네요..
일정 밀린다는 개발자를 수도없이 많이 봤지만 일찍 끝난다고 말해주는 개발자는 기억이 가물가물합니다.
프로젝트에는 상호 신뢰가 필요한데 SI해보면 그게 참 없더라구요.
일빨리 끝났다고 하면 옳다구나 하고 더얹으니까 그렇죠 ㅋㅋ
학습되니까 아무도 빨리끝내면 얘기를 안하는 겁니다
이게 빨리 앞당기면 뭔가 보상이 와야하는데 오히려 벌칙처럼 되어버리니...
착한 사람만 덤태기 쓰는일이 중소기업에선 비일비재 하죠
아무리 영업을 따와도 못쳐내면 도로묵이라 경영자도 안절부절하긴 하죠.
사람을 더 뽑자니 따박따박 일감이 나오는것도 아니고
각 쿼터마다 스케일이 다르니 참 어려운 문제긴 해요.
공장처럼 찍어내는게 아니라 사람이 하는 일이라 그런것 같아요.
고객사도 자금계획에 따라 운영할테고 일정이 있는데 마냥 맞춰달라 할 수도 없는 노릇이고
그러다 떠나가버리고..
유일하게 요구하던 사항이 있었습니다.
그 일정내에 해줄테니 자꾸 뭔가 중간에 동작하는 결과물을 보려고 하지 말아달라고 하는거죠.
(의견공유나 대략적의 화면흐름과 같은것들의 공유는 합니다. )
심지어 설계기간에 화면이 안나온다고 뭐라고 하면 정말 힘들더라구요.
개발이란건 보통 거의 일정의 70%이상은 제대로된 결과물이 안나옵니다.
나머지 막바지 30%에 대부분이 나온다고 보면 되죠. (적어도 저의 경우엔 그랬습니다.)
그런데 리니어하게 일자 흐름대로 결과물을 내놓으라고 하면.. 정말 이건 답없다고 볼수밖에요.
예전에 자꾸 제가 개발이 늦어서 일을 못한다고 하길래 2-3달만에 서비스하나를 만들었더니..
그후로 저는 빨리 오픈하자고 채근하는데 한달이상 못하고 있더군요.
그때 알았습니다. 다른파트에서 그냥 면피하려고 개발자 탓만 했구나....막상 빨리해놓으니 오히려
그쪽이 준비가 안되어있었던..
그래서 애자일 개발방식이 나온거라고 봐요
아무리 합리적인 사람이라도 비개발자는 화면이 나오기 전에는 아무 관점도 없어요
뭐래도 보여줘야 그때서야 아이디어랍시고 아무말이나 꺼내지...
그래서 차라리 화면을 먼저 보여주는게 난중에 딴소리 안할거능성이 높더라고요.