3.2 新敏捷扩展模型

IBM的敏捷实践始于小的、集中的团队开发模型,自2006年起,IBM中国开发中心开始尝试将敏捷方法用于各种各样的系统,包括但不限于基于Web的应用程序、移动应用程序、胖客户端应用、商业智能(BI)系统、嵌入式软件、生命攸关的系统,甚至是大型主机应用程序。尤其是Rational、Websphere、Tivoli和Lotus这样的大型组织,拥有分布在世界各地的、多达上百人的项目团队,需要在各自特有的文化氛围、高复杂度的环境中实施敏捷开发。总之,IBM的敏捷方式不局限于小型的集中团队,而是广泛适用于分布式团队、大型团队、组织级项目团队。

敏捷扩展模型,(Agile Scaling Model,ASD)的诞生为我们在复杂的业务环境中掌控重点信息提供了极大的帮助。敏捷扩展模型是敏捷实践的有效剪裁,以应对任何规模的系统交付团队及其特有的背景方法。图3-1概述了ASM不同敏捷类别之间的关系和区别。

00076.jpeg

图3-1 ASM框架概述

核心敏捷开发(Core Agile Development)。核心敏捷方法(如Scrum和XP)是自我管理的、以价值为驱动的系统开发方法,解决了开发生命周期中的一部分或某些阶段的问题。这些方法强调具体的实践方式,比如每日站立会议、需求和设计在迭代中细化等,适合小型且集中在同一地点的团队和简单的系统开发及优化。

规范性敏捷交付(Discipline Agile Delivery)。规范性敏捷交付流程包括Scrum、极限编程(XP)、动态系统开发方法(DSDM)和开放统一过程(OpenUP),覆盖从项目开始直至发布的完整的软件开发生命周期。规范性敏捷交付过程是增加了适当的规则治理框架的自我管理模式,既是风险驱动也是价值驱动的敏捷交付过程。同核心敏捷开发方法相同,规范性敏捷交付也适用于小型协作团队和相对简单直接的系统交付。为了实现全交付生命周期的系统交付,需要将几种核心敏捷方法组合起来,采用一种组合式的新方法(DAD),这个方法还采纳了一些能够反映敏捷哲学的改进型“传统”方法,如前期自上而下的需求分析和先行架构设计。

可拓展敏捷方法(Agile at scale)。可拓展的敏捷方法侧重于当一个或多个扩展因子适用时,对规范性敏捷交付方法的延伸和调整。共有8个扩展因子,分别是:团队规模、地理分布、规范性需求、领域复杂度、技术复杂度、组织分散度和企业规范。所有扩展因子都有一定的取值范围,一个项目可能需要调整一个或者多个扩展因子,但是很少有项目需要调整所有8个扩展因子。所以,需要根据情况灵活地调整有关因子的比例系数,裁剪规范性敏捷交付方法,解决所面临的特定问题。

3.2.1 规范性敏捷交付方法

“规范性敏捷交付(DAD)方法是一个以人为本、学习型、混合型的敏捷方法,是一个风险驱动、也是价值驱动的全生命周期的符合企业规范的过程。”从DAD的定义中可以看到DAD方法的重要构成元素。

1.以人为本

DAD的团队应该是自我管理、自我意识、自律的。传统开发过程中线性传递工作产品,如需求、分析、设计、测试和开发,无论什么原因,当某一环节成为了瓶颈,就将致使后续工作无法完成,产品无法如期发布。而线性传递正是造成时间和金钱巨大浪费的主要原因,人与人之间的交付、信息传递常常造成误解和缺陷注入。在DAD中,我们鼓励由跨职能的人组成跨职能的团队,团队内部不应该有层次,应该鼓励团队成员发展跨职能技能以满足工作的需求,而不是在他们的专业领域内纵深发展。在组织、团队、项目的规范上建立团队的相互理解,将会提升团队生产力,有效利用资源,减少对繁文缛节的依赖。

