研发管理思路和策略(一些经验和思考)


本文是《IT研发中心管理思路、策略和制度》专题的一部分。


不能被体系约束,但是又不能没有体系


跨组、跨部门协作:

    比如,要做一件重要事情,但是关系到多个部门的人,怎样 既能有效的把事情做完,又能把对他人正常工作的影响降到最低。

    我认为,绩效不能局限于本职工作,响应跨组织的协作应该是高优先级的事情。


临时事务或新想法的落地:

    比如,临时遇到一个重要需求或事情,或者想到一个很好的idea,到底要不要做?其实完全可以逃避或者敷衍,事不关己高高挂起嘛,即使不做,对自己的绩效也没影响嘛,何况很多公司连绩效也没有。

    要避免这种事情发生,就要有相关的政策引导,让大家只管把事情做好,不要有后顾之忧,而且做好了就有加倍的奖励,而敷衍的人会被发现和被淘汰。绩效不能只体现在日常工作,还应关注创新和服务工作,有的时候,服务工作和创新工作优先级要高于日常工作,甚至可以全职做。


实施方案(引导政策):


1、个人的工作安排,允许有足够灵活性和自主性,也就是说,除了上级领导安排的工作外,可以自己增加临时的、必要的工作项以及调整工作优先级,如果对重要事情的优先级有疑问,可以找领导商议。


2、跳出本职工作,及时响应跨组织的需求和协作。如果人有找到你,表示需要你协助,你必须及时回复(一般不超过1小时):如果这件事你能做,就应该优先安排时间完成,如果你做不了或者排不上优先级,可以向对方解释清楚。


3、工作中,有好的idea,可以随时找人商议,形成一些比较成熟的想法后,可以上报给领导,如果建议被采纳,可当场奖励。另外,鼓励你站出来领导和推进这个idea的落地实施(甚至可以全职投入),如果idea被成功执行和落实,将有更丰富的奖励。


2、扁平化管理

    压缩“金字塔式”多层职能部门和机构,使企业的决策层和操作层之间的中间管理层级尽可能减少。

    打破跨层级的阻碍,建立起 跨层级反馈机制 和 跨层级跨部门的虚拟组织,使整个组织紧密联系在一起(整个组织不再是金字塔结构,而是数学上的图结构,点与点之间可以连线,形成最短路径),严禁拉帮结派,避免出现许多各自为营的小团伙。


3、权力和责任成正比,明确权力和责任。防止滥用权力,有效监督。

(略)


4、以考核 驱动 正向积极的工作,避免 错误/消极 的工作。

    个人一个深刻的经验:服务工作的考核一定要加上客户评价!

    举个例子,许多公司有 “客户服务部”,接收客户的投诉和建议。其实工作中,许多岗位也肩负着服务性质的工作,如果这些工作做得不好,会是公司工作效率低下的源头。给服务工作人员的考核加上客户评价之目的,就是为了督促各岗位员工,忠于职守,热情高效的服务。

    哪些岗位存在典型的服务工作,举几个例子:行政,网管。还有很多非典型的岗位,例如运维。其实可以这么说,权力和责任是对应的,有管理权力,很多时候就有服务的责任:行政掌握了物资,就要有提供物资申请的服务,运维掌握了服务器,就要提供服务器申请的服务,等等。

      我待过不少公司,1.有的公司有类似于月度绩效考核的东西,直接影响当月的工资以及各种奖金。2.有的公司没有月度考核,只有季度汇总和年度考核,这只会对奖金有影响。3.还有的公司,没有正式的考核。这些都是些我的亲身经历。

      第1种公司,考核确实是他们很好的一种管理手段,解决了很多问题。但是做考核挺麻烦的,规则也相当复杂,没有一两年的经验积累,很难做好考核。但是话说回来,利远远大于弊。

      第2种公司,年度和季度考核,做得很粗,换句话说,很不准确,而且时效性低(比如有可能 某人这个月做得好,但是下个月做得差,这种情况在粗粒度的年度考核中很难体现),另外一点,对员工的约束力有限,因为这个只在年度才会有影响,平时根本就不用在乎, 或者有约束力 但是往错误的方向引导,因为打分的粗犷,让人认为只要讨得打分的人的欢心就行了。

      第3种公司,没有正规的考核,全凭自觉,或者主管的约束力,这种只适合 员工都很优秀 自觉,主管有很强的管理能力,这样的公司。否则从上到下一团乱。


经验总结:

1、建立稳定的绩效考核机制(一定要稳定,不能一年半载就变更),与研发人员的薪酬、奖金挂钩

