[Tech PM이란] 개발자의 "안됩니다"는 "하기 싫습니다"가 아닙니다.

개발자가 말하는 "안됩니다"는 단순히 "하기 싫습니다"라는 뜻이 아닙니다.

 

개발자는 물론 도구가 아닙니다.

제품을 생산하는 기계마저도 정확한 명령과 정해진 납기에 맞춰 제품을 생산하게 되어있습니다.

 

현업은 개발자에게 업무를 요청할 때, 다른 현업부서와 동등하게 부담을 가지고 요청해야 합니다.

개발자도 현업에게 받은 업무를 성실히 수행해야 하며, 현업의 입장과 언어에 맞춰 답변을 해야 합니다.

 

개발자가 설령 도구가 되어 일을 한다고 하더라도, 아래 상황에 따라 "안됩니다"를 시전할 수 있습니다.

1. 요구사항이 명확하지 않은 경우
 - 소프트웨어로 설명하기 어렵거나 정의되지 않아 모호한 현업의 요구사항
2. 요구사항이 명확하더라도 원하는 일정을 맞출 수 없을 경우
 - 한정된 자원 내에서 운영되는 공수를 고려하지 않은 상황
 - 개인에게 분담되는 업무의 양이 과다할 경우
3. 시스템이 구현되는 환경(인프라)의 제약이 존재할 경우
 - 보안 및 정책의 제약으로 인해 조직의 의사결정이 수반되어야 할 경우
4. 실제로 기술 구현이 불가능한 경우
 - 하드웨어의 제약, 능력의 한계(AI, ML 등)

물론, 개발자도 사람인지라 매너리즘에 빠져 정말로 하기 싫어서 안된다는 말로 방어하는 경우도 종종 있습니다.

하지만 모두가 그런 시선으로 개발자를 바라본다면, 현업과 개발자의 갈등을 좁혀나갈 수 없어 결국 서로 원하는 바를 얻지 못하게 됩니다.

 

Tech PM - 비지니스 가치가 있는 소프트웨어를 발의하고 기획/설계/일정관리/오픈/운영까지 A-Z를 관리

 

소프트웨어 구축하는 프로젝트를 발의하고 시스템을 기획/설계하는 Tech PM은 아래와 같은 일을 해야 합니다.

1. 개발자가 이해할 수 있는 수준의 요구사항 정의
2. 비지니스 상황에 맞춘 구축 우선순위 선정 판단
3. 간결하지만 명료한 문서작성 기술

기획된 시스템의 비지니스 측면 가치에 대한 고민과 구축된 시스템이 Product(제품)로서 안정적으로 고정적인 수익을 창출할 수 있도록 설계해야 합니다.

 

Tech PM은 소프트웨어 기반의 회사에서 개발자와 현업이 서로 원하는 바를 얻게끔 만들어주는 역할을
책임을 가지고 헌신적으로 실천할 수 있어야 합니다.

 

프로젝트 매니저는 이 모든 고민을 문서로 남길 수 있어야 하며, 상시 보고할 수 있는 준비가 되어 있어야 합니다.

1. 문서 히스토리
2. 메뉴구조도
3. 요구사항 정의서 2부 (현업, 개발사)
4. 테스크플로우
5. I.A(정보구조도)
6. 와이어프레임
7. 화면정의서
8. 기능명세서
9. 플로우차트
10. ERD,  다이어그램 등