摘自:  https://www.cnblogs.com/yaoshen/p/10995613.html

十年风雨,一个普通程序员的成长之路(五)

author 妖生
date 2019.06.09

成长、抉择与失去(上)

一、前言:生活的演变

在14年到18年间,我的生活中经历了喜乐悲丧,结婚、生子,爷爷的去世,老赵的病逝。
在个人职位上,则从开发组长到项目经理,惭愧的是,是老赵因病离职才给了我这个机会。
项目经历上,在这几年里,历经核心征管、管理决策、金三改造、数据迁移、大数据开发、税警交换等各种项目。
项目类型有OLTP、OLAP,有接手维护的,有重构的,还有从零开始的。

其中涉及的技术栈则让我见证了公司从远古到近代的演变:

  • ORM从datawindown、ormap到ibatis、Mybaits
  • framework从自研的sm@rtFrame到spring、springboot
  • 打包工具从ant到maven、gradle
  • 前端渲染从HTC到freemark、jQuery+layui、antdesign
  • 数据存储从Oracle11g到12c、mpp、noSql、hadoop、elasticsearch
  • 数据处理从kettle、ogg到sqlloader、kafka、flum、mapreduce、storm、spark
  • 系统架构从SOA的垂直分离到集成服务又到微服务
  • 服务管理从ESB到API网关

那么,在这些年里,主要做了些什么?又学到了些什么呢?

现在想想,好像大多都记不得了。只挑印象最深的几件事来说吧。
有正面,也有反例。
总结一下,便是得到与教训吧。

二、成长:得到与教训

2.1 计划制定与执行

有意识地参与工作计划的制定,分解里程碑计划与每周计划,正确认识团队协作中每个人能力的不同,合理安排人员计划,并跟踪执行a。

为什么推荐周计划?

这里说说为什么是周计划,而不是天计划、月计划?按天的计划太有压迫性,容易让开发人员思维紧张,每日跟踪也太浪费时间;而超过一周的计划则太过宽松,会在中途导致不可预估的风险,增加调整难度。

怎样为不同的成员分配合理的工作量?

在工作计划的制定中,很多技术人员在做team leader 后有一个通病,总是以自己的能力来衡量他人,导致产生不可预知的风险。

为什么一定要跟踪计划?

计划制定后,对于计划的执行则需要随时跟踪,监控前后变化,预估风险。计划在周五晚汇总,但并不意味着中途不予过问,最好的时间应该在周三时跟踪下计划执行情况,对于开发人员没有比较大的压迫感,又能及时沟通不能按时完成的风险,进行调整。

吐槽
  • 站立会
    在有些公司的最佳实践中,还包含了早(晚)站立会,实际上我是有些看不起的,因为一个teamleader连十人内的人员进度情况都不能随时掌握,有点脱离群众了。

  • 屁股与脑袋
    在职位晋升后,有些人的脑袋似乎便被屁股所掌握,忘记了曾经在所吐槽的人和制度。

得到

在每次周计划的跟踪中,摸清团队成员的能力上限,给团队人员多一点点但不要超过太多的工作量。
在里程碑的进度跟踪上,需要在项目进度与人员成长、工作强度(加班)之间作平衡,考验team leader的内部带团能力。
在位置调换后,你有时会理解以前吐槽段子中的领导为何有这样那样的安排。
只是,不忘初心,砥砺前行。

教训

如果有资源缺失的情况,千万不要自己背,例如这个成员能力差了点、那个技术路线有点风险,特别涉及到外部资源协调的情况,要及时上报,争取资源。

不要觉得这算什么,我自己加班搞两个小时就搞定了。一是把自己累死,二是有苦劳没功劳。

事情压在手里万一没解决的情况下,导致进度受挫,损失的是公司的钱、领导的信任、团队的士气。

2.2 个人能力提升

从前端到后端,从业务系统的开发到服务部署,从需求沟通到数据模型设计,从项目售前到项目立项。不知不觉就成了所谓的全栈工程师。

得到
专业技能上的广度与深度有什么提升?

广度

  • 语言
    JavaScript、java、python
  • 前端
    中台web、移动H5、小程序;
  • 交付
    CI/CD概念及工具、ant/maven/gradle
  • 服务容器
    weblogic、tomcat、nginx;
  • linux系统
    redhat、centOS、Ubuntu
  • 虚拟化
    OpenStack、KVM、VMware、docker
  • 测试
    用例、计划与报告,冒烟、覆盖与回归,人工、自动化,功能、安全与性能
  • 性能
    CPU、内存与IO,进程、线程与管道,QPS、TPS与PV,压力、负载、稳定性

深度
而深度上,对我提升最大的应该是Oracle,这也是得益于老赵对我们的技术分享,记得那次分享还推荐了一本书——《收货,不只是oracle》。
掌握了实例、表空间、用户、表结构设计、索引优化、系统表、redo、flush、DBF文件及IMPDP/EXPDP、AWR报告等oracle的理论及相关工具并予以实践,此时再去看诸如mysql等其他结构及非结构化的数据库,easy。

掌握了哪些业务能力?

历经申报、征收、登记、发票、文书等核心征管业务,又掌握了些元数据、数据仓库、数据处理、数据质量、数据分析的理念设计以及相关的一些工具。
与客户沟通的时候什么都能说上一点吧。