因此,敏捷方法淡化以技能名称划分角色,DAD角色可以使用多种技能,其中的五个主要角色是:

利益关系人(Stakeholder)。利益关系人是指被解决方案的结果影响的人。利益关系人可以是直接用户、间接用户、内部使用者以及商业伙伴。利益关系人作为团队中最了解业务的人,将帮助开发团队快速达到目标和做出适时决策。

产品负责人(Product Owner)。产品负责人是“客户的代言人”,他们定义产品的功能,决定产品发布的日期和内容,在和投资人的谈判中,规划产品的投入并对产出负责。产品负责人需要始终保持对市场和来自客户的阶段性需求和反馈的敏感度,根据这些变化对产品所需开发的功能模块进行优先顺序排列。在拥有多位利益关系人的团队中,产品负责人尤其需要统一利益关系人对需求优先顺序、团队目标和产品交付的意见。

团队成员(Team Member)。团队成员专注于实际解决方案中的测试、分析、架构、设计、编程、策划、评估,通常以“仅仅足够”的工作完成任务。注意,并非每个团队成员都会跨越多项技能,但他们属于这些技能的一个子集,并将随着时间的推移,努力获得更多的技能。团队成员在核心敏捷方法中被描述为“开发者”或“程序员”,然而,在DAD中,并不是每一个团队成员都必须写代码。

团队负责人(Team Lead)。团队负责人如果是敏捷教练,将有助于保证团队专注于工作项目,并履行其迭代目标。团队负责人直接对产品负责人负责,向产品负责人做出承诺并参与重要的会议,帮助产品负责人果断决策团队的相关事宜。团队负责人是一个真正的团队领导者,擅长交流,赋予团队能力和时间去优化工作流程,并确保团队拥有完成各项任务的资源。同时,团队负责人要在团队遇到棘手问题时及时介入,制定解决方案并实施,直到问题解决。

架构负责人(Architecture Owner)。架构负责人对产品、解决方案的体系结构做出判断和决策,并促进整体解决方案、产品的构建和改进。架构是项目风险的一个重要来源,架构负责人需要尽力减轻这种风险。但架构负责人并没有亲自实现方案、产品中的架构或解决实际问题,而是促成架构的协调者、决策者。

注意,测试人员和业务分析人员并不在DAD过程的主要角色中。相反,一个“通才”的队员应该能做多件事情,包括业务分析和测试。一开始,团队中曾经专职测试的成员可以志愿协助业务分析工作,甚至可以做团队负责人(对应Scrum中的角色)。这并不意味着每个人都需要成为全能技术专家,但它意味着团队愿意去学习和掌握任何所缺少的技能。

团队成员应该是“通才”——一个在“一个或多个学科”的专家,且在其他学科上拥有一般知识。因为,“通才”相比“专才”更加愿意与他人密切合作,分享他们的技能和经验,并好奇和热衷于学习新技能。由“通才”组成的团队不依赖于人与人之间的传递工作,相反,他们了解不同技术领域的差异和各自的局限性,所以更加热衷于依靠团队配合完成工作,而不是仅仅关注自身的事情。

2.混合型敏捷

DAD的许多战略和实践是根据两个主流的敏捷方法Scrum和XP,以及OpenUP、RUP、Kanban等其他方法而制定的(见图3-2)。DAD扩展了Scrum的构建阶段,为解决全交付生命周期问题而从多个敏捷和精益方法中抽取实践和规则。许多DAD建议中包括我们熟悉的敏捷活动和实践,如持续集成(CI)、每日协调会议、代码重构等,有些是普遍适用的“先进”做法,但是,由于某种原因,在敏捷方法中一般不强调的“需求构想进化”、“架构构想进化”、“即将发布前的测试”等实践活动在DAD中与其他关键实践活动并驾齐驱,下面仅举几例。

00078.jpeg

