请教一些团队管理和软件开发的问题

新年新开始，首先祝大家新年身体健康，事业有成。 

上一年年底，一直都在赶项目，有点封闭开发感觉了。听起来象是很积极的样子，其实是最不好了。过年在家，想到以下一些问题，很困惑，请各位不吝指教。

1. 沟通问题
我想沟通可分为正式沟通和非正式沟通两种。正式的可以控制，非正式的只能够鼓励。我在前公司，小组每星期一有一个例会，总结上周工作，安排本周工作。而周五则有一个类似培训的集会，用于解决组员问题，或培训一些"新"的知识。

我觉得我们公司现在沟通不足，会议也只是总经理要求才会开的。我提议应该实行例会，这样至少可以制造沟通的机会，让大家（包括PM和组员）了解开发情况。不过领导说：不必硬性规定，只有认为有必要，谁都可以召集会议；我的门也是开的，随时都可以来找我。

我想，这个思想无疑是很好，但似乎有点过于理想。现实情况是，底层没有人曾主动召集过会议。

不知你们公司的情况是怎样的？

2. 培训和交流
很多同事都提出培训的要求。公司领导许诺，可以提供机会和一定的费用。确是好事一桩。

我个人以为，培训大抵分为两类。一类是overview式的，一类是单点突破式的，多用于攻克技术难点。想依靠培训而成为个中高手不怎么可能。

因此，诉诸外，不如求诸内。正所谓“三人行，必有我师”。加强内部交流才是长久的、根本的解决办法。只有经过多个组员间长期的、频繁的、深层次的交流，才可以综合统效，持续发展。同时，这样也可以减低人员流动对项目所造成的影响。

培训和交流都有需要。而加强交流比加强培训显得更有必要。交流在一程度上可以取代培训，甚至可以获得更好的效果。

您说是吗？

3. 经历和经验
做过一件事，叫做经历。学到教训和心得，叫做经验。

公司经常有些项目出现意外，最直接的结果就是延期了。即使经历过几个项目了，对下一个项目的期限估算仍然显得信心不足。我想这与做项目时没有记录日志、做完项目时没有认真总结直接有关。

经历了项目，得到感性认识；总结经验，才能得到理性认识。总结提高，有总结才有提高。没有总结提练，没有铭记于心，下次又要从零做起了。

过年到车站坐车回家，走向便利店买食物时，才突然记起，这是第二次去这家便利店买东西了。大家都知道，同样的东西，便利店就是要比超市贵的。要是我能铭记上一次的教训，及早准备食物，那我就可以省下些钱了。

话又说回来，这道理谁都知道，关键是如何做。不知大家在这方面是怎么做的。我曾看过PSP的文章，做法很不错。照着做可能非常难，但简单的把当天活动记录下来应该是可行的。这样一段时间后，自己也好有东西可以总结。当然，要是只有一两个人实行的话，估计对整个项目没什么大帮助。

4. 中层培养
我们公司比较小，大部分项目都是由一个总经理负责的。我们有几个PM的，但按老总的话说：不放心放手。随着公司的发展，中层干部的培养就成了一个亟待解决的问题。

一位领导说：要向上升就先要懂得吃亏，脏活累活自己干，能力提升了，公司是会看见得的。即使在本公司没有得到回报，你将来要走，在别的公司也一定能得到回报的。

我认同领导的看法。不干活，不实践，不搞好同事间的关系，就算升了也会跌下来。但我又想，脏活累活自己干是一个必要条件，还不是充分条件。干活算是一种推力，会象水受到压力一样，四处溢出，要加以引导，才能汇聚。即是说，领导要是能给准中层在远处点上盏明灯（适当指引，由具体到抽象），放心放手（适当授权，由轻及重），不怕跌倒，则一定可以达到目标。

当然，这个问题已经超出我的能力，看法难免稚嫩，请过来人指点。

5. 人员培养
我作为新人进入公司，第一希望是学到东西，钱是次要。即使现在不能说是新人了，但这个想法依然没变。将心比心，别人也是这样的吧。学到知识相对于高薪来说，在一定程度上更具吸引力。

我曾看过一位新同事的JSP代码，由于受经验所限，代码里有不少比较低级的"错误"，杂七杂八，复杂得要命，自己把自己逼进了死胡同。写得多辛苦我是知道的。我甚至觉得是我们害了她。

我想人员培养一是平时加强交流，提高互助意识。一新点子一起分享，有难题一起解决。总比一个人钻进去搞得昏天暗地要好。二是代码走查。这应该是最直接的方式，不过我还没有试过。

各位是怎么做的？请谈谈。

