在工作中的一些想法，希望有管理经验的兄弟能够指点一二

水平有限，写的不好，各位见笑了，还请多多指正。

本人供职于某研究所的下属公司，部门成立2年只有十几个人，还在缓慢的壮大中，但是国有体制大家都懂的，关系户多干活的少。在下虽然顶着项目经理的名头，但实际上什么也管不了，做的好的不能奖励，做的烂的也不能处罚，时间一长必然人浮于事。毕竟端着公司饭碗，给领导发了份邮件，也算尽尽自己的职责，内容如下：

关于目前部门生产中存在的一些问题，从软件开发过程中的需求、设计、开发、测试四个方面，提一些建议。

1需求：目前XX软件的需求比较模糊，且大多都是领导口述，没有形成文字，很难复查，如果开发过程中间隔了一段时间或者发生人员变更，需求就很难说清楚了。

解决方案：当提出需求时尽量召集项目组的所有人，让所有成员都参与进来，这一点就部门现状来说十分必要，需求讨论完后可以让其中一人整理成文字，可以交由XX专职来完成，记录上日期及需要完成的主要内容，作为归档，成为开发的依据，并方便日后复查。

2设计：现阶段部门并没有设计这个环节，由于需求变动频繁，UML到代码很难做到同步，或者为了做到同步需要花费更多的时间，得不偿失，我觉得这个环节可以减化。

解决方案：一、需求要尽量的详细（上面说的尽量由专人整理需求，需求常变化也没关系，只要变化的部分也详细记录就可以了），详细的需求可以直接到代码开发阶段。二、尽量使项目模块化使彼此关联度降低，提高复用性，做到修改一个模块并不影响其他的模块。

3开发：部门现有的开发水平较低，开发人员的学习积极性也不高，现有的一人负责一个模块（从界面到数据库）的开发模式低效且不易于维护（因为每人的风格不同）。

解决方案：上面提到的全员参与，将开发人员每人分不同的方向但参与到所有的业务里，比如一个人只负责界面，一个人只负责数据库。这样每人只专做一块熟练度能很快提高，并且能促进成员之间的交流，产品质量和进度也能得到提高。

4测试：XX系统模块很多，业务也较为复杂，如果没有专人测试，仅靠程序员自测很难保证质量。

解决方案：如果不招聘专业的测试人员，也要在部门内找一个人专门负责手工测试，XX目前没什么工作安排可以让他们做（测试人员也要参与到需求的讨论中），并形成责任制，做到每天都要测试（时间或长或短），发现问题及时反馈，杜绝程序员不自测的现象。

以上是我对部门改革的初步想法，希望能把作坊式的队伍改变成正规军。园子里牛人众多，如果有什么简单实用的方法还望赐教。