图3-2 DAD是一个混合敏捷方法

Scrum。Scrum的重点是项目领导力和需求管理。DAD采用且裁剪了许多来自Scrum的思路,例如,从堆栈中先提取优先顺序高的工作项;有一个产品负责人代表所有的利益关系人;以及每个迭代都会生产出潜在可发布的产品或者解决方案。然而,DAD放弃了大部分的Scrum的术语,没有Scrum、团队负责人(Scrum Master),也没有迭代(Sprint),只有产品负责人(Product Owner)仍然保留。

极限编程(XP)。XP是DAD开发过程、实践的重要来源,包括但不限于持续集成(CI)、代码重构(Refractory)、测试–驱动开发(TDD)、团队所有制、简单设计、代码规范等。

统一过程(UP)。DAD采用了许多来自UP的敏捷实例,包括OpenUP和Rational统一过程中敏捷特色的实践和项目治理策略,例如,轻量级里程碑和明确的阶段划分,项目的初创期、构建期和发布期等。DAD同时还使用了降低风险策略,借鉴了UP中的原型和早期迭代架构。

看板(Kanban)和精益(Lean)。DAD采用了两个重要概念,即通过减少看板数量来减少产品的中间存储,通过可视化方式显示产品的库存状态。如果产品库存高,那么即使设备出现故障、不良产品数量增加也不会影响到后续工序的生产,所以容易把问题掩盖起来,延迟处理。而且即使人员过剩也不能解决问题,造成全线停工。看板方法使问题得以立即暴露,从而采取措施及时解决问题,通过改善活动使得生产线的“体制”不断增强,带来生产率的不断提高。看板正是一个精益哲学的方法框架。而精益的七项原则(杜绝浪费、打造精品、加强学习、推迟决策、快速交付、授权团队、优化整体)也注入了DAD的概念。

3.全生命周期过程

DAD延长了Scrum所专注的构建周期,涵盖完整的产品、方案的交付生命周期,从项目开始到发布产品、解决方案或投入生产(或市场)。

DAD关注项目完整的生命周期,从初创期开始实施项目直至解决方案或产品的发布期(见图3-3)。事实上,从一开始直至项目生命周期结束的每一次迭代都是不一样的。项目的工作重点随着时间的推移而发生着清晰的变化。

00082.jpeg

图3-3 DAD过程

为了清楚地描述这一点,我们将项目周期分成多个轻量级的里程碑阶段(见表3-1)以确保我们的重点是在正确的时间做正确的事情,比如最初的愿景是项目规划、建造原型、风险管理以及部署规划。这显然不同于主流敏捷方法,相似的主流敏捷过程发生在项目生命周期中的构建阶段,讨论项目如何开始、产品如何增量及如何发布等。DAD最后还有一个里程碑阶段是关注客户对产品的验收和产品投产。

表3-1 DAD轻量级里程碑及其目标分析

00087.jpeg

值得一提的是,DAD强调团队不仅仅需要实现功能需求,还必须修复缺陷(通过独立测试或用户反馈),为其他团队提供支持,或是参加培训课程等。所有这些活动都必须是可见的、可计划的,不只是功能性和非功能性需求。而这些工作项均应该统一存放至一个堆栈,而不是几个栈(可以区分工作项类型)。

4.符合企业规范

DAD团队由企业组建,是构成企业生态系统的一份子,他们从企业的规范性敏捷开发环境中获取企业的有效资源,把握企业内部系统的各种机会而不断发展。他们与企业的技术架构师和资产重用工程师有着密切的合作,利用并加强现有的技术基础设施构建“未来”的上层技术建筑。企业业务架构师和管理者应该适当地规范团队,监管整个商业生态系统的健康状况;企业数据库管理员、分析员应该能够访问和改进现有的数据来源架构以提升数据库服务效率和吞吐能力;而IT支持人员应当了解并遵守企业的IT原则(如安全性、数据公约等)。换句话说,DAD团队具备胸怀“整个企业”的全局心态。

