奈飞企业文化

一 值得推崇的价值才是真正的价值

判断力  

案例实践参考阿里巴巴的政委体系关于判断的定义：

具体判断的四个维度

一  闻味道

每个组织都有自己的气场，管理者既要有敏感度和判断力，又要懂得望闻问切。望：透过现象看本质；闻：感受，闻气味；问：沟通；切：以小见大，切中要害。

简单的说，感知组织冷暖和体察员工状态，基本方法：

  1.1反复观察：什么是闻味道，说得通俗一点，就是反反复复的去观察，做一个HRBP（政委）要会观察，还有要有悟性，如果你不会观察人的话，你是一定做不好HRBP（政委）的。

  1.2综合诊断：闻味道深层次解读是综合诊断，这个员工与阿里的主流企业文化是否一致；和团队深度交流，看一看团队的温度如何，是团队已经高烧了？还是团队的体温过低？你作为政委，需要及时为团队解决团队中的问题，也许是沟通问题，也许是支持问题，也许是团队需要找个地方high一下。

二、摸温度

需要及时感知这个团队状况，团队士气是否过于低落，需要设法振奋一下，团队士气是否高烧不退，需要降一下温。

三  照镜子

认识真实的自己，肯定自己的优点，发现自己的短板。美己之美，美人之美！照镜子分照下属、照自己、照同事和照老板，都要做到及时交流，定期review。

   3.1、不同维度：需要政委主动去和三种人群交流：上级、平级、下属。在阿里巴巴，有一个说法“对待上级要有胆量，对待平级要有肺腑，对待下级要有心肝”，每个角度所重视的不一样，上级关注你的思维和价值观，平级关注你的沟通与胸怀，而下级关注你的能力和关爱。

   3.2、创造氛围：比如以别人为镜子，需要创造一个简单信任的团队氛围。政委团队流传这一句话：“你对我不满意，就来找我，可以骂，可以批。但如果你不对我说，而是在背后说，那么请你离开”。一支团队有了信任，才有可能协作的土壤和机会。

4、揪头发：你知道你的上级现在想什么？你知道你上级的上级在想什么？上一个台阶看问题，把问题揪出来，揪上去。多方位多角度考虑问题，有全局观。

具体操作实践：

一、拎包陪访：阿里政委除了参与业务开会之外，他们还会陪着一线的员工，比如跟着一线的销售人员，直接到市场周边去陪访、去拎包，这样政委可以直接接触员工的工作场景，触碰到团队的温度，看到市场真正的问题，听到客户真实的声音，这是政委了解业务的一个非常重要的动作。

二、持续沟通：政委会跟员工做一对一的访谈，根据员工日报周报，去看业务和人身上的问题，去组织管理者的一些论坛，逐渐植入招聘，培训、绩效等人力资源专业的动作，去贴近管理层的沟通.

   2.1、随时随地：阿里政委会随时找员工访谈，平时有50-60%的时间在和员工访谈，传统的企业里，HR都是遇到问题、有硬性的工作要求的的时候才找员工谈，而阿里政委几乎每天都会和员工各种聊。

  2.2无所不聊：跟电视里演的那些政委一样，了解员工的各种情况，家庭动态，业务动态，团队成员间的状态：他要买房子么？他妹妹要买房子么？他娃要读小学还是幼儿园？他现在在工作中间遇到困难没？是否需要支持？他和团队中的其他人配合如何？……全方位立体化的，都需要了解，必要时也需要给出解决方案或者是支持。

沟通

案例

职场(潜)规则：心法和技法

作者：郑昀

链接：http://zhuanlan.zhihu.com/zhengyun/19639346

来源：知乎

是不是对其他主管有意见？是不是对其他部门有意见？是不是对公司有意见？

每个部门都有部门的行事准则和立场，所以有时候就是要“公事公办”，把话摆在桌面上说，一次说不清，那就约好了再聊一次。

话不说透，憋在心里，可能会违背下一个潜规则“不要等死”。

这条规则看似容易，但真的很难，大多数情况是，有话要说的时候通常都不愿意好好说，对吧？此时，只能长叹一声，让上帝的归上帝，让凯撒的归凯撒吧。

我们这里强调一下，有话要说的四个原则：

第一，态度要诚恳，传递明确的“我是为了解决问题而来”信息，是的，你不是来砸场子的。

第二，摆观点时一定要注意要“有据”！千万不要讲一些道听途说、似是而非、张冠李戴、捕风捉影的观点。把头头脑脑叫到现场，结果由于你没有遵守上一个潜规则“信任但是需要确认”，抛出的观点都是“转发（下属的）微博”而已，你自己也不做过滤，具体细节一问三不知，太丢人了。反正我的第一反应就是问“譬如说嘞”，没有具体案例和上下文，我只能左耳朵进右耳朵出。

