수석 개발자로 성공하려면 어떻게해야합니까?

특정 프로젝트의 수석 개발자가되었지만 큰 그림에 집중하고 프로젝트의 모든 부분을 다루는 데 어려움을 겪고 있습니다.

이 프로젝트를 관리 할 때 무엇을 명심해야합니까? 모든 것이 올바르게 처리되도록하려면 어떻게해야합니까?

나는 다른 개발자들이 선임 또는 리드로 전환 하면서이 여행을 보았습니다. 다음은 다른 사람들에게 제안한 내용입니다.

• 프로젝트의 목표가 무엇인지 이해하십시오.

종종 프로젝트에 적용 된 모든 기능에 관한 것이 아닙니다. 비즈니스 요구를 해결하는 핵심 기능 세트에 관한 것입니다. 이것이 기본 목표이므로 항상 명심하십시오.

• 작업에 필요한 사항을 분류합니다. 그들 사이의 종속성을 이해하십시오.

프로젝트를 세분화하는 것은 매우 간단합니다. 프로젝트 초반에 최대한 분해하십시오. 부품에 대해 광택을 내야하는 경우 수행해야 할 사항을 이해할 때까지 부품이 위험에 노출된다는 것을 이해하십시오.

• 프로젝트의 미결 질문이나 모호한 점을 이해하십시오.

처음부터 모든 모호성을 해결할 수는 없습니다 (시도해야 함). 관리자와 프로젝트 이해 관계자가 자신이 무엇이며 프로젝트에 어떤 위험이 있는지 이해해야합니다.

• 비즈니스는 놀라움을 싫어합니다.

모든 사람이 프로젝트의 상태를 (이상적으로 매일, 매주 작동) 알도록하십시오. 그리고 상태에 따라 수행 된 작업, 남은 작업, 열린 질문, 문제 등을 의미합니다. 프로젝트 완료에 영향을 줄 수있는 모든 사항을보고해야합니다.

• 매일 큰 그림을 살펴보십시오.

매일 한 시간 동안 큰 그림을 살펴 봐야합니다. 스스로에게 질문하십시오. 완료된 것은 무엇입니까? 해야 할 일은 무엇입니까? 공개 질문은 무엇입니까? 목표는 무엇입니까? 그들이 요청할 때마다 누군가에게 프로젝트의 자세한 상태를 알려줄 수 있어야합니다.

내가 여러분에게 줄 첫 번째 조언은 팀을 관리하는 것이 자신의 프로그래밍 작업을 수행하는 것보다 더 중요하다는 사실을 받아들이는 것입니다. 즉, 도움이 필요한 3 명의 주니어가있는 경우, 개발 과정에서 벗어나는 방법에 대해 우는 것이 아닙니다. 자신의 개발 작업에 너무 중점을 둔 경우, 종종 리더가되어 진행의 장애물이됩니다.

또한 위임하는 법을 배워야합니다. 한 시간 안에 쉽게 할 수있을 때 누군가에게 작업을 제공하기가 어렵고 하루 동안 flo 치게 될 것입니다. 그러나 작업을 수행하지 않으면 진행되지 않으며 팀이 게임을하는 동안 초과 근무를합니다.

또한 다른 사람의 코드를 수정하지 마십시오. 그들에게 무엇이 잘못되었는지 (그리고 왜) 말하고 고치도록하십시오. 또는 더 좋아지지 않기 때문에 모든 것을 고쳐야하는주기에 빠질 것입니다. 그들이 그것을 고칠 수 없다면, 그들이 팀을 유지해야하는지 고려하십시오. 약한 팀원은 자신이하는 모든 것을 고치기 때문에 머 무르지 마십시오.

리드로서, 당신은 나쁜 사람이되어 그들에게 불쾌한 소식을주게됩니다. 그것은 직업도 마찬가지입니다. 즉, 성능 저하 평가를 수행해야합니다. 마감 기한이 이동했거나 요구 사항이 변경되었음을 알려야합니다. 진전이없는 게으른 사람을 밀어야합니다. 마감 시한을 지키지 않을 때 상사에게 말해야하며 왜, 무엇을하고 있는지에 대해 설명해야합니다. 리드가되는 것은 좋아하는 것이 아니라 효과적입니다. 당신의 임무는 친구를 사귀지 말고 소프트웨어를 집 밖으로 내보내는 것입니다. 의사 소통이 핵심이며 나쁜 소식을 피하면 상황이 악화됩니다. 고객은 출시 날짜가 지날 때보 다 출시 전 한 달에 3 주가 더 늘어난다는 말을 처리 할 가능성이 훨씬 높으며, 3 주가 더 필요하다고 말합니다.

