Hacker News 의견

• 개인 개발자의 생산성을 측정하는 것은 터무니없음. 코드 라인이나 스토리 포인트 측정은 생산성의 반대임. 개발자가 더 적은 코드로 더 많은 가치를 창출하는 것이 중요함

  • 비즈니스 결과를 측정하는 것이 중요하지만 특정 개발자에게 귀속시키기 어려움
  • 결국 주관적인 판단에 의존할 수밖에 없음을 인정하는 것이 더 나음

• Tim의 이름을 티켓에 붙여 문제를 해결하는 방법을 발견함. 팀원들이 기꺼이 도와줄 것임

  • 생산성 지표가 완전히 무가치한 것은 아님. 팀 내에서 PR과 Jira 티켓의 비율을 보면 팀 리더를 추측할 수 있음

• Tim이 팀에 남아있고 프로세스를 올바른 방향으로 이끌어 기쁨. 경청하는 관리자가 필요함

  • OKR로 인해 개발자들이 고립됨. 팀 기반이 아닌 개인 기반의 OKR은 문제를 초래함
  • 문제 해결에 시간이 오래 걸림. OKR 때문에 도움을 받을 수 없었음

• 한 프로그래머가 개인 작업 없이 모든 도움을 주는 모델은 이상함

  • Tim이 다른 사람들과 같이 스토리를 수행하고, 도움이 필요할 때 그룹에 요청하는 것이 더 건강한 상황임
  • 팀이 매우 불균형하다면 Tim은 멘토 역할을 해야 함

• Tim이 개인 작업을 하지 않는 것이 이상함. 팀 생산성을 극대화하려면 개인 기여와 팀 협업의 균형이 필요함

  • Tim이 너무 인내심이 많아 시간을 낭비했을 수 있음

• Tim이 팀에 기여하지 않으면 일을 시작하고 스토리를 전달하라고 할 것임. Tim이 다른 사람을 도와주는 것은 좋지만, 자신의 작업도 해야 함

• 모든 것이 그룹 활동이 될 필요는 없음. 평균적인 개발자가 Tim의 지속적인 도움 없이 기능을 제공할 수 없다면 팀에 문제가 있음

  • 소프트웨어 개발은 개인 작업과 그룹 작업 모두에 시간이 필요함

• 최고의 팀은 항상 Tim과 같은 사람이 있음. Tim의 도움은 다른 사람들에게 전파되어 팀 전체가 성장함

  • 개발자가 막히면 스스로 해결하려고 노력하고, 필요한 경우 도움을 요청함

• 스토리 포인트로 개발자 생산성을 측정하는 것은 좋지 않음. Zero라는 개발자는 스토리를 할당받지 않고 팀을 도왔음

  • 관리자는 Zero의 중요성을 이해하고 있었음. Zero가 없을 때 중요한 릴리스를 미루기도 했음

• 지원의 가치를 정량화하는 것은 어려움. 하지만 지원은 필수적임. 리더들이 올바르게 판단할 수 있도록 신뢰해야 함