传统行业敏捷转型案例丨美国大超市Target的3大阻碍

这个敏捷转型案例证明：仅有敏捷远远不够，只有解决了架构刚性、人才紧缺的问题，并且采用产品导向型的开发模式，企业才能充分发挥敏捷的力量。

对于希望时刻紧跟用户需求和行业趋势的公司来说，敏捷开发非常关键。采用敏捷开发后，软件研发团队能够快速创造新的产品和服务，转变开发流程，甚至更加合理地改造组织架构。不过敏捷团队也会遭遇困难，由于他们需要与其他团队相互协作，提前预期并妥善处理可能出现的问题非常重要。 
假设一家信用卡公司希望升级他们的移动端应用，以使客户能够更加便捷地查询并兑换积分。那么下面就是开发筹备试验期间会出现的问题：

• 要创建一支敏捷开发团队，包括开发人员、设计师和项目负责人，负责人要能够深入理解用户行为，在开发过程中决定重点和优先顺序。
• 开发团队花费了数周时间对应用进行升级，而另一个团队又要花费数月时间提供积分系统的数据源，此后其他团队还需要花费更长的时间将这些改进嵌入到应用之中，新功能的推出被严重推迟。 
• 客户喜欢这个新推出的功能，但他们还希望在登陆的时候就能查看到最近的积分活动。
• 原来的敏捷团队很可能已经解散了，现在各自都有新的任务，想要再组建一支敏捷团队又要花费数月的时间。如果新团队做出了功能的调整，但又因疏忽了一个缺陷，导致新版本未能通过安全漏洞测试，即便是后来修复了这个问题，运营团队也可能拒绝推出这个版本，除非再经过更彻底的全面测试。那么这时开发团队和运营团队之间的矛盾又会导致新版本的延后推出。 

这样的状况对很多公司来说都很常见，即便是那些技术过硬的企业，上面提到的这个案例，其实就来源于几年前塔吉特公司所经历的。
经过了数年的发展，塔吉特公司累积了巨大的技术债务，公司的核心业务是由整体架构组成的，严重限制了创新和变革的便捷程度。经营规模的扩张还意味着公司对技术资源的需求也在上升，尤其是第三方承包商对技术支持的需求。

塔吉特和其他公司在技术变革上遇到的问题告诉我们：

敏捷开发非常强大，但那远远不够。想要拥有高度有效的数字化组织，公司需要给敏捷开发之路装上“减速带”，软件开发不能一味求快。

敏捷开发常伴随以下三个阻碍：

1. 刚性架构
2. 人才管理落后
3. 缺乏产品思维

在这篇文章中，我们将逐一介绍这些阻碍，并给出实用的解决方法。 

阻碍一：刚性技术架构 

在IT行业，多年来一直在膨胀的数据库和升级补丁已经让许多公司的技术架构失去了灵活性。
大多数公司提供给用户的应用软件都是在更科学的设计架构出现前开发完成的，饱受刚性架构之苦，太多的功能都被耦合在一起，如果你想要对其中某一段代码进行变更，产生的影响可能如同雪崩。 
在大多数情况下，要用应用程序编程接口（API）及微服务架构（microservices）对系统进行重新架构不现实，事实上，绝大多数公司采用的都是下面四种更常用的对策： 

• 无为而治。一些应用可能太过渺小或更新频率不高，不值得进行改进。 
• 包装美化。更多地向用户展示经过良好设计的功能，在开发新功能时再采用更加现代的架构体系。 
• 体系重构。重新设计应用，包括拆散原有数据库，将其设立为相互独立的部分，移除其中的硬编码值。 
• 重新开始。用现代架构模式如微服务架构搭建新的应用，取代原来的旧应用。 

对于架构中不同的部分，可以采取不同的方法，高管需要在决定选用哪种方法时，权衡各自的潜在价值。需要考虑的方面有对新功能的需求度、与系统的交互频率、现有应用带来的成本、对数据拆分的难度、业务中断的风险。 
塔吉特针对这些问题做出了决策，他们将打造现代化系统置于优先地位，公开常用的关键数据，例如物品价格和供应量等，对于运行良好的遗留事物系统则没有改动。
这种优先级决策，使得团队能够集中精力优化用户体验，让用户能够更便捷地搜索、兑换物品，而不是把时间浪费在从几个定价系统中选择哪个最准确。 

