一、前言

机缘巧合之下，成为了公司的技术管理，作为一个技术人er，并无太多团队管理和项目管理经验，说实话，心里也虚的很，最近也作为技术面试官参与到团队的组建和面试工作，想着写下点东西，趁着中秋节来临之际，补充点儿能量。

二、关于技术管理的三板斧

这里的管理，不是团队管理，是指技术本身的管理，倡导的是技术的微观化管理，技术和其他的事务不太一样，一旦宏观化管理，不能 Deep Dive 细节，就非常容易引发各种各样的问题。例如，在研发质量中体现为研发效率降低，架构孵化。学习以下三个方面的建议：

1、首先，把控核心细节。软件工程这些年，本质是没变的。不管是偏互联网的部分还是偏企业级的部分，关键细节是需要严格把关的。

2、另外，就是数据化度量。通过数据驱动研发体系的重建，通过质量风险文化的宣导以及核心指标的跟进，起到督导的作用。

3、最后，就是清单革命。清单革命是一本书的名字，这里借用过来，合适是 checklist，不管是代码规约、应用规范还是稳定性治理等，都容易由于不重视或者不 check 而逐渐孵化。这时候，一个好的 checklist 非常关键重要。

三、关于组建团队

1、初期团队成员的来源

作为一个技术leader，能组建一个合适的技术团队是一项很重要的能力指标，初期团队成员的来源主要有以下几个：
● 之前公司的同事，此类候选人了解比较清楚，将来出风险的几率也比较小，但要确定对方对公司的认可度和对参与创业的态度，很多人短期没有起色就又回大厂了；
● 同事/朋友介绍的候选人，对背景有一定的了解，但要切记不要碍于人情而盲目选择，一定要选择合适的人选，并且严格控制在公司的预算之内；
● 招聘平台，接触到的候选人数量比较多，但优质候选人比较少，所谓“人才市场无人才”，而且要去辨别可能存伪的简历信息，招聘效率不高，但只要你勤快，基本能保证招到人；
● 猎头，能带来一些优质候选人，但成本较高，大多数初创公司可能无法负担猎头费，而且前期可能并不急需高级专业性人才；
● 在一些论坛或专业性网站上发招聘贴或直接与感兴趣的人联系，这种相对比较主动，但能否遇到合适的人且对方也在看机会更多是靠运气。

我就在脉脉上自己发帖来吸引了不少人投递简历，我能从中选择合适的简历，并进行面试。

2、如何招到合适的人

在招聘的时候，我们永远都要有planB，候选人要有个list，已发出的offer要随时跟进，其他合适的候选人三天没发offer可能就入职了，所以有时即使只有一个head count也可以同时发两个或多个offer，毕竟还有试用期可以筛选，尤其是第一候选人接受offer但入职时间比较久的时候。

在发出的10份面试邀请中有2~3个候选人如约来面试了，那接下来就是另一个问题：永远也招不到合适的人。
这个问题在技术leader本身教育背景或者履历很优秀时更为明显，“一流的人才招一流的人，二流的人才招三流的人”，优秀的人总是想组建一个足够优秀的团队，从教育背景、工作经历甚至工作态度上都有一个比较高的预期，而且很多一直在大公司工作的人都会有一个认知误区，那就是“优秀的人很多，而且大家的道德水准都很高”，殊不知是被自己过去所处的环境所局限，“不识庐山真面目，只缘身在此山中”。
就总体而言，全国总人口的本科率只有4%左右，即使只关注2000年出生的人口，最终在2018年被普通本科录取的也只有约23%，一本的录取率更是只有7%左右（基于国家统计局公布数据计算），985/211就更凤毛麟角了，而且这些“高材生”中只有一小部分最终会从事互联网技术行业，所以你心里预期的人才都是万里挑一的，招不到，正常，招到了，可以抓紧时间去买个彩票了。
该如何取舍呢，首先合适大于优秀，对于每个职位技术leader都应该有个心理预期，要招进来的人需要扮演什么样的角色，完成什么样的任务，不会有100%匹配的人才，有一部分技能或经验匹配就可以考虑，有相关工作经验的，技能组成比较专一的普通院校毕业的候选人要好于经验少，技术广而不专的重点院校毕业的候选人；
其次是充分利用好试用期，任何新入职的员工都需要一定的时间适应新环境、新流程，了解新业务，而且通过几个小时的面试也不可能很全面的了解一个人，只有在实际工作中才能比较准确的评估工作能力，要有耐心，尽力帮助和引导，但如果发现不合适，坚决不能将就，否则都是债；
还有就是可以接受相互利用，任何时候都会有一些能力强、素质高的人想要转行做互联网，但大公司的招聘门槛对他们来说显然太高了，所以会寻求一些小公司作为转型或跳板，虽然他们可能不会在小公司长久做下去，但经过一段时间的学习和适应，他们可能会有让人惊喜的产出，而且性价比通常比较高，可以阶段性的为公司做出贡献

