8年前科班毕业,入了软件的行。
从开发到项目管理
当时的自己,向往匠人精神,认为应该专注把一件事做好,像小野二郎先生捏寿司那样,可以将编程作为自己一生的坚守,这是一件幸福的事情。在程序员的生涯中,一直秉承着匠人的精神,一砖一瓦的搭建着客户的产品。但当我看着行业中,那些优秀的产品,都是成百上千人的研发产品团队,数年的心血所打造的时,我知道了,开发是整个生产链条的一部分,想要了解的更多,需要跳出去看看更多的世界。
后面机缘巧合,离开了开发的工作, 先后做了业务分析师、技术咨询、运营管理等工作,直到几年前,开始了软件项目的交付管理工作。这些年,在业务、项目的管理方面有了一些心得,但最近越发感觉到,我的技术能力,好像很久没有更新了。这些年,技术的 landscape 发展真的很快。从过去我们大部分的项目都是 Web 开发,少量的 App 开发。到现在,IoT、区块链、人工智能,这些在过去看起来的新名词,已经出现在真实的项目视野中。就拿数据类的项目来说,在我的印象中,行业中大部分的工作还在是利用现有的国外的开源框架,搭建基础设施,把现成的数据导入,进行一些清洗、整合类的工作。到现在,已经进入建立数据模型,使用机器学习算法,通过样例数据的验证,来产生 MVP,之后在产品环境进行大规模验证的新阶段。
力不从心的项目管理
当我去管理这样数据项目的时候,就开始显得力不从心。如何理解现在做的事情?如何对现有工作进行拆解,估计?如何规划迭代,及时获取反馈?需要那些角色和专业技能的参与?哪些点可能产生高风险?什么是 DoD,如何来定义验收标准?这些在项目管理的过程中最基本的问题,开始变的模糊起来。
即使是非这样专业领域的技术,即使是 Web,App 端到端开发,这样早都做烂了的项目,这些年也发生了很多变化。从架构开始,很多项目已经抛弃了过去的单体,大泥团架构。如果是新项目,会直接采用微服务的架构(即使有的时候感觉并不需要),改同步为事件驱动;如果是老系统,更多则是从老的单体架构向微服务架构迁移的项目。交付实践上,过去能做到 CI 已经不错了,但现在,很多新项目是原生 CD,而且这个 D 已经从 Delivery 升级到了 Deployment,持续部署,从代码的提交到上线就在一瞬间。此时,各种自动化测试的保障,测试策略的设计都在项目启动时作为标配而引入。基础设施也从过去的数据中心,升级成以 docker 为基础的容器化云,有的是公有云,有的是私有云,各种云原生的工具也是层出不穷,琳琅满目。
那个时代的技术
2015年,想想我还做开发的时候,那时面对的是什么样的技术。大部分的项目都是 Web 和 App 的开发,基本都是单体,没想过微服务的问题,更多的就是使用 spring 的哪个版本,要不要从老版本进行升级。那时候,还有很多人使用 Ruby on Rails 进行 Web 的开发。讨论更多的问题,经常是前端和后端分离的情况下,项目应该怎么管理,如何做好前端的测试。如何做到及时集成,降低集成风险。还在讨论要使用 Angular JS 还是 React,React 似乎是个新生事物,还没有微前端,但已经慢慢出现了 SPA(Single Page Application),前端开始喜欢基于 mock server,可以不依赖后端,而基于契约的开发方式。而后是几年前端的大发展,当然还有云和虚拟化技术的高速发展。
在当时,docker 已经有了,更多当做玩具来使用,真正在产品环境敢使用 docker 的凤毛麟角,记得好像对 macOS 的支持还不是很好。云更多的是当做数据中心来用,很多功能还需要自己开发一些脚本,才能方便一点使用。有些客户在做云迁移,但迁移过程非常吃力,经常在讨论迁移过程中如何保证数据安全的问题,是否可以有私有云和公有云共存的方案。
项目管理也得懂点技术
那一年,我也在做迁移,是从技术角色到非技术角色,项目管理角色的迁移。你可能觉得,做项目管理工作,感觉不懂这些技术,也能做啊。我会管理客户期望,我会管团队,会管进度、依赖,能走商务,这些还不够么?
私以为,项目经理最大的作用,其实是进行风险管理 - 及时识别风险,防患于未然。而软件项目中,最大的风险,除了人本身之外,就是技术了。那你可能说,这不是技术经理应该负责的事情吗!项目管理第一大忌:不要把所有筹码都压在一个人身上。说实话,你并不能每次都能遇到100%可靠的技术经理,很容易单点失败。所以仍然需要有能力,在进行整体管理的时候,理解现在在发生什么,以及有哪些潜在的高风险的事情可能发生需要有能力进行工作的拆解和估算,需要知道团队的技术能力,塑造持久的工程耐力。否则最后只能道歉了...说实话,留给你道歉的机会并不多,你懂我在说什么。
如果你把是所有事情都要依赖其他人来做,自己只是小鞭子在后面啪啪啪。缺少对项目的整体理解,出了问题只知道咆哮,向团队施加压力,那估计这个工作也做不长。不说运筹于帷幄之中,决胜于千里之外这样的传奇、至少要能做到:当团队 ready 时,观察及时调整;当团队不 ready 时,培养团队,识别全局风险,适时地干预,解决问题。而这种解决问题的能力中,对技术的了解基本是必备的(注意,我这里写的是了解而不是精通)。
转变角色之后,说实话吃了几年技术的老本。之后经历的项目很多还是跟之前类似,都是 APP 和 Web,后台会对接各个复杂的系统。感觉自己俨然成了系统集成商。这个时候,管理的难点主要下面几个:
- 各个系统的集成
集成所使用的协议,有的是RPC, 有的是 SOAP,有的是 RESTful 等等。如何让各个系统按照统一的节奏进行集成。不同的系统使用的开发方法不同,有敏捷,有瀑布,其实大部分连瀑布的方法都没有玩转。没有开发节奏,测试滞后,运维还停留在很原始的阶段,来个包上线,坏了都不知道哪里出了问题的比比皆是。 - 前后端分离的开发和集成节奏
一般,会使用契约测试保证前后端的开发节奏,同时在持续集成服务器上及早测试,避免集成风险。一般很少项目可以做到持续交付,还是会规划上线,每次上线都能剥一层皮。虽然会有测试金字塔的规划,在我们的系统里的测试覆盖是比较全面的。但由于依赖系统较多,与遗留系统的集成测试会比较困难,从对于外部依赖环境的业务理解,到准备、更新、清理测试数据、测试环境,每个环节都会涉及到技术以及技术之外的协作问题,都比较难搞。 - 说服客户做 MVP
往往客户一开始就会想要一个大而全的系统,需要说服客户采用 MVP 的方式,能够逐步交付,验证假设,小步快跑。这件事情说起来简单,其实做起来很困难,懂得 less is more 的人似乎很多,但每个 PO 都觉得,自己规划的那个 scope 就已经非常 less 了。
移动应用时代的项目管理
说实话,从 web 时代,过渡到移动互联网时代,就有些不适应了。过去,大部分也就是 spring,可能就是升级到 spring boot。前端框架换来换去,从 angular,到 react,到 vue.js,万变不离其宗,对 PM 来说就是前后端分离那点事。数据库一般就是 mysql, sqlserver,最多到 mongodb,非关系型数据库,有坑但不多。
到了移动互联网时代要考虑的就更多了。要开始考虑原生开发,还是混合开发;混合开发用什么技术,要不要响应式设计。工作量估计,要考虑对大量不同移动设备的兼容性,从 app 到 pad,甚至 watch,支不支持 3d touch,各种 device 还经常有自己独特的 UI 小设计,都需要考虑到。以及不同国情,也会影响整体方案的选择。比如 push notification 。
海外 android 一律使用 google 推送服务,iOS 使用原生推送。但国内就不一样了iOS 还好说,可以继续用原生。Android 就比较麻烦了。Google 服务被禁用,一定需要采用国内自己的推送服务。但当你开始找的时候,发现并没有一家厂商可以一统江湖,因为手机厂商的腕儿更大。所有大牌的手机厂商都会有自己的推送服务,而且经常发现不同型号的手机,使用的服务还不同。所以要想要同时兼容 oppo, xiaomi, vivo,huawei 以及其它不同的厂商的手机,以及不同型号的手机,除了接入各家,可能还要定制自己的推送服务。在国内,想做一个高可用的推送服务,谈何容易。这就可能给新项目带来难以预料的坑。
在变化中学习
我们的货柜里有了给客户的更多选择,但货柜的发展也确实快。我们理应按照我们对技术趋势的理解,以及客户的不同需求,选择最适合客户的解决方案了,已经不是过去的 spring 全家桶选一下的问题了。这给项目管理工作带来的新的挑战。现在到了云原生时代,需要有更多的学习了。
有人说,技术更新换代非常快,作为开发人员,需要不断更新自己的技能。我的判断是:这个行业发展之快,已经超过所有人的想象。不仅仅是开发需要,PM、运营、策划,甚至设计师等等等等角色,都需要不断跟上发展的脚步更新自己的技术栈、因为,人、文化、技术、商业都在快速的变化中。
一切的主线
好在,一切的一切,都是有一条主线的。这是数字化时代的命脉,那就是技术本身。我坚信,技术是一切变化的原动力。只要你摸到了这条脉,就可以乘上时代的风。
御风而行。
因此就有了一个想法。把 PM 需要了解的技术记录下来,来回应这个变化莫测的时代。
以上。