经理人在竞争战略中需用好柔性力量
开篇：润墨网以专业的文秘视角，为您筛选了一篇经理人在竞争战略中需用好柔性力量范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
经理人需要为其特定的市场和竞争战略寻求恰到好处的柔性，效率和质量。什么是恰到好处，依次如下，取决于客户需求，竞争对手的能力以及其他因素，如市场的不确定性，或者政府政策（例如在医疗保健和通讯方面的政策）。但是经理人可以使用某些杠杆来平衡柔性，效率和质量，这一点是很清楚的。这可以取决于技术，比如可编程的自动装置。尽管特定的生产管理技术和管理供应商、工人、产品开发策略（例如企业模块化，或者使用企业内部平台的程度）可能更加有用。
产品开发与柔性
引入注目的是柔性相对于技术本身与非技术因素有很大的关系。工人参与问题解决小组，特别是与供应商，产品设计中零部件重用相关的方法在确定柔性时似乎更重要些。拥有最多计算机（可编程自动装置）的工厂事实上柔性最小。这一发现对组织使用其资源，理论能力，选择提高柔性所需的投资类型方式具有重要的启示。例如，经理人在购买最新的技术之前，将会更好地最大化他们现有的工厂，设备和供应商的柔性。
研究表明组织能够使用某些方式来变得非常柔性，也可以用另外的方式来使得工厂有较小的柔性。所以专注于“柔性工厂”或“柔性生产体系”就不是特别有用。而且，我们的研究结果表明，某些柔性类型往往同时改变，如产品组合和新产品柔性，但是产量柔性的动力不同。这一点又有重要的启示：经理人可以选择他们想要的厂商（以及其组织）在哪些方面变得柔性。企业根据环境可能会要求有更多特定的柔性类型，当然，柔性的实现不能以质量或者顾客的安全为代价。
正如我们能够分析在产品制造中的不同柔性类型，我们也能够分析在产品开发中的柔性及其权衡。我研究中的最好的例子又将重温微软为PC和因特网市场进行的敏捷式，或者迭代式的软件开发：相对于为大型计算机所使用的更为缓慢，更为结构化的软件工程。对PC和互联网软件，管理的挑战迅速变成了如何增加足够的结构来避免工程的混乱，但仍然鼓励个人创造力，产品创新，对市场的快速响应，不可预知变化的技术以及顾客需求。
“旧的”软件工程以及许多其他类型的产品开发的结构设计，采取“瀑布”式的或甚至是不那么严格的“阶段一出口”过程，根据这种顺序的工艺过程来执行规则。例如，瀑布式工程中的经理人，通常需要设计详细的需求文档以及详细的设计文档。然后，经理人就会尝试着“冻结”设计，程序员将会根据最初的要求和详细的设计，使得编码和测试的改变最小化。当然，不严格的“瀑布式”或者“阶段一出口”式的过程，在某种意义上来说能使项目更加有效，因为不允许某点之后改变设计，那么就可以使返工以及再测试的工作最小化。但是，在快节奏的市场中面临的挑战是发明创造和创新，或者处于开发与顾客提供的频繁反馈相关联的环境下，“瀑布式”的和“阶段一出口”式过程就变得非常缺乏柔性。在某种程度上这常常导致无效的过程，如果不能满足顾客的期望，或者与时俱进的市场需求时，项目的成员将不得不返工改变其设计，或者是前功尽弃。
比尔・盖茨早年的成功秘笈
在快速变化的市场，比如20世纪80年代和20世纪90年代期间PC和互联网软件，比尔・盖茨以及其他微软的经理人试图保留灵敏的和柔性的小团队，即使产品规模和产品复杂性急剧增加。这发生在当PC产业从基于字符的DOS操作系统和简单的DOS操作系统的应用发展到应用图形程序，就像1984年的麦金塔计算机和1990年Windows PC。微软的“组建可以像小团队那样工作的大团队”尝试并不是一帆风顺的，尤其是在开发Windows Vista其开发团队达到数千人之际。但是，微软已经足够成功了，尤其是在像Word和Excel（现在是Office的一部分）应用项目上，这两款软件首先是为麦金塔计算机开发，其后为PC开发。公司还遵循相同的敏捷或迭代原理，这些原理在Windows 7项目中被再一次证明是非常有用的。微软在退役军人史帝文・斯诺夫斯基和乔恩・德瓦恩的带领下，在2009年秋天完成了这个项目。他们两人都曾经领导过Office小组，管理过Windows团队以及“修复”过Vista中的问题。斯诺夫斯基德瓦恩在20世纪90年代初帮助提炼的原理，以及这些原理对Windows 7的适用性是后面讨论的重点。
使大团队像小团队那样工作
我们也许可以发现对这个表述的最佳解释需要结合柔性和结构，在我最喜欢引用之一中的《微软的秘密》（1995）。微软的前任Windows 95的测试经理戴夫・冯瑞兹，解释了如何利用他作为以色列坦克指挥官的背景，施加简单但是严格的规则，以保持高度个人主义的软件开发商之间的协调：
在军队中，当发生坦克战而我就在坦克里进行战斗，没有什么比从无线电对讲机中听到指挥官的声音更加令人感到安慰了。即使是一团糟，仍然有一个人正在负责一切……如果有15分钟到半个小时以上听不到时[指挥官的声音]，发生了什么事情呢？他负伤了吗？他失去了控制吗？他知道现在的情况吗？你就会十分焦虑。这也是微软所面临的情形。这些小办公室，门一关就与世隔绝。如果你不时时刻刻通过电子邮件发出权威的命令，公司就会停止运转。我现在做的一切都是从军队学到的……如果没有组织性，你就不可能做成任何复杂的事情……你要做的就是使这种组织性尽量隐蔽起来，并且要给所有这些傲慢的家伙造成一种印象，觉得他们仍然可以喜欢什么就干什么。谁去在乎一个家伙是否整天不穿鞋子到处乱走？谁去在乎这个家伙上班时间胡子乱糟糟的？我是不在乎。我只想知道……是否有人在5点之前没有登记他的程序。如果有的话，那个家伙就肯定知道我要闯进他的办公室。
冯瑞兹描述的这幅场面就像高度灵活但是协调的军队：在各自办公室（类似于个人坦克）工作的微软程序员的所属部门通过电子邮件和公共过程来协调。5点钟就是关于Windows 95组检查每天所编写代码的截止时间。此外，编码创造了产品的工作版本，以便于工程师能够测试新增的功能，确保在现有的特色仍能正常运转。每日构建是其“严格”组织目标之一，使得每个人都集中在一个项目之中。
绝大多数微软的经理人和程序员同样地避免了更高层次的结构和，我们可以从日本的软件厂商，或者在印度符合美国软件工程研究所的实践（CMMI 4级和5级）的先进的软件工程设施中看到这种更高层次的结构和。相反，微软的经理人和程序员往往试图将非正式化的小团队风格“按比例放大”进行软件开发，依靠每日构建和持续的测试来整合一些相对小的核心团队的工作。这些团队一般由5到8个软件开发人员，“结对”测试者和一个项目经理（组成。这些团队遵循一些高层次的法则（阿德勒称之为“元程序”）。
保持小团队一个显而易见好处就是使项目小型化，如通过限制他们的规模和范围。例如，相对于做一个需要4年的大项目，最好是将目标和团队减少一半，计划为两个18个月或24个月的项目。这种计划安排在20世纪90年代后期和21世纪初期变得更加困难，因为微软想要赶超网景，增加了成百成千的程序员到Windows团队。首要目标就是给Windows增加一个浏览器窗口，然后微软需要一个媒体播放器，一个搜索引擎和其他各种技术以及更好的安全特性，同时与谷歌，Linux，太阳微系统（Tava语言）以及其他的公司竞争。尽管如此，经理人需要给每个项目试图完成的目标设定界限的想法是正确的。在汽车行业，某种程度的设计改变需要在生产设备上如金属冲压模具，塑料模具和物理上有影响的相邻组件，发生了高昂的变化。汽车公司也要为每一种新的模型应对数以百计的供应商。因此，汽车设计相对于软件的开发在有关改变控制方面，除了像航天飞机上的软件，SDC或东芝公司专业的核电厂商控制软件编程应用是真正的关键任务之外，通常有更多的纪律。
要限定好团队规模
汽车公司通常尽可能地将设计变更限制在建模和原型阶段，使用计算机及其他技术来增加其柔性，这样生产许多原型和测试模型就变得更容易。汽车设计者也大量使用计算机辅助工具，模拟程序和能够允许项目在计划表的尽量延迟某些最终决定的其他方法。例如，工程师可以锁定某些规范和接口，如汽车门要设计多大，如何适应汽车车架，并允许同步进行做一些生产准备和模切。但是他们可以延迟最终的决定，即直到最后一刻才确定车门外表面准确轮廓。
限定能在任何一个项目工作的人数也是有用的。微软在应用项目如Word，Excel和Oflfice套件上比Windows更为成功。这些应用在历史上比操作系统组具有更简明扼要的目标。此外，项目经理通过设定时间限制，如用12个月或28个月生产一个软件产品的新版本，或用四年为一辆汽车生产一个新的模型能够聚焦项目。时间的限制，尤其是与员工的限制相结合就可以使团队做出利用所分配资源的决定。这提高了效率并产生了创造力。项目团队没有优先级和时间的限制往往会尝试去做太多的事情，但是却没有一样事情能够做得非常好。
再次重申，微软案例中应用组通常比Windows组更擅长于规定时间和员工的限制，Windows组往往目标模糊，对时间或人力资源没有实际的限制。应用系统增加功能比操作系统的技术上更加简单，所以在工作一段时间后更容易停下工作一个应用产品。应用组能够推迟未完成的功能到下一个版本，应用系统版本通常比操作系统版本更频繁地。
微软的应用系统开发和操作系统开发之间的柔性程度有所不同，也反映了产品不同产品架构以及不同的竞争情况。Windows是DOS代码库基础上演化出的特定方式，导致了更复杂的相互依赖的功能。Windows组几乎没有什么竞争力，通常计划项目要持续若干年，并已学会了将重点放在可靠性，与以前的应用程序和硬件的兼容性和安全性上。这些属性现在需要多年的测试，因为程序的规模大和过度复杂的架构。应用组已经将重点放在模块化和易用性上，通常组织更小的，时间更短的和重点突出的项目。
微软的例子表明，即使是对项目资源如时间和人员更多的限制，产品架构在提高柔性以及使大团队像小团队那样工作中扮演着至关重要的角色。产品架构被广泛应用于许多产业的核心技术就是模块化，将大的，复杂的系统分解成一组更小的和更独立的特征，功能部分或者子系统。因此，经理人能够将大的项目细分成更小的子项目和团队，在逻辑上能够反射出产品细分的结构。例如，微软通常将其应用产品和项目划分为相对较小的功能和核心团队。这种架构使得优先开发这些功能，将其归为一个团队并把最重要的或技术上相互依赖的部分优先构建，然后再轮到另一组特征等等。
里程碑的价值
另一个有用的方法是将一个大项目分成子项目，微软被称之为里程碑。微软在移向下一个里程碑之前，核心团队通过为每一个特性，或者组件的子集进行一个完整的开发（设计和编码），测试和稳定的周期。目的就是避免构建并且同时试图集成太多的特性。项目经理也想要避免对未来太遥远的目标，考虑到会发生太多的变化。微软至少在Windows 7之前，应用程序在限制变化以及密集的里程碑进度计划方面更为成功。随着产品被分成更小的特性，甚至这些特征又被分成子特性，使得项目能够将工程分解成小块，少数人通常就能够在短的时间内完成，例如半天完成。小型团队和个人也对其工作负有更加直接的责任，拥有知识和自来调整或者修改其产品中的某些部分。
现在我们来谈论该过程的关键之处：某些硬性规定使得个人和小团体像一个团队那样工作（即效率），但是没有过度地抑制个人的创造力，或者作出产品设计改变的能力（即柔性）。我们在20世纪90年代观察微软的时候，塞尔比和我发现了完成这个目标的三种实践。
1、每个项目都必须要创造一个每日构建。
2、没有一个登记新代码的人被允许打破构建，程序员必须立马解决任何问题或收回其改变。
3、项目必须再细分为里程碑子项目来减少他们所做事情的复杂性并且更加聚焦于团队。
我们为其他规则的不足而感到震惊。例如，开发人员可以自由地在他们高兴的时候来上班，只要他们喜欢，既可以很频繁地也可以很少地为产品构建做出贡献。然而，开发人员必须在一个规定的时间里检查其工作，不允许登记会导致演化中的产品停止工作的代码。这就需要可观的投资来做持续的测试：每个开发人员分配了对应的测试人员，以及一系列的自动化测试工具和测试用例。
没有良好的人际沟通和正式或非正式的实践促成适当的信息交换，那么基于团队的过程就不可能变得有效。我们看到了在微软中有效的若干实践。例如，尽管有职能的专业化和劳动分工，但人员间还是共同承担绝大多数的任务和责任。项目经理和生产经理在撰写产品愿景陈述时通常承担共同的责任。项目经理和开发人员也一起定义产品的特性。开发人员和测试人员一起测试代码。项目经理，开发人员和测试人员在新产品后都帮助回答客户支持电话。此外，微软尽可能使同一个产品在同一地点进行开发，使用共同的编程语言以及其他的工具。绝大多数的团队也尽可能避免官僚化，尽管这在公司和团队规模壮大的时候变得更加困难。
最后，我们发现如何使设计柔性到过程并能够适应意料之外的变化。尤其是微软假设产品的规范将持续演化到项目的终点。这是为了吸收原型内部用户的反馈，可用性实验室通过典型客户和测试用户尝试新的功能。愿景陈述引导了一个项目的整体目标，但这与瀑布式的说明文件不同。至少在20世纪90年代中期，项目经理预计微软最终的产品目录将会改变，相对于项目刚开始的原始估计要增加20%―30%。此外，项目为了适应变化，包含了事先安排了缓冲时间（应用项目大约20%的时间，操作系统项目和全新的产品50%的时间）。每一件重大事件发生后都要举行事后反思会议并撰写报告，项目结论也鼓励了员工随着团队经验的累积而与时俱进，并持续地演化其开发过程。
这些实践没有一种是软件开发所特有的。几乎在任何一个产业，时间和人员限制都是有意义的。因为这些限制能使得团队在竞争面前专心致志，并提供给客户一些有用的东西。正如在软件工厂或者多项目管理中一样，将复杂的系统分成模块或子系统，以及组件的重用和设计一些组件，以便复用等都是良好的工程实践。创造项目团队映射到产品的架构，组件或子系统中是很好的管理实践。如果团队具有实验的自改进其正在进行的设计或过程，也将变得更加有效和具有创新性。
与此同时，项目需要一些严格的规则使得个人进行频繁的沟通来协同其工作。良好的沟通机制，同一场所（或国家最先进的通信技术）工作，共享工具和技术，官僚陈规陋习最小化等能够鼓励进行有效地协同。众所周知，项目经理应该允许产品规范的演化，安排缓冲时间，包括即时的过程改进。项目经理在快节奏的开发周期短的产业中需要适应许多的未知事件以及进行有用的学习。当然，企业必须聘用能够应用最少规则来运作和应用判断力的人才使其行动方法最佳并在其他场合具有柔性。
惠普之道
我的合作者和我在惠普（和研究期间分出来的安捷伦科技）开展这项研究之前，对各种技术做了更详细的分析。我们的目标是比较强调迭代或者敏捷技术的项目与强调瀑布式技术项目的绩效。
最重要的发现是至少在单一的开发文化（惠普和安捷伦），尤其是技术似乎作为一组相关的实践在起作用。当相互结合在一起使用的时候，消除了彼此间效率和柔性的折中。惠普和安捷伦将几种技术而不仅仅是选择其中的一种或两种技术结合起来使用时，软件项目能在对质量影响最小的情况下调整后期设计，使之变得更加柔性。具体地说，当惠普和安捷伦使用初期原型的测试版本来获得用户的反馈，管理设计审查，对每个版本进行回归测试，或者集成测试（即在每次改变，或者产品添加新的附加功能）时，开始编码时不完整的设计和“错误”间的相关性就消失了。
统计分析（多变量回归分析）也提供了一些非常详细的洞察力。三个因素解释了项目之间将近四分之三（74%）的缺陷的不同：客户多早能够看见到原型，项目是否做了设计审查，项目是否对每个版本进行了回归测试和集成测试。关于质量和生产率水平，相对于中位项目，我们也发现了一些令人震惊的结果：
更早原型（即用20%的功能与中位水平的40%进行比较），与缺陷率减少27%和代码行生产率增加35%相关。
对每个代码进行集成，或者回归测试检查与缺陷率下降36%相关，这是与中位项目的再一次比较得到的。
进行设计审查与缺陷率减少了将近55%相关。
进行每日代码构建与将近两位数（93%增长）的代码行生产率相关。
当然，度量生产率和质量有不同的方式，尤其代码行是一个非常粗略的度量标准，每一代码行的缺陷不会显示出客户的满意，或者产品的经济价值。尤其是我们有一些来自大样本研究的具体的成果，可以肯定在其他研究中发现的观察结果。尤其某些实践被一起应用的时候，似乎能够消除生产率，质量和柔性之间的折衷的结果，与PCB的研究有明显的相似之处。与许多研究者在其他制造和工程运作研究中所发现的是一致。