PL업무 / sw 개발 / 프로젝트 리더 / 관리자 / 관리
소프트웨어 팀장(Leader) 이 하지 말아야 하는 행위
‘팀 플레이’라는 안티패턴
- 팀에 인원이 너무 많은 경우, 개발자들이 서로 반목하면서 동일한 코드를 업데이트하려 경쟁하게 된다.
--> 검토할 코드가 많아지고, 그 누구도 코드를 일일이 검토해 통합하기 원하지 않게 된다.
- 마이크로서비스 아키텍처를 구성하는 것은 개발자에게 숨쉴 공간을 준다. 독립적으로 자신이 맡은 코드 작업을 할 수 있다.
‘분할 관리’라는 안티패턴
- 더 중앙에서 통제를 하고, 더 중앙에서 테스트를 하는 것이 필요하다.
- 일부 개발자를 지정, 부분들이 가능한 원활하게 함께 작동할 수 있도록 통합을 지속적으로 모니터링하는 일을 맡긴다.
- 부분들이 함께 작동하도록 만드는 일은 부분들을 구현하는 것만큼 힘든 일이다.
- 개발자들을 동일한 방향으로 계속 유도하는 것 자체가 하나의 ‘일’이다.
‘비전을 따르라’는 안티패턴
- 모든 개발자가 이런 상상 후, 단 몇 줄의 코드로 모든 기능을 구현하는 ‘초능력’에 대해 상상한다.
- 계획 수립은 번거로운 일이다. 그러나 나중에 코드를 디버깅하는 것보다 빨리 할 수 있다. 때로는 다짜고짜 저지르기보다 그저 앉아 있는 게 나을 수 있다.
‘교과서대로’라는 안티패턴
- 스펙을 만드는 데 몇 달을 소비하고도, 모든 것이 거의 마무리되었을 때 새로운 각도나 문제를 발견하게 된다.
- 유능한 관리자는 방법론을 선택한 후, 이 방법론이 실패할 가능성에 대비한다.
- 어느 누구도 항상 성공할 수는 없다. 대비가 중요하다.
‘프로세스 신뢰’라는 안티패턴
- 창의성을 방해할까 두려워 세부 사항을 계속 추적하지 않으면 악성 결과가 초래될 수 있다.
- 책임자는 항상 지연을 초래하는 많은 장벽, 장애물, 문제에 직면하게 된다. 책임자의 도전과제는 효율적으로 일어나는 일을 모니터링하고, 현명한 결정을 내리기에 충분한 정도로 세부사항을 계속 추적하는 방법을 찾는 것이다.
- 소프트웨어 개발 매트릭스가 부정확할 수 있다.
- 그러나 지나치게 많은 기대를 하지 않으면, 누가 무슨 일을 하고 있는지 추적할 수 있도록 도와준다.
‘측정하지 않은 것은 관리할 수 없음’이라는 안티패턴
- 적합한 점수를 파악하는 것은 애초 문제를 해결하는 것만큼 어렵다.
- 정말 지독한 팀은 더 정확한 평가를 위해 서로를 경쟁시키기도 한다. 이는 팀웍이나 협업에 도움이 되지 않는다.
- 가장 큰 위험은 개발자들이 힘든 일이나 예측하기 어려운 일을 피하게 되는 것이다.
- 분기말, 연말에 충분한 점수를 얻게 되지 못할까 우려하는 행태가 번기는 것이다.
- 해결책은 이런 매트릭스를 지나치게 신뢰하지 않는 것이다. 점수를 추적 관리할 수는 있다. 그러나 이런 점수를 절대적인 척도로 간주해서는 안 된다.
'어리석은 일관성은 편협한 사람들의 망상’이라는 안티패턴
- 코드에 어느 정도 일관성이 있을 때, 패턴과 시각적인 리듬의 예측성이 높을 때, 코드를 더 쉽게 판독할 수 있다.
- ESLint 등을 이용하자.
‘기준이 구원자’라는 안티패턴
- 실행 코드의 품질에 거의 영향을 주지 않는 기준을 강제하는 것은 좋지 않다.
- 필자생각: 코드의 일관성을 유지하는 것과의 균형을 잡는 것이 중요할 듯 하다.
- 스페이스의 위치 같은 것은 사람을 위한 것이다. 사람들이 지나치게 많은 것을 주장하지 않도록 만드는 데 목적이 있다.
- 기준을 사용하고 싶다면, 적용하기 쉽고, 실제 유의미한 세부 사항만 신경 쓰도록 단순하게 만들어야 한다
‘스택 단순화’라는 안티패턴
- 코드 기반의 ‘순정함’을 유지하면, 그 대가로 속도와 효율성을 잃게 된다.
- 사용자를 만족시킬 수 있다면, 코드 기반의 이탈을 어느 정도 용인하는 것이 합리적이다.
- 절충의 가치가 있는 때를 파악하는 것이 핵심이다.
‘개발자가 직접 도구를 선택’이라는 안티패턴
- 나중에 문제가 발생한다. 코트린(Kotlin)을 좋아하는 개발자가 팀을 떠나고, PHP를 좋아하는 사람이 코드를 물려 받으면 이를 해독할 수가 없다.
- 적합한 스킬을 가진 사람들로 팀을 구성해 유지하는 경우에도, 자바스크립트 개발자들은 스위프트(Swift)로 작성된 코드를 확인할 때 고생을 하게 된다.
- 지나치게 개방적으로 모든 것을 수용해서는 안 된다.
‘성공의 열쇠는 동기 부여’라는 안티패턴
- 동료가 한 장의 티켓을 여러 티켓으로 분리해야 한다고 주장하는 것을 보았다. 봉급에서 보상을 받기 위해서이다. 이 동료는 풀 리퀘스트, 지원 티켓, 애자일 매트릭스를 ‘조종’하는 데 있어 ‘달인’이었다.
- 필자생각: 소프트웨어 개발에 경영을 위한 측정을 하겠다는 생각은 어리석다. 왜냐면 그것은 개발자 마음대로 쪼개고 늘리고 할 수 있는데다, 복잡도는 높다. 그래서 룰을 만들어도 쉽게 룰을 피해갈 수 있으며, 완벽한 룰을 만들면 할 수록 개발은 유연성을 잃고, 제대로 된 개발을 할 수 없게 되기 때문이다.
- 개발자들에게 진짜 동기를 부여하는 것은 수수께끼 같은 난제이다.
- 개발자들은 흔히 자신만의 생각을 갖고 있으며, 누구보다 도구를 잘 이해한다.
- 우리가 할 수 있는 최선은 ‘파트너십’에 대한 의식을 불어넣고, 큰 그림을 이해하도록 만드는 것이다.
- 그런 후, 이들이 추상적인 목표를 여러 수 많은 깨끗한, 테스트가 완료된, 버그가 거의 없는 코드로 바꿔 놓도록 바래야 한다.
See Also
- 엔지니어링 관리자를 위한 조언
References
- SW 프로젝트를 산으로… 서툰 리더십 행태 11가지 - CIO Korea
댓글 없음:
댓글 쓰기