实战第五步 ：项目管理的白与黑（项目管理的三个核心步骤）
前面几篇文章讲了从市场需求到功能的过程和如何把功能落地 ，本篇文章主要讲项目管理中一些需要注意的细节，与大家分享。
消失了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协议