2、建立稳定的晋升奖励机制,惩罚机制。

3、人性化管理:管理者制定基本规则,保证规则的正确性和稳定性,细节任由下属人员自由发挥。


管理技巧:

  • Re-Organization - 换组

  • One on One - Manager每周带一个成员

  • 个人OKR和Performance - 绩效与职级、薪酬挂钩


5、组织的组成和划分

    根据我的经验,针对垄断型产品,产品设计和研发有三个“首先”原则:

  1. 首先解决功能有无的问题,再解决用户体验问题;

  2. 首先解决用户核心需求,再解决其他需求;

  3. 首先快速上线,再根据用户反馈调整研发计划。

    (此处的垄断型产品,指的是“该产品具备固定的市场和使用范围,在这个范围内,用户没有别的选择”)

    应用这个原则,有如下一些方法:

  1. 快速原型法,快速收集真实反馈

  2. 测试先行法,开发测试,不完美测试,最小化测试

  3. 后端Mock法,屏蔽临时障碍或难点

  4. 最小功能,最简UI,甚至无样式、全部手工输入

    在传统企业,很难做到这些方法,因为它需要产品、开发、测试三方融合,共Team、共患难,

    如果没有这样的团队,就会出现下面的情况:

  1. 产品只管写文档,文档出来了,你们照着做,至于为什么要做成这样,产品说这个你别管,就是这样设计的;

  2. 产品到研发末期才验收,发现怎么做成这样,这里那里都不对,不符合预期,头大。

  3. 测试对开发说,我先写用例,等你们做完完整功能,并且通过自测和冒烟测试后,我们再正式开始介入测试。

  4. 测试发现,这里那里好像不对,找开发讨论,甚至找产品确认。

  5. 开发说,产品和测试都是死对头,恨不得在桌子底下放把菜刀,谁敢提bug、改需求就把刀拿出来,辛辛苦苦把功能做出来了,发现测试提了很多bug,产品需求也改动很多,时间也紧张,快要崩溃了,产品做出来好像也有些不对劲,怎么看都没有感觉。


    我的建议是,one team, one dream,产品、测试和开发,互帮互助,相亲相爱,朝着共同目标奋斗。


6、研发团队的绩效考核与奖励制度

    大的层面,奖励和效益挂钩,所有产品都要计算其效益,产品效益好,该产品的相关研发人员得到的奖励就高。

    基层研发团队按部门、产品线、项目组划分。如果公司小,可以不分部门和产品线,只分项目组。

    项目组成员根据需要动态配备,一个研发项目组实线 可能包括产品人员(非必须)、开发人员(包括前端、后端、移动端)、测试人员(非必须),他们共同组成一个team,可以由他们自己选出一个组长。公司所有基层研发人员,包括产品/测试/开发/运维/设计等,都在人力资源池中,需要组建项目组时,就从中调取。

    比如,公司根据需求,要成立三条产品线,五个项目组,

分别为:

基础数据服务-产品线

  下辖 数据平台组 开放平台组

应用APP-产品线

  下辖 某某APP组

基础技术服务-产品线

   下辖 基础平台组  OA项目组


 一种管理思路案例(仅供参考)

    其中,OA项目组是短期项目,预计2~3个月工期,其他项目组都是长期项目。每个项目组,有公司管理层的粗略的规划,设立了一些关键目标,并给出了初步预算,不过,这些后期都可以调整。

    这些项目拟定后,就开始招募和选拔人员,

    首先,自由报名,由公司 “产品技术委员会” 和 项目组内成员共同审核,通过则加入到项目组。

