18 | 需求管理：太多人给你安排任务，怎么办？

为了适当减少每次argue需求优先级带来的沟通成本，还可以把当前团队正在面对的四象限公示出来，让大家都能看到团队路线图，让提需求的人（产品经理更需要）看看自己的需求在哪个象限，什么优先级，有时候他们自己就明白了

程序员也应该更积极主动一些, 最好能推动事情发展, 当这件事情由你推动时主动权就在你的手里了

应该极力拓宽自己的视野，人容易被自己所限制，束缚不仅仅来自于外部，也很多来自于人自身。

开发团队无力反驳产品经理的需求，工作方式被动，话语权受限也是原因之一。虽说公司内各有分工，但大部分公司还是具备宽松氛围的，一直从事某产品开发的员工，只要不局限于自己的一亩三分地，即便不具备老板的视角，产品经理那点小九九还是能有对策的。其实不管是谁，什么角色，掌握工作的主动权最重要，重大事项商量着办，彼此协作才能越发默契。

团队中的需求来源就是简单文字描述，而且还是上一层需求收集人员理解以后补充上去，再给到产品经理那里。和文章说的，很多时候，就是某位领导说要做的。而团队中负责人听到是某领导提出时，并没有给出相应的方案，结果是都要做。提出的所有需求，都是紧急且重要的。因信息不对称，底下人很难判断其紧急和重要的程度。结果就是不停的加班，通宵赶进度，留下很多的技术债务。

做重要的事，或者说跳活干，才能拿到好绩效。

这篇说的太对了，我一直构思的整个系统完工后交付，有次开会，领导说，系统的1-3功能是重要的。其他的延期没影响，其中系统的1功能是必须要有，且要额外丰富功能。瞬间就感觉工作重点不一样了。时间也很宽裕。那种感觉，就像堵住的鼻孔突然打开。

http://ime.geekbang.org/column/article/76260 “精益创业：产品经理不靠谱，你该怎么办？ 打不开了

二刷的收获：管理好任务的优先级，并尽量想清楚关键任务的价值。积极主动，让自己收获更多！

1 套路包收集，留证据，把面对不确定性的决策风险（锅）甩给产品，把自己定位搬砖的。 关于尽量做重要的事，个人理解如下。 做好重要不紧急的事。 这项能力决定了人生的高度，是我开发生涯的信条。 例如重构，轮子优化，（极端情况下直接造），这些努力的背后哲学是，让体力活向智力活迁移，有时候少做是高纬度的多。 例如 在开发中不断和产品沟通已期待更好的为用户服务，更合适的开发资源投入。 文中谈到了站在老板面前。 我回忆了一下，好像更多是直接推开老板们，看他不忙就直接沟通的，关键问题直接硬怼，沟通能三句话说明白不扯第四句，有开脑洞场景的再放开聊，庆幸老板懂技术。 真的别怕，也没必要怕，我是信奉技术王道的，而我的目标是专注做优质产品的，我有问题你直接说，我思考后改（还有可能不改） ，大家目标一致，严重忙不过来，哪有空怕老板。 只管向死而生的活着。注意下身边的小人即可，这类人多了，直接走，也别犹豫。