第三，事先准备好提纲一二三四，别开会开成茶话会，浪费彼此时间。

第四，如果你是在公开场合上讲别人的问题，至少我的领导就会立即问你之前是否就此问题与对方主管有过沟通，如果没有，请立即停止，沟通之后再决定要不要讲、怎么讲。

第五，如果你不了解其他人在做什么工作、遵循的是哪些规则、具体怎么执行的，请不要给他贴标签、下结论。

是的，请你闭嘴，你可以在心中下结论，但不要说出来。

我会歧视那些刚看了一眼、听了一耳朵就下结论的人。你清楚公司是怎么运作的吗，你了解跟你隔行如隔山的那个部门的部门职责了吗，你给过他为自己辩护的机会吗，你明白你肉眼凡胎看到的现象背后的 Root Cause 吗，你曾经试图静下心来听听各方观点吗？

这块的案例容易得罪人，我就不举例了。

我们其实每天都在妄议他人。妄议他人的结果就是，被下结论的他，要为此付出很高的解释成本，甚至都没有机会解释，直接 game over。

冲劲

案例：《穷追不舍、事故入手和倒逼》

商业转载请联系作者获得授权，非商业转载请注明出处。

作者：郑昀

链接：http://zhuanlan.zhihu.com/zhengyun/19894956

来源：知乎

对干部和员工的行为管控是一件很困难的事情。

原因呢有三。

一，员工在之前的职业生涯里并没有接受过职业培训。譬如你常常见到员工像踏足现代商业社会的原始人，连“Reply”和"Reply All“都分不清楚。

二，员工从干部那里接收到的行为指令往往是模糊不清的。譬如”下午做个设计评审“，到底意味着什么？需要给员工一个明确指示和范例。

三，人普遍忘性大惰性大。

所以，很多问题会随着铁打营盘流水兵而一再上演。

那么呢，有三种手法来训练自己的团队，使得在突发事件出现时（也就是之前既没有流程定义，也没有干部知道该如何处理），团队能够自动自发地灭火。

第一，穷追不舍。

干部叫以身作则亲身示范，对每件事都穷追不舍，必须有一个结果。

首先，每一件事情到了干部这里，都能够不惜时间不惜体力不惜代价地对自己的团队要一个结果。

其次，干部明确传达出一个信息，所谓“结果”代表的是“真正解决问题”，要拿出解决问题的诚意，而不是被两句话打发。

长此以往，干部和员工就知道这个团队的作风是不会善罢甘休的，譬如对于研发干部而言，就知道涉及到交易支付的技术问题，不死不休。

那么，这种“行为”就会向下传染，成为一种“惯例”，一代一代的员工都能感受到。

第二，事故和投诉入手。

建立基本规范和流程后，干部长期从事故和投诉入手，对每一件都追查到底，顺藤摸瓜。

为什么要这么做？

所谓企业文化，很多时候是由“组织习惯”组成，而它很大程度上是公司成百上千的员工独立决策所形成的、长期“坚持”的组织习惯，这些行为习惯往往不在你的规章制度和业务流程范畴内。

那么从事故和投诉入手，就很容易揭开盖子，发现以往的一些习惯和行为是错误的，或者说是不可靠的。有些习惯以前是对的，现在是错的，这些都能够通过事故和投诉暴露出来。

实践证明，很多组织习惯是轻率的产物。

对于研发板块来说，顺着事故和投诉发现问题、提出问题和解决问题较为简单。我们毕竟是技术人员，可以用机器干掉这些习惯，减少人为干预因素。譬如说，我们可以依靠项目管理平台，让所有需求在它们的生命周期里从头到尾在平台上任务流转。譬如说，我们可以禁止手工提交发布包和手工上线，人只是上线任务的发起者而已，其他的事情交给更可靠的机器做。

第三，倒逼。

下游倒逼上游。

这也是技术领域常见的手法。一开始，开发规范和项目质量管理制度都会流于形式，大家懒得看、懒得遵守或者觉得束手束脚。我们不会去揣测大家的动机是什么，我们只需要纠正行为即可。

如何纠正？

下游设立一组或多组最后的看门人。看门人对事务的判断非常简单，非黑即白。

譬如，第一招，不符合质量控制的要求，不允许上线，甚至不允许提测，第二招，系统管理员只接收质量控制流转的上线操作指令，第三招，开发者没有生产环境的发布、修改配置文件等权限，更不用说数据库写权限了，只有数据库管理员才有写入权限。有了QA、SA、DBA这三组看门人，要求和压力慢慢地就会自下而上地、一层传一层地传播，最终大家都意识到，遇到事情先想想怎么过质量控制的check list吧。

