我读了 什么 - 支付 - 结构 - 你用于小项目 ,我想知道你们如何处理bug与功能.我曾经遇到过客户想要静态报告的情况.然后在项目结束后,大部分报告工作完成后,他说他一直想要动态报告.这种变化并不容易,因为我们选择的框架不支持动态报告.这是一个奇怪的情况,因为客户有一个编程团队,所以他们应该知道.也许这只是缺乏沟通技巧.
你们如何处理试图让你添加功能的客户,因为他们忘记了,改变了主意,或者被误解了？
我的意思是大功能,而不是小功能.
编辑:
他表示预算是固定的,无法改变,而且这个功能(如同每个)都很关键,如果没有它,他们就不会接受这个系统.(只是最糟糕的情况)
根据我的经验,在这个问题的两个方面,这通常更多的是关于经济学而不是关于编程,流程或项目管理.
我们,客户,经常说"它可能是一个功能,但如果我们称之为错误,也许我们可以让他们免费使用它."
最后,我们,程序员,收取或不收取更多的费用,取决于它是否会有助于或损害我们未来工作的机会.我们作为客户,将未来工作的胡扯作为让程序员免费完成额外工作的动力.
我不相信任何改变只是因为我们有一个更好的流程来说"这是一个错误"或"这是一个新功能".
重要的是,双方必须在软件开发过程中尽早了解他们的资金.敏捷方法论是管理这一过程的绝佳工具.如果您拥有团队的速度,则可以相当准确地确定在每次迭代期间可以添加的功能数量.估算任务,让客户参与确定要添加的功能的优先级以及哪些功能不太重要.确保在每次迭代后都有一个客户演示,以显示您同意在当前迭代结束时工作的工作功能.如果客户需要其他功能或显着更改您已经同意的功能,估计必要的故事点数(敏捷中使用的工作单元)来进行这一新的更改或返工当前的功能.这将有助于他们删除他们认为不如他们刚才建议的那个重要的另一个功能.这让每个人都感到高兴,当产品"发货"时没有任何意外
试图将它们与该功能争论是没有意义的.毕竟,沟通问题与否,其任务是提供客户在软件中需要的东西.
我将使用Iron三角形论证如下:
1)显然我们想要提供您需要的产品,所以让我们一起工作.
2)我们都明白,无论我们如何达到目前的水平,我们都只能从现在的位置前进.
3)我们也明白,实施变革需要时间和金钱,这些都来自某个地方.
4)此时你的选择是这些(选择一个)
*用这项改变所需的工作替换为其他功能计划的工作以保持预算和时间表(牺牲其他功能)
*延长截止日期(增加成本/轮班截止日期)
*增加资源(增加成本)
警告:虽然如果您正在进行制造类型的工作(构建另外1000支铅笔),C具有逻辑意义,但在像软件工程这样的研发工作中,它通常只是B的另一种风格,您可以放大成本和截止日期.
京公网安备 11010802040832号 | 京ICP备19059560号-6 