充分利用企业资产。DAD团队应该充分利用企业资产,或者至少知道有哪些资产,包括公共的代码规范、数据公约、命名规范、安全指南和用户界面标准,但企业的资产实际上远远超过这些。如果使用以资产为中心的方式来构建企业的软件,那么将不难发现,企业维护着一个不断成长的软件库,为了更为高效地工作,DAD团队应力争使用企业批准的技术和开放的数据源,并尽可能合乎企业架构。凭借企业资产提高产品、方案的一致性,从而便于维护,降低开发成本和时间,同时降低运营成本。

加强组织的生态系统。产品研发至少应该融入企业的生态系统,即能够与运营人员、技术支持人员、服务人员紧密合作,将产品的价值以最短的时间传递给客户系统。更理想的情况,则是DAD团队在研发产品的方案计划时就考虑如何优化这个生态系统,进而调整工作目标,我们希望DAD团队不要做象牙塔里的闭门研发,而是更加接地气。要做到这一点,第一步是尽可能利用现有的企业资产,在整个生命周期,特别是发布之前,确保企业了解组织生态的最新状态和方向。第二步,由DAD团队的独立测试团队负责生产集成测试,以确保产品或解决方案适合客户的生产环境,极大地简化产品发布后的部署和实施,减少运营投入。

开放和诚信的监控。虽然敏捷方法是基于信任的方法,但聪明的管理策略是采用“信任但要核查,然后引导”的心态。适当管理的一个重要方面是通过各种手段进行监控。一种策略是相关负责人参加DAD项目团队的日常会议,了解当前的状态,这是Scrum社区所推广的策略。虽然我们极力推荐这一点,遗憾的是IBM没有实施得非常好,因为负责管理的高级经理们经常忙碌得没有时间参加会议。另一种方法是使用仪表盘和协作开发、集成工具,尤其是JazzTM平台,以及IBM的Rational Team ConcertTM软件,该软件可以在项目仪表盘中显示实时指标。

5.风险驱动和价值驱动

DAD采用了一种被称为风险、价值驱动的方式,十分有效。DAD团队要努力降低项目风险,例如,利益关系人达成共识的产品愿景,经过论证的架构等;还要确保项目持续发展的可行性,是否已经开发完成足够的功能,是否为发布和投入生产环境做好了准备。同时,DAD也是清晰的价值驱动过程,DAD团队将时间和资源的投入、产出均集中在最有价值的功能和解决方案上,而这项工作的优先级又因新工作项的优先顺序变化而随之调整。

我们依然用建房子的例子(参见2.2节)来阐述DAD的要点(见图3-4),同时,也可以回顾Scrum方法并比较它们的异同。

00090.jpeg

图3-4 使用DAD方法建造房子

某房地产开发公司依然采用敏捷方法,并遇到了市场估计不准和资金不足的问题,但这一次,开发商为了规避风险且降低成本,认为整个团队需要适量的敏捷仪式和纪律规范,这就是DAD思想。

使用DAD方法的房地产公司开始建房了,与Scrum方法不同,在项目工程正式构建之前,DAD团队的设计部门在整体计划上投入了相当的时间,了解该地段未来10年的政府规划,研究土地的地质结构和原有的地下水系统。为了验证新技术的可行性,他们还提前设想并路演了房顶拆装再组装的技术。

与Scrum方法相似的是,建造过程较为顺利,新客户不断加入。因为超期完成工作,开发商奖励团队一笔红利,团队士气高涨。验收部门不仅对之前部分做了再次验收,还将验收工作范围扩大到了整个房屋增量型开发工作的连接部分,因为发现及时,在房屋交付前修复了屋顶接缝的漏水问题,避免了一场纠纷。最终,房屋依然在第4个月的时候准时交付,并因为房屋的设计精良、结构丰富和质量过硬,被业内杂志给予了非常高的评价。