3、团队人员比例

为了能与后台开发速度匹配上，前后端人员比最好是1.5 : 1或者2 : 1，而Android开发相对于iOS开发一样会有碎片化系统兼容性问题，所以为了保证Android和iOS平台APP开发进度同步，两者开发人员配置比最好也是1.5 : 1或者2 : 1。
如果考虑到控制成本的话，UI设计和APP开发前期可以外包出去，尤其是UI设计，不太会频繁改动，而且近几年UI设计培训机构众多，导致UI设计师过饱和，但是优秀的凤毛麟角，招聘也存在成本高，难招到优秀的设计师等问题。APP开发也存在阶段性工作问题，在初期产品上线后，更多是要快速扩大市场和客户，在用户量不大的阶段，APP迭代频率也不会很高，而且网站能提供覆盖APP甚至更丰富的功能，所以前期APP开发也可以外包，但原型设计要由自己团队把控。

四、关于技术选型

首先要确定主编程语言，其实并不存在说哪一种编程语言能更好的满足我的业务需求，基本上高级编程语言都能实现各种业务功能并且也有相应的开源框架可以用，选型主要从以下几个方面考虑：

1. 人员技能，Facebook最开始是用PHP来写的，淘宝是用Java来写的，当然还会有其他各种语言的配合，所以编程语言并无好坏之分，要根据现有人员技能配置以及招聘难度来决定，作为网站后台开发语言，Java依然是从业者最多，应聘候选者也最多的语言；
2. 开源社区，既然使用开源工具，就必然要考虑到开源社区的支持，以及是否有团队或公司在支持和维护这个开源工具；
3. 业务需求，每种编程语言都有自己的特点和更适合的领域，譬如c/c++这种编译型语言程序执行效率高，适合对性能有较高要求的系统级开发场景，Python这种解释型语言性能虽然不如编译型语言，但是平台兼容性好、可以快速部署而且编程相对简单，利于维护，更适合于后台任务分发、数据处理等场景，而Java介于二者中间，先编译成.class的字节码文件，然后通过jvm虚拟机进行解释执行，相对于纯解释型语言性能更高，也保留了跨平台特性，在分布式应用中带来很多便利；
   我们团队大多数人是做Java出身，自然而然选择Java作为主编程语言，早期使用的技术栈是SpringMVC+JDBC+freemarker，刚开始业务量不大，功能模块并不需要拆分，而且前后端也没有分开，所有人共同维护一个项目。
   后来随着技术的发展，我们的技术栈演变成SpringBoot + JPA + Vue.js，每一个选择都考虑过不同的备选，例如SpringBoot，我们此时的架构已经变成前后端分离+微服务部署，自然而然会想到用SpringCloud，其实SpringCloud封装了很多分布式系统需要用到的插件，也做了一些优化，是微服务架构中很常用的一个Java开源框架，我们之所以还是使用SpringBoot最主要的考虑还是异构的问题，我们系统中的服务有一些是使用go语言来开发的，同样是对外提供restful api接口，因此java服务使用SpringCloud的话，go语言服务依然要另外处理，因此就没有迁移到SpringCloud。
   持久层部分我们最终是在JPA和Mybatis中进行选择，之前我们有一段时间使用的是Mybatis，后来开发一些新的服务是我们尝试了JPA，使用JPA能更专注于面向对象的设计，对单表操作来说开发效率高，但对多表的复杂查询业务来说并不是很友好，之所以尝试JPA还是主要考虑的开发效率，而且有意识的提升开发人员的设计思维，通过一些数据仓库或者功能模块的设计尽量的减少跨表的复杂查询。
   前端框架的话，我们主要考虑的是Vue.js和React，二者都能满足我们的需求，最终选择vue.js还是从现有人员的技能上的考虑，当时做前后端分离的时候比较早，团队中的人员都没有使用过Vue.js或者React，相对React来说Vue.js比较轻量级，学习曲线比较浅，容易上手，而且就国内来说阿里对Vue.js的支持也越来越多，包括提供了npm镜像服务器等等，为开发者提供了不少便利。
   大的开发框架就这样选定了，关系型数据库使用的是MySQL，非关系型数据库使用的MongoDB，中间件Redis，RabbitMQ，es等，不过这些软件基本上都是选择的商用云服务，能保证高可用性，而且极大地降低我们团队自己的运维成本。
   如果你的产品不涉及到视频分享、游戏等特殊领域，对像电商、金融、社交等大部分领域的初创公司来说，如上所述的技术栈完全能满足初期的业务需求了。

