项目管理实践篇（二）：技术型 PM 炼成记

后台技术汇

关注

发布于: 4 小时前

1、前言

今年满打满算，是 17 年毕业之后的第 4 个年头了。4 年时间很长，经历的人和事数不过来；4 年时间太短，想打造自己的专业能力还要假以时日。我一直在思考，程序员到底在互联网这条路上能够走多远呢？

梳理一下职业发展的头 4 年：

毕业转行到互联网，恶补基础入门门槛；【1 年时间】
在项目迭代过程中，不断打磨业务能力和沟通能力；【2 年时间】
在项目性能优化中，逐渐深入技术底层，培养架构师思维；【1 年时间】

但总觉得自己所学仍旧不太够，所以借助不同的工具来学习知识，促使自己求变求存。

之前也总结过项目管理的相关文章，欢迎指点~

《学点项目管理，对咱程序员很重要》

《项目管理实践篇（一）：技术人如何做好风险把控》

我们日常开发中是否遇到过这些场景：

1、项目从立项开始就需要多个开发团队一起参与讨论，设计如何让所有模块跟数据打通？

2、你的团队依赖他人的模块对外能力，如何有效组织一场会议去讨论实现难度？

3、你在和别人进行开发排期时，说好是截止今天交付功能，为何到期了对方还是实现不了？

1.1 什么是 PM？

PM 是团体机能概念，任何一个团体都具有两种机能：一种是 P（performance），指工作绩效，是团体的目标达成机能；另一种是 M（maintenance），指团体维系，是维持强化团体或组织的机能。

1.2 我对 PM 的理解

我们常常讨论 PM 这个角色时，更多的就是组织、沟通、协调，预定会议、组织聚餐、项目周报等杂活。现实也是如此，我以前接触过的 PM，更确切说是偏向于 BD（Business Developer）的 PM。

但是，难道只有把 pmp 的 200 道单选题刷完，或者把项目管理相关的书籍都看一遍，才算一名合格的 PM 么？这个答案显然是否定的。

在几个月前，我参加了某次项目管理的培训课程。当我问起老师，“程序员有办法成为一名技术型 PM 么”，培训讲师微微一笑，当然可以，事实上他本人就是从 8 年后台技术研发，转型成了一个专业 PM。他补充回答，不是非得照本宣科将理论套用到生产实践，才算一个合格的 PM，一个成熟 PM 需要深刻理解项目痛点并推动解决，而完成这个目标，实际上用到的理论知识可能只有书本上的 20%。由此可见，PM 其实是更倾向于实战经验的岗位，我们技术人要对成为一名合格的 PM 抱有充分信心。

2、技术型 PM 是如何炼成的？

2.1 PM 能力要求

先看一份从 boss 参考下来的 JD：

其实这本质上就是一个技术型 PM 的岗位描述：

林林总总的技术点，突出技术能力要强；
白纸黑字，团队管理能力（领导力）优先；
白纸黑字，沟通理解能力很重要；

结合这个岗位要求，我结合自己亲身经历的四个真实案例，谈谈我对“如何成为合格的 PM”的实践和理解。

2.2 PM 能力模型

技术能力：talk is cheap，show me your code。
沟通能力：对象是开发团队，上级 leader，售前售后人员，运维人员，测试人员。
领导力：对象是公司上下游团队，结果为驱动的工作模式。
产品感：对象是产品，本质需求是什么，需求实现是否合理。

2.3【案例 1】技术能力：一个底层模块的有效维护和迭代

2.3.1 PM 必备技能：学会借力，成果共赢

第一个案例是，我刚毕业转行，然后去到老东家时，当时团队大佬离职，所以决定把这个相对稳定的消息模块给资历较浅的我，可以一边维护一边学习。这是个难出成果和绩效的活，因为底层架构不牢固，每天有解决不完的 Bug 提给我，当时心中难免充满委屈。

后来逐渐抽空看懂了这块实现原理，明白到这个还真不是随便实现的业务模块，是个实打实的架构层代码，于是便一头扎进去研究起来。终于第二年随着公司业务升级，消息模块拆分为微服务作为项目重构的大事而被重视起来。

那么这么一个重构项目最后还是遇到了问题，要怎么去实施落地呢？我给自己排了满满的会议：

现有业务是怎么样的
为什么业务当初是这么设计
后面业务要优化成啥样
重构带来的数据迁移工作量和风险
将来业务如何拓展

几次会议讨论下来，好家伙直接把我整懵了；虽然这个模块我琢磨了一整年，但是将来要怎么设计迭代，我还真是一头雾水。眼看项目推进即将受阻，而我又是任务跟进里面的 PM，怎么办，这个重构项目要黄在我手上了么？

