产品与敏捷研发

记得去年底在上家公司的时候，公司举办了一场针对产品经理的培训课程，那段时间我经常因为课程要往返成都与北京之间，不过也确实学到了一些东西，其中就包括敏捷研发与Kanban管理的相关知识。不过那会儿我即还没有开设自己的博客，况且所有相关的信息也都找不到了，所以权当从头来总结一遍吧。

说到敏捷研发，我们都知道敏捷研发的一个共同特点：先确定项目时间（就是我们说的项目周期），然后确定项目的参与人（人员大体不会发生变动），最后根据项目的需求来确定范围。

考虑到没有什么方法可以保证团队一定能开发出完美的软件（敏捷的团队也是同样），所以又专门制定了“敏捷12原则”来帮助团队进行更好的敏捷研发，这12条原则是这样的。

最优先要做的是尽早、持续地交付有价值的软件，让客户满意；
欣然面对需求变化，即使在开发后期。敏捷过程利用变化为客户维持竞争的优势；
频繁地交付可工作的软件，从数周到数月，交付周期越短越好；
在团队内外，面对面交谈是最有效，也是最高效的沟通方式；
在整个项目过程中，业务人员必须和开发人员每天都在一起工作；
以受激励的个体为核心构建项目。为他们提供所需的环境和支持，相信他们可以把工作做好；
可工作的软件是衡量进度的首要标准；
敏捷过程倡导可持续开发；
坚持不懈的追求技术卓越和良好的设计，以此增强敏捷的能力；
简单是尽最大可能减少不必要工作的艺术，是敏捷的根本；
最好的架构、需求和设计来自自组织的团队；
团队定期反思如何提升效率，并依此调整自己的行为；

此外，敏捷开发法又能够提供广泛的支持以适应不同的软件开发生命周期。有的专注于实践（例如，极限编程、务实编程，敏捷建模），而有的专注于管理工作流程（例如Scrum站会，看板）。有的支持需求规范和开发（例如FDD）的活动，而另一些则试图涵盖整个开发生命周期（例如DSDM，RUP）等等。

但是当我们回到“敏捷研发”的定义时，会发现一个问题：

“相对于‘非敏捷’，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。”

发现了吗？作为一种软件开发方法，敏捷研发这个概念其实更倾向于程序员们应该怎么做。程序员团队可以通过更高效且直接的方式与业务专家或客户进行沟通，从而提供更高效且专业的服务支撑。

那……产品经理呢？产品经理应该做什么？
你有考虑过这个问题吗？

其实如果回归到在某个项目或产品的生命周期中所需要经历的事情，这个问题也就不言自明了。

如果对项目或产品进行极致的抽象，一般会包含3部分流程，即定义需求，开发产品，部署上线。而对于这三部分过程来说，产品经理主要会处理这些问题。

定义需求

在任何项目或产品开始之前，我们都需要弄清楚，到底要开发什么产品。而在敏捷方法中，最让人担忧的也是产品经理能否代替现场客户的作用，研发成员在与最终用户取得联系这一过程是否能够被产品经理所替代。产品经理必须要通过研究目标用户、理解用户需求、洞察使用环境与使用习惯，才能发挥自己最大的作用。

在敏捷研发中心有倡导的所谓“极限编程方法”，其实是针对定制化软件项目提出来的，仅为了满足特定客户的特定需求（比如内部的OA系统，考勤系统或者薪资系统），这种方法并不适用于通用产品。况且，如果你去搜索那些描述极限编程方法的图书或方法论，很少会有提及如何设计产品管理或界面设计的文章。

此外，对于最终提供给用户使用的产品来说，UI与UE都至关重要，如果缺失了产品经理这一角色来设计产品，也需要专业的设计师来进行补充。

开发产品

对于开发产品这个过程而言，研发人员可能更愿意花费时间讨论使用何种“可扩展、高性能、可靠、易维护”的框架以及技术，讨论开发和测试软件的最佳方法与实例这一过程确实在产品经理的职责之外。

但产品经理仍然可以通过参与设计用户故事来了解或参与这一环节。

部署上线

常理来说其实部署上线，甚至产品测试，发布过程都与产品经理没有多大关系。而在产品上线之后，成为能够沟通研发与用户之间信息的桥梁，我认为非产品经理不可代替。对于研发同学而言，线性的逻辑与缺失用户属性与使用场景的问题确实很常见，而通过将产品管理、产品设计、质量保证进行串联的结合，确保团队所开发的产品能够为用户使用或认可。才能够被称作一款优秀的产品。