请教诸位：如何接手一个混乱的项目组。
　

---

小弟最近因为工作调动需要去接手一个项目组，我去了解了一下情况，基本如下：
1、项目组大约二十人左右，四五个有经验的人员（四五年的开发经验），其他是去年毕业的本科生。
2、开发采用VC++，已经开发了有将近一年的时间，产品基本完成，但是没有经过任何系统的测试。
3、开发过程中没有任何文档资料，最基础的源程序是从别处偷来的。所有的资料都在开发人员的头脑中。
4、至今没有什么制度、流程。所有人员对UML、RUP之类不了解。
5、领导层已经认识到管理中的问题，但是迫于市场的压力不能延缓产品完成的时间。

问题是我该如何切入这个团队？如何引导这个团队走向规范化？完成产品我不敢想象，如何使损失最小？

条件：我对C/C++语言开发、系统设计、UML/ROSE、RUP、CMM都有一些了解，不行还可以看看书，向大家讨教。

我觉得首先要找出系统目前最稳定的功能，形成产品的第一个版本，推出市场。把一些复杂的功能去掉。然后去规范项目的管理。
呵呵。。。本人的一些愚见！

 回复: 请教诸位：如何接手一个混乱的项目组。
　

---

这是一个主意。首先组织一个测试队伍，从测试的角度去切入系统。难点是没有需求和设计文档，测试工作不好安排。你有没有什么好的办法？

 我的一点看法
　

---

1.从你自身来说，尽快去了解这个系统。
2.将20个人分5组左右，分别由那几个4，5年工作经验的人带领。
3.将系统划分成几个功能模块，由那几个组分别进行模块测试。
4.通过3之后，进行结合测试。
5.在测试过程中，注意保留测试报告，最好可以保留测试数据。

一点小建议，不知道帮不帮的上。:)
　

 同意，这是一个好的主意
　

---

首先确定系统中最急需的、比较稳定的功能，集中测试，确定一个版本，推向市场，然后再考虑规范管理。过程中注意从测试工作开始左手进行文档的规范管理。
原因：
首先将目前的项目close，让所有的参与人员看到成果，感受成功，从而予以正向激励。否则，看不到希望的工作将导致所有参与者消极情绪，最终导致项目失败，老板也不会高兴。
在测试过程中，开始进行规范的实施，并开始着手积累本应该有的文档资料。需要注意的是，此时的管理沟通要做好，不要引起他们的反感情绪，毕竟你是一个新来者。
完成之后，重新来过，整理所有的需求，根据完成的部分，整理软件所有部分工作情况，其中包括结构，实现难易程度，实现时间，换言之：整理工作定额情况，以积累工程知识。

呵呵，个人意见，仅供参考

我的项目组情况比他的还不如，我的项目组目前没有有经验的人员了，我来之前他们都已经走了，项目比你的还烂。管理人员意识到类似的问题，可是却在我来之前搞了一个行政改革，改的很不适应项目发展，我头疼的很。

比如项目组对你的到来持何态度，有没有接受规范化管理的意愿，有没有什么实在或潜在的人事斗争……

你不是说资料全在他们脑子里吗，那么好，在决定了要对哪块进行测试后，就分别让其开发负责人去整理测试文档，包括测试计划、测试用例、测试报告等，其中测试用例的整理就是对需求和设计的整理，只是目的略有不同而已。

现在来看阻力还不大。首先是高层已经认识到管理的落后，决心去改变这种状态，但是这种决心有多大、承受能力有多强还需要时间的考验。
中层的技术核心都曾经是我的伙伴，对我的到来还是比较期待的，但是如果对他们的个人利益有较大的冲击的话能否得到持续的支持还不好说。

 回复: 你首先应该搞清楚有哪些阻力
　

---

/***
比如项目组对你的到来持何态度，有没有接受规范化管理的意愿，有没有什么实在或潜在的人事斗争……
**/
能说的详细点吗？鄙人愚蠢，但很想聆听教会。请讲一下可能的情况，以及如何应对。听君一席话，胜读十年书。不胜感谢！

1、这个系统总体我还是了解的，细节需要时间慢慢去了解。
2、现在实际上就是这样分组的。
3、各组人员完成的各个模块的开发工作，自身进行同一模块的测试工作结果我表示怀疑，相互之间存在交流的问题。我感到最欠缺的是技术文档。
4、现在是组成了一个大的系统在跑，但是没有经过系统的测试到了用户手里就很难说了。
5、最难办的就是测试数据的问题了，是否要求开发人员补出设计文档的时候提供测试数据呢？

谢谢。

你认为首先Close是最重要的？但是关闭有些难度，整个系统是揉在一起的。不过这是一个方向。

 回复: 规范性工作就从测试开始
　

---

要求各个模块的开发负责人都去写规范化的测试文档，包括测试计划、测试用例、测试报告等可能有问题。首先需要对他们进行培训，然后占用时间去写文档。阻力不小呀。不过在万般无奈下也只有这样了。
难道没有别的更好的办法了吗？

能否详细一些？

 分阶段开发，向管理要业绩
　

---