阻碍二：人才管理落后 

人才是数字化运营模式中的核心，高管也应该清楚他们需要招募的是能够负担得起的最优秀的人才。
然而，过去几年的经验告诉我们，想要招到对的人来提升IT企业的敏捷性太难了。 
例如，许多公司领导发现他们的IT经理并不能从商业视角来看问题，于是就开始招募更有商业头脑的人来替代。这些新招来的人都尤其善于交谈，能够理解业务与技术的优先度，和公司内部人员也能和睦相处。

所以导致人才管理落后第一个问题就是：这些人很多都不是深度的技术专家，因为公司领导在招人的时候更愿意选择与自己谈得来的，许多公司在技术、技能方面仍然比较吃亏。 

第二：技术外包形式的出现，一定程度上也加剧了技术人才缺失的问题。
从外部借调人才在某种程度上对企业有帮助，能够迅速帮企业解决遇到的困难，获取新的技能，或弥补企业人员不足的缺陷。可是有些企业过于依赖这种方式，公司内部的人才大多数时间都在将任务接洽给承包商，他们自己的技能不断退化。
这导致技术承包商垄断了大量的人才资源与创新能力，形成了强大的市场竞争力。在这样的情况下，倘若公司里一半的人都不是你的员工，你又怎么指望科技企业进行变革呢？ 
第三：公司内部权责模式的创建，例如产品的构建和维护的过程中，如果出现问题该由谁负责。
许多公司将产品的开发和运维区分开来，因为这样便于将产品后续的运维支持外包给第三方。
但是，如果大半夜的软件出现了问题，到底应该找谁解决问题呢？是写代码的人还是负责运维的人？

在敏捷团队中整合开发、运营和维护，能够解决不必要的职责纠纷，建立明确的端对端问责机制，这也是DevOps原则的核心要义。 

要解决这些问题，科技公司需要作出重大调整，加强技术人员的技术水平，减少对外包商的依赖，明确划分责权利。
如今，绝大多数科技公司都有三种人员分工：监督的人、干活的人和思考的人，但未来的IT行业势必会有变化，这些人员分工也必须进行调整。尤其是监督者，在公司中主要是指项目经理、业务分析师和资源渠道经理，他们需要在未来承担更多的职责。
新工作方式在敏捷开发中得到广泛运用，意味着更合理的安排、更重的义务和更透明的过程，也意味着对业务和技术缺口间的外包商更少的依赖 。

一些公司已经意识到了变革的必要性，已经开始重新设计公司的人才模式，他们主要依据以下几点原则： 

1. 重点发展技术型人才

IT企业应当寻找技术过硬的人才担任项目经理，既有能力核对程序员编写的代码，也具备适当的商业头脑，能够与产品经理和业务主管紧密合作。项目经理主要负责系统架构的技术可行性，同时汇聚各方英才。 

2. 重新定位监督者

甄选出最有能力的人才，拓展其职能以增加其对公司的价值。
例如，有创新思维的项目经理可以通过培训成为组织的敏捷教练，一些优秀的分析师可以发展为项目负责人。然而，现实是监督岗的人数远超过新运营模式下的新岗位，新模式是否有效且高效，主要取决于你赋予团队多大的权力与义务，以及去官僚化的程度。 

3. 民主问责制

新的人才模式中，干活的人也要承担更多的责任，扮演更丰富的角色。例如，产品计划中要兼具开发和运维。
曾经有一位客户的研发经理问到：“我们最优秀的开发人员要在半夜接听多少个有关产品问题的电话才能下班？”首席技术官回答道：“我也不知道。那我们又要给他们打多少次电话，才能叫醒他们写出更好的代码呢？”开发人员始终承受着开发很多功能的压力，难免会有疏忽之处。产品经理考虑到这个问题，也会让开发人员坚持在岗位上，毕竟他们对产品的质量负有最大的责任。

