영웅이 필요합니다: 프로젝트 관리자

이 기사는 마음에 앱 아이디어가 있고 은행에 약간의 현금이 있는 용감한 기업가를 위한 것입니다. 칵테일 냅킨에 낙서한 도표는 온 세상을 혼란에 빠뜨릴 것이고, 이미 돈을 가득 실은 덤프트럭이 당신의 집으로 파견됐다. 제 시간에 도착할 수 있도록 생산 주기를 원활하게 운영하기 위한 몇 가지 간단한 조언이 있습니다.

처음부터 프로젝트 관리자가 필요한 이유

Douglas Crockford는 "컴퓨터 프로그램은 인간이 만드는 가장 복잡한 것입니다. 그 이름을 들어본 적이 없을 수도 있지만 그는 프로그래머로 꽤 유명합니다. 그는 현재 PayPal의 수석 소프트웨어 설계자이며 이 기사의 범위를 벗어나는 모든 종류의 멋진 기술을 개척했습니다. 그는 대규모 프로젝트 작업에 대해 많은 것을 알고 있는 사람입니다.

나 자신은 13년 동안 프로그래밍을 해왔고 지금도 어떤 시점에서는 모든 프로젝트가 나를 미지의 영역으로 데려갑니다. 세상에는 너무나 많은 다양한 기술이 있으며, 새로운 기술이 놀라운 속도로 고안되어 현재 진행 중인 일을 완전히 파악하고 있다는 느낌이 들지 않습니다. 모든 프로젝트에는 고유한 과제가 있지만 몇 가지 상수가 있습니다.

• 프로젝트에는 시간 압박이 있습니다.
• 예산이 생각보다 적습니다.
• 나는 클라이언트가 원하는 것보다 더 비싸다.
• 나는 클라이언트가 원하는 만큼 완벽하게 듣지 않는다.
• 클라이언트는 내가 원하는 만큼 완벽하게 설명하지 않습니다.

분명히, 우리는 베이비시터가 필요합니다. 기본 규칙을 설정하고 모든 사람을 정직하게 유지하며 중요한 것을 잊지 않도록 누군가가 개입해야 합니다. 누군가는 모든 당사자 간의 의사 소통을 촉진해야 합니다.

이 누군가, 이 영웅이 프로젝트 관리자입니다.

Toptal은 내가 이 기사를 쓰기 시작할 때 프로젝트 관리자와 계약을 제안하지 않았지만 지금은 제안합니다. 시너지! 나는 다음 조언을 읽고 그들이 좋은 기회를 놓치고 있다는 것을 깨달았던 권력자들을 상상할 수 있습니다.

프로그래머가 좋은 프로젝트 관리자가 되지 못하는 이유

Project Management Institute의 인증을 제외하고 프로젝트 관리자가 테이블에 가져올 수 있는 가장 중요한 것은 경험입니다. 결과적으로 많은 프로그래머는 꽤 괜찮은 프로젝트 관리자가 될 것입니다. 우리는 누구보다 기술 프로젝트에 대한 더 많은 경험을 가지고 있으며 우리의 분석적 마인드는 정보를 목록화하고 구체적인 목표를 설정하는 데 능숙합니다.

선의는 당신이 우리에게 충분히 지불하고 있다는 것을 알고 있으므로 다른 사람의 시간도 당신에게 지불하도록 강요하기보다는 우리가 스스로를 관리 할 수 ​​​​있으리라 기대하는 것이 합리적으로 보입니다. 그렇죠?

글쎄, 우선, 당신은 우리에게 코드를 지불하고 있습니다.

우선순위를 정하거나 이번 주에 실제로 수행할 작업의 양에 대해 논쟁하기 위해 프로그래밍 멍한 상태에서 벗어나면 코드가 작성되지 않습니다. 그런 다음 "영역"으로 다시 돌아오는 데 최소 10분이 걸립니다. 특히 방금 나눈 대화로 인해 스트레스를 받은 경우 기능 우선 순위에 대해 논쟁하는 경우일 수 있습니다. 부후, 알아요. 하지만 이것은 값비싼 자원을 가장 효율적으로 사용하는 것에 관한 것입니다.