五、关于团队管理

1、描绘愿景，传递清晰的目标

执行力来源于对目标的充分理解，所以当产品方向和目标都清晰确定之后，管理者需要组织了一个项目整体宣讲会。
这个宣讲会可以和启动会一起开，也可以分开来开。总之是需要有一个这样的宣讲会，在这个会上，需要项目的负责人甚至更高级别的领导来重点描绘项目的愿景、讲解项目的重要性、部门/组织对团队的期望、项目成功后对组织及个人发展的影响，如果有可能，还可以展示竞品的产品。

大家不要觉得这是在给团队“画饼”（当然不排除这个嫌疑），但更重要的是希望通过高层管理或领导，给团队传递清晰的目标，增强团队的信心。
一个项目的立项，是奔着价值去的，而这个价值，不仅仅只是为部门或公司创造价值，也要清晰的让团队知道，从中可以获得怎样的价值，预期的回报 or 行业的领军人物 or 其他。
除了高管介绍项目的愿景和目标以外，项目经理要提前做好相关的规划准备，要清晰的告诉团队，项目在初始规划之后，整体项目的周期是怎样的，是一年，还是两年，甚至更长，这期间重要的里程碑有哪些。什么时候该重点关注什么。
既是传递清晰的目标，也是管理团队的预期，也包括主要干系人的预期。这里有一个非常重要的提示，就是这些信息在正式和团队宣讲的时候，一定是需要和团队的核心管理层沟通对齐过的。
随着项目的推进，逐步明晰，计划会不断刷新，每次刷新的时候，都需要和团队同步。

2、明确关键岗位，知人善任

（1）明确关键岗位
如果是大规模团队，需要先搭建项目团队管理架构（关于这点，后续文章会另外介绍），这里先以小规模团队为例：
明确关键岗位人员，抓核心骨干。在团队组建完成之后，项目经理需要和各小组的leader进行深入地沟通，明确各关键岗位的人员，并确定他们的职责。
这个关键岗位是要有影响力，且能够hold住的核心骨干。毕竟项目团队刚刚组建，项目的初始阶段，虽是项目研发的的第一个阶段，但更是项目的攻坚阶段。因此，对关键岗位人员的使用需要达成共识，即选用最合适的人。
（2）知人善任
在选定关键岗位人员之后，相信他们，但必须核实。这个核实更多的是在接下来项目各项工作开展中去观察，去验证，是否真正的能够起到关键岗位人员的效用。
在这个阶段，也是非常难的阶段，项目经理要把各个小组的leader卷进来一起，善于去发现问题，以成果和目标为导向去检验工作开展的是否顺利，让合适的人做合适的事情。
这里有一个小案例，在我之前负责的一个项目里面，当时我们项目组是分研发组和运营组，因为研发项目刚刚启动，人员不足，在人力盘点和整合之后，从运营组抽调了一位客户端人员小明，小明在之前的工作中，各方面的表现都比较好，也是之前的优秀员工。
经过沟通协商，我们把小明放到当时一条特性线负责人的位置上，但一个月观察下来，发现效果很弱，没有起到负责人的效用，不仅如此，小明自己还压力很大，情绪很低落，也使得整体输出效率比较低，因此在一个月之后，我果断的找到客户端主程沟通，并对人员进行调整达成共识。
后来把小明放到核心战斗线做具体的工作，没有承担特性负责人的角色，产出相比较之前有了很大的提升。而重新替换的一位负责人小李，在接下来的各项工作中开展的有声有色，特性线的工作推进也有条不紊，也获得团队的一致认可。

