97件事系列一之项目管理（一）

最近“二哥”看我为了工作上的事情焦头烂额，知道我对项目管理这事没有经验，遇到问题不知道怎么办，于是给我发了本很好的资料“项目管理应该知道的97件事”，本来只是下载下来了，没打算看，后来真心是烦躁的一塌糊涂，没心思coding，于是就打开看了会，不得不说老外写的书就是比国内的书有意思多，讲的东西很实际，也举了很多有意思的例子。。接下来我记录下我读这本书学到的东西。

1、尽早让开发人员与用户交谈

这一点个人很赞同，只有开发人员真正理解了用户需要的是什么，才能开发出符合其心意的产品。在我们公司，用户交互有专门的设计师，用户是由产品去引导着，但是我觉得也要考虑用户平常的一些操作习惯，可以多做调查。这一块通常我们都抛给我们的产品了，所以开发人员某种意义上面对的用户就是我们的产品人员。

2、避免打地鼠式开发

相信打地鼠这个游戏很多人都玩过，你会很好奇下个地鼠出现在哪，并且急着去消灭它。如果是程序上的bug，我相信没有人会对下一个bug出现在哪很兴奋，毕竟bug不是闹着玩的。在我们公司，项目迭代周期非常短，一周通常发布两次，更多的时候打的时间仗，这个时候我们通常都是想尽快完成需求，从而忽略了程序上各种细节问题，甚至为以后的扩展带来了不便。所以不要只考虑最初写代码所花费的时间，还要加上提升、调整和改进这些代码所需的时间。写高质量的代码和测试都需要花时间。从短期来看，这似乎是一种损失，然而它带来的却是长期收获。问问自己，你是想要速度还是想尽情享受可持续发展的乐趣。

3、一词不慎坏大事

看到这一点时，我表示不是很明白其中的意思，反复看了它的例子，讲的是多语言网站的例子。。。 由于实际项目中，没有遇到过，就不多言了。。有兴趣的同学到时可以看看原版的书籍。

4. 让项目发起人自己写需求

项目发起人自己写需求，能够避免掉很多不必要的错误，项目的发起人往往是最能知道软件开发出来真正用途的人，而他们往往认为：既然是一个软件项目，而自己可能又不懂软件开发，所以，他们认为没必要来亲自定义自己的期望。甚至不参与到项目的过程，只注重结果。不得不说这点我们公司贯彻的非常好，除了boss自己，需求都是项目发起人自己写，甚至是开发人员直面和项目发起人沟通。

5. 要简单，不要复杂

这一点深有感触啊，如果说一个功能能够“一键操作”，或者“傻瓜式操作”，我想对于用户来说应该是非常爽的，毕竟没人喜欢复杂的操作，简单的操作能达到自己的目的是最好不过的了。。

6、偿还你的技术债

项目开发过程中，为了快速完成任务，所以往往无力用很恰当的方式去处理代码，但采取一些捷径，他们也许能够让编写好的程序“刚刚足以”冲过终点线。这时可能会有很多的潜在的bug，要有效的管理起这些潜在的缺陷，恰当的去处理好它们。如果这些潜在的缺陷不去有效的管理，就会像滚雪球越滚越大。看到这我在想这是不是在为“打地鼠式开发”善后？

7、为团队增添人才而非技能

看到这条时，我刚好在面临着招聘的问题，公司底层架构基本已经稳定，这时缺的是会写业务的人，我在想招人的时候，应该招聘那些技能很强的人还是招些新人带动起来，当我纠结于此时，这本书给了我很大的启发。当你招一个你所需要的技能他样样的都会的人的时候，试想公司对于他可有发展，从某些方面看，公司其实是没有对他进行投资的，人们往往抱着一颗学习和进步的心来面对这份工作，如果他得不到更好的进步，我想过不久他还是会立马走人。所以我要招的人很简单：能与人融洽相处、主动合作、及时的对自己的工作做出整理，喜欢学习，对新鲜事物感兴趣的人，至于技能，公司有其他技术人员可以教他。事实上在我们的敏捷团队环境中，学习技术简单而迅速。然而，教一个成年人如何主动合作几乎是不可能的。

。。。。此处省略号几点

15. 记录工作流程，然后严格执行

对于这条，我并非很赞同，很多时候，为了适应快速发展，我们不得不去拥抱变化，此时流程上会随时发生改变，想要严格按照一定的流程执行就有点难，我觉得应该更高效的去管理需求变更。

。。。继续省略

18. 商业价值始终是衡量成功的标准

这句话是不是和“不以业务为导向的市场都是耍流氓“很像？任何项目都是奔着其一定商业价值才最终会有其自己的市场，为了应对市场的错综复杂，变化多端的业务需求也会压的”猿们“很累啊

19. 不要总因项目放弃休假

PM可能是团队中不可或缺的人，因此总是觉得没有时间去休假，团队时时都需要着你。长时间下去，人就会疲倦。一次假期能够缓解能够使你从繁重的项目中得到喘息。所以适当的休假非常有必要。只是休假要选择正确的时间。另外找一个合适的人并训练他偶尔顶替你的也是很重要的，这样当你不在的时候他能作为你的代理人，让项目持续得以进行下去。

。。。。还有很多件事。。有待继续体会