拯救逾期项目的技巧和窍门

我的一位朋友经营着自己的离岸开发公司，他最近遇到了一个客户让他头疼不已的情况。一个版本已经严重延期，客户每天都在抱怨，他不得不自己掏钱支付团队的工资，而客户却不断增加变更需求清单等等。这是典型的离岸开发故事。我们讨论了一些想法，希望能帮助他摆脱这种困境，并确保这种情况不再发生。

Kabir：嘿，你能帮帮我吗？我的客户让我们免费加班两个月来修复我们上次交付的bug。我们照做了。但在他看到成果后，他却提出了一百项变更，他设法将这些变更说成是bug或缺失的功能，并让我们在过去两个月免费工作。他每周都发来新的变更。我们不知道什么时候才能完成这个迭代。

Omar：我明白了。在你开始开发之前，有没有拿到客户签署的需求列表？

Kabir：当然有。他发给我一份Word文档，解释了他想要什么，我们给他一份任务分解和工时估算，总时长为三个月。现在三个月后，当我们向他展示产品时，他说这根本不是他期望的。然后他发来一大堆要修改的东西。

Omar：那些都是bug吗？

Kabir：当然不是。大多数都是新功能。

Omar：那为什么不直接告诉他们那是新功能呢？你有原始的Word文档可以证明。让他指出Word文档里哪里说了需要做X？

Kabir：嗯……他很狡猾。他总能把事情说得好像X是理所当然需要做的，而且他不会接受一个需求在X完成之前是满足的。例如，他说首页必须有一个完整的登录表单。所以我们做了一个典型的登录表单，包括用户名、密码以及确定和取消按钮。现在他说，邮件验证在哪里？我们说，你没要求。他说，“这是理所当然的，每个登录表单都有找回密码和邮件验证；我说的是*完整的*登录表单，不是半成品。” 所以，你看，我们不能为了维护形象而争辩。然后，我们按照他说的完全一样的方式做了登录表单。现在他说，客户端的验证，比如正确的邮箱地址、用户名长度、密码确认在哪里？我们说，你没要求过！他说，“拜托，现在哪个网站没有AJAX客户端验证，我什么都得告诉你吗？你们不够聪明自己想不出来吗？你们已经做第三次了，这次不能做得好点吗？”

Omar：好吧，停。我知道你的问题了。有些客户总想用更少的钱让你做更多的工作。他们会想方设法榨干他们付出的每一分钱。所以，你必须非常小心你向他们承诺多少，并确保在开发过程中或交付版本时，他们不能再添加更多需求。模型图是确保你和客户之间一切都清晰的好方法。你没给他看你要构建的功能的模型图，并让他签署这些模型图吗？

Kabir：是的，我做了一些模型图。但它们很简单。我没有展示验证或发送验证邮件之类的所有辅助工作。

Omar：你有没有让你的工程师审查过这些模型图？他们可以告诉你这些细节。

Kabir：没有，我没有。因为在客户签字之前，开发人员不会介入项目。所以，我为了省钱，所有的模型图都自己准备。

Omar：那么，这就是第一个问题。模型图和客户的Word文档一样模糊。基本上，模型图只是反映了Word文档中的句子。模型图并没有真正显示所有可能的导航（确定、取消、找回、注册）、系统消息、后台系统操作、工作流程等。你明白我的意思吗？

Kabir：是的。拜托，我不是开发人员。我不可能想到所有细节。这就是开发人员开始工作时要做的事情。

Omar：但是你是根据你的模型图来估算费用的，对吧？所以，如果模型图只显示一个简单的登录表单和更改密码链接，你就收5个小时的费用。但随后当你意识到你需要发送更改密码邮件，邮件需要包含一个令牌化的URL，这个URL需要显示一个更改密码的表单，你还需要通过CAPTCHA进行验证等，这就会变成20小时的工作。对吗？

Kabir：嗯，是的。通常我会把所有估算乘以1.5来确保安全。但事情已经偏离了原始估算的3倍到10倍。

Omar：是的，我只是举了个例子，说明当模型图没有经过工程师审查，并且重要问题没有得到解决时，一个登录表单的估算可能会偏离4倍。

Kabir：所以，你的意思是，我必须和工程师一起准备所有模型图？

Omar：总的来说，是的，因为你不够熟练，无法自己弄清楚；没有冒犯的意思。等你构建了几个产品，经历了几次“被踢屁股”之后，你就会变得足够好，就像我一样。我被踢了大约17次。在那之后，我就变得如此厉害，以至于当我坐下来时，我能制作出非常好的模型图。再被踢几次后，我希望我的模型图能达到100%完美。