这三种手法印证了一句话：先有技法，后（才可能）有心法。

指望先教会大家心法，然后形成技法，多半不靠谱。

『先有技法，后（才可能）有心法』，其实与华为说的“僵化、固化、优化”是一样一样的。

好奇心

创新

勇气

热情

诚实

无私

情境管理而非掌控管理

著作权归作者所有。

商业转载请联系作者获得授权，非商业转载请注明出处。

作者：郑昀

链接：http://zhuanlan.zhihu.com/zhengyun/19701633

来源：知乎

每一个快速发展、仓促之间聚集起来的团队都会经历1947年～1948年我党在东北所面对的局面。

从最开始出关的匆忙上阵、缺少武器弹药、节节败退、老底子被打光、成群结队开小差的逃兵、迷茫沮丧，到一年后数百万装备整齐、挑着狗皮帽子沿路炫耀武力的军团入关，这中间到底发生了什么？

简单地说，对于现代公司运营者来说，可以借鉴那个时候他们做的三件事：

第一点，统一价值观，这也是每个期望基业长青的公司都在着手去做的。在东北，他们是通过在基层员工搞阶级教育、诉苦运动，解决为谁当兵、为谁打仗的问题，从而统一了包括大批“解放战士”在内的员工价值观。

第二点，认识到价值观之外还有技战术素养普遍缺乏的问题，于是管理者必须提供工具。

什么叫“提供工具”？

经常会看到这样的场景：

管理者质问员工，你怎么这么瞎搞!

或者质问，就这么点儿事，你们都搞不定?!当年我分分钟搞定!

或者质问，你们怎么什么都不会?!

然后留下员工苦苦思索，领导甩手大踏步离开。下次员工保不齐还得被骂。

为什么（管理者）要提供工具？

因为要形成干部的工作套路。

什么叫工作套路？

林彪他们非常善于总结并简化套路，它们通常非常容易记忆和套用，非常适合向下传达，甚至细到以班为单位。

他们下发了六个战术原则：

一点两面

三三制

四快一慢

三猛战术

四组一队

三种情况，三种打法

这就是套路。

有了套路，管你东西南北风来袭，我只管上这六板斧，管你铁打营盘流水兵，我只管培训和演练。

什么是一点两面？

1946年9月15日，毛致电林，问“你们所说一点两面的战法是什么意思”，四天后，林彪回复邮件：

所谓一点，就是说要集中优势兵力于主要的攻击点上，反对在各点上平分兵力的办法。所谓两面，就是说必须采取勇敢包围办法，防止敌人突围逃走：两面是 指至少两面，兵力多时也可以是三面四面。一点的精神在於保证一定打垮敌人，整个的精神在于使打垮的敌人不致跑棹。大意就是如此。是针对我们干部不肯彻底集 中兵力和不敢追行勇敢迂回的毛病而规定的。

什么是三三制？

一个班内由三至四人划分三或四组。正副班长为当然小组长。另在班内挑选政治较好、战斗勇敢，或有经验的战士充当组长。

在战斗时各组以班长为核心，在班长指挥下，率领本小组根据敌情地形，散开距离间隔进行作战，不超过班长口令指挥范围以外，在平时使三三制编制要与日常生活管理教育公差勤务等一切活动相结合，在战斗中求得灵活运用发挥其效能。

一点两面和三三制如何结合？

在战略上要集中兵力，战役上一点两面，

而在战术上，战术动作却是分散兵力，稀疏兵力。

兵力集中并不是要求我们在冲锋时密集队形，而是要求在部队冲锋时，必须有充分的人力掩护与配合冲锋的部队及二梯队，所以兵多不是一下子都冲上去，而必须用三三制的队形。

什么是三猛战术？

猛打。

猛冲。

猛追。

猛是猛然的猛，即强调出其不意的突然性。而不是凶猛的“猛”。

什么是四组一队？

四组即火力组，突击组，爆破组，支援组。

主要是突击连队要分工，小组互相掩护，互相配合。

有点像研发时架构组、前端组、DBA组、系统组分工协作互相掩护一样。

下发六个战术原则，就行了吗？

你以为定义好三步，大象就能自个儿装进冰箱吗？

需要怎么做？

培训直到最基层

案例点评

——结合正反实例反复讲

——有机会就讲!有机会就补充!有机会就强调!

不断检查!不断重复!

郑昀问你，你们的工作套路是什么？请掰着指头数一数。

常规战争的周报+闪电战的日报

定期风险预警

脑图/鱼骨图

