敏捷、基于挑战的采购指南
敏捷、基于挑战的采购指南
原文：https://medium.com/hackernoon/guidelines-for-agile-challenge-based-procurement-4531ff335422
—罗伯特·l·里德博士和公民行动公司首席执行官亨利·普尔
2015 年 7 月，联邦政府总务署(GSA)的 Chris Cairns、Dave Zvenyach 和 18F 的其他领导人改革了政府 IT 采购。他们要求供应商通过快速编写代码来原型化一个简单的任务，而不是编写书面提案，来申请一揽子采购协议中令人垂涎的位置。在这篇文章中，我们试图解释和分析 18F 通过阐明一些政府机构的项目经理执行敏捷的、基于挑战的采购的指导方针开始了什么。这适用于联邦、州和地方各级政府。
简而言之，政府 IT 承包通常是这样工作的:
- 我们人民，通过我们选出的官员，要求建设一些东西。
- 因为我们的政府相信公平，建设是通过竞争来完成的，所以一个“征求建议书”(RFP)被写成描述人民想要什么，作为政府所能描述的最好的东西。这对于像桥梁这样的东西非常有效。
- 但是软件不像桥梁。很少有人在看到之前知道自己想要什么。有了桥梁和高速公路，物理环境是静态的，技术变化很慢。对于信息系统，边界通常是不固定的。通常不可能确定界限和内容，因为它们在授予采购后会发生变化。因此，RFP 在获取所需内容方面做得非常糟糕，即使它是由天才编写的。
- 许多技术性很强的人宁愿在私营企业工作，也不愿在政府部门工作，所以招标书通常是由非专业计算机系统设计人员或程序员编写的，尽管其主题是计算机编程。
- 许多大公司手头都有专家，他们的工作就是回答这些 RFP。为了取得成功，大多数公司发展了一项核心能力，即了解如何与联邦采购条例的规则和政府项目经理的习惯互动。这种持续的费用变得固定。这成为所谓的“环城强盗”的竞争优势。
- 因为小公司没有这方面的专业知识，他们通常甚至不参与政府合同的投标，因为当有大量其他有利可图的工作时，处理繁文缛节似乎不值得。
- 投标人会写很长的建议书，读起来像“吹牛表”。我们都读过。它们通常只是以前成就的列表。在某些情况下，它们似乎没有以任何方式反映 RFP 的细节，就好像公司甚至懒得阅读它一样。
- 一个由中等技术水平的人组成的小组通读了每份 10 到 25 页长(通常超过 100 页)的提案，并给它们打分，就像你评价高中作文一样，只有一个很大的例外。如果投标人不满足一个要求——这可能完全是管理上的——他们就会立即失败。这一要求可能只是超过他们的出价字体大小。在此期间，不能与公司联系。任何不清楚的事情就是不清楚。
- 然后，采购官员将所有未被取消资格的投标人的“分数”计算在内，并将合同授予一个或几个投标人。
- 然后，可能在征求建议书发布一年后，这些公司第一次开始认真研究真正需要做什么。
- 通常，获胜者(或多个获胜者)现在能够在没有公开竞争的情况下为该机构提供未来几年的所有服务。
- 对政府来说，这一过程是如此繁琐，以至于一旦授予合同，重新开始竞争比继续与不合格的供应商竞争更加困难。
18F 在敏捷 BPA(一揽子采购协议)中所做的就是用一种可能被非正式地称为“秀，不要说”的方法来颠倒是非。":
- 对这些公司的评估不是基于一份文件，而是基于他们设计和编码的工作原型和过程。
- 这个原型必须展示现代技术系统的使用，这些系统大概接近手头实际任务的需要。
- 这些公司必须展示现代软件方法过程。
- 从揭示任务的定义到到期日的时间相当短。
- 这个过程通常是完全开源的。产生的代码必须对公众开放，可以被他们和政府重用。
- 该流程包括用于评估成本的预算。
- 胜出的公司被放在一个池中，可以在没有进一步正式竞争的情况下获得任务(从而获得资金)。
敏捷 BPA 是革命性的，因为它需要证明而不是断言敏捷、能力和以用户为中心。尽管这个过程，像任何开始一样，有一些粗糙的地方和瑕疵，但它已经激发了至少三个模仿者，如加利福尼亚州卫生与人类服务机构的敏捷开发资格预审(ADPQ)供应商库，RFI #75001。可能国土安全部通过最近的 DHS-FLASH 改进了这种不断增长的能力，它使用了不同的结构。密西西比州正在举办一场挑战赛，在结构上类似于最初的 18F 敏捷 BPA。
为什么纳税人应该获得敏捷、基于挑战的采购
如果一个项目办公室在使他们的下一次采购变得敏捷和基于挑战方面做得很好，你和你的纳税人将获得以下好处:
- 你将得到你能得到的最好的公司，因为你正在创造一个计算机能力的精英统治，而不是文书遵从。
- 你将在竞赛的早期获得对你的项目的有价值的洞察力。本质上，你将提前几个月开始这个项目。没有什么比尽早与用户互动更能降低软件项目如期完成的风险了。
- 用户访谈会很早就被创建，而且来自如此多的不同公司，你的偏见会自动消除。
- 有价值的设计和代码将向全世界公开，但更重要的是，胜出的投标人将拥有使用落败的投标人生产的代码的所有合法权利(反之亦然。)
- 你从为一个大项目写一份完整、详细、正确的 RFP 的负担中解脱出来——这是不可能的。相反，你必须教自己使用敏捷方法，从采购开始。
- 最重要的是，你将通过变得更加敏捷来降低项目的风险，并获得一个敏捷的团队。
两种方法:谁提供用户？
18F 敏捷 BPA 和 DHS-FLASH 的结构是不同的，这种差异值得讨论，因为它们触及了敏捷和以用户为中心的设计的核心:开发团队与用户的关系。区别归结为:谁提供用户？
在敏捷 BPA 中，公司被期望自己找到用户。这样做的好处是，政府不必向大量公司提供用户。缺点是政府不能直接观察公司如何与用户互动，但必须依赖它期望公司提供的产品。
在《DHS 快讯》(撰写本文时仍在进行)中，联邦政府主动提供一个人来充当“用户代表”——可能是一个实际用户，也可能是某个熟悉实际用户的人。理论上，这提供了一个直接测试公司与用户互动能力的机会。然而，对政府来说，这似乎是后勤上的困难。这意味着挑战比赛必须限制在较短的时间内——在这种情况下最多一天。因为公司必须被公平对待，这似乎意味着质疑必须在不同的日子进行，并且必须保持主题的秘密性。我们发现这很不幸，因为像 USDS 剧本呼吁的那样“默认开放”或者像我们在 18F 常说的那样“从第一线开放”有巨大的优势。
从公司的角度来看，每种方法都有优点和缺点。如果公司必须在一天的挑战中亲自与用户会面，这必然会产生差旅费用。如果挑战持续几天或几周，这意味着更大的劳动力支出，因此在这两种情况下，对于小公司来说，迎接挑战将是适度的支出。
作为既有特权又有责任参与这些挑战的政府承包商，我们希望政府继续认识到企业所承受的成本，努力保持挑战有序和简短。我们建议政府选择“企业提供用户”或“政府提供用户”的方法，基于他们了解企业的具体需要，以及什么对企业有意义。例如，一个不期望非本地公司参与的县政府不会通过使用“政府提供用户”的方法增加本地公司的额外成本。如果项目办公室认为企业可以合理地找到给定挑战主题的模范用户，那么使用“企业提供用户”的方法更合理。
机构指南
运行敏捷采购需要极大的创造力。关于如何做的教科书还没有写出来。然而，有限的经验已经揭示了政府机构的一些准则。这些指导方针将使你的采购更加公平，更加有效，风险更小，最终为纳税人省钱。请理解，这些是指导方针，而不是规则，在某些情况下，它们代表了我们自己未经验证的观点。我们将这些原则分为与内容、过程和技术相关的原则。
内容
- 保持真实。人生苦短，不能空练。请你的供应商做一些小事情，但是可以在某种程度上推进你的目标。表现得好像你打算用每个供应商写的每一点代码来以某种方式帮助纳税人。这可能需要你发挥创造力，但请记住——计算机技术通常是通过玩弄想法来制定最佳方法而进步的。如果你得到了 10 个最小的、微小的项目版本作为对 RFP 的回应，你应该能够从每一个版本中学到一些有意义的东西。
- 如果您使用“公司提供用户”的方法，请坚持默认打开。公众为这个过程付钱给你，他们有权使用，更现实地说，检查和学习本 RFP 中开发的工作。你通过坚持一切都在阳光下进行来保护自己。如果您使用的是“政府提供用户”,仍然要设定一个参与挑战赛的条件，即挑战赛开发的所有代码都在公共领域，并将在挑战赛后发布，任何人都可以自由重用，尤其是政府本身。
- 坚持以用户为中心。通过坚持让公司在以用户为中心的程度上进行竞争，并在这种情况下工作，你实际上是在招募公司为你开始这一过程——比传统的采购过程提前几个月。如果公司竞相展示他们倾听用户的能力，你将立即从用户那里学习，而不是在获奖之后，因为公司学到的一切将指导你未来的工作。这是敏捷软件开发的原则之一——“重视客户合作胜过合同谈判。”
过程
- 尽可能地限制时间周期，以降低企业竞争的成本。如果你使用的是“公司提供用户”的方法，绝对要把比赛限制在 5 天内，也许 2 或 3 天会更好。如果您使用“政府提供用户”的方法，将编码时间限制在 4 或 5 个小时，也许还有额外的非编码时间。对许多人来说，这似乎短得可笑。然而，你帮了公司一个忙，限制了他们为赢得你的生意而投资的时间。你可以尽可能提前宣布比赛，但是你所要求的细节应该在比赛开始时就透露。一个不能在短时间内生产和部署某种原型的公司需要将这次挑战作为实践，并希望赢得下一次挑战。
- 要求公司在竞争开始时就默认(向你)公开，而不是在最后时刻公开。无论谁提供用户，代码都应该在比赛结束时公开。你应该要求看到比赛期间的发展，因为它萌芽。这包括诸如 scrum 会议记录、用户访谈、UX 草图、故事地图、用户故事和设计想法等工件。要求公司使用 Git 这样的版本控制系统，显示贡献者的修订历史。
- 在你的评估过程中，对与其他公司合作良好的公司给予奖励。一家公司使用另一家公司编写的代码应该得到奖励，如果这确实使他们的原型更好的话。更好的是，一家公司既使用另一家公司的工作，又以某种方式积极回馈另一家公司。不要要求独立工作，你应该重视公司间的合作，尽管不要到了公司追逐合作而不是向用户交付价值的程度。伟大的团队合作是关键。
- 根据公司如何利用他人来评估公司。这包括“社交网络”，但真正的意思是“贯穿所有时间和空间的社交网络”。例如，自由和开放源码软件代表了人类几个世纪的合作。在 2016 年撰写本文时，利用这种合作的能力比 30 年前更是高效编程的关键。然而，公司也必须利用终端用户，专家，他们可能没有的工作人员等。奖励公司与不同的人类知识和人才库的联系。
- 计划花足够的时间来评估产生的原型和代码库。如果你有太多的回应，这是一个负担，创建一个正式的筛选过程，例如在整整 20 分钟的时间内评估每个提交的内容，取消那些看起来明显较差的内容，允许对合格的内容进行更长时间的评估。
- 不要创造一个漫长的竞争，然后要求预算的钱或时间，因为你没有办法验证其准确性。相反，只需要来自供应商公司的每个人类贡献者识别每个离散的贡献。
技术
我们说的任何关于科技的东西，几年后都会是错的。尽管如此，我们不应该回避理解快速发展的技术前景——你也一样。
- 寻求帮助。如果你是一名项目经理或采购人员，掌握所有最新技术不是你的工作，但你的工作是寻找那些掌握最新技术的专家。至少你的 RFP 应该由技术专家审核，18F 咨询公司(现在分成几个部门)曾称之为“ RFP 代笔”。
- 期望从你的投标公司那里学到一些东西。他们可能会使用一些你不熟悉的技术。然而，如果你真的想看到 X 技术被使用，那就去要求它以某种有意义的方式被使用，但前提是你明白你所要求的是什么。不要因为炒作和流言蜚语而询问具体的技术。
- 如果可以的话，根据需求能力而不是技术来写你的 RFP。幸运的话，你可能会发现一些你想象不到的解决方案是可能的。例如，使用现代 API、Ajax 和现代浏览器，通常可以以一种无服务器的方式实现有趣的功能。一个要求特定语言或服务器的 RFP 将会排除这种创新的可能性。
- 处理遗留代码几乎是这项工作的一部分。如果你有一个遗留的数据库或 API 或代码库可以向公司开放，那么就这样做，并评估他们使用/绕过/通过过时系统的能力的有效性。
公司指南
一家竞标基于原型的敏捷竞争的公司拥有一个美妙而又充满压力的机会。要充分利用它，请遵循以下指南。
- 计划您的参与，以便在其他工作未充分利用您的技术平台时使用它们。
- 让一个敏捷团队做好准备，立即投入运行。
- 如果你能负担得起，排练。挑战越短，你就越需要排练。排练三次，尽可能的逼真，对于一天的挑战来说也不是不合理的。
- 如果政府提供用户，通过选择一个外部团体来扮演政府用户的角色进行排练。计划让他们做他们真诚相信政府会要求的事情，但也计划让他们向团队扔一个“曲线球”。团队需要排练如何应对突发情况。
- 利用这个机会探索新技术和新工艺。这是一个磨砺你的软件方法过程的机会。
- 利用这个机会，把以前可能没有一起工作过的人聚集在一起，在你自己的公司内部建立人际关系。
- 将你的短时间分成至少三次但最多六次短距离冲刺。如果有必要的话，将整个冲刺周期压缩到一个小时，并坚持你的压缩过程。你不能失控，也不能不早演示。如果你不在第一个冲刺阶段进行演示，最坏的情况是你会错过最后期限，最好的情况是你无法从你的用户那里学到一些东西。
- 给你内心的完美主义者买一个长假，在这段时间里，在社交媒体上屏蔽他们。在你接受挑战的短暂时间里，无论你建造了什么，与你能想象的相比，都将是微小和蹩脚的——除非你没有想象力。用盖伊·川崎在《革命者的准则》中的话说:“别担心，做个蹩脚的。”
- 努力但要开心。庆祝微小的胜利。这将是一场比赛，没有一场比赛是容易的，但你应该能够回顾它，并说你很高兴你跑了这场比赛，无论你是否赢得了申办。
- 计划学习每一次投标。不要想象失败——但要做好失败的准备，并从每次失败中吸取教训。
- 不要指望第一次尝试就能领先马拉松。如果你无法承担整个团队参与采购的风险，那就找另一家公司组成联盟，分担你的风险，从学习中获取有益的价值。
(罗伯特·l·里德是推特上的@罗伯特·里德。)
(亨利·普尔是推特上的@亨利·普尔。)
黑客中午是黑客如何开始他们的下午。我们是 @AMI 家庭的一员。我们现在接受投稿并乐意讨论广告&赞助机会。
要了解更多信息，请阅读我们的“关于”页面、在脸书上给我们点赞/发消息，或者简单地说， tweet/DM @HackerNoon。