共计 2756 个字符，预计需要花费 7 分钟才能阅读完成。
背景
笔者目前经营着一个开发人员为主的团队。成员有产品经理、前端开发、后台开发、测试、UI 设计师。在实际的项目开发中，一旦项目周期较长，上线时间非常难以把握。此外因为时间安排不合理，项目输出的软件产品质量也很难有所保证。
经过几次有些失败的项目开发经历，总结了一些原因，发现主要是因为开发过程中成员沟通问题所导致。特别是在前后端分离的开发过程中，更容易出现因开发人员沟通协调不到位出现各种问题。
痛定思痛。原先坚定认为小团队不需要进行项目管理的笔者，也不得不去思考一些有效的方案来破局。在最新的项目中，这一套方法论还是带来了不错的成效，今天在这里分享给大家。
正文
需求分析
笔者最早在学习软件工程的时候，就听过一句话：一切（发布的）软件问题，归根结底都是需求问题。这个环节主要是产品经理负责。
原先我们的流程是产品经理做需求分析，制作原型，然后组织全体研发成员（UI+ 前端 + 后端 + 测试）进行评审。这样的流程是存在不少问题的。一个会议人数如果超过 5 个人，就很难相互进行有效的交流，转而成为了一个公开发布的会议。
而当下情况，一个有开发经验的产品经理可遇不可求。产品经理设计出的原型，往往因为其缺乏开发思维，会出现一些逻辑错误。另外，最典型会出现的问题是，很多产品经理的原型只考虑了最表层的页面流程，而被这背后的数据流转缺乏认识。
针对以上问题，我们在这个所谓的“产品评审”环节前增加了一个“架构师评审”的环节。由一个资深的开发人员对产品原型先进行评审，这位开发人员需要时擅长后台开发的技术人员，辅助完善产品设计上的后台逻辑部分。在这个“架构师评审”环节完成之后，再组织全体研发人员进行公审，可以避免掉很多问题。
总结：产品在向全体成员输出原型之前，需资深开发对原型进行一次评审，从源头避免一些需求问题。
任务拆解
对于一个周期较长的项目来说，如果在开发把所有的功能全部实现之后在再开始进行测试和需求验证，风险会很大。所以，在开始进行开发之前，我们需要先将一个完整的产品拆分成相对对立的模块，每个模块需要能够独立的进行测试（典型的就是能够时间完整的增删改查功能），最后再将各个模块组合起来进行完整测试。
这项工作说起来简单，但是实际操作上并不容易。对于一个较为复杂的产品来说，各个模块的耦合度还是挺高的。所以在进行工作的安排时，完成顺序需要进行良好的规划。比如一个系统在进入测试（这里指的是有 QA 人员进行的测试）的时候，其最先需要完成的步骤。所以在规划上，我们需要把被依赖最多的模块安排在优先级最高的地方。
说到任务拆解，不得不聊聊分布提交测试。在以前我们往往会在一个项目即将开发完成的时候，才提交到测试那里进行测试。这种方式存在两个问题：
在开发阶段，测试往往并没有能够参与进入工作的机会，导致了时间浪费
同一时间测试那里堆积了过多的工作量，对于项目的整体进度带来了不稳定性
所以，做好任务拆解，一个不错的功能就是能够让测试较早的介入工作。项目经理通过规划好项目更新的计划，先完成一个相对完成较为独立的模块，集中开发完成此模块，然后进行测试提交。即可很好地完成将测试进度与开发进度交叉起来。
按照这种方式进行拆解，当然仍旧难以测试到各个模块相互交叉关联的地方。所以最后在整个项目开发完成，进行完整的集成测试仍旧是必须的。
任务跟进
里程碑
里程碑是在项目管理中比较经常强调的概念，这个概念放在项目开发中非常形象。相信很多人跟我一样，上学的时候老师布置的寒假作业、暑假作业经常只有到假期快结束的时候才会想起来写。在项目开发中也一样，大部分人对于时间节点是没有明确的概念的。所以将大目标分解成相应的小目标，能够有效的降低项目最终延期的风险。
站例会
最初听说站例会的时候，我是很不以为然的，总是觉得团队内部有什么问题，直接进行沟通就行了，应该不存在需要每天专门开会来解决的问题。而且现在有类似 Tower、Teambition 这样的协作产品，在团队的进度实时同步上能够提供很大的帮助。
但是在实际的项目实践中，往往因为各种原因，很多同事不会或者不愿意进行相关的沟通。在 Tower、Teambition 这种工具的使用过程中，也发现很多同事并不愿意及时去更新上面的任务状态，最终这类软件的任务安排流于形式，无法有效地跟踪任务进度状况。
前期我们遇到这个问题的时候，只能通过询问每个开发的方式来获取最新的项目进度情况，当时长期以往发现这个方式非常讨嫌。大部分开发都是比较讨厌别人向他们问进度情况的。
这个时候，站例会的优势就体现出来了。站例会的基本规则就是要求每个开发自述自己当前的项目情况，主要有以下几点：
我当前在做什么
我今天会完成什么
我有什么需要支持的工作
在会上如果成员提出需要何人支持，可以得到项目组相关成员的立即响应，对于成员的信息流转又很大的帮助。
甘特图管理整体项目进度（以模块进度来进行管理）
甘特图真的是一个好东西，可以很清晰的掌握项目的整体进度。但是我们在尝试使用的时候总是没有很好的办法让他落地。其中一个很重要的原因是一开始我们就把甘特图定的太细了。
例如，我们开发模式是前后端分离开发，为此将每个前后端的任务全部拆分开进行展示。这样做的后果就是甘特图上的任务过多，无法很清晰的定位，进而无法很好地把握整体项目进度。
经过我们的多次项目实践，发现一个较好的使用甘特图的方式就是：每个任务按独立的模块划分。无论是前端还是后台，我们将他们的模块放在一起进行管理。这样做的好处还有一点，就是能够刺激前后端共同合作把模块做好，而不是在遇到问题的时候，各种推脱甩锅。
网上又很多甘特图软件，但是就灵活性和易用性来讲，我还是喜欢使用 Excel 里的甘特图模板，耐心体验一下就会发现非常好用。有机会笔者会出一篇小教程来讲讲如何使用 Excel 里的甘特图模板。
后记
项目管理的过程，必然将分担一大部分人的精力。笔者个人仍旧认为，如果资源足够，一个团队最好的优化效率的方法是：严格抓招聘环节，及时淘汰掉不合适的人。
最后说说写这篇文章的感想吧。今天在听《罗辑思维》之前比较老的节目，里面讲到了“实验室经验”和“工厂经验”。前者指的是科学家们在研究所里面对新的技术、产品去研究，总结并发布自己的经验；后者指的是工厂在生产中总结出的各种难以复制的实践经验。
作为一个工作了 7 年的程序员，深知很多知识是难以在书本以及博客上学习到的。很多时候我们在某一个博客上学习到了某个技术知识，但是当它应用到生产的时候，就会出现各种问题。正如这篇文章讲的项目管理知识，个人在刚开始带团队的时候，也看了不少相关的文章和资料，但是大多都过于理论化，难以应用到我们实际的工作当中。
今天我写这篇文章，正是想要分享我在实践工作当中的“工厂经验”，这些经验可能不是最好的，但一定是经过实践考验的。希望能够帮到看到这篇文章的你。