将精益思想应用于项目集管理的相关思考

精益思想源于丰田生产方式(TPS,Toyota production system),从上世纪40 年代积累至今,形成丰厚的思想宝库,特别是1990 年美国麻省理工学院教授Jim Womack 和Daniel Jone 出版《改变世界的机器》一书后,推动制造业生产革新的洪流。2000 年以来的近十多年里,IT行业逐步吸收精益思想的精髓,敏捷运动蓬勃兴起,精益创业、精益设计、精益数据分析成为时下IT 业的热点。
作为银行IT 项目管理人员,我们发现,若将精益思想与项目管理方法论相结合,特别是将一组相关项目的项目集(Program)管理,结合精益思想所关注价值和流动,可以在传统PMI 项目集管理方法论关注组织战略、投资收益的同时,另外打开一扇窗户,聚焦价值和流动,去观察、分析和控制项目集。
由于项目集的组织级监控工作由PMO 来完成,因此本文主要站在PMO 运作的角度来思考相关问题。
一.全面运用看板管理
看板,是丰田公司为了寻求准时化生产(Just In Time)而发明的管理工具,以实现拉动式生产,一般分为生产信号看板和领料看板。2010年,David Anderson 编著了《看板方法-科技企业渐进变革成功之道》一书,将制造业的看板方法运用于软件工程,以解决知识工作者的管理可视化问题。看板方法的核心特性是:可视化工作流程、限制进行中的工作、度量和管理流动、明确过程策略、识别改进机会i。看板方法同时辅以每日站会,团队每天在固定的时间,由每个成员介绍昨天做了什么、今天要做什么、有什么困难需要帮助解决,团队从看板的右侧向左侧,关注价值流动中出现的等待和阻塞情况,可以有效促进了团队沟通和协作,传导管理压力,及时解决问题。
看板方法易于被各级管理者和员工接受,可以快速实施,经招商银行信息科技部门近3000 人团队使用200 多块看板的实践证明,是一种较好的运用于银行科技管理的方法。
二.同时关注资源效率与流动效率
资源效率,指单位时间内的产出,比如功能点/人天,故事点/人天,故事点/迭代等,目的是对人的高效实用,用更少的人做更多的事。流动效率,可以理解为项目交付速度,是对科技部门响应业务需求速度和能力的一种衡量,一般可分为两段:需求响应时间,即回复业务部门是否可以立项以及主要阶段计划。需求完成时间,即从立项开始到交付业务验收的时间,这也是精益体系中Leadtime 的含义。
举例而言,国内的医院追求资源效率最大化,医生、检测设备不停运转,患者到不同科室问诊、验血、拍片、收费、取药,患者看病的时间很长,但这种模式下医院可以服务更多病人,实现了资源运用最大化。
而消防队追求的是响应时间,在起火时要求几分钟内迅速到达现场,但平时人员闲置,随时做好出发准备,不能从事其他工作,用牺牲资源效率来换取流动效率最大化。
资源效率和流动效率应同时关注,根据业务需求的不同予以分别侧重。提高资源效率的方法是专业化分工和大规模生产,提高流动效率的方法是多能化和面向价值的快速迭代。资源效率和流动效率有时不可兼得,必须由组织级加以权衡。
三.观察和消除阻塞
业务需求提交至银行科技部门,立项形成项目,一直到上线投产的全过程,可以视为项目在各个环节加工处理,不断流动的过程。不同的组织形态下,流动的形态不同。
在流动的过程中,会出现等待队列和阻塞,常见的有已经提交但积压的业务需求队列、已立项又被暂缓的项目队列。组织级PMO 应及时识别、跟进、督促解决这些流动中的阻塞,不断清淤。一般来说,长期暂缓的需求和项目,会趋于失效,有一半最终会被取消,沉没成本极高。
我们还应该关注到项目过程中的隐性阻塞,这些阻塞从进度指标上不一定能识别出来,但却对组织整体的交付周期有很大影响,例如关联项目之间的相互等待、由于版本锁定造成的排队、由于业务验收不及时造成的项目周期过长、由于测试资源或测试环境的问题造成的项目等待等。
推广使用精益看板,推进部门之间的沟通协作,从组织级高频度清除项目集中的等待队列,端到端度量项目全过程不留死角等方法,可以有效消除阻塞。
四.LEADTIME 分布的截尾、左移和整形
若将一个团队在过去一段时间完成项目的交付周期数据进行图形拟合,横坐标表示完成周期刻度,纵坐标表示项目数量密度,我们就可以从总体上观察项目集的分布特点。
如果拟合图线符合Weibull 分布,且K 值处于1.4 到2.0 之间,说明此团队交付时间的可预测性较强。
将精益思想应用于项目集管理的相关思考_第1张图片图:需求交付周期(leadtime)分布变化图

