浅谈项目管理
丁磊的故事
以前提到网易大家只会想起游戏，而现在除了猪肉还有云村和严选（chao）等等，网易的产品很出色，云音乐很棒（工匠精神、艺术品）。
丁老板很关注公司的产品，经常会给产品经理提各种意见。有时候突发奇想会提一些不是很靠谱的需求。
这时候产品经理怎么办呢？有一位产品经理这样说的：我们先答应着，过段时间老板会忘的。过了段时间，丁老板确实也发现自己提的需求不太靠谱然后自己也谈忘了。
这个产品经理富有项目管理哲学。
产品经理与开发的矛盾
这里以创业公司举例说明，一般来说可以生存的创业公司，老板的视野格局都还是不错的，老板看得远，直面客户。老板是最了解客户需求的。所以老板很多时候都可能会和产品经理提出各种各种的需求。
通常来说，比起该需求做一些不痛不痒的功能他们更希望可以有多一点时间优化自己代码和提升自己的代码性能。
正确的方式是什么呢？开发的东西可以快速给用户试错，不断迭代，那么整个项目开发流程/产品周期走下来，开发会更有成就感，但不是每个开发和产品都能那么幸运。
这也是产品经理的价值所在，协调现有资源推进产品开发，让大家有条不紊的做事。
管理的目的
说到管理，我们会想到很多，自我管理、情感管理、时间管理、项目管理等等。
这里推荐一本关于时间管理的书：李笑来老师的 <把时间当朋友>。它告诉我们：如何打开心智，如何运用心智来和时间做朋友，如何理解时间管理的意义，在时间管理上取得突破，进而用心智开启自己的人生成功之旅。
项目管理的直接目的是提高项目组的开发/工作效率，让项目顺利进行。
项目管理工具
今天主要介绍的是JIRA，一个适用于中大型企业的项目管理工具。
被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域,项目管理工具。国内的竞品有腾讯的TAPD、明道、teambition、Tower.im、Worktile、trello等
Scrum boards/Kanban boards
Agile teams can stay focused on delivering iterative and incremental value, as fast as possible, with customizable scrum boards.
支持看板式问题管理、拖拽式操作。
Flexible kanban boards give your team full visibility into what’s next so you can continuously deliver maximum output in minimal cycle time.
image.png
image.png
好的流程
一般来说，B端产品的需求流程是这样子的。
- 需求产生：无法满足客户业务功能或者有了新业务就会产生需求；
- 需求管理：通过销售或客服传达给产品经理，产品经理分析需求并根据优先级等进行排期，需求拆解为开发的任务，需求评审，开发；
- 开发完成：测试通过，完成一个小版本迭代，交给客户使用。
下图是需求管理的流程，从任务的开始到开发到发布全流程。
workflow
任务状态的流程
| Status | Description | Expected Result | Owner | Next Action |
|---|---|---|---|---|
| Open | Initial status for all ticket | foo | ||
| Pending Requirement | Product manager start to collection information | - Requirement collected - Interaction design/Flow chart | Product Manager | Waiting for product owner approve |
| Product Approval | Product owner approve feature based on interaction design | - Approve or reject | Product Owner | Pass to designer |
| Design | Designer work on UI based on interaction design | - UI design | Designer | Waiting for product owner approve |
| Requirement Writing | Product manager write detail requirement base on UX and UI Work with QA write QA use cases | - Requirement document - QA test cases | Product Manager | On Schedule |
| On Schedule | The feature is ready, waiting for schedule it | Product Owner | Ready to do | |
| Plan | Based on the priority, product team will decide which ticket should work on in the meeting of Agenda for Product Plan Meeting | - Prioritize tickets in SPS Plan Board | Product Owner | In Progress |
| In progress | Development team is working on it | Developer team Owner | Staging | |
| Staging | Ready to test on staging environment | - Feature is ready to test on staging | Product Manager | QA |
| QA | QA is testing whole feature and all test cases | - All test cases covered -Edge cases covered | QA | Production |
| Production | Deployed to Production | - Working production version - Release notes sent | Product Manager | End |
团队角色
| Role | Duty | Note |
|---|---|---|
| Product Manager | ||
| Project Manager | ||
| Developer | ||
| Team Leader | ||
| QA | ||
| UX | ||
| UI |
敏捷开发
上面的流程比较复杂，比较适合中大型开发团队（研发20人以上）。
小团队的话分三个阶段
产品整理好这个版本的需求（需求背景和逻辑以及希望达到的目的）
开会和开发们(前后端)讲解需求
开发评估时间
制定sprint meeting 目标并开始sprint meeting，追求敏捷开发的话不需要太受限制于项目管理形式，也给开发足够的时间，没有任务的时候他们会进行技术储备，还是要信任开发并互相配合。
产品驱动开发快速完成版本计划
