产品开发的本质

根据第一性原理思维,可以得出产品开发的本质即:“高效、高质量地交付有用的价值”[1]。那么从这句话可以推导出四个需要解决的命题,即:

1
2
3
4
1,需要交付的价值是什么?
2,如何判断什么是有用的价值?
3,如何高效地交付?
4,如何高质量地交付?

此外,在软件产品开发过程中除了面临确定性复杂度之外还经常面临不确定性复杂度,不确定性的复杂度比确定性的复杂度更难解决,更容易引起焦虑,更容易带来团队熵增,也更容易造成软件开发交付的失败。因此,为了简单有效地解决这四个命题以及其所自带的复杂度问题,结合精益产品理论,本文提出一种从实战中总结出来的“极简产品开发法”。需要额外说明的是,本方法论还有两个约束条件:

  • 本方法论仅适用于以搞生产力为主而非以搞生产关系为主的企业、部门、团队或个人;

  • 本方法论仅适用于小团队或单兵作战能力很强的个体,比如10倍工程师;

极简精益产品开发法

为了简单有效地解决“需要交付的价值是什么?如何判断什么是有用的价值?如何高效地交付?如何高质量地交付?” 这四大命题以及软件开发所面临的确定与不确定复杂度,这里采用结构化的方法提出的极简产品开发思维模型,其涵盖五大原则与三大基石,即:

  • 五大原则:以终为始,架构先行,有拆有合,迭代更新,相关满意
  • 三大基石:领域能力,企业文化,组织到位

本极简产品开发法思维模型导图如下:

在极简产品开发法思维模型里,“领域能力、企业文化、组织到位”属于基石的范畴,三大基石不到位,则产品开发与交付的原则与行动无效。在五大原则里,“以终为始”是为了解决“判断需要交付的价值是什么?如何判断什么是有用的价值?”这两个问题,“架构先行,有拆有合,迭代更新,相关满意”是为了解决如何高效地交付,如何高质量地交付以及如何解决软件开发的确定性与不确定性复杂度。

五大原则

以终为始

“以终为始”是一种逆向思维,在软件开发里的应用指的是从最终的交付价值出发,反向推理交付过程,寻找软件开发的关键要素,获取反馈采取正确的策略,从而达成有用的价值交付。如下图所示,从未来的终局看现在,使用获取的未来信息强化现在的行为,赋予现在的行为以塑造未来的力量。

“以终为始”是确保正确地做事以及做的是正确的事的一种思维方式,在进行软件开发之前就进行了从交付结果开始的倒推分析,从交付结果得出开发的方向与方案。这里以“逆向工作法”以及“客户导向法” 为例说明软件开发过程中 “以终为始”思维的使用。

逆向工作法

逆向工作法是亚马逊所推崇的商业新哲学,因为产品最终的交付要“以客户为中心”,那就先从客户侧开始倒推开发,逆向工作法有助于一开始就把重心放在客户所真正关心的问题上,而不是一堆程序员坐在办公室内拍脑袋替客户做假想,进而避免一些无效的开发决策,使得确保推出的是有用、有价值、用户体验佳的产品。

拆解这个概念为具体的行动,亚马逊讲述了这个思维方式的应用步骤[4]:

1,先写一篇内部用的产品新闻稿,简单描述一下这个产品的特点与好处是什么,是为了解决什么痛点而产生,然后描述具体的问题,拿出一个新的解决方案,虚构一个用户的心声,设身处地为用户着想,然后发出来给内部同事,经过审核的也可以外发给公众;

2,写一个常见的FAQ问题文档,定义产品的用途以及考虑用户使用时会遇到的问题以及回答如何解决,FAQ需要包含外部客户会问的问题以及内部用户会问的问题;

3,定义客户体验,详细描述客户使用产品时会遇到的使用场景。比如用户界面是怎么样的,软件部署是怎么部署的,软件的技术架构图是怎么样的,先给客户一个能够呈现端到端体验的假象视图;

4,编写用户手册,用户手册是客户用来真正了解产品是什么以及如何使用它的,用户手册通常有三个部分:概念、操作方法和参考,它们之间告诉用户使用产品所需的所有知识。,

5,获取反馈,以上内容完成后,获取用户/客户反馈,然后在产品的生命周期中,不断迭代而演化产品的开发交付文档。

逆向工作法的目的是为了明白真正的用户/客户是谁,用户/客户的真实需求是什么,用户/客户的需要最先解决什么痛点等,而且以上步骤也只是一种应用方案,目的一致则无需拘泥于形式,只要思路和效果可以达到有效理解客户的目的即可。

客户导向法

客户导向法讲的是“先有客户再有产品与技术”,其理念上与逆向工作法类似,不同之处在于 逆向工作法是具体的行动,而客户导向法是认知上的提升。在这里,需要先定义什么是客户以及什么是客户价值:

  • 什么是客户?狭义的客户 = 买单的,广义上的客户 = 客户的客户 + 客户 + 客户的用户 + 所有相关方;
  • 什么是客户价值?客户价值就是对客户有用的东西,价值来源于价值的交换。技术的目的就是做对客户有用的东西,并且技术的进化方向是由市场所决定的。以客户为中心,就是给客户创造价值,替解决用户难点、痛点、挑战点、为客户提供高质量低成本的产品,同时响应要及时;

在产品开发上,软件开发人员常见的认知错误有:

  • “我为用户想”,这是研发人员最容易犯的错,其已经有用户意识,但是却没有进一步与用户沟通,直接替用户做决定,也不清楚用户的使用场景,因此容易造成”所想“实际上并不是用户真正所想;
  • 追求有挑战的技术而非技术的实用价值,也非从合适的解决用户问题的角度出发,将技术上的自嗨当成客户需求,比如用户需要从A地到B地,简单一点给用户一辆自行车就可以解决的问题,而技术自嗨就容易非要先自行造个飞机,然后拼命的给用户推销这个好这个快,但是用户却不买单;
  • 闭门造车,不实事求是,不与客户做探讨,不做调查就把想象的或还处于概念上的东西当成客户需求,带来的是低效、低质量的产品开发过程;

因此,开发产品需要先关注客户价值,在实现一个产品之前先确定这个是对客户有价值的,与客户/用户多沟通、一起共创,在“客户要的与我能提供的”二者之间保持理解一致,避免无效开发与交付。

架构先行

架构投影

柏拉图在《理想国》中构建了他的哲学王国—理念世界,其把世界分成两个:“现象世界与理念世界,柏拉图认为这两个世界的关系是原本和慕本的关系,理念世界是原本、模型,现象世界是理念世界的影子或慕本”。基于此设想,产品架构可以是产品在现象世界的原本,通过产品架构可以看到产品的最终形态。在开发(编码)产品之前可以先定义软件产品的架构,给出产品的画像,提供产品的总体概要架构设计文档(注意这里概要设计文档即可,无需详细设计文档),设计文档内定义产品的设计哲学、设计原则、技术架构图、设计提案、所需要实现的功能特性、交付目标以及风险管理、用户操作等,然后发给团队一起评审,利用团队的力量避免交付的技术路线风险,同时为下一阶段的工作分解做准备。

架构思维

狭义上的架构通常指的是架构的技能,其属于“术”的范畴,而广义的架构则是客户需求、市场趋势、架构理念、架构方法论、架构技能、架构用的工具以及架构的边界这几个方面的组合体,应用抽象思维,即“势、道、法、术、器、界”这六个字 ,简称架构思维六元组,具体可以参考《第15式 - 架构思维》。

势:时势

“势”是架构的方向。从宏观处着眼,“势”是产品架构设计的市场趋势、是客户需求趋势也是技术的应用趋势;从微观处着手,“势”是功能设计的价值与目的。架构设计需要从宏观处着眼微观处着手,看清客户的需求趋势、市场趋势以及技术趋势,功能设计需要分析清楚当前功能的价值与目的。

道:本质

“道”是架构的认知,是架构师的设计理念、设计意图,是产品架构的灵魂,这里我把它定义为产品架构的设计哲学。

法:方法论

”法“是方法论,是架构设计的方法论,是架构设计的套路,这里我把它定义为产品架构的设计原则

术:技能

术,技能,是架构技能,这里定义为设计提案,以及各种功能与特性实现的思路

器:工具

”器“是工具,是架构设计用的工具,”工欲善其事必先利其器“,

界:边界