비공식 점검표는 다음과 같습니다. 그것은 매우 비공식적입니다 ... 나는 매일 모든 일을하지는 않지만 매주이 모든 것들을 치지 않으면 조금 걱정이되며 매달 매달 치지 않으면 당황해야합니다. 그리고 마일리지는 회사 / 팀 문화, 개인 스타일 및 프로젝트 유형에 따라 완전히 다릅니다.

• 팀과 개별적으로 대화 - 팀의 모든 사람이 유용한 작업을 수행하고 있습니까? 제품 및 현재 릴리스의 전반적인 목표가 무엇인지 알고 있습니까? 그들은 당신이 어떻게 돈을 버는 지 그리고 당신의 사업의 주요 추력이 무엇인지 알고 있습니까? 그들은 현재의 작업이 그 모든 것에 어떻게 부합되는지 알고 있습니까?

• 집단적으로 팀과 대화하십시오 -주요 뉴스와 함께 모여 그룹을 구성하여 귀하와 함께 또는없이 커뮤니케이션이 이루어 지도록하십시오. 소규모 팀으로서 이것은 아마도 그룹 전략 세션 일 것입니다. 팀이 커질수록 주요 요점을 안내해야하는 경우가되며 필연적으로 그들과 대화하는 시나리오가 될 것입니다. 잘못이 아닙니다 . 모든 사람 이 공개 정보를 모든 사람에게 말하는 것을 듣는 것이 매우 중요한 경우가 있습니다 . 따라서 모든 사람이 정보를 보편적으로 제공한다는 것을 알고 있습니다. 그러나 "당신-모두-"회의는 당신이 더 많은 가이드 인 그룹 전략 회의와는 매우 다릅니다.

• 팀의 작업을 샘플링하십시오 -모든 사람의 작업에 대한 약간의 설문 조사를 받으십시오. 코드를 읽고, 기능을 실행하고, 테스트 사례를 시도하십시오. 모든 사람의 작업을 100 % 목표로 삼지 말고 모든 사람에게서 약간의 표본을 추출해보십시오. 그들에게 피드백을주고 팀 전체에 걸쳐 강점과 약점 영역을 정리하십시오.

• 경영진에게 조기에 자주 확인하십시오 -이것은 갈색 코가 아니며, 계속 반복됩니다. 경영진이 무엇을 요구하고 경영진이 무엇을 생각하는지 모른다면 어떻게 팀이 기대치를 충족시킬 수 있습니까? 당신은 당신의 상사와 정말 좋은 리포 어가 필요하고 당신은 사람들이 당신의 팀에있는 방식으로 그의 팀에 있어야합니다. 사소한 일에 대해 상사와 효과적으로 의사 소통 할 수 있으면 위기가 닥쳤을 때 도움을 받고 명확하게 이해할 수 있다는 자신감이 생깁니다. 또한 큰 사진 블라인더가 어디에 있는지 확인하는 것이 좋습니다.

• 팀 리소스를 정기적으로 검토 합니다. 이전에 사용 가능한 리소스를 사용할 수 없게되면 사람들이 흠집을 낼 수 있지만 알려지지 않은 문제를 검토합니다. 당신의 초크 포인트는 어디에 있습니까? 유용한 새로운 도구가 있습니까? 대부분의 팀에는 내가 가장 최신의 가제트를 항상 사용하는 Tool Hunter라고 생각하는 사람이 있습니다. Tool Hunter와 GuyWhoHatesEverythingNew 간의 대화 균형을 조정하여 진화의 다음 단계를 찾으십시오. 도구에는 SW, HW, 물리적 공간, 학습 리소스 등 모든 것이 포함됩니다.

• 지원팀을 알고 연락하십시오. 모든 회사는 다르지만 품질 관리, 문서 작성, 법률, 시설, 재무 및 비즈니스에 고유 한 기타 지원 그룹을 담당하는 직원을 알고 있습니다. 그들은 내가 생각할 수있는 가장 큰 그림 트리거입니다. 왜냐하면 그들은 세상이 당신과 완전히 다르기 때문입니다.

• 경쟁사를 파악하십시오 -매주 적어도 몇 시간은 제품을 사용하지 않는 경우 제품으로 해결되는 문제를 해결하는 방법을 알아냅니다. 단일 회사가 아닐 수도 있지만 다른 솔루션에서 제공하지 않는 것은 무엇입니까?