在新的模式之下，这些开发人员要与运营团队协同合作，他们主要负责简化代码的集成和部署，就不必在解决市场反馈方面花太多的功夫。

4. 减少对外部承包商的依赖

公司内部的软件创新应当主要来自于员工的努力，这意味着需要将任务进行分类，组建敏捷开发团队，按照合理的比例结合内部和外部的人才。
也就是说，不应该矫枉过正，切忌人为地盲目砍掉对外部人才的需求。企业需要对自己的目标足够清楚，依据客观的需要进行人员的配比，合理地将资源分配在技术管理和人员招聘上面。 
例如，塔吉特以前采用的传统招聘模式并没有招到适合的技术人才，把公司引领到目标的位置。因为企业对于技术人才外包的依赖，限制了它对于打造软件工程师社区的远见。
但是塔吉特在经历失败之后，选择转向开源技术，对外宣布了公司进行转型并发展数字科技的雄心。塔吉特此前坚持使用自己的专有代码，导致难以聚集足够多优秀的开发人才，因为许多优秀的开发人才都更偏爱在开源数据上工作。塔吉特的这一举措有助于吸引并留住优秀的稀缺技术人才，减少对第三方的依赖性。 

阻碍三：敏捷开发需要产品导向型的开发模式 

在敏捷开发日益盛行的世界，传统的项目导向、瀑布开发等模式逐渐被淘汰。相比于敏捷开发，后两种传统开发模式不够灵活，对于市场和客户的响应不足。 
向敏捷开发的转变会带来一些问题，但相较于转变后数字化开发的产品和服务，这些问题并不是无法解决的。将以下的产品管理实践与原则充分应用，就能帮助产品经理尽快跨越转变的鸿沟。 

1.以产品而非项目为中心进行组织

以产品为中心组织开发工作，能够更好地结合产品的开发与市场的需要，因为产品的诞生主要是为了解决某个行业痛点或是迎合市场机遇，通常表现为新的功能或用户体验的改善。技术研发团队和管理团队要共同决定开发的目标和优先级，每一个产品都要设置一个负责人，制定产品路线图，选择衡量进度的指标，在关键阶段作出正确的决策。 

2. 建立稳定的工作团队

在项目制导向下，开发团队会不停的组成又解散，而产品导向的队伍在整个产品的生命周期中都将延续，在需要进行改进的时候继续合作。团队的稳定性能让队伍更加高效，快速反应。 

3.进行长期融资

由于产品有较长的生命周期，团队需要每年为产品融资，以支持长期产品路线图的实现。
一些首席财务官和公司的控制者可能会对这个变动持谨慎态度，但产品导向型的开发模式实际上能带来更加稳定的结果，因为对产品产出的测度是可以持续进行的。每个季度重新评估融资状况，适时地调整开发的优先级，或是改变投资方向，以更高的回报率超越其他产品。 

许多数字化企业早已采用了产品导向型开发模式，因为他们主要的产品和服务就是软件等，现在更多的传统企业也开始接受这样的理念。

例如，塔吉特将其技术研发与其商业能力和顾客体验紧紧地结合在一起，他们250多位产品经理都像是独立的企业家一样，各自追求着可测度的商业投资回报，那些能够获取高额回报的产品经理，能够获得更多的资源和职责。 
敏捷开发是创造价值的有效方法，但就其本身来说，光有敏捷是不够的，不过许多企业都在努力地获取敏捷开发带来的技术、人才和产品管理上的优势。
一些敏捷开发的批评者认为，这种方法只适用于数字化的企业，这些企业才具有较大的潜力。解决架构刚性、人才紧缺的问题，采取产品导向型的开发模式，这些都需要企业领导及技术领袖承担足够的责任，并持续付出努力。

如今看来，这些方法本质上就是决定商业目标与技术目标之间的优先级，只有真正愿意且努力让企业更好地走向敏捷开发的公司，才能够享受到不断积累起来的收益。 

原作者：Will Poindexter and Steve Berez 
原文：Agile is not enough
未经允许，禁止转载