使用投标申请书（RFP）聘雇敏捷团队-InfoQ

这是个很普遍的场景：一个敏捷团队发现自己与一家外包的传统（读作“非敏捷”）合作伙伴 / 厂商 / 供方为伍，而互相间做事规范的错配浪费了双方大量的精力。本月早些时候，我们报导了 ScrumDevelopment 邮件列表上的一次讨论，其中敏捷从业者探讨了如何（以及是否）响应固定价格招标请求。另一位资深从业者则提炼了他在这一主题上的经验所得，提供了创建更佳招标申请书（Request For Proposal，简称 RFP）的策略，以吸引从事敏捷的团队们，这就是 Scott Ambler 近期撰写的“以敏捷的方式撰写投标申请书——采购部中的恩怨情仇”。

虽然敏捷专家们通常同意，固定价格（隐含固定范围）合同助长了效率和产出低下的行为方式，但是诸多项目还是如此这般进行，这也是事实。凭藉独到视角，Ambler 审视了整个流程的现实情况，不仅是服务提供商的应标，也包括了撰写招标申请书：

首先是敏捷式外包的好消息：敏捷项目团队能增强透明度，令利益相关方更易于进行监管……坏消息是，它假定客户…有能力发出反映敏捷开发实情的招标申请书，这也是本通讯要讨论的主题。

噢，问题的症结在这里：招标申请书的撰写方式，经常是要杜绝迭代的、适时的估计，而许多敏捷团队根本就不对这些招标申请书应标。这里关键性的潜在假设是，如果供应商交付了写明的需求，就万事大吉了。Ambler 归纳了众所周知的问题：“客户无法精确定义他们想要的东西，就算能，也要花上太长的时间，以至于他们的需求总是会有所变化。所以，要供应商提供哪怕是稍稍靠谱的建议书，实际上也是不可能的。” Ambler 将这种猜谜游戏视为“不道德”，并且建议，为对客户公平起见，敏捷供应商必须为客户提供其他的、更有效的选择来处理工作，同时告知优劣取舍和风险。

但是，让我们回过头来，深入查看问题根源。在该文中，Amber 详细阐述了如何撰写招标申请书：

… 现实情况是：你所在组织中，的确有（些）人正处在这个位置。所以，如果你不能改变你们的工作方式，那么请你将本通讯电邮给他们，并要求他们考虑我正要描述的敏捷策略。不迈出这第一步，你就不可能改善你们的采购流程。

Ambler 展示了如何在此适用一些根本原则：敏捷宣言，软件工艺宣言和精益开发治理。（该文末尾包括了一份含有如上及其他资源的阅读清单。）接着他概述了，要有效地采购敏捷开发团队的服务，招标申请书应该是什么样子。文中提出，基于“对供应商时间材料(T&M) 的较低费率及持续交付高质量、潜在成品软件的奖励”，以风险分享的策略代替“固定价格，固定范围”。

Ambler 承认，这一策略会承受一些潜在挑战，但他坚称这些挑战相对易于克服。

供应商通常不会让员工待命，…所以他们可能很难预先就确定说出谁会在某一项目上，尤其是在客户决策缓慢的情况下。（他会建议客户对人员配备做合理的期望，但对以次充好的偷梁换柱手段要保持警惕。）
客户需要对自己的决策承担责任，并积极参与项目监管——这非常有别于过去或许常用的“甩手掌柜”式做法。（Ambler 坚称“要让外包可行，客户必须采取事必躬亲的方式，积极监督和指导项目。”这显然不是省钱的地方——项目脱轨的风险太高了。)

现在，这一清单很有价值，因为开发人员通常不（真正）明了如何撰写一份招标申请书，而采购部门也搞不清 Jira 与 JUnit 的区别。使用 Ambler 的清单作为讨论的基础，也许就有可能开启流程，将重要信息反馈给那些为组织采购有价值资源的人。Ambler 暗示，当团队将其协作原则扩展到他们的采购人员时，他们就可能会在那里发现开诚布公的对话机会：