软件项目管理

       以前看了一些软件工程的书，非常的肤浅，一直深入不下去。

       这两天带领两个才毕业的学生做项目，我把需求文档、设计文档、数据库文档都写好，然后把工作分成很多的小块让他们去做，当然这些小块的功能怎么做都告诉他们俩了，也就是我把详细的工作都安排好，他们两个去执行就行了。对于软件项目的开发管理来说，现在我感觉最重要的是控制开发进程，开发人员的工作都在他们上面人员的控制范围之内，设计人员把功能都设计好，每个功能的框架和一些重要的点都设计好，留下详细的工作才能让开发人员去做，这样才能提高开发人员的效率，充分发挥设计人员的才能，这样才能人尽其才，合作开发，以最快的效率把项目做完。

       后来和我的内参讨论商量管理怎么才能做好后，总结出如下关于管理的思想：领导要把工作方向和节奏设计好，工作由手下人去做就行了，但领导要监控工作的方向和节奏，监督和引导手下人去把工作按时完成。

       这里的工作方向在软件工程中就是设计，节奏就是时间或里程碑等内容。当然设计有大有小，有详有略，我们要根据团队的人员情况把粒度分配好。一般是界面要把界面元素字段有什么说明白，至于字段编码、长度、类型都让开发人员去设计就行了，他们设计完设计人员评审下就行了。软件的行为的设计要把类图设计出来，把类的框架图设计出来；类需要完成的主要功能要设计好，把功能合理都划分到不同的类中；类之间的接口要设计出来，类之间的联系要设计好；类中具体函数的实现就让开发人员去做就行了。设计人员要把类的设计自己把成代码，然后交由开发人员把函数的功能完成。项目经理要充分评估设计人员和开发人员的工作的时间，把他们的前后关系分配好，那就是项目的时间安排。项目的人员安排就是把手下的人员分为设计人员、开发人员。

       项目文档一定要有需求文档、设计文档、用户使用手册。需求文档要把功能说明说明白，各个功能之间的关系要写出来，把业务流程图化出来。设计文档分为功能设计文档、类的设计文档、数据库设计文档。功能设计文档要有单个功能用到的元素字段列表和模块要实现的单个具体功能列表，每个具体功能要有详细的功能实现说明。类的设计文档要有类的框架设计（类静态图）、类的功能设计说明和类中的主要函数列表。

充分发挥设计人员的才能？你手下的两个人是什么感觉？如果是你你会怎样想？一种机械式的劳动，完全没有快乐而言，搞软件是为了创造出一些可以帮助人们工作和生活的东西，从中体验创造带来的乐趣。
要记得，对于一个软件，人的重要性远大于过程。如果就这样抹杀掉了他们的创造机会，作为一个程序员来讲是很痛苦的。不要让你的程序员感到痛苦。要让他们体验快乐，也许他们在设计方面远不如你，但你可以教他们如何去做以及为什么，而不是发出一种命令告诉他们这样做就可以了。你们可以经常讨论问题，不要总是居高临下以为自己是项目经理或者是什么职位。
要促进知识在团队里的流通，这样才会带出高效的团队，而不是让他们去做机器做的事情。

项目中的很多事情要交给团队去做，第一设计人员的精力有限，不可能面面俱到，最初设计的再完美如果出现需求更变也一样要大改一番，最好的情况是设计人员发现从某一个点（里程碑）之后的设计需要修改，差一点就是程序已经完成也需要跟着改，最坏的情况是你发现你的时间跟本不允许这样的更变。要多与客户沟通，了解他们的关键需求。可以先发布一个演示版本，从他们那里得到使用反馈。
我们为的是把软件做好。。。。。。

我很认同你的做法！

言之有理, 言之有物, 对于不同的项目,不同的人员,不同的项目阶段,都要有不同的策略,
对于较初级的人员和项目开始阶段,采用LZ的办法是不错的选择.
但是对于中后期项目和中高级人员,发挥个体的能动性和创造力是有必要的.

LZ把两个问题放到一块儿说了。
一个是管理。
一个是软件过程。
对于中小型团队，这个的软件开发过程还是可以的，但人数一多，就麻烦了（因为沟通就是问题了）。
至于管理，这样做会造成手下的人不愉快，不能发挥主观能动性。

关键现在十家公司有九家都讲以人为本，可以能有两家真正做到就不错了！