6. 思想、过程、工具的选用和推广
软件开发有很多思想，有很多过程可以实现，有很多工具可以辅助。但怎么选，选了后怎么推行，都让我头痛。

就说测试，其实我们公司上上下下，都认为测试很重要，也想采用科学的、切实可行的测试方法，以提高测试的质量。但是，目前我们似乎走着这样的怪圈：希望变，但又不身体力行的去变，结果就没改变。

有位负责测试的同事觉得，目前这种基于文档的Bug-Trace方式不方便，想转用CVStrace。可惜大家反应冷淡。认为问题不是摆弄一两个工具可以解决的。结果不了了之。

的确，问题并不是工具可以解决的。但这并不是放弃某种工具的理由。我想世上没有任何东西，可以一用就解决问题。假使这个工具可以让我们在这方面踏出一小步，那么，在没有更好的办法以前，能让我们踏出一小步的办法就是最好的办法，应该给予足够的支持。

是不是因为挑毛病比提意见要容易呢？或者说，觉得更能显示自己比别人高呢？呵呵，想想自己有时也是这样的。

大家有没有这方面的经验？请多多指教。

我谈一点看法，希望大家多多指正。
1.沟通：这是一座山，尤其对国内的同行更是如此。沟通说起来简单，但做好很难，很多同行认为做比说重要，这个有点片面，其实两者同样重要。比如，大家都有这样的体会，有时自己辛辛苦苦研究了好久的技术，其实高手一句话就说明白了，可以节省我们很多时间。那么怎么和高手沟通也是一门学问。还有，不了解客户意图，闭门造车。结果南辕北辙，沟通不重要吗？
2.培训：很遗憾，国内企业和外企比真是天壤之别。培训是为明天买单。很多国内企业舍不得这比钱，只是希望员工为自己带来价值，而员工的未来是不管的。结果谁愿意为这样的老板打工呢？还有就是，培训虽然不能使你变成高手，但可以引导你走上正途，免得自己在山间小道摸索。当然，国内的培训机构水平差，骗钱大有人在，这也使大家对培训的效果没有信心。至于公司内培训，本来是个好主意，可是高手未必是好老师。而且很多公司的高手都用来干活了，培训教师不是最优秀的人。IBM的培训是最好的，而且都是最优秀的人做培训，制度完备，合理。
3.人才培养：这个问题很难，真的。不过有一点就是，要容忍属下犯错误，因为你也是这样成长起来的，这是投资。
4.思想，过程，工具的推广：这个其实不难，但又很难。当年商鞅在秦国变法有多难，这个就有多难！
5.管理：成功的企业是不可复制的，因为有太多的因素。但有一点，就是人，好的企业都有，都用优秀的人。而不好的企业用的未必是优秀的人，甚至不用优秀的人。成功是由一个框架和无数细节搭成的。每一个细节都很重要。不过最高领导最重要。现在不是有种讨论吗，领导还是管理？其实领导还是很关键的，因为制度是领导建立的，人是领导用的。但是要是有能产生，选拔好的领导的制度那就更好了！：）
总的说来，做管理者很难，不过古人有指导：修身，齐家，治国，平天下。
一点看法，见笑见笑，多多批评！

原本想单独发一篇帖子讨论一下如何定制出一套适合自己公司团队管理和软件开发流程的，现在接thatway话题,抛砖，大家有什么好的经验和方法，都可以引玉的，先说说自己所处公司的一些基本情况：

1。公司很小，小到开发部只有3个人（不要讥笑，事实就是如此）；国际合作部10人左右，总共不会超过15人的开发团队。
2。主要从事外包业务（对日），因此很难涉及到程序设计之前的（说白了就是详细设计拿到了，开始编码）需求分析和系统设计部分，大多数项目都是日方提高详细设计，我们负责编码，测试，交付。
3。开发团队的技术水平远没有达到如dlee或是ozzzzzzz所提到的优秀团队的水平，（我指掌握的开发语言不统一，比方需要用java来实现的，可会的人不多），这个时候，怎样做才是比较合理的。（我所处的地方大都是从别的公司临时借人，美其曰合理利用资源，还能降低成本）

有朋友给我的建议是“XP比较适合你们，都是短期，时间比较紧张的项目，所以设计部分少，注重重构。 
test-driven development也比较适合。基本原理都是一样的：不用的功能就不写。 ”
结合上述几点，希望大家能给出几点建议，批评，都欢迎，帮我理理思路为谢。

------------------------------------------------------------

