关于项目管理

4年半的经历中，软件工程的全部内容我都有丰富的经历。同时见过不少风格迥异的PL，PM，部长

之前一直比较抗拒走管理路线，虽然一直以来都知道技术路线在中国不合适，而且，我本人其实对技术不是很热衷，只是很热衷于享受解决问题的快感，及决定一个项目实现，需求的认同感。其实最重要的是因为我本身是一个不好管的人，是一个个人英雄主义比较重的人，怕遇到的团队成员也是像我这样。。。

但，既然我已经跨出了这一步，要去做一个pl，就要在各种管理方式及风格间做出一个抉择，来决定未来2年内我的路

在我的心目中，一个PL是一个项目的核心，他会做出一系列的决定，来分配项目成员的工作内容，计划，进度管理，并同时需要掌控项目的风险，未来，还有汇报，统计等一系列的杂事，同时做好所有的并不现实，但要以项目为主，培养人员，使大家都比较幸福比较重要

1.管理风格

我见过的有比较规矩的，比较随意的，放任自流的，把活儿干完就行的各种

暗想下，我可能是那种比较不喜欢发号施令，不喜欢开会，不喜欢活跃气氛，大家一起合作把活儿干完的PL吧....

2.例会

我一直认为开会是比较浪费生命的一个方式，会花很长时间都决定不了一件事，而且扯皮的现象会很多。但例会，成员比较少的时候，除外。

以前都没什么正规的例会，成员间的工作交流也比较少，直到有一次开会说进度，旁边同事的进度比我快了很多，我在说的时候很紧张，才明白例会的重要性。进度不是填个文档就结束的。

例会上可以发现当时工作内容的问题，同时可以锻炼组内成员的表达能力。

但，我觉得，可以在例会中减少进度确认的时间，而增加发现问题，解决问题的时间。

●比如，可以做一个小的工具，把每日的任务及时间，完成到何种状态来划分汇报，如果PL有不明白的部分，再在例会上确认，同时可以将各个组员的进度汇总，在例会上说明（有图表的比较好，这样能看到未来，比较容易统计工作量和工作能力）

3.任务安排

我一直比较讨厌耳提面命式，说教式，说明暧昧的任务分配

●任务分配首先应该看这个人的能力，以及他想做的内容，而不是哪儿缺人都可以补上

所以我应该会先了解成员的履历，看看他们都做过什么，没做过什么，想做什么，及他们对之前自己的工作的满意度，再来安排他们的工作内容，当然，不是每个人都有想做的事，或者没有他想做的事，或者大家都想做同一件事，这样的情况也是不可避免的，但我觉得如果你做了了解这一步，就算当时无法满足他的愿望，也可以在以后考虑他想做的事。

如果能大家坐一起要任务，争任务就更好了，哈。最好别给我个时间紧迫的活儿，那样我就是想法再多都没法实现……

4.进度

其实进度确认是一个比较虚的东西，好多人都想着要把进度细化到可控，但实际上，这东西的的可控性是少之又少，就算把任务细化了，中间会出现何种问题又无从得知，所以难呐。我还有一个问题，就是容易把事情想的比较简单，而且，容易高估别人的能力。。。。。。还有就是每天不能安排8小时的任务，要有余裕和休息，还有杂事……

5.角色

一个组里，肯定会有需求+设计+开发+测试+管理这么几个角色，之前的PM说过，一个组5个人比较合适，能专心干一个事当然是很好，但也得有个什么都能干的人，随时补充。。这样一个项目才能比较稳定，才能比较高效。不会在工作中被打搅

有关任务分配，我从09年就想写一个工具，但不幸的是，一直都没有实现，只是处于设计阶段，我想，可以利用这段时间把这个任务完成吧，一个一个的小模块，会组成一个好用的工具地