我当时用了 4 个步骤来解决：

提前梳理好消息模块的业务实现方案
提前搜集网上消息模块的解决方案
提前对比各个方案实现的优劣和实现难度，并以文档形式输出到团队，内部征求意见
死皮赖脸的缠着架构师和 leader 开会，让他们不断的优化意见

这 4 个步骤里面，我觉得最后一步骤是最有效的，因为项目遇到不可抗力很难推进时，学会借助他人的力量就很重要了。

对于架构师，在业务和架构上实现分工，架构师负责顶层框架设计选型，我负责实现上的各种细节；
对于 leader，给到确切的交付时间点，中间随时沟通开发进度和上线风险；

最终这个消息系统也成功完成交付，实现了架构升级，三方共赢（我完成项目开发任务，架构师有绩效指标，leader 可以向上交差）。

这是我第一次主动尝试扮演技术型 PM 的角色，通过这次磨练，除了技术水平得到了很大提升，还学到了一招法宝--“学会借力，实现多方共赢”，在有项目压力交付的前提下，有效的进行 push 和沟通。

2.3.2 PM 必备技能：提高自身技术能力

如果大家对这个消息模块比较感兴趣，可以参考下我之前的文章：《IM消息系统》。

提高技术能力是一个开放式命题，其问题本质应该是“如何高效获取技术知识，并且学以致用”。

学习技能知识平台：InfoQ 就是一个很棒的学习平台，极客时间客户端等
学习成果记录工具：公众号、博客、云笔记等
多种学习校验手段：面试、刷题

所以，有足够的技术能力是一名合格技术 PM 的首要条件，之前跟阿里的某位 P8 大佬有聊到一句受益匪浅的话--“每个人都是自己的 CTO”。所以，前路漫漫，一起努力吧~~

2.4【案例 2】领导力：一个人单挑业务大数据项目

要分享的第二个案例，也是给了我很大勇气和自信去尝试转型技术型 PM 的一次经历；

可能我们的某些同行经历过公司人手紧缺，而一线销售却在疯狂的接项目签合同，这个案例恰恰发生在这个背景下。

由于交付周期仅有 1 周~2 周时间，当时架构组加班给这个加急需求进行了开发方案评审，当进行到需求分发环节时，各业务线的开发人都表示手上已经有活在干，而我正好赋闲，于是底下 7 个业务开发同事的活都被推到我这边了。

所以我这边理想情况下要进行三向沟通：

一边跟产品经理
一边看业务人员写的代码
一边跟测试讨论用例的设计，会设计数据流的统计逻辑和底层结构

但是生活远比想象中要困难一点，实际上我面临了 3 个风险因素：

因为产品经理刚入职，业务熟悉程度甚至比不了我，所以往往是 BD 拉着我来跟产品进行需求评审（时间上比预想中还要紧迫）；
测试也是临时安排的，很多测试用例来不及细细评审，软件交付质量存在风险；
项目团队缺兵少将，PM 既是统筹项目进展，也是项目开发者，自我管理能力很重要；

说实话，如果公司内部出现类似问题，大多数情况下可能出现项目延期上线，但这个锅总得有人背，而我不想背。现在手头上的资源留给我的不多，除了我，还有一位直接跟客户打交道的 BD，一位新入职的产品经理，然后是每天忙的挤不出时间的业务线同事和测试。要如何最大化去发挥现有资源呢，达成目标呢？

领导力（Leadership）指在管辖的范围内充分地利用人力和客观条件在以最小的成本办成所需的事提高整个团体的办事效率的能力。

我作为 PM，当时用了 4 个步骤来解决：

设置长期目标：由多个短期目标完成，拆分为两个部分：需求开发（按简单->复杂的顺序排期开发）和数据同步（存量数据/增量数据同步）；
设置短期目标：研发实现一个“相对简单的需求数据指标”，同时前端配合联调，最小功能调试通过了，产品和 BD 及时介入评估需求完成度；（作用是：短周期开发要确保避免需求推倒重来，及时让产品和 BD 适应结果输出）
协调内部资源：因为数据算法来源于业务开发团队，数据指标是否合法取决于业务产品团队设计，我提前知道他们一周会议的安排，见缝插针去挨个 check 需求实现的难度；
协调外部资源：因为测试是另外一个城市的团队，沟通上有成本，所以我提前拉了一个群梳理好需求和风险点，让他们提前准备好测试用例，在一周内的后期投入时间去测试；

