在开发的日常工作中，已经交付的功能却被产品说要加个“小调整”，催着求着想要赶紧加上去，是非常常见的场景。
虽然调整是一件很正常的事情。敏捷的方案就是要适应调整，但是往往问产品的人：“改完这个后，是不是还可能有其他调整？”
得到的回答往往是：“不能保证没有。”
最后时间可能花在一些不重要的“小调整”上面，让其他更重要的功能无法上线。
那么今天的极限拷问来了：
1.你认为他为什么这么着急做这个小调整？
2.你会如何应对他的这个要求？
3.你会建议在未来做什么改进？
面对这样需求不断调整的情况，可能有些同学的想法和做法是：
“ 产品是甲方爸爸，他说怎么改就怎么改，他是产品拥有者。”
“ 应对办法，愿改就改，不愿改就离职，不帮他干活了。给产品工作就这样的，开发只是一个执行者，没有权利说不。”
“虽然技术上做不到想改就可以随时改并且快速上线质量没问题，但是这些风险产品都是知道的， 既然他愿意在产品上加大投入，那开发就开活啦，反正每个月不少工资，顺便再坑点加班费”
但仔细想来，产品只是站在用户的角度来给开发的同学提出需求，并不是必须指哪儿打哪儿。软件开发中要避免产品做产品的，开发做开发的，测试做测试的， 避免竖井思维，大家有一个共同的目标是 怎么把产品做好， 怎么给用户提供有价值的服务。
着急做出“小调整”的情况，总结起来大概分这么几种：
产品经验不多，导致需要经常有些小改动。
一厢情愿的认为是对的、很重要。
有时候在产品的制作过程中，产品经理只是累加的功能，虽然都是经过对方考虑的，但是对方无法听取其他人的意见或者听到其他人的意见就感觉自己有挫败感。有可能对方的出发点是好的，但是实践过程中沿用了自己旧的方式，最终导致冲突点很多，修改的理由也是匮乏的。
市场商机非常敏锐，需要作出调整。
尤其是ToC的产品，一些时间点非常重要，错过就会造成很大的损失。有些问题是混沌的问题，虽然没有办法证明那些时机是百分之百可靠的，只能通过结果证明。
政策原因
比如银行清分、当前的大商户模式，在过去一段时间逐渐严格化。这些政策原因直接导致了功能的调整。如果不作出调整，后续的功能或者商业模式都会受到影响。
那么遇到这种情况应该怎么做呢？
如果是刚刚和接触，还未建立信任，并不会直接上来阻止对方，而是先了解对方的真正目的是什么？综合以下几个方面考虑并与对方达成共识：
对于“小调整” 考虑是否涉及到其它部门的协调、比如测试团队相关人员等。衡量与目前正在开发的需求之间的 优先级 ，决定是否动手；
目前上线的功能是否对于用户的使用有影响？产品方面是否知道紧急上线的风险？
避免只用口盾，寻找机会来达成协作上的共识，可以基于当时的上下文添加约束也可以删除约束。
当然，如果已经建立了信任，那么就直接聊是什么、为什么、怎么做；然后进行下一步动作就可以了。
在未来的工作中，想要积极避免此类情况，可以在以下方面做出改进：
基础建立。 基于事实、结果建立信任。
团队协作。 基于当时环境的环境上下文来协调沟通。知道对方关注什么，没有关注到什么，用共同遇到的事情来推动磨合，避免这是单方面认为是产品问题或者单方面认为是技术问题。
技术准备。 针对已经出现过的情况，调整技术架构，技术实现来准备响应方案。
定期回顾改进。 不同的上下文会有不同的处理方案，让响应产品需求的能力成为团队的能力而不是单个人决定，避免这类个人瓶颈的出现。
请你吃饭
【极限编程中国 | 实践者】微信群今日中奖
@北京-李义@深圳-大可-Ray
内容来源
本期内容整合自 【极限编程中国 | 实践者】
内容贡献者：
如果你也想加入讨论，获取干货
迅速成长，提高效率
欢迎加入我们
↓↓↓
▲【极限编程中国 | 实践者】微信群
↓↓↓
怎样加入我们
限时免费加入
【极限编程中国 | 实践者】微信群
和前ThoughtWorks总监咨询师熊节实践敏捷开发返回搜狐，查看更多
责任编辑：
京公网安备
11010202010575号
加载中,请稍侯......