我们需要让我们的客户开发合作伙伴参与我们的开发过程。我们或多或少地遵循敏捷方法。一些客户合作伙伴相距遥远，而另一些则更近。我们需要尽量减少差旅费用。
我们的客户在医疗保健领域，往往很忙、价格昂贵且难以安排。
哪些实践和技术有助于支持客户参与？我们正在使用电话、电话会议和电子邮件。我们对利用 wiki 技术感到好奇，并且很想听听对其他人有用的方法。
jfaughnan
问问题
2689 次
10 回答
6
客户是在同一个隔间还是在地球的另一端并不重要，除了通信延迟 - 关键因素是可用性。
几天忙于回复您的电子邮件的客户将导致您的迭代延迟或失败
客户对敏捷有两个关键承诺：
- 可以及时回答问题
- 在迭代期间不要改变他们的想法/优先级
客户必须承诺就可用性达成合理的服务水平协议 (SLA)，例如 1 小时响应时间或 24 小时响应时间等，并且您需要根据滞后因素调整所有估计和时间表。如果客户不承诺或不遵守，则取消迭代并重新计划，再次将客户的承诺置于首位。不要只是“猜测”您认为客户可能想要什么。
底线：没有客户承诺，敏捷就行不通。
于 2009-02-11T04:33:00.270 回答
4
我对敏捷方法的体验主要针对桌面应用程序。当我们的客户在远程时，我们会花时间让工程师到客户现场配置/安装演示设备。工程师与客户一起制定测试和演示设置/计划，以提供客户认为复制部署环境的重要方面但将演示系统与现有基础架构隔离的环境（以便我们可以在需要时推送更新）。工程师还设置了部署系统，将我们的应用程序转移到生产环境中，这样我们就可以在不现场的情况下“部署”。我们的应用程序可以自我更新（对于每个版本或每个构建），我们会仔细检测版本以记录所有错误并将所有崩溃作为错误提交给我们的错误跟踪器。这样我们至少知道出了什么问题，即使我们不知道什么是对的。
对于出现在客户测试平台上的每个版本/构建，我们都会提供一个（简短的）截屏视频，由项目负责人或主要开发人员讲述，演示任何新功能。发行说明包含我们希望客户考虑的任何长期问题或问题（即无法通过电话或电子邮件立即解决的问题），应用程序会为用户显示这些说明。
最后，可能也是最重要的，我们在我们的日历服务器上为客户和/或客户的联络人提供一个帐户，并配置他们的日历应用程序以使用该帐户。然后这是双向的——我们可以与客户安排时间（现场、电话、电子邮件等），他们也可以与我们的开发人员做同样的事情。
于 2009-02-11T07:14:07.183 回答
3
一种选择：在“客户合作伙伴”站点安装客户代理，当这些客户可用时，该代理可以提取您需要的信息。让这些代理建立稳固的关系，让他们能够代表客户的观点。他们的时间都是你的。当出现他们无法回答的问题时，他们可以随时联系您的客户合作伙伴——即使是在咖啡生产线上。
于 2009-02-11T05:03:07.870 回答
3
敏捷中客户的全部意义在于与开发人员进行开放和自由的对话（即即时反馈）。如果您的实际客户无法提供此服务，那么您需要一个可以担任此角色的中介/代理。您不需要 实际的客户，您只需要能够很好地代表客户利益以满足客户需求的人。
于 2009-02-11T06:14:52.660 回答
1
只是一些想法：
如果您确实选择使用 Wiki，请确保它支持整个 wiki 范围的“最近更改”列表，并且最好是特定于用户的列表。人们与开发人员的距离越近，就越有可能将电子邮件作为他们使用计算机的隐喻。如果他们不能立即告诉他们什么时候有新的东西可以看到，他们永远不会去探索它。您最好还需要向他们表明您需要他们注意事项的方法，否则他们会像对待 CC 一样对待更改。
我非常相信创建交互的视频屏幕截图（叙述）并将它们分发给用户。与真实的演示不同，客户不需要打断他们，他们可以一遍又一遍地倒带和重新观看相同的交互，关注小细节。
最后，如果您确实分发原型，请确保派人（或至少一个屏幕共享会话）来查看原型是如何使用的。上下文设计是有效的。您可以指望人们以与您期望的方式不同的方式使用您的原型，并且您必须了解他们如何使用它才能真正了解问题所在，即使他们没有报告问题。
于 2009-02-11T03:38:16.983 回答
1
您是否考虑过类似LogMeIn的东西。
这将允许客户登录到您网络上已经运行您的应用程序的 PC，或者允许您在他们的一台计算机上安装/更新应用程序。
这将解决远程客户问题，还将支持敏捷过程中持续不断的客户反馈要求。
我在以前的公司使用它来提供技术支持，但没有理由（除了可能的成本）它不适用于您的情况。
这也是实际了解用户如何使用您的应用程序的好方法，因此可以找出哪些有效，哪些无效。
于 2009-02-11T04:12:27.463 回答
1
首先，确保您有产品经理或产品负责人关闭开发人员。此人将管理与客户的关系。
然后，产品经理可以在每次迭代结束时向客户展示产品，并在开发人员需要反馈以实施用户故事时询问客户问题。
当您参与其中时，您可以从客户那里获得积极的反馈，这真是令人惊讶。
我们没有使用 wiki，大部分交流是通过电子邮件、电话和屏幕共享应用程序完成的（我们使用的是 GoToMeeting，但有很多替代方案）。
于 2009-02-11T04:13:33.950 回答
1
您可能应该在一个地方与每个人一起进行一次开球。面对面的时间是无价的。这包括所有开发人员。准备一些元计划问题，但也有足够的时间来交流。
于 2009-02-11T04:59:50.593 回答
1
我认为，对于高度依赖客户参与的敏捷流程的大多数定义，您已经错过了“最佳实践”，这将是针对现场的，最好是始终在场的“团队内”客户。所以我想我们正在寻找“下一个最佳实践”。:)
有可能在现场引入“代理客户”。我不得不承认对代理客户的价值持怀疑态度。我担心在组合中引入某种二流和其他不必要的业务分析师功能的风险，增加的信噪比和可能出现乱码的消息。它还存在让忙碌的真实客户减少参与流程的风险，这可能会导致不满。我想知道是否有最近退休的具有良好领域知识的人可以担任顾问？
与远程客户的通信带宽惊人地低于面对面，这是我直到开始与另一个国家的用户打交道时才完全意识到的。即使是视频，损失也很大。
你的迭代有多长？计划迭代有多难？是否更容易进行更长的迭代并以更少的频率完成更多的计划，或者减少迭代长度并进行更小但更频繁的计划会议？是否涉及一位以上的客户
在每次迭代结束时，您是否有可用且可用的构建？在下一次计划会议之前，相关用户是否有时间进行实践？通过频繁发货来保持用户参与从表面上看似乎是一个好主意，这可能为小频繁迭代（一周？两周？）
wiki 的想法可能会奏效：您看过FIT 框架吗？这是一种集成的验收测试/wiki，可能有助于从远程客户那里获得验收测试。我想我还希望提供某种（单独或集成的）“项目仪表板”，可能会定期推送给关键客户以及按需提供。用它来代替白板上的便利贴、大可见图表等。有许多开源或低成本的选项可以提供服务——编写自己的简单替代方案也不必太耗时或太昂贵。
最重要的是，请记住，“敏捷”是一种包罗万象的标签，用于强调敏捷宣言中所支持的价值观和原则。在一种情况下被认为是“最佳”的东西在另一种情况下可能并非如此。如果您了解这些原则并定期以批判的眼光审查您的方法，那么您可能会足够接近适合您情况的最佳实践应用程序。
我已经有一段时间没有看它了，但是作者名单上有 Beck 和 Fowler，在规划极限编程中应该有一些有用的东西。
于 2009-02-11T09:58:19.037 回答
0
在我之前的职位@drchrono.com，我汇总了来自全国 20,000 名临床医生的数据/反馈/迭代请求。做到这一点的最好方法是宣传像 uservoice.com 这样的网站。我与有时 50 到 100 名医生（医生直接从我们的网站注册）举行了“每日现场网络演示”。在这些演示中，我将展示我们当前的产品并宣传用户的声音，以将他们的反馈转化为对我们的开发团队有用的工具。所有这些都是远程完成的，并导致经常性收入增长总体增长 1,400%。
于 2011-09-29T01:57:53.883 回答