当客户自由/订约时,通常会指定功能需求、验收标准等,实现细节掌握在开发人员手中。
作为一名开发人员,您的技术选择是在您最熟悉的技术、技术上正确的工具、很容易找到具有这种技能和费用的编码人员以及其他几个因素之间的平衡行为。
我所处的情况是,我已经评估了我的选择,并选择了一种有点模糊的开源技术,我相信这种技术将使我更快、更容易、更易于维护。这是不同的,但我认为这正是需求所要求的。
客户已经询问了我将使用什么来构建解决方案,现在他们很担心,因为他们以前从未听说过它。我选择的原因主要是技术上的,而客户则不是(但他们知道一些时髦的字眼!)解释这些技术原因并不容易,我也不确定这是否正确的方式来处理这种情况。
这就是我的问题:怎样才能正确地处理这种情况,从而使每一个参与者的头痛程度降到最低?
发布于 2012-10-05 17:43:19
我相信这些技术将使我更快、更容易、更易于维护。
你就是这么证明的。如果他们不相信你做出这样的评估,那么他们就有权自己做出评估。但是,除非为时已晚,否则要明确这会影响你的评估,因为你的评估是基于你选择最佳技术的能力。
他们甚至可能会决定,他们很乐意承受现在的财政打击,因为他们可以在以后用另一个开发人员代替你。或者,事实上,出于任何其他对他们有意义的原因。他们有权作出这一选择。请记住,您的优先级(速度、简单性和维护性)可能与他们的不匹配,最终是他们的钱。
发布于 2012-10-05 17:48:03
我相信这些技术将使我更快、更容易、更易于维护。
这一理由不会使你的提案成为赢家。您的建议应该满足他们的业务需求,并具有成本效益、灵活性和可维护性。
业务希望得到的是:一个用户友好且信息丰富的UI,在后端具有强大的功能。因此,客户更关心的是好的应用程序如何吸引眼球,并使他们的业务更容易管理。
因此,说X技术将解决他们的业务问题,它将很快实现,将落后于预期。然而,让客户相信以前复杂的菜单导航将被直观的UI和灵活的后端引擎所取代,这样就可以更容易地定制服务,这将是接受您的建议的一个重要卖点。
发布于 2012-10-05 18:46:08
程序员通常更有能力知道哪种工具(技术)最适合手头的任务;然而,尽管如此,您的理由不应该来自程序员的角度,而应该来自您的客户的角度。
也就是说,你需要了解一下你的客户以及他们关心的是什么。例如,您提到了这样一个事实,即您选择了一个更晦涩的开源解决方案。如果客户高度重视能够为将来的维护带来运行中的开发人员,这可能不是一个好的选择,因为它与他们的优先级相权衡。
不管某些技术对于手头的技术任务有多适合,但对于客户来说,有一些业务方面的问题可能更有意义。最终,门外汉不关心技术细节,只关心后果。
https://softwareengineering.stackexchange.com/questions/167652
复制相似问题