급한 일 빠르게 해봐야...

결론적으로 '능력 부족한 개발자'소리를 듣는 것이 대부분이다.

대부분 급하다고 일을 의뢰하거나 서비스 론칭을 위해서 급하게 요구하는 경우가 있다. 개발자의 선택은 매우 명쾌하다. 정해진 기간과 인원 숫자로 만들어야 하는 서비스가 특정한 시간 내에 동작하게 하는 방법은 동작시에 제약사항과 커버하지 못하는 품질 이슈를 만드는 것뿐이다.

말 그대로 기술적 부채를 만들어 낼 수밖에 없으며, 이 기술적 부채는 결론적으로 반복적인 유지보수 업무와 처리하지 못하는 기능들에 대한 하소연을 만들어 낸다.

슬프지만 그렇게 반복되는 과정에서 경영진은 해당 개발자를 신뢰하지 못하게 된다. 그리고, 그렇게 반복적인 유지보수 업무를 만든 것은 개발자의 능력 부족이라고 생각하게 되고, 이 관계는 보고서가 늘어나거나 주간회의시에 디테일하게 보고하라는 식의 결론으로 귀결된다.

물론, 이런 상황을 만든 '착한 개발자의 결정'이 문제이기는 하다.

대부분 경험이 풍부한 개발자들은 이런 과정들을 반복해 보았기 때문에 처음부터 거부하거나 거절하거나, 적정한 선에서 타협하는 방안들을 제시한다. 물론, 그 과정에서 무지한 경영진과 트러블이 발생하는 것도 다반사이다.

이 경우 중간관리자가 개입해서 타협하는 경우가 분명 있다.

단언컨대 해당 중간관리자는 둘 중 하나이다. 무지하거나 난파하려는 개발 조직을 재빠르게 떠날 사람이다.

소프트웨어 개발에서 '급한 일'이란 없다.

정해진 규칙과 기본에 충실하게 하고, 빠진 것 없는지 체크하고 디자인, 설계 후에 미래의 변화에 대해서 적절하게 해당 조직의 규모와 형태에 따라서 반영한 후에 '개발'하는 것이다.

지금 이상황에도...

'급한 일'이라면서 일을 가져다주는 경영진을 만나고 있을 슬픈 개발자들을 위해서...

끄적끄적...