实战第五步 ：项目管理的白与黑（项目管理的三个核心步骤）
前面几篇文章讲了从市场需求到功能的过程和如何把功能落地 ，本篇文章主要讲项目管理中一些需要注意的细节，与大家分享。
消失了1年，文章很有没有更新 ，很多读者和好友期待我的后续文章 ，说实话很感动，写作的目的就是帮助产品新人 ，很多与我沟通的PM觉得文章很受用 。所以我下定决心继续写下去。你们的热爱是我写作的动力 。肉麻的话就说到这里，咋们继续续写前几篇干货文章后续。
其实本篇章本不应该写的 ，因为项目把控是PMO（项目经理）的事情，产品在输出相关交付物后 ，本应该就是在开发过程中解答技术的需求疑问和验收就行 。
但是绝大部分中小型公司未设立项目经理岗位（估计觉得PM应该兼任） ，这个时候产品经理就需要充当PMO去把控项目的开发进度 。
本次文章内容基本写的大白话（主要是语文差），希望能帮到各位 。
一、什么是项目管理？
项目管理：项目的管理者，在有限的资源约束下 ，运用系统的观点 、方法和理论，对项目涉及的全部工作进行有效地管理。即从项目的投资决策开始到项目结束的全过程进行计划 、组织、指挥、协调、控制和评价，以实现项目的目标。（来源：百度百科）
读起来头头是道 ，用词专业 、文字简练。但是理解起来很有困难。
我觉得可以用大白话这么翻译 ，各位看一下对不对 ：“和一群人在有限的时间和资源下，完成一件目标明确的事情。”
二、核心工具
项目计划表
合格且规范项目会拥有一张项目计划表（如上图） ，项目经理按照预期设定的时间推进项目成员完成每阶段事宜。
本文这次介绍其中一个阶段 ：如何在研发阶段把控进度。
那如何做到项目进度的清晰把控？知道项目在开发阶段会不会存在延期风险。有人会说，会不会延期 开发不是很清楚吗？
这个时候需要纠正一下，当一个项目团队几十上百人的时候 ，每个人的分工和所负责的模块不同。他们基本不清楚所负责的模块对其他关联模块的影响有大多，所以这个时候如何管理就变得很重要。
三、核心能力
1. 拆解项目节点
2. 把控核心：任务—人—时间
根据项目整体维度，拆分成更细的维度更好把控。
- 任务：按模块分类（一级、二级模块） ，层及分类（前端、后台）；
- 人员 ：拆解任务具体谁负责完成 ，根据项目程度是否需要加上直属领导；
- 时间：计划开发完成时间 、实际开发完成时间、 联调进度、 联调完成时间、移交测试时间 。
把上面这些节点字段组合在一起，就是完整开发进度管控表。可以就长这样：
3. 系统拆分
这个是什么意思，上面不是已经说得按模块分类了吗 ？
此模块更可以理解为系统。主要是用于一些大系统升级改造，拆分成多个子项目，这个时候就需要按照每个子系统去列 。
4. 组织进度会议
PM对这种会议都不陌生（谁还没开过会啊 ，没组织过 ，也参加过） 。
这种会议的特点：又短又快：短（会议间用时短 ，5~20分钟） 、快（会议频率快，部分项目/关键节点天天开）。
5. 干系人进度同步
定期通过邮件同步项目进展，内容包括 ：
- 当前项目进度 ；
- 当前阻塞（如有） ；
- 待支持（如有）；
- 待领导决策（如有） 。
说明：干系人指提需求人员或项目Leader
其他
读到这里 ，是不是感觉好像本篇的内容已经讲完了 。是不是有一种错觉项目管理其实挺简单的，不好意思，项目管理真这么简单的话 ，那不是人人都已做PMO了（毕竟这岗位薪酬还不低）
其实在我们正常的工作中，上面的那部分所占用的时间可能只有20% ，我们更多的时间在与项目干系人 、技术同事撕逼或被他们打脸 。
- H5前端A：微笑，你这个地方设计的不合理啊，我觉得按照用户操作行为应该这么设计。
- ioses前端B ：微笑，你这逻辑是不是有问题 ，感觉怪怪的 。
- JAVA后台C：微笑，你这样设计 ，我后台又要增加临时表，这表关联的好乱，后期没办法维护。能不能调整一下方案 。
- 设计师D：……
- 某干系领导：……
- 某干系运营：……
这才是实际项目管理的真实情况。而且项目过程中出的不确定性因素太多 ，所以很难去统一化、规范化。（核心点是不变：人-事-时）
列了一些常见的点 ：
- 需求调整：细节微调、方案微调
- 需求变更：流程变更、功能变更
- 其他：方案大调整、合作方跑路 ，急需备用方案
上面这些在项目管理过程中基本占据我们60%以上的时间，在处理这些问题的方式或者方法上可能大家的存在很大的差异，或者有部分初级PM在遇到棘手的问题 ，甚至不知如何处理。
问题的本质最后也会回归到人上面，出现问题就去解决它 ，解决不了问题，就解决提出问题的人（开玩笑啦）。
处理项目过程中遇到问题的方法步骤 ：
- 分析问题的真伪性（假需求，该怎么办你懂得）；
- 及时提出解决方案；
- 与干系人确定修改后方案的合理性与可行性；
- 同步项目成员及干系人、领导方案结果。
可能读完还是没有太大感触 。举个简单的例子 ：
lowB微笑在设计登录机制时采用账号密码登录 ，开开心心码完需求文档：注册包含大小写字母-密码不少于8位；
到需求评审的时候 ，前端/后台技术就开始展示他们的专业性（批斗产品的机会来了）：
- H5技术：微笑，你这注册机制是不是太low了哦 ，现在都采用手机号 验证码登录，方便用户登录（顺带还会提一下用户体验）；
- java后台 ：你需要考虑一下用户体系，如果一开始不考虑这个，后面再去搭建用户体系，针对系统改造很大 ，你可以考虑一下使用手机号 UID，这样……（os ：大牛，讲的真好）
- ioses前端：……
再经过一番被教育后，觉得技术同事给的意见很在理 ，那么我就只能去修改，按照手机号 验证码的机制去设计。
在我修改完后怎么办 ？直接发给技术？NO！NO ！
记住 ：在项目过程中，一定要保持信息同步，同步给项目成员及干系人。
同步信息时一定要想清楚 ，那些人是必须要知道的，那些人是需要知悉。同步方式根据自己公司的实际情况去同步 ：邮件、项目群或者二者同时使用。
例如我刚刚的那个例子 ，我会这么写 ：
{日期}需求变更：
- 登录机制由账号密码变更为手机号 验证码，同时支持第三方登录（微信、QQ）……需求 ，文档已更新，位置（4.3.2）
- 效果图已同步更新……
望各位熟知 。
@具体负责开发的技术人员 。
上面只是一个很简单的例子，项目过程中 ，有很多比这个复杂、繁琐 、难以抉择 、突发是事情发生。我们需要抓住管理的本质（人-事-时）去进行灵活的变通，这样才能更好的掌握项目管理的技巧而熟练运用。
最后祝各位PM正在负责的项目顺利上线，没有重大BUG，数据biu biu biu的撑爆服务器。
#相关阅读#
实战第一步 ：市场调研
实战第二步：如何做一份有针对性的竞品分析
实战第三步：从需求池到确认需求的全过程
实战第四步：新项目之十大输出产物
本文由 @微丶笑 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash ，基于CC0协议
