十年风雨，一个普通程序员的成长之路（五） 成长：得到与教训
十年风雨，一个普通程序员的成长之路（五）
author 妖生
date 2019.06.09
[TOC]
一、前言：生活的演变
在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，还是会偶尔聚会，吹牛喝酒，怀念当年。
教训
实际上技术分享 代码检查 项目总结这些没有能很好地执行下去。除了项目经理外没有拥有足够威望的人监督执行。有些事情一拖，便不了了之。
在成员关系上，每个同事也都有自己的棱角，能保证质量的完成任务就行了，没必要去要求相亲相爱。强行弥合，反而更不痛快。
欢迎关注我的公众号：姚毛毛的博客
这里有我的编程生涯感悟与总结，有Java相关的开发技术，有JVM、Linux、数据库的性能调优，有工作中进行的架构设计实践和读书理论，有……
有技术，有情怀，有温度
欢迎关注我：姚毛毛& 妖生