Kabir：好的，那么流程就是，我从客户那里拿到Word文档。我从中制作模型图。然后我交给工程师，让他们添加更多细节。然后与客户评审后，我再交给工程师进行估算。然后我要求客户签署模型图和估算，对吗？

Omar：嗯，首先我想说，你不应该进行长达三个月的迭代，因为你离客户很远。你应该进行为期两周的短冲刺。你知道SCRUM吗？

Kabir：是的，我们的一支团队这样做。

Omar：我猜被“踢屁股”的团队没有这样做？

Kabir：没错，他们没有。

Omar：好的，那么首先你要开始做SCRUM。我不教你细节。你可以在线学习SCRUM。现在，你从客户那里收集‘用户故事’。如果客户不给你用户故事，只是模糊的需求段落，你就把需求分解成小的用户故事。明白了吗？

Kabir：不，举个例子。

Omar：好的，假设客户想要一个*完整的*登录表单。你可以将其分解成几个故事，比如：

• 用户从首页点击“登录”链接，以便用户可以登录系统
• 用户在用户名文本框中输入用户名（最小5个字符，最大255个字符，仅限字母数字）
• 用户在密码字段中输入密码（最小5个字符，最大50个字符，仅限字母数字）
• 用户在输入用户名和密码后单击“确定”按钮
• 系统验证用户名和密码，并在凭据有效且用户有登录权限且账户未被锁定时显示安全门户

明白什么是用户故事了吗？

Kabir：是的，但你忽略了我们之前也忽略的所有验证，现在我们却免费工作了两个月。这些“用户故事”根本没用。

Omar：等等，你只看到了用户故事的基本步骤。现在，你用以下内容描述每个用户故事：

• 用户所有可能的输入及其有效格式
• 无效输入的所有可能的系统生成消息
• 从主要用户故事出发的所有可能的备用导航。例如，在输入密码时，用户可以单击帮助图标，以便用户可以看到允许的密码类型。

明白了吗？

Kabir：现在开始有意义了。然后呢？把这些用户故事展示给客户？

Omar：不，把它展示给你的首席工程师，他有足够的经验来识别你是否遗漏了什么。你的工程师应该指出至少所有可能的系统操作。

Kabir：如果我的工程师想不出来怎么办？如果他也和我一样笨呢？

Omar：解雇他。给自己减薪。

Kabir：说真的，如果那样怎么办？

Omar：你的工程师*总是*会发现你的模型图有问题。你总是需要另一双眼睛来验证你的模型图并添加更多细节。你不是世界上唯一的聪明人，你知道吗？

Kabir：我以为我就是，好吧。接下来呢？

Omar：将这些用户故事分类存储在你的问题跟踪系统中。例如，“用户故事”类别。你用什么来跟踪你的问题？

Kabir：Flyspray

Omar：足够了。在Filespray中创建一个名为“用户故事”的新项目。为用户故事创建任务。每个故事一个任务。将模型图附加到任务上。然后为你的客户创建一个账户，以便客户可以登录并查看用户故事，发表评论，提出修改建议等。你将与客户的对话记录为任务中的评论。这对工程师和以后解决争议都很有用。此外，让你的客户正确地确定任务的优先级。明白了吗？

Kabir：我不认为客户会费这么大劲。客户会要求一个包含所有用户故事的Word文档，并在文档中写下他们要做的修改。我必须在Flyspray中反映这些。将用户故事保存在Flyspray中真的有必要吗？我不能只和客户维护一个Word文档吗？

Omar：绝对不行。Word文档存在版本问题。你有你的版本，客户有他的版本，工程师有他们的版本。用很多用户故事的Word文档来同步简直是噩梦。此外，引用特定的用例也会有问题。比如项目后期，有个bug需要引用用户故事#123。你不得不说用户故事#123在*\\centralserver\fileshare\user stories1.doc*。现在如果*\\centralserver*挂了，或者你把它放在别处，所有这些引用就都没了。不要用Word文档。把所有东西都放在网上，你可以用URL或简单的数字来引用它。另一个问题是在Word文档中给故事编号。Word不会为你生成唯一的ID。你最终会得到重复的用户故事编号。如果你使用Flyspray，它会为你生成唯一的ID。

Kabir：好的，我来看看怎么说服我的客户使用Flyspray。

