本文关键点：
\n- \n
- 外包软件开发和军事行动之间有相似之处，有些军事行动策略对软件产品交付也有一定助益\n
- 让销售和售前团队参与前期侦察，并确保将在客户环境中获得的深层理解传递给开发团队，使他们了解客户的情况，以避免在项目后期出现问题\n
- 在项目开始时，清楚解释客户利益和业务结果，可以帮助那些无法与客户天天互动的人，使他们与项目目标保持一致和充满动力\n
- 快速交付优秀的产品可以提升客户满意度，从而使整个项目获得成功\n
- 尽可能缩短参与项目至第一次交付之间的时间，而冗长的、前瞻性的、连续的项目对所有干系人来说可能都充满了挑战\n
简介
\n软件开发项目无疑是项目管理中最具风险的学科之一，天然会受到大量变更和不确定性的威胁，事实证明的确如此，我们的平均成功率低于其他更“确定”的业务领域。
\n我在这里要向读者们推荐一下CHAOS年度报告，自90年代中期以来这份研究报告在该领域就享有盛誉，它基于一个数据库，包含了20多年来收集的数千个各种类型和规模的项目。尽管围绕它的方法论有一些争论，但是这个报告仍能显示软件项目的结果是多少糟糕。
\n伟大的行业思想家已经在努力提升工具、技术、过程和方法，以应对这一行业症状，特别是自从电子时代演变到目前数字革命的洪流以来，面临的挑战越来越大。我们都在努力追赶这些技术进步，以改善我们的结果。
\n然而，一场轰轰烈烈过后，我们在管理软件项目时仍然经常忽略一些通常不为人知的实践。它们之所以被忽视，可能是因为总把自己置身于技术或系统工程方面的实践之中，而没有过多地涉及理论。然而，它们是一种实际和实用的方式，除了承担起构建软件应用程序的繁重任务，还可以显著提高我们的成功率。
\n我会试着在这篇文章中阐明其中三个实践，大家在领导项目时可以自己试试并看看结果，如果你还没有这样的项目，可以先把它们加到下一步提升的技能集中，看看能否在它们身上发现我所发现的价值。
\n因此，我们在这里讨论的主要受众是所有领导软件项目的人。顺便说一下，我们的讨论和方法论无关，只是在所做的事情中会保留一些敏捷风格。因此，读者可以遵循你们在开发过程中采用的特定方法论。
\n起源
\n当你看到这个标题的时候，不要怕，不用缩回到防空洞里，这里没有枪炮硝烟！
\n然而，软件交付和战争之间逐步发展出了许多相似之处：在某种程度上两者都涉及到某种“战斗”。在战争中，对抗的是敌人。在软件中，对抗的是“失败”，而“失败”是任何业务的敌人。
\n至少，中国古代兵圣、军事家孙子的《孙子兵法》和普鲁士将军、军事思想家克劳塞维茨的《战争论》这两部伟大的战争著作，在处理商业冲突和关系方面，给商人们带来了许多策略上的启发。
\n现在，我们这些软件人员正在为成功而战，就像军队为胜利而战一样，我们将利用其相似之处，从战争中借鉴三个主要的概念，以赢得我们与失败的战斗。
\n让我们看看这些诀窍吧。
\n项目情报:侦察任务
\n客户不是敌人，项目也不是天生就有冲突的，但是为了对客户展开“友好”的攻势，您需要充分了解他的领域和能力。这种预先的了解就是我们所说的项目情报。
\n这得先侦察一下。你永远也别把它当作间谍任务，这只是一个道德问题，只是深入观察客户自然流露给我们的东西。但谁会成为“耳目”为你做这件事呢?先看看周围环境吧。
\n销售和售前是赢得新合同的先头部队。为取得胜利，他们会花一些时间建立客户关系，了解人和事，努力去实现目标：签订合同。通过这种方式，他们可以接触到相当多的信息，不仅是纯粹商业相关的，还有关于新战线商业政策的，以及它的弱点和优点。
\n因此，如果签约了合同，销售和售前情报收集人员就过早地脱离项目，直接丢给实施团队，而没有充分利用他们对客户“领域”的了解带给团队帮助，就是重大的损失。
\n我一直认为，从销售/售前到项目经理和业务分析师的深度“交接”是团队协作的良好迹象，也是安全进入项目的一个非常有价值的工具。这个子流程实际上是合同签订前的一个情报任务，销售团队必须好好利用这个任务，为项目管理和团队提供尽可能多的有用信息，这些信息主要有以下四个维度：
\n- \n
- 股份持有人\n
- 他们的决策权和动态\n
- 业务流程和需求。这通常是故事的组成部分\n
- 客户在知识方面的弱点和优点，可以是业务方面的，也可以是实现领域方面的技术。\n
通过这种方式，项目经理可以预见实现过程中可能遇到的风险和障碍，从而更好地规划以减轻这些风险和障碍。至于需求方面，虽然这个信息仍然有点粗糙，但收集到的信息将让分析师能更清晰规划满足需求的最佳方式，基于更多的了解去完成他的任务，使他的工作可以事半功倍。
\n看起来这似乎更多地关乎项目的“进度”，而不是项目的“质量和价值”。但事实上，项目情报对这两方面都有影响，质量和进度都是一样的。适当的情报工作可以避免项目上的“噪音”，这些噪音来自与错误的人的交流，或容忍了客户方未经授权的决定。项目噪声是事情含糊不清的源头，使开发过程不断地出现返工的情况，直接影响进度。另一方面，错综复杂的整体情况会影响团队的士气和对任务的专注力，降低产品的质量和价值。
\n所以，您可以很容易得出结论，适当的项目情报工作肯定会减少项目上的噪音，使交付更加及时，交付质量和价值更高。
\n战略上的团队参与：作战动员
\n在常见的外包环境中，大多数实现团队（除了分析师和项目经理）是见不到客户的，他们对项目的了解仅限于需求规格表、代码、UML图、时间表和测试资料。这对团队的合作过程有什么影响呢?
\n如果以这种枯燥的方式开始一个项目，可能最后也能完成，但却牺牲了故事的激励作用，这是你要付出的代价。肯定，随着日积月累，你的员工就会对自己的工作感到不满意，信不信由你，无聊的感觉会逐渐渗入他们的灵魂，使他们开始考虑新的工作。
\n在关于领导软件团队的演讲中，我经常问听众一个问题，以深入挖掘他们的经验，这个问题是：“当你开始一个新项目时，做的第一件事是什么?”过去得到的答案几乎都与资源调度有关，几乎毫无例外，比如能力规划、预算、WBS和任务分配等等这些纯粹的“管理”方面的东西。
\n问题是，在这些答案中就没有“领导”技能，只有管理。这差别可太大了！我们以军事来类比，上一问题的正确答案是围绕新目标激励团队，激励他们做好工作的准备，做好承受一些压力的心理准备。这就是所谓的“夫战，勇气也”。
\n怎么做呢?其实很简单：将实现团队内部启动会作为一个让每个人与新工作的业务层面保持一致的仪式。主要由项目经理、分析师或者是销售人员向大家演讲，目标是使执行小组能够全面了解下面这些情况：
- \n
- 应用程序的业务内容以及其为客户提供服务的方式。\n
- 应用程序对于客户的市场价值。\n
- 应用程序对于公司的战略价值。\n
- 就所使用的业务和技术而言，在应用程序中预计会遇到的挑战。\n
允许每个人提问、讨论和发表意见，确保每个人都能参与其中。新项目是团队和公司学习和发展的新机会，让我们把握住把它做好吧。
\n当然，您将随着任务分配进一步了解业务方面的细节。但要确保在代码块、草图和一堆堆的表格中别丢失了总体业务目标。
\n依我的经验来看，这种方法可以让团队采取更好的行为，因此团队绩效：
- \n
- 它为开发人员在纯技术视角之外增加了一个新的维度，使他们不再抱着一成不变的工具做着纯技术性的工作，觉得厌倦无聊。\n
- 这让他们有了一种“价值感和尊重感”。让他们参与了解这一层信息就明确地传达了这个意思，表明你把他们当成了“成功伙伴”，而不仅仅是“任务的执行者”，这会极大地鼓舞他们的士气，进而具有更优秀的工作表现，做出更高质量的项目。\n
- 它有助于围绕一个任务粘合团队。很显然，这意味着会有更好的协作和生产效率。\n
采用了这个简单的策略，你就可以和团队和客户一起，顺利飞抵目的地。这，就是成功。
\n第一次交付的魔力：出其不意的原则
\n战争认为，确保胜利的密诀只有一个，那就是：兵贵神速、速战速决，或闪电战，或出其不意，这些都是久经考验的战争战术！软件项目要打的仗，不是关于摧毁的，而是关于交付的。
\n让我们面对现实吧，没有什么比你的第一次交付更能定义你在客户眼中的形象了。它必须非常有用、令人印象深刻、健壮、稳定和及时。它不必大而全，但是在包含所有功能之前，必须要满足上述属性。实际上，敏捷学派的精神就是明智地选择正确的业务价值(ROI)，然后规划第一个交付，我们应关心这个非常特殊的里程碑的质量和健壮性，在任何情况下都不应该妥协。
\n要知道它的风险巨大，如果你的第一次交付不能满足这种期望，不论是进度还是质量，您的客户就会占了你的上风，贯穿整个项目周期：这种情况很难扭转，必然会带来许多不利于开发团队的后果。
\n另一方面，如果您在第一次交付或sprint中成功地完成了不错的演示，那么请放心，您已经采取了正确的“领导”项目的立场，包括“悄悄地”领导了客户，直到项目结束。坚持下去！
\n顺带提一下瀑布法的一个缺点，或者说是关于交付的确定性学派的一个缺点。瀑布开发通常提倡以较长的阶段来构建和交付功能，并按阶段反馈给客户。除非你面对的业务非常非常的确定，比如你设计的产品要面向开放市场，而不是针对特定的客户需求和时间表，否则长时间脱离客户代表就会让人没了劲头和热情，让大家越来越懈怠。
\n此外，即使您交付了一些“工作软件”之外的可交付成果，也就是根据计划做的那些需求、设计文档，扪心自问，客户方谁会阅读、评论、评审它，给它提提意见？对所有这些付出时间和责任心？我相信，我们都知道这有很大的难度。对于客户来说，看到大部分梦想得以很快实现，和花时间和精力去阅读各种各样最全面、最优雅的一叠文章真是大相径庭。
\n这就是你应该做的，迅速出击！
\n但是，如果客户没有为你的第一次快速出击做出所需要的准备和响应，会发生什么情况呢?如果你有此疑问，那么我认为你是一个立足实际的称职的实践者！当然，这个障碍我们必须得想办法跨过去。跨过它的技巧其实早就准备好了，不过那属于另一个专题了，我们很快会在一篇专门的文章中对此进行单独的讨论。
\n最后：注意危险区域
\n既然提到了快速出击策略，那肯定不能忘了强调交付过程中的一个概念性事实，即我所经历并称之为“危险地带”。它实际上是客户从第一次付款到第一次交付合同产品之间的一段时间。
\n为什么它很危险呢?
\n软件本质上是无形的产品，你不可能马上就得到它。即使我们讨论的是套装解决方案，实现和定制客户的需求仍然需要延迟些时日，得人来做些工作。因此，它不像硬件或汽车，掏了钱就可以直接拿走，或者哪怕需要一些规定的交货时间，但对于客户来说需求仍然是有形的，可以从一开始就知道要的是什么。这意味着，除非你按照客户预先的期望安装了第一个功能块，否则付费的客户就感觉花出去的钱不怎么值得了。
\n如果这段时间不断地拉长，项目的风险就会呈指数级增长，你开始在客户那边觉得有些“力不从心”，这将反映在团队身上，对项目产生负面影响。不幸的是，这种情况很难恢复。
\n结论
\n构建软件是一场为了赢得成功的战争。从签订合同到完成合同，会遇到变更、不确定性、客户行为或其他团队相关内部因素的风险，我们很容易受到这些风险的影响。
\n不妨从战争中借鉴一些战术，这或许是处理这些风险的好办法。
\n确保你完成了正确的“项目情报”练习，在参与项目之前已经了解了客户。激励你的员工，让他们充分认识到自己所做的事情的价值，以及它对公司的影响和他们自己职业生涯的影响。用强大的第一次交付征服您的客户，让他默许你控制项目的其余部分。将交付第一个功能块或危险区域的时间降到最低。
\n然后管理你的项目。
\n关于作者
\nMedhat Sabry是一位软件开发顾问、演说家和作家，经常出现在自己基于web的开发社区Techstamina上，以及其他社交媒体和专业网络渠道上。他在软件交付过程的核心领域工作了近40年，对开发行业中出现的挑战有深入的了解，这些挑战激发了他的热情，帮助开发人员和公司建立他们的专业耐力，以应对当今软件市场中不断增长的压力和挑战。
823
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
