|
这是芃篙君的第27篇原创 本文大概2600字，阅读需要8分钟。 一般在人数上规模的公司中，组织结构层级化是不可避免的。这时候就有头部、腰部和腿部的说法，大概对应着战略、战术和执行几个层次。领导层会综合根据公司的情况和对市场行情的判断，定义公司战略，可能是永久的，也可能是阶段性的，各个下属团队再根据自己团队负责的板块，结合战略方向拆解成对应的执行计划。关于一线团队管理者对公司战略的拆解，芃篙经历过一段比较痛苦的转型之后，大概有那么一点感受，理解的不一定透彻，还请大家指正。 01. 谁需要拆解战略规划 前面说过，常规的设定是战略通过逐层拆解，最后形成具体的执行计划，那么各层级的管理者肯定是需要做战略相关的拆解的。所谓“拆解”有两个方向的结果。其一是对战略方向的理解之后，结合自己团队的业务情况，细化出具体的团队运作原则，作为日常做业务的决策支撑；其二是根据战略方向的要求，具化出团队业务的理想目标，根据目标制定阶段性的规划。假如再细化到是技术团队的话，技术团队的季度或者半年规划，一方面取决于其支撑的业务团队的产品或者项目规划；另一方面是技术团队自己基于软件产物现状和战略指引来制定技术上的演进规划。同时管理者根据公司在不同阶段的需要，决定在两个方向的人力投入比例。所以对管理者来说，拆解战略是职责所在、必须要做的事。 芃篙却认为，员工也需要去尝试理解战略的拆解过程。有一位大佬曾经说过，大多数人的成长路线应该是“员工-->管理者-->创业者”，从功利的角度讲，抓住机会尝试去看看下一个阶段的思考模式、做事方法是有必要的。可能有人会觉得我一个打工人没有那么多信息源，直属老板也没跟我说一定要怎样怎样，不好下手。但实际上团队无论是使用OKR或者KPI这种标准工具，还是野路子直接给员工安排项目或者技术任务，具体动作最终还是会传达到执行层的。即便不从长期的成长看，短期上来讲，作为任务执行者，不满足于“知其然”，也应该要“知其所以然”，这样才能让任务执行的恰到好处，不会偏离航线。 并且，合格的管理者需要把整个逻辑链条给员工讲清楚，员工也可以通过信息整合找出自己的理解。更好的方式是最终的计划是上下结合起来制定的，这就要求执行团队对战略方向有较为一致的理解，共同为终端规划负责。孙子曰：“上下同欲者胜”，多多少少有那么一点儿意思。 02. 拆解战略规划的基础 员工的视角毕竟没有那么全面，从拆解本身来说，管理者想要做到比较好的战略拆解，大概需要具备两个基础要素。 其一，向上要理解战略。战略指引往往是抽象的，是难以理解的。得先搞清楚题干，才有机会正确解题。当然更高层的管理者也应该把战略意图阐述得清楚明白，不要云山雾罩，让下级茫然猜测。可能现实情况是中间层充斥着不少混日子的管理者，既无法理解上级提出的战略，又不愿意暴露出来，再向下拆解时就十分晦涩。这个时候员工就非常难受了。 其二，向下要了解执行层的现状，包含人与事。人自然是团队成员的任务分配和能力情况；事则既要包含业务上的规划和技术上的现状。把抽象的战略方向具像化到要做什么事，这两者缺一不可。 这样讲似乎有点抽象，我们不妨来举个例子。 03. 举个例子 借用鹅厂大佬年初提的一句话作为要拆解的战略：“不做集成商，做好被集成的角色”。 再做个假设吧，芃篙现在是一个基础技术团队的管理者，负责支持几个业务线的常规产品迭代，和客户服务部门的基于基线产品的定制项目。 （1）理解战略 这个时候不建议做八股文，去把这句话做逐字逐句的拆解研究，正常情况下，老板应该在各种战略会或者其他场合讲清楚为什么这么制定。即便没有其他常规渠道，还不如直接找老板搞清楚前因后果。毕竟大家都是为了公司往更好的方向发展，只要不涉及经营机密，也不会藏着掖着。 假如经过了充分的沟通和理解，“不做集成商，做好被集成的角色”，讲的是过去几年公司的业务中做了很多总包项目，除了集成公司的标准基线软件产品之外，也根据客户要求，集成了很多三方厂家的产品。类似总包的项目，在有限的资源下，能够完成的数量是有限的，并且每个客户要求都不一致，没有办法批量复制。并且看起来总包的项目金额巨大，但是对应的研发投入成本也不小，整体算下来盈利水平已不符合现阶段公司的要求。所以公司在战略方向上，号召大家尽量“被集成”，这样更容易规模化复制，对于软件产品而言，规模化之后研发维护成本反而会降低，这样符合软件的基本特性。 好的，那么接下来，就要结合团队的情况分析。 （2）分析现状，找到警惕点和差距点 了解了前因后果，那就更容易察觉症状。 警惕点是什么，就是找到看起来不太符合战略方向的业务流。很明显定制项目可能不是推荐的业务模式，但是此时不建议高举战略大旗，直接否决这条业务链路。而是应该跟相关的前线团队一起找优化方案，客户是把我们当成集成商，还是单纯的基线产品无法满足需求；不同客户之间是否存在相同的群体特征，客户之间的目标是否存在相似性等等。 差距点是什么，就是目前我们的软件架构、人员储备跟战略方向要求的状态是否有差距。这也需要结合业务上的警惕点来综合看，对应的技术上我们的架构是否有足够的可扩展性和可修改性来满足不同客户的需要等等。 （3）制定规则和规划 经过分析，就可以有针对性地做出具体的拆解了。 比如我们可以根据过往项目数据和客户数据，分析出具体什么样的客户项目可以接，什么样的客户项目应该找外部集成商接，什么样的客户项目不能接。定义对应的项目流转规则，保证项目可以按照规则消化。 比如我们可以根据过往的项目代码实现情况来反推目前的架构需求，同时制定新的架构衡量标准，把更好的扩展性提高判定优先级。是否可以通过配置管理的方式消解定制需求，或者通过引入跨端技术栈的方式降低定制成本或者增加可开放的能力，提高集成商承接总包类型项目的可能性等等。同时根据人力排兵布阵的情况，和团队整体投入的比例要求，定义季度性的技术演进计划。 拆解战略是一个从务虚到务实的过程，也从来都不是一个非零即一的开关型思维来落地的事情。从战略定义到具体业务发展产生影响，可能存在一定的时间和空间要求。这需要广大执行层团队在不断摸索中跟头腰部形成良性的沟通，不断对齐思想、克服困难、共同演进和落地。 ----关注芃篙君⬇️，循序渐进，不负光阴---- |
|
|
