[번역] 개발자 생산성을 파괴하는 12 가지
통계보기 전용뷰어 보기
개발자 생산성을 파괴하는 12 가지
[원본]
많은 기사가 기술 리드 및 엔지니어링 관리자의 역할을 다룹니다. 우리가 자주 접하는 한 가지 공통적 인 주제는 팀의 생산성 을 향상시키는 방법 입니다. 그러나 생산성을 높이기 위해 에너지를 집중하기 전에 먼저 무엇이 파괴되는지 고려하고, 구축 할 수있는 기반을 마련해야합니다. 안타깝게도 Peopleware 가 거의 30 년 전에 출간 되었지만 일부 (부정적으로) 놀라운 방식으로 막대한 생산성 손실을 겪고있는 팀이 많이 있습니다!
프로그래머가 컴퓨터에 액세스하지 않고도 작업을 수행 할 것으로 기대하는 사람은 없지만 프로그래머가 자신의 마음에 들어 가지 않으면 작업을 완료 할 것으로 기대하는 회사가 많이 있습니다. 이것은 똑같이 비현실적입니다.
따라서 개발자가 "영역으로"들어가서 생산성을 발휘하지 못하게하는 12 가지 항목을 자세히 살펴 보겠습니다. 나는이 목록을 가장 영향력이 적은 것으로부터 우선 순위에 우선 순위를 두려고 노력할 것이다. 자유롭게 의견을 말하십시오!
이 모든 것이 투자 가치가 있는지 궁금하다면 개발자의 급여 만 고려하십시오. 심지어 생산성이 10 % 더 많습니다!
1) 방해 및 회의
인터럽트는 개발자를위한 최고의 생산성 킬러입니다. 개발자는 중단되기 바로 전에 어디로 쉽게 돌아갈 수 없습니다. 그들은 발달을 위해 사고 방식에 들어가야하고, 그때 그들이 중단 한 곳으로 천천히 되돌아 가야합니다. 이것은 쉽게 30 분 이상 걸릴 수 있습니다. 그리고 방해가 많을수록 좌절감이 적어지고 품질이 떨어지고 버그가 많아집니다.
"시작하기 위해 노력하는 동안 더 많은 시간을 여행하게됩니다. 시도 할 때마다 더 길어집니다. 내 아침을 방해로 채우는 경우 - 비생산적 일 때 놀랄 필요가 없습니다. "Reddit의 개발자
회의는 어떨까요? 회의와 중단 사이의 유일한 차이점은 회의가 계획된 중단이므로 더 악화된다는 것입니다. 개발자는 작업 중에 중단이 발생한다는 것을 알고 나면 작업을 진행할 수 없습니다. 따라서 한두 시간 안에 회의가 열리면 대부분의 엔지니어링 작업에 더 많은 시간이 걸리기 때문에 어떤 작업도 진행할 수 없습니다.
폴 그레이엄 (Paul Graham)이 썼 듯이 , "한 회의는 하루 종일 힘든 일을하기에는 너무 작은 두 조각으로 나누어 전체 오후를 날려 버릴 수 있습니다."
어떻게 피할 수 있습니까? 이 부분은 잘 문서화되어 있습니다. 너는 변명의 여지가 없다. 예를 들어 불필요한 중단을 피하기 위해 하루 중 가장 빨리 또는 점심 식사 직전에 짧은 지위 회의를 개최하십시오.
2) 마이크로 관리
여러 유형의 관리자 중에서 마이크로 관리자는 개발자의 생산성 측면에서 최악 일 수 있습니다. 물론 마이크로 관리자는 더 많은 회의와 계획되지 않은 중단을하는 경향이 있습니다. 그러나 그 뿐만이 아닙니다. 그들은 신뢰의 부족을 보여줍니다. 그렇게함으로써, 당신은 끊임없이 자신의 기술과 일을 끝내는 능력을 훼손하고 있다고 느낍니다. 개발자가 중단 사이에 가졌던 동기는 그 시점에서 사라졌습니다. 그 영향은 생산성을 뛰어 넘습니다. 마이크로 관리자는 개발자가 최소한 팀을 변경하거나 떠나야하는 첫 번째 이유 일 수 있습니다.
3) 모호함
모호성을 설명하는 데는 여러 가지 방법이 있습니다. 버그보고는 "고장 났어요, 고쳐주세요!"개발자가 작업하기에 충분한 정보가 없습니다. 그건 그렇고, 버그 리포트 템플릿을 가지고 있으면 도움이 될 것입니다.
또는 기능에 대한 명확하지 않은 사양이있는 경우 관리자는 관리자가 예상 된 동작을 자세히 설명하면 처음부터 다시 시작해야하기 전에 개발자가 자신에게 맞는 것을 구현하기 시작할 것입니다.
불명확 한 우선 순위도이 범주에 속합니다. 개발자가 올바른 작업을 수행하고 있는지 궁금해하는 시간을 너무 쉽게 피할 수 있습니다. 그리고 관리자가이 특정 작업 (우선 순위가 정의되지 않은 상태에서 작업 한 이유)을 묻는 의견을 얻은 경우 ... 글쎄, 당신은 그것을 얻습니다 - 많은 좌절감을 느낍니다 ...
4) 갈매기 관리
당신은 그것을 들어 본 적이 있습니까? 그것은 관리자가 작업에 완전히 관여하지 않을 때 발생하지만, ... 그들은 단지 모든 것을 다 뒤집어 쓰고 있습니다. "이것은 잘못되었습니다. 그리고 이것은, 그리고 이것은 나 빠지고 있습니다."등, 다시 날기 전에. 나는 이미지를 좋아한다는 것을 인정해야하지만 불행히도, 이것이 우리가 원하는 것보다 더 자주 발생합니다. 이 동작은 개발자들에게 심히 불만 스럽습니다. 앞으로 몇 시간 내에 그들은 구역으로 돌아올 수 없으며 때로는 며칠도 못 돌아갈 수 있습니다.
5) 신용 욕심
지난 주에했던 일에 대해 모든 공로를 인정한 관리자 또는 다른 개발자가 있습니까? 개발자는 무엇보다 능력을 중요시합니다. 다른 사람의 신용을 얻는 것은 다른 사람의 능력을 자신에게 가져 가서 그 사람이나 그 사람에게서 제거하는 것입니다. 내리스트에서 꽤 높다. 너무 긴장감을 불러 일으켜 꽤 오랜 기간 동안 전체 개발자의 생산성을 저하시킨다.
6) 환경 - 소음, 모션, 작업 공간 디자인 ...
이는 프로그래머가 아닌 사람들에게는 이상하게 보일 수 있지만 개발자가 일하는 환경은 자신의 활동에 중요한 영향을 미칩니다. 예를 들어, 약간의 백색 잡음 (큰 소리의 AC)을 가지고 있으면, 들리는 자동차와 트럭은 그들이 더 잘 집중하는 것을 돕는다. 그래서 우리 중 많은 사람들이 헤드셋을 착용합니다! 나는 방금 RainyMood를 발견 했다 - 정말로 굉장한 �!
마찬가지로 작업 공간이 가능한 한 많은 동작을하도록 설계된 경우에는 초점을 맞추는 데 도움이되지 않습니다. 또는 데스크톱 컴퓨터 화면이 관리자에게 매우 잘 보이는 방향으로 배치되도록하는 것이 좋습니다. 그러면 약간의 추가 스트레스가 발생하고 중단 될 기회가 더 많이 생깁니다.
7) 범위 소름
프로젝트 관리에서 범위 크리프 (포커스 크립, 요구 사항 크립, 피처 크립 및 때로는 싱크대 증후군이라고도 함)는 프로젝트 범위의 통제되지 않은 변경을 나타냅니다. 이는 프로젝트의 범위가 올바르게 정의, 문서화 또는 제어되지 않은 경우 발생할 수 있습니다.
Scope creep은 상대적으로 간단한 요청을 끔찍하고 복잡하고 시간 소모적 인 괴물로 바꿉니다! 그리고 대부분의 경우 개발 중에 발생합니다! 예를 들어, 간단한 기능 :
버전 1 (구현 전) : 기능은 "위치지도 표시"
버전 2 (버전 1이 거의 완료되었을 때) : 기능이 "위치의 3D지도 표시"
버전 3으로 변경되었습니다. (버전 2가 거의 완료되면) : 다시 "사용자가 날 수있는 위치의 3D지도 표시"로 변경된 기능
8) 제품 정의 프로세스
그래서 이것은 언뜻 보면 이상하게 보일 수도 있지만 실제로는 이해하기 쉽습니다. 제품 팀이 해당 기능의 관심을 (고객 의견 또는 다른 방법을 통해) 검증하지 않고 팀의 우선 순위를 정의하고 개발자가 대부분의 기능이 결국 사용되지 않는다는 것을 알게되면 개발자는 자신이하는 일이 쓸모없고 그들의 동기를 잃을 것이다. 우리 모두는 영향력을 느끼기를 원하며 개발자에게는 더욱 중요 할 수 있습니다!
9) 기술 채무에 대한 고려 부족
기술적 부채는 최고의 솔루션을 구현하지 않거나 소프트웨어를 더 빨리 출시하기 위해 최선의 코드를 작성하지 않기로 한 신중한 결정입니다. 일부 기술적 부채를 취하는 것은 불가피하며 단기적으로 소프트웨어 개발 속도를 높일 수 있습니다. 그러나 장기적으로 시스템 복잡성에 기여하여 개발자의 작업 속도를 저하시킵니다. 프로그래머가 아닌 사람들은 종종 생산성 손실을 과소 평가하고 항상 앞으로 나아갈 유혹에 빠지며, 이것이 문제가됩니다.
그러나 리팩토링이 우선 순위의 일부가 아니라면 생산성에 영향을 줄뿐만 아니라 제품 품질에 영향을 미칠 것입니다.
10) 도구 다중성 및 하드웨어
개발자는 매일 여러 가지 도구를 사용하여 코드를 프로그래밍하고 밀어 넣고 병합합니다. 자동화가 많을수록 좋습니다. "고대"도구를 사용하면 생산성에 영향을줍니다. 마찬가지로 큰 화면을 가지고있을 때 랩톱 만 있으면 영향을 미칠 수 있습니다. 하드웨어 비용과 개발자의 급여를 감안할 때 5 %의 생산성 향상 효과 만 있으면 그만한 가치가 있습니다! 개발자 팀이 선호하는 도구와 하드웨어를 제공하십시오 (개별적으로 하드웨어는 있지만 그룹 도구로 제공).
11) "방법"문서
코드를 작성하는 방법을 배울 때 우리는 일찍 그리고 자주 언급해야한다고 들었습니다. 너무 적은 의견을 갖는 것보다 너무 많은 의견을 갖는 것이 더 좋은 아이디어입니다. 불행하게도 많은 프로그래머가 이것을 잘못 해석하여 모든 코드 라인에 주석을 달아야한다는 것을 의미합니다. 그래서 우리는 종종 다음과 같은 코드를 봅니다 (Jeff Atwood의 "Comments Without Coding" 게시물 ).
r = n / 2; // r을 n을 2로 나눈 값으로 설정합니다.
// (r - (n / r))> t) {r = 0.5 * (r + (n / r))} while 루프 동안 r - (n / r) // r을 r + (n / r)의 절반으로 설정합니다.
}
이 코드가 무엇을하는지 알고 있습니까? 나도 마찬가지야. 문제는 코드가 수행하는 작업을 설명하는 주석이 많지만 코드가 수행하는 이유를 설명하는 설명이 없습니다. 프로그램에 버그가있어이 코드를 발견하면 어디서부터 시작해야할지 모를 것입니다.
12) 불가능한 마감일
이 마지막 것은 관리자가 개발자에게 견적을 요구하는 경향과 관련이 있습니다. 그런 다음 가능한 한 많이 견적을 내린 다음 마술처럼 마감 시간으로 간주합니다. 관리자는 개발자 자신이 견적을 "결정"하기 때문에 마감일을 지키므로 마감일은 고위 경영진과 공유 할 수있을만큼 유효하다고 간주해야합니다.
당연히 개발자들은 마감 시간이 부당하고 임의로 엄격하다고 생각합니다. 이것은 긴장감과 집중력을 잃게 만듭니다.
이러한 모든 것들이 개발자에게 고유 한 것은 무엇입니까?
12 가지를 모두 살펴 본다면, 실제로는 대부분의 다른 프로젝트 기반 작업에 공통적입니다. 개발자가 각자의 임무를 수행하는 데 중점을 두어야하기 때문에 이들 각각의 영향이 개발자에게 더욱 중요하다는 것입니다.
회사에서 위에서 언급 한 몇 가지 사항을 알고있는 경우 개발자에게 문제를 제기하는 것이 흥미로울 수 있습니다. 그들과 이야기하십시오; 이것이 문제인지 그리고 어떻게 해결할 수 있는지 알아보십시오. 그들이 뭐라 할지라도 가장 중요한 것은 그들의 피드백과 통찰력을 신뢰하는 것입니다. 오늘날의 기술은 30 년 전과 매우 다르지만 그 교훈은 여전히 같습니다. 팀 생산성을 고려할 때 인간의 요소를 무시할 수 없습니다. 팀과 함께 프로세스, 환경 및 작업 습관을 반복하고 최고의 생산성과 영향력을 갖는 방법을 안내 할 수 있도록하십시오.
