请点击上面的“方正柱”，关注我哦????
4月15日，HRBP组织了研发团队的述职；在这次述职中，除了了解大家的业务产出外，也还有一件非常有意义的事情，述职过程中体现出了各个leader目前所处的阶段、遇到的问题。针对他们所在的阶段和遇到的问题，一一给了建议。令人欣慰的是，研发团队的leader都在进步的路上，相信他们在未来的职业之路上，会有很好的提高和发展。
Stage 1:
技术leader一段，个人贡献者or团队贡献者
有两个同学述职时，提到自己在工作里，遇到比较大的困惑；主要的问题，是自己忙不过来，精力不够用。可是也不敢把手头的工作，大胆的放手给团队的其他人，担心其他人接不过来核心的、有困难的、时间紧张的任务。把自己的大部分精力，投入在项目的研发任务攻关上。
仅从上面的情况看，对于爱好技术的人来说，这样对技术工作的付出和努力，并不会让人觉得厌烦和沮丧。让他们感到沮丧的，是自己觉得项目做的不好，对项目中出现的目标不明确、团队合作不顺畅，感到困难和无力解决。从而担心团队的整体产出和持续发展。
这是典型的技术leader把自己当作团队的技术产出主力、其他事辅助的情况，他们个人勤奋、技术好、价值观正；这些技术工作上很优秀的人，如果不能调整自己的工作方法，就会成为团队提升的障碍，在技术leader这个岗位上碰壁，不能在新的岗位上，持续保持优秀。
对项目的目标感到不明确的原因，和团队合作不顺畅的原因，主要都是leader没有完成角色的转换，把代表团队进行对外沟通、对外协作的工作，作为一个重要的工作。沟通和协作是要高成本的投入，尤其是leader的投入；同时也是leader的杠杆作用体现的一个重要方法。
给他们的具体建议，是把技术工作时间的比例，降低到30%以下，大量的专业工作交给团队的成员。其余的时间，主要用来：
澄清目标（一线leader还不用规划目标）
具体任务执行上，对内部成员提供支持和辅导
提高内部人员能力或引进专业更强的人
对外部进行沟通协调。
通过这4个工作，来完成自己由个人贡献者，向团队杠杆作用者的角色转换，成为一个真正意义上的leader：岗位是leader、职责是leader、行为方法是leader。
Stage 2:
技术leader二段，项目管理思维的叠加
做述职后的提问环节里，我问到这一个Q，觉得自己做的比较好的地方是什么时，有4个同学提到“在产品的进度跟进”上，有了比较大的进步，体现在项目交付的时效性更好了。当leader感受到这一点时，在不知不觉中，他们已经意识到项目管理思维的重要了。
项目管理不仅仅是研发进度的跟踪。项目管理是一个成熟的、完成的体系，从需求管理、资源配置、流程管理、风险控制、投入产出分析等多方面，来为一个项目的成功做保驾护航。仅仅自发的从“研发进度”这一个点上发挥，是不能具备比较好的项目管理思维的。研发leader要让团队的项目成功，那么他必须向前、向后看，向前观需求管理，向后观项目价值（收益），同时在执行中关注资源、风险和流程。具体的产品过程中，根据项目的规模、复杂度，leader去按项目管理的知识去做实践，摸索出自己积累的项目管理经验，逐渐形成自己的项目管理思维。
项目管理的思维是非常重要的，在以后团队带到一定规模后，公司非常看重团队的执行力，能不能把公司规划的产品成功的一个个落地。为leader个人未来的职业成长，铺垫一条业绩之路、信任之路。
给这几位同学的具体建议，是：
a. 看一本专业的项目管理书，了解项目管理的理论和常规实践。
b. 在自己的工作里，灵活应用项目管理，通过实践形成自己的项目管理思维。
Stage 3:
技术leader三段，团队的教练
有两位同学在回答Q1做的最好的方面时，提到了团队成员的成长，他们在团队成员的辅导、指导上，做了很好的实践。其中一位同学，带了3个ADC做主数据管理系统，非常大的挑战，但是结果做的很好。
他个人是一个很好的工程师，技术能力、写代码效率都很高。但是他没有以自己为中心来组织团队开展工作，而是把项目拆分成模块、任务，大量分给几个ADC同学，让ADC去做超过他们当前能力的事；他自己在项目过程中，辅导和支持ADC同学。半年时间就把ADC带成了团队产出的主力（这和贝壳招聘了一批优秀的ADC有很大关系，素质好，能够快速培养起来）。
这样的带人方式，我在高德工作的时候，也使用过一样的方法。团队成员通过自己的努力和leader的指导，完成了超过自己能力的任务，他们的成就感、自信心、实际的工作能力，都会有很大的提高。整个团队的产出，远超过以leader为中心产出能力的模式。能够带出一个优秀的队伍，是技术leader进一步在管理上进行发展的必要条件。
队伍强了，leader的精力就可以更多的用在杠杆作用上，进一步放大团队的产出，进入一个正循环。我给他的建议是：
去理解产品经理的思维方式，不仅仅是看懂产品经理的PRD。
项目管理的专业提升，看一本项目管理的书，在内部实践。
总结什么样的人可带，可培养。
Stage 4:
技术leader四段，产品思维的叠加
这次的述职中，没有体现出产品思维有叠加的技术leader。这可能是一个副本，不是每个技术leader都有机会去尝试做产品、带产品，不做产品基本建立不起来产品思维，也很难去带产品。从长期的发展来看，这会束缚技术leader的发展空间。不过这也是一条难路，从技术思维的主线里，去理解和接受一个相差很大的产品思维，非经过大折磨难以合成。
我过去因为技术团队带的比较好，公司为了培养我，而给我机会，让我去带产品团队、业务团队。刚开始带产品团队时，对产品经理们估计是个很痛苦的过程，我们很难有效的交流，无关对错、无关是非，仅仅是因为思维模式不一样，看待同一件事时，关注的点是不一样，难以有共鸣，难以有共识。理解一个事情，最好的办法是自己去做一下，参与设计几个产品，看他们是怎么工作的，努力在和他们的交往、配合中，把自己转换成一个产品经理，用共同的语言、共同的思考模式、共同的视角去发现、分析和解决问题。实践上来说，细致的review产品经理的PRD，把自己理解不一致、认为有问题的地方提出来，和PM一起探讨，是技术leader比较快的搭建产品思维的一个方法。
仅仅从做好技术团队的工作本身出发，具备一定的产品能力和产品思维也是很有必要的。技术团队的项目来源于产品经理的输出，如果不具备一定的产品思维，很难和产品经理一起对PRD进行深入的有效沟通。知道PRD说明了要做什么，为什么这么做、有没有更好的办法做，却是不能理解的。不能理解产品经理的思考和产出PRD过程，研发就容易降级为产品经理实现目标的资源，而不是伙伴关系。
Stage 5:
技术leader五段，业务思维的叠加
在这次述职里，技术leader的OKR里，大部分有一条：100%实现产品经理的需求；或100%实现产品经理有价值的需求。研发实现产品经理的产品设计，这是职责的一部分。但是我不认为这样写研发的OKR合适。我更希望他们的OKR，是实现业务的某个目标，和产品经理是保持一致的。
这两者的差异，在于是否拥有业务思维。OKR定义为实现产品经理的诉求，是一个技术思维；定义为实现业务的某个目标，是业务思维。研发做的好不好，最终是看有没有体现出业务的价值。有一些研发leader认为，技术团队的职责就是实现产品规划，这是没有错的。但是更进一步，产品规划是为了实现业务目标，所以研发工作的最终目标，是实现业务目标。只有研发的目标和关键结果，和业务结果关联起来时，才能对产品的规划、方案，进行有深度的review。只有团队目标定义为业务目标，技术leader也才会有意识去和业务进行深入的交流和沟通，去理解业务的目标，培养更高的格局和对长期目标的理解。
“对于公司来说，无论技术干部、产品干部还是管理干部，都是业务干部，为公司的业务目标负责”。这是高德老领导董振宁先生的一句话，对我影响久远。无论身在技术、还是身在产品，心永远在业务；以达成业务目标为自己的职责。
这五个阶段，非一层层的升级关系，每个leader因为工作环境、团队环境的场景，可能会早接触或晚接触某个阶段。在接触到某个阶段时，希望能够有意识的去建立这方面比较全面的思维，在知识上先学、仿其他人，逐渐在工作实践中形成自己的认知，最后用自己的认知，形成自己的方法，去指引自己工作。
这五个阶段，不是覆盖的关系。思维的叠加，更像多维空间的延展，每一种思维都来之不易，也有无限的提升扩展空间。在我们的整个职业生涯和生命中，我们都应该在持续的升华自己的复合思维。
注：本次没有提到架构思维，对于技术leader来说这是非常重要的一个思维。在述职过程中，主要述职内容是业务OKR和团队建设，没有对专业技术、架构方面进行讲述。
本文以笔者工作经历为素材，进行思考、总结，肯定有不足、不对之处，欢迎各位读者斧正，请加我的微信（windows2000d）或关注公众号（Management_V)，共同学习、提高。
【历史文章推荐】
811
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