• 비용 및 일정 검토-팀이 현재 마감일을 의미 할 가능성은 얼마나됩니까? 다음 마감일은 어떻습니까? 비용의 연소 속도는 얼마입니까? 다가오는 큰 구매는 아직 지불하지 않았습니까? 예산이 얼마 남았습니까? 세부 사항은 재무 추적 방식에 따라 다르지만 매우 비공식적 인 회사 일지라도 남은 일 / 주 / 월 예산과 현재 제품의 마감 기한을 모두 알고 있어야합니다. 어딘가에 누군가 "어떻게이 일을해야합니까?" "다음 달 / 분기 / 연도에 지불 할 여유가 있습니까?" 해당 번호를 알고 다음 단계에서 입력해야합니다. 다음 주에 누군가가 들어 와서 물었다면 지금 설명 할 수있는 명확한 계획이 필요합니다. 다음 달에 좋은 계획이 필요합니다. 현실이 닥쳤을 때 2-3 곳에서만 바뀌게됩니다. 분기에 대한 스케치 계획과 해당 연도의 헤드 요지에서 일반이 필요합니다. 과거에는 거대한 프로젝트에서도 숫자는 숫자 일뿐입니다. 그들의 말에 귀를 기울이십시오. 그러나 아무도 피에 서명하지 않았 음을 깨달으십시오.

그것은 내 머리 목록의 상단에 있습니다. 나는 일반적으로 "놀람"에 의해 머리를 뒤집어 놓을 때 그것을 추가합니다. ).

또한 Dread Context Switch를 준비하십시오. 방금 관리를 시작한 경우 소규모 팀이 있고 관리 담당자가 팀을 관리하고 개별 기고자 작업을 수행하는 데 시간을 보내는 것이 좋을 것이라고 생각했을 것입니다. 이 작업을 수행 할 수 있지만 둘 사이의 컨텍스트 전환은 거칠습니다. 그것을 계획하십시오. (점심 전과 후와 같이) 전환 시간을 차단하고 연습이 부족한 기술을 알고 처음 몇 번은 자신을 끌어다 놓아야한다는 사실을 깨달으십시오. 실제로 어디든 가려면 최소 2 시간이 필요합니다.

상황에 맞는 스위치는 양방향으로 작동합니다. 경영진은 실무를 수행하고 그 반대도 마찬가지입니다. 그러나 당신이 당신의 힘의 관점과 연습에서 불편 함과 덜 연습의 장소로 갈 때 당신은 고통을 더 느끼고 후퇴하는 자극은 강합니다. 그 사진을 알고 싸우고 큰 그림에서 튀어 나오면 모든 것을 더 잘 받아 들일 수 있습니다.

이 책 읽기 : Herding Cats : 프로그래머를 이끄는 프로그래머를위한 입문서

_{얼마 전에 나는이 책을 상사에게 선물했고 그는 그것을 좋아했다. 내가 그것을 읽을 때, 그는 그가 무엇을 말하는지 알고있는 것 같았습니다. 그리고 이것은 그렇습니다. 저자는 자신의 경험에 대해 이야기합니다. 관리자의 "단순한 진실"의 모음이 아닙니다. 이들은 이전 프로그래머의 말입니다. 그리고 그것은 HIS 경험 이었다는 것을 이해해야하지만, 당신의 경험은 다를 수 있습니다. 따라서 어떤 점에서는 비판적으로 보일 것입니다. "관리자는 더 이상 프로그래머가 될 수 없습니다-중요합니다."}

최근에 개발하지 않은 제품에 대해 소규모 회사의 기술 리더십을 인수했을 때, 사물 관리에 매우 도움이되는 것은 제품의 작동을 오이로 기록한 내부 기능을 평범한 영어로 문서화하는 것이 었습니다. 객체 모델에 대한 설명을 작성하고 다양한 컨트롤러를 통해 흐릅니다. 내가 찾은 것은 A) 제품이 약간 혼란 스럽다는 것입니다. :) 그리고 B) 앱이 어떻게 작동했는지 훨씬 더 빨리 배웠으므로 문제가 무엇이고 리팩토링이 필요한지에 대한 지능적인 대화를 할 수 있었으며, 또는 주어진 기능을 구현하는 데 필요한 것.

그림은 Visio와 같은 제품을 엉망으로 만들지 않습니다. 저는 크레용과 백지를 사용합니다 (실제로 저는 집에서 일하고 종종 2 살짜리와 함께 일합니다).