手头上的一个项目顺利到达一个里程碑了，昨天和一个兄弟加班到12点半，总算把工作都完成了。

回想两个月来的过程，心里不禁生出许多感慨来。想起孔圣人说的“吾日三省吾身”的话来，想想自己确实应该反省一下了。

1.在项目准备阶段，因为自己对项目在技术上很有把握，但是没有什么项目经理经验，因此一些东西没有准备，比如项目组成员的一些技术上的培训，公司和客户两方面也没有去主动的去沟通。一句话，不主动。

2.在项目启动阶段，没有明确的项目启动仪式，兄弟们几个都不知道什么时候开始，也没有开始要干一个项目的精神状态，因此影响了后续阶段进行时，伙计们对项目的热情没有达到我的要求。没有和大家特别明确责权利，没有确定明确的项目组规章制度，没有明确的赏罚措施。导致后来有一两个伙计拖延工作时，没有办法对其进行有效的促进。在项目人员的配置上，也没有想得特别好。当然这点和公司有关。这是一个B/S项目，但是除了我以外，其他5个人只有一个做过B/S项目，其他的没有这方面的开发经验。在要人时，公司给搭配的人员就不是很合理，但是我也没有花太大的精力去交涉。

3.在需求分析阶段，在时间和人员上没有安排到位。在进行需求分析阶段，客户没有提出明确的项目完成时间，因此自己也没有在思想上进行重视，导致需求分析阶段的时间花了很长，但是效果很差，没有形成需求分析文档。这个是因为在项目前期没有定规章制度，干什么活没有形成要书面结果的习惯，很多时候讨论过了就讨论过了，这是一个很坏的做事习惯，现在回想起来主要原因是把自己的做事风格带到项目组中来了。以前自己做事的时候，都是和项目经理或是其他干系人直接讨论后，直接进行开发，然后拿出一个比较原始的模型进行在讨论，这样做的一个前提就是我自己有很强的责任心，想把事情做好，积极性特别强。而在该项目中，因为自己还是没有起到项目经理这个角色的作用，因此伙计们的积极性不是很强。在角色上，没有给自己一个明确的定位。其实到现在也不知道自己的定位是什么。描述一下实际情况，各位看官给个评价：该项目我从技术到业务都非常熟悉，但是伙计几个无论是从技术上还是从业务上都不熟悉。我是项目经理，项目在开始时，我和我们的部门副经理以及其他几个资深的高程（都不是项目组的成员）写出了一个方案。客户在本项目中的性能要求比较高。因此我花在对方案的性能测试上的时间很长，因为公司没有能够做性能测试的人，因此，我只好一边摸索一边测试，最后结果出来比较满意，但是时间上花得太多了。而且，在我进行性能测试时，也没有叫项目组的成员参与，也没有向公司申请额外的技术支持，至少应该叫苦什么的。而且也不知道这个事情是不是应该项目经理来做。在做性能测试的同时，也有安排伙计们熟悉业务，但是由于没有很严格的审查制度，伙计们也没有怎么了解，时间又浪费了。最后只能匆匆地进行需求分析，这又犯了兵家大忌。

4．在设计阶段：到这个时候时间已经是很紧迫了。但是伙计们没有意识到这一点，我也不知道怎么向大家传达该信息。因此，最终的结果就是设计得比较草率，项目匆匆开始编码。好在项目不是很大，而且我又非常熟悉，因此，在我的加班加点下，项目如期完成编码工作。

5.项目组中，有一个伙计干活相当不积极。假设一个一天能够干完的活，我需要花一天和他说清楚他具体要干什么，怎么干（这个主要原因就是在详细设计阶段的匆忙引起的，但是感觉这个伙计就是有点故意的，如果是其他伙计，则只要花半个小时就能交流完，而和他交流，他经常会顾左右而言其他）。然后他会给自己安排两天的时间做完（如果你说只要一天，他就会说做不完，其实可以上报部门经理，让上级来协调这些事情，但是，我没有用过这个方法，不知道在这个时间已经是非常紧的时候这么做好不好。我也可以发飚，但是结果肯定是更大的反抗）。然后我需要花两天的时间来修改他的程序，因为他写的程序基本不能用，不符合要求。在这里，我确实不知道该怎么处理这件事情。因为我不想在这个时候换人，而且公司也没有给我什么惩罚的权力，在项目开始时也没有定下来什么制度。可能在交给他活干的时候，就是要提出非常明确、明细的要求吧。要怎么编码，字符串要怎么拼写，SQL要怎么写，要怎么发布，最终要达到什么业务上的要求，这些都通通要说，要不然他的程序里面什么问题都会出现，从这边copy一段代码来，加上从那边copy一段代码来，然后很随意的拼凑，编译，然后提交给我。逼我安排另外一个人和他耗着，或者是我自己和他耗着，有时候觉得安排活给他做简直就是浪费了两个人。找他谈心没有用，可能是要使一些狠招或是阴招治一治他吧，但是我又不会。而且这是一个年龄比我大很多很多的人，很多面子拉不下来。但是有人又给脸不要脸，还以为我好欺负吧………郁闷

说了那么多，其实就是一句话，我还不会当项目经理，很多事情还不知道该怎么干。当然，写下来的主要目的就是总结一下，吸取一些经验，作为自己的一个成长的果实吧。

写得比较乱，各位尽量谅解，提出宝贵的意见。共同成长。

我想一个里程碑的总结，首先应该是这个阶段的目标要表达出来，其次才写一些实际状况。至少会有一些成绩吧，该写出来。

从文字中感觉到，项目管理应用得比较少，仿佛是一个普通的工程师经历了一个项目后的感受。建议多读一些项目管理基础理论的书。

但这样的阶段性总结我不看。
作为初涉管理的项目经理，我希望你能重新写一遍总结，而不是仅仅按照过程罗列问题。

小荷的建议不错，先描述项目的进展情况，哪些完成了、哪些未完成、哪些延期了、哪些提前了，进而检视项目的开发计划，然后分析问题。
分析问题应该有要点、有结构，IT项目不是提倡技术上的结构化吗？把这种有利于理顺思路的方法应用到管理上来呀。
这样分析：出现了什么问题？原因是什么？如何改进？是否需要进一步的支持？等等。

做好项目的计划和总结，是项目经理的基本技能，等待着满意的答卷。

有问题，找IT项目管理http://IT.mypm.net
上海的PM牵起手：http://SH.mypm.net

Dill的话一针见血阿。我这几天在多看看ITPM有关方面的书籍，然后再写一篇总结出来大家看看。

刚刚参加过一个PM的培训，看来没有学好呢。
不过我感觉有一点，是不是我不会与人相处造成的呢?
最近发现了这个问题。

不过还是会积极吸取教训的