가장 중요한 것은 나무 때문에 숲을 볼 수 없다는 것입니다. 이 기사에서 다른 점을 빼지 않았다면 다음을 이해하십시오. 하루 종일 몇 가지 특정 버그를 보려고 하면 뇌가 더 큰 그림을 놓치게 됩니다.

내 두뇌는 그 버그를 수정하면 나에게 보상을 해주고, 나는 내가 훌륭한 일을 해냈고 지금 비디오 게임을 할 수 있다고 가정합니다. 누군가가 나에게 홈페이지가 여전히 고장났다는 사실을 상기시키면 나는 전체 프로젝트의 아주 작은 부분에 대한 매우 상세한 지식으로 내 두뇌를 채우고 나머지는 잊어버린 하루를 보냈기 때문에 완전히 놀랐습니다. 그것이 내 두뇌가 작동하는 방식이며 많은 다른 프로그래머가 비슷한 심리적 구성을 가지고 있습니다.

클라이언트가 좋은 프로젝트 관리자가 되지 못하는 이유

그렇다면 우리 프로그래머가 프로젝트 관리 작업을 완료하는 책임을 지기를 원하지 않는다면 그것은 클라이언트인 당신에게 맡겨야 합니다. 그것은 당신의 돈입니다. 그것은 당신의 비전입니다. 어쨌든 궁극적으로 모든 책임은 당신에게 있습니다.

그러나 당신은 또한 당신의 접시에 많은 것을 가지고 있습니다.

많은 고객들은 우리와 마찬가지로 하루 일과를 하며 살아가고 있으며, 일부는 일을 미루거나 건망증으로 고통받는 것으로 알려져 있습니다. 이것이 반드시 귀하를 설명하는 것은 아니지만, 특히 전체 프로젝트를 유지하는 중요한 작업으로 돌아갈 수 있도록 주변에 전문 기억인을 두는 아이디어를 기쁘게 생각하십시오.

비슷한 범위의 기술 프로젝트에서 작업했거나 감독했다면 실제로 프로젝트의 훌륭한 관리자가 될 수 있습니다. 그렇지 않은 경우 발생할 수 있는 문제를 예측할 수 있는 사람의 가치를 과소 평가하지 마십시오. 예상 시간은 항상 추정일 뿐이며 버그는 가장 적절한 시점에 발생하는 경향이 있습니다. 프로세스의 어떤 부분이 가장 많은 관심을 필요로 하거나 필요할 것 같은지 아는 사람을 주변에 두는 것은 시간제일 경우에만 다른 직원에게 비용을 지불할 가치가 있습니다.

품질 보증(QA)을 예로 들어 보겠습니다. 적절한 QA는 모든 프로젝트에서 원하는 것을 얻는 데 필수적이며 가치 있는 관심을 결코 얻지 못합니다. 훌륭한 프로젝트 관리자는 제한된 QA 리소스를 최대한 활용하고 프로그래머의 품질을 보증할 것입니다. 때로는 우리의 깊이에서 벗어나고 때로는 실수를 합니다. 프로그래머가 쉬는 날인지 아니면 실제로 프로젝트에 적합하지 않은지 판단하려면 감독 역할을 하는 기술적으로 능숙한 사람이 필요합니다. 인사 문제를 조기에 해결하는 것은 프로젝트의 삶과 죽음의 차이를 의미할 수 있습니다.

