평범한 개발자가 팀을 해치고 있음을 경영진에게 보여주는 방법 [닫힘]

저는 소규모 회사의 개발자 팀을 "관리"하는 불안정한 위치에 있습니다. 나는 일을 할당하고 그들의 성과에 대한 피드백을 제공하지만 실제로 개인을 징계 할 의지가 없기 때문에 "관리"라고 말합니다.

내 팀 중 일부는 무엇을해야할지 모르고, 스스로 작업 할 수없고, 엄청난 양의 손을 필요로하며, 그대로두면 일반적으로 프로젝트에 큰 혼란을 안겨줍니다. 실패가 발생하면 나는 프로젝트를 구제하고 결승선을 가로 질러 밀어 내야합니다 (때로는 절뚝 거림).

이러한 개발자는 프로그래밍 개념에 대한 기술이 부족할뿐만 아니라 일반적으로 코드 문제에 대한 솔루션을 공식화하는 능력이 부족합니다. 루프 작성과 같은 간단한 작업은 문제에 대한 솔루션을 설계하고 구현하는 것은 물론 어렵습니다.

우리는 페어 프로그래밍, 수업 비용 제공, 책 구입, 근무 시간 동안 훈련에 시간 할당, 심지어 팀 훈련에 하루 종일 소요하는 것을 시도했습니다.

다른 선임 개발자와 나는 무엇을해야할지 모르겠지만, 우리의 생산성은 이러한 개인을 매일 처리해야하는 상황에서 제한을 받고 있습니다. 경영진은 우리가 그들에게 일을하도록 강요하고 있으며 그들의 주요 불만은 일이 얼마나 빨리 완료되지 않는지입니다.

우리 경영진 중 누구도 저와 다른 선임 개발자 외에 다른 개발자와 직접 일하지 않습니다. 관리는 비 기술적이며 모든 개발자가 동등하게 생성되며 더 빨리 완료하려면 이러한 프로젝트에 더 많은 사람이 필요하다고 믿습니다.

나는 이미 "신화의 남자의 달"과 "코드 완성"의 섹션이 포함 된 문서를 준비 중이며, 우리를 정말로 방해하는 것은 개발주기를 통해 평범한 사람들을 끌어 야한다는 통계와 함께 설명하기 위해 경영진에게 보낼 것입니다.

다른 어떤 리소스가 있습니까? 책, 기사, 일반적인 조언은 무엇이든지 도움이 될 것입니다.

문제가 기술이나 능력 부족, 프로그래머의 태도 문제 또는 좋은 직업 윤리를 장려하지 않는 기업 문화에서 비롯된 것입니까?

기술이라면 가르 칠 수없는 것이 있다는 것을 이미 알고 있습니다. 회사가 기꺼이 (그렇다고 생각되는 것 같고) 개선을 보여줄 수 있다면 교육을 늘리고 어떤 개발자가 상황에 맞는지 확인합니다. 당신이 아닌 사람들은 놓아 주어야합니다. 기존 개발자 중 일부를 내 보낸다는 사실을 알 때까지 추가 개발자를 고용하지 않을 것입니다.

프로그래머의 게으름이나 기타 태도 문제인 경우, 징계 조치를 뒷받침하도록 경영진을 설득해야합니다. Scott Vercuski가 설명하는대로 모든 문제를 문서화하십시오 . 상황에 맞출 수없는 프로그래머를 점차 쫓아 내십시오. 나머지 프로그래머에게 좋은 프로그래밍 기술과 모범 사례를 배워야한다는 것을 알리고이를 사용하십시오.

아직 수행하지 않은 경우 코드 검토를 받으십시오. 이를 올바르게 수행하는 방법을 설명하는 많은 리소스가 있습니다. 그들은 성냥을 외치는 것이 아니라 원하는 결과를 내기위한 전략 세션으로 간주되어야합니다. 코드에 대해 토론하십시오. 어떻게 개선 할 수 있습니까? 필요한 경우 리뷰에 새 코드를 작성하십시오.

경영진이 문제인 경우 문제라고 말하고 해결 방법을 보여줍니다. 그러나 당신은 설득력 있고 설득력 있어야합니다. 당신은 그들의 옹호자 여야합니다 . 문제에 대한 문서를 작성하십시오. 프레젠테이션을 만들어 보여주세요. 이익 동기에 호소하십시오.

마지막으로, 당신이 될 수있는 최고의 리더가 되십시오. 그들을 도와주세요. 작업을 수행 할 수 있도록 차단되지 않은 상태로 유지하십시오. 당신의 직업의 일부는 고위 경영진의 정치로부터 사람들을 보호하고 적절한 근무 환경을 유지하여 그들이 할 수있는 최선의 일을하는 데 집중할 수 있도록하는 것입니다. 즉, 사람들이 당신을 신뢰할 수 있는지 확인하십시오.

웃기는 아무도 당신에게 관리 기술이 부족할 수 있다고 말하지 않았습니다.

