내가, 경력 20년 넘으면서 일하는 방법...(2)
개발자 조직에서 최고 의사결정을 할 때에...
가장 중요한 것은 명확한 업무지시와 중요한 의사결정 과정에서 그 책임을 '담당자'에게 떠넘기지 말라는 것이다. 판단에 대한 책임도, 업무와 일에 대한 결과도 '기술 책임자'로써 책임을 다 하면 된다.
그리고, 기간이 늘어지건, 비용이 더 들어가던, 작업을 다시 해야 하건... 그 책임을 다하면 된다.
개발자들이 기술 책임자를 의논의 상대, 의사결정 과정에 있어서의 책임자로 인식하게 하라는 것이다.
시스템의 안전을 위해서 비용이 추가로 들어가고,
비용을 최소로 줄이기 위해서는 안전을 일부 포기해야 한다.
요구사항의 순서에 따라서 개발 순서가 달라야 하고,
최대 개발범위를 위해서 개발 조직을 운영할 수 없다.
언제나 적절한 수준의 기술 프로세스와 적절한 범위의 개발 조직이 운영되어야 한다.
버려야 할 코드들이거나 다시 만들어야 할 레거시에 대해서 명확하게 선언해야 한다.
비개발자인 경영조직과 경영자들에게도...
개발자 조직의 개발자들에게도 기술 책임자가 해야 하는 일은 그 어떤 것을 '결정'하는 것이다.
개발 조직을 모두 완벽하거나 완전한 사람들로만 구인할 수 없다는 것도 알아야 한다.
일부 부족하거나, 일부 기능적인 요소가 충분한 사람들의 유기적인 조직 구성을 효과적으로 해야 한다.
기존 조직원들의 장단점을 파악하고, 부족한 기능이나 롤을 가진 사람들을 찾아야 한다.
너무 프로세스를 만드는 것에 목표를 두지 않고, 각 동료들이 최대한 서로 의사소통이 가능한 방법을 찾아야 한다.
개발 조직이 조금 커지면 바로 만나게 되는 것은 BtoC, BtoB, 의사결정 과정의 거버넌스가 중첩되고 복합적으로 운용된다는 점이다. 이러한 과정들을 단일화된 의사결정체계나 프로세스로 제한을 가할 필요는 없다.
적당하게 각 팀이나 파트별로 유기적으로 운용될 수 있는 구성체계를 갖추면 된다.
개발과정에 있어서 정해진 답도 없고, 그 당시 최선의 선택만이 있을 뿐이다.
모든 동료들이 각자 최대한 자신들의 미션과 목표를 위해서 달려갈 수 있는 환경을 갖추어주고, 그들이 임무를 완수할 수 있도록 기다려주면 된다.
물론...
조직에 맞지 않는 사람이거나, 근태가 불성실하거나, 비즈니스 목표에 맞지 않는 자신만의 바퀴를 재발명하고 있는 사람들을 찾아내서 업무를 격리해야 한다.
보고가 부정확하거나, 말을 잘 못한다고 하지만, 실제 업무를 분석해 보면, 회사에서 필요한 일을 최대한 말없이 수행하는 사람들을 찾을 수 있다. 그들을 찾아내서 대우하고, 인정해주는 분위기를 만들어야 한다.
기술도 중요하고, 비즈니스의 속도도 중요하다.
그 경계선에서 적절한 균형을 찾는 사람이 기술 책임자가 해야 할 일이기도 하다.
개발자들이 추구하는 목표와 비즈니스의 방향성과 가장 일치하는 사람들로 만들어야 하고,
장기적인 목표와 단기적인 목표 사이에서 적절한 범위를 조정해 주어야 한다.
결국, 즐거운 개발은 비즈니스의 속도를 맞출 수 있게 되고.
개발자의 행복함은 소프트웨어의 품질로 다가온다.
생각해보면... 대부분 소프트웨어 개발은 그 개발 수준이 그렇게 정밀하지 않은 경우가 대부분이다.
우리는 로켓을 쏘아 올려서 화성을 보내거나,
정밀 타격하는 미사일이나, 비행기에 들어가는 소프트웨어만 만드는 것은 아니니까...
물론, 그렇게 정밀한 소프트웨어 품질이 요구되는 최소한의 기능을 만족하기 위한 동료와 후배를 꼭 찾아두는 것도 좋다. 그들은 말없이 소프트웨어의 품질을 커버할 것이니까.
그들을 조용하게 대우하고, 인정하자. 그러면, 서로 미소를 짓는 동료의 모습으로 표현될 테니까.
그것이...
경력 20년 차 개발자가 살아가는 삶이다.
