在理解了公司战略后，研发也应该有自己的战略。这个战略就比较具体了，可以体现为研发管理的前提条件、核心工作、其他工作三个部分：

1. 前提条件。包括对公司战略的理解、建立领导力和文化。
2. 核心工作。有包括技术、人才、生产（售前、产品/项目）。
3. 其他工作。主要是公司层面（经营域、研发域、支撑域）的组织协同。

这篇文章会着重讲我认为应该干的事情还有做事的框架。尽量克制不写问题以及具体场景的处理，那些是下一篇要讲的。

2.1. 前提条件

2.1.1. 公司战略的理解

一个公司可能有愿景，也可能没有愿景，有愿景的可能是真的也可能是假的。但不管愿景如何，一定应该有战略。而研发要做的首先是理解这个战略，接受这个战略。如果认为有问题，应该与公司不断沟通，直至达成一致。如果开始这一关都貌合神离，那后面的工作一定做不好。

公司的战略，其实就是确定大方向，确定我们卖什么东西挣什么钱，不卖什么东西不挣什么钱。举几个栗子：

• 我们是软件公司、房地产公司、投资公司，还是什么挣钱就干什么？
• 我们是只做某种产品，只钻某个行业，还是专门卖人头？
• 我们打算花（浪费）多少钱花（容忍）多少时间去完成一个新产品的研发或者战略转型？

所有的技术管理规划、策略都应该以公司战略为原点去延伸，如果没有那个原点，就无法判断在什么阶段，什么样的技术管理的规划策略才相对更合适。一定要深度解读公司战略，与高层有充分的沟通。做技术管理规划在外包的公司和互联网公司肯定不同。什么样的公司，需要什么样的战略；什么样的战略，需要什么样的管理；什么样的管理，需要什么样的资源和什么样的支撑。

2.1.3. 建立领导力和文化

这个话题太大，讲述的文章和书籍也很多，这里就先不展开了，只说三点：

1. 领导力和文化是同一个山峰的两侧 很难想象一家称得上有文化的公司，其leader是缺乏影响力的，反之亦然。

2. 领导力是产生文化的第二要素 产生文化的第一要素应该是创始人的愿景，当然很多公司的愿景都是发展起来后出于marketing的需要追加的，更多的公司根本没有愿景。为什么要把这一条放上来？因为第一要素中创始人/公司高层，他们的眼界与决策将决定公司是否有建立领导力的土壤。

3. 建立技术领导力不是搞小团体占山头。 这句话即是说给老板听的，也是说给技术领导者说的。

以史为鉴，历朝历代的太祖对于将帅的态度和处置方式，往往是在打江山的时候一个样，在打下江山时一个样；在有外部危机来临时一个样，在外部危机解除时又一个样。技术领导力与文化是卓越组织的特质，只是对于权利欲望特别强的老板来说，“我要控制”才是第一位的。所以组织想要走向卓越，老板的胸襟最重要。

有欲望的可能不仅仅是老板，技术域的负责人可能也会有。既然我自己也能干，为什么不自己去做？所以老板的担心也是可以理解的。但这个事情应该分两层来看。首先，市场经济，自由竞争，老板人为阻拦挡得了一时，挡不了一世。除了阻挠，其实还有很多更好的选择。其次，技术是为了支撑业务，技术领导力的建立同样应该围绕这点。如果技术领导者的行为对组织健康发展无益甚至有害，那这种行为无益是错误的。

2.2. 核心工作

2.2.1. 技术战略/管理

1. 明确技术路线

这里的技术路线是指公司应该持有的技术能力和技术栈。这看起来可能是个伪命题，因为有人会说技术日新月异，也有人会说用什么技术要看是什么场景等等。但我认为明确的技术路线是有很大好处的，这个好处稍后再说，先说一说我认为的技术路线应该包含什么。

组织级的技术路线定义，应该包含若干条技术栈定义，每条技术栈上挂着的，是与之相关联的具体技术。以上是技术栈定义核心部分。在二维的核心部分之外，其实还有第三维，也是关键的一维，就是生成技术栈的根源，也就是业务。为什么需要这样的技术栈？这种技术栈面向什么业务，能形成什么解决方案或者产品？相关的技术趋势是什么？在核心部分之外，从技术栈中的具体技术上，还可以延伸出来知识库，以应对不同的工作主题，如技术科研、培训、人才发展、招聘支撑等等。