마지막으로 고객인 당신도 때때로 약간의 견제 및/또는 균형이 필요합니다. 우리 컴퓨터 프로그래머는 솔직한 성격으로 잘 알려져 있지 않기 때문에 쓰기가 어렵습니다. 간단히 말해서, 저는 클라이언트가 모든 것이 최우선 순위이며 완료하는 데 필요한 모든 것이 절대적으로 중요하다고 단호한 많은 프로젝트에서 작업했습니다. 이것이 절대적으로 사실이라는 데는 의심의 여지가 없지만 슬프게도 이 고객들은 하루에 몇 시간을 보낼 수 있는지 통제할 수 없었습니다. 그들은 그들이 원하거나 받을 만한 긍정적인 결과를 얻지 못했고, 클라이언트가 작업량을 평가하고 재치 있게, 그러나 확고하게 상황을 점검할 권한을 프로젝트 관리자에게 위임했다면 이러한 결과를 피할 수 있었을 것이라고 생각합니다. . 대부분의 기술 프로젝트에서 요구하는 냉정한 판단을 내리는 것은 어렵습니다. 당신의 아이디어와 돈이 온라인에 있고 컴퓨터는 당신이나 내가 울고 소리를 지르더라도 상관하지 않습니다. (여러 번 시도했기 때문에 이것이 사실임을 압니다.)

기술 프로젝트 관리를 위한 불완전한 기술 목록

이전의 1,000개 단어를 무시하고 직접 프로젝트를 관리하기로 결정했든, 아니면 누군가를 고용할 예정이지만 프로세스에 대해 더 알고 싶든, 이 목록이 도움이 될 것입니다. 나는 (공식적으로) 프로젝트 관리자가 된 적이 없으므로 주어진 프로젝트 관리자가 어떤 도구를 사용할지 말할 수는 없지만 이러한 모든 기술로 좋은 성공을 거두었습니다.

이정표

새 프로젝트를 시작할 때 대부분의 사람들은 프로젝트를 약간 더 관리하기 쉬운 덩어리로 나누는 것이 중요하다는 것을 직관적으로 알고 있습니다. 프로젝트를 시작할 때 이러한 이정표를 수립하기 위한 시작 회의를 갖는 것이 좋습니다. 그들에게 어떻게 다가갈지 막연한 것은 괜찮습니다. 가장 중요한 것은 각 이정표 이후에 계속 확인하여 모든 사람이 프로젝트에 대한 향상된 이해의 혜택을 받고 프로젝트의 이정표가 계속 유지되는지 확인하는 것입니다( 대략) 처음에 믿었던 것과 같은 크기입니다.

예상 시간

우리 프로그래머는 추정치가 틀릴 것이라는 것과 우리에게 불리하게 사용될 것이라는 것을 알고 있기 때문에 추정치를 절대적으로 싫어합니다. 정의상 소수의 미지수를 기반으로 하기 때문에 그들이 틀렸다고 해도 괜찮습니다. 우리 직업이 꽤 푹신하고 때때로 채찍이 부러지는 것이 아프지 않기 때문에 그들이 우리에게 불리하게 사용되어도 괜찮습니다.

따라서 새로운 이정표에서 작업이 시작될 때마다 언제든지 견적을 요청하십시오. 각 주요 기능에 대한 대략적인 예상 시간과 함께 한두 줄을 예상해야 합니다. 나는 일반적으로 낙관적인 추정을 한 다음 두 배로 늘립니다. 종종 이 추가 시간은 보이지 않는 함정을 설명합니다.

사용자 스토리

사용자 스토리는 앱 내의 단일 기능에 대한 간략한 설명입니다. 그것들은 중요한 특징의 기록으로 유용하며 인덱스 카드에 들어갈 수 있고 종종 약간의 그림과 함께 할 수 있는 한입 크기여야 합니다. 더 중요한 것은 클라이언트가 원하는 것과 프로그래머가 컴퓨터에 말해야 하는 것 사이의 다리 역할을 한다는 것입니다. 그것들은 클라이언트인 당신이 몇 분 안에 녹아웃할 수 있을 만큼 간단하지만 프로그래머인 우리가 빠져들기에 충분히 자세합니다.

