如何让产品研发保持节奏感？

不少管理者在产品研发中都遇到过这样的问题：原本预计8个月就要上线的产品，作了一年功能才完成70%；deadline临近，产品目标却迟迟完成不了；原本月底要发版本，却发现还有成吨的bug没有处理……

那么，做为管理者，如何确保可以2周发布一次版本？产品功能完善时既快又稳定呢？

作产品就像马拉松，节奏感很重要

我是个喜欢跑步的人。在参加马拉松比赛时，若想取得好成绩，首先要了解本身的身体情况，好在比赛中根据本身的身体情况不断调整跑步姿式和速度，保存体力，在终点前进行冲刺。

产品研发和跑马拉松其实差很少。在整个过程当中，我一样须要不断调整团队的工做状态，保持节奏感，不能全部问题都用无限制的加班来解决，这样容易进入恶性循环，你们也会产生不良情绪。

想要造成节奏感，我认为首先要让工做更聚焦。工做明确了，你们劲儿往一处使，就会很容把目标实现，并且沟通上也会减小不少阻力。

伟大领毛主席曾说过：面对强大的敌人时，咱们要集中火力，各个击破。差很少就是这个意思了。

固然，光有主张是不够的，还要有实现方法。我在管理团队过程当中，走了不少坑，也在爬坑的过程当中总结出了一些心得，在此整理成文，与你们分享。

让工做更聚焦

记得本身第一次负责项目时，天然是踌躇满志，天天认真整理需求，把任务列表塞得满满当当，为了按时完成产品上线的目标，要求团队加班加点赶进度，梦想着有朝一日成为CEO，迎娶白富美，走上人生巅峰。但让我疑惑的是，这种方式非但没有加快进度，反而让团队作起事来变得更拖沓了。

后来经大师指点，一语惊醒梦中我：实现不了的目标，等于没目标。

是啊，定个那么大的目标，你们天天都不知道作到哪算完，一想后面还有那么多……去他大爷的，老子去逛京东淘宝了！

通过此次教训，我决心改变本身的管理方式。

我总结了一下，团队效率低下的主要缘由在于没有明确的目标感，致使你们最终失去了工做热情。因而我就想，若是把冗长的任务列表变成一个个可完成的小目标，会不会能让你们更有干劲儿呢？

随后，我开始将项目拆分红许多个小目标，每一个目标都单独安排计划，目标中的任务也很少，大概2周就能完成的量，而后一次只作一个目标，完成了再作下一个。经过这种方式，加强你们的目标感，让工做更聚焦。（以下图）

将项目划分为几个阶段目标，一次集中完成一个目标

尝试了这种新的管理方法后，一个月下来，我能明显感受到团队效率有所提高，你们更有干劲了，须要加班的状况也愈来愈少。

跟踪进展，及时调整目标

但随之又产生了新的问题：

因为制定计划时每一个任务的工时都是预估的，加上有紧急bug须要修改的状况，或是用户反馈须要尽快解决这种突发性事件，很难保证目标能够按原计划完成。

为了让目标可以按时完成，我天天早上到公司，都会先开20分钟左右的站会，总结一下前一天的工做，同时制定当天的工做计划。

一方面，明确每一个人当天的工做内容，让你们的工做目标保持一致；另外一方面，根据目标的进展状况及时调整计划内容，确保计划的可完成性。尤为是在前期，你们对预估工做量都不太熟练的状况下，更须要及时调整目标。

若是不管如何目标中的任务都没有作完，我也会结束掉这个目标，将未完成的任务移至下个目标中。

至于为何不惜移动任务，也要将目标结束，这个我后面再说。

首先我要解决如何制定当天工做计划的问题。

前面我提到，开早会时很重要的一部份内容就是明确每一个人的当天工做内容。固然，明确不能只是嘴上说，管理是须要落到笔头上的，必定要有记录。

但问题是，在自己已经有了一层目标计划的前提下，如何在计划中再作一层计划？并且，管理层级过深的话 ，查看起来也不方便。

这着实困扰我好久，直到采用列表+看板切换的方式，我才将这个问题解决。

我在列表中将目标计划制定好以后，按流程将看板分为待处理、进行中、已完成三个任务栏。目标下全部任务先分配到“待处理”中，早会时，我会将你们当天要作的任务统一拖入“进行中”。

这样作有两个好处：对于我来讲，列表模式更方便添加任务，制定目标计划；而对于执行的人来讲，看板模式让他们只需关注“进行中”的任务就好，不会被目标中的其余任务所干扰。

选择当天要完成的任务，拖入“进行中”

但这个方法有一个局限。

对于列表和看板两种模式都支持的工具，适应性会很好；若只有看板，加上目标管理也能够用，但制定计划时体验性稍差；若是只有列表模式，因为自己层级太深，不建议用此法。

别把bug和任务放在同一个“篮子”里

另一个比较难解决的问题，就是bug管理。

之因此说它难，是由于产生bug这件事自己是不可控的。就像打地鼠游戏同样，你不知道它们会在何时蹦出来，也不知道一下会蹦出多少来，你还不能不理，不然它跟你玩game over。
所以，开发人员常常得放下手头工做去处理这些活蹦乱跳的“地鼠”，这很是影响进度。
要解决这个问题，我就得避免将bug与任务放在一块儿，不然天天都有新bug进入当前目标，我就永远也别想完成它了。

我通常会将bug与计划分不一样的项目管理。测试先将bug记录在单独的项目中，标记一下bug的紧急程度，回头由我来决定哪些bug能够进入到当前目标中优先处理。

在制定目标时，我也会预留出1到2天的时间，专门处理突发事件和bug，具体时间要看实际的bug产出量和紧急程度而定。

将须要修改的bug添加到开发计划中

有时候会出现这种状况，直到产品上线，项目中还会有上百条bug没有解决。

其实这是很正常的状况，我不会妄想将bug都处理完，由于bug是永远处理不完的，只要保证它们不会影响功能和稳定性，那么这个产品自己就是健康的。

这也是bug单独管理的另一个缘由，避免被这些“场外因素”打扰。

确保目标必定要完成

最后咱们来讲一说，为何目标必定要完成这个问题。其实写到这里，你们已经可以发现，上面写的这些内容，都是为了达成一个目的：完成目标。

你们可能会问，为何不惜调整计划也必定要保证目标完成呢？

其实缘由很简单：只有团队目标按时完成了，你们才能把目标当作切实的标准去看待。

虽然一开始，因为目标任务量设定不够合理，或是bug产出过多，可能会致使一些任务没法完成。但只要坚持下去，你就会发现，目标制定会愈来愈合理，遗留的任务愈来愈少，完成的目标愈来愈多。它会由一种仪式变成一个标准，你们在完成任务时会不断产生成就感，让你们专一于眼前的目标，并将这种高效的工做状态一直保持下去。

如此，节奏感就天然而然创建起来了。