MS Project/甘特图

排期会

每日站立晨会

项目启动会

任务看板

项目信息墙

SWOT

日常拉各种List清单的习惯

内评/外评评审会

Code Review

自动化测试

测试驱动

倒逼上游

“四象限”法

罗伯特议事法则

……

前面讲了那些年他们做了三件事，第一点统一价值观，第二点管理者提供工具，第三点是什么？

管理者要直面白刃战

第三点是管理者不能停留在宏观层面，总是说一些似是而非、永远正确的话上。

管理者必须直面白刃战，必须随时能深入到业务细节。

什么意思？

郑昀从最简单的“表头法则”说起吧。

表头法则

——当你交代一项需要你汇总或检查的工作时，给他（们）定义好输出的表头。

最怕的就是管理者“一句话”作风。一句话让下面所有人跑断腿，然后一句话否定大家的揣摩上意后的努力，最后一句话让大家再做一遍。

比如，你说我想知道现在大家都在忙什么，那你就统一给所有主管下发一个表头：

需求登记时间

需求总发起人

状态

紧急程度

跟踪负责人

预期上线时间

实际上线时间

占用资源数

方便填写。要不每个人给你一个自定义格式，甚至只是一些项目名称罢了，你怎么合并，电话邮件沟通来沟通去，有这时间，下发一个表头，要求逐一填写不就结了？

你拟定不出来表头，很有可能是你压根不知道工作细节，你不知道一个指令如何落地、如何实作、如何汇总!

最后展示一下辽沈战役中军委下发的“铁路大翻身”电报，大家体会一下。不要觉得郑昀你是军委，所以铁路翻身是小事儿，是细枝末节，那是你对工作优先级判断力不够。而判断力不够，是诸多管理者下课的原因。

所以，请管理者不要吝于定义流程步骤。

下面请看：

电报全文如下：

刘邓、陈粟、陈谢韩、徐滕薄、饶黎、张邓、谭许、聂肖刘、杨杨耿、彭张、王王、贺箫、李周（注：这封群发邮件是抄送众多高级将领的）：

东总介绍铁路大翻身的方法如日下：

（一）以百人左右为一队，几十个人也可以，携带粗绳廿根，结实木廾根（内一部份可用铁路上起道钉之铁起子）及一二十把铁锹洋镐。（注：物料、人力这些资源罗列清楚，方便各部门的成本核算）

（二）第一步将铁路一边之两根铁轨连结之螺丝钉取掉（或毁棹），并取下结合处的两槐小铁板，只能截断一边铁轨，不应截断两边铁轨。

（三）第二步从两根铁轨断开处，用工具将二、三十根枕木下的垫土刨空。

（四）第三步，用粗绳隔一枕木，将铁轨和枕木交叉处捆结实（十几根绳子按次均捆上），然後以一部人用木（铁）棒将分离开的一面铁轨撬起来，同时用力拉绳子，使整个铁轨枕木翻个筋头，接著便很容易的往前。结果全部铁路都翻了筋头。

（五）然後将枕木取下，堆集起来用火一烧，日前敌人修路极感头痛的是没有枕木，要从美国运枕木来，因此烧掉全部枕木，是重要的一着。

（六）此法开始时较费力气，只要开头翻过，事後利用铁轨本身重量及压力，越翻越轻。据我们的经验一连人每小时可翻六里长，所以这种方法的特点是方法简单，动作迅速，破坏规模大，所费力量小，东北敌人十分怕铁路翻身。（注：明确效果，确认各部门对任务的优先级理解到位）

军委

廿敬

认同一致 松散耦合

著作权归作者所有。

商业转载请联系作者获得授权，非商业转载请注明出处。

作者：郑昀

链接：http://zhuanlan.zhihu.com/zhengyun/19701633

来源：知乎

背景知识，阿米巴组织

所谓“阿米巴经营”是指，『将组织分成小的集团，通过与市场直接联系的独立核算制进行运营，培养具有管理意识的领导，让全体员工参与经营管理，从而实现“全员参与”的经营方式。是京瓷集团自主创造了这种独特的经营管理模式』。 我们认为，数以百计人员组成的大型研发组织，或许可以划分为更小的“集团”，即子部门，这些组织的负责人可以推动自我进化自我迭代，在某种程度上属于阿米巴组织。

一，工作范围，主动出击

我们认为，每一个研发子部门，应该努力演化为一个自成体系的组织。这也就是子部门负责人的目标。每位负责人都有自己的工作背景和成长轨迹，可能在有些方面“奈何力有所不逮，技术有所不及”。这里要强调的是，打铁还要自身硬，请你主动出击，率先做到自我管理、自我激励、自我完善，然后惠及他人。