我们用表3-2来对比一下两家房地产公司使用不同方法建造房子的异同。

表3-2 SCRUM和DAD方法的异同

00092.jpeg

00094.jpeg

3.2.2 新敏捷思维的延展

在敏捷的初期,敏捷开发往往是在小范围内进行且项目管理相对简单,小型且集中的敏捷团队管理思想仍然可以在这些情况下指导团队完成任务。而如今,机遇和环境已经显著改变,我们希望将敏捷开发应用于更广泛的项目,并且需要更庞大的团队,为了降低地区经济和市场领域的风险,同时在全球各个地区展开业务,CEO们希望利用分布式方式组织庞大的敏捷开发团队,同时与其他组织成为合作伙伴。因此,需要考虑法规和行业标准,克服巨大的技术或文化环境差异问题,利用超越单系统的思维方式,真正有效地调整跨系统因子——团队规模、地理分布、规范性需求、领域复杂度、技术复杂度、组织分散度和企业规范(见图3-5)。

不是每个项目团队都要面临所有可变维度带来的新问题,也没有任何两个团队会面临同一个问题,但任何一个问题都将增加敏捷交付的复杂性。根据不同的情况,DAD过程需要适应新环境,而团队必须找到策略来面对这些独特的挑战。

团队规模。核心敏捷方法能够很好地适应10~15人的团队,但如果团队大得多呢?50人,100人,或者1000人?随着团队规模的增长,团队沟通和协调会更加困难。书面沟通反而比核心敏捷所提倡的面对面沟通更加有效,但有时书面沟通以及面对面的沟通都会显得无力。

地理分布。如果团队成员位置分散,他们不在同一间会议室中,或许在同一建筑物内的不同楼层,或许在同一个城市的不同位置,甚至在不同的国家,将会发生什么有趣的事情?如果允许一些工程师在家工作,或是团队成员在不同的时区,又会发生什么?团队的联结被断开的可能性越来越大,有效的协作变得更加具有挑战性。

00097.jpeg

图3-5 ASM是DAD模型的八个维度延展

规范性需求。如果行业或地方监管法案出台,所有的移动设备均需送检过关后方能投入运营网络,又或者企业要求所有流程必须符合ISO9000认证,那么这些将带给产品交付过程什么影响?其实,往往是外部强加的、客户驱动以外的许多规则、需求增加了团队的工作流程和工作内容。规范流程往往彼此相似,而业务的日常运行至关重要。发展新客户是运营项目的一个例子,建立一个新的服务客户,无论是作为一次性客户或持续性客户,对项目进展都是有益的。但是,一般的工作流程对于客户基本上是无差异的。合同制造是这种类型的项目环境中的另一个实例,虽然每个产品可能是唯一的,但制造产品的流程却几乎完全相同。

领域复杂度。有些项目团队要解决的是一个非常简单的问题,如开发数据录入、查询应用程序或以信息公开为主的网站。而有些问题是比较复杂的,如监控医疗药品的生物化学工艺或通过大数据采集、存储和分析以辅助交通管制决策等。还有些问题涉及快速变化的信息,如金融系统的前后台转换、端到端的电子服务平台,需要较高的安全保障且兼顾易用性。有人认为,领域内的变化速度、系统的临界性,以及商业模式是影响软件开发过程的关键因素。更复杂的领域需要更加注重探索和实验,以降低风险,这其中的活动包括原型验证、建模和仿真等。

组织分散度。一个项目团队可能包括来自不同部门的成员、不同的合作伙伴,或由外部服务公司雇用、委派的成员。对于组织分散的团队,更适合的关系将是合同联结的方式,而不是协作。例如,一些项目成员虽然在需求、架构、设计,甚至是代码上产出,但实际上出于安全原因,他们不能访问源代码所属空间,不能获得资源执行测试,对真正的产品的理解有极大的偏差,且缺乏组织凝聚力,这将大大增加项目实施的风险。由于缺乏信任,从而减少合作意愿,甚至可能会增加知识产权(IP)斗争的风险。因此,许多组织都在努力调整人力资源采购流程和合作合同,以便更好地在分布式环境中实现产品、解决方案的成功交付。