例如,数据平台组为重点项目,公司开出了10人*10万/年=100万/年的奖金,并按季度发放,张三 李四等10人都报名,经过委员会评审,决定张三 李四,第一批加入到该项目,然后后面8人,由张三、李四和委员会共同审核,最终5人入选,人员结构为 Java开发4人 产品1人 测试2人。那么这100万的奖金,将由这7个人分摊。如果中途有人加入或者退出,奖金额度不变。

    虽然,这7个人组成了项目组,但是他们3个月后发现,测试貌似只需要1人就够了,另外需要一个前端工程师长期支撑,以及一个Android工程师临时支撑——大概需要高级开发-30人/天。要减掉一个测试,需要组内所有人都同意并且报委员会审批,如果另外6个人都同意那个测试离场,且委员会审核通过,那么那个测试将会出局,回归到人力资源池中。减掉的那个人,奖金会计算到他离场的时间点,并且按最高绩效A等核算。在人力资源池里面暂时没有项目组的同学,只计算基本工资(全额工资的1/3,且无奖金),且如果3个月都没有项目组收留,公司就会与其解除合同。

    需要增加的前端,他们有两个选择,1是找个短工,签6个月(大约需要花费5万元的奖金),2是找个临时工,让其他组的同事加班支持,事情按时做完了,给与丰厚的酬劳(按一周加班16个小时算,共支持40天,每天给予1000元奖金,共支出4万)。

    上述产品化方案的问题

  • 运维怎么搞?

  • 研究组怎么搞?

  • 架构组怎么搞、虚拟组织怎么办?

  • 人力变动工作怎么交接、团队怎么管理?

    这些问题按上述方案去做,很难解决,所以还是不要自行选拔人员,而是由管理层去调度。

    首先,人数、工期和预算,管理层统一规划,比如,上面说的数据平台组,定义为“重要,紧急度一般”,预期第一版工期2个月,一期绩效预算20万,初期按开发4人 产品1人 测试2人来规划,平均每人每个月绩效开支1.4万。注意,只是公司层面的预算,而不是每个人的收入。

    后面1个月后,发现测试有大量空闲,但是缺少一个前端工程师,那么应该是项目经理向上级申请、或者管理层根据数据分析发现这个情况,主动调整队伍组成,将测试抽调到其他地方,再调来一个前端支援。

    整个产品、预算、工期、人员,都是研发管理层决定的,团队成员无需知晓预算是多少,他们的薪酬也不因项目的不同而有明显差别,不论在哪里,做好他们眼前的事情就可以了。


7、缩减会议,提高办事效率

    集体会议效率是很低的,浪费的时间也很可观,比如一个15人参加的会议,1个小时,总时间成本就是15小时,相当于2人/天的成本了。

    关键是,会议期间,大多数时间,只有很少一部分人在认真的参与,其他参与者大部分时间处于无关状态,这样算下来,一个会议15个小时的成本,浪费可能有80%,而且通常效果还不好(举个例子,一次上线评审会,各个岗位,约有15人参加,最后会议通过了评审,但是后面执行人员真正准备去执行时,才发现之前评审通过的流程居然漏洞百出,而当时他还在评审现场,也没发现有这么多问题。这是个真实的例子,其实很正常,评审的时候,并没有用心去看流程,所以到了真正执行时,才会仔细去检查)。

    综上所述,其实想说明一个道理,很多会议,不但浪费时间,而且效果并不好。真正高效的是,小团队沟通,1对1,或者3人,但不要超过4个人,否则效率会大幅度降低。


    IT研发团队,有哪些集体会议是可以省略的?

    各类评审会议,部门日常会议等。


产品研发的流程是什么,在这个流程里,产品、设计、测试、开发(包括前、后端等)应该如何配合?

这个我专门有个PPT来总结分析,此处只补充一些:

    我将产品分为多种类型,比如偏业务的产品,偏技术的产品,偏UI和用户体验的产品,各种不同的产品研发,侧重点不一样,主导权也不一样。

  • 偏技术型产品:开发经理主导,产品经理辅导;开发主导测试,测试辅助测试。

  • 偏业务型产品:产品经理主导,测试经理和开发经理辅导;测试主导测试,产品辅助测试。

  • 偏UI和用户体验产品:产品经理主导,前端开发经理和测试经理辅导。

    当开发和测试过程中,有任何争议,应该由产品的主要负责人们来定夺(如果各个负责人也无法达成一致意见,可以采取投票制)。

举例如下:

    某测试提了一个BUG,级别为“3级-严重”,但开发认为不是BUG,可能的原因是,1.测试人员的用法不对,2.需求描述不清楚,每个人的理解不一样,3.本来设计就是这样的,可能设计不算合理,但开发就是照着设计做的。

    遇到这种情况,双方沟通无法达成共识,怎么办?解决办法如下:

    开发否决BUG,并且备注原因。被否决的BUG,流转到对应测试人员那里,测试人员接受则关闭BUG,不接受,则提交复议,复议人员组成根据项目特性来决定,通常包含产品经理、开发经理、测试经理,复议人员发表评论,再由测试经理根据讨论结果,采取进一步操作:否决、重新打开(可以重新设置BUG级别)、下一期处理。

    这个主题,还包括IT团队各个岗位的设立,单独一篇文章论述,参见:《研发中心各个岗位的设计和配合》


© 2009-2020 Zollty.com 版权所有。渝ICP备20008982号