软件开发团队的“基础设施”建设

Phemia ·
更新时间:2024-11-14
· 603 次阅读

一.软件团队

自软件危机爆发以来,人们开始用软件工程来试图解决这个问题,提出了各种各样的开发理论, 开发模式。软件开发的艺术性,和不可预知性,使得各种开发理论,开发模式,总是有其局限性,终始无法精确的用工程的手段来量化开发过程。

软件是科学与艺术的结合,理论与实践的结合。作为一种智慧产品,软件开发基本上是一种智能的投入,是软件开发团队的智慧结晶。在软件中凝结的智能愈高,软件的价值愈高,能被市场接受的价格愈高。完全按工程组织来完成软件开发,基本是不可能完成的任务。

在看似平静的表面下面,软件开发其实是充满着各种风险,不可预知,和躁动不安的。按开发计划完成软件是世界上困难的事情之一。虽然你有着那么多的开发经验,技术资源,开发模式,但是你不能完全的依赖它们,每一个软件都有它的独特性,都需要你特别的付出和关注。你不要指望事情能按你预想的那样一帆风顺的进行。你需要关注,特别的关注,直到它的诞生。因此有人说:与其说软件的开发是可依进度或功能切割的项目,不如说是一种第六感。有时候它的确是这样。

也正因为软件诞生的艰辛,所以它的诞生也具有震撼性。一个伟大的软件产品,总是震撼着市场,震撼着心灵,将是人们全部的焦点所在,顾客将带着钞票抢着购买。公司也将因此成为行业中的个中翘楚。这是软件的魅力。一个高效率的开发团队会将这一切变为可能。

微软的成功,促使人们更多的开始关注小的开发团队的使用。

软件开发团队是为一个软件产品,或者一个项目的开发而组合在一起的组织. 软件开发团队首先是为目标的存在而存在的.

对一个软件开发团队首先要解决的问题是: 应该由那些角色来组成团队.在传统上组建一个开发团队时,习惯上是找一个主管,几个主力程序员,加从其他部门调来,或者现招几个程序员,算做是一个开发团队,期望他们能按时按质的拿出东西,运气好的话,他们可以搞定,大多数时候,项目不是严重超期,是永无出头之日,后只有下马的命运.

一个先天不足的团队,很难期望他们能按时按质的拿出产品。

参照微软项目团队组成,一个软件开发团队应该由如下角色组成:项目经理,系统设计师,程序员,测试人员,用户教育培训人员。项目经理对整个项目的成败负责,需要关注项目的进度,与客户的沟通交流,理解客户需求,项目经理更多的是作为用户和开发人员之间沟通的桥梁.因此对项目经理,不仅要求在技术上能够解决项目中发生的各种问题,也能预见到项目的各种潜在风险,并规避风险,更重要的是做为产品的代言人,能阐述清楚产品的用途,特色给潜在客户,也能明白,清晰的理解客户的需求描述,并和客户在需求问题上达成一致或折中.系统设计师和主力程序员一起对整个产品的架构,设计负责,确认开发语言,制定开发规范,预先架构中的潜在问题,解决开发中遇到的技术问题和测试问题.程序员分为主力程序员和一般程序员,主力程序员将承担更多的责任,协助系统设计师的设计工作,并具体指导一般程序员的开发工作,主力程序员一般由有多年项目经验的程序员担任.测试人员负责产品的测试工作,从方案设计开始参与并撰写测试计划,测试人员也应包括几种:能写测试代码的,完全不懂计算机,只做用户测试的.其测试的侧重点不同。

用户教育培训人员撰写用户使用文挡,产品说明书等,用户教育培训人员是一个项目很容易被忽视的角色,但事实上,在一个大项目中,他们的身影重要,这部分工作,没有专人来做,必然的分摊到程序员身上.程序员很难有时间,有心情来完成这些东西,不但会影响程序员的专注,也使文挡的质量很差.特别是在项目的后期,程序员的专注是非常重要的.我们看微软的项目管理,角色可以重叠,合并,但程序员与其他角色是不会重叠,合并的。

将团队划分为几种角色,目的是要他们各司其职,相互倚重,共享前景.一个团队如果没有明确的职责分工,没有规划,没有分工合作,只会让事情乱做一团,遇到问题,人人推委,终导致团队信誉整体下降。项目经理虽然对项目的成败负责,但是项目经理不可能面面俱到. 因此保持出了问题有人负责处理的原则,是非常重要的.懂得分工与授权,项目经理才能"解放"自己,团队成员也才会遇事不躲,主动承担并处理问题。

二.人员建设

团队划分出各种角色后,应明确各个角色的素质要求和技能要求,一个不适合的人处于一个不合适的职位上,是一个双输的选择。团队建设上应避免把团队建设成为一个大箩筐,什么东西都可以装。开发团队要进人,应该严格的按照岗位要求,招合适的人。在严把进人关的基础上,团队还应该逐步的,有计划的把不合适的人员替换掉.这个岗位不适合他,应该还有更适合他的岗位,而勉强呆在原位,不仅对团队,也对他不公平.当然在中国这个人情化社会里,要做到这一点很不容易.特别是工作多年的同事,同时可能也是朋友,要做做这一点更难。管理者也要克服掉人情关。过不了人情关,很难成为一个合格的管理者。

