管理实践小记

我想得到什么?
企业雇佣我想得到什么?
灵魂拷问:我会不会被能换掉?
企业需要你,不是必须要你。
什么是职业经理人
以经理为职业的人
为了某种职责,以此为业称为职业
用特殊的方法,达到一定目的的行为称为管理
管理就是价值转换的过程


2020年06月09日

管理解码19条

原则

- 关注结果、为整体做贡献、聚焦关键、利用优势、建立信任、正面思考

任务

- 目标、组织、决策、监督、个人发展

工具

- 会议、报告、工作计划与控制、个人工作方法、预算及编制、绩效评估、垃圾处理

今日总结:

- 学会担当,放权不放责
  金一南:忠诚 干净 担当*

今日疑问:

- 如何用魂道术器挽留一个想离职的人?
  答:如果想走,就让他早点走!

下期疑问:

- 如何快速挖到一个能干活的软件技术人员?

2020年06月10日

关于监督:
重新声明规范,强约之后,必须铁腕治理。
技术岗要求的是标准之上的人行标准之上的事,标准是什么?
是一套体系,一种行为规范,一部部门规章,内容尽可能的少,但非常有价值。
关于工具:
对于一个技术人员,速度快一毫秒,尺寸优化1kb非常重要。
自上线微服务以来,我们距离理想的生产环境慢慢在靠近,同时距离理想的生态环境却渐渐变远。
产品上线大致分为四块:需求>研发>测试>部署
其中,自动化需求是不可能的,自动化研发至少现阶段科技水平也做不到;
唯有自动化测试和部署。因精力有限,测试首先用堆人力的方式完成;
而部署是一个利用自动化脚本,设定好必要的参数即可自动完成。
且多环境日常部署每天要消耗1-3小时的工作时间。
介于以上原因,最近特别制作了自动化部署方案,只需要发送一条指令给服务器。
服务器10分钟即可完成代码的上线部署,相当于年度平均节约66天个人工!

后记:一个时刻追求极致的人,是我们一直需要招募的。