从项目集管理的角度,可以采取改进措施主要包括:
1.截尾
简洁的规则,可以应对复杂的情况。PMO 可根据历史数据,梳理各类项目所应完成的规定周期(比如功能增强项目应在3 个月内完成),以此去观察和督促超期项目,可以更有针对性。超出规定时间之外的项目作为异常点,成为项目监控的主要对象,其超期的主要原因,一般有人力资源、版本冲突、相关项目影响等,同时也存在本身体量较大而超出期限的项目,这些应视为正常。从图形上看,消除这些异常点可以视之为“截尾”,可以提升团队健康度,减少项目黑天鹅事件。同时通过精益5H 工作法,分析和解决这些异常点出现的根因,以减少未来可能出现的异常点。
2. 左移
整个图形的左移,即缩短leadtime,这是精益思想的核心,也是项目集管理的目标,在保证质量节约成本的前提下,通过不断改进,提升交付能力,缩短交付周期,最终提升客户满意度。
3. 整形
即提高峰值,加强团队交付能力的内聚度和稳定性,对于同一类型的项目,团队应在基本相同的周期内完成,有利于各方形成稳定的预期,提升计划的准确性和客户满意度。
从实施的顺序看,一般应先截尾,以消除异常;再左移,以提升团队的交付能力;再整形,增强团队交付的确定性。
五.控制项目批量大小
与大规模生产中“大批量(Batchsize)、少品种”不同,丰田生产方式采取了“小批量、多品种”模式,通过几十年的努力,将生产线的换模时间从几十小时减少至几分钟,实现“柔性生产线”,以满足客户对汽车的多样化需求。
将“批量”的概念应用于银行软件开发项目管理过程中,我们应梳理整合不同来源、不同粒度的业务需求,整合为批量大小适中、具有内在联系和共同业务价值的集合,一并立项完成;同时将过于庞大的业务
需求进行拆解,按照业务价值的高低划分迭代逐步完成。这样,通过寻找合适的“经济批量规模”,既可以减少项目过程成本和管理成本,实现规模效益,又可以避免由于批量过大带来的交付时间过长问题。
将精益思想应用于项目集管理的相关思考_第2张图片
图:经济批量规模
(批量越大,总交易成本越低,但同时持有成本提高)