所谓组织自成体系，指的是：

自我进化

招人、留人、培养人

自我淘汰

能快速识别出能力、责任心和诚信上不符合我们团队价值观的员工，当断则断，清理干净；

自我升级

带领团队成员在研发效率、研发能力、研发活力上共同进步，不偏科，不随波逐流；

建立知识库，随时做好知识转移，应对突发的人员危机；

对结果负责

一个子部门通常能独立完成研发工作，包括优化措施和预研课题，所以子部门负责人应该对这些工作的结果负责；

请你们知晓，职场有一个残酷法则“没有苦劳，只有功劳”，不要期望公司因为你和小伙伴们有苦劳而宽容你们没有产出。

子部门应该在以下事务上自我运转，无需上级主管事事安排：

招人

你应该不定期提出招聘计划，经过上级主管审批后，对接HR的招聘部门；

你应该撰写招聘岗位的 JD（Job Description），定义岗位职责和任职资格，指定初试和复试的面试官，指定岗位入职时的直接上级；

提前查探到员工离职意向，在面谈无效后，你应该预先（向上级主管）提出离职补岗需求；

面试

你与面试官通过阅读我撰写的《面试、入职、离职的那些事儿(附录A.1)》，商量好面试策略，不要盲目面试，必要时提供笔试题集；

你有必要通过阅读我撰写的《面试案例点评》和《面试技巧》，了解如何甄别面试者；

一对一面试，与一对一绩效面谈一样，是一门学问，请尽快建立你的人才选拔观和面试问题集；

如果应聘者通过初试和复试，你应该形成书面资料，记录对候选人的评价，以与入职后他的表现相对照，不断修正你的人才观；

培育新人

你应该为新员工指定导师（mentor），你或导师做好团队、技术架构、工作制度等介绍；

你应该思考哪些人适合做新生导师；

你与导师一起制定新员工在考核期内的考核项。我希望你们做到的是，通过一个或多个考察题目，尽快确认新员工是否具有独立分析问题、设计和解决问题等能力，他必须能当众讲解直面PK而不是只说服你即可，如附录A.1所说“不要跑过来跟我说， （他）“凑合”、“能干活”，我们不需要行尸走肉”；

将萌芽消灭在试用期，牢记两句话：

实践证明，你在面试或试用过程中发现的他身上的缺点，在日后的工作中将无限放大，直至你无法承受后果，最终还是要辞退他。

在现行法律制度下，员工在试用期的考察非常重要，因为只有在试用期终止劳动合同是痛苦指数最小的。发现不合适的员工，应该在试用期尽快解雇。

人员打组

每个子部门至少7人以上，你为了方便管理，要分组并指定 Team Leader；

你必须对 Team Leader 的输出物做严格定义，确保规范执行，如（项目/小组/人员）周报发送时间、格式和表头，如是否做组内排期，排期表的表头，如对外输出项目计划、延期通告的格式；

关键岗位实行“AB角”备份制，避免单点；

对 Team Leader 要求要越来越高，“逼迫”他逐步成长起来；同样， 我们对你的要求也会越来越高 ；

进度管控

你承接的每件事都要指定一个研发负责人，他要做任务分解、制定和核对项目计划、建立和检验里程碑、组织评审会、组织演示会、组织站立晨会等等；

你要通过阅读我撰写的《最佳实践系列：常规项目管理（跨部门项目）的12个最佳实践(附录B.2)》，理解在什么场景下启用哪些最佳实践；

你应该逐步把进度管控交给 Team Leader 来跟进，你必须确保项目中暴露的问题都得到妥善解决；

绩效考核

“天下武功，唯认真不破”，绩效考核不能走过场，我要求你必须对每一个考评都认认真真地面谈、撰写评语，员工也必须认认真真写考核期内的总结；

我希望我们板块始终是公司里做绩效考核最认真的一群人，你要把员工在考核期内的优缺点明确指出来，写清楚希望他在下一个考核期内在哪些方面注意和完善，不要写套话空话；

如果我通过考评察觉你部“将不知兵，兵不知将”，我会找更适合的人来带队；

请阅读《回馈的魔力(附录C.1)》来理解为什么要认认真真地面谈、认认真真地写评语、不说空话套话、只说真话；

死磕BUG

你必须认真领会航天二十字口诀“定位准确、机理清楚、可以复现、措施有效、举一反三”，即使再忙再累，也要坚持这些原则；

请你通读我撰写整理的RCA报告集和幻灯片，认真领会何谓“Root Cause”；

