我认为最重要的基层管理事项
目标设定
团队目标:为公司创造更大的业绩;
个人目标:完成管理能力的提升和职位的晋升;
软件团队的搭建和培养
一般都是按照技术领域进行软件人才团队的搭建,并通过领域内有经验而且具备一定沟通协调能力的人来作为一个技术领域的Leader,从而形成领域内的人才梯队搭建。
针对有技术优势的成员,可以优先考虑,因为这样的组员在领域内自带影响力,只需给与一定的管理知识培训,即可有效完成团队的管理。
同时,需要关注其对于工作内容的跟进严谨度、耐心、毅力,是否喜欢思考工作推进的策略和方法,将工作有条不紊的推进并达成目标。当然,乐观坚韧也是优选的一个参考因素。
盈亏意识、团队考核
既然是组建了团队,自然就要考虑团队本身盈亏,也就是盈利水平。其实也可以讲此简单化,只需要关注团队的投入成本和产出成果就行了。
投入的成本,大头主要还是人力成本,关注人头;产出成果,大头就是交付的可用的客户软件功能或者团队的正向软件资产。
客户软件功能是团队当下的苟且,这个是所带团队有饭吃的基础;团队的正向软件资产,是诗和远方,是可以产生复利的资本,并且团队的创新也可以由此孵化出来,后面有专门讲到这部分,以“轮子”和乐高进行类比。
团队考核,跟随着团队的盈亏,在相同领域内进行合适维度的对比即可完成绩效公正有效评估。当然,团队的考核还有其他的因素和维度,但是作为工作核心之本,这个是最重要的。
流程的流畅性梳理
在谈及团队的投入产出和效能的话题时,大家可能都会讨论到这里来,大部分人都会怪罪到流程身上,流程仅仅是流程,他不可能万能。想要流程在设计出来就能面面俱到,这个不现实。只能说,流程本来就是一个灵活的操作指导,属于大的方向性框架,在它的指导下,能够在全部最优化执行,而我们需要做的就是能够在局部做到最优,就是最佳的实践了。
不过,流程的设计,当前确实会存在睁眼瞎的设计,因为流程的设计的工作一般会交由不具备业务流程参与经验的、偏文员性质的工程师来整理,他们没有深入到日常业务流程的执行中,对于流程的执行痛点也不会深入的访谈,最关键的问题是,他们不会也无法从整个组织的层面,来设计和思考流程的优越性,仅仅让相关的工作能够进行下去,让相关的工作有人做就行了。过程中的指导文件、宣导、检查点、执行标准、反馈报告,都是非常缺失的。让那些关键的流程仅停留在纸面上。作为“文员”的他们,他们最喜欢就是检查大家的文件有没有按照要求的格式命名、对应版本是否正确、该要的章节是否都有。
这样的流程设计和流程检查,基本上就是“僵尸”流程。
真正的流程设计,应该是需要从顶层设计,我们需要达成的最高效的运作模式是什么,过程中的每一个环节的标准和价值如何,定期复盘和深度访谈执行过程中的问题,并通过IT系统有效的数据搜集进行客观的评判,最后再进行针对性改善,再次进入下一轮流程的优化。
流程的优化不是改大方向,而是需要及时识别流程执行不到位或不理想的根因,并进行针对性的改善;如果大方向本来就是错的,那就相当于一座大厦的地基和大梁都有问题,你再怎么装修单层内外饰,也是没有意义的。
上善若水,流程亦是如此!这才是让流程“变活”的关键。
家底的打造意识和推进策略
软件开发,管理者经常的一个惯性思维就是,外面随便抓一个,就可以顶上,但是,在基层管理工作的就知道,其实这样的意识是有很大问题的,除非你的团队确实正想通过人海战术来攻克一个项目。
如果对应的软件行业本身有非常的通用性,这样执行起来还好;但对于我们这样存在一定行业壁垒和需要额外的知识背景的行业,这样做是有很大风险的。
新人进来,为什么会有3个月的试用期,而且需要大量的培训,而且是在有人带领的情况下,进行阶段性的介入实际项目的开发。行业标准如此,不是没有道理的。
所以初建一个团队,还有很重要的一个隐形的很重要而且工作量很大的工作,那就是打造家底。
如上图,我们很难让一位刚从外面招入进来的工人,使用它自带的工具直接上岗工作,如此可能引起的后果想必大家都非常清楚,每个公司的工具和标准都是不一样的,直接使用自带的工具(或经验),很可能酿成生产事故。所以,我们需要自己打造这部分团队趁手的、便捷的、标准化、适合公司、适合当下业务的工具件。这样,工作人员在完成相关工作的时候,可以快速获取到想要的工具,而且通过这些工具本身给与一些标准化和流程化的指导和纠偏,不仅可以让团队提升效率,而且可以提前规避很多低级的错误。
再举一个例子,软件行业经常提到的一个词就是“轮子”,我们都说不要重复制造轮子,其实就是我们需要尽量创造可复用的代码单元块。
因为再庞大的软件系统,也都是由可拆分的代码组件块组装而来。
我们将这种通过软件单元块的搭建成可用软件的过程,类比成乐高游戏。
可被重复使用“最小乐高单元”示例图
可被重复使用的“中间粒度乐高单元”示例图一
可被重复使用的“中间粒度乐高单元”示例图二
通过 “中间粒度乐高单元”和“最小单元乐高单元”组建的“乐高作品”
纯粹的代码(或编程语言),是组成“最小乐高单元”的原材料,通过多行代码有效“建模”“型成”可处理特定数据的函数或者方法,等同于“最小乐高单元”,而通过对多个不同函数的编码和组装,形成具备基础业务处理能力的模块或组件,此类函数是为了解决某一专门的业务问题而存在的,等同于“中间粒度乐高单元”,而将这写代码、函数、模块或组件再次进行有效的“组装拼接”后,就可以高效地完成产品软件的开发,而这个最终的软件,等同于最终的“乐高作品”
而针对初建的团队,首先得解决“有轮子”的问题,而这写可用复用的“轮子”,就是团队的家底。
由于团队初建,由于每个人对于软件的认识和这种“轮子”的意识,还不那么高,所以,我们需要动用“变革”的技巧力量,来推动这个事情的落地,主要有如下基本步骤:
首先,提出有冲击或能够让大家认可认同的“证据”,这个可以通过行业数据说明轮子在软件行业的价值,对于一个团队的成果业绩输出、质量提升、能力提升等方面有怎样的好处,而我们作为“一穷二白”的团队,没有这些,我们当前又面临怎样的问题?bug多、项目周期短但是每个功能都是从零开始开发,如果项目正式启动再策划“轮子”的打造,又无法满足客户的交付等。
回想我们被项目经理和客户被逼到墙角的各种窘迫,回想我们被领导和客户质意软件交付质量时的无奈,回想我们一直想提升自己的技术能力(如架构能力、编写优化代码的能力、重构的能力、全栈能力等)却没有机会或时间的悔恨!
然后,针对大家反响的情况,给团队一个方向,通过观察,选择有志之士,组成“尖刀班”,让一部分人先“跑”起来,然后,再带动更多的人投入到这个行动中来。
过程中,不断地宣导我们地理念,定期地展示成果并定期地表彰有贡献的参与者,适当忽略还未投身革命的人士,千万注意不要对他们进行批评,因为你还处在初期阶段,你需要尽量多的参与者。
随着时间的推移,只要你的意识得到了传递,并且你持续关注产出和褒扬,最终的成果就是时间的问题了。
成员执行力意识培养
首先,流程要建设好,且执行步骤要讲的通透,而且需要天天宣导,定期检查。
流程,工程师在日常工作过程中,除了需要给予清晰的目标外,还需要有明确的流程及工作指导文件。
其中,工作指导文件我认为是不能缺少的,原因有二:
工作指导文件是给工程师的日常工作的一个正向参考,也算是对应岗位及流程执行是,对应阶段的最佳实践,如果有非常清晰的工作指导,这样就可以给与良好的引导,不至于走偏,保证大部分时间不会“扯皮”,部分同事认为,我给予模糊的工作范围,目的就是给予员工一些发挥的空间,让工程师能够有更多的贡献,而且在日常工作中,管理工作可以随意发挥,我认为在高层管理时,可以只给方向,不给操作指导,如果面对的是基层的一线工作者,我认为就需要给出明确的工作要求和指导,刚才提到的对于新入职员工有很好的指导和引导价值,同时可以让团队和管理者,能够明细哪些是自己的本职工作,哪些是本质以外的工作内容,在进行绩效评估时,也可以进行有效的对比和参考;同时,特别是在组织之间(上下游学科/上下游部分),也可以减少扯皮的事情。
在基层管理中,只有清晰可执行的工作指引,这样才能让工程师在明晰自己本质工作的同时,在干好自己本质工作同时,能够进一步有效延伸,争取更多的挑战及绩效,否则可能出现舍本逐末的情况。
在清晰的工作流程&指引的同时,如果能够给团队说明此流程的优越性和先进性,这样,流程就会有更多的拥护者和执行者,因为这样,大家才可以清晰的了解到自己在流程中所承载的价值,并且是高效而且是基于前人经验的情况下构建起来的。
我们有时会问,为什么相关的流程有,但是就是执行不下去,其实这个缺少是值得反思的,而且需要有序的进行复盘,并且需要获取如下信息:
对于具体的工程师:
是不知道此流程的存在?
还是指导流程的存在,但是不知道怎么执行?
还是指导怎么执行,但是没有时间或者不想执行?为什么?
只有深入的剖析,才能找到解决此问题的密码。
作为基层管理者(我这样的角色),我也在反思:
我知道这个流程吗?
这个流程怎么执行,知道吗?
有没有主动关注和推行这些流程的执行和落地?执行过程中,是否有发现什么问题?效率高吗?便于执行吗?自己花了多长的时间在这个流程的推行上面?
自己是否有更好的想法来优化这个流程呢?如何评价这个建议是否是优秀的?
如有优化的建议,如何推行这个变革呢?有这个影响力来推动吗?关键人员是谁?
流程的潜移默化,让大家形成“肌肉记忆”是非常有必要的,在某件事时,即自动反应对策,形成自己的工作模式和应对套路,需要结合如下几个点:
持续不断的宣导;
结合自己的检查和其他方的反馈,及时反馈存在问题的点,明确的给与奖惩(口头);
在小组例会或者重要场合,进行结果宣导,适当给与物质奖励(引导为主);
对于一直存在执行问题的同事,私底下给与足够的关注和引导,避免引起群体效应;
如流程自带先进性和大家对于流程的深度认可,执行效果加倍;
这一块可以在周例会的小组例会(周例会PPT)和晨会上都有频繁宣导,在日常工作开展过程中,也注重发现和及时纠偏,梳理原则和强调规矩。
效能的话题永不过时
效率=单位时间内团队产出/单位时间内投入成本
产出有效提升
增加可复用的“轮子”、可快速仿照的规则、可参考的最佳实践
合并同类项(专人专项,专业成就效率)
一次把事情做对,减少重复投入,降低简单的错误重复出现的概率(特别是售后问题/客诉问题等)
意识形态(流程、标准、规范、经验)
个人能力(技术、沟通、总结、学习)
团队方向(目标、流程、合力、除障)
成本有效降低
Bug数量多
同一个Bug反复被激活的占比高(获取相关项目被重复激活的Bug百分比)(Bug激活率/版本发布成功率)
各个项目的Bug攻关的名场面
研发投入严重后置(解Bug时间投入),正向的前置研发投入严重不足(正向设计),项目后期出问题成本
解决问题的能力及团队信心的培养
团队带头人
遇事不慌、长远眼光、坚定目标、变革有时
不专挑组员的刺,要多正向引导,及时表扬、有效激励
遇到组员破坏规则,要及时制止,流程意识,时刻宣导
以身作则,为公司办事
遇到问题(人员)怎么办:
解决的问题能力,关注如下几点意识,相关的问题解决起来就不难了。