刘远亮

刘远亮的博客

他的个人主页  他的博客

大软件策略里的软件队伍培养

刘远亮  2013年08月13日 星期二 21:40 | 1396次浏览 | 1条评论

软件师如何在大软件部门里培养团队

接着前文“互联网公司的大软件战略”谈谈大软件策略里的软件队伍培养。

 

最近看李宗仁回忆录,我觉得其实软件团队的培养和军队的建立训练有很多相似之处。这里给大家做个类比,大家看看,有没有道理。

 

我是崇尚和平的,一般很不喜欢军事上的东西,而且软件的团队开发和部队打仗恐怕还是有些不同,比如可以使用内部开源的做法,鼓励员工的主动性等等。

 

军队从招募到训练到能够作战需要一定的时间。新兵的协同作战能力是比较差的。但是一支军队建立起来后,就是个可以四处征战的部队,是有其持续性和稳定性的。

 

新兵招进来后,是需要训练的。但我们软件团队却很缺乏训练培养的意识。对于软件团队来说,这些培养包括对协作工具的使用, 规范,对公司开发工具和环境的熟悉,管理团队对设计的讨论和制定,开发人员的具体执行,问题的经常沟通,代码的早提交经常提交,进度的主动汇报等等。

 

新兵进来后,也是需要几次实战的磨练,才慢慢开始具备团队作战的能力。

 

软件是一个整体。大软件策略,如前文所述,需要有软件师始终对公司的软件整体有把握。软件的设计,需要多年的经验。效率的差别会是至少上百倍的(或者说根本无法用倍数衡量的,因为是注定失败和成功之间的差别)。而在设计定下来,具体规范也确定后,具体的代码编程速度,主要取决于工具的使用,键盘的操作速度等等。都相对熟练的程序员,这方面差别可能几倍的样子。不会如设计方面差的这么许多。

 

好的军队,指挥部应该能够制定好的作战计划,具体的作战和执行,就交由具体的作战人员来完成。软件里,设计的方案定了,具体的代码,交由具体的开发人员去完成。好的软件师是很难找的,找到一个两个也就足够做整体设计了。具体开发的程序员很容易找,即使是找那些聪明的有潜质的,可以比较容易的招一批人。这样,软件的开发,所花费的时间主要是设计所需要的时间,包括试错的时间,而开发的时间可以通过增加程序员大大缩短,甚至几乎到忽略不计的情况。也就是说,经典的增加程序员反而使得软件开发速度降低的问题,其实是需要辩证的去看的,关键在团队人员的配置。整个团队的建设,不同层次能力的人,不同方面技术的人,整个梯队的建设,尽量以节省成本的方式,打造一个富有战斗力的团队。

 

当然,这听着象科学管理里面所说的只有很小一部分人做大脑。大多数人做手和脚,有点大生产里为了生产效率"dumbing us down"的感觉。其实科学管理是有些道理的。另外,我们的做法又不一样。管理层作为设计者也会经常参与代码编程中,尤其是在项目的早期,需要设计架构和具体规范时,管理人员(或软件师)是身体力行的打头阵的。另外管理人员也会不时的给普通程序员一些比较大的任务,让他们逐步的得到锻炼和培养。在普通程序员多任务处理能力还不强,需要集中精力在当前任务的完成和技术学习中时,软件师也会担负起一些日常事务的处理。软件师是身先士卒的。软件师也不是把所有的枯燥的重复性的劳动扔给普通程序员去完成。软件师也是注意保护普通程序员的任务完整性的,尽量通过比较小,符合程序员当前能力的各个方面的任务让程序员的能力得到多方面的锻炼。所以软件师的角色其实是导师(mentor)的角色,以自己的经验知道程序员前方的路,在实战中培养程序员的成长。

 

软件师对软件团队的建立需要有整体的观点。需要有计划有策略的去搭建打造一个强大的团队。这里包括,对虽然经验浅,但人聪明肯学,有很大潜力的新兵的招募。需要知道那些渠道可以接触到这些人。

 

在团队的建设中,我更加看重基本概念清楚,思维灵活, 能探索,善于表达的人。对于这样的成员,可以分配一些小到中的任务,其探索研究后能够表达分享自己探索的结果。

 

李宗仁讲作战指挥军队,喜欢用如臂使手(指)这词,并视其为治军的最高境界。一个软件团队,在协作上最理想的境界也应该是如臂使指一样。这是队伍建设最终的目标。

 

另外,和球队的管理一样,足球上切忌让年轻球员去过早承受大赛的压力。不要一下子给队员超出能力太多的任务,揠苗助长,不利于年轻人的成长,打击其自信。

 

大家在学校里学的程序员。在公司里,希望逐步帮助大家完成从程序员到软件师的转变,学会从软件整体的观点去观察把握。比如周五下午不要再做技术上的工作,必须浏览公司的网页,使用公司的产品。不想做元帅的兵不是好兵,在这里我的理解就是,软件开发人员必须用产品的角度去看自己做的事情,必须尝试整体的观点,是去主动了解产品而不是被动的等开发任务。虽然有些人也许就只是喜欢做纯技术,当小兵,但我们还是可以在公司文化层面做这样的倾向性的要求。

 

在内部项目管理上,实行内部开源的机制。内部开源是项目的内部开放,所有人都可以参与。这样首先是以开源的标准去要求项目的管理和代码的质量。其次是每个项目都有拥有者,有决定是否接受其他人提交代码的权利,这样明晰公司内部项目的权责,并建立个体的成就感和工作的相对独立性和完整性,培养软件师中工匠性的一面,培养独立的审美判断能力。并鼓励所有人在完成自己任务之余,可以去参与公司内部所有的开源项目。这些项目一开始会局限在软件领域,但未来有可能扩展打其他领域。

 

关于内部开源,我们另文专门叙述。这里点到为止。

 

讲得不是很条理,有些拉拉杂杂的。先写出来大家做个交流。待有时间再做更好的归纳整理。

评论

我的评论:

发表评论

请 登录 后发表评论。还没有在Zeuux哲思注册吗?现在 注册 !
徐继哲

回复 徐继哲  2013年08月21日 星期三 00:43

软件队伍的培养和组织结构有很大关系。

0条回复

暂时没有评论

Zeuux © 2024

京ICP备05028076号