开发人员习惯于说YES。好比自己是超级黑客，一旦有了计算机这样的武器就无所不能，当超人的感觉非常好，尤其是被别人认为是无所不能的时候，尤其是。开发非常担心如果说不，会让提出请求的人失望，进而影响自己的光辉形象。
但是要知道，每一个说YES的背后，承载了重重的客户期望。期望能够尽早的保质保量的吗完成你答应的工作。如果对于每一个客户的请求都说YES，就意味着你要用自己有限的资源去满足每一个人的请求，每说一次YES就意味着你的承诺被稀释了一次，每一次YES实际上就相当于对之前的客户说NO。
所以开发人员的工作不是用来对所有的请求说YES的，而是尽早的交付高质量高价值的软件。所以，如果想把自己的工作干好就要学会说不。
1、明确的说不
要非常明确的表达出你不做的意愿，但是要用比较客气的说法：抱歉这个功能实在是在这个迭代没有办法开始。因为这个迭代我们已经答应了某某产品经理一定要完成某某某功能，我需要全力投入在这个功能上。如果把你的这个功能放进来的话，那我们对某某产品经理的保证就要大打折扣了。但是如果你让PO把这个功能排到下个迭代的最高优先级，那我们就会考虑如何去实现它。
2、说NO的时候只给一个最有力的理由
当团队外部人员向你提出一个功能请求的时候，注意一般情况下敏捷团队需要作为一个整体来接受请求，而不是某个成员直接来接受外部请求。这个时候，可以这么说：不好意思，我现在没法开始你这个需求。我们这个迭代已经开过计划会了，如果要接受这个请求的话，我们团队还需要针对你这个需求另开一次计划会议，大家可不喜欢这样。如果你觉得这个请求的优先级非常高的话，可以找PO商量排一下优先级，我们按照优先级高低就可以放到合适的迭代开始了。
3. 因为共同的目标而说NO
有时候经理会不断得加任务给你，因为他她是你的上级，这个时候说NO就需要更加有智慧。可以想想经理和产品经理是不是有共同的目标，例如在敏捷环境下，大家都会遵守DOD标准。这个时候就可以这么说：我也想立刻开始这项任务，但是如果这样做的话我手上原先答应任务的DOD标准就会受到严重影响，当初我们制定的这些DOD标准可都是血泪换来的呀，您说呢。
当你的经理不认同你的目标的时候，注意一定要坚守研发人员的个人修养，不写BUG，不写BUG，不写BUG，为此我必须花时间来保证质量，心中默念。然后可以说：既然您认为这任务确实重要，必须马上开干，而且其他的任务也必须完成，那根据我的估算需要额外的多少多少时间才能保证质量，但是目前的工作已经把加班时间和周六日都排满了，要不把最终发布日期往后调某某天？如果经理还不同意，那么就再说：那这样的话，我会努力完成，但实在没有办法保证这个功能的质量，你得允许我在发版后再改某某天的BUG，然后可能需要发一个补丁版才行，您看怎么样？如果经理还不同意，那就再说：现在这些任务确实非常重要，但又不能保质保量的全部完成，要不您从哪哪调一个人来帮我把某某任务搞定，这样风险就小多了，如何呢？如果经理还不同意，在心里默念三声，我这是为了经理好，然后再说：我非常想把这些功能全部实现，而且还能保证质量。但实在是完成不了，只能把某个低优先级的任务拿走了，您给想想办法。
4. 解释你说NO得原因
有些时候，提出请求的人并不了解这项任务的真正影响。这个时候需要清晰的解释如果说YES的后果。可以这么说：如果我现在开始你的请求的话，那我们组每天的BUG净降目标就达不到了，这样会影响我们最终的发版时间的。或者这么说：我目前的工作量非常大，已经天天加班到九十点了，如果不把我手上得已经答应某某的工作移走一部分的话，我是实在没办法接你这个请求的。
5. 说NO的时候表达对对方的理解
有些时候让请求提出方觉得你确实已经理解他们请求的重要性也可以让对方更容易接受你说的NO。比如可以这么说：你说得这个功能我理解是为了解决某某客户的某某问题，确实很重要的一个改动，可以给客户带来某某价值。我也理解你为什么觉得这个功能这么重要了。不过这个功能的影响面可不小，它不应该是一个BUG，你最好找PO把它开成一个Story，然后我们大家来计划一下看什么时候开始着手。
最后再强调一点，当一个开发人员总是说YES的时候，要么这个开发就是超人。要么大家，包括你的经理、高层经理、需求人员、产品经理都会对你不满意。大家会说，这个家伙每次答应的好好的，结果要不就是拖延，要不就是质量很差，唉，靠不住呀靠不住！而当你很智慧的说NO的时候，大家最好后对你有这样的评价，这个家伙挺有想法，虽然每次让他干活都得费一番口舌，不过他一旦答应了你，就很快能把任务做完而且质量还很好。有个性有能力，人才呀。
想想两种结果，你会说YES还是说NO呢？
请务必大大方方的说NO，大大方方的对你的上级、你的产品经理、你的高层经理、你的外部团队说，NNNNNNNNNOOOOOOOOOOooooooooo!
Master同样适用本文，不过可能需要更好的谈判技巧，您说呢？
