判断是否是合理需求，分析权重及紧急情况进行安排

leader应该是PM和程序员之间的防火墙，如果你觉得一个需求确实有意义，且确实不会造成delay可以接。你也要做好跟程序员的解释工作。反过来，如果PM的需求太多，严重影响了team的开发进度，你要勇敢说不。

给你两个简单的建议

1.不能把决策过程暴露出去.

无论需求是否合理, 收集需求和决策绝不同时进行, 你们部门的开发节奏由你来掌控. 如果暴露了决策过程, pm今天可以跟你聊加需求, 明天就可以饶过你直接找程序员改代码, 这是程序开发的大忌.

2.无论对方提什么要求, 你也对对方提一个

很多人在管理上走不远,在谈判的时候被情商高的人吊打是常有的事, 记住这个原则死的不会太难看吧.

有一些专门程序员管理的书可以看看, 比如<IT项目经理成长手记>

JIRA排期 分优先级

3楼 @梦中醒不过来

2.无论对方提什么要求, 你也对对方提一个

很多人在管理上走不远,在谈判的时候被情商高的人吊打是常有的事, 记住这个原则死的不会太难看吧.

突然知道自己经常被吊打的原因。;(

3楼 @梦中醒不过来 感谢点拨！ 书已下单

2楼 @tinyfool 之前确实没理解这层责任，感谢~

确实不是一个小时的问题。因为你要先从现在的开发思路出来。很多时候，赶工一小时后，回头得重新找思路了。当然，这种情况也不完全是没有办法的。但对开发的影响，可能不是表面上看起来那么小。作为Leader应该对组内开发的工作饱和度有一个基本的判断。比如你说到的妹子，如果本身开发任务就相对紧张，就要考虑这个需求有没有别的富闲人力可以接手。还要分清，接手的人是领了任务就可以自己干的人？还是令了任务得让妹子先带一天才能开始干活的人？

也就是说，接不接新需求，要根据你手上的人力情况来判断，而不仅仅是需求本身。如果自己手上的人力排不过来，就要和产品商量，先停掉还待开发的需求。当然，要做好撤需求的评估，包括代码回滚和代码评审，已经回滚后回归测试等问题。