项目管理实践篇（二）：技术型PM炼成记
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。
2、技术型PM是如何炼成的？
2.1 PM能力要求
先看一份从boss参考下来的JD：
其实这本质上就是一个技术型PM的岗位描述：
林林总总的技术点，突出技术能力要强；
白纸黑字，团队管理能力（领导力）优先；
白纸黑字，沟通理解能力很重要；
结合这个岗位要求，我结合自己亲身经历的四个真实案例，谈谈我对“如何成为合格的PM”的实践和理解。
2.2 PM能力模型
2.3【案例1】技术能力：一个底层模块的有效维护和迭代
2.3.1 PM必备技能：学会借力，成果共赢
第一个案例是，我刚毕业转行，然后去到老东家时，当时团队大佬离职，所以决定把这个相对稳定的消息模块给资历较浅的我，可以一边维护一边学习。这是个难出成果和绩效的活，因为底层架构不牢固，每天有解决不完的Bug提给我，当时心中难免充满委屈。
后来逐渐抽空看懂了这块实现原理，明白到这个还真不是随便实现的业务模块，是个实打实的架构层代码，于是便一头扎进去研究起来。终于第二年随着公司业务升级，消息模块拆分为微服务作为项目重构的大事而被重视起来。
那么这么一个重构项目最后还是遇到了问题，要怎么去实施落地呢？我给自己排了满满的会议：
现有业务是怎么样的
为什么业务当初是这么设计
后面业务要优化成啥样
重构带来的数据迁移工作量和风险
将来业务如何拓展
几次会议讨论下来，好家伙直接把我整懵了；虽然这个模块我琢磨了一整年，但是将来要怎么设计迭代，我还真是一头雾水。眼看项目推进即将受阻，而我又是任务跟进里面的PM，怎么办，这个重构项目要黄在我手上了么？
我当时用了4个步骤来解决：
这4个步骤里面，我觉得最后一步骤是最有效的，因为项目遇到不可抗力很难推进时，学会借助他人的力量就很重要了。
对于架构师，在业务和架构上实现分工，架构师负责顶层框架设计选型，我负责实现上的各种细节；
对于leader，给到确切的交付时间点，中间随时沟通开发进度和上线风险；
最终这个消息系统也成功完成交付，实现了架构升级，三方共赢（我完成项目开发任务，架构师有绩效指标，leader可以向上交差）。
2.3.2 PM必备技能：提高自身技术能力
如果大家对这个消息模块比较感兴趣，可以参考下我之前的文章：。
提高技术能力是一个开放式命题，其问题本质应该是“如何高效获取技术知识，并且学以致用”。
学习技能知识平台：InfoQ就是一个很棒的学习平台，极客时间客户端等
学习成果记录工具：公众号、博客、云笔记等
多种学习校验手段：面试、刷题
所以，有足够的技术能力是一名合格技术PM的首要条件，之前跟阿里的某位P8大佬有聊到一句受益匪浅的话--
2.4【案例2】领导力：一个人单挑业务大数据项目
要分享的第二个案例，也是给了我很大勇气和自信去尝试转型技术型PM的一次经历；
可能我们的某些同行经历过公司人手紧缺，而一线销售却在疯狂的接项目签合同，这个案例恰恰发生在这个背景下。
由于交付周期仅有1周~2周时间，当时架构组加班给这个加急需求进行了开发方案评审，当进行到需求分发环节时，各业务线的开发人都表示手上已经有活在干，而我正好赋闲，于是底下7个业务开发同事的活都被推到我这边了。
所以我这边理想情况下要进行三向沟通：
但是生活远比想象中要困难一点，实际上我面临了3个风险因素：
说实话，如果公司内部出现类似问题，大多数情况下可能出现项目延期上线，但这个锅总得有人背，而我不想背。现在手头上的资源留给我的不多，除了我，还有一位直接跟客户打交道的BD，一位新入职的产品经理，然后是每天忙的挤不出时间的业务线同事和测试。要如何最大化去发挥现有资源呢，达成目标呢？
领导力（Leadership）指在管辖的范围内充分地利用人力和客观条件在以最小的成本办成所需的事提高整个团体的办事效率的能力。
我作为PM，当时用了4个步骤来解决：
上面并没有把我自己的加班算进去的，那段时间的每一分钟都很宝贵，每个晚上都工作到了凌晨，白天起来不断的线上拉群讨论，线下沟通需求。最终，项目还是比原计划晚了2天验收，因为解决定位Bug消耗了较多时间，但是最终成果还是让上级很满意的。
2.4.1 PM必备技能：懂得多角度协调资源
2.5【案例3】沟通理解力：新老结合的团队如何推动日常迭代
我分享的第三个案例是关于如何跟新人一起协作推动项目发展的。新老结合的团队其实是很合理的组织结构，新人给团队带来活力和新鲜血液，老人则给团队持续积累底蕴，如果沟通恰当合理，将会给团队带来巨大的凝聚力，提高团队产出。
沟通理解能力包含了：表达能力、倾听能力和设计能力，做到团队成员的高效协作，我认为做到耐心倾听和准确表达足矣。
前不久团队来了一位新同事，一位非常优秀的前端同事，对很多问题都有自己独特的见解。在入职满1个月后，我们一起合作做了个需求（一个历史包袱比较重的功能迭代）。
常规发布流程如下：
预计是1周后发布灰度环境，但是各种问题不断暴露出来后，发现前端开发已经赶不上迭代发布的速度了。我们面临了两个选择：要么延迟发布（功能下个版本发布），要么灰度环境进行兼容（让用户无论在pro环境还是staging环境，都保持使用同一个功能）。
2.5.1 PM必备技能：保持团队内有效沟通
这是一个惊醒我的案例，也给我很大的启发，如果没有那次延迟发布，是不是问题就被暴露给用户呢。
那么有什么好的办法预防类似问题吗？有的，我复盘了一下，我跟同事都有可以做的更好的地方：
2.6【案例4】产品感：让产品经理了解你对需求的态度
其实产品思维是很多开发岗位的隐藏属性，但不说明它不重要。身为技术人，我们不害怕需求，但我们害怕产品经理们没有找到用户的真实需求，这最终会导致研发投入大量时间和精力，开发了一个无用的功能。
举个案例，过去有位产品同事问过我，这个迭代能不能增加一个需求--“在PC端提供个管理页面浏览实时用户数据”，这个需求很合理，但是没有必要，因为我们以前就有个功能：支持用户实时数据导出文件。
当时我手头上还有其他要上线功能，无论我主观想法多强烈，客观上都没有多余精力和实际去临时开发个新功能。一个合格的PM，应该可以恰当让同事清晰了解到问题原因，并提出解决办法。所以，我并没有一口回绝，而是仔细思考了一阵子（这个思索的过程很重要，说明你的重视态度），再回复产品：
这个功能如果没经过有效评审，就着手临时加紧开发，不仅不能有效确保功能交付质量，后期还会给产品带来新的设计麻烦；
我认为虽然一线BD着急的提出这个需求，但很可能是个伪需求，用户真实期望是一个数据载体；原因很简单，没有用户会守在PC面前死死盯着成千上万的数据，而是希望使用Excel等工具进一步去分析数据；
而我们恰好已经有这样的功能，可以支持用户导出他想看的数据，你看要不要先这样帮助用户解决他的问题呢？
最后，产品满意的回去答复一线需求了，而用户确实也是有这个真实的需求。
2.6.1 PM必备技能：理解产品的真实需求
3、总结一下
以上是我根据项目管理的书籍资料，结合自己的项目实战经验，进行的一次总结：
真实研发流程往往会面临更多特殊的情况，文章分享的几个案例仅是抛砖引玉，我们一起加油努力~~