现在可以说一下明确技术路线有什么好处了：

一方面，技术是完成公司战略落地的工具。一家公司的战略不可能是经常变的，技术作为完成战略落地的工具，必须成为一个更具象的体现才有落地执行的可能，才能够被测量。如果你是赵家庄的雷主任，那你肯定知道你主要的技术是埋各种雷而不是使用迫击炮。在这个例子里，选择玩雷而不是玩炮就是技术路线。

另一方面，技术路线是人才战略的必要条件。主要体现在对人才发展和招聘支撑上面。清晰的职业发展规划与可保障质量的技术面试都依赖于技术路线以及对应知识库的明确。其实，知识库可以是技术团队周五下午自由支配时间的集体活动产出，也可以是面试时的备选题库。

如此这样看，就会明白，技术路线并不是一个空泛的概念，而是能与业务、人力资源有机结合成一个管理铁三角。与业务发展需求、人力资源管理需求一致，同样遵循PDCA法则。

2. 技术积累与传播

每个人在自身实践的过程中，都会产生各种积累，这些积累存在于我们的脑海里，形成经验，对未来自身的工作带来帮助（某种程度也是限制）。

个体技术的积累转化为生产力是需要大量时间的，但这种时间是必须付出的，并不是浪费。但是如果从个体上升到组织层次，或者哪怕在个体之间来看，这种时间是有浪费的，如何减少这种浪费，以带来更高的生产力，才是技术积累与传播的价值与意义。

卓越的公司一定会有一套行之有效的技术积累与传播机制。当然，这不代表我们在内网建立一个知识库然后号召所有人都上来写文章上传资料就可以解决的。遗憾的是，很多公司都是这个思路。

2.2.2. 人才战略/管理

2.2.2.1. 如何面对研发人员

1. 坦诚相待

这点最简单，也最难做到。和技术人相处其实很简单，不需要太怎么管，只要理一理就好了。坦诚相待，是最基本的尊重，也是发挥1+1>2的基础。

什么叫坦诚？不要总是给同事讲你自己都不相信的事情，而要告诉他们你真实的期望。什么样算是到位了？当他们不痛快，甚至想离职，甚至已经决定离职了，他会提前告诉你，并且把手头的事情做完交接好再离开，甚至，一直等到项目结束的时候。

2. 心里装着这些平时撑着你的人

关心一个人，不仅仅是嘘寒问暖，更要帮助他们做得更好，让他们感觉到成长的烦恼与快乐。不要把工作一布置就当甩手掌柜，而要脑子里要有完整的认知这个事情该怎么做，要让同事们知道你能确定事情的目标，你能辅助/带领他们找到达成的关键路径，你会关注他们最终的结果，你会在过程当中基于他们实际的支持。

3. 还有很多……

真的还有很多，这里就不多说了。心里有，就会有办法。

2.2.2.2. 建立有效、完整的技术族职业发展通道

为什么需要输出公司级的（管理族、技术族）职业发展通道？

1. 对公司来讲。通道意味着公司当前或者未来要追求的人力资源体系结构。没有这个规划，说明公司没有人才战略，不是真的重视人才。也不知道自己面对的业务需要什么样的人，需要多少人。
2. 对个人来讲。这可以让人清楚的知道自己在公司什么位置，还能走到哪里。比如现在很多人在关注敏捷，但敏捷在组织中应该如何推广呢？如何定义敏捷参与者在公司的角色？他们未来的发展在哪里？这都要靠职业发展通道的定义。

2.2.2.3. 招聘规划

我一直觉得，招聘可以体现出一家公司的水平。遗憾的是，我接触过的（包括听其他人描述的）很多公司，招聘面试都很烂。这部分不打算列123了，想换个说法，讲讲故事~

故事1 如果你看一家公司在招聘项目经理或者架构师，但是火急火燎要你入职，那可能这家公司就是有点问题（有问题不代表一定不能去）。对于项目经理、架构等等这样沟通渠道多、专业能力强的岗位，都不能做到提前3个月招聘，那说明这家公司要么没有任何规划控制能力；要么是个挣块钱的公司；当然还有一种可能，就是上一任跑路了现在需要人来填坑。

