本文来自微信公众号 ”产品人卫朋“，作者：卫朋，纷传经授权发布。

虚实结合，打造最强产品人

上到战略规划，中至运营策略，下至元器件选型，本号力图为读者呈现一整套的产品落地化打法。

随着移动互联网、软件即服务（SaaS）和基于云计算的快速发展，你需要加快你的产品开发周期，将重点工作放在定义核心功能集的前端。

你可以从敏捷软件开发思想中借鉴一些最佳实践，并将这些实践应用于团队管理中。

敏捷思想最开始是通过17位软件开发领导者合作编写的敏捷宣言（Agile Manifesto）脱颖而出的。

敏捷宣言提出了十二项敏捷原则，表达了敏捷开发的精神。 

随后，敏捷逐渐演变成为一套框架和实践，例如：Scrum、冲刺、每日站立会议、燃尽图等等。

但是，这些具体的实践对于敏捷来说并不是必须的。

敏捷是一组有利于授权团队的原则，这些团队被授予创新和创造满足客户需求的产品的自由。

相比传统开发模式，敏捷团队要具备更多的决策权。

敏捷发生在团队中，它更多是为了使团队更好地适应新信息，而不是执行预先制定的计划。

这就产生了一种方法：

管理团队与开发团队协作，实时快速地定义产品。

你可能会在4-6周内定义大型产品，并从组织中汲取最佳思维，让又快又好成为可能。

什么是敏捷管理看板图？

看板源于丰田生产系统和精益生产，是一种可视化流程管理系统。

主要描述团队在生产什么、何时生产及生产多少。

在敏捷方法中，看板（Kanban）是一个动态的管理工具，可以显示项目中每项工作的流动性，并且可以识别瓶颈。

看板也是一种信息发射源，用于展示信息，它要放置在团队成员路过就能看到的地方。

常见的看板类型有物理看板和电子看板：

• 物理看板易于创建，只需要一块白板或一面墙，利用物理看板可以将团队成员从工位拉离并形成所需的集会；

  
  

• 电子看板有随时可访问的显著优点，对于分布式团队特别有效，而且能将每项工作信息和相关讨论保存，使数据不丢失。

看板的作用是把整个开发流程可视化。

这种最佳实践提升了基于sprint开发方法的基本要素，并将其应用于产品开发的前端，也就是通常所说的概念或定义阶段。

尽管管理团队的代表（常说的客户代表）不是全职在开发中工作，但访问是广泛可用的。

冲刺过程是通过采用产品营销提出的一页纸概念定义来启动的，并由管理团队的代表（通常是营销副总裁或 CMO）塑造。

这将被带入与核心团队（4-6名，包括质量和用户体验）和管理团队（3-5名负责监督业务部门的 C 级经理）的工作会议中。

工作会议的结果是完善和扩展的产品概念描述。

这组要求分为三组：

• 候选：是那些尚未讨论的要求；

  
  

• 进行中：是那些已经提出但尚未完成（或缺乏完全同意）的要求；

  
  

• 已定义：团队开始着手处理开放的需求，并与客户代表一起迭代定义。

在第一次会议后不超过两周的时间里，团队重新聚在一起审查“候选”和“处理中”的要求，目标是在一两次会议中将所有这些都转换为“已定义”。

这个过程通常会再重复一次，然后项目就可以进入开发阶段了。

这种方法有什么好处？

创建引人注目的产品定义是任何企业都需要解决的最困难的任务之一，这种方法可以帮助提高速度和质量。

它提高了定义速度，因为开发和管理之间的紧密迭代循环减少了间隔时间的记忆损失。

此外，它设定了团队的时间限制与期望。

而且定义的质量更好，因为你拥有组织的集体智慧，而不仅仅是少数聪明人进行权衡。

此外，管理团队将倾向于引入更多的跨职能需求，从而确保定义“整体产品”，而不仅仅是核心功能集。

解决哪些业务问题？

这种方法最重要的好处是它可以帮助组织快速开发真正困难的平台程序。

它还具有为产品创建共同愿景的附加作用，当需要进行进一步权衡时，这确实有助于下游。

有哪些注意事项？

在给定的组织中实施该方法之前，应检查许多考虑因素。

这不能替代获得客户的声音，直接从客户（和渠道合作伙伴）那里收集需求非常有必要。

其次，这是资源密集型的，因此大多数组织会承受太多压力，无法让所有正在开发的程序都遵循这种方法。

在这种情况下，执行团队可能需要标记具有非常适合此方法的属性的程序（大范围、涉及子系统的平台、新的世界或公司的新程序）。

案例分析

一家最大的公司正计划在明年秋季推出新的员工评级和评估系统。

由 IT 项目负责人、人力资源经理和项目经理组成的设计团队在全国范围内举办了三场需求收集研讨会。

此外，他们还创建了“原样”和“未来”流程设计，并向管理层提出了一系列建议。

但在第三次管理审查和六个月的工作之后，他们似乎并没有比开始时更接近。

其中一家企业的负责人建议采用敏捷管理方法，因为他们看到它在帮助其部门进行产品开发方面非常有效。

这位业务部门的负责人同意成为团队的一员，而不是法官，并同意与设计团队密切合作。

在六周内，到第三次会议结束时，就项目的整体愿景达成了完全一致。

那时起草了一份工作声明，用于寻找软件供应商和集成合作伙伴。

项目定义阶段结束，正式开发阶段拉开帷幕。

IT 项目负责人将其描述为他所从事的任何项目中恢复最快的项目之一，并表示考虑到高层管理人员的参与，这些要求可能会坚持下去。

上表源自看板制造过程（准时制），在每个步骤的列中指示。

表中有三列及时显示给定快照的需求状态。

这是第一次定义会话后项目的快照：

• 第一列描述已知但未定义的要求；

  
  

• 第二列列出了那些已经讨论过但尚未完成的要求；

  
  

• 最后一列代表团队同意完成或完全定义的要求。

上面的图表显示了未定义需求随时间的进展或燃尽。

纵轴是未定义需求的数量，横轴是会话编号。

理想的图表将从左侧未定义的需求总数开始，然后在第三次会话时下降到零。

这让团队成员有进步感，并帮助他们尽快专注于完成质量定义。