”界“是边界,是架构的约束限制,是技术边界、也是技术约束与技术限制,也是架构的取舍因素之一,是架构能做什麽不能做什麽的解读,对市场来说它是技术壁垒,对产品来说它是法律法规、是功能约束,对团队来说它是资源约束、是自我能力约束。

有拆有合

有拆有合指的是工作分解结构法,基于“架构先行”这一步输出的概要设计进行工作分解,工作分解的结果可以直接影响了产品开发的效率与质量。

工作分解是个有拆有合的过程,一个大的工程任务往往是由很多的小个的任务组成的,如何将一个大任务拆解成合适的小任务,能将大任务拆解成什么样的小任务,能拆解到什么粒度,拆解是否准确,这是”拆“的过程。怎样对任务进行量化与质化,怎么将任务落地到具体的执行人员上,怎么进集成怎么验收,这是“合”。以下图的工作包分解表为例:

项目

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
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

翻译成中文即:”组织设计的产品/设计等价于这个组织的沟通结构“,通俗的来讲:产品结构必然是其组织内成员沟通结构的缩影,比如微服务。

组织到位的第二个意思是:人员到位,人事匹配。进行软件产品开发一方面需要配备相应的能力需求的人员,另一方面也需要讲究合适的人放在合适的岗位上,合适的岗位需要合适的人选,人选对了,事就成一半。

自组织、自平衡与强管控

软件产品的开发过程除了是一个业务管理过程也是一个团队/个人管理过程,“极简精益产品开发法”更多讲的是业务管理的过程,然而团队/个人管理的成功与否也可以决定产品开发的成败。软件开发过程是一个复杂的系统过程,而业务与团队也是一个复杂系统,需要以系统化的思维而非线性思维来看待。团队能否有效的自我组织、自我驱动直接影响软件开发的效率与质量。

基于此,这里提出团队/个人的三个组织形态:自组织、自平衡与强管控,如下面的组织形态变化图所示,组织的形态变化有自组织、自平衡、强管控这三个形态,自组织态会过度到自平衡态,如果没有外力的干预作用,自组织态与自平衡态都容易滚落到强管控态,强管控态势能最低也是最稳定的最终形态。

在一定的企业文化以及组织架构下,每一个管理决策和管理措施的输出背后,都有一种人性假设,道斯·麦格里格(Douglas McGregor)的X-Y理论(Theory X-Theory Y)概括了对人性的根本性理解:X理论-人性本恶,Y理论-人性本善。中国古代也有儒家人性论之争,最具有代表的就是孟子的“人性本善论”和荀子的“人性本恶论”。

人性本恶论认为员工需要被强力控制与安排,员工都讨厌工作、工作的驱动力只是为了保住饭碗、对于工作能躲就躲,因此有了强KPI管理法,271、361、末位淘汰、设定严格的规则制度等,如上图所示,其“具有低势能稳定性的形态,但不会带来创新和竞争力”[1];

人性本善论认为员工是能自我驱动的,愿意自我承担责任、积极向上、会自我以目标为驱动努力工作,因此有了OKR管理法、工作-生活平衡、对员工授权、人性激发、信任管理法等,如上图所示,其具有“高势能非稳定的状态,但确是激发创造力、提升效能的利器”[1];

软件开发是一个创造性的脑力劳动,其并不适合以人性本恶论为出发点强管控管理法,但是高效率、高创造性的自组织形态却具有不稳定性的特征,因此需要微管控使之一直处于自平衡态,既保持自组织的高效能、高创造力的特性,又规避了强管控管理法带来的无创新、无竞争力、低效率的弊端。以上三种形态在一个大的组织结构内可能同时存在。

本文将方法论局限在“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

[5] https://www.sohu.com/a/299920333_263553

1. 前言

在一个软件工程项目组里有四种角色特别重要,即:架构师、领域专家、产品经理以及项目经理,在一个比较大的项目里或者大公司大部门里,这四类角色一般分别对应四个人,然而在中小型项目里,特别是创业型公司或大公司里的小部门,这四类角色可能是四者合一的,即从团队当中选定一位有能力担当这四个角色的成员。如果这个成员原来就是架构师,那么对这位架构师的要求就是除了专业技能之外还应该具有项目管理能力。

根据定义项目是“为提供某项独特产品或服务所做的临时性努力”,其本身的特点是“变化”,因此,项目管理对架构师本身来说也是具有很大的挑战性的一项管理工作。项目管理具有入门容易、精通难的特性,大多数项目管理给工程师的感觉就是定计划、看进度、催活、做汇报,实际上这是没有领悟项目管理的精髓。

PMBOK定义项目管理为:“项目的管理者,在有限的资源约束下,运用系统的观点、方法和理论,对项目涉及的全部工作进行有效地管理。即从项目开始到项目结束的全过程进行启动、计划、执行、监控和验收,以实现项目的目标。”,即项目管理有其自身的“观点、方法与理论”,而在项目的落地过程中,所有节点的计划、执行、监控、风险管理以及验收等都依赖于工作分解结构(WBS: Work Breakdown Structure ),不同的行业对项目管理有不同的需求,进而有不同的工作分解结构方法,本文讲述的是与软件工程紧密相关的工作分解结构法。

2. 项目管理方法论

依据PMBOK理论定义以及软件工程实践,软件工程项目管理可以分为两大部分:一是5大流程,二是12大知识领域 ,如下:

2.1 项目管理五过程

项目管理五大过程包括项目的启动、计划、执行、监视和验收,如下图所示:

项目5过程

  • 启动阶段,首先需要确定项目的目标和项目的关键负责人、进行业务分析、需求分析以及组建团队,并且宣布项目正式立项;

  • 计划阶段,编写项目计划,把项目目标量化与质化,制定达到目标的里程碑,在这个阶段,还需要完成的是概要设计、目标分解、任务分派、风险评估等工作内容;

  • 执行阶段,按计划开展项目,进行详细设计、编写代码、调试自测,阶段性的实现目标,这一步是软件工程最核心的一个步骤;
  • 监控阶段,监控阶段与执行阶段是循环的关系,这一阶段需要准确识别偏差,判断影响项目进度因素,同时进行计划刷新与风险刷新以及任务刷新;
  • 验收阶段,按照项目要求,进行项目验收,包括版本发布、文档归档以及项目复盘。

不同于理论,在实践中,这5大过程是个计划、执行、检查、更新的循环过程,而不是一个线性过程。

2.2 项目管理12项

项目管理1.0版里涉及 范围、时间、成本以及质量,这四者是个平衡的过程。项目管理2.0里,又增加了 业务与组织,项目管理是为业务服务的,同时给组织保证结果。而在实践过程中容易发现软件工程项目管理其实涉及12大领域,即:业务、范围、进度、成本、质量、资源、风险、采购、相关方、沟通、测试以及综合管理,具体如下:

项目12项

  • 业务管理,其涉及业务分析、客户管理;
  • 范围管理,包括规划范围、需求分析、定义范围、工作分解、确认范围以及控制范围;
  • 进度管理,其包括:规划进度里程碑,定义任务,排列任务优先级,估算人力资源,估算所需时间,制定进度计划表以及控制进度;
  • 成本管理,包括规划成本管理,估算成本,制定预算以及控制成本;
  • 质量管理,包括规划质量指标,QA测试,质量保证以及控制质量;
  • 资源管理,这一部分与组织结构相关,是决定项目成败的关键要素,合适的项目需要合适的人选,其包括4个子过程:人力资源管理,组建团队,建设团队以及管理团队;
  • 沟通管理,包括3个子过程:规划沟通,管理沟通,控制沟通;
  • 风险管理,包括识别风险,风险分析,定量风险,提出应对以及控制风险;
  • 采购管理,包括4个子过程:规划采购,实施采购,控制采购,结束采购;
  • 相关方管理,相关方管理也是项目成败与否的一个非常关键的要素,包括4个过程:识别相关方,相关方参与,相关方满意度等;
  • 测试管理,项目管理往往容易忽略掉QA测试的作用,在代码编写好后需要提前安排QA介入,记住一点没有经过QA严格质量测试的软件包是不能输出给客户的;
  • 综合管理,综合管理的关键是综合平衡最优,平衡以上11项使之达到最优,包括制订章程,制定计划,指导与管理执行,监控项目,变更控制,结束项目。

