看到[30岁后的程序员,该如何做出职业抉择?](https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653547498&idx=1&sn=5d29a4875d5a093a7f33e9ec89887b3b&scene=1&srcid=0705bSatpzBcv9Lvy2a3VKQo&key=77421cf58af4a653b9f124ad066dd22a151b84a45108d04f6e8c624da0157a4d56e346624ab9b0a198bb49ab74ffa727&ascene=0&uin=MjE5NTY4NQ==&devicetype=iMac+MacBookPro12,1+OSX+OSX+10.11.5+build(15F34) 文章,有感而发。

0 前言

其实我还不是一个正式的技术管理者,还是在学习管理的路上。

以前我对做管理也有很多误解,比如任务做了管理之后对技术就会慢慢生疏了技术,越来越不懂技术,在技术的路上只能看着别人一路前进了。另外,管理上更多是琐碎的事情,不停在协调资源,给人打kpi,毫无技术含量。

记得在去年自己刚开始接触管理的时候,内心是非常抵触的,都不愿意承认自己在往技术管理的方向发展;也因为这种思想导致自己在实际工作中不能把技术管理做好,也没有把技术做好。

之前写了这篇程序员的业务观,做到合格的技术管理应该有很好的技术观产品观数据观、整体来看也就是有全面的业务观
现在谈谈我在技术管理角色中做了什么。

1 业务项目的整体架构和规划

首先要在业务项目把控整体架构并作出长远的规划。例如在项目整体架构方面,需要把控好每个项目的业务领域到底有哪些,应该属于哪个级别的服务。例如我们现在业务里面有订单服务,对于订单服务我们提供最重要的创建订单,订单更新和订单基础查询服务,并抽象模型能够支持多个业务接入,在这里订单服务就属于基础服务。长远规划是将订单服务拆成更小粒度的服务,如将创建订单和订单更新分拆成一个服务,而将订单基础查询独立为单独的服务,并新增订单综合查询服务;需要监控数据库情况,在条件成熟的情况下需要将交易相关的数据单独出一个新的数据库等等。

另外还需要关注服务之间的架构模式,如各个服务之间的依赖关系是否合理,相互之间的通信方式是否合理等等。

除了自己业务的项目之外,还会涉及到与其他团队服务的交互问题等等,都需要有个合理的规划。

2 需求把控和细化

这个角色类似于Scrum中的Scrum Master。
在互联网公司随时会面对不靠谱的产品经理,也可能会面对靠谱产品经理提出的不那么靠谱的需求,总之把握好产品提出的产品需求是阻挡不靠谱需求的第一道防线,在这个过程中不仅能够挡掉不靠谱的需求,也能够很好的引导产品需求提出更好的需求,作出更合理的决定。

站在技术的角度一般会考虑这些方面:

  • 首先要理解的就是产品的价值,也就是这个需求是为了解决什么问题,要解决的在实际中是否能成为问题。
  • 产品的形式是否合理。要解决问题参与这种方式是不是最优的,有没有一些产品未曾考虑到的问题,与线上的产品形式会不会相互矛盾。因为很多产品的需求会比较宏大,可能会说这次我们要来个大的改动,可是仔细讨论下来,可能绝大部分的改动都是没有什么意义,或者在近期是不需要做的。
  • 给出技术复杂度以辅助产品经理作出决策。有些需求在产品经理来看可能以为只是一个很小的改动,但是在技术上可能需要很多资源才能实现,这时候需要给出合理的评估时间(如果自己不能给出较为准确的时间,需要找到对应的业务Owner来给出时间),让产品来权衡花这么大的资源来实现需求是否合算;另外,如果一个需求的实现成本很高,又必须去做,那就需要有合理的排期,不同阶段应该有相应的milestone,这样更有节奏的开发。

    例如我们在工作中遇到过一个这种需求,因为我们的订单消费有商家手动确认消费和系统确认消费(用户过了消费时间又未退款)两种,且结算是依赖依赖消费数据,因为商家通过商家后台使用时对系统确认消费比较疑惑。

产品经理提出针对需要系统确认消费的订单不再做系统确认消费的动作,从而解决商家这个功能的疑惑。这个需求是要解决商家对系统确认消费不理解的问题,这个目的是比较正常的也是必须的,但是采用更改订单流程的方式来修改,这种修改方式不仅影响商家的消费数据,同时也影响到商家结算,影响范围较大,实现成本也很高;这时候回头来看产品要解决的问题是解决商家对文案的疑惑,简单的使用修改商家后台文案的方式也就解决了,而且解决成本很低,也能快速上线。

厘清了这些关系,产品也比较能够接受这种实现成本低,上线风险小的方案。

3 辅助团队成员

我一直不喜欢使用管理团队成员这种方式,我更喜欢团队是一个自管理的,而技术管理者只要提供适当的帮助,让技术人员既能有足够的自由度又能按照目标前进。在这里推荐情境领导者这边书,书里关于如何管理不同类型的开发人员有很好的阐述。
不同能力的开发人员给予不同的帮助:

  • 初级开发

    针对其做事方式、编码能力和设计能力做强力的指导,给定其目标,给出实现的方式,并定期review其完成情况。这部分工作,有时候也会交给高级开发来承担。

  • 中级开发

    需要锻炼开发能力和设计能力,会主要分配一些相对完整的需求/项目,更多关注其系统设计,在编码上给予一定的自由度,引导其处理线上运营时间,也给予一些犯错的机会。

  • 高级开发

    给予更多的自由度,能够承担更多更重要的开发任务,引导其做项目管理,并适当放权,放手让他们去应对线上问题,让他们能够兼具技术开发和项目管理的能力。

4 培养团队的气氛

团队气氛也就是团队的价值观,这些需要技术管理者站在更高的角度来推动和引导。现在我们团队更多是在推下面这些价值观:

  • 技术创新

    鼓励团队成员锻炼技术,在项目中使用新的技术,不断提高个人和团队的技术能力;更重要的一点是利用技术优势来影响产品,探索业务;鼓励新的想法,如果合理就可以排到迭代中实现并持续优化。

  • 包容

    团队成员各不相同,无论对内对外都以包容的心态相处,弥补彼此的缺点,让团队更加稳定而有战斗力。

  • 参与到业务中,参与到产品中

    开发不只是实现产品需求的工具,而是积极参与到产品需求的讨论中,提出更好的产品形式,甚至提出更好的业务模式。

5 总结

做技术成就感主要来自技术,如学习了新技术,实现了一个高明的算法,成就感单纯且实在;技术管理所要面对的事情更多更复杂,成就感来之不易。但是技术管理对技术的要求一刻也不能落下,而且要求有更全面更有战略的思维,通过成就别人来成就自己。

References

[30岁后的程序员,该如何做出职业抉择?](https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653547498&idx=1&sn=5d29a4875d5a093a7f33e9ec89887b3b&scene=1&srcid=0705bSatpzBcv9Lvy2a3VKQo&key=77421cf58af4a653b9f124ad066dd22a151b84a45108d04f6e8c624da0157a4d56e346624ab9b0a198bb49ab74ffa727&ascene=0&uin=MjE5NTY4NQ==&devicetype=iMac+MacBookPro12,1+OSX+OSX+10.11.5+build(15F34)
服务化设计模式实践