大家听说过木桶理论:一个木桶所能装的水不是由长的那根木条决定的,而是由短的那根木条决定的。对这个理论应用到软件开发领域是:一个软件开发团队开发出的产品品质差是由能力差的人决定的,所能开发出来的好的产品品质是由能力强的人决定的。通俗的理解是,一个开发团队开发出来的产品品质是由差和好的人来决定的,也是团队成员决定的。一个产品的现状往往能很准确的反映出一个团队的现状。产品的品质也是团队的品质。这是为什么有的产品叫好又叫座,而有的产品缺无人问津,甚至中途夭折,产品品质终是由人来决定的。而当某个团队请到一个牛人指导时候,其产品品质往往有大幅度的提升。而某个产品很糟糕的时候,回头看看他的开发团队,通常是整体表现为能力欠缺。

因此软件开发团队想要开发出好的软件产品,首先要做的是挑战团队成员自身的局限。团队成员的自大,高傲,拒绝合作,敌视,盲目自信都不利于团队的成长,更不利于自身的成长。而一个开放的心态,虚心的态度,崇尚交流的风气将更利于团队成员相互接受,互助合作,更容易完成任务。当团队形成注重成长的风气后,产品品质将会得到不断的提升,团队成员在自身成长的同时,也会带动其他成员的成长,这是有示范效应的。当短的木条和长的木条都在开始长长的时候,木桶能装的水是在增加,而对于开发团队来说,是能开发出品质更高的产品,他所能解决的问题域更广,经验更丰富,更懂得如何去开发出一个好的产品。

团队是不停的发展变化的,成员的新增,辞职是不可避免的。对于新进员工,应有一个"入模子" 的过程。联想柳总总结出来的"入模子"过程,很形象的说明我们是要把新进员工的身上打上自己的标记,让大家有共同的语言,共同的行事规则,共同的理念,共同远景。团队文化,氛围如果不能影响新进员工进入共同频道,这个团队建设是失败的,不能延续的,迟早会出问题。要形成自己的氛围,理念不是一早一夕能作到的,团队建设者应更多的关注到这个问题上来。这是形成团队战斗力的关键。也是凝聚团队的关键。对不能溶入共同频道的人,应坚决的予以清除。

三.职业生涯规划

堡垒往往是从内部被攻破的,软件开发团队也会在发展过程遇到因为内部问题而邦分崩离兮。重要的内部问题,我认为是团队成员的职业生涯规划问题。一个团队,其管理者职位总是少数,而目前各个公司没有明确的职业生涯规划,只有走上管理之路,才能有大的发展,也造成了千军万马过管理这条独木桥。人的趋利性使人们只向升职一条独木桥上钻。聪明的人开始团结领导,能干的人寻找其它机会, 程序员开始投简历,终团队走向没落。因此员工的职业生涯规划不能走千军万马过管理这条独木桥之路,而是要条条大路通罗马。在国外的一些软件开发企业里,程序员一样可以拿到相当于副总裁,高级管理人员才能拿到的薪水, 这样程序员才能安心的解决计算机问题,而不是去解决人际问题。软件开发团队不同其他团队,软件开发中有越多的老战士在第一线作战,产品成功的概率越大。而我们往往做的是把一个技术好手提升为管理者,再招上十个八个人,来开发一个漏洞百出的产品,导致技术得不到延续,管理也是一塌糊涂的结果。

团队成员都能专注于做自己的事情,则这个团队的开发效率将越来越高,产品品质越来越好。我认为微软软件开发的成功,也在于此,一个有着数十年软件开发经验的团队和一个刚刚建立的团队开发出来的产品当然是不可同日而语。《软件开发的科学与艺术》一书中提到,微软NT4前的产品经常会导致无故重启,死机,但是现在微软的产品越来越少看到这种现象,主要原因是微软大量的程序员开发经验越来越丰富,测试经验越来越丰富的结果。可见团队的延续性是多么重要;团队成员的专注是多么重要。而这种专注取决于管理者如何来解决团队成员的"前途"问题。

团队成员的发展途径,我认为可以有如下几个:行业专家,技术专家,设计师,架构师,系统分析师,高级程序员,项目经理, 产品经理。团队每个人都将有足够的选择机会。完全可以根据自己的特色选择。喜欢管理的可以向项目经理,产品经理看齐,喜欢技术的可以专注于技术,走技术专家,设计师,分析师之路。终形成百花齐放的格局。在技术上也可保持连续性,并可不断的加深技术底蕴。终技术,管理都将得到大的发展。



软件开 开发团队 软件

需要 登录 后方可回复, 如果你还没有账号请 注册新账号