[컴] 소프트웨어 팀장(Leader) 가 하지 말아야 하는 행위

PL업무 / sw 개발 / 프로젝트 리더

소프트웨어 팀장(Leader) 이 하지 말아야 하는 행위

‘팀 플레이’라는 안티패턴

  • 팀에 인원이 너무 많은 경우, 개발자들이 서로 반목하면서 동일한 코드를 업데이트하려 경쟁하게 된다.
    --> 검토할 코드가 많아지고, 그 누구도 코드를 일일이 검토해 통합하기 원하지 않게 된다.
  • 마이크로서비스 아키텍처를 구성하는 것은 개발자에게 숨쉴 공간을 준다. 독립적으로 자신이 맡은 코드 작업을 할 수 있다.

‘분할 관리’라는 안티패턴

  • 더 중앙에서 통제를 하고, 더 중앙에서 테스트를 하는 것이 필요하다.
  • 일부 개발자를 지정, 부분들이 가능한 원활하게 함께 작동할 수 있도록 통합을 지속적으로 모니터링하는 일을 맡긴다. 
  • 부분들이 함께 작동하도록 만드는 일은 부분들을 구현하는 것만큼 힘든 일이다. 
  • 개발자들을 동일한 방향으로 계속 유도하는 것 자체가 하나의 ‘일’이다.

‘비전을 따르라’는 안티패턴

  • 모든 개발자가 이런 상상 후, 단 몇 줄의 코드로 모든 기능을 구현하는 ‘초능력’에 대해 상상한다.
  • 계획 수립은 번거로운 일이다. 그러나 나중에 코드를 디버깅하는 것보다 빨리 할 수 있다. 때로는 다짜고짜 저지르기보다 그저 앉아 있는 게 나을 수 있다. 

‘교과서대로’라는 안티패턴

  • 스펙을 만드는 데 몇 달을 소비하고도, 모든 것이 거의 마무리되었을 때 새로운 각도나 문제를 발견하게 된다.
  • 유능한 관리자는 방법론을 선택한 후, 이 방법론이 실패할 가능성에 대비한다.
  • 어느 누구도 항상 성공할 수는 없다. 대비가 중요하다.  

‘프로세스 신뢰’라는 안티패턴

  • 창의성을 방해할까 두려워 세부 사항을 계속 추적하지 않으면 악성 결과가 초래될 수 있다.
  • 책임자는 항상 지연을 초래하는 많은 장벽, 장애물, 문제에 직면하게 된다. 책임자의 도전과제는 효율적으로 일어나는 일을 모니터링하고, 현명한 결정을 내리기에 충분한 정도로 세부사항을 계속 추적하는 방법을 찾는 것이다.
  • 소프트웨어 개발 매트릭스가 부정확할 수 있다.
  • 그러나 지나치게 많은 기대를 하지 않으면, 누가 무슨 일을 하고 있는지 추적할 수 있도록 도와준다.

‘측정하지 않은 것은 관리할 수 없음’이라는 안티패턴

  • 적합한 점수를 파악하는 것은 애초 문제를 해결하는 것만큼 어렵다.
  • 정말 지독한 팀은 더 정확한 평가를 위해 서로를 경쟁시키기도 한다. 이는 팀웍이나 협업에 도움이 되지 않는다.
  • 가장 큰 위험은 개발자들이 힘든 일이나 예측하기 어려운 일을 피하게 되는 것이다.
  • 분기말, 연말에 충분한 점수를 얻게 되지 못할까 우려하는 행태가 번기는 것이다.
  • 해결책은 이런 매트릭스를 지나치게 신뢰하지 않는 것이다. 점수를 추적 관리할 수는 있다. 그러나 이런 점수를 절대적인 척도로 간주해서는 안 된다.

'어리석은 일관성은 편협한 사람들의 망상’이라는 안티패턴

  • 코드에 어느 정도 일관성이 있을 때, 패턴과 시각적인 리듬의 예측성이 높을 때, 코드를 더 쉽게 판독할 수 있다.
  • ESLint 등을 이용하자.