- 小故事样例:
有一个老丈人说:小伙子,彩礼不问你要30万50万,你第一天给我一分,
第二天给我二分,往后每天是前一天的一倍,连续给我一个月,
我就把女儿嫁给你。
- 小伙高兴坏了…… 叔,这是第一天的 红包到账1分钱。
15天 327元            :)
28天 2,684,354元      :|
30天 10,737,418元     :(
他老丈人一定是教数学的,他想用1分钱撬动1000万。
评:别小看任何一个细节、千里之堤,溃于蚁穴。

2020年06月15日

关于组织
在信息中心想培养出来一个能干活的实习生,至少需要一年,
让一个有工作经验的新手,独立负责一个模块也需要半年,
更有甚者,工作一年带来的项目贡献价值为负,影响极其深远!
试想:多人写同一本书,如果没有核心主编,那这本书内容得有多乱?
再试想,多个实习生,写同一本书,因为水平不一,造成的体验会有多差?
关键,这些都是表面看不出来的,你永远不知道下一个bug是多少年前哪个实习生遗留的。
做软件系统 应该给新人机会,每个人都由新手走过来的,但是核心业务,你敢用刚毕业的新人吗?
由此,可以看出,团队建设中,中级开发人员就是中坚力量,是多么重要。
但是,如何让一个新入职的员工更快的上手进入到核心模块的研发?
学习与加班,同样是3年工作经验,有的人是用一年加班加来的。
PS.只有主动加班才是真加班,被动加班都是在浪费公司的电!

近期目标:团建

团队建设中,中级开发人员就是中坚力量,但目前大部分开发都是新手及其工作经验。
只有快速培养新人,才能让企业的中坚力量更稳固。

后记:
辛辛苦苦从搭建,到开发实践,再到生产应用的项目就像自己养育的孩子。
总想再多保护一点,但他需要长大和蜕变。
不管是高标准还是低要求,让他有意义的活着,比什么都强。
但,有谁不想让他一鸣惊人、一飞冲天呢?

2020年06月16日

关于聚焦关键之抓大放小

彼得原理告诉我们,木桶盛水量是由短板所限制,也就是常说的主要矛盾
但大部分人忽略了第二个观点:

- 比最低的木板高出的部分是没有意义的,高出越多,浪费越大!

在IT行业中,职称评级非常有用,主要解决的就是人力资源浪费问题。
高级工程师、中级工程师、初级工程师、见习工程师……
目前已经存在二八两级分化:

- 高级工程师80%的时间都在处理初级工程师制造的故障。
- 中级工程师80%的时间都在处理见习工程师制造的故障。

解决办法也很简单,把金字塔型人力结构改成橄榄球型。

关于关注结果

所看到的Bug远超它的影响范围!

- 分析问题 >> 协调对应负责人勘察 >> 协调测试复现 >> 确认复现方法及条件 >> 
  提供合理处理方案 >> 监督解决 >> 二次测试 >> 解决完成。
- 以上流程按部门统筹至少调度:
  需求部门 * 1人  测试部门 * 1人  开发部门 * 2人(高级+中级或初级)

这就是标准流程,且该流程能有效稳定快速解决所以超预期的问题。
符合要求的结果才能满足当今复杂的业务模式。
黑猫白猫的理论只适用于粗放型的初级阶段,后遗症及并发症终身难治。

关于利用优势

业务扁平化

- 再错综复杂的业务系统都需要独立的个人去做分类清晰的事务;
  总结下来就是:一次只做一件事,把事与事之间协调好、隔离开;
  年度计划永远需要剥离到月度计划、不断剥离到最小单位后,事与事之间首尾相连;
  就实现了业务扁平化(就是我们常用的甘特图理念)。
  只有精细的分拆才能管理好时间、管理好人力。
关于建立信任

细化强制约定

- 最近一直在忙这块,先总结一句话就是:"利他主义";
  这与上面说的职称呈现弱线性关系即:职称越高、利他主义觉悟也越高;
  “系统难用” “不稳定” “慢” “不方便” 等一切的根源都是没有做到利他主义;
  俗话说一白遮百丑,一胖毁所有;
  细化强约就是在落实这件事儿
  所谓的白就是体验友好,所谓的胖就是含蓄不清、界线模糊、无从下手、深坑死巷……
  用设计原则来说就是:
  Postel’s Law 波斯托定律 --- 保守输出,自由输入。

2020年06月23日

再谈关于建立信任

分类

- 团队信任
  又称内部信任,是对组织内部不同成员之间以组织目标为导向依托于各自负有职责的强信任关系;
  直白的说就是由上级领导直接牵线的合作关系的亲密程度;
  非常适用于流水线式的工作安排,因为职责的存在,一般非常好建立信任协作关系。
- 客户信任
  又称外部信任,是陌生关系的信任。
  明确一下:人类进化的成功有两个鲜明特点“紧张”和“趋吉避凶”,
   紧张就是为了快速激活保命技能,做到能随时遁逃;
  客户也是一样,在信任关系建立前需要充分再充分的知道在趋吉还是在避凶;
  生水煮成开水是一个线性过程,从 0 到 100 度,不能跳过任何一度。
  我相信人与人的信任也是一样:持以执着的诚恳,满足真正的需求,摒弃可有可无的需求,杜绝不需要的需求。
- 自我信任
  自信,自我能力的评估。

实践

- Geek 天生就对现实世界充满不信任的挑战。
- 开发者成功实现业务的路线只有一条,而失败的路子却有N条,
   只有充分的不信任与亲历亲为才能保障走一条通往成功的道路。
- 确定的小目标,完成小目标能提振信心。
关于慎始

需要做准备,但不能一直在准备

- 成大事前,专心做好一件件小事;
- 当资源收集到暂时够用时,投入实践工作。
关于时限

在有限的时间做最有生产力的事性

- 布鲁克定律:为已经延期的软件项目增加人手只会让项目延期得更厉害。
- 千万不要硬着头皮做自己根本不擅长的工作,而是应该花更多的精力做自己所擅长的事情。
关于责任到人

会议纪要的重要性

- 声音比文字更生动易理解,但文字比声音的分量更重;
- 文字能让声音在权责问题上做到板上钉钉。

2020年06月30日

关于绩效

什么是绩效:

- 绩效是指对应职责的工作岗位,所达到的阶段性结果,及其过程中可评价的行为表现。

什么是绩效管理:

- 管理者与员工之间,就目标与如何实现目标上达成共识的基础上,
  通过激励和帮助员工取得优异绩效,从而实现组织目标的管理方法。

KPI的理论基础是二八原理

- 意大利经济学家帕累托提出的一个经济学原理:
  一个企业在价值创造过程中,
  每个部门和每一位员工的80%的工作任务,是由20%的关键行为完成的。
  抓住20%的关键,就抓住了主体。
  考核工作的主要精力要放在关键的结果和关键的过程上。

结论

- 将必要的信息进行疏通,消除信息孤岛,是管理者的重要职责
- KPI导致了很多软件从业人员,把精力过早的放在结果上,
  而实际人们应该更加关注的是软件开发过程。
  对于体力工作者而言,影响最终结果的主要原因可能是懒散,
  但对知识工作者(软件开发者)来说,就不尽然了。
  任务进展不下去,主要原因之一是,开发者无法获取到想要的信息。
  因此,绩效管理应该帮助这些资源用到一处,资源充分协调起来。

实践

- 后端开发团队由打分制绩效,试实行报告式绩效。
- 因体力工作的成果,通常可以用数量和质量来衡量,但是这种衡量方法并不能适用于“知识工作”。
- 软件开发也可以看做是一种知识密集型的工作,开发者每时每刻都在加工、处理和创造新知识,
- 用代码量来衡量一个开发者是不行的,只能看他们对外界的贡献。
- 绩效考核的规则不是对比目标,而是对比每个人针对个人目标的完成程度。

2020年07月07日

再谈关于工具

工作设置与任务控制

- Jira 是项目与事务跟踪工具,被广泛应用于缺陷跟踪、客户服务、需求收集、
    流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

背景

- IT团队从2016年开始尝试使用Jira 那时团队在10人以内,业务要求在 `多快好省` 的状态下初具模型;
  从2018年前后,多次技术更新时,团队从10慢慢向15人 20人 扩建,不得已把多次废弃的Jira重拾起来;
  现如今软件开发过程中的所有知识文档及需求沟通记录全使用Jira工具;这是一个稳定的突破。
  在这几年里,项目管理中的 `问题类型方案` `工作流方案` `页面方案` 
    `字段配置方案` `时间跟踪`、`问题链接`、`问题状态`等等等
  全部都经过无数次的打磨适配,为的是适用于公司的软件开发流程及目标。
  同时这也是一个长期演进不间断优化的结果,也会一直持续下去。

实践结果

- 成功将系统的开发变成知识库的开发,极大利好未来人才培养及工作协调,避免信息孤岛。

结论

- 如果方向正确,则坚持下去!

人人都是产品经理

- 以往面试应征者,都只聊技术。而在工作才会慢慢发现这个弊端非常大;
  最好用的员工,往往是处处为别人考虑的员工;
  任何一个细节都要多站到客户的角度上去审视,往往有产品经理思维的员工,不会让客户和领导太操心。
  拿苹果的IOS举例:
   - 让傻瓜式的系统给用户少做选择题,直接了当的实现用户最紧迫的目标。
   - 非必要情况下,系统自动决策问题的解决方式,必要情况下把尽量少且优质的方案交给用户决策;
  这同一个好员工的思维方式是一致的,领导不能帮员工解决所有问题。
  让领导选择决策,让会议出落实方案,让方案查可有据,是合格产品经理基本素养,也是所有员工的目标要求。

2020年07月10日

骨干队伍和人才队伍建设

能者上、优者奖、庸者下、劣者汰

用加法做人,用减法做事

- 人一定要进步,技术能力,处事能力,挣钱的能力,要做加法,只有增量才能让人活的有意义;
- 做事一定要用减法,站在前人的肩膀上,多与前辈沟通。
  勇敢试错,排除所有错误答案,那些错误答案就是宝贵的经验,有了经验才能把事儿做到没的挑。

不合格开发者常说的三句话

- 不可能出问题(过度自信)
- 我本地好好的(不愿理解别人)
- 报错是用户的问题(不愿担责任)
评论未能加载 DISQUS被屏蔽 请检查网络