• 2004-06-27

    项目坚壳

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/240236.html

    项目伊始,来自五湖四海的兄弟姐妹为了一个共同的目标走到了一起。正常情况下,一个项目组很难从始至终由同一批人完成,对于项目组成员的进进出出,大家也就习以为常了。如果这是一个有生命力的项目,随着项目一天天的进行,一群所谓的“项目主力”逐渐露出水面,虽然项目组的其他人有如走马灯一样,来了又去,但这些项目主力基本上如果不是自己提出,领导不会选择让他们进入走马换将的行列。项目主力稳定的存在于一个项目之中,彼此之间的交流和协作给了他们一种难得的默契,一个眼神,一个动作,几个词语,无需完全的表达,大家便已心领神会。正是这种默契,使得项目组成员之间的交流省去了不少的麻烦,也正是这种默契,无形之中形成了一种坚硬的外壳。对于任何新加入项目的成员,如果不能打破这层坚硬的外壳,他便只能徘徊在项目之外,无法真正融入项目之中。

    我们项目从去年年初开始,人员不停进进出出,算起来,在项目里面挂过名的也有几十号人了。到现在,在项目早期进入项目而一直坚持下来的,总共有三个人:负责管理系统的开发的项目负责人和我,负责管理系统开发的一个兄弟。

    现在参与业务系统开发的第三个人是去年年中加入到项目组里来的,最初负责测试,直到年底,2.0系统的开发,他才正式加入了开发业务系统的行列。私下里的聊天,他对我说,自己最初进入业务系统开发时遇到了种种困难:项目文档不完整、对项目理解很浅薄、开发工作不明确……当时,我确实没有意识到这些问题的存在,因为对我来说,一切都很清楚,我和负责人讨论项目中遇到的问题很容易,因为彼此心知肚明。但这一切,对于刚刚加入到我们行列中的这个兄弟,没有那么简单,我们的话对他来说,可能像天书一般,因为没人告诉他应该知道的一切。

    不过,他总算是苦尽甘来,融入到项目组之中,而另外的一位就没那么幸运了。
    也是去年年底,鉴于管理系统只有一个人苦撑,而新需求又压了下来,一个同事进入到项目组中,加入到管理系统的开发队伍中。前前后后,他在我们项目组里干了半年。遗憾的是,他最终没能融入到项目组之中。
    由于对管理系统不是很熟悉,分配任务的时候,负责人常常会把管理系统相关的内容交给负责管理系统的那个同事那里,对于这位新同事的任务,顶多也只能布置一个大概,他期望的是负责管理系统的同事可以把工作更好的布置下去。不过,这种想法并没有得到充分的交流,而那位同事只是管理系统的开发人员,而没有真正的“官衔”顶在头上,所以,他没有义务去完成“负责”工作。这样造成的结果是,这个新同事往往是很长一段时间不知道自己该干什么,常常是工期临近的时候,才猛然发现自己居然有这么多东西要做。终于,在一次项目组会议中,他爆发了。
    现在,他离开了我们项目组,换到了其它的项目组。

    在这里讨论人们之间的对错是非没有任何意义,发现问题之后,我们需要的是解决问题。俗话说:“一个巴掌拍不响”,有了问题通常是双方做得都不甚理想。
    不知是幸还是不幸,迄今为止,我从未半路加入一个项目之中,我总是清楚项目组中一切的来龙去脉,于是,我暂时还没有机会与那层坚硬的外壳正面交锋。
    或许,以我的经历而言,讨论如何打破坚壳有些站着说话不腰疼,不过,既然我无法保证以后自己不能半路出家,能以人为鉴,又何乐不为呢?让问题消弭于无形之中,总比自己碰得头破血流要好。作为现在的壳内人员,如何帮助新成员打破坚壳,也是个有趣的问题。

    我的那个同事为什么不能很好的融入项目组之中呢?前面说过的交流问题固然是一个原因,对项目的不甚了解也是重要原因。对其他人来说,基于对项目的了解,即便负责人没有做好工作的分配,大多数情况下,我们也知道自己该干什么,知道那有问题需要自己去处理。而这个同事做不到,他根本不知道项目进行到什么程度,哪是他可以自由发挥的。我们项目的文档工作完成的并不理想,这位同事无法通过文档对项目有一个完整的人士。不过,话又说回来,即便有完整的文档,以我们这里文档的质量,读了之后有多大帮助谁又能知道呢?这其中牵扯到了“不但要有文档,而且文档要有效”,这不是这次的话题,让我们暂时忽略它。
    这个同事和我聊天的时候,也曾希望对项目有个完整的认识。他的想法很好,不过,他更多的时候是在期待别人把知识送过来,而不是主动的获取。基于我们的现实情况,项目的一切,大多数时候靠的彼此之间言传身教在大家之间传递。因此,交流是必不可少的。在一个新成员进到项目组中,我们会把项目的一个概况告诉他,对于一个希望对项目有个大概认识的人来说,这就已经够了,但作为开发者,这只是一个入口点,真正工作会要求我们尽可能了解一切的细节。作为项目组的“老”成员,那些细节是埋藏在大脑深处,没有人问起的时候,它们基本上不会主动走出来,缺省情况下,“老”成员会认为这些东西大家都知道。因此,如果想了解尽可能多的细节,只有靠新成员自己去发掘。
    我的这个同事本身就是一个非常内向的人,他很少主动和别人交流,我们脑子的这些东西始终无法传递给他,他的大脑中就无法形成一个完整的项目视图,而在他看来,是我们这些人不主动把信息告诉他,这样造成的结果就是,在我们无知无畏的时候,他却感到非常的不舒服。最后对于任务分配理解的差异只是让他这个前期积累爆发的一个导火索。

    写到这里,我突然觉得,虽然我们可以鼓励项目组完成更好的文档,项目组其他成员应该多多与新成员交流,但归根结底,要想融入一个项目组,更多的还是要靠新成员自己的努力。毕竟大多数情况下,我们无法改变环境,而只能去适应环境。

    分享到:

    历史上的今天:

    引用地址:

    评论

  • 由于网络原因,发了三遍,请删除多余的。




    还有一点想说的是,当新成员问问题的时候,老成员的态度也很重要,我以前遇到过一些人,一问问题就摆出一副这么简单的问题你居然不知道的表情,好象谁生下来就该什么都知道一样,好在我这个人脾气有点倔,越是遇上这种人,越要死缠烂打的要他来解惑,反正已经被人嘲笑了,就更要弄懂了才值得。而且我发现,有些人表面上表示不屑的问题,他们自己当初也不一定就是天生就明白的。记得有一次有个问题,我连着四次跑去问一个同事,因为每次他给我讲完了,我复述之后他点头,然后我自己回去琢磨,发现逻辑上很不通,然后又去问他,然后他又深入一点,每次都深入一些,最后一次,他周围的其他人都对我侧目了,呵呵,他发现三言两语每办法满足我,终于拿起笔,仔仔细细的给我从头到尾讲了一遍,然后我又复述了一遍,他点头,然后说,当初他自己为了弄明白这个问题都花了比我多很多的时间。当时我就觉得忿忿,因为期间好几次去问他的时候,他的态度很不好,表现出来的就是这么简单的问题,你都弄不清楚。


    如果回答问题的人态度差劲的话,我想别人就算有疑问,也不一定愿意再去问你啦。交流是双方面的,任何一方的不积极都有可能造成损失。
    回复mochow说:
    所有问题都是双方的,如果别人来问我,我会愿意把我知道的告诉他,但有时候,确实可能会有态度不是很好的时候。多谢mochow的教导,值得吸取教训。
    2004-06-28 21:20:52
  • 我对这种情况深有体会,半途中加入一个项目,负责人总是花十分钟讲一些他认为很重要的东西,而很多时候,这种很重要的东西对于理解整个项目的作用不是太大,然后扔一些文档和源码,好几次,很重要的文档都忘了给我,看完之后,甚至不知道这个项目到底在干些什么,好在我脸皮比较厚,一有想不通的就抓住人狂问,慢慢的会有人陆续给我增加一些比较重要的文档,给我解惑,每次我都要把我理解的东西复述一遍给他们听,直到他们点头为止。因为我发现很多时候就算听他们亲口说,也依然存在误解的可能。这个过程中,我往往会做一些笔记,添加一些注释,完善一些文档,把我作为一个初学者时感觉到的疑惑都记录上去,以期望后来者少费一番心思。


    同样,别人加入到我一直在做的项目中来的时候,大概是我自己曾经经历过那种境地,所以我会比较主动和详细的给他讲一些容易混淆的东西,然后会经常的去问他对项目的理解和进展。


    理解和融入一个项目光靠看文档肯定是不行的。而看源码的话,时间上一般不会允许的,剩下的只有交流了,交流越多,就能越早的进入状态。