“搬家”与产品研发管理

最近这段时间在搬家，昨天才搬完，搬完后躺床上复盘了一下，发现整个搬家过程和我们的产品研发管理的过程有很多相似点。本篇就基于个人的搬家经历来说说怎么样去做产品研发管理。

我们搬家的时间是半年前就定了 —— 因为租的房子到期了，必须在到期前搬家。也就是说Deadline 其实是定了的，有 Deadline 的好处很明显，那就是会基于这个时间点倒排计划，也就是我们说的“以终为始”，意味着到这个时间点时必须完成所有规划的工作内容。当我们定下来产品研发的阶段目标和截止时间点后，我们就可以基于目标和可用时间来协调资源、分解任务，并制定阶段性的成果（里程碑）。这样就把一个大的任务分解为多个小任务，一步一步按照计划朝既定目标前进。

比如我们搬家，就确定了什么时间搬什么东西，谁做什么，要不要请搬家公司。当然，对于搬家这件事，因为参与人不多，分工就简单很多了，更多是排计划。如果是产品研发，涉及的角色更多，因此基于 Deadline 的任务分解和排期需要更细致，否则很可能一两个环节出问题导致整个团队延期。

我们在工作过程也经常发现一种情况，就是当 Deadline距离现在较远的时候，总会觉得时间还很多，因此往往前期工作会拖沓，到了临近 Deadline 的时候又会紧张起来赶进度。这就是典型的“先松后紧”的情况。比如我们搬家也是一样，开始以为工作量不会那么多，整理东西也好、搬运也好，前期的节奏都比较松，包括请的货拉拉装车都没装满，然后到了搬家前3天才发现要搬的东西比自己想象的多很多。最后这几天，每天一大早开始搬（没有请搬家公司），然后都是到很晚才收工。结果就是最后几天感觉很疲累。

这种状态在产品研发过程也很常见，为什么临近发版上线的时候加班很密集，很多时候是前期的工作安排不够紧密。然后到了后期，加班多、人疲劳、产出还可能有质量问题（疲劳状态下很容易出现纰漏）。

我个人在工作中的习惯却是相反的，通常来说，领导安排任务下来后，我会确认交付的时间点，然后尽可能地提前完成 —— 给调整留出一定的时间裕量。因为，实际工作过程中我们会发现，即便是大家都认为自己的工作如期完成了，但是工作质量却未必能够让人满意。如果有时间来调整的话，我们的产研交付物的质量会更高。因此，相比“先松后紧”，显然“先紧后松”会更好。

怎么样“先紧后松”呢？一方面取决于个人工作方式和态度，更多的其实是制定计划的时候要设置合理的里程碑，分阶段交付和复盘，这样就能够将一个长的任务周期的工作饱和度安排得更均匀。

通常来说，产研团队里都是各自的 Leader 说了算，比如搬家过程中的具体安排基本上是我老婆定，我更多是做执行 —— 清理东西、搬运、开车。因为家里的东西她比我更熟悉，如果两个人都来参与决策的话，可能最后东西塞到哪些箱子里都不知道了，那样搬完后找东西又要花很长时间。但是，一定是要 Leader 说了算吗？

从大的方向来说，这个肯定是谁担责谁拍板，Leader 这个时候肯定是要去做决策的。但是，涉及到具体业务的时候，还是要给予团队成员参与的机会。毕竟，他们负责的板块他们更熟悉，也更有话语权。因此，如果是团队 Leader，设计具体业务的时候还是需要和团队成员商量，确定具体的方案和时间点。产品研发本身就有一部分的创造性的工作，如果仅仅是靠 Leader 拍板，一人说了算。一方面是决策上的不合理会导致交付质量差，后期返工；另一方面，降低团队成员的参与感，会让大家对事情本身缺乏热情，久而久之就是纯粹地做执行，导致大家对交付物质量不关心。比如，外包型团队很多时候对研发质量就不怎么关心，因为都是甲方说了算，项目的运营结果和他们没关系。

在这一点上，我自己的经验是，如果我拿不准的方案，我在设计产品前会先和负责这项工作的团队成员沟通。比如和后端沟通业务对象关系，和前端确定交互方式等等。这样提前沟通后再来做设计，产品和开发的配合会更好。千万不要抱着“怎么实现我不管”的心态去设计产品 —— 哪怕你是团队 Leader。

我们的产品会进行持续迭代，这一点和搬家不同，搬家通常来说搬完很长时间都不会再搬了。持续迭代并不意味着要“一路狂奔”，我们也应该试试停下来看看沿途的风景 —— 回顾过往的研发工作，总结经验，推广好的方式方法，改善不足， 这样整个团队的研发工作才能持续改进 —— 这也是研发团队迭代的一种很好的方式。

我们常说在生活中拾取经验，“纸上得来终觉浅，绝知此事要躬行”。当我们能够将生活中的经验应用到产品设计、团队管理过程中时，实际上也是一种模式的复制。同样的，我们也可以将产品设计的模型、方法论应用到生活中，也有可能会过得更好。

文中配图由 Midjourney 生成。