不管是项目管理5大流程还是项目管理12项,其中有一个非常重要的工作即创建“工作分解结构”,工作分解结构是开展一切项目管理的依据与基础,可以说没有“工作分解结构”就没有项目管理。

2.3 工作分解结构

在工作过程中,人的认知是有差异的,比较资深的人员描述一个任务或问题时会比较的抽象,而初级工程师比较能理解的是具体的任务描述,为了团队具有较好的执行力,就需要把抽象的概念或描述分解成具体的可执行的行为或任务,这就需要一种合适的工具或方法来分解概念与工作。

工作分解结构法(WBS: Work Breakdown Structure,是一个“描述思路的规划和设计的工具”,是以项目结果为导向的工作过程的结构分解方法论,是将抽象的概念或任务分解成具体的行为的一种工具。将工作进行合理的分解是项目负责人的重要能力之一,缺乏项目分解能力的项目负责人容易造成项目失败,“工作分解”的好坏与否 也可以决定项目的成败与否。

项目

如上图所示,项目管理有两大基石:工作分解结构法与 企业文化+组织结构, WBS在PMBOK中给出的定义是:“WBS是针对可交付成果对项目要素进行的分组,它归纳和定义了项目的整个工作范围,每下降一层就代表对项目工作更详细地定义。”。这一定义说明WBS所分解的目标是工作包(Work Package),以可交付成果为导向的。企业文化与组织结构也是项目成功与否的基石,企业文化作保证,组织调整到位可以给项目提供坚强的基础资源与能力。

“工作分解结构法”的任务拆解是个有拆有合的过程。一个大的工程任务往往是由很多的小个的任务组成的,如何将一个大任务拆解成合适的小任务,能将大任务拆解成什么样的小任务,能拆解到什么粒度,拆解是否准确,这是”拆“的过程。怎样对任务进行量化与质化,怎么将任务落地到具体的执行人员上,怎么进集成怎么验收,这是“合”。任务拆解比较的考验工程人员的工程能力,任务拆解是否成功是工程进度与工程交付能否成功的关键要素。

3. 如何进行工作结构分解

3.1 任务树分解法

如下图所示,工作分解结构就是把项目可交付成果,比如总目标一级级的分解成较小的、更易于执行的组成部分的过程,建立工作分解结构的过程就是将项目进行显性化、结构化,将复杂的总目标分解成一级任务、二级任务,最后分解成最小可执行工作包的过程。

项目

工作分解结构可以按功能、组成、生命周期以及组织的形式进行分析,在软件工程项目中,通常以项目生命周期 + 功能以任务树的方式分解项目。如下图所示,

最终交付成果按生命周期分解成了 项目管理、业务、需求、设计与编码、集成以及交付这6项。然后设计与编码又按功能的形式分为一级任务特性:关键特性1、关键特性2、关键特性N,以此类推,直至分解成最小可执行工作包。

项目

工作分解结构法是面向结果为导向的分解,分解过程中也需要适可而止,比如初级工程师需要给他分解到很具体的最小可执行工作包这种层次,而比较资深的工程师可以给他分解到关键特性这一层次即可,当然前提是这个资深工程师有能力承担这一特性的分解与执行。

此外,任务树适合项目汇报使用,而工作包表格适合团队内部协作使用,其能提供更详细的细节,因此在任务树拆解后,下一步是进行工作表格分解。

3.2 工作表格分解法

对比于任务树,工作包表格可以在右侧增加更多的细节,这有利于团队协作,以下图的软件项目工作包表格为例:

项目

1,首先前三行定义了项目的目标、原则以及投入,说明了项目的交付目标、交付的原则以及约束、还有确定了人力资源的投入,;

2,任务分解成了一级任务、二级任务以及工作包、工作包名称;

3,除这些在任务树上也可以体现的内容外,还增加了 工作进展、状态、评论、风险、阶段目标、执行的人员、复杂度以及依赖条件;

4,输出最终交付成果。

工作包表格的这些细节可以使得团队协作更加顺畅,所以一般开发过程中选用工作包分解表作为项目跟进的任务进度表。

3.3 关键路径网络图分解法

除了任务树与工作包表格之外还有关键路径网络图分解法,在项目当中有些任务比较重要而复杂,有些任务相互独立、有些任务又有依赖关系,

如下图所示,S 表示Start,F表示Finish,SS 表示同时启动,FS表示先完成再启动。F11任务需要在F1任务启动后10天再启动,F23与F31任务可以同时并发进行,

而最终交付的目标需要 F2211 与 F3111 同时完成。

项目

关键路径网络图分解法明确了任务之间逻辑关系、先后关系、时间关系,有利于项目计划进度时间的评估与规划。

4. 工作分解结构法的理念与原则

以上内容讲的都是 工作分解结构法的 “术”的层次,其本身还有背后的理念 ,即“道”。工作分解结构法是“系统思维与分治思维”在软件工程项目中的应用。工作分解除了非常重要的专业技能,还需要遵循以下几个理念与原则:

1,滚动原则

如下图所示,项目的推进是一个 “分解、执行、检查、更新”滚动推进的过程,依据导弹思维,先保证大方向正确,开工,然后再在过程中调整小方向,直至最终精确的命中目标。项目管理也是一个逐步实现目标的过程,时间上近的获取的信息多、那么分解的层次与类目自然也就更细、更多、更准确,而时间上远的,因为信息不够完善,分解的层次与类目自然更少少,也没那么精确,在目标逐步达成后,可以进行刷新重新进行分解,完善工作包,直至最终达成目标。

项目

2,MECE原则

MECE即“相互独立,完全穷尽”,是应用系统思维从全局的角度分解任务,既不重复也不遗漏,纵向递进,横向遍历。

3,量化质化原则

分解出来的工作包需要能量化,需要可量化的完成时间、可量化的验收标准,不能量化的任务需要质化,即以满意度的方式验收。

4,以上统下原则

工作包分解的目标是可交付成果,每一个下级成果有且只有一个上级成果,每一个上级成果是其下级成果之和,不同的交付成果可以分解到不同的层级;

5,适可而止原则

工作包并不是分解的越细越好,而应当根据项目特性的难易程度进行分解,难的复杂度高的分解细点、适当增加分解的层级,而容易的复杂度低的可以减少分层。

6,人事匹配原则

需要考虑每一级任务到底需要什么样的领域专家或者工程人员,任务要能匹配工程人员的能力,工程人员能力要能匹配任务,考虑到执行力,还需要将任务分解到人人有事做,事事能完成的层次。

5. 小结

本文从宏观角度讲述了工作分解结构法的“术”与“道”,在宏观上理解了工作分解结构法,还需要微观上进行实践,才能做到“学以致用”。另作者能力与认知都有限,”我讲的,可能都是错的“,欢迎大家拍砖留念。

6. 作者简介

常平,中科大硕,某AI独角兽深度学习高级软件主管工程师、架构师,前EMC资深首席工程师,主要工作背景在深度学习、大数据、云计算、分布式中间件以及Linux内核领域。

7. 版权申明

本文的版权协议为 CC-BY-NC-ND license:https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用(以获利为准)以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

8. 参考资料

[1] 《极简项目管理》 郭致星著

1. 前言

不同于教科书里讲的深度学习的评价指标,这里主要讲述生产训练中常用的评价指标。通常在分布式训练中对训练的过程与结果会进行评价,比如选择一个评价指标:准确率,即表明模型求解给定问题的准确度。而本文提到的评价指标主要分为两大类,即训练结果评价与训练系统评价。

2. 训练指标

教科书里经常提到的深度学习的评价指标有准确率、精确率、召回率、F1值等,如下:

  • 准确率(Accuracy),所有的预测正确(正类负类)的占总的比重;

  • 精确率(Precision),查准率,即正确预测为正的占全部预测为正的比例;

  • 召回率(Recall),查全率,即正确预测为正的占全部实际为正的比例;

  • F1值(H-mean值),F1值为算数平均数除以几何平均数,且越大越好;

实际上这些指标在真正的生产过程中用的不多,在实际的分布式训练过程中,比较关心的训练评价指标有:

  • 加速比(speedup),即多卡训练下的单卡吞吐量平均指标除以单卡训练下的吞吐量平均指标,比如,大规模训练下的 ResNet-50 v1.5的单卡FPS指标是600,而单卡训练的FPS指标是800,那么加速比即 600/800 = 0.75,加速比体现的是训练集群的效率与可扩展性,越高的加速比表明训练集群的资源利用率越高,但是越高的加速比要求对训练集群的技术要求也越高。比如 一个 1000张卡的训练集群,要求 加速比 0.9以上,那么对于主机间的网络、主机内的网络、全栈软件、训练卡内部的硬件架构、集合通信拓扑算法、训练算法的优化等的要求都极高,这就涉及到整个分布式训练系统的问题,而不是单个点能彻底解决的;
  • 吞吐量,sequence/sec 或 FPS, 即每秒能处理的图片数或数据量;
  • 收敛时间(Time)与训练次数(epoch),生产过程中对训练所有的时间是有要求的,假设给定一个模型的训练次数(epoch)为100,如果要把这个100次都训练完需要 好几天,甚至好几个星期,那么可以认为生产不适用,基本上可以定义 训练一个模型到收敛需要 24小时以上,都可以看做是生产不适用,需要扩大训练集群的规模,使之训练时间控制在24小时之内;
  • 平均准确率(eval Accuracy),平均准确率是训练是否收敛的重要评判标准之一,比如定义一个 Resnet50 v1.5 的训练模型的准确率为 76%,如果训练结束的平均准确率能达到这个值就认为训练是收敛的;
  • 可收敛,训练的最终结果可以达到 平均准确率的要求,即认为可收敛,否者即任务训练失败;
  • 学习率(Learning rate)与损失率(Loss),学习率大模型训练学习速度快,但是易导致损失率爆炸, 学习率小模型训练学习速度慢,而且容易过拟合,收敛速度慢;
  • 曲线拟合(Curve Fitting),这是一个非常重要的评价手段,在XPU训练的场景下,通常先用一个已有的之前训练好模型为基础或先用GPU训练出一个基础模型,然后把XPU训练的结果指标跟GPU训练模型的指标进行比较,曲线拟合即认为XPU的训练结果达标,这也是调试XPU训练结果的一个重要手段。这里埋一个问题,按照曲线拟合的说法,假设有一个2000张XPU卡的集群,怎样评价这个集群训练的结果是正确的?以GPU训练的结果做比较,那么找一个这么大规模的GPU集群进行训练然后得到想要的模型做基础匹配也是不大现实的,那么需要采用什么技术方案才能解决这个问题?

以TensorBoard为例,说明模型的评价指标,在下面的命令行列输入一个baseline:/log_path_2:

1
# tensorboard --logdir=training_model:/log_path_1, baseline:/log_path_2

这个baseline 的模型已经确定是精度达标,生产可用的。然后 XPU训练的模型的 training_model:/log_path_1 与这个GPU训练处的baseline进行比,在tensorboard里可以表现如下图:

训练结果

在上图里,新的模型的eval_accuracy值与baseline的值最终是一样的,这说明训练结果是收敛且精度达标,eval_accuracy中间的线有点差异是由于按不同的训练次数进行tensorboard指标保存所造成。新模型的Loss线与Learning_rate 线也与基础线吻合,这说明XPU训练的模型质量可生产适用。eval_accuracy、Loss、Learning_rate是三个最重要的度量指标,只要这样三个指标达标,那么大概率即可判断这个在XPU下新训练的模型具备生产可用能力。

3. 系统指标

分布式训练系统其本身也是一个分布式系统,因此除了训练领域相关的度量指标,也有与分布式系统质量有关的一套度量指标,其中比较重要的几项内容如下:

  • 可用性(Availability),可用性指的是分布式训练系统长时间可对外提供服务的能力,通常采用小数点后的9的个数作为度量指标,按照这种约定“五个九”等于0.99999(或99.999%)的可用性,默认企业级达标的可用性为6个9。但是当前从时间维度来度量可用性已经没有太大的意义,因为设计得好的系统可以在系统出现故障得情况下也能保证对外提供得服务不中断,因此,当前更合适得可用性度量指标 是请求失败率;

  • 可靠性(Reliability),可靠性一般指系统在一定时间内、在一定条件下可以无故障地执行指定功能的能力或可能性, 也是采用小数点后的9的个数作为度量指标,通常5个9的可靠性就可以满足企业级达标;

  • 可伸缩性(Scalability),是指通过向系统添加资源来处理越来越多的工作并且维持高质量服务的能力,其受可用性以及可靠性的制约,集群规模越大出故障的概率越高从而降低可用性、可靠性,为了保证可用性以及可靠性达标,需要适配合理的可伸缩性指标;

  • 韧性(resilience),通常也叫容错性(fault-tolerant),也就是健壮和强壮的意思,指的是系统的对故障与异常的处理能力,比如在软件故障、硬件故障、认为故障这样的场景下,系统还能保持正常工作的能力,分布式训练系统的容错能力是一个非常重要的指标。

4. 小结

本文从实践的角度讲述了分布式训练的训练结果评价指标与系统评价指标,这些指标是度量一个分布式训练系统与训练的模型是否生产可用的重要参考。日拱一卒,功不唐捐,分享是最好的学习,与其跟随不如创新,希望这个知识点对大家有用。另作者能力与认知都有限,”我讲的,可能都是错的“,欢迎大家拍砖留念。

5. 作者简介

常平,中科大硕,某AI芯片公司深度学习高级软件主管、架构师,前EMC资深首席工程师,主要工作背景在深度学习、Ai平台、系统调优、大数据、云计算以及Linux内核领域。

6. 参考资料

[1] https://www.changping.me

7. 版权申明

本文的版权协议为 CC-BY-NC-ND license:https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用(以获利为准)以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

1. 前言

深度学习软件工程具有一体两面性:单卡的功能完备性、质量、用户体验以及多卡大规模。多卡大规模的出现是为了解决这样一个主要矛盾,即:“日益增长的数据、模型训练的需求与当前单卡计算能力无法满足这个需求之间的矛盾”,而分布式训练可以通过扩展卡子的规模解决这个矛盾,因此,这就是分布式训练的价值。

然而,正如懂得很多道理,仍旧过不好这一生一样,懂得很多分布式训练的理论与知识,也不一定就能做好一个分布式训练系统。把这么多机器连接跑起来、跟跑好也是两回事,分布式训练是一门实践的软件工程,只有你PK过设计方案,调试过一个个Bug,手把手的敲过一行行的代码,为了性能指标能达标无所不用其极的去验证各种性能优化方案,才能知道细节在哪里,难点在哪里,痛点、挑战点在哪里。因此,宏观处着眼,微观处着手,才能完全理解分布式训练的道理。

一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握,微观是实践,中观讲方法论,宏观靠领悟。本系列文章我把它命名为《分布式训练与推理实战》,从工程实战的角度拆解分布式训练里最重要的十八个套路,也是从“微观实践、中观方法论、宏观领悟”这三个维度系统性的讲述分布式训练技术,本文讲述第1式,也是最难讲清楚的一式(也后续再迭代更新),即本质的一问:“什么是分布式训练“

2. 什么是分布式训练

简单来说,分布式训练 = 分布式训练系统 = 分布式系统 + 训练系统,因此,要解答什么是分布式训练就需要解答什么是分布式系统以及什么是训练系统,而“系统 = 要素x连接 + 目的 + 边界”,因此进一步的就是需要分析分布式系统的要素、连接、目的与边界以及训练系统的要素、连接、目的与边界。

2.1 分布式系统

在AI训练过程中采用单卡总会遇到一些问题,比如原始的数据样本太大无法加载进训练卡,或者模型太大无法训练,那么这就需要用到分布式技术把大量的数据分割成小块由多个训练卡分别进行计算,在更新运算结果后,再将结果统一合并得出最终的可用模型。百科上对分布式系统的定义有:

1
A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another. The components interact with one another in order to achieve a common goal.

即:

分布式系统是指其组件位于不同的网络计算机上的系统,这些组件通过相互传递消息来进行通信和协调其动作,且彼此相互交互以完成一个共同的任务目标。

从这句话可以得出三个结论:

  • 分布式系统的组件是位于不同的网络计算机上的;
  • 分布式系统的组件通过传递消息进行通信与协调的;
  • 分布式系统的组件是通过相互交互以完成一个共同的任务目标,同时是有边界的;

因此基于此定义,拆解分布式系统的概念,从中可以看到分布式系统里的要素即为组件,连接即网络,目的是共同的任务目标。其中的位于不同的网络计算机上的“组件”是分布式系统的要素,即各种计算单元,比如Ai训练卡,“网络”是分布式系统的连接,即神经网与数据网,“共同的任务目标”是分布式系统的目的,即训练,至此,再进一步抽象,可以推导出分布式系统的公理化定义,也是分布式系统的本质理论定义:

1
分布式系统 = 计算 x 网络 + 目的 + 边界

在这个公式里,计算即计算单元,是各种AI训练卡,比如GPU, TPU, DPU, DTU。网络即网络连接单元,在单个训练卡内为计算用的神经网,主机内的多个卡子之间是PCIE 以及PCIE Switch,以及各种高带宽通信网,比如GenZ,CXL,NVLINK,OpenCAPI,CCIX等,在主机之间是各种通信网络,比如RDMA网络、InfiniBand网络、普通的TCP网络以及对应的各种交换机,另外从磁盘 + 主机内存 + 训练卡的HBM这个IO路径我们认为属于IO网络,而这里的目的 即训练,同时这个系统是有边界的,其专注于解决Ai训练过程中的难题,不是什么功能都能往里塞都能解决。

2.2 训练系统

以数据并行随机梯度下降( SGD )技术为例,神经网络训练的过程如下:

AI训练

1,首先需要通过在第一个step进行Broadcast操作将参数同步到集群内的所有的训练卡上;

2,将数据样本切片分发到整个集群的每张训练卡上并且通过data pipeline技术将数据样本加载进训练卡的高速内存空间内,作为输入X;

3,每个训练卡在其数据样本上运行前向传播,计算出误差LOSSi;

4,对计算出的LOSSi进行反向传播,得到梯度GRADi;

5,所有的训练卡在主机内及主机之间进行集合通信并进行梯度归约(AllReduce);

6,最后再进行参数更新以获得新的梯度参数。

本质上分布式训练是数据加载、前向传播、反向传播、集合通信以及参数更新\这5个步骤的逻辑组合,因此,基于以上步骤,这里可以推导出训练系统的公式定义如下:

1
训练系统 = 数据加载 + (前向传播 + 反向传播) + 集合通信 + 参数更新

从上面的步骤可知分布式训练是在固定的步骤迭代中进行的,并且需要系统内的所有的训练卡都完成它们的迭代步骤,才能进行最后的参数更新,这相当于在单个训练卡上执行梯度下降技术,但是通过在系统内所有的训练卡之间分发数据样本并同时执行计算来获得训练的加速。

2.3 举例说明

以TensorFlow为例说明模型的训练过程,TensorFlow 是用数据流图做计算的,如下图所示:

计算流图示例

图片来源于网络版权归原作者所有

图中显示了 TensorFlow 的训练过程,其包含输入(input)、塑形(reshape)、Relu 层(Relu layer)、Logit 层(Logit layer)、Softmax、交叉熵(cross entropy)、梯度(gradient)、SGD 训练(SGD Trainer)等部分。

它的训练过程是,首先从数据分片输入开始,经过Reshape数据清洗后,进行前向传播运算,通过Relu 层后得到LOSS值,然后进入 Logit 层,再进行反向传播并且用 Cross Entropy、softmax等 来计算梯度,接着进行梯度归约(Allreduce),这一步在分布式场景就涉及集合通信的过程,最后进行参数更新SGD Trainer,如此迭代循环直到获得收敛指标达标的结果为止。

4. 小结

采用分布式训练的目的往往也是因为数据量或模型太大,一个训练卡放不下,因此对数据或者模型进行切分,分发到多卡上进行计算与归约。本文很概况性的讲述了什么是分布式训练,简单来说分布式训练就是分布式计算的一种,通过对数据样本的计算,得出最后可用的模型再用于数据推理。本系列文章的后续内将展开讲述分布式训练系统的基础理论、训练过程、质量保证、集合通信、系统工程、产品化等,同样分布式训练系统除了解决训练所带来的各种故障也还需要解决分布式所带来的各种故障。

日拱一卒,功不唐捐,分享是最好的学习,与其跟随不如创新,希望这个知识点对大家有用。另作者能力与认知都有限,”我讲的,可能都是错的“,欢迎大家拍砖留念。

5. 作者简介

常平,中科大硕,某AI芯片公司深度学习高级软件主管、架构师,前EMC资深首席工程师,主要工作背景在深度学习、Ai平台、系统调优、大数据、云计算以及Linux内核领域。

6. 参考资料

[1] https://blog.tensorflow.org/2019/09/tensorflow-20-is-now-available.html

7. 版权申明

本文的版权协议为 CC-BY-NC-ND license:https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用(以获利为准)以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

产品开发的本质

根据第一性原理思维,可以得出产品开发的本质即:“高效、高质量地交付有用的价值”[1]。那么从这句话可以推导出四个需要解决的命题,即:

1
2
3
4
1,需要交付的价值是什么?
2,如何判断什么是有用的价值?
3,如何高效地交付?
4,如何高质量地交付?

此外,在软件产品开发过程中除了面临确定性复杂度之外还经常面临不确定性复杂度,不确定性的复杂度比确定性的复杂度更难解决,更容易引起焦虑,更容易带来团队熵增,也更容易造成软件开发交付的失败。因此,为了简单有效地解决这四个命题以及其所自带的复杂度问题,结合精益产品理论,本文提出一种从实战中总结出来的“极简精益产品开发法”。需要额外说明的是,本方法论还有两个约束条件:

  • 本方法论仅适用于以搞生产力为主而非以搞生产关系为主的企业、部门、团队或个人;

  • 本方法论仅适用于“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
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

翻译成中文即:”组织设计的产品/设计等价于这个组织的沟通结构“,通俗的来讲:产品结构必然是其组织内成员沟通结构的缩影,比如微服务。

组织到位的第二个意思是:人员到位,人事匹配。进行软件产品开发一方面需要配备相应的能力需求的人员,另一方面也需要讲究合适的人放在合适的岗位上,合适的岗位需要合适的人选,人选对了,事就成一半。

自组织、自平衡与强管控

软件产品的开发过程除了是一个业务管理过程也是一个团队/个人管理过程,“极简精益产品开发法”更多讲的是业务管理的过程,然而团队/个人管理的成功与否也可以决定产品开发的成败。软件开发过程是一个复杂的系统过程,而业务与团队也是一个复杂系统,需要以系统化的思维而非线性思维来看待。团队能否有效的自我组织、自我驱动直接影响软件开发的效率与质量。

基于此,这里提出团队/个人的三个组织形态:自组织、自平衡与强管控,如下面的组织形态变化图所示,组织的形态变化有自组织、自平衡、强管控这三个形态,自组织态会过度到自平衡态,如果没有外力的干预作用,自组织态与自平衡态都容易滚落到强管控态,强管控态势能最低也是最稳定的最终形态。

在一定的企业文化以及组织架构下,每一个管理决策和管理措施的输出背后,都有一种人性假设,道斯·麦格里格(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

[5] https://www.sohu.com/a/299920333_263553

前言

在一个软件工程项目组里有四种角色特别重要,即:架构师、领域专家、产品经理以及项目经理,在一个比较大的项目里或者大公司大部门里,这四类角色一般分别对应四个人,然而在中小型项目里,特别是创业型公司或大公司里的小部门,这四类角色可能是四者合一的,即从团队当中选定一位有能力担当这四个角色的成员。如果这个成员原来就是架构师,那么对这位架构师的要求就是除了专业技能之外还应该具有项目管理能力。

根据定义项目是“为提供某项独特产品或服务所做的临时性努力”,其本身的特点是“变化”,因此,项目管理对架构师本身来说也是具有很大的挑战性的一项管理工作。项目管理具有入门容易、精通难的特性,大多数项目管理给工程师的感觉就是定计划、看进度、催活、做汇报,实际上这是没有领悟项目管理的精髓。

PMBOK定义项目管理为:“项目的管理者,在有限的资源约束下,运用系统的观点、方法和理论,对项目涉及的全部工作进行有效地管理。即从项目开始到项目结束的全过程进行启动、计划、执行、监控和验收,以实现项目的目标。”,即项目管理有其自身的“观点、方法与理论”,而在项目的落地过程中,所有节点的计划、执行、监控、风险管理以及验收等都依赖于工作分解结构(WBS: Work Breakdown Structure ),不同的行业对项目管理有不同的需求,进而有不同的工作分解结构方法,本文讲述的是与软件工程紧密相关的工作分解结构法。

项目管理方法论

依据PMBOK理论定义以及软件工程实践,软件工程项目管理可以分为两大部分:一是5大流程,二是12大知识领域 ,如下:

项目管理五过程

项目管理五大过程包括项目的启动、计划、执行、监视和验收,如下图所示:

项目5过程

  • 启动阶段,首先需要确定项目的目标和项目的关键负责人、进行业务分析、需求分析以及组建团队,并且宣布项目正式立项;

  • 计划阶段,编写项目计划,把项目目标量化与质化,制定达到目标的里程碑,在这个阶段,还需要完成的是概要设计、目标分解、任务分派、风险评估等工作内容;

  • 执行阶段,按计划开展项目,进行详细设计、编写代码、调试自测,阶段性的实现目标,这一步是软件工程最核心的一个步骤;
  • 监控阶段,监控阶段与执行阶段是循环的关系,这一阶段需要准确识别偏差,判断影响项目进度因素,同时进行计划刷新与风险刷新以及任务刷新;
  • 验收阶段,按照项目要求,进行项目验收,包括版本发布、文档归档以及项目复盘。

不同于理论,在实践中,这5大过程是个计划、执行、检查、更新的循环过程,而不是一个线性过程。

项目管理12项

项目管理1.0版里涉及 范围、时间、成本以及质量,这四者是个平衡的过程。项目管理2.0里,又增加了 业务与组织,项目管理是为业务服务的,同时给组织保证结果。而在实践过程中容易发现软件工程项目管理其实涉及12大领域,即:业务、范围、进度、成本、质量、资源、风险、采购、相关方、沟通、测试以及综合管理,具体如下:

项目12项

  • 业务管理,其涉及业务分析、客户管理;
  • 范围管理,包括规划范围、需求分析、定义范围、工作分解、确认范围以及控制范围;
  • 进度管理,其包括:规划进度里程碑,定义任务,排列任务优先级,估算人力资源,估算所需时间,制定进度计划表以及控制进度;
  • 成本管理,包括规划成本管理,估算成本,制定预算以及控制成本;
  • 质量管理,包括规划质量指标,QA测试,质量保证以及控制质量;
  • 资源管理,这一部分与组织结构相关,是决定项目成败的关键要素,合适的项目需要合适的人选,其包括4个子过程:人力资源管理,组建团队,建设团队以及管理团队;
  • 沟通管理,包括3个子过程:规划沟通,管理沟通,控制沟通;
  • 风险管理,包括识别风险,风险分析,定量风险,提出应对以及控制风险;
  • 采购管理,包括4个子过程:规划采购,实施采购,控制采购,结束采购;
  • 相关方管理,相关方管理也是项目成败与否的一个非常关键的要素,包括4个过程:识别相关方,相关方参与,相关方满意度等;
  • 测试管理,项目管理往往容易忽略掉QA测试的作用,在代码编写好后需要提前安排QA介入,记住一点没有经过QA严格质量测试的软件包是不能输出给客户的;
  • 综合管理,综合管理的关键是综合平衡最优,平衡以上11项使之达到最优,包括制订章程,制定计划,指导与管理执行,监控项目,变更控制,结束项目。

不管是项目管理5大流程还是项目管理12项,其中有一个非常重要的工作即创建“工作分解结构”,工作分解结构是开展一切项目管理的依据与基础,可以说没有“工作分解结构”就没有项目管理。

工作分解结构

在工作过程中,人的认知是有差异的,比较资深的人员描述一个任务或问题时会比较的抽象,而初级工程师比较能理解的是具体的任务描述,为了团队具有较好的执行力,就需要把抽象的概念或描述分解成具体的可执行的行为或任务,这就需要一种合适的工具或方法来分解概念与工作。

工作分解结构法(WBS: Work Breakdown Structure,是一个“描述思路的规划和设计的工具”,是以项目结果为导向的工作过程的结构分解方法论,是将抽象的概念或任务分解成具体的行为的一种工具。将工作进行合理的分解是项目负责人的重要能力之一,缺乏项目分解能力的项目负责人容易造成项目失败,“工作分解”的好坏与否 也可以决定项目的成败与否。

项目

如上图所示,项目管理有两大基石:工作分解结构法与 企业文化+组织结构, WBS在PMBOK中给出的定义是:“WBS是针对可交付成果对项目要素进行的分组,它归纳和定义了项目的整个工作范围,每下降一层就代表对项目工作更详细地定义。”。这一定义说明WBS所分解的目标是工作包(Work Package),以可交付成果为导向的。企业文化与组织结构也是项目成功与否的基石,企业文化作保证,组织调整到位可以给项目提供坚强的基础资源与能力。

“工作分解结构法”的任务拆解是个有拆有合的过程。一个大的工程任务往往是由很多的小个的任务组成的,如何将一个大任务拆解成合适的小任务,能将大任务拆解成什么样的小任务,能拆解到什么粒度,拆解是否准确,这是”拆“的过程。怎样对任务进行量化与质化,怎么将任务落地到具体的执行人员上,怎么进集成怎么验收,这是“合”。任务拆解比较的考验工程人员的工程能力,任务拆解是否成功是工程进度与工程交付能否成功的关键要素。

如何进行工作结构分解

任务树分解法

如下图所示,工作分解结构就是把项目可交付成果,比如总目标一级级的分解成较小的、更易于执行的组成部分的过程,建立工作分解结构的过程就是将项目进行显性化、结构化,将复杂的总目标分解成一级任务、二级任务,最后分解成最小可执行工作包的过程。

项目

工作分解结构可以按功能、组成、生命周期以及组织的形式进行分析,在软件工程项目中,通常以项目生命周期 + 功能以任务树的方式分解项目。如下图所示,

最终交付成果按生命周期分解成了 项目管理、业务、需求、设计与编码、集成以及交付这6项。然后设计与编码又按功能的形式分为一级任务特性:关键特性1、关键特性2、关键特性N,以此类推,直至分解成最小可执行工作包。

项目

工作分解结构法是面向结果为导向的分解,分解过程中也需要适可而止,比如初级工程师需要给他分解到很具体的最小可执行工作包这种层次,而比较资深的工程师可以给他分解到关键特性这一层次即可,当然前提是这个资深工程师有能力承担这一特性的分解与执行。

此外,任务树适合项目汇报使用,而工作包表格适合团队内部协作使用,其能提供更详细的细节,因此在任务树拆解后,下一步是进行工作表格分解。

工作表格分解法

对比于任务树,工作包表格可以在右侧增加更多的细节,这有利于团队协作,以下图的软件项目工作包表格为例:

项目

1,首先前三行定义了项目的目标、原则以及投入,说明了项目的交付目标、交付的原则以及约束、还有确定了人力资源的投入,;

2,任务分解成了一级任务、二级任务以及工作包、工作包名称;

3,除这些在任务树上也可以体现的内容外,还增加了 工作进展、状态、评论、风险、阶段目标、执行的人员、复杂度以及依赖条件;

4,输出最终交付成果。

工作包表格的这些细节可以使得团队协作更加顺畅,所以一般开发过程中选用工作包分解表作为项目跟进的任务进度表。

关键路径网络图分解法

除了任务树与工作包表格之外还有关键路径网络图分解法,在项目当中有些任务比较重要而复杂,有些任务相互独立、有些任务又有依赖关系,

如下图所示,S 表示Start,F表示Finish,SS 表示同时启动,FS表示先完成再启动。F11任务需要在F1任务启动后10天再启动,F23与F31任务可以同时并发进行,

而最终交付的目标需要 F2211 与 F3111 同时完成。

项目

关键路径网络图分解法明确了任务之间逻辑关系、先后关系、时间关系,有利于项目计划进度时间的评估与规划。

工作分解结构法的理念与原则

以上内容讲的都是 工作分解结构法的 “术”的层次,其本身还有背后的理念 ,即“道”。工作分解结构法是“系统思维与分治思维”在软件工程项目中的应用。工作分解除了非常重要的专业技能,还需要遵循以下几个理念与原则:

1,滚动原则

如下图所示,项目的推进是一个 “分解、执行、检查、更新”滚动推进的过程,依据导弹思维,先保证大方向正确,开工,然后再在过程中调整小方向,直至最终精确的命中目标。项目管理也是一个逐步实现目标的过程,时间上近的获取的信息多、那么分解的层次与类目自然也就更细、更多、更准确,而时间上远的,因为信息不够完善,分解的层次与类目自然更少少,也没那么精确,在目标逐步达成后,可以进行刷新重新进行分解,完善工作包,直至最终达成目标。

项目

2,MECE原则

MECE即“相互独立,完全穷尽”,是应用系统思维从全局的角度分解任务,既不重复也不遗漏,纵向递进,横向遍历。

3,量化质化原则

分解出来的工作包需要能量化,需要可量化的完成时间、可量化的验收标准,不能量化的任务需要质化,即以满意度的方式验收。

4,以上统下原则

工作包分解的目标是可交付成果,每一个下级成果有且只有一个上级成果,每一个上级成果是其下级成果之和,不同的交付成果可以分解到不同的层级;

5,适可而止原则

工作包并不是分解的越细越好,而应当根据项目特性的难易程度进行分解,难的复杂度高的分解细点、适当增加分解的层级,而容易的复杂度低的可以减少分层。

6,人事匹配原则

需要考虑每一级任务到底需要什么样的领域专家或者工程人员,任务要能匹配工程人员的能力,工程人员能力要能匹配任务,考虑到执行力,还需要将任务分解到人人有事做,事事能完成的层次。

小结

本文从宏观角度讲述了工作分解结构法的“术”与“道”,在宏观上理解了工作分解结构法,还需要微观上进行实践,才能做到“学以致用”。另作者能力与认知都有限,”我讲的,可能都是错的“,欢迎大家拍砖留念。

作者简介

常平,中科大硕,某AI独角兽深度学习首席软件工程师,前EMC 大数据资深首席工程师,主要工作背景在深度学习、流式大数据、云计算、分布式中间件以及Linux内核。

版权申明

本文的版权协议为 CC-BY-NC-ND license:https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用(以获利为准)以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

参考资料

[1] 《极简项目管理》 郭致星著

前言

不同于科研可以专研的很深而无需转化成生产力,工程化是一套将项目转化成产品从而达成生产力目标的科学方法论。架构师是业务与技术、产品之前的桥梁,除了熟练掌握软件开发的本质、方法论、技能、工具还应该具备工程化能力与项目管理能力,即任务的分析,拆解,计划,执行,领导,管控与团队的组织与管理。

工程化

工程化就是任务拆解

任务拆解是个有拆有合的过程。一个大的工程任务往往是由很多的小个的任务组成的,如何将一个大任务拆解成合适的小任务,能将大任务拆解成什么样的小任务,能拆解到什么粒度,拆解是否准确,这是”拆“。怎样对任务进行量化与质化,怎么将任务落地到具体的执行人员上,这是“合”。任务拆解比较的考验工程人员的工程能力,任务拆解是否成功是工程进度与工程交付能否成功的关键要素之一。

工程化就是取舍

工程化是取舍的艺术,工程受限于已有的条件,需要做出适当的取舍,才能解决实际问题。资源都是有限的,项目开工之前先搞清资源与人员能力,然后制定人员调配策略与合理的进度安排,需要计划让哪些人员去处理哪些问题,也需要制定合理的资源调度策略,从而才能稳操胜券。

比如“田忌赛马”就是一个经典的人力与资源的调配故事,精明的项目管理人员在项目开工之前就能彻底的预判结果,告诉资源掌控者我缺啥需要啥,满足这些条件才有取胜可能,然后再采用合理的策略从而抵达目标获取胜利。不同的人员会制定不同的策略,这也是工程人员的能力差异所在。

工程化就是组织与沟通

一个工程往往需要几十、几百甚至几千、几万人协同工作为达成一个共同的目标而奋斗,因此,在工程中人员的组织、沟通协调也非常重要,合理的人放到合适的位置,才能发挥其能力从而高效的解决实际问题,同时工程也讲究文档化、标准化、流程化与规范化。

工程化就是进度安排

将任务进行拆解仅是工程化解决问题的一个步骤,任务拆解之后还要区别主要矛盾与次要矛盾,进行优先级排序与里程碑确定,需要从时间上进行合理的安排与调度,最终让每一个子任务之间做到有效的协同与交付。

项目管理是工程化的子集

工程化是以现有资源与技术为基础,通过加人员、技能、知识组合起来,短时间内快速解决实际的复杂问题的一种方法。软件工程是指将系统化、规范、可度量的方法应用于软件开发的过程以及软件的运行和维护,其包括两方面内容:软件开发和软件项目管理。因此,项目管理是工程化的子集。

项目管理

项目铁三角

项目铁三角指的是项目管理的四个重要方面,即:

  • 范围:需要做什么;

  • 时间:什么时间做完;

  • 成本:投入多少资源;

  • 质量:做到什么程度才算达标。

范围、成本、时间三者之间任何一个变动均会对其他两项产生影响,如下图所示:

image-20201227171818955

范围扩大(需求增加),做的事情多了,时间进度就需要延长,并且成本也会增加。如果做的事情多了而时间与成本投入又不变那么必然影响到质量。如果不打算减少所做的事情,就必然需要多投入成本(比如时间,人力),否者质量与范围又无法保证。范围、时间、成本之间的制约关系是必然存在的,但是也要依据实际情况而采取合适的方法,有的项目时间节点是固定的、有的质量要求严格、有的有固定的成本约束等,因此,需要根据情况进行合理的调整。

项目三重境

第一重,满足客户质量要求,这是项目管理的最基本的需求,在范围、时间、成本之间获取平衡是为了达到客户的质量要求;

第二重,满足业务的需求,项目管理人员需要懂业务,需要知道为什么需要做,什么是客户需要的,避免项目大方向的错误;

第三重,满足组织成员的需求,项目是由人实施的,其注入了人的精神与意志,因此也需要了解组织成员的需求,准确并且满足成员的需求,才能更好的推进项目。

项目拆解

道与法

架构师完成概要设计后就需要进行项目拆解,拆解的成功与否是项目能否按期交付的关键,在进行项目拆解的时候需要遵循以下的“一人二法三要素四角色”原则,

  • 一人: 项目是由人执行的,人是项目里最关键的要素,合适的任务要拆解到具体的合适的人员上;

  • 二法:量化与质化,任务拆解需要能量化(类似KPI,比如先赚它一个小目标:一个亿)有具体的时间、具体的数值,不能量化的需要质化(如同OKR,比如客户对这个质量感到满意,这个缺陷的修复方案QA已验证接受等,这个策略已经被客户所接受);

  • 三要素:即范围、时间、成本,在有限的成本、范围、时间约束下达成质量目标;

  • 四角色:即RACI角色: 谁负责(R = Responsible): 谁来干这活,谁批准(A = Accountable):谁说了算,咨询谁(C = Consulted):专家团,顾问是谁, 通知谁 (I =Informed):谁需要被通知到,谁需要知道这个进度与风险。

术与器

如何进行拆解,能拆解成什么样的任务,这也比较考验项目管理人员的专业技能,这属于”术” 的范畴,同时也可以借助合适的工具(器)编排拆解的任务与进度。

项目计划

1,项目计划的本质是项目执行人员的承诺,因此,不同于产品与项目制定人员比较看重的是项目的价值,执行人员通常会比较关注项目的资源投入、技术难度、技术实现、里程碑、奖罚等,因此对于计划都会比较的谨慎;

2,计划本身没有太大作用的,但是没有计划却万万不行,如同“天气预报”,没几次预报会准确,但是好处是有了计划就有了可预测性;

3,大的项目计划需要拆分成合理的里程碑,每个里程碑都能对应到一个最小可交付版本(MVP)用于进行市场验证(PMF);

4, 大方向与里程碑先保证正确,过程中进行小调整。

有时候计划的交付时间点是固定的,其由商业交付时间点反推,那么就需要在 “范围,成本与质量承诺”这三点上进行合理的取舍。

人员与组织

项目是由人完成的,了解团队成员的需求,满足TA所要的,这样具有保持团队稳定以及项目价值输出的可行性。

小结

本文从宏观角度概述了工程化与项目管理的差异,只会项目计划那是最初级的项目管理,更高级的项目管理是懂方法论,懂任务拆解,懂项目计划,懂业务、也懂人与组织等。在宏观上了解了工程化与项目管理,还需要微观上进行实践,手把手的操作过、练过、蹲过坑、吃过苦头才能叫做“实践出真知”。另作者能力与认知都有限,”我讲的,可能都是错的“,欢迎大家拍砖留念。

作者简介

常平,中科大硕,某AI独角兽深度学习首席软件工程师,前EMC 大数据资深首席工程师,主要工作背景在深度学习、流式大数据、云计算、分布式中间件以及Linux内核。

版权申明

本文的版权协议为 CC-BY-NC-ND license:https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用(以获利为准)以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

参考资料

[1] https://www.zhihu.com/question/26699139

[2] 《网易一千零一夜 - 互联网产品项目管理实战》 网易杭研项目管理部著

先有客户再有技术

技术不同于科学,科学是人类对自然的认知,它可以很前沿很理论也不用讲究工程价值,而技术更多指的是功能与工程得实现,更需要关注的是“利他”的常识。技术人员其比较关注的是技术架构、实现方式、技术价值以及开发成本,而比较容易忽略客户需求、使用场景以及产品价值与用户体验。忽略这些产品相关的内容而维技术论就容易犯错进而浪费有限的开发资源,在工程实现上维技术论常见的有四错:

  • 第一错:“我为用户想”,这是研发人员最容易犯的错,其已经有用户意识,但是却没有进一步与用户沟通,直接替用户做决定,也不清楚用户的使用场景,因此容易造成”所想“实际上并不是用户真正所想;
  • 第二错:追求有挑战的技术而非技术的实用价值,也非从合适的解决用户问题的角度出发,将技术上的自嗨当成客户需求,比如用户需要从A地到B地,简单一点给用户一辆自行车就可以解决的问题,而技术自嗨就容易非要先自行造个飞机,然后拼命的给用户推销这个好这个快,但是用户却不买单;
  • 第三错:维性价比论,总以为又便宜的又好的就是真的好,性价比是大杀器,但是很多情况下其实客户也讲ROI(投入产出比),比如双11秒杀活动,用户可以不计成本的采用最新进最前沿的技术,只要能扛得住双11的流量就可以不计成本,因为再大的成本,跟双11带来的收益对比都是毛毛雨;
  • 第四错:闭门造车,不实事求是,不与客户做探讨,不做调查就把想象的或还处于概念上的东西当成客户需求。

因此,架构人员不能维技术论,维技术论就不是一个合格的架构师,架构师还需要关注客户价值,在实现一个架构之前先确定这个是对客户有价值的,同时平衡好客户价值与技术前沿之间的取舍关系。

什么是客户,又什么是客户价值

什么是客户

用英文单词表示,客户与用户其实是比较容易区别的,客户是 customers, 用户 是users,而中文二者都有个“户”字就比较容易混淆。To C产品客户可以是用户,但是To B产品, 客户却不是就等于就是用户。狭义的客户 = 买单的,广义上的客户 = 客户的客户 + 客户 + 客户的用户 + 利益链上的所有,用户也不就是一个角色或者某人,对to B产品来说,用户的本质是“需求“的集合。

什么是客户价值

“任何先进的技术、产品和解决方案,只有转化为客户的商业成功才能产生价值“ [1] ,客户价值就是对客户有用的东西,价值来源于价值的交换。技术的目的就是做对客户有用的东西,并且技术的进化方向是由市场所决定的。

以客户为中心,就是给客户创造价值,替解决用户难点、痛点、挑战点、为客户提供高质量低成本的产品,同时响应要及时。病根是需,药是求,拿出 “求” 解决 “需”,药到病除就是为客户创造价值[1]。

如何做到以客户价值为中心?

认知上做到技术要先从客户价值开始,那么执行上应该如何拆分?使得认知具有可量化的执行性?这里从以下三个方面对“如何做到以客户价值为中心”这个问题进行拆解:

  • 价值探索 - 价值与交付双轮驱动思维模型,PMF-MVP思维模型
  • 价值确定 - 三三制需求分析思维模型
  • 价值输出 - 卡诺需求分级与分类思维模型

价值探索1 - 双轮驱动思维模型

双轮驱动思维模型

价值探索的方法论之一是双轮驱动思维模型,其原则为:

  • 以客户价值为前轮,前轮把握方向,解决的是需求探索、价值确定、特性探讨以及价值精炼的过程,需求输出需要去伪存真、去粗纯精、过滤提炼;
  • 产品交付为后轮,后轮提供驱动力,解决的是开发、测试、运维以及获取客户反馈;
  • 先有客户价值再有产品交付,客户价值又可分为主动式客户价值与被动式客户价值,获取客户需求的方式也需要合理取舍;
  • 在双轮驱动模型里,二者谁都离不开谁,不是厚此薄彼的关系,而是二者互相协作从而推动产品往商业成功这个目标前进的关系;

价值探索2 - PMF-MVP 开发模型

PMF-MVP

如上图所示,PMF(Product-Market Fit)是讲究产品与市场匹配,是产品需要与市场需求相匹配,而MVP (Minimal Viable Product)是 最小可用产品,MVP讲的是每个版本的迭代都是一个可用的产品而非功能的堆砌,PMF-MVP开发法,讲究快速给的输出可用的版本给到客户,再由客户进行使用获取客户的信息反馈,再进行版本迭代。

价值探索的方法论之二是PMF-MVP开发法,其原则为:

  • PMF-MVP 开发法可以帮助团队在早期快速确认客户的真实需求;从特性列表中确定产品(特性)的基本功能, 然后迅速开发MVP,再投放市场提前踩坑,收集用户反馈,然后再进行产品迭代,只有用户用起来,产品才有机会演化;
  • 做MVP的时候,不是验证产品好不好用,而是验证产品/特性是不是用户真的想要的,减少开发成本,“闭门造车”式的开发经常会遇到“再来一次”;
  • 跟目标用户产生互动和连接,每一步都收集用户的反馈,前期跟客户多交流,多沟通,“一元共创”与用户一起成长。

在价值探索之后就需要进行价值确定。

价值确定 – 三三制需求分析思维模型

公式: 需求 = 需(痛点、难点、挑战点、恐惧点) + 求 (产品、服务或解决方案), 需即痛点、难点、挑战点,求即解决方案、产品或服务,求到需即完成,这就是有客户价值。依据三三制需求分析思维模型我们可以进行价值确定,三三制需求分析思维模型是一个价值确定思维模型,其如下表:

类别 功能 质量 约束
“大”**客户** 业务目标: 商业成功,比如科技向善 业务质量: 多、快、好、省 业务约束: 时间、质量、成本,法律法规,信息安全,技术趋势,竞争对手,行业标准等
“大”**用户** 业务需求 运行时质量: 性能、可用性、可靠性,可伸缩性、可观测性、可运维性、易用性、兼容性、安全性等 使用时约束: 遗留系统,业务环境,用户能力,用户群特征等
“大”**团队** 功能需求: 基本功能P0 、增值功能P1、潜在功能P2 、可有可无功能P3 、有害无益功能P100 编程时质量: 可扩展,可读性,可测试性,可维护性,可移植性 编程时约束: 开发进度,资源预算、上级要求、开发团队能力、产品规划、运行环境

三三制需求分析思维模型进行价值确定之后即价值输出。

价值输出 – 卡诺需求分类与分级思维模型

KANO

这里采用KANO需求分类与分解思维模型进行价值输出,依据kano模型,需求可以分为:

  • 基本需求:必须有的最根本的需求,没这个根本就没法谈,会阻塞产品交付;
  • 增值需求:当提供此需求时用户满意度会提升;当不提供此需求时用户满意度会降低;
  • 竞争力需求:若不提供此需求,用户满意度不会降低;若提供此需求,用户满意度会有所的提升,属于亮点要素;
  • 可有可无需求:用户根本不在意的需求,对用户体验毫无影响;
  • 有害无益需求:提供后用户满意度反而下降;

卡诺模型将需求进行了分级与分类,进一步的区分了需求的价值。

小结

本文首先确定了 “先有客户再有技术”的认知,再讲述了什么是客户,什么是客户价值,并且以思维模型的方式讲述了如何做到以客户价值为中心。日拱一卒,功不唐捐,分享是最好的学习,与其跟随不如创新,希望这个思维模型对大家有用。另作者能力与认知都有限,”我讲的,可能都是错的“,欢迎大家拍砖留念。

作者简介

常平,中科大硕,某AI独角兽深度学习首席软件工程师,前EMC 大数据资深首席工程师,主要工作背景在深度学习、流式大数据、云计算、分布式中间件以及Linux内核。

版权申明

本文的版权协议为 CC-BY-NC-ND license:https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用(以获利为准)以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

参考资料

[1] xx增长法