产品团队业务思维的重要性

最近一直在和一个产品团队工作。由于产品的交付压力，从不同项目团队调集了人员加入当前产品开发。让不同风格的团队在短时间内快速融合，一起合作面临了一些有趣的挑战。今天想分享一些在这其间的一些感受。

团队对于需求的态度

项目团队对于需求的态度，一般会有如下：

• Product Owner/BA 要求如何做就如何做，除非技术实现复杂，否则基本都可以实现。

• 严格按照 Design 图来做，越细节越全面越好。

• 不接受一句话需求。

产品团队对于需求的态度，一般会如下：

• 喜欢通过和 Product Owner 讨论需求，来明确需求。

• Design 图仅用于理解需求。如果有更好的想法会不吝啬提出来。

• 不畏惧一句话需求。

项目团队这种风格并不奇怪，因为主要他们是在项目中工作，每一个项目都是客户为中心，要严格按照客户的要求实现需求，所以会比较依赖 BA 和需求文档的前期分析，明确细化后，团队只需要严格执行就好。在这个过程中往往详细的 Hi-Fi Design 也是一并要发给客户确认的。整个团队对于变更更加封闭一些，大家更喜欢一切明确稳定。因为在固定时间的项目中任何不确定性都会带来风险。此外项目团队一般也没有过长的延续性，项目结束就会奔赴另一个项目，在这个工作模式下的团队几乎没有太多的思考的空间和意愿。产品团队有明显的不同，因为产品团队要和产品的生命周期保持一致，所以产品会和每个人紧密相连。大家更愿意在一起为产品的发展建言献策，对于需求，大家会保持开放的心态，拿到需求的时候大家更关注需求对应的问题，这些为题为什么会困扰用户，从而思考解决方案。团队也不在意 Design 是否是 Hi-Fi 还是 Low-Fi，从投入产出比来说，甚至一个手绘图能说明问题、让大家理解一致就够了。在这种场景下的团队，有时候更喜欢一句话需求，因为这种场景下团队的思考空间会更大，可以尝试更多的可能性。

任务拆分的方式

传统项目如果是按照瀑布方式，那么团队拿到详细设计后，只需要按照项目的交付时间，结合团队的实际情况反推一些关键里程碑，最后每个里程碑之前拆分子任务来执行。这个时候很容易采用专业度高的团队分工模式，例如前台任务、后台任务、数据库、最后前后台连调等。

产品研发或者敏捷项目开发会有些不同，因为每次团队交付是按照迭代来进行。而每次迭代最后如果要做一个评审，就需要有可以交付的内容。传统项目的交付一般是在项目末期，至少 2 周～4 周的迭代周期内达到这个要求，团队会觉得压力很大。加之按照分工横向拆分的任务，在各个部分连调组装起来之前，很难给拿出端到端的一个展示。

产品团队会更喜欢理解需求后将任务拆分成一条主线任务和多条辅助任务线。例如：一个需求是在系统中所有 PeoplePicker 中支持对组的选择和操作。那么主线任务就是将组的信息能够显示在 PeoplePicker 中，同时支持选择后的添加和删除操作。而辅助任务就可以是支持排序、搜索、条件过滤，表格中分类显示等。

产品团队的拆分方式让任务都可以作为端到端的交付来实现，同时任务也有优先级，主线任务肯定是优先实现，而之后辅助任务根据剩余迭代时间可以选择只做几个或者根本不做。毕竟解决客户实际需求问题是主线任务，辅助任务更多是锦上添花。

如何让团队转变思维方式

如何让团队从项目思维转向产品思维呢？下面是我实际的一些实践和感受：

• 从业务需求入手，让团队关注需求的根本问题域，而不要一开始就是技术实现。个人比较喜欢验收测试驱动开发（ATDD）的方式来引导团队转换思维方式。下面有几篇我之前分享的 ATDD 相关文章，有兴趣的可以阅读。《一次ATDD的团队实践》,《ATDD的小妙用》。

• 有时候团队对于交付标准的理解并不一致，研发只关注开发完成，而不关注测试的时间和工作量。所以迭代之内能够交付的工作内容有时候会把握不好，承诺过多。团队一同制定完成标准（DoD），并达成一致。会有促使团队在迭代周期内进一步拆分任务，因为要达到 DoD 的承诺，团队需要更加谨慎。这里有一个小 Tips，如果处于传统研发模式到敏捷模式转型的团队，可以先形成一个团队契约，对团队内部如何工作、DoD/DoR 的要求等达成一致，提高沟通效率。

• 单件流让团队习惯完成一条任务之后再开始新的任务，减少并行任务，降低单个成员在多任务之间的切换。让团队更加关注产出的质量和价值，而不是数量。降低返工率，从而提高效率。这一条需要一些时间让团队来接受。同时也需要结合 DoD 以及团队契约，让研发放慢脚步，关注质量。真正做到“Stop Starting，Start Finishing”。

总结

团队技术过硬固然重要，不过产品思维对研发团队来说也是必不可少的一个关键要素。产品研发是一个创造性的知识工作，而不是简单的重复劳动。激发团队的主动思考能够事半功倍，找到更合理的主线功能来优先实现。同时业务讨论能让更多的人员参与，因为使用业务语言，Product、QA、研发、Designer 都可以参与讨论了，从不同的视角让大家对问题域和解决方案域进行讨论和对齐。最后的产出物 AC 可以用作测试和验收的 Case 直接使用，为提高产品质量和价值作出贡献。

践行敏捷实践，让工作变得更美好。欢迎给我留言，交流落地经验。

【我的个人博客】