Omar：是的，你应该这样做。如果Flyspray对客户来说太难，就用一些简单的、对非工程师来说易于使用的issue tracking system。一些花哨的AJAX待办事项列表网站就足够了，如果它有图片附件功能和自动任务编号功能。

Kabir：好的，我会找一个这样的网站。所以，我有了用户故事。现在我把它们展示给客户，进行评审，进行修改。最后，我让客户对两个星期的冲刺的用户故事#X到#Y进行签字，对吧？然后会发生什么？

Omar：在冲刺的第一天，你会召开一个冲刺计划会议，在会上你将用户故事展示给工程师，并让他们将每个故事分解成小的任务，并估算每个任务。确保没有工程师为任何任务设置1天或2天。将它们分解成更小的任务，例如4小时的任务。这将迫使你的工程师仔细考虑故事，并及早发现可能出现的问题。通常当有人说这需要一天或两天时，他并不知道该怎么做。他没有考虑完成任务所需的步骤。你得到一个估算，要么过高，要么过低。强迫工程师将任务分配到4小时以内，可以让他们仔细思考步骤。

Kabir：如果工程师进行如此细致的估算，他们会花至少一个小时来思考每个任务。这需要几天才能完成如此多的任务估算。你一天怎么完成？

Omar：我们有一个4小时的计划会议，期间产品负责人向工程师解释故事，然后在30分钟的休息后，再进行一个4小时的会议，工程师在此期间选择故事，将它们分解成任务，并即时估算。这个4小时的期限严格遵守。如果产品团队无法在4小时内解释完一个冲刺的任务，我们就不会在这个冲刺中做这些任务。如果任务太复杂，或者任务太多以至于无法在4小时内解释完，工程师很可能无法在一个/两周的冲刺中完成它们。同样，如果工程师无法在4小时内完成任务估算，这些任务就太复杂了，无法估算，因此很可能无法在冲刺中完成。所以，我们也会放弃它们。

Kabir：这不可能！没人愿意一天参加8小时的会议。此外，让他们当场估算任务非常低效。他们的估算准确率不会超过60%。他们会给出一个笼统的估算，然后就走开了。

Omar：不对，如果工程师不能在10到20分钟内完成任务估算，他们根本就没有估算能力。如果你的工程师习惯于从你那里接手一个任务进行估算，然后回到办公室，打电话和朋友聊天，喝汽水，到处走走，和同事闲聊，到了晚上才有心情坐下来思考估算，然后打开一封新邮件，写上数字发给你；他们最好学会按需、及时地这样做。这是他们需要学会并应用到生活中的一项纪律。估算是他们从醒着到睡着一直在做的事情。此外，计划会议是估算任务的最佳场所——所有工程师都在，产品团队也在，你的架构师应该在，QA团队也在。这样很容易提问，获得想法和帮助。

Kabir：我有一些工程师就是无法在压力下表现好。他们需要一些不受干扰的时间，可以让他们在没有人盯着的情况下思考任务。

Omar：训练他们学会如何在关注中保持冷静并做好工作。总之，别再谈论这些辅助性问题了，来谈谈最重要的那些。我们说到哪儿了？

Kabir：关于放弃任务，我已经和客户商量好了，这个冲刺我们会做故事A、B、C。现在冲刺计划会议之后，工程师说他们做不了B。问题是，我已经向客户承诺在两周内交付A、B、C，并给他寄了发票。我该如何处理？

Omar：当你不知道A、B、C需要多长时间时，你是如何承诺的？

Kabir：客户让我两周内做A、B、C。在与工程师进行了一些初步讨论后，我向客户承诺，然后才进行冲刺计划会议。我不能等到冲刺会议结束，开发人员给我所有任务的估算。

Omar：错误。你应该在冲刺计划会议结束后再向客户承诺。在此之前，只给客户一份你认为可以在接下来两周内尝试完成的事情清单。告诉客户，你将在冲刺计划会议结束后才能确认。进行一次冲刺会议只需要8小时=1天。所以，一天结束时，你就有一些具体的事情可以向客户承诺。从你让工程师花几天时间估算的模型来看，是行不通的。你必须在一天内完成计划，并在一天结束时向客户承诺。

Kabir：如果客户不同意怎么办？如果他说，“我必须在两周内拿到A、B和C，否则我就去别家了”呢？

Omar：这很难。我很想告诉你“滚蛋！”，但实际上你不能。你必须谈判并达成 mutual agreement。你不能仅仅服从客户说“是的，主人，我们做什么都行”，因为你显然做不到。事实是，冲刺结束时，你*只能*完成A和C，B未完成。然后客户会把你快递他的鞋子，让你找人来踢你。

