除了写代码，Dev平时还干点啥？
　　如果脱离开PM的角度，做为一个孤傲的开发，时常会觉得PM为什么老是问我进度，是不是怀疑我的能力？为什么监视我的工作？相信我，其实他才不想监视你。但是你设想一下：如果你不参与代码编写，每天只是看旁边的哥们写，你如何知道他实际的进度呢？而且众所周知，开发很难准确的更新自己的工作进度，而且遇到问题也很少积极主动的报告，通常都会自己埋头尝试解决。那么，轮询显然是一种成本最低，反馈最快的方法。
　　不主动更新进度是另外一个大问题，不过这个得单独说。关于更新进度，典型的的场景是：早上站会的时候，开发目光呆滞的盯着某个卡片，努力回忆其中的验收条件以及自己的当前进度，如果恰好脑海中的技术细节和卡片的描述在某个点上匹配了，他会迅速的告诉你，目前进展良好，今天上午应该就可以做完。开发在更新进度时，不是盲目乐观，就是跳进太细节的地方进行讨论，最后讨论的结果就是：跟没更新一样，除了浪费了10分钟时间。但是别忘了，PM会在15分钟之后再来轮询一次。
　　PM每周都需要汇总很多数字，比如本迭代完成的点数，剩余的点数，总体进度如何，有没有人有请假计划，遇到什么blocker，每个blocker的具体原因，每个风险点的最终日期是何时，等等等等。他肯定不能记住这些数字，所以可能一天之内向你询问数次。
　　PM的其他职责/技能
　　上边说到的其实只是描述PM的辛苦，而最微妙，最考验PM的是其“察言观色”的技能。这绝对是一个工作经验在10年之内完全无法获得的技能（而且是在中国的项目上工作10年）。比如，在showcase的时候，有个客户说，嗯，挺好，整个流程就是这样的，后续你们的UI是不是还会美化？如果你遇到这个情况，请问，这个客户是什么意思？
　　如果你能回答上这个问题（而不是提出问题），那说明你还离PM差十万八千里。成熟的PM会先判断，问这个问题的人是什么角色，以及他在系统中的话语权如何，还有其他人就此问题的反应如何等等因素，然后找到一个合适的答案。
　　PM另一个绝技是扯皮（不是贬义），开发会花一个下午（我是说10分钟）去跟客户讨论需求的范围吗？或者会为5个人天来讨价还价吗？我想开发大概会说，尼玛，找其他供应商吧，老子不伺候了。
　　一个项目的成功，需要多方合作，这里说的合作并不局限在甲方和乙方之间，即使乙方的团队之中，也需要很紧密的合作。比如项目经理和开发，设计师之间的合作。如果仅仅从开发的角度来看，PM有时候看起来就是和客户站在一起来整开发的一样，比如催进度，过分保守的估算人天（导致团队加班赶工）。PM需要释放团队中的负面情绪，保证团队士气，还需要他做一些开发不屑于做的琐碎的事情。

设身处地，提他人着想
　　本质来来说，每个项目都是一次生意。在去掉那些繁杂的流程和形式之后，做一个项目和你去菜市场买菜其实并无二致。举个例子，根据传统，软件开发界特别喜欢找建筑行业做类比，我也找个建筑方面例子。装修房子的时候，我们会要求施工方提供图纸（水电改造，基本设计等），按期交付（确定工期），同时会界定项目范围（比如刷墙，贴地砖，吊顶，封阳台等等），会要求工人按时来上班，正常出勤，认真工作，直到项目结束。过程中我们还会讨价还价，比如捎带着把栏杆拆除，捎带着敲掉一面隔离墙等等。在过程中，我们还会敲敲地砖，检查过门石，检查吊顶，测试水电等等。作为甲方，这些活动相信没有人会觉得过分。
　　但是一旦我们做乙方，也就是施工方的时候，情况就全变了。比如客户要求打卡，有人会觉得不爽，客户要求代码review，有人会觉得不爽，要求代码有设计文档，有人会觉得不爽，要求设计有多个备选方案，有人会觉得不爽。大多数情况下，这都是虚无缥缈的虚荣在作祟，这种情况所在多有，不过还不致命。一旦涉及到讨价还价（不是商务上的讨价还价，而是和客户就工作量达不成一致，或者就某个技术方案达不成一致之后），开发全部歇菜，一言不合，转身就走，压根不具备讨价换件的能力，这样还怎么做生意啊？设身处地想一下，如果你是甲方，当提出了一些合理的要求（比如需要一方提供验收标准，通过验收测试等），结果施工方还一脸的“我不跟你说了，你就是以大傻B”，你能乐意吗？
　　如何合作？
　　说了这么多，这两种角色在同一个项目上要如何合作呢？我想，作为开发来说，有这样几点可能：
　　首先，理解PM的工作。在很多时候，开发会有莫名其妙的优越感（其实每个角色都会有了，比如销售看不上技术人员，技术Lead看不上PM等等），主要原因其实是坐井观天，对其他角色的辛苦和工作不清楚。然后错误的认为别人的工作都很low。
　　之前听一个同事讲过一个小session，里面有一点我印象非常深刻：不要因为一个人不会某个技术而鄙视他。就好比你不应该因为不会弹钢琴，而被一个会弹钢琴的人鄙视一样。道理很简单，但是开发在长期的“宅”生涯或者坐井观天中，进化出了这种非理性的观点：如果一个人连vim（此处的vim可以换成任何其他技术）都不会，就压根不足以谈人生。
　　其次，学习如何报告进度。PM催你的根本原因是进度不明确，如果每一个潜在的风险都清楚的显示着进度，而且有明确的负责人，PM就会降低轮询的频率。这需要开发经过刻苦的练习才能达到：
站会前自己花3分钟整理一下昨天做的工作
根据story的验收条件（最好有和BA/QA一起的讨论需求），进行合理的任务划分（tasking技能）
可以借助便签纸等工具，帮助自己明确进度（划分了5个子任务，昨天完成了3个，那么可以粗略的估计为60%）

再次，合理估算。有些时候，新人（来自于传统管理环境的新人）可能会误以为PM是一个管理的角色，或者处于某些考虑会在PM询问进度时做出一些错误的回答。比如PM在迭代启动会议上是问这个迭代我们有没有可能做完所有计划内的任务，作为一个负责任的开发，你需要在第一时间指出那些“非理性”的期望，以便PM进行更加准确的计划。
明确告诉PM，有哪些需求是不可能按时交付的，PM会根据实际情况来重新定计划，并和客户确认
明确告诉PM一些可能的风险，团队整体对交付负责，而不是PM，或者开发
　　按照经验，项目从来就不会按照计划进行，在做好一个粗略的计划之后，PM的职责更多的是进行动态调整。所以团队内部至少需要保持信息的流通，虽然可能短期来看可能会影响开发速度，但是从整体上来看，可以减少很多不必要的浪费。
　　简而言之，要站在别人的角度考虑问题：如果换做是你，你会怎么做？

这么好的东西，没人看？

太长了。。。
　　　　------情不知所起，一往而深，再而衰，三而竭。～

真长

说了那么多，还是改不了PM是傻B的本质~

太长不看

PM不出意外是全公司最累的人之一。

看人

kan bu dong

项目经理是大傻B