核心做法是:把“结论”和“结论成立的条件”写在同一段里,并且优先保留那些一旦缺失就会让结论反转的限制。向非技术同事讲解时,不要先讲完整原理再补条件,而是先给一个可执行的最小动作,再明确说出这个动作不能推出什么。下面用两种条件展开,说明何时该展开细节、何时该只保留边界。
如果非技术同事的任务是批准、排期或分配人手,他不需要理解实现细节,但必须知道哪些前提不能动。此时把限制压缩成“只要……就……;如果……则不适用”的句式,比列一堆术语更有效。
例如你在搭建个人博客教程里遇到一个具体问题:同事问“能不能把文章批量导入”。你可以回答:“只要来源文件的字段和现有文章结构一一对应,就能批量导入;如果来源里混有草稿和已发布两种状态,就不能直接导入,需要先人工分拣。”这句话里,“字段对应”和“状态单一”就是关键限制,缺一个结论就不成立。
实施动作:讲完后请对方复述一遍他理解的前提。如果他复述出的限制和你说的不一致,说明这句话还没压缩到位,下一步不是继续解释,而是换一个更具体的例子重说。这个动作的结果直接影响下一步——对方能准确复述,你才可以把任务交出去;不能复述,就说明限制还停留在你这边,需要继续拆。
如果非技术同事要自己执行,比如上传图片、填写文章信息、检查页面显示,那么限制不能只停留在口头,而要绑定到他操作的每一步。做法是把限制写成检查项,而不是写成背景说明。
假设一个场景:你让同事帮忙把一篇写好的文章放进博客后台。你可以给出三个检查项:标题是否和正文首行一致;图片是否都已经上传而不是只填了本地路径;发布状态是否仍为草稿。这三项里,任何一项不满足,页面显示就可能和预期不同。这里要明确:检查项通过只能说明这一步没漏,不能证明整篇文章没有问题,因为内容准确性、链接有效性等仍需要另外核对。
实施动作:让对方在操作前先把检查项读一遍,操作后再逐项打勾。结果如何影响下一步?如果三项都通过,你可以让他继续处理下一篇;如果有任何一项没通过,先停下来修正,而不是继续往下做,否则后面返工的成本会更高。
这三类信息不需要每次都全部展开,但只要其中一类缺失会导致结论反转,就必须保留。判断方法很简单:问自己“如果对方不知道这一条,他会不会做出错误动作?”会,就留下;不会,就可以暂时省略。
当你没有完整数据或权限时,仍然可以执行一个最小动作:把已知事实、未知项和假设分开写。已知事实是你能直接确认的,未知项是你暂时查不到的,假设是你为了继续推进而暂时接受的。三者混在一起,非技术同事就会把假设当成事实。
例如在搭建个人博客教程的语境下,你暂时看不到后台的访问统计,只知道页面能正常打开。此时可以执行的最小动作是:先确认页面标题、正文和图片是否显示正常。由此不能推出“文章已经被收录”或“读者能看到这篇文章”,因为显示正常和可被访问是两件事。访问统计归零也可能由统计代码未生效、筛选条件设置过窄、数据延迟等原因造成,不能单独用来证明某个处理一定正确或一定错误。
实施动作:把“已知、未知、假设”三栏写在一张便签上,发给同事之前先自己读一遍。如果发现某一栏里混进了另一栏的内容,就拆开重写。这个动作的结果是:同事能清楚知道哪些结论可以直接用,哪些还需要等数据或权限补齐后再判断。下一步该做什么,也就自然清楚了。
有一种例外情况:对方已经知道背景,或者只负责传递信息,明确表示不需要细节。这时仍然要保留限制,但可以换一种方式——把限制放在结论后面,用一句话带过,而不是展开成段落。比如“可以按这个方式处理,前提是来源文件格式不变;格式一变就要重新确认。”这样既没有增加理解负担,也没有把关键限制丢掉。
如果对方连这一句都不想听,那就把限制写进你交付的文档或消息里,让他需要时能查到。保留限制不等于每次都要口头强调,而是确保限制在信息传递过程中没有消失。只要限制还在,后续有人接手时就不会因为缺少前提而做出错误判断。