职能鉴定理论-职能鉴定理论

咱们平时干活的时候，极少像写论文那样，非得把难题分个“第
一、第
二、第三”来烂在肚子里。
那些东西一旦装进脑子，第二天醒来就变成满屏的列表，读起来像机器人背书，没味儿。真正的做事，逻辑是嵌在动作里的，是顺着事儿往那一站，如何顺手，如何顺嘴，如何往死里钻，如何往益处处靠，全看如何顺势而为。
有时候认定这事儿没头没尾，实际上是在摸门道，哪边硬、哪边软，那一边就顺，另一头就得绕道。 这就引出了那句老话：职能鉴定。但这词儿听着挺严肃，仿佛要把人分门别类，贴上标签。
实际上不然，它更像是一种对劲儿位的校准，是对每个人心里那杆秤如何用的细照。
不是让你去记哪位了得哪位不中，而是先看看这事儿到底得往哪边靠，靠哪位最利索，靠哪位最能接。 你看咱们公司里的部门，平时大家扯皮，实际上是出于最终收口这步没对上。
有时候业务方认定产品部不中，产品部认定交付部忒拖，结局就是互相推诿，最终俩部门哪位也没办法把活儿干完。
这时候就得拿出来个职能鉴定，先把事儿定准了。
不是非要分出个高下哪位多哪位少，而是定个位子。哪位在哪个环节卡脖子，哪位能在哪个环节多跳级，哪位能在哪个节点提前落地。
这地方要是找错了，后面再忙也白搭。 举个具体的例子，跟一个偏重技术出身的老板谈业务项目。他总认定产品部只会画图，不懂如何落地。但咱们仔细一看，产品部的人实际上比哪位都懂技术，只是他们习惯用技术语言去解释业务逻辑，而老板习惯听业务语言。
这时候职能鉴定的第一步，就是别急着说哪位对哪位错，而是得找个中间人，要么在谈话里先把话头转过来。
不是单刀直入地否定产品部的本事，而是说：“刚看你们那边最近那个技术方案，技术细节挺扎实，但业务落地这块，是不是想尽早让业务方参与进来？咱们找个工夫聊聊，看看如何把双方的语言找对路。”这话听着不像在鉴定，倒像是在找路。一旦路找到了，前面那些关于哪位更强、哪位更慢的争论，自然就消音了。 再说说执行层面的事儿。
有时候活儿是挺大的，但人也是有限的，工夫也是有限的。
这时候不能光看哪位资历深、哪位经验老，得看哪位在这个流程里是最关键的路。
比如一个项目盘算，总负责人定，产品定，开发定，测试定，运营定。
这五个人哪位在链条上离交付最近？哪位要是慢了，整个链条就崩；哪位要是忒快了，造成冗余，那就浪费资源。大量人纠结于“哪位先动手”，实际上那是战术难题，职能鉴定关切的是“哪位该定这个节”。
要是业务流程里，产品经理没签字，开发就开工，那肯定是不对的。职能鉴定就是帮你发现这个缝隙，把这个缝隙堵上，要么把缝隙拉长点，给后面留出缓冲期。 有时候活儿是混乱的，但职能鉴定要是放那儿，反倒显得过度干预了。
这时候得学会“静默鉴定”。
你看着忙，实际上是在替别人操心，结局自己也累得半死。
这时候最好的办法是承认这一点，然后轻轻敲个门：“这事儿你看着办，我只要确认几个关键点：数据源对不对？工夫节点能不能到？要是到了，咱们如何收尾？”说完这就走。真正的专家不是告诉别人如何做事，而是告诉别人在啥时候该问自己，啥时候该请人帮忙。 职能鉴定的另一个益处，是它能帮你在没事儿的时候，把脑子里的琐碎给挡了一下。大家干活总喜爱盯着眼前的琐碎，想着“哎，那个报表还没做”、“那个电话还没挂”。
这时候职能鉴定就站出来了，它告诉你：“别盯着表，先看看这个任务的核心价值是啥。核心价值对吗？要是目前不解决，后面会不会爆发？这时候再去解决，准没错。”这实际上是给大脑做了一次降维打击，把注意力从低效的重复上移到了关键的决策上。 自然，这事儿得有个尺度。忒干了，像做领导；忒浅了，像做协作者。职能鉴定最好的状态，是让你认定自己是难题的主人，可是那个在事后复盘、在关键时刻救火的人。
不是你在前面做苦力，而是在后面踩着线，确保前面的动作不偏航。 最终得说句心里话，这东西不能死记硬背。每个人的技能树不一样，行业的痛点也不一样。一个在搞基建的，看惯了图纸和现场，看功能是看结构严不严；一个在搞互联网的，看惯了数据和需求，看功能是看响应快不快。你得根据自己最近干的那些事儿，去定义啥是“关键”，啥是“次要”，啥是“务必”，啥是“能够”。别瞎想，别硬套，越具体越有效。 总而言之，职能鉴定不是为了把人分等级，而是为了让事儿好运转。它不追求完美的规整划一，它追求的是让每一块拼图都找准位置，让每一根链条都顺畅衔接。别总想着去鉴定别人，有时候自己先把自己那块“拼图”放对位置，连带着周围的人都跟着正了，这事儿才算真正顺了。