世界上没有无缘无故的爱，也没有无缘无故的BUG，所以它出现一次，意味着它还会第二次光临，坐在那里祈祷是没有用的，不要等死，加监控，加报警，加日志，提高日志输出级别，再重新看一遍应用配置文件的每一行，再重新检查一遍没有显式配置的默认配置项……不要等死；

你必须要求引发严重错误的员工请本组织成员、请受牵连的其他组织成员吃零食喝饮料。我们通常处罚只到总监级，通报也仅限于提及部门名称，但建立一个温和的内部惩罚机制是必要的；

你部门成员引发的问题，请你负责善后；

发现问题

你的部门内外，一定有这样那样的问题，阻碍了生产效率，折磨了人心，如果你迟迟发现不了问题（多数情况是因为麻木不仁所以视而不见），就会有人主动用脚投票；

你必须从日报、周报、面谈以及各种反馈中察觉这些问题，，并把这些“痛点”当成一件大事，一个一个消灭；

『你真正没有能力解决的问题绝对不会超过10%。50%是你根本没有搞清楚问题是什么，20%是你根本没有殚精竭虑去找解决问题的方法，20%是你根本没有竭尽全力去找能解决问题的人帮忙。』，对于老兵来说，你所能发现的那些问题，都能解决，所以“何事惊慌(附录D.2)”；

发现问题、提出问题、解决问题，是我们的干部的基本素养，这也是我们对你的考核点之一；

谈话

（正式地、一对一地）谈话是一门学问；

通常你需要做如下谈话：

新人入职后考核期内定期谈话；

绩效面谈；

诫勉谈话；

劝退谈话；

遵从我撰写的《职场（潜）规则：心法和技法(附录E.1)》文中的规则“有话要说，但有话必须好好说：每个部门都有部门的行事准则和立场，所以有时候就是要“公事公办”，把话摆在桌面上说，一次说不清，那就约好了再聊一次。”，很多事都介于“不说憋屈”和“说了矫情”之间，在我们这里，请你尽可能选择说出来，诚恳地说真话，不和稀泥；

二，重点工作，发动群众

干革命就是要发动群众。下面是你的重点工作，但你要学会尽快分发出去：

日常研发管理；

确保“三个提升”：团队成员研发能力有提升、生产效率有提升、研发活力有提升；

有计划有步骤地落实支撑未来业务发展的技术点；

线上问题定位和解决；

分发给谁？

分发给你的 Team Leaders。不要让自己成为部门运转的瓶颈。

但要注意，你要温习我撰写的《管理杂谈：学习东北战争好榜样(附录E.2)》中提及的思想“第二点，认识到价值观之外还有技战术素养普遍缺乏的问题，于是管理者必须（向下）提供工具。……第三点，管理者不能停留在宏观层面，总是说一些似是而非、永远正确的话上。管理者必须直面白刃战，必须随时能深入到业务细节。”

别（真）当甩手掌柜。

培养好你要依靠的那几个Team Leaders，他们要和你一起成长。

三，法则常驻，三观稳定

我在《职场（潜）规则(附录E.1)》文中说，“我们的干部要争取做到发出的指令80%是正确的。指令总是正确的，兄弟们就会默认地信任你的指令，如臂使指。如果总是计划赶不上变化、朝令夕改、做面子工程、做无用功，那信任就会慢慢丧失，每次发指令时，兄弟们就会嘀咕，这次会不会又是当炮灰？”

如果你作为部门负责人，要对内对外输出价值观，你应该怎么做？

首先你要了解清楚过去、现在和未来，什么时间什么人埋过什么雷，什么时间从什么业务逻辑变为了什么，当初这个业务场景为什么这么设计，等等。不了解历史，你（一定会）无法客观地输出价值观。

其次，形成自己的判定规则，避免朝令夕改，避免输出给员工的结论和指令前后不一致 ，避免被不同人翻来覆去影响 。这也就是我说的“三观稳定”。

我们的内存中应该常驻哪些法则？我简单罗列几条，没有先后顺序：

没有苦劳，只有功劳。

事故处理二十字口诀：定位准确、机理清楚、可以复现、措施有效、举一反三。

做事有始有终，日拱一卒，拿出结果。

主动往前迈半步，必要时跑步上前对接。

代入式思考，不当甩手掌柜。

对一团乱麻要分类，分类可以有很多维度，把目的想得越清楚越可能设计出正确的维度，然后按照维度分类，针对每类情况设计解决方案和解决时间。

低头拉车，抬头看路。

遇到分歧，沟通无果后，迅速升级。

决不能“最后来的事情优先”。

竭尽可能消灭线上Exception。

晋升和成长

关于晋升，可以参考罗辑思维微信号3月21日的语音

经常有企业家问我：怎么策划一个大事件？

