(1)将人员重新调整、组合，剔除滥竽充数的垃圾，增加新鲜血液；（已经开始执行，效果还可以）
(2)将原有人员分成技术部（含设计、开发）、测试部（含技术支持）、配置管理（尚无合适人选）、风险控制（尚无合适人选）、后勤保障等部门，让他们明确责任、分工；
(3)加强项目管理机制，建立奖惩措施，提高员工士气；(4)建立考勤制度；
(5)建立周报制度，每周五下班前将本周工作内容发送到我的信箱中；
(6)建立周例会制度，每周一上午9点钟准时召开周例会；
(7)补充完善文档，。。。。。。、/*!!@到了我的难处@!!*/让他们写什么？是否有必要让他们从需求、概要、详细等处写起？时间如何保障？欢迎您的建议，我每天扫描您的答复，我十分焦急，项目结束时，作『项目总结报告』是十分必要的，但是对于半截工程，如何写前期的开发文档，我确实拿不定主意啦！

至于周例会和周报，我的个人建议是算了，你的直接下属也就是7-8人（其他应该已经授权管理分在具体的Leader手下了，你不用直接管理吧），那么私下里和他们沟通比较好。这时候频繁的私下沟通，会给你将来带来好处的。只是成本比较高而已，等大家都熟悉了这种汇报方式，再采用周报和周例会制度。而不是给大家一个模板说：OK，汇报了。然后在例会上说什么啊？大家都没有试验过，一开始要大家干这干那的，挺累。

文档呢，我不建议现在补充Spec和设计文档，因为单纯这样的补，冲击最后的保贵时间，而且大家也不理解，不如从用户手册和System design doc开始抓，这样一来对于系统部署等等是有用的，开发人员相对愿意去干。然后使用细化Release plan以及需求实现对应表的机会，逐步重建Spec；通过设计Review，来建立High level design和rough design.可能会更容易推进和操作一些。这些事情不一定非得在这个项目周期内完成（当然了，如果仅仅是一个项目，那么补充一下Spec list和HDL就可以了，为将来留下一些关键的东西，其他的就不要了）。
呵呵，如果是我，我会如此做，当然了，对你的现状理解不够，所以只能泛泛而谈。见笑了。

能不能在在发射火箭以前，先放几个小鞭炮？
zhf_karen 分析的很透彻：
“只有3项，而且最多只有3项”
抬100棺材去改革的人失败了，回去教书了，当博导去了。