有时候需要学会放手，别让自己太劳累

工作当中，无论自已处于哪个位置，总喜欢去看看项目的代码，动手写一些代码。因为只有这样，自己心里才有底，才比较踏实。有底，是指了解了代码的实际处理逻辑，并且自己很清楚代码是否存在问题。踏实，是指在有了底之后，能够更好的与客户进行沟通；而且看代码写代码是最实在的东西，对于喜欢写代码的人来说心里是踏实的，实实在在的。

 

最近负责管理一个项目，大家都比较忙，但我自己更忙...

我的工作内容包括但不限于：项目管理、需求分析、设计、技术指导、代码走查、基础框架搭建与编写少量代码、测试...

看着有点眼花缭乱吧^_^

 

其中，大部分时间还是花在前几项，花在后几项的时间相对少一些，但无论如何也占用了一些时间。

其实有些工作并不是自己必须去做的，但我认为项目经理是最了解需求和业务的人，如果能够多参与一些项目内部的工作，相信项目的质量会更高，返工更少，客户会更满意，事实也是如此。

有些工作内容也是实在没办法，由于团队成员的技术能力与对业务知识的了解有限，完全放手让他们去做还是不太放心，当然这一点主要体现在项目前期，越往后就越好了。

 

介绍一下项目的一些情况：

1、项目开始的前几周，基本是每周最少3、4次需求讨论会，每次几个小时，几乎占用了所有的工作时间；

2、在对用户需求了解得差不多之后，形成文档，与客户开了需求评审会并对需求进行评审确认；

3、在项目需求确认之后，一直维持着每周写周报及开周例会的惯例，从未停过；

4、项目管理计划，每几天甚至每天不定时间进行滚动更新。有句话叫计划就是瞎猜，短期内的计划是比较可行的；

5、每1~2天跟进开发进度及遇到的问题，鼓励每位队员及时提出问题，无论是技术问题还是业务问题；

6、项目文档的文件夹目录结构，以及文档的编写与整理大部分都自己完成

7、同一类功能，原则上一个人实现，其他人参考，避免由于研究处理同一问题导致项目进度滞后。强调多分享，互相参考；

8、核心的业务流程或代码我会亲自过一遍代码，关键代码自己动手；

9、不定时单独向各队员了解进度，了解具体的实现流程是否正确，有没有遇到什么问题；

10、前期由于测试人员忙于测试其他项目，自己亲自进行测试，否则进度跟不上。后来，慢慢的测试人员加入了，测试工作基本就交给他们了；

...

 

由于项目进度很赶，以上采取的一些方法，包括自己多参与到项目内部工作还是挺有效果的...

 

写着写着，好像有点跑题了。好吧，回来总结一下吧：

学会放手，多给队员机会，相信他们能够把事情做好。如果不让他们自己去尝试，去犯错，他们永远都做不好。

每个人的精力都是有限的，像我这样长久下去是扛不住的，业余时间都被占用了大部分，而且有时候也会影响整体管理工作。

 

（转载请注明来源：http://zhanjia.iteye.com/blog/1987944）