产品迭代中的节奏感

小胖之前说过自己公司是使用的敏捷这种工作方式，一般是以两周为一个迭代，通过这两周时间就可以完成出需求、开发、测试、上线、验收等全流程。

但是最近的一个迭代，持续了几乎有三周，才踉踉跄跄的上去线，真的是上了一个好长的线。之所以如此，肯定是哪里出现了问题，所以团队内部也进行了一次小胖之前跟大家介绍过的复盘。

小胖也看到了一些问题，也对这些问题背后的原因做了一些思考，这些问题或许也是胖友们经常会遇到的问题，可能会对你有所启发。

这次复盘会中大家提出的问题可以分为两类：其一是关于需求，其二是关于时间。而这两者又是相互作用的。

大家会觉得时间紧，是因为需要做的事情太多了，但是这些做的事情中，有很多都是可以不用做的，换言之就是大家做了很多无用功，而这些无用功占用了大家的太多时间，进而留给那些真正的需求的时间就很有限了。

那么为什么会做很多无用功呢？开发自己写出来的 bug 都还好说，关键是业务流程的不确定性，甚至是错误性，以及需求频繁的变更，而这些不确定性以及错误性都源于需求，到开发手里的需求都似是而非，很多问题都是在开发的过程中才慢慢发现，才被提出来，这滞后性是很可怕的。

那么需求为什么会有那么多不确定性以及频繁的变更呢？是因为一开始产品就没想好，这份需求在产品团队内部就没有达成一致性，所以才会出现都上线了一版，产品负责人说这个流程有问题，如果内部早点跟这位负责人过这个需求，这种问题出现的概率就会被降到最低。

但是产品为什么没有在产品团队内部达成一致呢？为了将需求尽快的出出来，跟开发测试过，进而尽快的上线，那么留给产品自己细化需求的时间，在产品内部达成一致的时间就被进一步压缩，所以在一开始就过的很仓促，那出现不确定性，甚至错误，肯定就在所难免了。

以上的问题看起来貌似都是时间问题，好像每一环节都在求快，产品想尽快的把需求给到开发，开发想尽快的开发完给到测试，测试想尽快的测试完毕上线。可是这份快最终导致的结果就是比平时还慢了。

不过在小胖看来，这一切问题背后都是产品迭代节奏出了问题。以上的环环相扣，最终都成了死循环。在不断求快的过程中，出现的错误越来越多，导致的结果就是越来越慢。

那么该如何调整这个节奏呢？必须得从源头入手了，我们都知道任何问题都应该在最早的环节在最上游被发现，而不是在执行的过程中，甚至是到了下游才被发现，因为越往后去犯错的成本越高。

产品方是最开始的那一环，如果在那一环都犯了错，那么依赖它的开发、测试、UI 等等都会跟着错，所以产品犯错的成本是很高的。那么如何减少产品犯错的概率，如何降低交到开发手里的需求的不确定性呢？似乎就是给产品更多的时间，让他们去达成一致性。

这里的一致性首先是产品团队内部的一致性，产品团队内部各个成员对这个需求的理解一致，特别是产品负责人认可出的这个需求，而不是在到了开发测试过程中才过去指指点点，对于老板更是如此了，因为可能大佬只是动动嘴，下面的人可能都要忙活好几天，这个成本非常高。

一致性当然还包括，跟外部也就是外部依赖方的一致性，包括对方系统联调上线的时间等等，既不能人家做好了，让人家等着我们，也不能我们做好了，而因为对方没做好，我们上不了线。所以只有在这些一致性都达成的情况下，才可以对团队内的开发测试等同学进行需求的讲解，因为至少到了这一步，需求是相对确定的。

第二点就是要做减法，要学会砍需求，只去做那些确定的事情。不确定的事情，不要交给开发做，因为这些不确定性，很可能造成开发做了很多无用功。其实，大家不是怕很忙，怕的是忙的没有价值，一直都在忙着做无用功。

如果产品能够把需求出的确定，减少一些后续的确认环节，留给开发测试的时间更多一些，那么上线后的问题也会少一些，整体的开发迭代节奏也会好起来。

否则的话，团队总是要把本该上个迭代该做完毕的事情，被迫拖到了下个迭代，那就会导致把这个迭代做事情做的仓仓促促，又会出现错误，进而形成恶性循环。

敏捷这种工作方式跟传统的瀑布流工作方式比的确会快，但是快只是它的结果，而不是它追求的目标，敏捷更多的还是为了快速响应变化，以小步快跑的方式进行产品迭代。

如果在做产品的过程中，节奏把握不好，每个人都会被搞得身心俱疲，并且产出很低，而在生活中亦是如此。

每个人的生活都会有自己的节奏，也该有自己的节奏。节奏正常，一天下来都会觉得很轻松，会有一切尽在掌控之中的感觉，而节奏一旦混乱，很可能会导致事事不顺，因为这都是环环相扣的，前面的都会影响后面的。

如果说上面的是一天天的小节奏的话，那么我们每个人的大节奏也是如此，我们每个人都应该以适合自己的节奏在向前走，而不是说到了一个什么时间点该做什么事情，因为很可能一步走错，步步走错。

关于节奏感的事情，到这里小胖就说完了，有问题欢迎留言讨论。

胖友们，周末愉快，晚安。