上面并没有把我自己的加班算进去的，那段时间的每一分钟都很宝贵，每个晚上都工作到了凌晨，白天起来不断的线上拉群讨论，线下沟通需求。最终，项目还是比原计划晚了 2 天验收，因为解决定位 Bug 消耗了较多时间，但是最终成果还是让上级很满意的。

2.4.1 PM 必备技能：懂得多角度协调资源

在面临项目难点时，领导力能够在一定程度上帮助团队去克服资源不足的问题，你需要做到的是拿出一份科学有效的资源规划，随机应变的往目标靠拢。

2.5【案例 3】沟通理解力：新老结合的团队如何推动日常迭代

我分享的第三个案例是关于如何跟新人一起协作推动项目发展的。新老结合的团队其实是很合理的组织结构，新人给团队带来活力和新鲜血液，老人则给团队持续积累底蕴，如果沟通恰当合理，将会给团队带来巨大的凝聚力，提高团队产出。

沟通理解能力包含了：表达能力、倾听能力和设计能力，做到团队成员的高效协作，我认为做到耐心倾听和准确表达足矣。

前不久团队来了一位新同事，一位非常优秀的前端同事，对很多问题都有自己独特的见解。在入职满 1 个月后，我们一起合作做了个需求（一个历史包袱比较重的功能迭代）。

常规发布流程如下：

预计是 1 周后发布灰度环境，但是各种问题不断暴露出来后，发现前端开发已经赶不上迭代发布的速度了。我们面临了两个选择：要么延迟发布（功能下个版本发布），要么灰度环境进行兼容（让用户无论在 pro 环境还是 staging 环境，都保持使用同一个功能）。

后来同事找到我，说明白了功能延迟发布的改动代价非常大，我听取了意见并建议优先把兼容功能的活先做了，再去继续完善新功能；（此时，离上线灰度还有 2 天）
后来同事又找到我，说因为精力放在了优先实现新需求，没有考虑到灰度和 pro 环境的业务兼容问题，显然我的意见并没有被他接纳。（此时，离上线灰度还有 1 天）
后来同事在发布灰度前火线完成了业务兼容，但是没有经过严格的测试流程，仅是代码层面的单元测试通过而已。（此时，已经准备发布灰度了）
我考虑再三，跟测试和运维同事沟通，容许延迟 1 天时间发布灰度，给测试在 test 环境验证业务兼容问题。（此时，灰度发布被我延迟了）
然后，非常出乎意外但在情理之中，灰度环境发现了一个比较严重的 Bug。（此时，灰度延迟发布，价值被体现出来了）

2.5.1 PM 必备技能：保持团队内有效沟通

这是一个惊醒我的案例，也给我很大的启发，如果没有那次延迟发布，是不是问题就被暴露给用户呢。

那么有什么好的办法预防类似问题吗？有的，我复盘了一下，我跟同事都有可以做的更好的地方：

后续功能开发时，双方都需要提前线下开会碰头；
对于开发步骤要保持协调，作为比较熟悉项目的一方应该多花时间确认新人对进度的理解程度，并给以指正；

在新老结合的团队中，保持同事间良好的沟通理解，能有效降低项目迭代上线的风险，让彼此工作都保持活力。

2.6【案例 4】产品感：让产品经理了解你对需求的态度

其实产品思维是很多开发岗位的隐藏属性，但不说明它不重要。身为技术人，我们不害怕需求，但我们害怕产品经理们没有找到用户的真实需求，这最终会导致研发投入大量时间和精力，开发了一个无用的功能。

举个案例，过去有位产品同事问过我，这个迭代能不能增加一个需求--“在 PC 端提供个管理页面浏览实时用户数据”，这个需求很合理，但是没有必要，因为我们以前就有个功能：支持用户实时数据导出文件。

当时我手头上还有其他要上线功能，无论我主观想法多强烈，客观上都没有多余精力和实际去临时开发个新功能。一个合格的 PM，应该可以恰当让同事清晰了解到问题原因，并提出解决办法。所以，我并没有一口回绝，而是仔细思考了一阵子（这个思索的过程很重要，说明你的重视态度），再回复产品：

这个功能如果没经过有效评审，就着手临时加紧开发，不仅不能有效确保功能交付质量，后期还会给产品带来新的设计麻烦；
我认为虽然一线 BD 着急的提出这个需求，但很可能是个伪需求，用户真实期望是一个数据载体；原因很简单，没有用户会守在 PC 面前死死盯着成千上万的数据，而是希望使用 Excel 等工具进一步去分析数据；
而我们恰好已经有这样的功能，可以支持用户导出他想看的数据，你看要不要先这样帮助用户解决他的问题呢？

最后，产品满意的回去答复一线需求了，而用户确实也是有这个真实的需求。