我的产品发布了：CEO数字分身，让CEO分身有术，有意者联系。
关注公众号回复1，获取高清管理路线图
之前为某100人规模团队做某产品深度咨询过程中，老板一再强调职能线的Leader必须了解业务、了解产品，只有熟悉业务，才能真实的做好团队赋能。
这是一个非常正确的观点，于是老板开始带着HR、财务负责人，持续参加产品研讨会，但实际的效果却不太好：
HR财务虽然表面上很用心，但私下是一点时间都不想投入，最终结果自然就不了了之了。
其实，这里老板带着HR、财务去了解业务，甚至直接参与到了产研的执行细节之中，是很值得玩味的。
如果认为仅仅认为老板真的想让HR或财务给大家送温暖，那就太年轻了！
因为从HR与财务部门的属性来说，他们在公司里面主要就是一个监督和兜底的作用。严格来说，他们都是CEO监管团队的能力延伸：
HR需要确定项目组有无人在摸鱼，这属于人员方面的浪费； 财务部门需要对项目组的所有款项做确认，这属于费用方面的浪费；
所以，老板让他们了解业务、熟悉产品，其真实用意是更好的评价团队效能、降低费用浪费。
但想法总是好的，真实的世界往往不会按你想象的来，于是实际的情况确实也是HR与财务一直在假装努力。
所以后续对于产研的产出，HR依旧没有基本的判断力，他只能依靠是否加班进行粗暴的判断；
财务对提交上来的采购单据，依旧只能以三方比价的土办法来规避风险；
因为他们对此毫无判断力，他们只能假装努力，假装在乎，以规避责任，因为他们确实没办法，他们是真的不懂，也不想花功夫去懂啊！
那么什么是懂呢？
什么是懂？
前几天我丢了一个客户关于项目经理的招聘信息在群里。
有眼尖的同学发现一个情况：JD对项目经理的要求不包含懂技术，于是就热闹起来了。
有同学马上吐槽：不懂技术的项目经理比较招研发烦，因为他听不懂技术在说什么；
其次他们分不清楚客户到底是需求还是许愿，总是一股脑的用客户要求作为鞭子，而产品沟通下来又发现根本不是那回事，于是项目经理就显得非常业余。
于是话题开始衍生：不懂技术能做CTO吗？
对此，有些同学认为可以，有些同学认为不可以。但马上有2个同学打破了僵持：实际上已经有2个产品成为CTO的真实案例，并且他们还做得挺好的！
所以结论是：不懂代码也能做CTO，因为懂技术和懂代码完全是两回事，比如：
前端同学往往不会后端代码； 后端同学会对Native代码感到陌生； 就算有全栈高手，面对新出的AI技术，依旧需要再学习；
所以就算技术出身的CTO，也不见得对技术有全面的认识。
而全栈技术本来就很难，花大量时间成为专家，但管理能力不行，业务理解跟不上，这种人是很难成为CTO的。
综上，不能以懂代码作为懂技术的衡量标准，那么应该用什么作为懂的衡量标准呢？
我认为面对一件事情/任务的时候，有三点要思考：
对于这个问题已经提出的动作，或者完成的工作，能不能提出问题。很多人对这个事情/任务毫无概念，连最基本的问题都提不出来； 提出正确的问题是为了引导负责人思考，这需要我们对事情/任务有好坏的标准的基本认知，也就是知道什么是好坏； 最后，如果这个任务有问题，你是否具备指导的能力；
比如，大家遇到一个问题，有几点可以看出我们对问题是不是清晰：
第一，我们能不能对问题提出清晰的观点，有观点才有认知； 第二，对于我们提出的观点，我们是否有足够的论据，或者知道要找什么论据，进一步去哪里找； 第三，有其他同学提出了我们没想到的论据，我们能否判断这个论据的真假，以及与我们的论点是否有直接的关系； 最后，有些论据不完善，我们是否有能力进一步去完善他；
所以，什么是懂（一件事/一个任务）？
首先，你对这件事/任务会有一个清晰的衡量标准，你能明确定义他的好坏，并且这个好坏能被专业的人所认可；
其次，你的衡量标准是可衡量、可进一步拆分的，甚至可以形成一个判断模型；
然后，对于一个已经存在的任务，你能根据衡量标准，清晰的指出他哪里有问题；对于一个需求去完成的任务，你能毒辣的指出，他哪些部分是多余的，不需要做的！
最后，对于那些有问题的部分，你能提出进一步的优化建议。
综上，你如果对一件事有标准、能揪出问题，有修改意见，对于这件事毫无疑问你是懂的！
结语
其实，“懂”也是分层次的，对于HR与财务来说，对业务只要有基本判断的标准，能找出明显的问题，其实已经是不小的进步了。
只不过，对于他们来说这很难，因为这需要他们打破本身舒适区，真正的去“学会这件事”，但对他们的认知防御体系来说，“花精力学习不需要的知识”是个错误的决策。
跟进一步，“懂”是一种深入的认知，它不仅意味着掌握知识或技能，还包含一种整体把握、深度解析和灵活运用的能力。
懂的层次感
真正的“懂”包含三个层次：
洞悉本质：不仅要知道事情的表象，还要深入理解其内在逻辑和核心原则，能区分真伪、判断好坏，明确标准。 系统视角：在更广阔的框架中看待问题，将其置于整体中，理解上下游环节的关系，能看到任务对系统的影响及其长远价值。 智慧行动：基于深刻理解，灵活应对环境变化，精准调整策略，并提出建设性意见和可行性改进措施。
真正的“懂”是知识、判断与执行的融合，使你不仅知其然，更知其所以然，进而知其能如何推动变革。
最后，我们用之前的经典案例做结：
某天，线上有个BUG，前端可以解决，于是后端认为是前端的问题；后端也可以解决，于是前端认为是后端的问题。
两个同学一步不让，10分钟代码的事，扯了一个小时，两人相持不下，开始上升问题。双方Leader介入，并开始为自己的组员据理力争，于是10分钟的事情4个人拉扯了一天...
一线员工视角：应对层次的“懂”
对于一线员工来说，“懂”在这个层面主要是对工作分工和个人责任的理解。
这种理解多局限在表面的职责划分上，关注如何完成自己的工作，避免承担不属于自己的责任。
由于缺乏系统性思维，他们未能看到整个团队协作的重要性，反而陷入了情绪化的争执。
这种“懂”仍处在较浅的层次，是一种单点式的认知。
经理视角：协调层次的“懂”
作为经理，理解的层次升级了，他们需要“懂”得如何维护团队协作的流程顺畅和效率最大化。
在这个层次上，“懂”不只是自己的职能范围，而是要具备跨部门协调的能力，避免矛盾影响团队士气。
两位经理虽然介入了问题，但未能有效解决，反而使问题进一步升级，说明他们缺乏对解决问题优先级的理解和灵活应对的“懂”。
好的经理应当具备及时发现并上抛问题的意识，理解在什么情况下让更高层介入，以保障团队的高效运作。
总监视角：机制层次的“懂”
总监的“懂”已经上升到系统化视角，能够看出背后跨部门协作机制的缺失。
在总监看来，这不仅是一次技术责任的推诿，而是深层的管理结构问题，反映了部门间协作不畅。
此时，总监的“懂”在于通过系统视角识别流程的缺陷，并提出机制改进措施，比如建立明确的分工协议或沟通机制。
这个层面的“懂”强调对系统性问题的把握，避免类似问题重复发生，从而提升团队整体的协作效率。
公司管理层视角：全局层次的“懂”
公司管理层需要在更高的层次上“懂”，他们看到的是企业文化和管理机制对公司效能的影响。
管理层的“懂”体现在如何构建全局性的制度和文化，让员工优先考虑高效解决问题，而不是陷入不必要的拉扯。
他们要“懂”得识别和暴露潜在的管理问题，通过建立规范、培训和文化建设，将结果导向和协作精神融入日常工作。
这种全局层次的“懂”不再关注具体问题的解决，而是以防范机制和文化塑造为目标，减少类似问题的发生。
总结
从一线到公司管理层，每个层次的“懂”逐渐加深，体现了从执行、协调、机制到全局管理的不同理解深度：
一线员工：关注自身分工与责任的界定，浅层的“懂”。 经理：关注团队协作与流程顺畅，需要“懂”得平衡员工之间的矛盾并及时上报问题。 总监：看到跨部门机制的缺陷，系统性的“懂”，对机制改进有清晰认知。 公司管理层：全局的“懂”，关注整体文化和制度建设，追求持续改进和减少问题发生的概率。
好了，今天的分享就到这里，希望你能通过这个案例，认识到懂的层次感。