사용자 스토리에 대한 몇 가지 빠른 정보를 위해 Mountain Goat Software와 Roman Pichler의 이 튜토리얼이 고품질의 간결함을 발견했습니다. 애자일 프로젝트 관리의 전체 철학에 대한 자세한 내용은 Paul Barnes의 이 Toptal 블로그 게시물 애자일 프로젝트 관리에 대한 궁극적인 소개를 참조하십시오.

작곡(목업)

이것은 대부분의 클라이언트가 이미 그것을 이해하고 있다고 느끼기 때문에 디자이너가 필요한 이유에 대한 기사가 아니지만, 프로그래머 앞에서 구체적이고 잘 고려된 디자인을 하면 엄청난 생산성 향상을 볼 수 있기 때문에 반복해야 합니다. 디자인 결정을 내려야 할 때마다 우리는 "영역"을 떠나야 하고, 최종 초안이 제공되지 않았기 때문에 돌아가서 무언가를 변경해야 할 때마다, 글쎄요, 당신이 계산을 하고… 디자인이 재미있기 때문에 불평하지 않습니다. 그러나 제 경험에 따르면 이것이 피할 수 있고 추가 청구 가능한 시간의 제 1 소스입니다.

대부분의 디자이너는 Adobe Photoshop, Adobe Illustrator 또는 Sketch에서 컴포지션이라고도 하는 컴포지션을 제공합니다. 직접 하는 경우 Balsamiq 또는 InVision과 같은 수많은 온라인 도구 중 하나를 사용할 수 있습니다. 구성 요소는 완성된 제품과 동일한 색상과 스타일을 가질 필요는 없지만(나중에 쉽게 변경할 수 있기 때문에) 시간을 내어 모든 UI 요소가 존재하고 설명하는지 확인하십시오.

스탠드업 미팅

긴 회의가 불가피할 때도 있지만 프로그래머에게 과부하를 주거나 필요한 것보다 더 많은 시간을 소비하고 싶지는 않을 것입니다. 나는 내가 2시간 30분 동안의 회의에서 말한 모든 것을 기억하기를 기대하는 것처럼 보이는 고객이 있었습니다. 그들은 크게 실망했습니다. 기립 회의는 일반적으로 15분으로 제한되며 지속 시간 동안 서 있는 것이 관례입니다. 스탠딩 측면은 모든 사람이 참여하고 회의를 짧게 유지해야 합니다.

스탠드 업 동안 모든 팀원이 서로의 진행 상황에 대한 최신 정보를 유지하면서 간단한 상태 보고서를 제공하기 위해 원을 그리며 돌아갑니다. ExtremeProgramming.Org에서 스탠드업에 대해 자세히 알아볼 수 있습니다. 모두 원격으로 작업하고 매일 Skype에 접속하고 싶지 않다면 스탠드업 대신 15Five와 같은 재미있는 도구를 사용해 볼 수 있습니다. 15Five를 사용하면 팀원들이 편할 때 언제든지 의견을 제시할 수 있으며, 보다 심층적인 응답을 도출하기 위해 설문조사 질문이 제공됩니다.

발권 시스템

누구나 스티커 메모 및 Google 문서 시스템(모든 사람의 작업이 서로 다른 색상으로 강조 표시됨)을 유지할 수 있지만 실제로는 필요하지 않습니다. 많은 사람들이 당신을 위해 이 문제를 해결하려고 노력했습니다. Basecamp와 Trello는 사용 용이성으로 유명하지만 Pivotal은 전체 "애자일" 철학을 매우 매끄러운 패키지로 캡슐화하려고 합니다. 어떤 선택을 하시든 좋은 발권 시스템을 통해 최소한 다음을 수행할 수 있습니다.

• 작업 만들기
• 우선순위 및 마감일 지정
• 작업 및 하위 작업 연결
• "완료" 또는 "테스트 실패"와 같은 다양한 해결 방법 할당
• 특정 사용자에게 할당된 모든 작업 표시

