1 min to read
如何做好管理
带人
参考:如何做好mentor
带项目
一个核心点:交付
交付的两个关键维度:质量、时间
一个项目大体分为以下环节:
需求评估 → 目标设定 → 技术方案选型与设计 → 研发进度管理 → 测试、交付/上线
带团队
带团队是一个全方位的管理问题,主要拆分为以下四个方面:
- 制度管理:通过制度、流程、做事方法论保证高效的工作
- 人才管理:每个人的定位、成长规划、公司留人的核心理由
- 技术储备:团队的技术栈管理,包括广度,深度
- 业务规划:从业务背景出发,自上而下规划出具体的项目、工作,自下而上总结升华为目标
相比带人与带项目而言,带团队的挑战在于需要保证团队在做正确的事情;
衡量事情是否正确主要看是否能为业务,团队,公司创造价值,这个价值不需要理解太狭隘,比如:一项工作可以让团队成员能力提升,让团队技术栈更加丰富,对团队、业务、公司来说也是一种价值;
团队所做的事情并不全是按部就班,领导分配下来的事情,很多时候是需要基于团队现状挖掘有价值的事情,ROI更高的事情去做,这是有挑战的地方;
如何发掘有价值的事情并不是一件容易的事情,也不是一朝一夕可以完成的;往往需要立足于现状、了解业界的动态综合评估决定,一时的苦思冥想也未必有效果,需要反复不停的思考,比如平时走路、吃饭等等时候,也许就能出现有价值的想法和思路
注意管理团队的技术氛围,成员之间的关系友好性
感觉出现问题的时候,一定要对上对下多沟通,沟通是解决问题的有效利器之一
管业务
明确业务的核心目标:营收、体验、日活、留存…… 很多时候可能是多个指标,并且相互之间有制约关系。
体验衡量
- 数据,如:DAU、用户使用时长、CTR、次日留存、7日留存等
- 网民口碑(微博、社区、公众号、自媒体、商店/商城评论等)
- 用户调研(对使用体验、满意度、易用性等进行调研,比如:NPS等)
- 竞品对比
- 横向对比:功能丰富度,具有竞品没有的功能
- 纵向对比:大家都有的功能,在视觉、易用性、覆盖度等方面进行深度对比
- 业界影响力
- 是否有权威机构背书
- 竞品是否跟进,模仿
规划
团队文档目录
- 使命&愿景
- 战略、战术、规划、目标
- 新人入职文档
- 成员的成长计划
- 项目管理&需求管理
- 技术分享
- 会议记录,如复盘会等
- 每周计划
- 周报
- 做事方法论(如何开会,事故复盘,技术分享,日常记录归档,如何沟通等等)
- 工程规范,如:编码规范,上线规范
- 招聘记录、岗位JD等
文档规范
- 每周计划:工作内容,@Owner,优先级,完成情况
关于研发的一些“套路”
项目重构
优化项目组织结构、更新技术框架(换语言、升级版本、换框架等)
通用技术逻辑抽取
公共模块的剥离与封装;工具类开发;项目脚手架;
新技术调研与应用
其他
如何更好的获得同级或者兄弟团队的支持?
如何下达负面通知?
比如:加班、较差的绩效等;
重点在于心理上的疏通引导,尽量降低心里压力和情绪波动;同时要解释清楚原因和理由;
对于绩效不达预期的,首先要引导其进行反思总结,强调绩效考核的目的是反思过去,为了未来做的更好,不要直接就通知绩效;
同时,也可以找一些客观理由,比如:最近互联网行业整体不景气,今年公司业绩也不及预期,公司绩效形式本身比较严峻等等
如何高效的组织技术交流分享
技术分享是团队技术氛围建设的一种常用手段,也是留住员工的举措之一;
关键点
确定有价值的分享主题
调动全员积极性
对分享过程进行文档记录,相关资料归档保存;
每个季度结束后,匿名投票、激励;(个人不建议每一次分享会后填调研问卷,对分享者可能会有一些压力)
分享责任的要进行适当的划分,如果团队具备了一定规模,分享责任就需要进行向下拆分,既不要集中于大团队,也不要平摊到每一个人,最好是能够拆分到每一个小团队负责人,就是要将责任进行适当的拆分;即便规模不算太大的几个人的小团队,实际上也可以按照岗位的领域&职责来进行划分;
下属能力不符合预期
如何分配任务,既公平公正,大家又乐意
跨部门协作
下属工作不上心,吊儿郎当怎么办
本质上可能是对工作的不认可或者工作不饱和,应该通过沟通达成对工作价值的认知以及设定更加具体可量化的里程碑目标;
也有可能是有其他方面的事影响情绪、心情或者需要思考处理,导致不能专心工作;
组织能力评估
评估成长发展环境
- 当前环境是否能学到东西,获得成长;
- 职业规划是怎么样的,有没有迷茫
- 知不知道自己努力的方向
评估归属感
- 主管对于员工生活是否关注
- 是否可以无顾虑的发表建设性观点
- 对同事的认可度
-
是否知道或者认可自己的工作对于团队的价值(侧重于定位)
评估目标是否清晰
- 是否了解团队的目标
- 是否了解或者认可个人目标之于团队目标的价值(或者个人目标产生的逻辑),相比归属感的第四点而言,更侧重于短期目标
- 就个人目标的认知是否与主管达成一致
信息透明
- 是否可以通过部门会议、公开资料等形式获取团队或者部门的大事
绩效沟通 & CFR
一定要强调绩效沟通的目的:不仅仅是对过去成绩的考核评估,更重点是为了不断提升在目标设定、执行、总结等方面的工作经验,帮助以后的工作有更好的产出;所以实事求是,客观的评估进行;
方法论:肯定优点 → 明确不足 → 鼓舞士气
流程环节:反思成果 → 反思设定 → 反思执行 → 经验总结
关键点:总结亮点、反思不足(如果重来,哪些方面可以改进,做的更好)、总结经验方法论;
分情况讨论
横向是个人预期绩效,纵向是实际绩效
高 | 中 | 低 | |
---|---|---|---|
高 | 基本同右边逻辑 | 1. 先肯定成绩,给予鼓励 2. 宣布绩效 3. 再说明不足之处以及未来的挑战,防止骄傲懈怠 |
|
中 | 基本同下 但第3、4点需要做如下调整 该绩效没有明显不足,不必从缺点与不足展开沟通,而应该用提升,发展的角度去沟通,指导其向更高层次努力 |
||
低 | 1. 强调沟通目的是对未来的总结改善; 2. 肯定其成绩与长处 3. 明确不足之处,对不足达成共识; 4. 制定具体可执行的改善行动 5. 宣布绩效 6. 鼓舞信心 |
基本同左边逻辑 |
辅助措施
- 行业不景气,公司/部门业绩不好,比例限制严格等
- ** 很多人对绩效敏感是由于它跟奖金挂钩,沟通的时候可以给出一个松绑的解释** 绩效并不是绝对的客观衡量,里面有公司安排的比例问题,有难以界定的好坏,有团队总包的考虑;(同样的高绩效,给到薪资高低,工作是否满一年等不同的人,团队总包是不一样的)
- 绩效与奖金的关系也不是绝对的,结合前面的总包以及公司对绩效比例的约定,决定了绩效跟奖金不是完全绝对成比例的;
- 强调绩效已定,很难调整,这次是对绩效的沟通,着眼未来;
另一个维度,从标准(预期)的维度,与实际表现的维度进行对比,科学合理的解释是否符合预期、高于预期、低于预期;
最终落点一定要有具体、有理有据的不足之处;
其他
技术团队,有必要增加方案设计与技术评审环节;
团队入手项目101,用于指导团队新人学习熟悉组内环境;
项目/功能可以起一个“酷炫的名字”,可以内部用;(也有待商榷)
Comments