技术团队和项目管理

如果你是一个研发部门的领导,我想你需要花很多时间考虑团队建设、管理,以及项目管理的事情。作为一个技术人,即便你现在还没有处在这样的位置上,你也可以先做个假设,假设哪天老板把你放到这个位置上了,你该怎么做。机会只留给有准备的人,虽是老生常谈,然而千真万确。 在这里,我根据自己的实践经验和思考,做一些分享。 首先,应该想清楚管理是什么,为什么要管理。这听起来好像是废话,然而很多人并没有真正想明白。管理就是消除混乱,让混乱的事情变得有序,从而提高团队协作的效率,最后达到的结果是帮助公司降本增效。管理中最重要的是理,要把很多事情理清楚,否则无从管起,而在一些土老板眼中,管理可能就是盯人加班。 在我有限的经验看来,管理涉及的内容是:方法论、工具和文化。

1. 方法论

方法论先行,因为它具有指导具体行为的作用,比如SMART原则,就可以起到监督我们设定目标的时候是否偏离了方向。OKR,可以作为我们管理目标和关键成果的理论框架,帮助我们更好地分解任务。有了指导原则和框架之后,并没能解决实际问题,在做项目的过程中,我们还需要以下一些心法:

 1) 范围和问题

保证所有参与者都把需求理解清楚,明白需求的范围,需要真正解决的问题是什么,在需求问题上参与者达成共识。

 2) 增加透明度

权责明晰化,每个参与者都可以看到其他人的任务、进度,明白自己所扮演的角色以及和其它角色的关系,这样每个人都明白自己不能按时完成任务会对其他人有哪些影响,从而激起更强的责任心。我们经常听到老板说,大家要拧成一股绳,乍一听还以为是拔河比赛呢。而在拔河的时候,没有一个总指挥然后大家都不知道别人的状态的时候,就不知道该在什么时间以什么方式发力最有效,所谓的拧成一股绳就变成一句空话。 

3) 强调质量

对质量的强调要贯彻项目的整个生命周期,在每一个可能会影响到产品质量的节点上,都进行强调并及时督促验证。我们见过太多的例子,比如说到后面再验证再优化,大概率是不会验证也不会优化了。所以对质量的验证要及时,不要放任,这也跟破窗理论的说法类似,当居民楼的某个窗口被捅破了之后,你会发现那一排窗口中有越来越多被捅破的现象。 

4) 小步迭代,真的小步

参与者要及时的Check-in工作成果,出现问题就及时纠正,这样才不容易偏离方向。保证大部分时候,项目处于可发布的状态,即使还是一个不完整的版本。

 5) 自动化

我一向提倡自动化,繁琐的事情、需要重复去做的事情,适合交给机器去做,这种事情由人去做往往会出错。构建一个自动化流水线,并不断优化,参考精益思想,不断消除流水线中的等待和浪费。 

6) 变更管理

代码的变更,我们有源码管理系统,可以清楚知道代码的变更历史。我们还可以把配置文件源码化,配置文件也可以通过源码系统来管理。再推而广之,需求的变更、参与者所作的改动,都可以在管理系统中记录下来,最终,需求、任务、行为,都想代码变更一样被管理起来。 

7) 风险管理

主要是技术上的风险,比如技术难题的客服;人力资源上的风险,比如人员变动;需求上的风险,比如大量的需求变更。每个模块尽量让多余一个人熟悉,这样在人员变动的时候不至于太被动。需求上的变更,审核其必要性,如果是来自甲方的强势变更,不许服从的,那就记录下来,就像上面说到,像管理源码一样管理需求,这样后面如果任务因为需求变更被推辞了,也还能找到确切的原因。

8) 数据聚合

我们使用了一些项目管理工具,那么就尽量把所有项目相关的数据都录到这个系统中,并通过可视化的面板去了解项目的各种情况。这样一方面有利于对项目有整体的把握,另外也有利于知识在团队内部的传承、沉淀和分享。一个信息流向闭环的系统,不仅可以让很多数据变得可追溯,同时有利于去改进和优化。

 2. 配套工具

工具就涉及到管理工具,比如敏捷开发管理系统;辅助开发的工具,比如IDE开发环境的插件;辅助交付的工具,比如用来构建流水线的Jenkins等。 

3. 研发文化

最后要说的是研发文化。DevOps是近十年来被推崇的一种研发文化,它结合敏捷思想、精益思想、学习型组织思维,通过构建自动化流水线和反馈环,提高交付的速度,并通过不断改善闭环系统,最终提升交付产品的能力,同时团队成员有更好的成长。总的来说就是,快速响应变化、协同工作、自动化流水线、持续改进的闭环系统、学习型组织,这些东西的长期坚持,渐渐形成团队的一种研发文化,是一个现代研发团队走向强大的希望所在。

欢迎长按扫码关注【技术人成长】视频号,与你分享更多技术人成长的心法,我们视频上见!