笔者在近期参加了公司的PM培训，对于项目管理有了一些明确的方法论和经验教训。为了更好的让大家对项目管理有体感，特将我去年当技术PM时，主导做的一个核心项目拿出来反思（现在回头看过去，那时候就是土八路，问题一堆，但是好在后来事情还是做完了）。本文会从项目管理的5个阶段（启动/规划/执行/监控/复盘），依次还原我们当时是怎么做的，遇到了什么问题，以及应该怎么做。希望通过本文，大家能对项目管理有一个初步的认识，并收获到一些项目管理工具和方法论，并真正用在自己的日常工作中。本文中涉及到的项目管理概念，会在附录中放置参考链接，请自行查阅。
1. 项目背景
1688搜索在重构前是一个3年多没有重构过的老项目，主要的问题是前后端耦合，业务支撑和维护都很慢，搜索性能整体不好且UI层面上信息繁杂无序；更糟糕的是缺乏AB实验等业务持续迭代需要的能力。
在痛苦的折磨了一段时间之后，业务方和技术同学下定决心，发起了一个重构项目。项目的详细信息如下：
项目时间：预期2个月
项目目标：通过性能和UI的提升，给予用户更好的体验，并提升搜索的转化率
项目参与人：前端，后端，PE，PD，测试
项目PM：前端（笔者本人）我在没有参加PM培训之前，大家都是土路子，甘特图一画大家就撸起袖子开干了（如下图）。当然了，项目在实际推进的过程中出现了很多问题。下面我们就针对项目推进各阶段中出现的问题，一一进行盘点，并反思最佳的解决方案，希望能在实战中给大家一点项目管理中的帮助。
2. 项目遇到的问题
在项目管理中，项目会被分为5个阶段。下面我们将逐一盘点各个阶段中搜索重构这个项目遇到的问题。
2.1 启动阶段
2.1.1 只关注了技术侧的持续交付
我们在当PM的过程中，很容易只关注持续交付需求&研发效能的提升，觉得作为技术PM，将整个开发工作按时推进完就OK了，若是在这其中能有一些研发效率的提升就更加完美。但是如果我们反思一下，就会发现经常做了一些上线后根本没有用的项目。这些项目或者被迫下线了，或者没有业务收益。
不关注业务价值的研发效率是没有价值的
这其实是我们没有将业务提升从一开始纳入到PM管理中导致的。PD们往往不清楚某些项目的ROI和风险，所以从项目的启动阶段，就要积极的参加到产品规划中去，对于有问题的需求要在项目的开始就拍死，这样才能尽可能的减少让自己觉得难受/恶心的需求。
搜索在这块很幸运，尽管也只关注了技术侧的持续交付和研发效能提升，但是通过UI的改版最终也取得了业务的价值。当然这有很大的幸运成分，系统化的学习项目管理就是将幸运变成持续的成功。
2.1.1 没有明确的项目目标
我们前文讲过，搜索重构的目标是：通过性能和UI的提升，给予用户更好的体验，并提升搜索的转化率。好的目标应该有下面三个特性：
专注：目标并不是越多越好，应少而精
具体：目标要具像化，而不是空洞的口号
牵引：目标能够牵引前进的方向，而不是日常琐事明显我们的目标比较空洞，没有上面的三个特性。这其实是我们在一开始没有理解业务背后的隐藏逻辑。搜索背后的业务系统模型应该如下：
整个1688搜索其实是一个飞轮，商品多了买家体验就好了，买家体验好了交易量就会上升，交易量上升卖家数就会增多，卖家数增多商品多样性就会增多——从而重新导致买家体验变好。这样就变成了一个增强回路。而我们的这次重构，正是通过更好的商品信息透出，让用户更容易找到自己关心的商品，从而提升自己的购买体验。在用户体验这一层级来促进飞轮的运行。
当有了这个业务模型之后，是不是目标就变的清晰了，项目的核心就从提升搜索的转化率变成了提升商品视图模型，衡量指标变成了点击率/转化率。
当然，我们还需要将目标进一步具体化，比如说提升5%的点击率，同时进行可行性分析，预估我们要新的商品视图模型是否可以保证这样的提升，如果不行的话要有其他的预案。
最终我们的目标应该是：
业务目标：商品点击率提升5%，转化率提升10%
技术目标：沉淀商品视图模型提升中台，对外输出搭建，AB，数据反馈3种能力
在这一部分我们引入了一个新的工具，有兴趣的同学可以自行了解一下： CLD图（因果回路图）。
2.2 规划阶段
2.2.1 过于乐观
在规划阶段犯的最大问题就是过于了乐观。将各个工作都按照理想化的情况进行了分工，没有流出时间buffer。或者说，被老板逼着倒推了时间节点，但是也没有认清这个时间节点的困难度。这最终导致了这个项目的延期。
2.2.2 没有进行目标的合理拆解
过于乐观其实因为对整个项目理解不够导致，换言之，我没有对我们要达到的目标进行合理的拆解。事实上，我只分析了前端自己要做的内容，然后列了一个简单的甘特图，就开始做了。
而我应该要根据我们项目中的系统结构、产品功能、实现过程，将项目划分成较小的，更容易管理的部分，并保证每个最细纬度的工作量都在1-2天之内。
业务目标的拆解这边推荐使用影响地图来建立业务目标到产品功能的链接：
WHY：项目的目标
WHO：项目的用户
HOW：我们该怎么做
WHAT：具体怎么做举个例子：
2.3 执行阶段
如果说在项目的启动/规划阶段我们主要是缺失了某些步骤，在项目的执行阶段我们就主要是犯了错。最大的问题是信息流动不畅和低下的流动效率。
2.3.1 信息沟通不畅
- 向上沟通
在向上沟通的过程中，主要的问题是有问题，有疑问不敢沟通，在项目的后期，由于延期了，问题都倾向于自己去解决，而不是及时上报。从另外一个层面又增加了项目的风险。
向上沟通应该包含如下四部曲：问题描述，原因分析，影响范围和解决方案（一个或多个）- 跨团队沟通
整个重构项目还是比较大的，同时前端位于杭州，后端位于北京，这一定程度上造成了沟通的困难。尤其是进度黑盒的问题，在项目后期比较严重。
其实我们如果能在一开始就确定目标，明确分工，建立沟通机制和问题处理方案，整个信息沟通的问题会少很多。
2.3.2 低下的流动效率
最终我们这个项目延期了2个月（整体4个月），其实前端大概就干了2个月，但是由于流动效率是瀑布型的，测试测了1个月，后端同学优化也用了1个月。
若是我们能先盘清楚产品的MVP链路，然后进行持续的迭代，让各方面并行起来，等待的时间就会大大减少，流动效率也会提高。
2.4 监控阶段
2.4.1 项目延期
由于没有进行合理的目标拆分和迭代，项目延期了。但是如果我可以一开始就定下责任人和责任时间，并持续监控，那么我们就有充足的时间来制定应对措施。而不是最后默默接受项目延期的结局。
2.5 收尾阶段
2.5.1 没有交付复盘
这个项目最终我们达到了：
搜索性能提升：Search Web端搜索性能提升64%，整体耗时降低39%；PC前端页面渲染能力提升：1s内首屏渲染完成率提升39.43%
发布效率提升：前后端分离后，后端发布时间由3人/天提升至1天；前端发布时间由3人/天提升至小时级；
问题排查效率提升：提升5倍左右问题排查的效率。线上问题排查能力从原来的0，到现在98%以上都可在线排查，并且具备历史问题追查能力；
搜索转化指标提升：实验效果达到搜索转化率相对提升9.34%，点击率相对提升5.58%。
但是，由于没有及时的进行交付复盘，明确下一步迭代的方向，导致我们后续的迭代由于方向不明反而有所迟缓，这也是我们需要反思的。
总结
本文利用了CLD图，影响地图和一些方法论，重新对1688搜索重构这个项目进行了反思，罗列出了项目各阶段遭遇的问题和应该采取的方法，希望能给大家一点帮助。