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

背景

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

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

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

正文

需求确认

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

原先咱们的流程是产品经理作需求分析，制做原型，而后组织全体研发成员进行评审。这样的流程咱们在前期进行了好久，可是问题有不少，好比：你们在会议上要么没法有效提出改进意见；要么就是提的意见太多，会议没法正常进行。而且，在团队人数逐渐增长的过程当中，这种状况会愈演愈烈。

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

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

任务拆解

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

这项工做提及来简单，可是实际操做上并不容易。对于一个较为复杂的产品来讲，各个模块的耦合度仍是挺高的。因此在进行工做的安排时，完成顺序须要进行良好的规划。好比一个系统在进入测试（这里指的是有 QA 人员进行的测试）的时候，其最早须要完成的步骤。因此在规划上，咱们须要把被依赖最多的模块安排在优先级最高的地方。

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

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

任务跟进

里程碑

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

站例会

笔者起初对于站例会不太在乎，老是以为团队内部有什么问题，直接进行沟通就好了，应该不存在须要天天开会来解决的问题。并且如今有相似 Tower、Teambition 这样的协做产品，在团队的进度实时同步上可以提供很大的帮助。

可是在实际的项目实践中，每每由于各类缘由，不少同事不会或者不肯意进行沟通。在Tower、Teambition 这种工具的使用过程当中，也发现不少同事并不肯意及时去更新上面的任务状态，最终这类软件的任务安排流于形式，没法有效地跟踪任务进度情况。

前期咱们遇到这个问题的时候，只能经过询问每一个开发的方式来获取最新的项目进度状况，可是这个方式很是讨嫌。大部分开发仍是比较讨厌别人向他们问进度状况的。

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

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

在会上若是成员提出须要何人支持，能够获得项目组相关成员的当即响应，及时解决须要支持、依赖的工做，可以有效地促进你们工做的完成。

甘特图

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

例如，咱们开发模式是先后端分离开发，为此将每一个先后端的任务所有拆分开进行展现。这样作的后果就是甘特图上的任务过多，没法很清晰的定位，进而没法很好地把握总体项目进度。

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

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

后记

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

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

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

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