这是个很普遍的场景:一个敏捷团队发现自己与一家外包的传统(读作“非敏捷”)合作伙伴 / 厂商 / 供方为伍,而互相间做事规范的错配浪费了双方大量的精力。本月早些时候,我们报导了 ScrumDevelopment 邮件列表上的一次讨论,其中敏捷从业者探讨了如何(以及是否)响应固定价格招标请求。另一位资深从业者则提炼了他在这一主题上的经验所得,提供了创建更佳招标申请书(Request For Proposal,简称 RFP)的策略,以吸引从事敏捷的团队们,这就是 Scott Ambler 近期撰写的“以敏捷的方式撰写投标申请书——采购部中的恩怨情仇”。
虽然敏捷专家们通常同意,固定价格(隐含固定范围)合同助长了效率和产出低下的行为方式,但是诸多项目还是如此这般进行,这也是事实。凭藉独到视角,Ambler 审视了整个流程的现实情况,不仅是服务提供商的应标,也包括了撰写招标申请书:
首先是敏捷式外包的好消息:敏捷项目团队能增强透明度,令利益相关方更易于进行监管……坏消息是,它假定客户…有能力发出反映敏捷开发实情的招标申请书,这也是本通讯要讨论的主题。
噢,问题的症结在这里:招标申请书的撰写方式,经常是要杜绝迭代的、适时的估计,而许多敏捷团队根本就不对这些招标申请书应标。这里关键性的潜在假设是,如果供应商交付了写明的需求,就万事大吉了。Ambler 归纳了众所周知的问题:“客户无法精确定义他们想要的东西,就算能,也要花上太长的时间,以至于他们的需求总是会有所变化。所以,要供应商提供哪怕是稍稍靠谱的建议书,实际上也是不可能的。” Ambler 将这种猜谜游戏视为“不道德”,并且建议,为对客户公平起见,敏捷供应商必须为客户提供其他的、更有效的选择来处理工作,同时告知优劣取舍和风险。
但是,让我们回过头来,深入查看问题根源。在该文中,Amber 详细阐述了如何撰写招标申请书:
… 现实情况是:你所在组织中,的确有(些)人正处在这个位置。所以,如果你不能改变你们的工作方式,那么请你将本通讯电邮给他们,并要求他们考虑我正要描述的敏捷策略。不迈出这第一步,你就不可能改善你们的采购流程。
Ambler 展示了如何在此适用一些根本原则:敏捷宣言,软件工艺宣言和精益开发治理。(该文末尾包括了一份含有如上及其他资源的阅读清单。)接着他概述了,要有效地采购敏捷开发团队的服务,招标申请书应该是什么样子。文中提出,基于“对供应商时间材料(T&M) 的较低费率及持续交付高质量、潜在成品软件的奖励”,以风险分享的策略代替“固定价格,固定范围”。
Ambler 承认,这一策略会承受一些潜在挑战,但他坚称这些挑战相对易于克服。
- 供应商通常不会让员工待命,…所以他们可能很难预先就确定说出谁会在某一项目上,尤其是在客户决策缓慢的情况下。(他会建议客户对人员配备做合理的期望,但对以次充好的偷梁换柱手段要保持警惕。)
- 客户需要对自己的决策承担责任,并积极参与项目监管——这非常有别于过去或许常用的“甩手掌柜”式做法。(Ambler 坚称“要让外包可行,客户必须采取事必躬亲的方式,积极监督和指导项目。”这显然不是省钱的地方——项目脱轨的风险太高了。)
现在,这一清单很有价值,因为开发人员通常不(真正)明了如何撰写一份招标申请书,而采购部门也搞不清 Jira 与 JUnit 的区别。 使用 Ambler 的清单作为讨论的基础,也许就有可能开启流程,将重要信息反馈给那些为组织采购有价值资源的人。Ambler 暗示,当团队将其协作原则扩展到他们的采购人员时,他们就可能会在那里发现开诚布公的对话机会:
采购人员…都是聪明人,他们完全知道他们的流程有毛病。不巧的是,他们经常觉得无力改变招标申请书流程,原因要么是他们对其管理层言听计从,要么是他们以为其所共事的供应商无意以敏捷方式工作。
敏捷团队正在发现制造业者早在上个世纪就已知道的同一样事情:不要自扫门前雪,与邻互助才会真正获益——在这一例子中,他们的邻居就是内部采购职员。阅读全部原文以了解招标申请书可包含的细节,以吸引敏捷团队上门。
评论