给你一个建议：
第一：把主要的程序员集中起来，统一思想，统一行为方式，形成第一个突击团队，并把这个小组的思想明文公布，让大家学习遵守，并专人培训新手；
第二：抓住系统中的核心模块，让这个最有战斗力的团体，用你们统一的思想和行为把核心模块做完，模块的大小以工作量不超过3个月为宜；
第三：把你们这个核心团队的人员分散成各个小组的组长，用你们做核心模块的经验，完成其他的模块，并同时培养新手。每个小组不应该超过5人，多的人可以去做别的，不仅没产出，而且难以管理；
第四：严明纪律，严肃处理个别现象，整顿工作态度和作风
第五：千万不要在较大的工程中全盘照搬、采用自己不熟悉的软件工程技术。软件工程技术是实践的技术，必须经过实践才行，单纯的理解会有偏差，执行的偏差就会更大，这样不仅不会提高效率，还会把你的积极性打消了。软件工程技术的效率，不是暂时的效率，是长久的、可持续发展的效率。一个项目仓促间主要还是用项目管理的手段来提高效率。
实践的时候抓住自己确实理解的环节，最好能有有经验的高手指导，这样会在很大程度上提高你的效率；记住：在没有实践经验前，千万不要纸上谈兵照搬软件工程技术的方法！书本上的东东基本都是对的，但是如何变成自己的需要大量的实践经验甚至是失败！如果要实践，有重点地、小规模地采用，这样会让你尝到不少甜头，增强你的信心！
至于软件工程的技术，反而在其次了。一个技术不是那么容易引进的，你只要抓住核心的东东就行了，面向过程的结构化分析和面向对象的分析都有一系列成功的案例，找个合适的就行了。在执行上面没必要亦步亦趋，抓住核心的东西严格执行，认真审查。
我是做数据库系统开发的，我的技术有侧重点，可能不一定适合你。

 回复: 请教诸位：如何接手一个混乱的项目组。
　

---

一点小建议：
1、首先自己要有信心，并让组内成员感受到你的信心。
2、激发组员的斗志，精诚合作，共渡难关。
3、虚心向老组员请教，不要着急将自己的意志灌输到组员中。
目前就是首先在项目组内形成良好的工作气氛，然后再按照诸位兄弟的建议实施，效果应该不错，我曾经接收过类似的事情，不过规模没那么大。

关于测试计划，可以参考XP的plan game的方式。

是的，一定要尽快将项目结束。如果项目组中的成员都失去了对未来的希望，那只能陷于更深的黑洞中，丧失继续工作的动力，这样的系统更加的不可靠。项目管理的最基本目标也就无从实现。

 是的，一定要尽快将项目结束。
　

---

是的，一定要尽快将项目结束。如果项目组中的成员都失去了对未来的希望，那只能陷于更深的黑洞中，丧失继续工作的动力，这样的系统更加的不可靠。项目管理的最基本目标也就无从实现。

这样的话，向上取得与职责相称权和利，项目组的用人权和用钱权是很重要的；
向下搞清楚造成当成局面的原因，看看有没有搞定的可能性。

管理管什么?还不是人嘛.

你的目标是培训员工还是完成项目？
如果想完成项目但没有足够时间的话，先确认系统必须要有的功能是否已经完成，测试按照系统基本功能的合法处理能得到正常结果，放弃错误处理和代码优化，不考虑是否硬盘满之类的特殊情况，修改测试时发现的错误时优先修改那些日常合法输入不能得到正确结果的问题，其余能缓则缓。争取达到楼下说的快速关闭项目这一版本，只保证日常输入能顺利进行。如果还有时间，在版本升级时处理文档规范化等问题。至于了解细节本来就是必须的，员工向心力之类的就纯粹是管理能力了。
如果目标是借这个项目培训员工就完全是另一回事了。

 Totally agree with you. USE Iteration.
　

---

First of All
1. make a feature freeze.
2. code freeze and so on..

should leave the unstable and fancy features to the next version.

It is our way.

Dont worry, it is not diffcult.

　

 拙见，供考
　

---

代码说明，
及指在原代码文件开始的说明，可以建立一个说明规范，主要记录文件的目标、设计特点、（简要）流程说明、修改记录、遗留问题等；
另外，对代码其它部分，也要加入足够的说明；
说明工作由:
代码走查（负责检验），
程序员交替检查代码，包括说明是否清晰，并提交意见，安排说明会议，整理说明文档；

版本控制，
建议使用cvs，（至少将vss用好），解决并发开发，版本分支，合并的问题；

测试，
总体归纳功能点，建立（会多次使用的）详细测试计划；
采用一个缺陷管理系统，如ClearQuest,将所有的bug整理起来，并跟踪管理；
不断测试........


你的项目组不小，建议增加多名专职测试人员，以及2名软件工程辅助人员；建议你们boss请几个这样的人，成本比开发人员低不少。


　

项目的目标当然是完成产品。说实话，我对成功完成产品信心也不大。但是可以在下一版进行改善。

权力我已经有了，造成如此局面的原因除了管理上的因素外还有部分技术原因。

 回复: 拙见，供考
　

---

你的意见对我帮助最大。

 回复: 请教诸位：如何接手一个混乱的项目组。
　