‘기준이 구원자’라는 안티패턴

  • 실행 코드의 품질에 거의 영향을 주지 않는 기준을 강제하는 것은 좋지 않다. 
    • 필자생각: 코드의 일관성을 유지하는 것과의 균형을 잡는 것이 중요할 듯 하다.
  • 스페이스의 위치 같은 것은 사람을 위한 것이다. 사람들이 지나치게 많은 것을 주장하지 않도록 만드는 데 목적이 있다. 
  • 기준을 사용하고 싶다면, 적용하기 쉽고, 실제 유의미한 세부 사항만 신경 쓰도록 단순하게 만들어야 한다

‘스택 단순화’라는 안티패턴

  • 코드 기반의 ‘순정함’을 유지하면, 그 대가로 속도와 효율성을 잃게 된다. 
  • 사용자를 만족시킬 수 있다면, 코드 기반의 이탈을 어느 정도 용인하는 것이 합리적이다. 
  • 절충의 가치가 있는 때를 파악하는 것이 핵심이다.

‘개발자가 직접 도구를 선택’이라는 안티패턴

  • 나중에 문제가 발생한다. 코트린(Kotlin)을 좋아하는 개발자가 팀을 떠나고, PHP를 좋아하는 사람이 코드를 물려 받으면 이를 해독할 수가 없다.
  • 적합한 스킬을 가진 사람들로 팀을 구성해 유지하는 경우에도, 자바스크립트 개발자들은 스위프트(Swift)로 작성된 코드를 확인할 때 고생을 하게 된다.
  • 지나치게 개방적으로 모든 것을 수용해서는 안 된다.

‘성공의 열쇠는 동기 부여’라는 안티패턴

  • 동료가 한 장의 티켓을 여러 티켓으로 분리해야 한다고 주장하는 것을 보았다. 봉급에서 보상을 받기 위해서이다. 이 동료는 풀 리퀘스트, 지원 티켓, 애자일 매트릭스를 ‘조종’하는 데 있어 ‘달인’이었다.
    • 필자생각: 소프트웨어 개발에 경영을 위한 측정을 하겠다는 생각은 어리석다. 왜냐면 그것은 개발자 마음대로 쪼개고 늘리고 할 수 있는데다, 복잡도는 높다. 그래서 룰을 만들어도 쉽게 룰을 피해갈 수 있으며, 완벽한 룰을 만들면 할 수록 개발은 유연성을 잃고, 제대로 된 개발을 할 수 없게 되기 때문이다.
  • 개발자들에게 진짜 동기를 부여하는 것은 수수께끼 같은 난제이다. 
  • 개발자들은 흔히 자신만의 생각을 갖고 있으며, 누구보다 도구를 잘 이해한다. 
  • 우리가 할 수 있는 최선은 ‘파트너십’에 대한 의식을 불어넣고, 큰 그림을 이해하도록 만드는 것이다. 
  • 그런 후, 이들이 추상적인 목표를 여러 수 많은 깨끗한, 테스트가 완료된, 버그가 거의 없는 코드로 바꿔 놓도록 바래야 한다.

리더를 위한 3가지 팁[ref.2]

  1. 약점을 드러내라.
  2. 조직원을 일괄적으로 대하자.
  3. 사람들이 일을 하는 방식, 선호하는 업무, 이를 가장 효과적으로 처리하는 방법을 파악하고, 영향을 줘서 성과를 내도록 인도하자. 자신의 스타일을 강요하지 말자.
  4. 안정감과 소속감을 부여하자.
    • 직원들이 혼동하지 않도록 하는 것
    • 자신이 하겠다고 말한 일을 하는 것
    • ‘우리’ 같은 소속감을 느끼는 표현을 사용하는 것
    • 다른 사람들의 정체성을 배려한 문화적 겸양을 실천하는 것
    • 진심 어린 칭찬을 많이 하는 것
ref. 3 을 참고한다면, 적어도 서구권에서 리더는 좀 더 assertive(확신적인) 가 되어야 할 듯 하다.

References

  1. SW 프로젝트를 산으로… 서툰 리더십 행태 11가지 - CIO Korea
  2. 기고 | 리더와 관리자의 차이··· 3가지 팁 - CIO Korea, 2020.01.20
  3. The bamboo ceiling - Indian v Chinese bosses in America Inc | Business | The Economist, 2020-02-29





댓글 없음:

댓글 쓰기