项目管理的一些软技能

参与并主导项目售前、投标、立项到项目启动、执行、上线、运维等一系列项目活动。
从一开始的项目意向沟通,原始需求的收集、分析到编写需求规格说明书,设计界面原型,然后是投标书中的技术指标编写与审核,项目立项与公司流程的审核,项目中途的代码与文档审计,项目上线前的等保评测、安全加固等等,不一而足。

  • 效率工具

这里用到的几个专业工具倒是可以说下,office2016套装且不说了。
界面原型设计推荐Axure + antDesign,
流程及架构设计则推荐在线工具ProcessOn(本地则是visio、PPT),
思维导图及团队协作也可以使用ProcessOn(本地则是xmind + excel),
数据模型设计我也用的是ProcessOn(本地则可以用powerdesign)。

原谅我,成了ProcessOn脑残粉,好用上瘾(笑)。

吐槽

有时候转到管理岗很难再有精力继续做技术,如果还有颗做技术的心,关注开源,保持技术敏感性。

教训
  • 原型设计

原型很重要!
原型很重要!
原型很重要!

所谓一图胜千言,有时候客户自己都不明白自己想要什么,总是说“你先做一版出来看看吧”。
懵逼了吗?

在跟客户确认三轮需求之前,不要做,不要做,不要做!
压力再大都不要真正地投入人力开始干。
除非,你是政治任务。

  • 协调管理

对于客户、上级、第三方要善于管理,及时同步相关信息,务必不要让项目干系人产生信息差,导致目标与进度的偏离。

对于客户,如有进度偏差,及时取得沟通谅解。有问题不上报,出了事就是个炸弹,为什么不被叼?心里没点数吗?
但是沟通又要有技巧,我在这方面乏善可陈,所以经常因为说话不够艺术,而被叼。
而且每周都应该跟客户碰面,对于进度中的业务需求演示与确认,让客户有参与感。特别涉及企事业多部门单位的协作项目时,客户没有参与感,是不会主动去帮你解决问题的。你拿钱办事,不应该吗?

对于上级,及时汇报进度与风险,有一些问题无法解决时,不要给上级做填空题,而是选择题。甚至在没问题的时候,也要从项目中找一些选择题给领导做一下,让领导有参与感。
但是在项目之内的事情,其实作为上级应该尽量做到不要越级插手。老蒋就是这么丢的江山,不是吗?
任正非都说了,砍掉高层的手脚,砍掉中层的屁股,砍掉基层的脑袋。
这说的什么意思?高级领导不要亲力亲为、指手画脚、越级干活。
在我之前的公司中,有个总监什么都好,就是做事太过亲力亲为、巨细无遗,导致下属的项目经理直接变成了项目助理,毫无动力。多做多错,听命令就好了嘛,对不对?
中层不要为了自己的小团体做打算、不顾公司利益。
在我经历的几个项目中,有些研发、测试、运维的leader都打着自己的一套小算盘,不以项目目标为导向,而是以自己不背锅为导向。这样能把事做好吗?

对于第三方,上游公司且不说,在多数为协作外包方的公司,应及时盯紧进度,需要对方按照里程碑计划提供项目交付物,并在中途予以真实系统演示。否则,你作为总包方,客户叼的不是分包方,而是你。毕竟,投标、收钱的都是你啊。

2.3 团队能力培养

每周一次的技术分享,两周一次的代码检查,每月一次的项目总结。良好的工作氛围,友善的同事关系,愉快的工作心情。

实际上在工作的几年中,最自豪的并非是完成了多少项目,而是可以在自己学会某些东西后,能分享给团队里的兄弟,在将某个项目掌握好后,能很快丢给兄弟们,并让他们也可以独当一面。

从来不想做什么不可替代,如果某个人不可替代,那么意味着公司的大风险。

也不想用公司的条条框框把人养废,那样哪天从公司出去了就会毫无竞争力。

得到

我自豪的是,从我们项目组出去的,不管是去公司总部还是其他地方项目组,都能很快独当一面,成为核心骨干。

我自豪的是,在我任项目经理期间,大家成长飞快,并且感情甚笃。在18年,大家都陆陆续续从公司离开后(我也在17下半年离任了项目经理),我们都各自成为了不同公司的团队leader,还是会偶尔聚会,吹牛喝酒,怀念当年。

教训

实际上技术分享 代码检查 项目总结这些没有能很好地执行下去。除了项目经理外没有拥有足够威望的人监督执行。有些事情一拖,便不了了之。

在成员关系上,每个同事也都有自己的棱角,能保证质量的完成任务就行了,没必要去要求相亲相爱。强行弥合,反而更不痛快。

三、抉择:管理与技术

在一个公司/团队/项目组中,有了一定资历后,是继续做技术岗还是转为管理岗?
有时候被迫或被动地转为管理岗怎么办?
到了一定年龄,还能不能继续做技术?
还是要受项目经理的指手画脚吗?
技术研发、技术管理、项目管理,怎么选?哪个适合自己?

12点多了,今天写不完了,下篇写吧。

四、失去:生活与生存

同上。

作者:妖生
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利.