允许客户参与项目的最佳方法是什么？

我们一直在为客户建立CRM。既然第一个主要阶段已经完成，并且第二个阶段已经达成共识，那么客户希望承担一些工作，在我们构建第二个阶段的同时，对数据库模式和业务流程进行较小的修改。

我不确定这是否完全可行，但是假设是这样，我想指出一些指针，可以针对这些指标采取措施以使其完全可行。到目前为止，这是我得到的：

• 到目前为止，客户大多从用户的角度看项目。显然，应该分两部分进行讨论，向我们介绍内部工作原理：

  • 首先，显示现有的数据库架构，并通过示例的方式对其进行扩展，
  • 然后，显示一些示例代码，并为架构增强编写新的业务流程。
• 该代码当前位于内部Subversion存储库中。虽然我们可以在他的网络上建立一个或多个公共网络（我们可以通过VPN连接到它），但我觉得分布式系统会更好。但是，我似乎是唯一这样的人，因此我可以使用一些令人信服的论点。

• 我不确定如何授权/确保在生产环境中运行的代码已提交。好像“灾难发生之前，x进行了关键的，无记录的更改；现在y正在试图弄清楚此错误自此以来一直在发生”灾难是不可避免的。理想情况下，在部署之前，所有更改将：

  • 在问题跟踪系统中记录下来，
  • 首先在单独的测试环境中进行，并且
  • 必须通过自动化测试。

  las，我怀疑其中任何一种纪律都会盛行。

假定插件体系结构或单独的项目不是可行的选择，因为1）前者不存在，并且2）后者将禁止客户查看并可能修改现有代码，我相信他会坚持。

这将是最不喜欢的答案-但这确实是！

这是有风险的（就像允许新手驾驶一辆崭新的汽车一样）-但这不是一个坏主意。

了解他们为什么要这样做：不是因为他们有多余的资源，而是让自己感到受到控制。

您需要做的是：

1. 教育您的客户-软件不仅仅是代码。如果他们想参与，让他们先审查建筑方面，设计等。向他们提出问题，并向他们展示他们事先做出的选择的含义。

2. 您应该始终返回关于方法的利弊的选项（并很好地记录这些会议），但应该允许他们做出一些决策。至少他们会开始意识到他们并不了解-或将拥有所有权。

3. 您可以创建单独的空间（例如分支），以便它们必须能够编写所需的任何内容-在提交或合并之前，应该对它们进行适当的测试。

虽然我知道可能会发生并发症，但每个问题都是一个机会。如果一切顺利，您的客户实际上将对内部问题有更多的了解，并会赢得更好的信任，因为他们知道（如何）您做得很好！

PS：为了给您一个见识-我来自印度；我知道很多IT部门的管理人员并没有太多线索。他们通常不介意（甚至感到高兴）客户会投入额外的资源来确保项目不会进入垃圾箱！这对他们很有用；他们都怀着一种心态“无论你说什么，先生！”。这并不是要贬低我自己的同胞，而是要表明共同发展并不是一个坏主意。毕竟，许多管理专家描述的是对业务问题的“ 生产者方法 ”。

哦，您的想法是正确的，但是我已经看到这会带来多大的麻烦，并且双方都遭受了很大的痛苦。我目前正在维护这样的应用程序。

找出客户认为有必要直接为项目做出贡献的真正原因。是不是他们现在希望该项目完成得比您实际完成时快？他们是否已经想要更改，但是担心您因更改规格或请求其他功能而产生额外的费用？他们的组织中是否存在政治斗争，内部开发资源需要项目的更多控制和投入，或者他们正在寻找内部开发人员的忙碌工作？（这最后一个对我来说很近）

找到他们的真正动机，并尽可能解决它们。他们甚至暗示这是一个巨大的警告信号，说明麻烦即将来临。在同意此类事情之前，请尝试减轻他们的实际担忧，因为很有可能会发生的事情是，他们将对项目进行有力的控制并逐步淘汰您，否则将导致大规模的混乱和失败的项目。

编辑：不幸的是，那艘船已经为您航行，但还不要绝望。您仍然可以做一些事情以最大程度地减少即将出现的痛苦。无论如何，绝对要确保他们是一位且只有一位项目经理和产品所有者，并且此人与您的组织/公司有关联。此人必须具有计划冲刺，包括或删除用户故事并将任务分配给公司以及客户公司中资源的能力。无论发生什么情况，请确保您公司的开发资源不会与客户资源分开工作，更重要的是，请勿允许您公司中的开发人员向其项目经理或产品所有者报告！他们将充分利用合同未涵盖的免费工作，或者将您拒之门外。可以肯定的。

从法律的角度来看，您基本上是在问“骑驴被雷场蒙上眼睛的最佳方法是什么？”

