互联网产品项目管理经验分享

背景

笔者目前经营着一个开发人员为主的团队。成员有产品经理、前端开发、后台开发、测试、UI设计师等。在实际的项目开发中，一旦项目周期较长，上线时间就非常难以把握，项目输出的软件产品质量也很难有所保证。

经过几次有些失败的项目开发经历，我总结了影响项目进度一大原因：沟通问题。特别是在前后端分离的开发过程中，更容易出现因开发人员沟通协调不到位而出现问题。

痛定思痛。原先坚定认为小团队不需要进行项目管理的笔者，也不得不去思考一些有效的方案来破局。在最近的一次项目中，我在团队中尝试了一套比较简单的项目管理方式，取得了出乎意料的成果，今天在这里分享给大家。

正文

需求确认

笔者最早在学习软件工程的时候，就听过一句话：一切软件问题，归根结底都是需求问题。这句话虽然有些夸张，但是需求分析的确是很多团队的短板。这种情况也进而形成了现在产品开发圈里吐槽产品经常改需求的特殊文化。

原先我们的流程是产品经理做需求分析，制作原型，然后组织全体研发成员进行评审。这样的流程我们在前期进行了很久，但是问题有很多，比如：大家在会议上要么无法有效提出改进意见；要么就是提的意见太多，会议无法正常进行。并且，在团队人数逐渐增加的过程中，这种情况会愈演愈烈。

此外，一个有开发经验的产品经理可遇不可求。产品经理设计出的原型，往往因为其缺乏开发思维，会出现一些逻辑错误。比如一个常见的问题：原型上只考虑了最表层的页面流程，而这个流程涉及到的后台流程却被产品忽略。

针对以上问题，我们在这个所谓的“产品评审”环节前增加了一个“架构师评审”的环节。由一个资深的开发人员对产品原型先进行评审，这位开发人员需要是擅长后台开发的技术人员，辅助完善产品设计上的后台逻辑部分（前端的内容比较形象，产品往往也能够很容易考虑到，当然能够找到前端一起分析最好）。在这个“架构师评审”环节完成之后，再组织全体研发人员进行公审，可以节约不少时间。

任务拆解

对于一个周期较长的项目来说，如果在开发把所有的功能全部实现之后在再开始进行测试和需求验证，风险会很大。所以，在开发之前，我们需要先将一个完整的产品拆分成相对对立的模块，每个模块需要能够独立的进行测试（典型的就是能够实现完整的增删改查功能），最后再将各个模块组合起来进行完整测试。

这项工作说起来简单，但是实际操作上并不容易。对于一个较为复杂的产品来说，各个模块的耦合度还是挺高的。所以在进行工作的安排时，完成顺序需要进行良好的规划。比如一个系统在进入测试（这里指的是有 QA 人员进行的测试）的时候，其最先需要完成的步骤。所以在规划上，我们需要把被依赖最多的模块安排在优先级最高的地方。

所以，做好任务拆解，能够让测试较早地介入工作。项目经理通过规划好项目更新的计划，由开发先完成一个相对完成较为独立的模块，然后进行测试提交。即可很好地完成将测试进度与开发进度交叉起来。

按照这种方式进行拆解，在前期难以测试到各个模块相互交叉关联的地方。所以最后在整个项目开发完成，进行完整的集成测试仍旧是必须的。

任务跟进

里程碑

里程碑是一个在项目管理中经常被强调的概念。相信很多人跟我一样，上学的时候老师布置的寒假作业、暑假作业经常只有到假期快结束的时候才会想起来写。在项目开发中也一样，大部分人对于时间节点是没有明确概念的。所以在项目中设定多个里程碑，每个里程碑都重新梳理项目的计划以及剩余工时，能够有效的降低项目最终延期的风险。

站例会

笔者起初对于站例会不太在意，总是觉得团队内部有什么问题，直接进行沟通就行了，应该不存在需要每天开会来解决的问题。而且现在有类似 Tower、Teambition 这样的协作产品，在团队的进度实时同步上能够提供很大的帮助。

但是在实际的项目实践中，往往因为各种原因，很多同事不会或者不愿意进行沟通。在Tower、Teambition 这种工具的使用过程中，也发现很多同事并不愿意及时去更新上面的任务状态，最终这类软件的任务安排流于形式，无法有效地跟踪任务进度状况。

前期我们遇到这个问题的时候，只能通过询问每个开发的方式来获取最新的项目进度情况，但是这个方式非常讨嫌。大部分开发还是比较讨厌别人向他们问进度情况的。

这个时候，站例会的优势就体现出来了。站例会的基本规则就是要求每个开发自述自己当前的项目情况，例如：

• 我当前在做什么
• 我今天会完成什么
• 我有什么需要支持的工作

在会上如果成员提出需要何人支持，可以得到项目组相关成员的立即响应，及时解决需要支持、依赖的工作，能够有效地促进大家工作的完成。

甘特图

甘特图真的是一个好东西，可以很清晰的掌握项目的整体进度。但是我们在尝试使用的时候总是没有很好的办法让他落地。其中一个很重要的原因是一开始我们就把甘特图定的太细了。

例如，我们开发模式是前后端分离开发，为此将每个前后端的任务全部拆分开进行展示。这样做的后果就是甘特图上的任务过多，无法很清晰的定位，进而无法很好地把握整体项目进度。

经过我们的多次项目实践，发现一个较好的使用甘特图的方式就是：每个任务按独立的模块划分。无论是前端还是后台，我们将他们的模块放在一起进行管理。这样做的好处还有一点，就是能够刺激前后端共同合作把模块做好，而不是在遇到问题的时候，各种推脱甩锅。

网上又很多甘特图软件，但是就灵活性和易用性来讲，我还是喜欢使用 Excel 里的甘特图模板，耐心体验一下就会发现非常好用。有机会笔者会出一篇小教程来讲讲如何使用 Excel 里的甘特图模板。

后记

说说写这篇文章的感想吧。《罗辑思维》有一期比较老的节目，里面讲到了“实验室经验”和“工厂经验”。前者指的是科学家们在研究所里面对新的技术、产品去研究，总结并发布自己的经验；后者指的是工厂在生产中总结出的各种难以复制的实践经验。

作为一个工作了 7 年的程序员，深知很多知识是难以在书本以及博客上学习到的。很多时候我们在某一个博客上学习到了某个技术知识，但是当它应用到生产的时候，就会出现各种问题。正如这篇文章讲的项目管理知识，个人在刚开始带团队的时候，也看了不少相关的文章和资料，但是大多都过于理论化，难以应用到我们实际的工作当中。

今天我写这篇文章，正是想要分享我在实践工作当中的“工厂经验”，这些经验可能不是最好的，但一定是经过实践考验的。希望能够帮到看到这篇文章的你。

都看到这里了，点个赞关注一波哦。