프로젝트 관리자가 같은 날짜에 마감된 40장의 밝은 빨간색 최우선 티켓을 보여주면 이 프로젝트의 조감도의 가치를 진정으로 이해하게 될 것입니다.

소스 제어

프로젝트의 버전 제어 시스템에 있는 코드를 전혀 보지 않을 수도 있지만 소스 제어(또는 버전 관리)는 우리가 처리할 수 있는 가장 중요한 도구 중 하나이며 상상할 수 있는 가장 큰 백업 시스템입니다.

대부분의 현대적인 프로젝트는 Git을 사용하지만 가끔은 잠시 동안 있었던 프로젝트에서 작업할 때 Subversion(SVN)을 실행하게 됩니다. Github을 사용하면 무제한 공개 리포지토리를 무료로 호스팅할 수 있으며(게다가 여기에는 세계의 대부분의 오픈 소스 프로젝트가 포함됨) Bitbucket을 사용하면 무제한 비공개 리포지토리를 호스팅할 수 있으므로 상용 프로젝트에서 선호하는 선택입니다.

어떤 버전 제어 시스템을 선택하든 문제가 발생할 경우에 대비하여 원격으로 코드를 저장하고 코드를 "커밋"할 때마다 추적하면서 작업 중인 내용을 설명하는 약간의 메시지를 작성하도록 합니다. 이렇게 하면 서로 다른 개발자가 서로의 코드를 덮어쓰는 것을 방지하고, 주어진 기간 동안 변경된 모든 내용을 볼 수 있으며, 즉시 실행되지 않는 기능을 저장할 새 코드 분기를 생성할 수 있습니다. 심지어 주어진 코드 줄에 대한 책임이 있는 사람과 커밋된 시간을 보여주는 "blame"이라는 명령도 있습니다.

소스 제어가 가장 좋습니다.

테스트 주도 개발

이것은 상대적으로 비용이 많이 드는 방식이므로 예산이 몇 명의 프리랜서로 제한된 프로젝트에서 자주 사용되지 않습니다. 따라서 스타트업 기업가인 당신은 이것을 하지 않은 것에 대해 너무 슬퍼해서는 안 되지만 버그에 대한 궁극적인 방어를 제공하기 때문에 아이디어를 당신 앞에 매달아 놓아야 합니다. 기본적으로 프로그래머는 앱의 특정 부분이 구체적이고 예측 가능하며 반복 가능한 방식으로 동작하도록 하는 테스트(작은 코드 블록)를 작성하는 데 귀중한 시간을 추가로 소비합니다. 예를 들어 "로그인" 버튼을 클릭하면 사용자 이름 필드가 있는 팝업이 열리도록 하는 테스트를 작성할 수 있습니다.

테스트의 장점은 일단 작성한 후에는 하나의 명령으로 모두 실행할 수 있다는 것입니다. 200개의 테스트를 작성했다면 새 버전의 앱을 출시한 후 테스트를 실행하여 200개의 기능에 버그가 도입되지 않았는지 확인할 수 있습니다. 완벽하지는 않지만 버그가 없는(적어도 버그가 없는) 앱을 보장하는 데 최대한 가깝습니다.

마무리

이것이 내가 프로젝트 관리에 대해 아는 전부입니다. 이 중 얼마나 많은 것이 프로젝트 관리 연구소에서 소집되어 지나갈지 모르겠지만 지난 10년 동안 웹 프로젝트에서 작업하면서 얻은 모든 것입니다. 물론, 나는 당신이 누군가를 고용하여 그 또는 그녀의 경험을 활용할 것을 권장하지만, 당신이 할 수 없는 일이더라도 이 정보가 도움이 되기를 바랍니다. 당신은 이 프로젝트의 궁극적인 권위자가 될 것이므로 내부 작동에 대해 더 많이 이해할수록 프로젝트를 승리로 이끌 가능성이 높아집니다.