昨天项目经理安排了个任务，分析当前项目的重要任务，本来要10号输出就行，结果下午突然检查我的功课。幸亏昨天晚上留在办公室做了点准备，加上这段时间一直在留心项目经理提到的事情，心里还算有准备，虽然项目经理不是特别满意我的答复，不过总算是混了过去。从项目经理的表情和反应看，我这一关过的比较险，思路不太合意。
从这件事情而言，得到一些小小的心得。
作为程序员而言，领导安排个活，比如修改问题单，站在程序员的角度来说，神挡杀神，佛挡杀佛，遇一个解决一个，不需要考虑太多；但是站在项目经理的角度考虑这个问题时，结论可能就大不相同。首先，项目经理会认为做一件事情最重要的是确定目标和意义，完成这件事情所需要投入的资源和完成这件事情的计划，至于完成这件事情时具体采取的策略，项目经理可能就不会太上心了，最多就是希望程序员可以经常性的报告状态，降低管理的风险。
对应到修改问题单这件事情，上述的几点可能都比较简单。目标非常清楚，比如在项目结束前，修正全部的问题单（这个要求比较高，一般都达不到）。修改问题单需要投入的资源，最直接的就是人力，那么需要多少人专职做这件事情呢，这需要依据实际情况来确定，如果问题数量很多，那么可能全项目组都要投入，如果问题数量较少，就可以事件触发或者安排程序员专职投入。修改计划，在问题单数量比较多的时候，为了降低管理的风险，这时特别需要程序员提供一个修改计划，明确下修改的进度，方便项目经理根据计划来管理问题，比如对于在计划时间内未完成修改的问题单需要分析原因和对策，避免影响项目整体的计划。
那么为什么项目经理会这样想呢？还是以修改问题为例。
问题单肯定是要清理的，但是每一项目也是有截止时间的，不可能为了某一个问题花费过多的时间而影响到项目的整体计划。另外为了方便其他支撑人员比如QA，为他们预留更多的时间，问题单肯定不能拖到截止时间才去修改，因此项目经理希望领到任务的程序员可以根据自己对问题的分析，首先给出一个修改计划和风险列表，然后在修改过程中经常性的刷新这个列表。另外，透过现象要看到本质，项目经理其实希望程序员可以做的更多，比如对问题单作个简要的分析，确定问题引入的原因和时间点，确定问题所在模块的质量状况，或者分析一下问题单的分布情况是否合理，从数量和代码覆盖率等维度分析，给出一个像样的结论。
思维好像有点混乱，可能一下子理不清我的真正感受。用一句话总结一下，不谋全局者不足以谋一域，不谋万世者不足以谋一时。假如永远站在小兵的立场上考虑问题，那么升职的机会到了眼前，可能还是把握不住。平时多练习一下以他人的角度考虑问题，机会来临时也许就不会太慌乱了。
另外的心得，项目经理做为项目管理者，需要依赖程序员把项目做好，不可能所有事情都亲力亲为，所以项目经理在项目中的最大贡献不于是在亲手写了多少代码、修改了多少问题单，而是站在一定的高度为参与项目的程序员指明方向，合理利用当前可用的资源把项目做到最好。从我个人角度看，作为项目经理参与项目开发是好事，但是不能本末倒置，把重要工作忘掉；当然了，做为项目经理对代码很熟悉、对技术很敏感的话，相信在参与项目的成员内应当更有威信，讲话更有说服力。
。。。。。。。。。。。
下午一个前同事突然发消息说恭喜我工作满X年了，问我有什么感想。。。此处省略XX个汉字。其实没有太多的感想，只有头痛。工作满第一年的时候还挺有想法，拉一起培训的同事出去吃饭、K歌、打游戏，后来工作久了，渐渐的都失去了联系，也对出去玩失去了动力。在公司工作的大学同学工作都比较忙，平时能聚在一起吃个饭，饭后顺便打个牌就已经是奢望了。现在头痛的事情比较多，比如在公司，工作这么久了居然还是小兵，前天看公司组织的培训，由来自百度的架构师来讲解百度XXX产品的演进和未来的发展（想不起来培训主题了，可能是年纪大了）。一看讲师的简历就让人郁闷，07年毕业进入百度，工作至今已经是某产品的首席架构师、委员会主度。。。唉，人比人，气死人呀。相比之下，我进步的实在是太慢了。工作之余确实需要为自己考虑一下了。