“人是什么？我想一定是超越了纯粹的存在的某种东西。因为如果纯粹的存在是人的基本特征，那我们和牡蛎又有什么区别——Hsu”

涉及到人的问题，往往会比任何问题要复杂很多，以至于头疼。

相信绝大多数开发团队都会遇到同样的问题：总可能会面对在项目中期新加入的人员。他们可能对业务流程不是很了解，也有可能对软件结构和团队的规范需要熟悉，甚至可能编程技能还没有达到团队的要求。而几乎每个人都希望新人能够尽快的融入到团队之中，尽早的有所贡献。

但是，这是一种损耗，很大的损耗。等待新手步入正轨是一个充满变数的过程。新手的理解可能有所误差以致完成的代码还需要原有成员进行修改；新手可能充满问题，需要原有成员进行帮助，而这又消耗了已有的工作能力。甚至会仅仅因为新手的加入，使项目进行陷入暂时的混乱状态。这也就是那条著名的论断的原因之一：“向一个注定延误了的项目添加人手，只会使得项目更加延期”……

尽管，我们一般不希望团队成员发生变化，但是我们永远无法逃避开发团队的成员变化问题。事实上不断调整的团队会有其他的好处，一个不平衡态也会使得团队可以拥有更多的动力因素。不过，不管怎么说，处理成员的变化永远是一个棘手的问题。

OK，在每一个人刚刚进入一个团队的时候，他都是一个新人。献身说法是，在我刚刚进入团队的时候，是一个可怕的过程。我所拥有的是一份不完整的文档，注释很少的代码，和一个不太究竟的目标。尽管师兄也竭尽所能的帮助我进步，但是事实是，我经常听到的最多的话是：“你再看看代码吧”……我的经验是，让一个新手在没有instruction的情况下靠看代码来理解整个项目是一件恐怖的事情。事实证明，我这一批人在进入项目很久以后依旧没有摆脱新人的状态，我们所拥有的是“照猫画虎”的无奈，而大部分的代码都没有达到那个我们不太清楚的目的。而最有意思的，同样的代码，不同人的阅读完全可能得出截然不同的想法。

阵痛过后，我们迎来了一个短暂的春天，每个团队成员似乎好不容易找好了自己的位置。然后，我们面对的是又一次人员调动。我丢掉了三个成手，然后得到了三个新人（至少对这个产品来说是新人）。我的想法是，如果重复我们进入项目的过程，那会是另一场恶梦。所以我决定尝试另一种方法，我曾经以为会有一定效果的方法。将每一个新人和一个成手配成一个小组，共同完成任务。其实我原本的目的是让共同开发成为新手的学习过程。而这被证明只不过是另外一个错误。首先，新人的提问很大程度降低了我们小组的开发速度，学习过程和开发过程纠缠在了一起，正常的工作经常被解释问题所打断；其次，发展到后来，会发现不耐烦的成手开始宁愿自己承担更多的工作，而把一些容易实现的目标交给同组的新人；再后来，我惊讶的发现，成手和新人完全分割开来了，完全在做不同的部分，没有交流，没有问题，没有学习。然后我不得不承担，新手代码依旧偏离目标的结果。很抱歉，我失去了对这一过程的控制。

而现在，我们这届的人逐渐要离开当前的工作进行新的研究了。在走之前，我们必须做到的事情就是把这些工作完好的交接给新人。咳，没错又是新人。老师布置任务的时候强调，要整理好文档，描述完整。事实上，我想单独靠完整的文档是否能够简化学习过程的。那会有帮助，但是依旧不够。我的感觉是，一个引导性的交待是必要的。我该怎么做，这会是又一次的尝试。

我会提供尽量容易阅读的文档，但是我不会提供那种“标准”的成摞的文档。事实上，我个人觉得一个完全不懂的人，依靠阅读从成山的文档和代码中理清头绪是对时间的浪费。我们有交流的条件，几次面对面的交流应该可以更快的帮助他们理好一条路径，然后在安排好起点、终点以及中转站的旅途里前进，那目的性应该会强很多。当然，老人的帮助还是不能少的，经验是最难获得的东西，但是这种帮助应该更有序，Maybe会安排专人，或者安排专门时间，总之尽量不打算让大家的工作时间频频被打断，而很难进入状态。

尽管在软件开发过程中，我们谈论更多的是技术、框架、平台一类的东西，或者客户市场和商业前景。但是做为开发的主体，人才是最重要的因素。事实上，当我们谈论项目管理，我们大概想谈的不是技术问题，我们工作中的主要问题是社会学问题。至少，是人在制造软件。

团队成员和机械系统中的零配件完全不同，永远不可能简单替换。我还很菜，我不指望这次的尝试能应对好变更的团队，但我希望这次能比前两次得到更好的结果。不断的尝试其实是很有趣的事情。而关于软件开发中人的问题，会和技术问题一样，不断引发我的思考和学习。

BTW. A worm welcome to my new teammates.

Trackback: http://tb.donews.net/TrackBack.aspx?PostId=735272