3、先帮后管，借力打力

（1）先帮后管
项目经理对产品整体的了解，对目标的理解是比其他团队成员都清楚的，为了更好地提升团队的执行力和战斗力。项目经理采用先帮后管的策略，帮助特性负责人梳理和明确清楚目标，各个事项，让他们清楚的知道如何更好的开展工作，并充分信任他们，同时为了平衡好时间和任务的压力，以目标为导向，以成果为导向。
帮的维度还有很多，需要项目经理在这个过程中，细心的去发现，去挖掘。因为团队中很多成员不一定会主动反馈他们的困难。那项目经理怎么去了解到这些呢？可以通过定期的晨会，周会；可以通过走动式管理的模式；可以正式或非正式的和团队成员沟通交流；可以重点关注关键路径，主动询问团队成员。
当然，还有一个比较好的策略，因为团队刚刚组建，也是建立相关规则最好的时机。建立团队规则，团队行为准则，也是项目经理的核心价值之一。

（2）借力打力

项目经理大多是有责无权的，在项目推进的过程中，要善于借力。那这个借力来自于哪里呢？
按照prince2其中的一个主题（组织，为有效管理项目所需要的临时性PRINCE2项目管理团队中的角色和职责）所提供的思路，每个项目都应该有一个核心管理组，这个核心管理组在主要效用就是决策。

项目经理在项目推进过程中，要善于向这个核心管理组借力，比如项目中的任何重大事项落地之前，都需要和这个管理组沟通对齐，明确思路，达成共识，确保执行方向不偏移；目标、计划的对齐，也都及时地和管理组沟通；项目问题、风险，都及时地和管理组同步，确保项目信息都是核心管理组都清楚的。从而也可以更好地管理好核心管理组的预期。
当然，有些团队不一定是一个核心管理组，也可能是只有一个老板，或高层领导，或者项目发起人。总之，都是可以通过目标对齐、信息同步去向他们借力。
还有一个维度，就是各小组的leader，也可以向他们借力。项目经理因为没有直接的考核权，但可以在项目推进过程中，记录团队成员执行过程中做的比较好的方面，及时的同步到各小组leader，获取各leader更多的支持。
换位思考，每个小组leader都是希望能听到来自其他团队或项目经理更正向、更积极的反馈的。同样，团队成员做的的一面，通过项目经理反馈给自己的直属leader，也是对项目贡献的重要体现，也是很客观的加分项。这样一来，项目经理也可以获得团队的认同。
通过这些积极、主动的反馈，也可以为日后争取考核建议权增加一定的权重。
4、服务为主，充分信任
在其他日常的项目推进过程中，也还是以服务团队为主，提前统筹，规划好各个目标事项，帮助大家解决项目过程中的问题。

服务为主的思路，主要以一种仆人式领导的方式，为团队成员提供项目过程中的必要支持，要逐步让团队成员们知道，项目经理是他们使用的一种资源，从而让他们更好地为达成目标而服务。

此外，充分地信任团队，是项目经理必须要有的格局。著名的现代管理大师，彼得·德鲁克说：组织不再建立在权力之上，而是以信任为基础。可见，信任团队成员，是一种非常好的激发方式。
项目经理在这个过程中，要转变思维观念，目标的达成是要依靠团队成员的。既然选择确定了各个工作的人员安排，就要充分地信任他们，无需在项目的推进过程中患得患失，担心这担心那的，更不要去做本该团队成员他们的工作。要知道，项目经理需要追求的是整体合理，而不是单个或局部的完美。

六、好的leader定义

下一篇文章分享

七、一个好的面试官

下一篇文章分享

八、总结

做好技术管理和团队管理并不容易，自己也有很多要学习的地方，热爱可抵漫长岁月，温柔可抵艰难时光。
未来的日子里，继续努力，加油！！祝大家中秋节快乐。