项目管理学习到的教训

虽然我的职称是软件工程师，但对于小公司来说，我也同时是项目的负责人。作为软件项目的管理人，我学习到了非常多除了软件开发以外的知识和经验，如沟通技巧，项目时间线管理，资源分配等等。但是在这些经验中我也获得了许多血淋淋的教训，今天给大家稍微分享一下。

1. 不要过度信任对方的项目经理

作为一个软件咨询公司，我们常常需要和客户的 IT 团队的项目经理打交道。以我的经验来说，不是每个 IT 项目的项目经理都是具备 IT 知识的。所以呢，尽量不要去假设对方已经明白你所说的东西，记得再三确认你们在各方面已经达成一致的认知，才着手去做开发。不然的话，在事情发生后你就会收到这样的回应：”哦，这和我当时理解的不一样呢。。。“。

2. 单一信息源

尽量不要只用邮件来作为讨论事项的纪录。使用文档管理工具，如 Confluence，来追踪和记录产品需求与其他讨论事项。以周期，例如一星期为单位，发送最新的文档与进度给各个单位以确保大家都保持在同一个步调。如果每个团队都有各自版本的产品需求文档，那么当问题出现的时候就很难去争辩对错。

3. 会议记录

一定要写会议记录。有时会议开得比较快或者比较匆忙，可以先随手记下讨论的重点和做的决定，之后再把它们整理成文档，给所有参加会议的人都发一份，以确保讨论事项的正确性。

4. 尽量不要改动原有的需求，除非是双方正式同意推迟时间线

在敲定了产品需求并且开始开发之后，尽量不要改动原有的需求，尤其是我们有时候很容易在会议讨论的时候答应对方一些额外的需求，从而无意中拖慢了整体项目的进度。以下是我自己的故事以及教训：

我们在与甲方讨论了产品需求之后，发了文档版本，双方也同意了我们才开始开发。但我所不知道的是，甲方的项目经理并没有把软件真正的使用团队带进这个产品需求的讨论会议。直到开发完毕，进入用户测试的时候，甲方项目经理为了掩盖并补上之前产品需求收集时所缺失的东西，在与我的电话会议里三番两次的拜托我帮忙加进去。这里我犯了一个严重的错误，就是没有提醒该项目经理我们已经处在用户测试的阶段，如果再加入新的测试项目会严重低推迟上线时间。他好声好气地拜托我了，我也当作是做好事地帮忙完成，并且让用户再继续测试。就这样一拖两拖，就超出了用户测试的原定期限。

甲方的上层并不知情，而此时该甲方的项目经理也非常适时地补刀，对上层声称我们的开发有缺失，进而拖慢了用户的测试。当我收到该投诉邮件的时候别提我有多傻眼了。但是就没有跟进时间线这件事情我也是有错（而且毕竟是甲方），所以我只是默默地准备好所有的证据（之前讨论的所有事项和截图），以防到时对方还要继续追究。接下来我也集中精力把所有的开发与测试完成，比原定迟了两个星期上线。或许这只是他们内部使用的软件，所以他们也没有要继续刁难我们的意思，但这确实给我实实在在地上了一课。

至此以后，我对原有的产品需求范围界定非常谨慎。如若不是必定要在这一个版本上线的功能，就推到下一个版本一起开发，而如果必须是这个版本死也要上线的但不在原有的需求内，双方必须同意达成时间线上的共识才能做。