技术复杂度。有些开发项目是从头开始的,易于提升整体质量和满足客户需求;但如果开发工作与现有的遗留系统和遗留数据源存在极大的耦合需求,产品就有可能变得不完美。同理,使用一个单一的平台来建立系统会相对容易,如果系统需要基于多种平台,或兼用几种不同的技术,这一过程就会相对困难。另一方面,技术复杂度是相对主观的因素,例如,在敏捷计划中,每个人对工作复杂度的理解会因为个人经验和技术水平的不同而不同。换句话说,不同的团队成员评估同一项工作会有不同的结果,所以针对技术复杂度,我们在思考交付过程时需要一个复杂的解决方案。

组织复杂度。有些组织结构和文化可能直接反映了瀑布式交付的价值理念,这将为采用和推广敏捷策略增加难度。更糟的是,组织内的不同团队可能有不同的看法,因为他们需要考虑自身的需求。而差异性策略即使是相当有效的,但作为一个整体,因为他们并不是向同一个方向努力,因而可能大大增加项目风险,也可能闭门造车般地重复投入资源开发着同一个轮子。

企业规范。大多数企业希望利用共同的基础架构平台,以降低生产成本,缩短产品上市时间,提高一致性,并促进可持续发展的步伐。如果项目团队只专注于他们的迫切需要,理念和实际就会脱离。为了充分利用公共平台和资源,项目团队需要采取有效的企业架构、企业业务建模、战略性重用和资源组合,必须同心协力以更好地实现规范敏捷交付流程。但是,这不是免费的,敏捷开发团队需要招募专业人士——如企业架构师和企业资产重用工程师——如果这些人士属于非可调动的资源。该企业的专业人士也需要学习规范敏捷交付的工作方式,因为未来的工作相比于他们在传统的团队的工作方式将有非常大的不同。

需要指出的是,每个扩展因子代表的复杂度才是关键,而每个项目团队都将面临这些复杂度的不同组合,这意味着团队需要根据实际情况做出调整。实际上,前四个扩展因子(团队规模、地理分布、规范性需求、组织分散度)是相对简单的,能够通过工具,采用适当的技术来解决。而其他四个扩展因子(领域复杂度、技术复杂度、组织复杂性和企业规范)则更难解决,许多企业正在努力寻找解决方案。

3.2.3 案例分析:“唯衣定制”——ASM框架下的制衣品牌

有些产品开发受到“合规性”的约束较多,且必须按常规的频率运行这些项目,而项目之间通常十分相似,对于新技术的需求并不大,因此对业务的日常运行模式没有必要经常更新和颠覆,此时有效的工作模式更应偏向传统的计划性开发模式。这好比“工厂式”的工作流程,面对每一个客户时流程基本上是相同的。而“合同制造”也正是这类项目的另一个特点,虽然每个产品可能是“唯一”的,但该过程构建出的系统通常是普遍的。相反,如果合规性要求降低,产品对于新技术本身的需求增加,例如互联网行业,则开发模式就应该向敏捷开发方向偏移,图3-6所示为扩展因子对开发流程的影响程度。

00100.jpeg

图3-6 扩展因子对流程的影响

对于合规性要求很高、不需要技术革新、相对流程类似生产线的工厂式项目,不妨分享一个制衣行业的故事。