---

1 理清该项目的范围，确定Baseline
2 对现有的团队适当的重组，管理团队一定是软硬兼施的，尽量做到内部的公平性。
3 结合实际情况作一些培训是必需的。
4 重新制定测试计划。

个人拙见。祝你好运!

 回复: 代码走查应该执行到什么程度，是要看懂代码找出代码中潜在的错误呢，还是仅仅看看代码说明是否规范？
　

---

重点在实现的思路清晰否，明确潜在的问题，外加说明规范性；
其实只要你去看（进去）别人的代码，你的第一感觉就是‘人和人不一样’，

没有设计文档直接去阅读代码太困难，工作量太大。

 我不同意！！
　

---

我觉得作为领导人首先要头脑清晰，对和程序员交流，尤其是刚接手开发组的时候，尽量对了解他们的长处，按才使用，尤其项目初期的设计工作要作好。尽量在项目全部展开之前作好，减轻程序员的压力，尽量减轻他们的抵触情绪，我认为首先这是比较重要的。要让他们对项目有信心。
兄弟拙见，

 这些我赞同：）
　

---

可是应用平台设计的需求分析我觉得很重要，有的时候连项目经理都不清楚
我觉得这是很奇怪的现象

 回复: 必须有设计文档
　

---

有多少代码是你现在项目组的同事写的...
设计文档往往也靠不住，

God bless you！

you need 7-9 months to re-develop it.
but I think you have no more than 3 months now.

面對這樣的項目,關鍵是理清思路,看清問題的根源在那里:
1 從項目需求文檔著手,建目標系統的功能需求文檔.
2 根據需求審查當前系統的進度,有多少完成,有多少未完成,有多少存在問題待完成的.一個一個著手.
3 適當的時候要重組開發隊伍,走較規範的開發方式,在這個時候阻力可能會相當大的,一定要讓所有人明白,游勇散兵開發方式,最終只是死路一條.
4 重視文檔的建立,重要的文檔一定要補上.
如果你對系統有整體的認識後,就不會手忙腳亂的,無從下手的.
希望對你有幫助!
共勉

 回复: 思路要清晰,發現問題,解決問題.
　

---

谢谢，我现在基本上就是这个思路。首先清理，尽快关闭，充分测试，完成项目。

Yes, time is important factor.

项目进行到此，提高并激励士气是第一步。方法很多，其中很重要的一条是code freezing, function freezing。尽快拿出一个版本，让项目组成员看到阶段性成果。第二步可以慢慢地补一些必要的文档，补文档相对写程序而言是相对轻松的一个环节，可以选择在项目组调整的时候进行，比如在拿出第一个版本之后，给成员一段休息的时间时。

这个项目原来预计20个人6-8个月完成，只有一个大致需求，在开发时不断有新功能被要求完成，都是没有纪录，直接由项目经理或sub-leader分配给具体的程序员完成，程序里到处是为了某个功能（很可能看上去无关）的补丁，改动就是牵一发而动全身，没有看懂source改正程序是很危险的。现在进度一拖再拖，一年下来，看上去基本功能都完成了，但有若干个必须要有的功能无法做到，这几个功能的追加在源程序上对整个系统都有影响，而且有功能上的冲突。
目前你手上的几个sub-leader都垂头丧气，指望能早些结束/脱离这个项目，10几个新人程序员反正法不责众，要求做什么就做什么，反正就是做出来，好不好，对别的功能，别人的程序有没有影响就不管了。整个系统不是设计不好的问题，是根本就没有设计。任何功能，任何修改的原因，只有找到具体修改人才有可能被回忆起来，而且还有很多是忘了。
你现在有全权，只要能在3个月内完成项目，但时间紧迫，由于需要熟悉系统的过程，你事实上没有增加人手的可能。

如果是这样，你只有先自己熟悉需求，决定需求的优先级，放弃低级别的需求以满足高等级需求，争取能混出一个产品来。
如果不是我估计的，您就可以去完成文档，规范化团体规则了

 你估计得很准
　

---

时至今日还有几个功能没有实现，几个有经验的程序员已经捉了好几个月的Bug，但是系统还不是很稳定。
现在没有完成的功能是必须(！)完成的。我需要去完成这些功能。我争取到了5个月的时间，再多就不可能了。现有的程序量大约有十五万行左右（据开发人员估计）。

放弃任何理论, 任何软件工程或者过程. 在 5 个月内把必须实现的实现出来, 不管用什么手段不管是否会影响别的部分不管是不是补丁加补丁. 然后尽可能地消除 bug, 能消除多少是多少. 只有这样才能达到目标.

任何理论上的夸夸其谈都是没用的.

unless boss want to get a zero-bug product

 有五个月，应该可以完成
　

---

关键就是你老板想要达到多好的产品。
开发途中的安排和你以后会不会继续做这个产品的升级有关，决定是为以后的升级储备一点技术实力还是做出这个算数。
其实管人是最难的。但这就和这里的主题无关了。
我个人觉得你这样的情况，如果3个月，完成项目的可能性在50%左右，5个月，大概90%。乱猜的，您别太相信了