产品开发的本质
根据第一性原理思维，可以得出产品开发的本质即：“高效、高质量地交付有用的价值”[1]。那么从这句话可以推导出四个需要解决的命题，即：
1 | |
此外，在软件产品开发过程中除了面临确定性复杂度之外还经常面临不确定性复杂度，不确定性的复杂度比确定性的复杂度更难解决，更容易引起焦虑，更容易带来团队熵增，也更容易造成软件开发交付的失败。因此，为了简单有效地解决这四个命题以及其所自带的复杂度问题，结合精益产品理论，本文提出一种从实战中总结出来的“极简精益产品开发法”。需要额外说明的是，本方法论还有两个约束条件：
本方法论仅适用于以搞生产力为主而非以搞生产关系为主的企业、部门、团队或个人；
本方法论仅适用于“The two pizza team”，即小于10人的小团队或单兵作战能力很强的个体，比如10倍工程师；
极简精益产品开发法
为了简单有效地解决“需要交付的价值是什么？如何判断什么是有用的价值？如何高效地交付？如何高质量地交付？” 这四大命题以及软件开发所面临的确定与不确定复杂度，这里采用结构化的方法提出的极简精益产品开发思维模型，其涵盖五大原则与三大基石，即：
- 五大原则：以终为始，架构先行，有拆有合，迭代更新，相关满意
- 三大基石：领域能力，企业文化，组织到位
本极简精益产品开发法思维模型导图如下：
在极简精益产品开发法思维模型里，“领域能力、企业文化、组织到位”属于基石的范畴，三大基石不到位，则产品开发与交付的原则与行动无效。在五大原则里，“以终为始”是为了解决“判断需要交付的价值是什么？如何判断什么是有用的价值？”这两个问题，“架构先行，有拆有合，迭代更新，相关满意”是为了解决如何高效地交付，如何高质量地交付以及如何解决软件开发的确定性与不确定性复杂度。
五大原则
以终为始
“以终为始”是一种逆向思维，在软件开发里的应用指的是从最终的交付价值出发，反向推理交付过程，寻找软件开发的关键要素，获取反馈采取正确的策略，从而达成有用的价值交付。如下图所示，从未来的终局看现在，使用获取的未来信息强化现在的行为，赋予现在的行为以塑造未来的力量。
“以终为始”是确保正确地做事以及做的是正确的事的一种思维方式，在进行软件开发之前就进行了从交付结果开始的倒推分析，从交付结果得出开发的方向与方案。这里以“逆向工作法”以及“客户导向法” 为例说明软件开发过程中 “以终为始”思维的使用。
逆向工作法
逆向工作法是亚马逊所推崇的商业新哲学，因为产品最终的交付要“以客户为中心”，那就先从客户侧开始倒推开发，逆向工作法有助于一开始就把重心放在客户所真正关心的问题上，而不是一堆程序员坐在办公室内拍脑袋替客户做假想，进而避免一些无效的开发决策，使得确保推出的是有用、有价值、用户体验佳的产品。
拆解这个概念为具体的行动，亚马逊讲述了这个思维方式的应用步骤[4]：
1，先写一篇内部用的产品新闻稿，简单描述一下这个产品的特点与好处是什么，是为了解决什么痛点而产生，然后描述具体的问题，拿出一个新的解决方案，虚构一个用户的心声，设身处地为用户着想，然后发出来给内部同事，经过审核的也可以外发给公众；
2，写一个常见的FAQ问题文档，定义产品的用途以及考虑用户使用时会遇到的问题以及回答如何解决，FAQ需要包含外部客户会问的问题以及内部用户会问的问题；
3，定义客户体验，详细描述客户使用产品时会遇到的使用场景。比如用户界面是怎么样的，软件部署是怎么部署的，软件的技术架构图是怎么样的，先给客户一个能够呈现端到端体验的假象视图；
4，编写用户手册，用户手册是客户用来真正了解产品是什么以及如何使用它的，用户手册通常有三个部分：概念、操作方法和参考，它们之间告诉用户使用产品所需的所有知识。,
5，获取反馈，以上内容完成后，获取用户/客户反馈，然后在产品的生命周期中，不断迭代而演化产品的开发交付文档。
逆向工作法的目的是为了明白真正的用户/客户是谁，用户/客户的真实需求是什么，用户/客户的需要最先解决什么痛点等，而且以上步骤也只是一种应用方案，目的一致则无需拘泥于形式，只要思路和效果可以达到有效理解客户的目的即可。
客户导向法
客户导向法讲的是“先有客户再有产品与技术”， 详细可以参考《第25式- 让技术回归常识,先有客户再有技术》，其理念上与逆向工作法类似，不同之处在于 逆向工作法是具体的行动，而客户导向法是认知上的提升。在这里，需要先定义什么是客户以及什么是客户价值：
- 什么是客户？狭义的客户 = 买单的，广义上的客户 = 客户的客户 + 客户 + 客户的用户 + 所有相关方；
- 什么是客户价值？客户价值就是对客户有用的东西，价值来源于价值的交换。技术的目的就是做对客户有用的东西，并且技术的进化方向是由市场所决定的。以客户为中心，就是给客户创造价值，替解决用户难点、痛点、挑战点、为客户提供高质量低成本的产品，同时响应要及时；
在产品开发上，软件开发人员常见的认知错误有：
- “我为用户想”，这是研发人员最容易犯的错，其已经有用户意识，但是却没有进一步与用户沟通，直接替用户做决定，也不清楚用户的使用场景，因此容易造成”所想“实际上并不是用户真正所想；
- 追求有挑战的技术而非技术的实用价值，也非从合适的解决用户问题的角度出发，将技术上的自嗨当成客户需求，比如用户需要从A地到B地，简单一点给用户一辆自行车就可以解决的问题，而技术自嗨就容易非要先自行造个飞机，然后拼命的给用户推销这个好这个快，但是用户却不买单；
- 闭门造车，不实事求是，不与客户做探讨，不做调查就把想象的或还处于概念上的东西当成客户需求，带来的是低效、低质量的产品开发过程；
因此，开发产品需要先关注客户价值，在实现一个产品之前先确定这个是对客户有价值的，与客户/用户多沟通、一起共创，在“客户要的与我能提供的”二者之间保持理解一致，避免无效开发与交付。
架构先行
架构投影
柏拉图在《理想国》中构建了他的哲学王国—理念世界，其把世界分成两个：“现象世界与理念世界，柏拉图认为这两个世界的关系是原本和慕本的关系，理念世界是原本、模型，现象世界是理念世界的影子或慕本”。基于此设想，产品架构可以是产品在现象世界的原本，通过产品架构可以看到产品的最终形态。在开发（编码）产品之前可以先定义软件产品的架构，给出产品的画像，提供产品的总体概要架构设计文档（注意这里概要设计文档即可，无需详细设计文档），设计文档内定义产品的设计哲学、设计原则、技术架构图、设计提案、所需要实现的功能特性、交付目标以及风险管理、用户操作等，然后发给团队一起评审，利用团队的力量避免交付的技术路线风险，同时为下一阶段的工作分解做准备。
架构思维
狭义上的架构通常指的是架构的技能，其属于“术”的范畴，而广义的架构则是客户需求、市场趋势、架构理念、架构方法论、架构技能、架构用的工具以及架构的边界这几个方面的组合体，应用抽象思维，即“势、道、法、术、器、界”这六个字 ，简称架构思维六元组，具体可以参考《第15式 - 架构思维》。
势：时势
“势”是架构的方向。从宏观处着眼，“势”是产品架构设计的市场趋势、是客户需求趋势也是技术的应用趋势；从微观处着手，“势”是功能设计的价值与目的。架构设计需要从宏观处着眼微观处着手，看清客户的需求趋势、市场趋势以及技术趋势，功能设计需要分析清楚当前功能的价值与目的。
道：本质
“道”是架构的认知，是架构师的设计理念、设计意图，是产品架构的灵魂，这里我把它定义为产品架构的设计哲学。
法：方法论
”法“是方法论，是架构设计的方法论，是架构设计的套路，这里我把它定义为产品架构的设计原则
术：技能
术，技能，是架构技能，这里定义为设计提案，以及各种功能与特性实现的思路
器：工具
”器“是工具，是架构设计用的工具，”工欲善其事必先利其器“，
界：边界
”界“是边界，是架构的约束限制，是技术边界、也是技术约束与技术限制，也是架构的取舍因素之一，是架构能做什麽不能做什麽的解读，对市场来说它是技术壁垒，对产品来说它是法律法规、是功能约束，对团队来说它是资源约束、是自我能力约束。
有拆有合
有拆有合指的是工作分解结构法，详细参考《第27式- 系统思考，分而治之 - 工作分解结构法》。基于“架构先行”这一步输出的概要设计进行工作分解，工作分解的结果可以直接影响了产品开发的效率与质量。
工作分解是个有拆有合的过程，一个大的工程任务往往是由很多的小个的任务组成的，如何将一个大任务拆解成合适的小任务，能将大任务拆解成什么样的小任务，能拆解到什么粒度，拆解是否准确，这是”拆“的过程。怎样对任务进行量化与质化，怎么将任务落地到具体的执行人员上，怎么进集成怎么验收，这是“合”。以下图的工作包分解表为例：
1，首先前三行定义了项目的目标、原则以及投入，说明了项目的交付目标、交付进度、交付的原则以及约束、还有确定了人力资源的投入；
2，任务分解成了一级任务、二级任务以及工作包、工作包名称，关键特性可以是具体需要实现的功能，也包括项目文档、测试部署、相关采购等；
3，除这些在任务树上也可以体现的内容外，还增加了 工作进展、状态、评论、风险、阶段目标、执行的人员、复杂度以及依赖条件；
4，输出最终交付成果。
工作包分解表可以使得团队协作更加顺畅，将不确定的大任务包分解成一个个确定的最小可执行工作包，是的开发工作从不确定到确定，有利于保证软件产品开发的效率与质量。
迭代更新
产品根据环境改变而迭代，根据反馈结果而更新。迭代更新其目的为了逐步逼近所需的最终目标，而每一次迭代更新得到的结果都会作为下一次迭代更新的初始输入。在不确定性较大的软件产品开发过程中，将产品开发分为迭代0、 迭代1、迭代2…..最终迭代目标这几个阶段，每个阶段的输出都是一个最小可行产品，即 MVP（Minimum Viable Product）。
如下图“10人以内小团队你极简精益产品开发法”所示：
1，迭代0，先完成信息输入，依据“以终为始、架构先行、有拆有合”的步骤完成客户目标确认、价值确定、需求分析、初版概要设计、初版工作拆解；
2，迭代1，进行软件开发，输出MVP1，依据“以终为始、架构先行、有拆有合”的步骤刷新客户目标、交付价值、客户需求、概要设计、进行二次工作拆解；
3，迭代2，进行软件开发，输出MVP2，依据“以终为始、架构先行、有拆有合”的步骤刷新客户目标、交付价值、客户需求、概要设计、进行三次工作拆解；
以此类推，逐步迭代更新，过程根据变化微调控保证方向正确，直至抵达最终交付目标。
相关满意
相关满意指的是项目相关方满意，项目相关方是会影响项目或受项目所影响的组织、团队或人员。项目相关方的参与是项目成功的前提与保证，没有项目相关方，也就没有项目，忽略任何项目相关方都可能导致项目的失败。项目的开启、过程以及结果都需要能令项目相关方满意。
达成项目相关方满意需要从以下4个方面进行迭代推进以支持项目团队的工作：
1，识别相关方，相关方一般包括需要知晓情况的用户、客户、供应商、合作第三方，需要通知到的项目批准人、项目负责人，负责具体执行的项目开发团队：项目经理、产品经理、架构师、领域专家、各级工程师、测试、采购，以及其他的组织内外的项目支持职能部门；
2，管理预期，准确识别相关方的需求和期望；
3，提出方案，依据”以终为始、架构先行、有拆有合、迭代更新“法输出满足相关方需求和期望的提案；
4，迭代更新确保事态向最终目标的方向逐步推进；
项目相关方满意的核心就是在所有的相关方的预期中取得一个彼此都接受的解。
三大基石
领域能力
领域能力狭义上指的是个人或团队所具备的相应专业能力，广义上指完成整个软件开发交付所需要的技能，包括产品思维能力、项目管理能力、架构设计能力、编码能力、测试能力、维护能力以及质量保证能力。领域能力是软件开发原则与行动的最重要的基石之一。没有对应的交付能力就不要谈什么产品开发原则与交付，比如一个拧螺丝的团队你非要他们在限定的时间内打造一根火箭，必然无法达成。
企业文化
企业文化是极简精益产品开发法的基石之一，其涵盖了使命，目标，制度，边界，奖罚等，属于软件开发团队运作、开发原则与产品交付的最底层的基础设施。企业的使命讲的是企业与世界的关系，这跟企业员工离的较远，姑且不谈。而目标讲的是员工与企业的关系，每年制定的企业发展目标属于企业的战略范畴，体现了企业的战略方向以及资源投入的方向，团队目标与企业目标保持一致，个人目标与团队目标保持一致，这是最基本的团队运作准则，如果个人或团队年度目标不与企业目标对齐，那么个人或团队也拿不到资源得不到发展。而企业制度、边界与奖罚是团队运作的保障，奖什么罚什么更是最明显的企业文化导向，这里就不作举例说明了。
组织到位
组织到位的第一个意思是：”组织结构影响产品结构“，组织基因即产品基因，依据康威第一定律：
1 | |
翻译成中文即：”组织设计的产品/设计等价于这个组织的沟通结构“，通俗的来讲：产品结构必然是其组织内成员沟通结构的缩影，比如微服务。
组织到位的第二个意思是：人员到位，人事匹配。进行软件产品开发一方面需要配备相应的能力需求的人员，另一方面也需要讲究合适的人放在合适的岗位上，合适的岗位需要合适的人选，人选对了，事就成一半。
自组织、自平衡与强管控
软件产品的开发过程除了是一个业务管理过程也是一个团队/个人管理过程，“极简精益产品开发法”更多讲的是业务管理的过程，然而团队/个人管理的成功与否也可以决定产品开发的成败。软件开发过程是一个复杂的系统过程，而业务与团队也是一个复杂系统，需要以系统化的思维而非线性思维来看待。团队能否有效的自我组织、自我驱动直接影响软件开发的效率与质量。
基于此，这里提出团队/个人的三个组织形态：自组织、自平衡与强管控，如下面的组织形态变化图所示，组织的形态变化有自组织、自平衡、强管控这三个形态，自组织态会过度到自平衡态，如果没有外力的干预作用，自组织态与自平衡态都容易滚落到强管控态，强管控态势能最低也是最稳定的最终形态。
在一定的企业文化以及组织架构下，每一个管理决策和管理措施的输出背后，都有一种人性假设，道斯·麦格里格（Douglas McGregor）的X-Y理论（Theory X-Theory Y）概括了对人性的根本性理解：X理论-人性本恶，Y理论-人性本善。中国古代也有儒家人性论之争，最具有代表的就是孟子的“人性本善论”和荀子的“人性本恶论”。
人性本恶论认为员工需要被强力控制与安排，员工都讨厌工作、工作的驱动力只是为了保住饭碗、对于工作能躲就躲，因此有了强KPI管理法，271、361、末位淘汰、设定严格的规则制度等，如上图所示，其“具有低势能稳定性的形态，但不会带来创新和竞争力”[1]；
人性本善论认为员工是能自我驱动的，愿意自我承担责任、积极向上、会自我以目标为驱动努力工作，因此有了OKR管理法、工作-生活平衡、对员工授权、人性激发、信任管理法等，如上图所示，其具有“高势能非稳定的状态，但确是激发创造力、提升效能的利器”[1]；
软件开发是一个创造性的脑力劳动，其并不适合以人性本恶论为出发点强管控管理法，但是高效率、高创造性的自组织形态却具有不稳定性的特征，因此需要微管控使之一直处于自平衡态，既保持自组织的高效能、高创造力的特性，又规避了强管控管理法带来的无创新、无竞争力、低效率的弊端。以上三种形态在一个大的组织结构内可能同时存在。
本文将方法论局限在“10人以内小团队” 也是为了更容易达到团队的自组织或自平衡态，使之保持团队的勇于担当、自管理、高效率、高质量输出、高创造力形态。
小结
本文提出了一种 “10人以内小团队极简精益产品开发法”，用以解决软件开发的复杂度问题以及需要解决的四个命题，即：需要交付的价值是什么？如何判断什么是有用的价值？如何高效地交付？如何高质量地交付？详解了“以终为始，架构先行，有拆有合，迭代更新，相关满意”这五大原则以及“领域能力，企业文化，组织到位”这三大基石，此外还论述了“自组织、自平衡、强管控”这三种团队组织形态。其目的都是为了使得团队/个人目标与组织目标保持一致并且“高效、高质量地交付有用的价值”。此外，作者能力与认知都有限，”我讲的，可能都是错的“，欢迎大家拍砖留念。
作者简介
常平，中科大硕，某AI独角兽深度学习首席软件工程师，前EMC 大数据资深首席工程师，主要工作背景在深度学习、流式大数据、云计算、分布式中间件以及Linux内核。
版权申明
本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh
在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。
参考资料
[1] 《精益产品开发：原则、方法与实施》 何勉著
[2] https://zhuanlan.zhihu.com/p/56556328
[3] https://www.cnblogs.com/yanglang/p/10270592.html
[4] https://www.allthingsdistributed.com/2006/11/working_backwards.html