한 번은 1 년 반의 훈련 후에 루프를 코딩 할 수없는 사람들과 함께 일하게되었습니다. 나는 그들이 완전한 기능의 웹 프레임 워크를 사용할 수있을 때까지 그들을 훈련 시켰고 단 한 달 밖에 걸리지 않았다.

아마도 당신 은 훈련을 받아야 할 것입니다.

아마도 당신에 대한 보고서를 읽어야 할 것 입니다.

나는 당신을 공격하는 말이 아닙니다. 전혀. 과거에도 팀을 관리하지 못했기 때문에 문제를 잘 이해합니다.

그러나 공을 피하지 마십시오. 당신이 인생에서 얼마나 많은 모범 사례 문헌을 읽었는지에 상관없이 당신은 주로 당신의 팀에서 일어나는 일에 대한 책임이 있습니다.

그런 경우에는 불평을 멈추고 일을 시작하십시오. 코더가 아니라 관리자로서.

마지막으로 나는 틀릴 수 있습니다. 아마도 당신은 모든 것을 올바르게했을 것입니다. 이 경우 사임 할 수 있으며 그럴 수도 있습니다. 손을 움직여 비행기가 추락하는 것을 막으려는 것은 아무리 강하더라도 쓸모가 없습니다. 자신의 기술을 최대한 활용하여 기적을 수행 할 캐주얼 팀이 많이 있습니다.

문서는 당신의 가장 큰 자원입니다. 저의 옛 관리자는 "당신이 그것을 기록하지 않으면 일어나지 않았습니다."라고 말했습니다. 개발자가 작업을 완료하는 데 필요한 예상 시간을 서면으로 제공하고 해당 마감일을 지속적으로 (심각하게) 놓친 경우 문서화해야합니다.

어떤 종류의 시간 기록 시스템이 있습니까? 아니면 개발자가 시간을 기록합니까? 문제가 X 일이 걸릴 것이라고 말하고 X 일이 지나도 완료되지 않은 이유에 대해 질문 할 수 있습니다.

다시 말하면 ... 문서화가 핵심입니다. 만약 당신이 갑자기 누군가를 해고하고 소송 영역에 들어갈 수있는 이유에 대한 적절한 문서가 없다면. 문서가 많을수록 주니어 개발자가 부담을주지 않고 교체해야한다는 사실을 경영진에게 쉽게 알 수 있습니다.

행운을 빕니다.하지만 당신이 매우 힘든 길을 가고있는 것 같군요. 저는 그곳에 있었으며 그것은 오랜 시간 동안 진행된 과정입니다.

나는 이전에 이런 상황에 있었으며 확실히 공감할 수 있습니다. 제가 한 일은 저나 다른 선임 개발자가 2 일 이상 걸리지 않아야하는 소규모의 독립적 인 작업을 줄이는 것이 었습니다. 이 작업을 위해 솔루션 구현 방법, 데이터베이스 변경 사항 등을 식별하는 문서를 작성합니다. 그런 다음 개발자와 함께 앉아서 작업에 대한 높은 수준의 안내를 제공하고 할당합니다. 마감일은 1 주입니다. 주말에 그들의 작업과 비교할 수있는 확실한 무언가가 있습니다. 사양을 충족 했습니까? 그들은 어떻게 되었습니까? QA에서 발견 한 버그는 몇 개인가요? 어떤 식 으로든 빌드 또는 중단 프로세스를 중단 했습니까?

그것이 끝나면 그들이 실패했다고 가정하면, 그들이 그들의 의무를 어떻게 수행하지 않는지 설명하는 직접적이고 뾰족한 회의가 있습니다. 똑같은 일을 한두 번 더하고, 문서화하고 사슬을 통해 소통하는 한 그것들을 밀어 낼 수 있어야합니다. 가혹할 수도 있지만, 한 걸음 더 나아가 야 할 사람이 필요하고 적절한 사람이없는 것 같습니다.

또한 새로운 후보자 인터뷰에 참여하십시오.

내 조언은 다음과 같습니다.

당신이 관리자라면 책임에 따른 권리가 있어야합니다 . 이러한 권리에는 귀하가 속한 사람들의 징계가 포함됩니다. 고위 경영진이 귀하에게 그러한 권리를 부여하는 것을 거부하는 경우 해당 책임을지지 않습니다.

당신은 반드시 당신의 상사에게 그렇게 굳건히 대할 필요는 없지만, 그것이 반드시 일어나야하는 일의 본질입니다.

내 조언은 버그 추적기를 구현하고 작업을 할당하는 것입니다. 이것은 팀원의 생산성을 보여줄 것입니다. 처음 사용했을 때 팀을 구성하고 작업에 소요되는 시간을 측정했습니다. 내가 좋아하는 것 중 하나는 누군가가 작업을 할당했을 때 작업자에게 이메일을 보내고 작업을 확인하기 위해 다른 사람에게 사본을 보낸다는 사실이었습니다.

그건 그렇고 우리는 BugTracker.Net 을 사용했습니다 .

이 사람들이 처음에 어떻게 회사에 들어 갔는지 궁금합니다.