故事2 如果你有过投简历过着面试的经验，那很有可能有遇到过接电话时HR弄错你的应聘岗位（比如你明明是前端而她要找的是java）让你过来面试，接着你到公司面试时面试官问的问题都奇奇怪怪，要么像发情的孔雀拼命像你展示他才是最牛逼的你不行，要么一上来让你把你简历上都有的个人情况再说一遍，还有可能问的问题完全太easy以至于你都怀疑他懂不懂问你的这些东西（很有可能是只听过一个名词）。这都是有可能的。因为可能从你到达要面试的公司到面试官过来的1个小时内，HR去随机找了一个看起来能面试你的人，当发现面试官A不在、面试官B在开会、面试官C正在给其他不知道要到哪个部门去工作的人做面试时，无奈找了高级程序员D。可惜高级程序员D并不高级，他只是高龄，恰好他手里还有一个开发任务已经拖了3天，还正在百度，HRMM来找又不好拒绝，只好随便面面。当辗转一圈后，你其实都不知道真正用人部门的人并不是你的面试官。高级程序员D在拿到简历后直接去做了面试，并没有问这是一个什么岗位，有什么要求。整个面试过程平淡而无聊，10分钟之后面试结束。HR这时会向面试官索要面试的意见，面试人可能被认为合格，也可能被认为不合格，不过那些都不是最重要的，最重要的是价格合适。

你一定能在两个故事中看到很多问题，比如没有公司没有人力资源规划、HR没有安排好面试、面试官的管理混乱、没有明确的评判体系等等等等。这样两个故事场景其实就在你身边，它不遥远。容忍就是犯罪。技术管理者应该去推动变革。

2.2.3. 生产管理

2.2.3.1. 研发体制管理

组织、流程、制度、人员是研发体制所关注的重点。这里每一个点都有很多讨论和案例。不管怎么管理，明确目标是头脑，组织体制是骨架，流程制度是血脉，人员是手臂和手臂。只想强调一点，人，特别是技术人，绝对不是资源设备，那只是成本，会折损的。人可以创造，可以发挥更大的价值，他是利润。

2.2.3.2. 组织级售前/项目/产品管理

首先是售前。售前不等于收集材料制作PPT。售前要多跟销售、跟客户走在一起。了解行业的最新趋势。没有相应的市场机会是销售的事情，但能不能做得来，怎么做，能不能与已有的成果产生聚集效应，这是售前应该考虑的事情，而且要不断PDCA做重构。

项目与产品的过程类似，都是规划、营销、研发、监控、投产、总结、传播、PDCA。组织级的项目管理可以做投入产出分析、经验总结；给项目经理、产品经理提供工具箱、案例库；给售前提供最前沿的武器和最新鲜的血液。

2.3. 其他必要工作

2.3.1. 组织协同管理

研发需要跟营销协同？营销拿下项目需要研发的支撑，项目拿下来往往就不管了，有事情全摔锅给研发。太多的例子证明，很多时候问题的根源其实是在当初那个合同签的就不对。合同不对条款苛刻当然不一定就是营销的问题，也有可能是客户更有主动权，也有可能项目本身不是为了赚钱。但无论如何，既然签了，事情就需要大家一起来解决。

研发需要跟支持（财务、后勤、综合管理）协同？如果一个项目组研发任务非常重，还要为了一次临时出差的一张机票左打申请右打申请，笔记本电脑求爷爷告奶奶一周都申请不下来，出差一个月回来还要一张一张的贴发票，把战士的战斗力都浪费到这些地方，仗怎么打？

营销，是给老板赚钱的人，研发（被认为）是花老板钱的人，花多少钱甭管该不该花都会肉疼，赚钱即使是苍蝇蚊子腿那也是肉，亲疏远近天生如此。公司在小的时候，支撑部门就是支撑部门，大了以后，支撑部门往往就变成大爷部门了。PMBOK里给这些里里外外乱七八糟的事情放到一起起了个委婉的的叫法，叫做“事业环境因素”。

研发管理必须能认清事业环境因素，在可能的情况下，尽量减少这些因素对研发造成的负面影响，最好能通过有效调动起前锋和后场，共同努力赢得比赛，这样才是一个优秀的中场核心。

2.4. 最重要的事

PDCA。只有PDCA才能保障体系持续更新，跟上最新的形势。体系的背后是认知，一个技术领导者的认知，应该超越他下面的那个群体，只有这样，才能走得更远。