我总是告诉他们：没有一个大事件是策划出来的。

大事件，只能“遇见”。

这意味着——

你做了准备。

你在正确的路上。

你朝向正确的方向。

你高速运动以增加概率。

你运气好。

晋升同样适用这个道理。

对于技术人员的成长而言，我们探讨下以下案例：

著作权归作者所有。

商业转载请联系作者获得授权，非商业转载请注明出处。

作者：郑昀

链接：http://zhuanlan.zhihu.com/zhengyun/20270317

来源：知乎

第一阶段 认真构建完整的知识体系

十几年前我投身软件行业的时候，光是讲解数据库原理、操作系统、TCP/IP、组网、算法等等基础知识的英文原版书摞起来就等身，认认真真看完，各种上手实践，入行后，读遍 C++ 各种经典著作，读遍各种协议原文，认认真真打基础。

很多工程师都说自己平常就是在某些 IT 门户上看看推荐的博文或新闻，我说这属于典型的零敲碎打，不够刺激。

聊到这时，我会举一个例子，为什么要阅读长篇小说，因为中短篇小说就像用针扎你，而长篇小说就像把你装进一个沙袋里吊起来，从四面八方用狼牙棒打你，酣畅淋漓。构建可用的知识体系，就得读书，书是有体系结构的，你关心不关心，现阶段你用到用不到，它都讲到了，从头到尾看几遍，针扎得透透的。

何谓知识体系？

几年前，前支付宝架构师姚建东曾经在我们公司做过技术人员如何规划自己的分享讲座，他是这么论述的：

技术与技巧包括：

计算机基础理论

计算机模型：内存/IO/时钟/CPU……

算法

专项技术领域：

数据挖掘

数据管理

智能推荐

搜索

……

语言与工具

语言与相关体系

开发工具，分析工具，代码管理工具

HTML/CSS/JS/Ajax

常用框架与第三方类库

调试与测试

调试方法和哲学

定位问题

BUG管理工具

单元测试

集成测试

性能测试

安全测试

兼容性测试与方法

JS/Ajax测试与方法

服务层测试

Web层测试

网络与系统

TCP/IP协议与模型，HTTP/SMTP等协议

Linux系统，网络分析工具，系统分析工具

容量，流量与负载均衡

应用部署、规范、规划

安全

监控与故障分析

磁盘与存储

Shell

DNS与域名

缓存，反向代理

图片服务器（海量小文件）

需求挖掘与分析

需求文档格式

需求访谈

需求分析方法，需求分析工具

领域知识与经验

系统分析与设计

UML语言与模型

分析模式

设计模式，领域驱动

系统分析文档格式

系统设计文档格式

功能性需求与非功能性需求

数据与系统

数据库

可伸缩策略，扩展策略，备份，容灾，性能，安全，高可用……

数据设计与范式，SQL/NoSQL，Cache，分布式文件

架构设计

架构模式，典型互联网公司架构演进历史

架构原则，常用策略

架构设计方法

非功能性理解

扩展性

伸缩性

稳定性

一致性

性能

吞吐量

容量预测与规划

架构体系与相关技术

过程与管理

分析过程

研发过程

评审过程

测试过程

发布过程

回滚过程

文档管理

知识管理

项目管理

以上其实就是一份从业基础知识清单，你可以按图索骥，阅读相关书籍。

第二阶段 顺着一个Topic钻进去，锻炼自己的预研能力

无论公司业务还是自己喜欢做的事，都可以抽象出通用性课题，然后以做论文的方式杀进去。这个事情得反复操练，有意识操练。

做事方式为：

抽象出 Topic——如分布式锁，分布式并行计算引擎，防CSRF的FormToken自动生成框架，定时任务管理与调度平台，分布式跟踪，等等

向功课好的学生学习——有针对性地深入了解业界其他公司是如何分析问题和解决问题的，汇总各种方案，站在巨人的肩膀上

分析特定应用场景，技术选型

兼顾高可用性和可伸缩，做设计评审

做测试自证靠谱，梳理知识点，开技术分享会

上线商用，总结经验教训，开经验分享会

其中一个重点是汇总和分享。05年时，应电信级统一消息业务需要，我去研究了 SIP 协议，做了各种试验，分析报文，写了一系列的幻灯片，做了公开分享，一时间还颇受欢迎：

SIP_to_Freshman_by_zhengyun.ppt

SIP之穿越NAT_by_zhengyun.ppt

SIP体系架构讲义及消息交互演示_by_zhengyun.ppt

SIP多方会话消息之实例讲解_by_zhengyun.ppt

SIP安全框架之认证[NTLM和Kerberos]_by_zhengyun.ppt

