제품개발 역량이 낮은 팀에서 공통적으로 하는 것?

 사업화 제품을 개발하는 팀의 역량 정도를 파악하는 여러 지표들이 있는데, 개인적으로 경험해 본 조직들 중 비슷한 역량을 갖는 팀이 공통적으로 하는 것이 있어서 신기했던 경험이 있습니다.

사업화 과제에서, 정말 긴급하고, 중요하게 다뤄지는 문제 중 하나는 "이슈(불량) 해결" 입니다. 일정이 미뤄지기도하고, 생산 라인이 멈추기도 하고, 고객에게서 항의 메일이 오기도 하고, 아예 사업이 부러지는 경우가 발생하기도 하죠.

그래서 사업화 제품을 개발하는 팀 중 몇몇 팀들은 자체 역량 강화를 위해 종종 또는 자주 "기술 세미나" 라는 것을 하는데요. 신기하게도 "XXX 불량 분석 방법", "XXX 불량 분석 노하우 공유" 이런 류의 기술 세미나를 하는 조직 들이 있습니다. 경험해보신 적 있으신가요? 이슈에 대한 포스트모텀과는 전혀 다른 성격의 세미나 입니다. 어떻게 하면 이 이슈/불량을 분석하는가에 대한 툴 사용법이랄지, 로그 확인 방법 등을 알려줍니다.

저도 이런 세미나를 해달라는 요청을 여러 차례 받아 본 적도 있었고요. 그 때마다 대체 이걸 왜 해야 하나요? 하고 투정+반항을 해보기도 했습니다만..😁

제 기준으로 봤을 때 해당 팀의 기술 역량이 낮은 상태, 즉 제품 코드/아키텍처를 이해하는 사람이 적을 수록 저런 류의 기술 세미나가 빈번하게 진행 되었고, 개발자들에게 저런 노하우를 공유하라는 지침이 많았던 것 같습니다.

우리가 보는 불량/이슈라는 것은 결국 우리가 만든 소프트웨어/하드웨어 시스템이 결합되어 동작하는 설계에서 그것을 구현해 내는 코드들 중 논리적 결함이 있는 경우인데요, 반대로 생각해보면 내 제품의 시스템 구조, 설계, 코드를 잘 알면 당연히 분석이 쉬워지는 것이죠. 모르는 만큼 분석을 할 수가 없는 것이구요. 너무 당연한가요? 🤷

이런 너무 당연한 사실이 있는데, 신기하게도 기술 역량이 아직 낮은 팀은, 제품의 설계나 코드에 대한 이해를 하기 위해 개발자들에게 시간을 주는 대신, 일정에 대한 압박 등이 크기 때문에 단기 처방으로 저런 류의 대증 요법 같은 세미나를 진행하곤 하죠. 그렇게 하면 적어도 known issue에 대해서는 어느 정도 분석이 되는 것 같거든요. 하지만 그렇게 시간을 써버린 만큼 본질적인 문제는 여전히 해결이 되지 않기 때문에 또 다른 크리티컬한 문제가 발생하면 고난의 길을 걷게 됩니다.

거기에 더 문제를 어렵게 만드는 것은, 해당 문제의 중요도가 올라가게 되면 감놔라 배놔라하는 사람들이 늘어난다는 것입니다. 외부에서 "전문가"라는 사람들이 투입되는데 이 사람들이 실제 해당 제품의 전문가는 아니기 때문에, 시스템 구조나 코드의 배경을 이해할 리 없죠. 그래서 한 단면만을 보고 문제를 진단합니다. 그리고 이런 것들을 대응하기 위해 개발자들은 시간이 더 없어지죠.

결국 문제를 가장 빠르게, 정확하게 풀 수 있는 방법은 문제가 어떤 것인지 정확하게 알아야 하고, 속된 말로 하는 "땜빵"이 아니라 제대로 풀어내어야만 합니다. 기술 역량에 문제가 있으면 그 제품을 완성하는데 필요한 기술 역량을 올려야지 않을까 하고 생각했었습니다. 그 역량을 못 올리니까 대체제만 찾아서 진행한다? 흠 🫢

시간이 지나면서 점차적으로 발전해 나가는 조직과, 현상 유지만을 하는 조직, 그 마저도 못하는 조직은 확실히 다른 부분들이 있습니다. 😀

끝.