六.控制并行项目数
JIT(准时生产)和自动化是丰田生产方式(TPS)的两大支柱。其中JIT 可概括为“在需要的时候,按需要的量生产所需的产品”,也就是通过生产计划控制及库存的管理,追求零库存,或库存达到最小的生产系统。降低库存的主要办法是降低WIP(在制品)数量,在丰田生产体系中,一般只保持一天的存货数量,其他均在客户下单之后拉动式生产。在银行软件研发中,正在开发中的项目、测试中的项目、测试完成等待上线的项目,均可视为WIP,当并行项目数过多时,会明显影响交付周期,同时带来版本锁定、团队士气下降缺乏成就感、管理负担增加、项目问题被掩盖等诸多问题。当出现等待及阻塞时,应提倡“STOPSTARTING”停止启动新的工作、“START FINISHING”聚焦于已经开始的工作,尽快完成手头已有事项。
那么,WIP 是不是越小越好,或者说保持在WIP=1 最好呢?也不尽然,这要根据具体管理要求、产品化程度和团队能力而定。当WIP 过小时,可能由于需求不饱和、管理的不成熟造成资源闲置。统计数据表示,在项目制为主的IT 支持部门,保持平均1.5 左右的并行项目数,可以在交付周期和工作饱和度之间达成较好的平衡。
七.减少项目3M(浪费、负荷过量、不均衡)
在丰田生产方式中,常结合使用MUDA、MURI、MURA 三个术语,用来描述需要消除的浪费行为。
1.Muda 指一切不为顾客创造价值但却消耗资源的活动。开发出没有用户使用,或使用频率低的软件功能,是软件开发中的首要浪费。银行科技部门由于一般缺少有效的业务需求ROI 分析和考核机制,IT 资源容易被无效耗用。应对方法一是建立有效的业务需求ROI 分析、承诺和跟踪机制,适当采取优先级重排序、高层审批、事中控制等手段;二是运用Design Thinking(设计思维)和MVP(最小可行产品)理念,不急于进入设计具体解决方案,而是在前期反复思考所要解决的问题和痛点,分析清楚用户是谁,要解决用户的什么问题,用户究竟要什么,再考虑解决方案。经过两次发散和两次收敛,最终明确开发计划;三是缩短迭代周期,采用敏捷开发方法,小步快跑,快速验证业务假设。
2.Muri 指超载的设备或是超负荷的工人,在制造业,通常是生产工作的节拍比原设计的规格更高、更困难所致。从软件开发角度来看,当研发团队长期处于高负荷状态时,会严重影响团队士气,效率极低,质量也无法得到保证,从长期看是不可行的。就如同高速公路在百分之三十的流量负载时,可以顺畅通行,到了百分之八十以上,会迅速进入阻塞,此时并没有发生车祸,但整体通行效率极低。从精益的角度看,应以观察端到端的服务响应和产出情况来识别团队的“工作饱和度”,而不宜按100%、120%甚至150%的比例过量分配工作。
3.Mura 指生产运作的不平衡,例如生产系统的进度安排不符合客户的需求,或者一个不均衡的工作节拍,导致员工有时匆忙,有时空闲的现象。
从银行IT 来看,当业务需求缺乏整体规划,或是原先制定的年度规划经常被插队,缺乏规划管控与沟通,就容易造成IT 资源计划与业务需求之间的不平衡,在需求高峰时IT 资源供给不足,在需求波谷时又不能及时释放资源,人力过剩。对此,应加强业务需求的年度规划和变更管理,加强对当前业务方向、工作重点以及所需IT 投入的提前沟通,做好提前准备和整体计划。
PMO 应以年度为周期,掌握全年的业务需求规划及变化,同时根据现有项目信息、人员信息和生产效率数据预判各条线未来3 个月到半年的计划安排、资源投入、新增人力和培养情况,作好动态规划和预测。
精益思想注重从总体上解决浪费,认为整体优化重于局部优化。在项目集的管理过程中,应关注MUDA、MURI、MURA 之间的逻辑关系,生产的不均衡和开发大量客户不需要的功能,均有可能导致工作负荷过重。
因此,当发现开发团队工作负荷过重时,要考虑增强对业务需求的前瞻性准备,并运用MVP、迭代等各种方法,促进业务部门聚焦于有真实价值的需求。
八.总结
综上所述,本文探讨了精益思想与项目集管理相结合的可行性,提出了一些简要的工作思路,由于制造业和IT 业特点不同,如何吸收精益思想,还需要结合软件工程、项目管理体系和实际情况进行综合运用,才能取得好的效果。精益思想的创立者大野耐一在《丰田生产方式》一书中说过,丰田生产方式是为了适应日本经济“恐怖的低速增长”应运而生的,面对我国目前经济长期L 型发展的趋势,重新思考精益思想,也许可以给我们带来更多启发。
(本文为招商银行总行信息技术部项目办公室PMO负责人廖为民发表于银保监会《IT治理与研究》)

你可能感兴趣的:(将精益思想应用于项目集管理的相关思考)