从编程的角度来看，我会要求提供更多信息-是否可以使用某种用户定义的EAV系统或可添加到系统中的挂钩来实现客户端的要求？理想情况下，出于各种原因，我希望使客户端的代码与您的代码尽可能分开。

通常有人在这里扮演客户的角色。老实说，我不会遇到这个问题，因为如果到此为止，您将使用我的CI设置和QA设置来测试事情，这将在我的源代码控制中。这种安排可能很难设置-我从顾问那里得到了很多建议，尤其是事情进展顺利。流程似乎与计费时间相关。

我认为您的观点确实有些歪斜。首先，请记住，它不是您的代码库，而是我们的代码库。其次，在大多数情况下，客户端的IT商店更有动力确保此产品按设计工作，并且易于维护，管理和支持。与大多数顾问不同，重新投入精力来修复错误对我们来说不是更多的收费时间。此外，当您也拥有代币的操作方面时，构建易于配置且以可预见的方式失败的事物就显得尤为重要。您可能最终会获得更高质量的项目，因为部分开发人员不受可计费时间的限制。

就如何使其有效而言，DCVS绝对是可以实现的方法。选择中立的东西（bitbucket，github）可以有所帮助。在这里放置CI也是一个天赐之物-当每个人都知道在上一次提交时摆脱了重击时，事情很难摆脱。如果您可以强制通过CI部署某些东西（我们通常必须强加给供应商），那么您就可以确保所有更改都已提交。在培训方面，您是否考虑过与客户配对几天？这可能是建立所需横向连接的好方法。总的来说，最好的办法是说服每个人加入同一个团队。因为他们在同一个团队中。

似乎这是一个管理问题，因为这是一个技术问题。我已经在咨询公司和软件公司中处理过这种情况。从总体上“客户将从软件中获得多少价值？” 和“在后期制作中我需要付出多少努力？” 这实际上对您来说是一个好情况。许多客户坚持要求其员工参与其中。尽管这将需要很多工作。

从结局开始，您将需要一个良好的工作陈述。这将列出您的用途以及他们的用途。一个角色和责任矩阵是一个不太墨守成规文档描述了谁拥有的每个项目，涉及到谁，谁只需要通知。这两个条件都假定您具有定义明确的工作分解结构，该结构以较低的级别列出（足以估计）每个任务的含义。

在创建方面，通常是相反的顺序：作用域（您显然已经拥有）-> WBS（您可能已经拥有）->角色和职责矩阵-> SOW。

明确定义所有权后，就可以管理代码和环境了。我对代码管理工具不了解。我要说的是，对核心团队外部人员所做的所有事情进行代码审查至关重要。如果您使用的工具对此进行了标记，那就更好了。您要避免有人束手无策，而这与先前做出的关键体系结构决策背道而驰。4眼概念（另2眼则复习所有事物）是您可以做出的最重要的战术决策。

环境也难以管理。通常，我遇到过这样的情况：“我们在环境中进行工作，完成时交给您自己去做”，而供应商和客户都在为此苦苦挣扎。您的情况听起来更复杂。我建议尝试找到一种方法让他们在您的环境中工作，直到项目完成为止。如果您能找到一种方法来培训客户如何管理他们的环境（不要以为他们擅长于此），那就更好了。

其他一些警告...

1. 不要以为客户的生产力与您的团队相同。（您会在域知识上获得惊喜，在软件特定速度上获得惊喜。）

2. 不要以为客户知道您的方法。

3. 不要以为客户分享您团队的职业道德。（我已经看到了向上和向下的惊喜。）

4. 花大量的时间进行培训和安排。

5. 花费每个小时教客户进行故障排除将在未来节省很多天。

6. 请利用客户为您的内部组织工作，并找到有关内容和领域问题的专家。

7. 要利用客户来销售培训他们的组织。

8. 默认情况下，让客户参与您的开发过程会迫使您像专业服务公司一样思考。 大卫·梅斯特（David Maister）撰写了有关该主题的最好的书。即使只有20％与您相关，也值得一读。

尽管有所有这些警告，但您团队中的客户仍然可以创造奇迹，使您与购买者之间的距离更近。这些客户最有可能成为将来的参考。充分利用这种情况，祝您好运！

绝对应该向您的客户介绍如何进行所有设置，这应该是在第一阶段中签字的要求。您应该推迟允许客户直接编辑任何内容，他应该填写一个更改请求，该更改请求将输入到您的问题跟踪系统中，并优先处理其余工作。您和您的客户可以决定哪些请求不在合同范围之内。应该如何在某种变更管理工作流/文档中设计这种情况的发生方式，如果不存在这种情况，我强烈建议您创建一个，并让您的客户同意这是他可以更改并获得此结果的过程。写作。否则，除了祈祷没有错，您无能为力。