“唯衣定制”是一家个人品牌店,这家店是由两兄弟在北京创业发展起来的,店面不大,但是工作量不小,几乎每天都有客户上门要求量身定制衬衣、西服等。大部分客户是男性,多在35岁以上,有了一定的经济基础,但同时身体也开始发福,市面上常规规格的服装不再适用,因此他们非常需要量身定制。此外,这家店还吸引了一些讲究的客户,这部分客户对外型比较挑剔,例如领子的形状、扣子的排列、衬衣和西服的材质、口袋设计的位置以及袖口的设计等,一件男士定制衬衣价位200~1000元不等。从产品的多元化方面来看,这家店是非常有吸引力的。价格合适、品质出众,又受到“私人定制”风潮侵袭,我果断地订了一件。

从下订单到通知取衣服的时间大约是15天,超出了老板承诺的10天。说实在的,如果再不来电话,我可能都忘记了。但店主很客气,一边道歉一边解释说,年前由于遇到了订单高峰期,加上工人提前回家过年,没有能够按照承诺的周期交付。看老板态度不错,加上我并不着急,也就未予计较。

取衣服时和店主聊了起来,这么一聊才知道,制衣的所有工序都是固定的流程,鲜有例外,每个订单都有详细的要求记录,一张订单会发送到工厂,然后工厂的工人依次“组装”。生产线上有足够的工人,而且工人的操作都非常熟练。“组装”就是一个瀑布式过程,一共5个环节,“前道、中道、后道、检验、大烫”,每个环节只完成一个或两个衣服的组成部分,如领子、上衣、扣子、领口的加工等。

有意思的是,“唯衣定制”的返工率只有不到10%,有时候100件衣服只有2~3件需要增肥或者减瘦。我比较惊诧,难道没有像我们估计那样,瀑布式的传统开发会因为过度的遵循计划,而忽视市场的变化吗?原来,除了第四道工序是整体检验、核对订单和需求以外,每道工序的工人都已经自然地对前道工序的结果做出了判断。事实上,这不仅仅是一个“等待和递交”的传统开发过程,每道工序都是“需求理解+设计+开发+测试”的完整过程。从另一个角度看,每个环节都可以交付成品,如成品上衣、成品袖口等。这分明是敏捷开发的迭代过程!

通过更进一步的了解,才发现“唯衣定制”真是团队建设的高手。团队采用自我管理方式,员工是“跨职能”的,也就是能够在各个环节工作,尤其是组长,更是各个环节的好手。员工的技能培养方向也是全面的,如果某个环节的工人输出明显慢下来,产生了积压,则组长会立即安排其他环节的工人来帮忙,保证所有工人忙闲适度。而每个环节的工人都有熟练和不熟练的,一起干就是培养新人的最好过程。组长和工人干一样的工作,同时还需要协调生产线上的人力分配,是不折不扣的拥有最令人信服的“能力+协调力”的“领导”。

从薪酬角度来看,工人除了底薪以外还有按照完成成衣件数计算的提成。因此,团队会很认真地做新员工入职考核,帮助筛除效率低下的人员。同时,大家的配合更多的是一种良性竞争,之间的利益关系不是此消彼长,而是配合越有效率,成品越多,得到的回报也越多。而且这个提成机制将员工的个人利益和团队利益捆绑在了一起。

那么,如果因为制衣问题返工了,工人会受到惩罚吗?老板的回答是:“不会的,成衣只要经过了以上五个环节就会安全出库,我们的衣服非常少会因为制衣质量问题而返工,绝大多数返工是因为太瘦、太肥,而这部分工作有专门的团队来处理,所需的成本在我们的报价中已经包含,并不是返工多少,我们赔多少,而是返工少了,我们赚得更多”。

“唯一定制”就是一个规范敏捷开发过程,因受到“合规性”因子影响,在一开始就已经将规划、成本预算、架构搭建好,和客户“合同”达成一致。在之后的开发过程中,按照增量型的迭代交付成品,每个迭代过程都有完整的“需求+设计+开发+测试”过程。在发布期之前,又会做一次完整的验证,确保产品和需求一致,最后将“按需定制”的商品发送给客户。