前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >精益企业原则之:以产品为中心,而非交付项目 | TW洞见

精益企业原则之:以产品为中心,而非交付项目 | TW洞见

作者头像
ThoughtWorks
发布2018-04-20 10:38:18
6930
发布2018-04-20 10:38:18
举报
文章被收录于专栏:ThoughtWorksThoughtWorks

今日洞见

文章作者/配图来自ThoughtWorks:姚安峰,作者新书《精益企业》中文版已经正式开卖。

本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站,在使用时必须注明"内容来源:ThoughtWorks洞见",并指定原文链接,违者本网将依法追究责任。

如果要创造一个软件产品,我们现在是怎么做的?

很可能你会先组织进行可行性研究,包括分析市场环境,在纸上算算未来可能的成本和收益。如果技术上也可行,那么就写一份漂亮的商业计划书,编织出美好的数据来说服管理层和财务部门拿到一大笔预算,成立项目。项目启动后首先将需求详细写出来,在正式动工开发之前可能就已经过去了几个月甚至更久。之后负责方案设计的业务分析人员将详细方案文档交给公司的软件开发部门或外部供应商来实现,最后开发团队将软件包交接给一个专门的运维部门部署维护,并提供用户支持。

这就是现在在大多数企业的做法。不仅仅流程冗长,组织结构往往也是按业务,开发,和运维划分成不同的职能机构,大大拉长了一个想法从提出到交给用户的周期,常常错过投入市场的最佳时机;现实中业务人员对于用户到底需要什么、喜欢什么经常产生误判,在这种模式下提前数月制定的大计划就会导致大量浪费;以范围、成本和进度为中心的交付管理使得所有人都迷失了,似乎项目交付就是目的,而忽视了投资本身的初衷是要达到的用户和业务目标,更谈不上持续创新。图Figure 1 展示了这样一种传统结构:

Figure 1 阶段化的项目模式

这种项目化的传统模式带来的问题不仅于此。由于开发阶段和维护阶段往往由不同的职能部门负责,在成本上也是分开计算,开发人员往往不会很认真考虑运维因素,可能给系统增加不必要的复杂性,例如引入过度异构的设计或难以理解的数据结构,这导致运维成本增高,然而这些问题却反映到不到设计和开发阶段,组织很难看到围绕一个产品实际产生的所有成本;当生产环境出现问题,只有运维人员苦命地24小时待命,找到快速恢复的办法,而开发人员却可以心安理得地留下系统低质量和不稳定的风险。

以产品为中心的模式

现代科技企业所面对的竞争环境越加激烈,用户和市场的变化迅速,要能够快速适应变化,真正创造用户喜爱的,有竞争力的产品,并持续创新,需要告别以往多年以项目为中心的管理,建立一种以产品为中心的软件交付模式。也就是说,组织的投资决策与治理结构要支持团队解决问题,而不是交付项目,这是建立高适应力、持续创新的精益企业的核心原则之一。组织创造产品的目的就是要解决用户或组织自身(也就是内部用户)所面临的问题,因此以产品为中心,也就是以解决问题为中心;而相反,以项目为中心的则是以计划、预算和职能为中心。

那么要以产品为中心,组织需要在哪些方面做出改变呢?

首先,以产品为中心,要求管理的核心要素从项目的范围、时间和成本转向给用户带来的实际价值和质量。现在很多软件项目的管理者都有类似PMP这样的认证,对如何在范围、时间和成本这三个因素之间周旋很有经验。甚至一些项目管理者几乎全部的工作就是计算各种PV,EV,SPI,CPI值,通过加人减人、加班等方式来保持项目在计划和预算之内,却忽略了最最重要的事情:团队忙于添加的特性到底有没有价值?解不解决问题?

价值是产品的最核心要素,然而这在传统的项目管理指南中基本看不到对它的关注。由于人的本能,那些提出需求的人(如用户或业务部门)往往提出来的是他们认为的解决方案,而交付团队可能连真正要解决用户什么问题都没搞清楚,只将其视为需要完成的一项任务。管理工作围绕价值开展就需要管理者将最多的关注放到对用户的分析和对工作的优先级排序。

具体的方法包括与用户和各种干系人一起确立明确的愿景,对目标用户群进行识别和特征分析,找到评判一个想法优先级高低的标准,设计可以验证假设的实验;在交付过程中管理好团队的在制品数量,确保集中精力将最高优先级的特性快速交付并获得真实的反馈,从而更好地决策产品方向。

正因为围绕价值进行管理至关重要,在以产品为中心的组织中更加强调产品经理的角色,而非项目经理。产品经理或产品负责人是一个团队实际的决策者,决定产品的方向和策略,对价值负责。即便仍存在项目经理,也只能是一个辅助性角色。

另一方面,虽然每个人都口口声声质量很重要,但时间、范围和成本往往都在前期的承诺中被固定了,对任何一项预先计划进行调整都需要复杂流程,而且会被视为管理者工作做得不好。当管理者努力要保障一切按计划行事,那么很自然质量这个隐性因素就成为二等公民被牺牲了,团队加班加点,或临时增加人手,降低上线质量标准。而且软件有其特征,很多质量问题是无法通过功能验收测试来发现的,设计和代码的恶化很隐性。要以质量为核心,就需要管理者在团队内建立普遍的质量意识,提升团队的工程实践能力,提升自动化水平,形成持续改进的团队文化,而不仅仅是完成功能。

▽ 点击【阅读原文】阅读剩下的内容

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-04-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 思特沃克 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 以产品为中心的模式
相关产品与服务
项目管理
CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档