小问题背后的大逻辑

小问题背后的大逻辑

马上要开外部方案评审会议，问一负责的同事会议准备如何？有没有checklist？

答曰：以前的老套路，相关人都知道做什么？

好像没有什么毛病，但我总感觉不放心。

我建议列出checklist。包括有哪些事项、谁负责、完成标准、完成时间、注意事项、是否存在风险等等？然后逐项检查打√。毕竟涉及到几十家外部单位，有十几项工作要落地，多位人员协同。一旦出点差错也会比较麻烦，也可能会忙中出错。

虽然最终这位同事输出了这份checklist，但其实不太乐意。认为以前都是这么做的，不会出什么问题，觉得我有点"小题大作"。

看了这份checklist，心里才有了一点点把握。

这只是一个案例，普遍现象是：很多过往经验储存在自己的最强大脑中，大部分情况下都只是口口相传。

一直很崇尚通过现象看本质，小问题背后也许隐藏着大隐患。

下面通过亲历的一些具体现象，简单思考小问题背后的大逻辑：

来公司一年多通过不停地与客户接触、向同事请教、自己总结等方式，才慢慢了解客户的组织结构。但没看到文档说明。

背后的逻辑：客户组织结构决定了业务方向和组织结构，只有深入了解客户，才能够更好把握产品战略和市场策略。

由于行业特点，需要组织各类评审会议，不同阶段会议要求也有差异。但没看到checklist。

背后的逻辑：没有人保证不犯错，尤其面临复杂问题的情况下，只有分解成一系列简单的任务，才能够万无一失。推荐《清单革命》。

财务抱怨业务没有遵循财务规范，业务说没看到财务对业务有哪些规范要求，财务说业务应该知道基本的财务原则。但没有看到发布的原则和规范要求。

背后的逻辑：很多情况下都是你以为我知道，最后的结果也就停留在“你以为我知道”的状态。

项目经理跟总监说月初已经把计划知会给大家了，过程没有监控，最后期限才发现进度延迟或需求不满足。

背后的逻辑：每个人都有自己的优先级，如果缺少过程监控与闭环，项目管理就会失去意义。

市场经理说这事交给他放一百个心，轰轰烈烈发个誓听起来很激动，中间也没进度和状态反馈，最后成不成往往靠运气。

背后的逻辑：及时反馈工作状态，暴露问题和风险，并制定规避措施，才能够成为一个“靠谱”的人，真正做到让领导放心。

研发上次解决了项目A的一个问题，这次项目B又出现了，顾此失彼。

背后的逻辑：发现一个问题解决一类问题是正确做事的方式，要善于发现问题背后的本质。譬如一个问题背后可能是产品架构问题、或是流程问题、或是工作态度问题等等，针对根本问题对症下药才会形成良性循环。如果总处于发现一个问题解决一个问题，甚至会引入新的问题。那只是在被动干活，缺少主动思考，工作甚至生活往往都是处于被动和被撕裂的。

测试说功能已经实现，只是操作的方式跟正常思维或常规方式不一样，测试通过但客户却不会用，产品留下诟病。

背后的逻辑：研发闭门造车或者盲目创新都是不可取的。作为产品的最后一道关，
测试更应该从客户视角思考，培养同理心。

……

每一个问题表面上看都是小问题，背后的逻辑看似“小题大作”。但挖掘小问题背后真正的根因，直达问题本质是必要的。

本质上这是一种思维方式，只要不把简单的事情搞复杂，能把复杂问题简单化，小题大作又如何？