개인적으로 경험한 프로젝트에서 제대로 된 진행 관리의 방법에 대해 정리해 보았습니다.

1인 달 미만

개인으로 받은 안건이나, 중규모 프로젝트로 할당된 태스크의 매니지먼트를 하는 장면에서 이용.

Backlog와 Github의 Issue로 충분합니다.
요구 사항을 정리하고, 태스크 리스트를 만들어 PullRequest에 대해 PUSH 해 가는 것만으로 좋다.

e.g.

お問い合わせページの離脱率を改善するためにいくつかの施策を行う。
対応ブラウザは各種最新とする。

- [ ] ワイヤーフレーム作成
- [ ] ◯◯さんにOKもらう
- [ ] レイアウト調整
- [ ] フォームのバリデーションをリアルタイムに実行できるようにする
- [ ] よくある質問へのリンクを目立たせる
- [ ] 離脱する際にモーダルを表示させる

요령은 자신이 하는 태스크라도, 타인에게 건네줄 수 있는 입도까지 태스크를 부수는 것.
간트나 마일스톤을 사용하면 스케줄 관리를 하기 쉽기 때문에, 기일이나 공수는 Issue에 쓰지 않는 것이 좋다.

20명 달 미만

신기능 개발이나 신규 안건의 매니지먼트를 하는 씬으로 이용.

Backlog의 부모와 자식 과제에서 Gantt 차트와 Github 프로젝트가 편리합니다.
특히 Github의 Projects는 온라인으로 칸방으로 사용할 수 있기 때문에 진행 관리가 진행된다.

요령은 진행의 룰을 결정하는 것. 칸방은 아침 제대로 갱신합시다든가.
규칙을 확실히 지키면 누군가 한 손으로 진행 관리할 수 있다.

100명 달 미만

진행 관리만을 실시하는 디렉터가 필수.

요구 사항 정의

설계서 작성

견적 및 일정

구현

테스트

위 차례로 잘 진행되지 않으면 실장 단계에서 멤버 불만이 폭발한다.
(사양이 뒤집히는 경우가 많기 때문에 잘 진행해도 폭발한다 )

이 정도의 볼륨의 프로젝트로부터 프로젝트 매니저의 수완이 물려진다.
DB 설계서나 와이어프레임 등의 설계서를 써서 멤버의 인식을 통일하는 것이 엄청 소중하다.
인식을 통일하기 위해 용어집을 준비해야 하는 경우도 있다.

대단한 기세로 간트 차트를 반죽 돌리기 때문에 크리티컬 패스의 설정을 확실히 할 수 있는 툴을 사용하면 좋다.
개인적으로 xPlan이 우수하다고 생각합니다. Backlog는 간트 업데이트가 번거롭지만 온라인으로 공유하기 쉽다.



프로젝트의 색이 나오기 쉬워지는 볼륨이므로 정직 요령이 없다.
불타지 않게 하기 위해서, 상류의 단계에서 얼마나 골 근처의 이미지를 부풀리게 할 수 있는지가 중요.

100명 달 이상

경험이 없기 때문에 여러가지 물어보고 싶다.
이 레벨의 디렉터라든지 정직하고 싶지 않지만. 단가에 따라

마지막으로

처음의 투고입니다만, 앞으로도 쵸코쵸코 써 남기고 싶습니다.