SIP消息之逐项讲解_by_zhengyun.ppt

为什么要写出来、讲出来呢？

因为有一个学习金字塔理论，如下图所示：

我们读过的事情能够记住学习内容的10%，

我们听过的事情能够记住20%，

我们看过的事情能够记住30%，

我们听过和看过的事情能够记住50%——如看影像/看展览/看演示/现场观摩，

我们说过的事情能够记住70%——如参与讨论/发言，

我们说过和做过的事情能够记住90%——如做报告，给别人讲，亲身体验，动手做。

这也就是我在《窝窝研发过去几年做对了哪些事》中阐述的管理方法：我们从入职之后就有意识地训练大家，让大家能够公开陈述、清晰表达。所以，试用期内，新人必须做一次技术分享和一次技术评审，面对各方的 challenge；预研的中间和结尾都要有分享会；平时也要定期组织技术讲座。

第三阶段 疯狂回答技术问题

知识体系慢慢构建，与业务相关的抽象 Topic 也在探索中。

但这还不够。

因为你亲身接触到的世界太小，可能不足以构成挑战，你可能意识不到自己缺多少知识和技能，不利于你分析问题、提出问题和解决问题的能力培养。

所以，要主动出击：

疯狂回答问题。

我曾经在入行的头几年里几乎把我关注的垂直领域（包括语言领域和业务领域）里的所有问题都回答了一遍。我对外宣扬知无不言言无不尽，放出邮件地址和 MSN（那时候 MSN 很高大上），很多网友都会发邮件或者加我好友，问各种开发疑难问题，平均每天都有几个，然后我把解决问题的过程写成微软 KB（KnowledgeBase） 文体发表在我的博客上。

你想想看，工作中的问题你平均每隔几天才能遇到一个，而这么做，每天你都会遇到几个乃至于十几个，第一让你脑力激荡，第二接触到更多新知。

05年到06年期间，我因工作需要学习了 JavaME（或古老的称呼 J2ME），早年间 Symbian 手机上的客户端开发。那段时间我天天扫中文论坛的帖子，力求回答所有问题，尤其是那些 BUG 或故障。对于那些暂时没有人解决的，如流媒体实时播放，如仿 OperaMini 二级菜单界面，都上下求索，最后放出思路以及源码。

同时，我经常整理常见问题，梳理成册并发布。譬如我整理过的 J2ME 疑难问题：

[J2ME Q&A]真机报告MontyThread -n的错误之解释

[J2MEQ&A]WTK初始化WMAClient报错XXX has no IP address的解释

[J2ME Q&A]untrusted domain is not configured问题回应

[J2ME]“Cannot open socket for LIME events”错误解决

几个月后，我成为 J2ME 中文论坛超级版主。通过这个历程，我想告诉大家，回答网友问题，技巧得当的话，比如别老是重复回答新手问题，试着攻克那些疑难问题，或者离奇故障，绝对不会浪费你的时间。

为什么？

因为你要信奉：

你学过的每一样东西，你遭受的每一次苦难，都会在你一生中的某个时候派上用场。

——佩内洛普·菲兹杰拉德 《离岸》

Everything that you've learnt and all the hardships you've suffered will all come in handy at some point in your life.

第四阶段 RCA/总结

现在是你把经验教训变为财富的时刻了。

什么是好的技术 Leader？

随便一个业务需求或业务场景讲出来，你立刻把它抽象为几个模块/系统/Topic，然后侃侃而谈，业界都是怎么解决的，我们以前又是怎么分析怎么解决的，现在咱们这种情况下应该如何设计，可能会遇到什么问题，我们应该做哪些预防设计，blabla。

怎么做到这一点？

第一，写 RCA 报告。

我以前说过，『窝窝从 2011 年开始，一直坚持每错必查、错了又错就整改、每错必写，用身体力行告诉每一个新员工直面错误、公开技术细节、分享给所有人，长此以往，每一次事故和线上漏测都会变为我们的财富。这就是我们的 RCA（Root Cause Analysis）制度，截止到目前已经收集整理了近两百个详尽的 RCA 报告。』

RCA 报告格式为：

背景知识（Optional）

问题现象

影响范围

问题原因

问题分析过程（Optional）

解决办法

后续处理措施：如线上脏数据如何修复，如对用户造成的影响如何弥补等（Optional）

经验教训

RCA类型：如代码问题、实施问题、配置问题、设计问题、测试问题

这样，作为一名合格的老兵，你见过了足够多的血，并且把它们变成了你的人生财富。

第二，写总结。

话说，要经常拉清单。

侃侃而谈得有资料，这些都得是你自己写才能印象深刻，关键时刻想得起来。