이러한 개발자는 프로그래밍 개념에 대한 기술이 부족할뿐만 아니라 일반적으로 코드 문제에 대한 솔루션을 공식화하는 능력이 부족합니다.

루프 작성과 같은 간단한 일이 어렵습니다 ...

회사는 직원 채용에 더 많은 시간과 노력을 투자해야합니다. 서두르면 낭비가됩니다.

이제 설명하는대로 그런 상황이 발생하면 보고서를 완성하고 (다른 사람들이 암시 한대로) 회사에 비용이 얼마나 드는지 간결하게 강조하고 최선을 다해 제출하고 기다립니다. 실제로 개인을 징계하는 데 의존합니다. ").

나는 프로그래머가 최고가되기를 원하도록 격려하는 것에 대해 얼마 전에 이것을 읽었다.

괴상한 무리

팀을 위해 "성과에 대한 피드백을 제공"한다고 언급하셨습니다.

그래서:

1. 팀과 함께 앉으십시오.
2. 그들에게이 페이지의 인쇄물을 건네고 당신이 그들에 대해 게시했다고 말하십시오.
3. 그들이 그것을 읽게하십시오.
4. 문제 해결을 도와달라고 요청하십시오.
5. 듣고 적으십시오.
6. 관리 팀에 가져 가십시오.

Peopleware는 목록에 포함되어야 할 또 다른 책입니다.

그러나이 책을 읽었을 때 회사의 아무도 권장 사항을 시도하고 싶어하지 않았기 때문에 실용적이지 않았습니다.

올바른 길을 가고있는 것 같습니다.

숫자를 어렵게 보여 주면 더 명확하게 볼 수 있습니다. 코딩 과제를 만들고 각 작업에 대해 여러 프로그래머에게 할당합니다. 스스로 테스트 할 수 있도록하십시오.

각각에 걸리는 시간, 코드가 생성하는 결함 수에 대한 세부 정보를 유지합니다.

고위 경영진에게 수치를 보여 주면 이제 확신을 갖게됩니다.

그 책

코드 완성 : Steve McConnell의 소프트웨어 구축에 대한 실용적인 핸드북

모범 사례를 배우는 데 도움이 될 수있는 좋은 소스입니다.

각 개발자에게 토론을 통해 이것을 읽고 배우도록 요구하는 것은 조금 도움이 될 수 있지만 가장 큰 것은 결과를 정량화하는 것입니다. 자신과 나머지 팀원의 급여를 받아 다른 사람의 실수를 고치는 데 드는 추가 시간을 계산하고 개발자가 처음부터 작업을 엉망으로 만드는 추가 비용을 계산합니다.

그런 다음 더 나은 개발자 팀이 ROI를 개선 할 수있는 방법을 보여줍니다.

보고서를 간결하게 유지하십시오. 장황하게 만들지 마십시오. 이것에 대해 그들이 얼마나 많은 돈을 잃고 있는지를 고려하십시오.

이제 코드 모듈의 복잡성을 측정하는 도구가 있습니다. PL / SQL 모듈에서 실행되지만 다른 환경에서 사용할 수있는 도구가 있다고 생각합니다.

전체적으로 다양한 섹션이 있지만 우리의 주요 모듈 중 여러 개가 'unestable'로 표시되었을 때 경영진에게 눈을 뜨게했습니다.

중복 기능을 강조하는 데 도움이되는 임팩트 분석 도구와 결합하여이 모든 것을 '기술 부채'평가로 패키지화했습니다.

모듈 단위로이를 제시 할 수 있었기 때문에 가해자를 식별하는 것이 쉬웠을 것입니다 (우리는보고했지만보고하지 않았습니다). 그렇기 때문에 조직은 손가락으로 가리키는 것보다 앞으로 나아갈 개선에 더 중점을 두었습니다.

(제외로, 이제 모든 코드가 검토를 위해 제출되고 함께 제공되는 코드 분석이 제공되어야합니다. 상황이 확실히 개선되고 있습니다.)

이것은 경영진과 좋은 견인력이 없다면 불가능합니다. 제 경험상 강요하려고하면 문제가 생길 수 있습니다.

그냥 아이디어.

SVN과 같은 소스 버전 제어 시스템을 사용한다고 가정합니다. 따라서 커밋을 검토하고 잘못된 커밋을 거부하는 정책을 만드십시오. 그런 다음 다른 관리자에게 거부 된 커밋에 대한 통계를 표시하여 평범한 개발자가 회사에 비용이 많이 든다는 것을 증명하십시오.

여기 당신을위한 또 다른 아이디어가 있습니다 : 그들이 깨지는 것을 고치지 마십시오. 재 작업을 위해 이메일에서 무엇이 잘못되었는지, 수정 방법 (일반 용어로만) 및 참조 관리를 알려주십시오. 이것이 최종 기한에 어떤 영향을 미치는지 경영진의 이해를 위해 기록해 두십시오. 이것은 당신을 위해 성능 문제에 대한 문서를 생성하고 그들 중 일부는 자신의 혼란을 고쳐야 할 때 더 이상 나빠질 수 있습니다.