满打满算,今年是 17 年毕业之后的第 4 个年头了。
4 年时间很长,经历的人和事数不过来;4 年时间太短,想打造自己的专业能力还要假以时日。我一直在思考,程序员到底在互联网这条路上能够走多远呢?
梳理一下职业发展的头 4 年:
但总觉得自己所学仍旧不太够,所以借助不同的工具来学习知识,促使自己求变求存。之前也总结过项目管理的相关文章,欢迎指点~
前言
我们日常开发中是否遇到过这些场景:
1、项目从立项开始就需要多个开发团队一起参与讨论,设计如何让所有模块跟数据打通?
2、你的团队依赖他人的模块对外能力,如何有效组织一场会议去讨论实现难度?
3、你在和别人进行开发排期时,说好是截止今天交付功能,为何到期了对方还是实现不了?
PM 是团体机能概念,任何一个团体都具有两种机能:一种是 P(performance),指工作绩效,是团体的目标达成机能;另一种是 M(maintenance),指团体维系,是维持强化团体或组织的机能。
我们常常讨论 PM 这个角色时,更多的就是组织、沟通、协调,预定会议、组织聚餐、项目周报等杂活。现实也是如此,我以前接触过的 PM,更确切说是偏向于 BD(Business Developer)的 PM。
但是,难道只有把 pmp 的 200 道单选题刷完,或者把项目管理相关的书籍都看一遍,才算一名合格的 PM 么?这个答案显然是否定的。
在几个月前,我参加了某次项目管理的培训课程。当我问起老师,“程序员有办法成为一名技术型 PM 么”,培训讲师微微一笑,当然可以,事实上他本人就是从 8 年后台技术研发,转型成了一个专业 PM。他补充回答,不是非得照本宣科将理论套用到生产实践,才算一个合格的 PM,一个成熟 PM 需要深刻理解项目痛点并推动解决,而完成这个目标,实际上用到的理论知识可能只有书本上的 20%。由此可见,PM 其实是更倾向于实战经验的岗位,我们技术人要对成为一名合格的 PM 抱有充分信心。
技术性PM如何炼成
2.1 PM 能力要求
先看一份从 boss 参考下来的 JD:
其实这本质上就是一个技术型 PM 的岗位描述:
结合这个岗位要求,我结合自己亲身经历的四个真实案例,谈谈我对“如何成为合格的 PM”的实践和理解。
第一个案例是,我刚毕业转行,然后去到老东家时,当时团队大佬离职,所以决定把这个相对稳定的消息模块给资历较浅的我,可以一边维护一边学习。这是个难出成果和绩效的活,因为底层架构不牢固,每天有解决不完的 Bug 提给我,当时心中难免充满委屈。
后来逐渐抽空看懂了这块实现原理,明白到这个还真不是随便实现的业务模块,是个实打实的架构层代码,于是便一头扎进去研究起来。终于第二年随着公司业务升级,消息模块拆分为微服务作为项目重构的大事而被重视起来。
那么这么一个重构项目最后还是遇到了问题,要怎么去实施落地呢?我给自己排了满满的会议:
几次会议讨论下来,发现项目进展很慢,因为我们一直卡在架构设计环节;虽然这个模块我琢磨了一整年,但是将来要怎么设计迭代,我还真是一头雾水。眼看项目推进即将受阻,而我又是任务跟进里面的 PM,怎么办,这个重构项目要黄在我手上了么?
我当时用了 4 个步骤来解决:
这 4 个步骤里面,我觉得最后一步骤是最有效的,因为项目遇到不可抗力很难推进时,学会借助他人的力量就很重要了。
最终这个消息系统也成功完成交付,实现了架构升级,三方共赢(我完成项目开发任务,架构师有绩效指标,leader 可以向上交差)。
这是我第一次主动尝试扮演技术型 PM 的角色,通过这次磨练,除了技术水平得到了很大提升,还学到了一招法宝--“学会借力,实现多方共赢”,在有项目压力交付的前提下,有效的进行 push 和沟通。
如果大家对这个消息模块比较感兴趣,可以参考下我之前的文章:《IM消息系统》。提高技术能力是一个开放式命题,其问题本质应该是“如何高效获取技术知识,并且学以致用”。
所以,有足够的技术能力是一名合格技术 PM 的首要条件,之前跟阿里的某位 P8 大佬有聊到一句受益匪浅的话--“每个人都是自己的 CTO”。所以,前路漫漫,一起努力吧~~
要分享的第二个案例,也是给了我很大勇气和自信去尝试转型技术型 PM 的一次经历;可能我们的某些同行经历过公司人手紧缺,而一线销售却在疯狂的接项目签合同,这个案例恰恰发生在这个背景下。
由于交付周期仅有 1 周~2 周时间,当时架构组加班给这个加急需求进行了开发方案评审,当进行到需求分发环节时,各业务线的开发人都表示手上已经有活在干,而我“正好赋闲”,于是底下 7 个业务开发同事的活都被推到我这边了。
所以我这边理想情况下要进行三向沟通:
但是生活远比想象中要困难一点,实际上我面临了 3 个风险因素:
说实话,如果公司内部出现类似问题,大多数情况下可能出现项目延期上线,但这个锅总得有人背,而我不想背。现在手头上的资源留给我的不多,除了我,还有一位直接跟客户打交道的 BD,一位新入职的产品经理,然后是每天忙的挤不出时间的业务线同事和测试。要如何最大化去发挥现有资源呢,达成目标呢?
领导力(Leadership)指在管辖的范围内充分地利用人力和客观条件在以最小的成本办成所需的事提高整个团体的办事效率的能力。
我作为 PM,当时用了 4 个步骤来解决:
上面并没有把我自己的加班算进去的,那段时间的每一分钟都很宝贵,每个晚上都工作到了凌晨,白天起来不断的线上拉群讨论,线下沟通需求。最终,项目还是比原计划晚了 2 天验收,因为解决定位 Bug 消耗了较多时间,但是最终成果还是让上级很满意的。
在面临项目难点时,领导力能够在一定程度上帮助团队去克服资源不足的问题,你需要做到的是拿出一份科学有效的资源规划,随机应变的往目标靠拢。
我分享的第三个案例是关于如何跟新人一起协作推动项目发展的。新老结合的团队其实是很合理的组织结构,新人给团队带来活力和新鲜血液,老人则给团队持续积累底蕴,如果沟通恰当合理,将会给团队带来巨大的凝聚力,提高团队产出。
沟通理解能力包含了:表达能力、倾听能力和设计能力,做到团队成员的高效协作,我认为做到耐心倾听和准确表达足矣。
前不久团队来了一位新同事,一位非常优秀的前端同事,对很多问题都有自己独特的见解。在入职满 1 个月后,我们一起合作做了个需求(一个历史包袱比较重的功能迭代)。
常规发布流程如下:
预计是 1 周后发布灰度环境,但是各种问题不断暴露出来后,发现前端开发已经赶不上迭代发布的速度了。我们面临了两个选择:要么延迟发布(功能下个版本发布),要么灰度环境进行兼容(让用户无论在 pro 环境还是 staging 环境,都保持使用同一个功能)。
这是一个惊醒我的案例,也给我很大的启发,如果没有那次延迟发布,是不是问题就被暴露给用户呢。
那么有什么好的办法预防类似问题吗?有的,我复盘了一下,我跟同事都有可以做的更好的地方:
在新老结合的团队中,保持同事间良好的沟通理解,能有效降低项目迭代上线的风险,让彼此工作都保持活力。
其实产品思维是很多开发岗位的隐藏属性,但不说明它不重要。身为技术人,我们不害怕需求,但我们害怕产品经理们没有找到用户的真实需求,这最终会导致研发投入大量时间和精力,开发了一个无用的功能。
举个案例,过去有位产品同事问过我,这个迭代能不能增加一个需求--“在 PC 端提供个管理页面浏览实时用户数据”,这个需求很合理,但是没有必要,因为我们以前就有个功能:支持用户实时数据导出文件。
当时我手头上还有其他要上线功能,无论我主观想法多强烈,客观上都没有多余精力和实际去临时开发个新功能。一个合格的 PM,应该可以恰当让同事清晰了解到问题原因,并提出解决办法。所以,我并没有一口回绝,而是仔细思考了一阵子(这个思索的过程很重要,说明你的重视态度),再回复产品:
最后,产品满意的回去答复一线需求了,而用户确实也是有这个真实的需求。
作为一个合格的 PM,在掌握好自己手头的业务同时,要学会总结在行业内摸打滚爬的经验,把沟通交流的话术整明白了,这将会无形中锻炼我们的产品感和沟通技巧。
总结
以上是我根据项目管理的书籍资料,结合自己的项目实战经验,进行的一次总结:
真实研发流程往往会面临更多特殊的情况,文章分享的几个案例仅是抛砖引玉,我们一起加油努力~~