1704257833
资源/流程/工具——目标分解、责任落单。本质是权衡执行中的时间进度、资源成本与产品质量三要素
1704257834
1704257835
第一步,根据产品定义文档和功能需求文档,由责任人“架构师”做出系统设计,完成从设计目标到执行目标的最重要的跨越。
1704257836
1704257837
更一般的目标体系是关键绩效指标KPI。以第一个推行KPI的央企中国移动为例,每项业务都有KPI指标,各省KPI考核会影响到该省员工来年的薪酬预算。重压之下,分公司采取强行捆绑用户、开通增值业务送等额话费的促销手段。数据显示,近70%的用户使用了捆绑数据以及信息业务的套餐,连最成熟的无线音乐收入的53%都来自套餐捆绑。对此,李跃出任CEO后不久就公开表示,“数据业务和用户在不断增长,但没有相应幅度的收入增加”。
1704257838
1704257839
扭转你希望的执行力就是修订KPI,中国移动打破原来对单项业务的数据考核,转向对业务包的利润指标考核,而各省可自主选择数据业务。李跃期望,在利润压力下,各省将主动考虑如何打通各类数据业务,以期发挥各业务的协同效应增收。
1704257840
1704257841
第二步是将系统设计按WBS(work breakdown structure)逐层切割,由责任人首席产品官或程序经理部负责人(大PM)将产品切片成子项目,并分配到单一责任人(职能经理或小PM),同时归总形成所有子项目的列表。切片的原则是让每个子项目间的团队依赖与沟通成本尽可能少。一个子项目只能对应一个PM,但一个PM可以负责好几个子项目。
1704257842
1704257843
为什么责任要落地在唯一责任人身上?国史上最惨的一战是长平之战,40万赵军在秦军包围中粮尽力穷而降,秦将白起“乃挟诈而尽坑杀之。”问:为什么40万军人不反抗?
1704257844
1704257845
社会心理学家罗伯特·西奥迪尼阐述了人类从众的心理,即人们往往以别人的行为作为判断标准。在那个绝望的夜晚,活埋40万其实很容易,因为赴死只是从众,而反抗则需要舍身赴死、力挽狂澜的大勇气、需要“虽万千人吾往矣”的大霸气。可以想象,群龙无首,被恐惧压垮的人啊,都在侥幸地企盼一个振臂一呼:“活埋是死,反抗也是死,拼了吧!”
1704257846
1704257847
第三步就是由小P、职能经理、具体的开发和测试人员将评估子项目,估算出大致的资源要求和进度计划,做出甘特图或PERT图,找到关键路径,做好风险分析,准备开始执行。
1704257848
1704257849
其中,估算排期最难。微软的做法是四大原则,即自底向上估算、咬死发布日期、风险驱动式排期、为不确定性预留缓冲时间。之所以采用自底向上排期是因为当经理把排期推到个人或小团队自定时,它会产生非常大的同行竞争压力。如果你估时太长,经理会重新平衡,把模块从你手中拿走给其他同事。与美国相比,中国同行们还不是特别职业敬业,我们采用双向排期,先自底向上,然后自顶向下由开发经理评估。
1704257850
1704257851
排期的规律是帕金森法则:工作会自动膨胀到占满所有可用的时间。另外,如果项目延期,记住布鲁克定律“增加人手到一个进度延期的项目会使它更延期”,所以可采用加班、封闭开发等用空间换时间的方法。
1704257852
1704257853
1704257854
1704257855
1704257857
半面创新:实践者的创新制胜之道 行业主力流程
1704257858
1704257859
以软件业为例,图灵奖得主Fred Brooks认为,“软件系统是人类所创造的最复杂的系统。”最初的软件开发带有强烈的个人色彩,没有系统方法,没有需求规格,没有团队概念,开发人员把头脑中的代码写好交给客户,客户不满意再改,如此反复。
1704257860
1704257861
1968年软件危机后,软件工程的概念和方法被提出,即将系统化的、规范化的、数量化的工程原则及方法应用于软件的开发运维,最初是四大基础模型:
1704257862
1704257863
瀑布模型:历经系统需求、软件需求、分析、设计、编码、测试,最后上线运行。主要问题是最终发布的可运行产品在开发过程中很迟才能看到,很可能产品做好之日就是客户不满爆发之时。
1704257864
1704257865
增量模型:为了提早获得可运行版本,可以先实现一些功能,发布一个版本;再实现一些功能,再发表一个版本……每个增量包括分析、设计、编码、测试等阶段并交付一个可运行版本。
1704257866
1704257867
快速原型模型:核心是用交互的、快速建立起来的原型取代了形式的、不易修改的规格说明,用户可实际运行和试用原型而提供反馈。优点是使得用户在设计阶段就能参与,减少了风险。
1704257868
1704257869
螺旋模型:瀑布模型+快速原型模型+周期迭代。每个阶段使用瀑布模型,包括需求定义、风险分析、工程实现和评审四个阶段,再由这四个阶段进行迭代。优势是设计上可在项目的各个阶段进行变更。以小的分段来构建大型系统,使成本计算变得容易。客户始终参与每个阶段的开发,保证了可控性。
1704257870
1704257871
基于基础模型的行业四大主力流程是RUP、MSF、XP和CMMi,只做理念概述:
1704257872
1704257873
统一过程RUP。中心思想是用例驱动、架构为中心、迭代和增量,适用于大中型产品。它是二维开发模型,如图17-1所示。横轴把开发周期分为多个循环,每个循环生成产品的一个新版本,每个循环由四个连续阶段组成:先启阶段定义最终产品视图和业务模型,确定系统范围;精化阶段设计、确定系统的体系结构,制定工作计划即资源要求;构建阶段构造产品并继续演进需求、体系结构、计划直至产品提交;产品化移交阶段把产品提交给用户使用。
1704257874
1704257875
纵轴为九大工作流,一是业务建模,理解待开发系统所在的机构及其商业运作,确保所有人员对它有共同的认识,评估待开发系统对结构的影响;二是需求,定义系统功能及用户界面,为项目预算及计划提供基础;三是分析设计,把需求分析结果转换为分析与设计模型;四是实施,把设计模型转换为实现结果,并做单元测试,集成为可执行系统;五是测试,验证所有需求是否已经被正确实现,对软件质量提出改进意见;六是部署,打包、分发、安装软件,培训用户及销售人员;七是配置与变更管理,跟踪并维护系统开发过程中产生的所有制品的完整性和一致性;八是项目管理,为软件开发项目提供计划、人员分配、执行、监控等方面指导,为风险管理提供框架;九是环境,为软件开发机构提供软件开发环境。
1704257876
1704257877
1704257878
1704257879
1704257880
图 17-1 统一过程RUP模型
1704257881
[
上一页 ]
[ :1.704257832e+09 ]
[
下一页 ]