另就thatway问题说说自己的观点：
1。沟通：很重要，每周五公司都会有例会，但纯是管理方面的，涉及到技术交流的，很少，关键是可以交流的对象少。
2。培训：很少，日语培训倒是有，技术培训很少。
3。人才培养：感觉自己还需要被好好的培养。
4。思想：不是看几本编程思想就能获得的，长期积累，总结，领悟出来的。

kingdl 说的培训和人才培养是最重要的内容。这个人才不是懂得越多（懂得多用不出来的不叫人才）的就是人才，而是符合公司需要的人才。
小公司最大的问题是不注重积累，这个积累包括多个方面。

技术的积累：
做了很多年还是只会用简单的 JSP。连 MVC 是什么都不懂。虽然 MVC 也并不是什么很神奇的东西。
员工对公司感情的积累：
招人时不严加选择，在项目进行到一半时发现人不行又裁人，极大地影响士气和团队胶合的产生。
不重视对自己人的培养。不重视自己人，只知道去招收新人。把自己的员工当作编程机器和群氓，员工没有任何忠诚度。
客户关系的积累：
做的项目很少有真正成功的，客户怨声载道，难得有回头客。

软件质量很大程度上取决于责任心，而不在于你采用了什么高深的技术。没有责任心的人做出来的产品能好的了吗？
要鼓励高手共享自己的知识，不鼓励相互藏私。职位、薪水要向共享知识多的人倾斜。

德不孤，必有邻。要做一个有文化的企业，失去了德，你将一无所有。

很认同你的观点。公司现在让我写开发规范，我感觉自己还没达到那种程度，但我希望共享自己的一点点知识，也许对别人而言没什么帮助，但对自己也会有提高的。

没有人所说的正是目前国内大多数软件公司的现状。
其实，很简单，就是管理不行。管理不行主要是因为主要的领导不行，不能识人用人，还有就是没有好的制度。
有好的制度才有好的人，没有好的制度，好人也会变坏。

Dennis，我不认为XP适合你们，因为事实上XP对开发人员的水平要求还是比较高的。
“有朋友给我的建议是“XP比较适合你们，都是短期，时间比较紧张的项目，所以设计部分少，注重重构。
test-driven development也比较适合。基本原理都是一样的：不用的功能就不写。 ” ”
时间紧的项目用XP未必合适，上边这句话我基本不认同。不过对需求划分优先级还是正确的。优先完成高优先级的功能，多版本发布，迭代增量进化的开发过程，通常是适合大多数项目的。
至于人员，其实只要有几个核心人员就够了，外围的人员并不是很重要。核心人员一定要团结，而且各有所长，都能独当一面。可惜这也不是一件很容易的事情。

同意你的观点，同时公司目前能独挡一面的人很少，包括自己在内，都是一点点在摸索，我想公司目前也不可能采用XP，项目一旦启动，往往也顾不上什么新技术，而且对日开发，日方对新技术一向就不感冒，它更愿意采用已经运用了10年，20年的成熟技术，所以，我觉得公司目前的状况，还是采用比较成熟的开发模式，正如你所说的，“优先完成高优先级的功能，多版本发布，迭代增量进化的开发过程。”

kingdl 对 XP 的看法是对的。XP 的目标本来就不是敏捷，以前我曾经多次说过 XP 的不足。采用什么开发过程与人的能力密切相关，不能脱离开人的能力谈开发过程的优劣。在采用某种开发过程前首先该问自己：
发明这种开发过程的专家所管理的是什么水平的开发人员。
我们是否有与他们水平相当的开发人员？
如果不能回答好这两个问题，就不要以为照搬某种开发过程能够达到与别人相同的效果。最后发现效果不好又要去骂人，其实最该骂的还是自己。ozzzzzz 兄以前说过，首先要找到适合你们自己的开发过程，然后再参考别人的做法（RUP、XP、FDD、ASD、Crystal、etc.）去改进。如果你们自己根本就没有方法，对于什么东西适合你们根本就不清楚，无论 XP、RUP 还是 CMM 都救不了你们的。
现在 XP 的热度犹如两三年前的 RUP，但是很多人并不知道 XP 是什么东西，误以为做一些自动测试、做一些重构就是 XP。
根据我的亲身实践和观察，XP 其实并不适合大部分的中国软件企业。实施 XP 的前提是开发人员都有了很强的开发能力，并且具有非常好的纪律性。想想看，开发高手又很遵守纪律，那不是完人了吗？我们都可以扪心自问我们是不是这样的人。

对于“短期，时间比较紧张的项目”，可能 ASD（自适应软件开发）、Crystal（水晶方法）都要比 XP 好。国内目前已经有这些方面的专著出版。

dlee，水晶有书出了吗？叫什么名字？