Kabir：没错，那么我该怎么办？

Omar：有狡猾的解决方案和不狡猾的诚实解决方案。狡猾的解决方案是，假设你雇佣了5名工程师来完成A和C。但你发现你需要再雇佣一名工程师来做B，否则你不可能在两周内完成A、B、C。所以，你给客户开6名工程师的账单，并完成A、B、C。然后客户可能不同意你支付第6名工程师的费用。这时你就可以耍个小聪明。在这个冲刺中，你免费雇佣第6名工程师。不要告诉客户有一个额外的头在项目上工作。或者你可以告诉客户，出于好意，你想免费雇佣另一名工程师，以确保客户能够按时交付。这会提升你的形象。之后，当你有一个相对轻松的冲刺，4名工程师就能完成工作时，你悄悄地把一个工程师调到另一个项目，但仍然向客户收取5名工程师的费用。这样你就可以弥补你在前一个冲刺中秘密雇佣的第6名工程师的成本。这很卑鄙。但当你有一个如此强硬的客户，他同时强迫你“做什么”、“什么时候做”和“怎么做”，并且不愿意谈判时，你就别无选择，只能采取这些卑鄙的伎俩。你也可以为每个工程师在冲刺中的每个任务额外增加一小时，或者添加一些模糊的任务，比如“重构用户对象以实现强大的登录”。这样，你就可以获得相当多的额外工时，足以弥补你秘密雇佣的免费工程师。

Kabir：真是绝妙！那诚实清晰的做法呢？

Omar：你和客户谈判。告诉客户，他或她只能从“金钱-范围-时间”这三者中选择两项。这就是所谓的项目管理三角。你了解这个吗？

Kabir：正在谷歌搜索……

Omar：阅读这篇文章：http://office.microsoft.com/en-us/project/HA010211801033.aspx

它显示了一个这样的三角形：

所以，你的客户可以指定任意两个。如果客户指定了范围和时间（“做什么”和“什么时候”），那么客户必须在金钱或“如何”去做方面保持灵活。如果客户指定了金钱和范围，那么你可以在时间上自由决定。你雇佣更少的资源，花更多的时间来完成工作。明白了吗？

Kabir：是的，明白了。不错，我可以向客户展示这个，并教育他。有没有一本关于你刚才告诉我的那些卑鄙伎俩的书？

Omar：没有，我可能很快就会写一本。我会把它命名为“客户是邪恶的，所以你也一样”。

Raisul：嘿，我有一个项目团队是固定的。我无法在冲刺之间改变人数来弥补金钱的变化。所以，这个三角模型对我不起作用。我该怎么办？

Omar：对。我也对此有一个稍微不同的版本。这是我的看法：

这适用于你有一个固定的资源为特定客户工作的场景。在这种情况下，你不能按需减少人员，因为你无法重新分配他们。这种情况需要不同的策略。如果客户强迫你质量和时间，那么客户必须牺牲数量。客户不能说，在两周内做一个完美的登录表单，并为其添加很酷的Ajax效果。客户必须牺牲酷炫的Ajax效果，或者牺牲登录表单的*完美*，或者牺牲天数。

从上面的两个三角形中，哪个更适合你？

Kabir：第二个，因为客户从我这里雇佣了5名工程师。我不能把一个人调走去别的项目。好吧，至少不能公开。

Omar：好吧，听起来合理。你还需要我做什么？

Kabir：让我好好想想这一切。这绝对值得深思。我必须决定是公平竞争还是狡猾竞争。归根结底，我需要生产出伟大的产品，这样我才能获得客户的好评和未来的项目。所以，我需要不惜一切代价去做。经营一家离岸开发公司很难，我们有点像奴隶，而且像一群僵尸一样每10分钟嘟囔一次——“客户永远是对的”。你拥有自己的公司真是太幸运了。

Omar：我在Pageflakes之前经营过两家离岸开发公司。我知道是什么感觉。祝你好运。我见过你的产品，你们正在构建一个很棒的ASP.NET MVC+jQuery应用程序。发布它吧。它值得展示。

Raisul：非常感谢。再见……

（聊天结束）

这是我朋友制作的图表，显示了在冲刺开始前需要完成的步骤。

对产品经理很有用。对开发者来说很有启发。

这是图表的完整版本。

结论

我很想知道你是否经历过类似的情况，以及你是如何摆脱困境的。如果这个故事让你想起了一些痛苦的过去，请在论坛上分享。