一、先看个职场难题再买火车票
两年前做过一家大型IT公司的项目，闲暇时对方一个技术大牛老曹跟我吐槽：他写代码的能力在公司是绝对的“顶尖”，堪称公司的一面旗帜，也备受圈中人追捧。可当开发主管好几年了，却一直都得不到升迁。
“团队里的小孩儿，要么太笨，要么太懒，要么不听话，写的程序都不怎么行，只能我亲自来。你说我比任何人加班都多，天天累死累活，升迁居然还没有我的份！老板瞎了吗！”我依然记得老曹当时相当不忿的语气！
当时我不知道应该跟老曹说啥，就陪着呵呵了几声（现在想起来非常地汗颜，给咨询顾问们丢脸了）。不过入职YouCore工作两年后的今天，我突然发现如果时光可以倒流的话，我很想对老曹说一句话：“曹哥，不是老板瞎了，也不是你不行，而是你最本能的工作方法层次低了！”
老曹长期从事编程工作，每天主要处理的就是业务部门抛过来的技术难题或软件冒出来的疑难Bug，因此他所形成的工作方法重点是快速处理问题（越快越好），而非发现问题。
老曹形成的这套工作方法在他作为程序员单干时，是非常有效的，因此当他去干其它事情（比如带团队）他依然会不自觉地使用这套他已经形成本能的方法。
对比以上两种工作模式，你会发现它们在本质上是一致的：
被动地接收问题。编程时是被动接收业务部门提出的问题或软件自动冒出的问题；管开发团队时是下属已经发生的延迟或错误。
工作方法确实没变，但结果却大相径庭：老曹“华丽”地从技术大牛转为了管理菜鸟！那么，老曹“以不变应万变”的做法错了吗？肯定不是！
从释迦牟尼到星云大师、从孔子到王阳明、从爱因斯坦到霍金，古今中外的宗教法师、儒家泰斗、物理大师毕生都是在追求宇宙的根本规律，也就是可“以不变应万变”的“道”。因此，老曹“以不变应万变”的思路没错，但“不变”的内容错了。大师们用贴近一般规律的“法”或“道”来应对变幻万千的世界，而老曹用的是仅适用于程序员的“术”来应对变化后的管理工作，方法的层次低了。
三、买张火车票感受下高层次的工作方法
那么老曹可以通过啥不变的“灵丹妙药”从技术大牛转身为管理大牛呢？
咳咳，“药”来了，就是《思维力：高效的系统思维》一书中给出的“用框架解决问题五步法”，先让我们帮领导订张火车票感受下这套五步法：
步骤一 界定问题
领导让你帮忙订一张火车票，作为一名合格的助理你的第一反应绝对不会是动手去买，而是至少先问清楚领导要买去哪儿的，什么时间的，高铁、动车还是普通火车，接受的价位范围是怎样的等等。若是你伺候领导的经验够丰富，你还应该问清楚什么档次的票（商务座、一等座、二等座？软卧？硬卧下铺、中铺、上铺？）、是否要安排车接送、还有没有人同行等，甚至还要从侧面了解下领导这次为何坐火车去（终于知道当好行政助理也不容易吧）。
步骤二 构建框架
还是继续扮演助理买车票吧。假设经过第一步界定问题后，你明确出需求是买一张本周六从深圳到武汉的高铁一等票，那是不是立即到12306网上订票呢？如果你想干好助理，那么还是乖乖跟着我先构建一个框架明确有哪些可以买票的方法吧。
有同学可能有疑问，买个破票难不成还要画个逻辑树？！呃，其实以上这个框架在脑子里画出来就行，只是如果我不显性地画在纸上，你也看不到我在想啥啊。
步骤三 筛选关键
这么多订票渠道，你当然要做好筛选啦。怎么筛选呢？一般情况下，用80/20法则选出只要花20%精力、时间、资源就能起到80%效果的办法就行啦，不过这个案例在筛选上会更复杂些，至少要统筹考虑公司规定、领导喜好、购票效率、价格、可靠性等。
公司规定、购票效率、价格这些硬条件都好办，但像领导喜好这些软因素就要你平时多观察、多积累了。譬如，公司楼下有个火车票的小小代售点，价格高、出票慢、服务态度还不咋滴，该不该选择呢？啊啊啊，我不能再说了，再说就不符合社会主义价值观啦，扔个波士顿矩阵，你自行琢磨去吧！
哎，这么经典的波士顿矩阵被我胡诌成买票筛选大法，你说那些凭此工具将几张PPT卖到几百、上千万的咨询顾问们会不会有掐我脖子的冲动呢？
步骤四 高效执行
这个步骤最关键的就是怎么在合理的时间内，以预算的价钱（钱花得太少有时也是种罪），买到一张（不是两张）真票（不能过期、也不能假）。是不是有点眼熟啊？对了！就是项目管理里的范围（一张票）、时间、成本和质量（真票）四个要素。
辣么神奇的项目管理原来也就买了张火车票，自诩高大上的项目经理们是不是有点不忿呢（这篇文章是要将圈内人得罪光的节奏啊）。
步骤五 检查调整
其实这个过程就是PDCA中的C（check，检查）和A（Action，调整）了。绝大多数人拟个P（Plan，计划）没问题，D（Do，执行）是肯定要干的，但很多时候就是一个P、一个D就完事了，至于是否按Plan来Do、Do得怎么样就不管了，因此同样的事（譬如买票）重复了千遍、万遍，还是那个熟悉的P味、那个熟悉的D样。
好了，以上就是一个完整的“用框架解决问题五步法”了，从界定问题开始（发现问题），到构建框架、筛选关键（分析问题），最后高效执行、检查调整（解决问题）。
火车票买完了，赶紧回来用同样的方法帮老曹升个职吧。还是五步：
步骤一 界定问题
- 为什么老曹会升不上去呢？——因为老曹团队的绩效差。
- 为什么老曹团队的绩效差呢？——因为团队的整体能力上不来。
- 为什么老曹团队的整体能力上不来呢？——因为老曹总是直接代替下属去写代码。
- 为什么老曹会直接代替下属去写代码呢？——因为老曹不知道管理者应该更多辅导下属去做。
- 为什么老曹不知道管理者应该更多地辅导下属去做呢？——因为老曹不知道管理者应有的能力模型。
问题找到了，既然老曹不知道管理者应有的能力模型，那他自然不知道自己的能力差距，也就自然不会在工作中采用正确的管理办法来弥补。因此，我们要做的就是帮老曹构建出管理者的能力模型，找到关键差距，再出具对策。
步骤二 构建框架
不急！“不要重新发明车轮”，既然别人都开发出那么多优秀的框架了，我们直接套一个呗，就用拉姆·查兰的领导梯队模型吧。
根据以上模型，老曹目前处于第一阶段转型，他若想往上再升一级就必须先成功完成第一阶段转型，领导梯队定位明确后我们就可以用拉姆·查兰给出的第一阶段管理者的能力框架给老曹把把脉了。
有了能力模型，老曹就十分清晰地知道作为开发主管需要具备哪些能力，也能清晰地认识到自己各个能力维度的差距了。
步骤三 筛选关键
从老曹碰到的最大困境来看就是团队能力上不来，而主要原因就是老曹代替下属写代码，而不是指导他们写代码了，因此他最需要优先改进的就是下面三项用红色虚线框标出的能力。
步骤四 高效执行
不过有一点提醒，虽然我们反复强调要对下属进行教练辅导、尽量指导下属而不是代替下属写代码，但也要分清楚工作的轻重缓急以及分配给下属的任务是一次性还是反复性的，若是任务很急或者该任务是一次性的，那适当地自己动手写代码也是必要的。
步骤五 检查调整
看，掌握了更贴近一般规律的工作方法——“用框架解决问题五步法”，老曹就可顺利从技术大牛升级为管理大牛了。
再次温馨提醒你好好回顾下“用框架解决问题五步法”的内容：
【步骤1 界定问题】→【步骤2 构建框架】→【步骤3 明晰关键】→【步骤4 高效执行】→【步骤5 检查调整】。
作者：李青霈
去年今日运营文章
- 2023: 3F倾听模型：沟通从倾听开始(0)
- 2023: 桃园三章用户运营方法论(0)
- 2023: 商业模式画布—构建商业模式的有力工具(0)
- 2022: 如何打造爆款单品？小红书品牌营销全链路解决方案来了(0)
- 2022: 打破实体门店经营困局，邦伲德共享商圈帮你找到出路(0)
原创文章，作者：爱运营，如若转载，请注明出处：https://www.iyunying.org/zha/97140.html
