我们需要让我们的客户开发合作伙伴参与我们的开发过程。我们或多或少都在遵循敏捷方法。一些客户合作伙伴距离较远,而另一些客户合作伙伴较近。我们需要最大限度地减少旅行成本。
我们的客户是医疗保健行业的,他们往往很忙,很贵,而且很难安排时间。
支持客户参与的实践和技术是什么?我们使用电话、电话会议和电子邮件。我们对利用wiki技术很好奇,也很想听听其他人是怎么做的。
发布于 2009-02-11 07:14:07
我对敏捷方法的经验主要是针对桌面应用程序的。当我们的客户在远程时,我们会花时间让工程师到客户现场配置/安装演示平台。工程师与客户合作进行测试和演示设置/计划,客户认为该环境复制了部署环境的重要方面,但将演示系统与现有基础架构隔离(以便我们可以在需要时推送更新)。工程师还设置了部署系统,将我们的应用程序转移到生产环境中,这样我们就可以在不在现场的情况下进行“部署”。我们的应用程序可以自我更新(对于每个版本或每个构建),并且我们仔细地检测发布,以记录所有错误并将所有崩溃作为bug提交给我们的bug跟踪器。这样,我们至少知道哪里出了问题,即使我们不知道哪里是对的。
对于客户的测试平台上显示的每个版本/构建,我们都会提供一个(简短的)截屏视频,由项目负责人或主要开发人员讲述,演示任何新功能。发行说明包含任何长期问题或我们希望客户考虑的问题(例如,不能通过电话或电子邮件立即解决的问题),应用程序会为用户显示这些说明。
最后,也可能是最重要的一点,我们让客户和/或客户的联系人在我们的日历服务器上建立一个帐户,并配置他们的日历应用程序来使用该帐户。然后这是双向的--我们可以安排时间(在现场、电话、电子邮件等)他们也可以对我们的开发人员做同样的事情。
发布于 2009-02-11 04:33:00
除了通信延迟,客户是在同一个隔间还是在地球另一端都无关紧要--关键因素是可用性。
如果客户连续几天忙于回复您的电子邮件,将会导致您的迭代延迟或失败
客户对敏捷有两个关键承诺:
客户必须遵守合理的可用性服务级别协议(SLA),例如1小时响应时间或24小时响应时间等,您需要根据延迟因素调整所有估计和计划。如果客户不承诺或不遵循,则取消迭代并重新计划,再次将客户的承诺带到最前面。不要只是“猜测”你认为客户可能想要什么。
底线:没有客户的承诺,敏捷将无法工作。
发布于 2009-02-11 05:03:08
一种选择是:在“客户合作伙伴”站点安装一个客户代理,当这些客户可用时,该代理可以提取您需要的信息。让这些代理建立牢固的关系,使它们能够表示客户视图。他们的时间是你的了。当出现他们无法回答的问题时,他们可以随时联系您的客户合作伙伴-即使是在咖啡线上。
https://stackoverflow.com/questions/535314
复制相似问题