我是一名初级程序员.由于我的主管告诉我和客户坐在一起,我加入了.尽管成功(从我的程序员的角度来看)项目的交付,我看到了客户不满意的表情!
客户:你可以包括这个!
我们:不在规范中!
客户:常识!
作为程序员,您如何应对这种情况？
你应该怎么做才能避免这种情况:
明确指出将包含哪些内容以及不包含哪些内容.
问题可能归结为规范的未指定部分:
客户认为应该有未指明的东西,即暗示.
开发人员认为不应该有未指定的东西.
对于您拥有的未来规范,您应该有一个catch all语句,该语句明确指出如果本文档中未指定某些内容,则可以在原始规范完成后以额外成本完成.
在目前的情况下你应该做些什么:
除了从您的经验中学习,您应该与客户达成妥协.
示例:我将执行您认为常识的此功能,但是对于所有未来的添加/更改,必须明确指出.
也就是说,你将不得不做更多的工作,但值得一提的是,所有明确规定的客户将签订协议.
糟糕的规格？
这一定是一个糟糕的规范吗？没有.
无法提及客户可能期望的所有内容,因此在您的规范/合同中清楚明确地说明上述所有声明至关重要.
其他减少问题的方法:
尽早介入客户,向他们展示早期原型.即使他们不要求它.
尽量不向客户销售最终产品,但更多的是为他的产品提供服务.
考虑一个敏捷开发模型或类似的东西,以便任务定义明确,小,付费和无可争议.
这将是我转向敏捷开发理念的众多原因之一.在我看来,成功避免这种情况的唯一方法是要么无所不知,要么大量涉及客户并经常发布/经常发布以尽快获得反馈.这样你就可以开发出客户真正想要的软件,而不是客户告诉你他们想要的软件.
客户:你可以包括这个!
我们:不在规范中!
客户:常识!!
我们:我们不会尝试超越客户指定的范围 - 我们遵循规范.重要的是不实现未指定的功能,因为它实现了指定的功能.我们永远不会再猜测我们的客户,他们重视这样一个事实:他们可以完全依赖我们在预算内按时正确地完成规范.
正如其他人非常正确地指出的那样,情况几乎总是比我上面描述的简单交换更复杂.
但是,如果实施者有一个带有客户签名的规范,则上述内容是有效的,该规范基本上实现了一个协议,即"一旦软件可证明地实现了规范中的所有功能,那么它就被认为是完整的",并且任何其他内容都在规范,因此在合同之外.
合同本身也可能有一些意见 - 如果你没有签署合同而不是规范中的内容 - 到目前为止所做的一切都是在握手时完成的,整个交易(包括付款)可以基于对任何一方的任何不满而下厕所.
但是如果你有合同和规格,并且客户已经看到并签署了这两份合同,那么他们就没有足够的空间来要求你进一步.
现在,关于是否应该实施它的问题:
真棒! 您交付了一个产品,他们只有一个投诉.实施该功能,称之为"免费赠品(确保他们理解您的工作超出规范和合同,明确向他们发送工作账单,并以美元显示折扣)并让他们在整个项目上签字.
它将明确地证明项目已经结束,你超越了职责,并且任何进一步的"惊喜"超出了合同/规范,这为你提供了一个超出你已经(表面上)的保护层有.
如果这是一个用户界面问题,那么你就会陷入困境.
规范是否充分描述了用户界面？它有样机吗？如果规范没有非常详细地描述布局,用法和包括模型,我不会对客户提出关于UI的投诉.
无论哪种方式,我认为你可以理解客户的立场 - 如果他们没有玩过UI模型,那么无论如何他们都会对结果感到失望 - 从心理上讲,你和你的客户可能没有办法心中有同样的想法(不要忘记常识不是!).
坦率地说,如果这是客户第一次考虑在工作完成之前检查UI,那么至少部分是因为没有向他们解释良好的UI设计流程.这是他们的应用程序的一个关键功能,它与他们想象的非常紧密耦合 - 在这种情况下没有人会满意,除非他们随着时间的推移'增长'他们的内部表现以匹配现实.
这种断开只能通过频繁的用户和客户测试来解决,这显然是缺失的.这是关于客户教育和沟通的问题,而不是规范是否得到满足.
-亚当
期待最后一刻的范围变更 - 它们总是发生,所以要做好准备.
经常与客户审查进度 - 以尽量减少意外.
合同:功能规格,加上具有初始上限的时间和材料(因此客户感觉控制).然后,当出现变化时,如有必要,重新协商上限.
永远不要说他们不能拥有他们想要的东西.他们可以免费获得答案!
总是给他们比他们要求的更多,所以他们知道你有一个积极的态度.
与客户关系与他们在同一个团队中.不要接受被合法地描绘为对手.
与员工相比,他们可能会认为承包商不忠诚.告诉他们你和他们的员工一样致力于他们的成功,你会更加努力.
京公网安备 11010802040832号 | 京ICP备19059560号-6 