1. 从 OKR 说起

2021 年初，我们部门制定了第一季度的 OKR。过完年回来，OKR 涉及到的项目陆陆续续正式开展起来。分配到我个人身上的有下面两个项目：

• App 可视化全埋点自定义属性；

• SDG（Sensors Data Governor，中文名：神策数据治理） 技术架构演进。

这两个项目都是由我负责跟进，因此一个程序员的项目管理之路就此拉开帷幕。

2. 可视化项目

首先说说比较熟悉的「App 可视化全埋点自定义属性」项目，因为个人是 Android 研发，从技术栈的角度来说，对于该项目更加熟悉。在项目启动之前，也参与过「App 可视化全埋点」其他几期的研发，整体来说比较有信心。

2.1. 大道至简

该项目的特征是产品主导，需求细节特别多，市面上基本无可借鉴的设计，产品的每一步设计都可谓是从零到一的突破。

这里我们需要解决的一个核心问题是：怎么把产品打磨的更好用？为了解决该问题，产品同学对需求文档修改次数达到 300 次以上。我们的终极目标是要让产品的使用符合人性、符合习惯，最大程度地降低用户对产品的学习和理解成本。最终产品上线时，我们认为达成了这个目标。

2.2. 有限时间内创造无限可能

2.2.1. 前端工作量太多

需求文档定稿在 3 月初左右，距离上线仅有不到两个月的时间。整个项目的关键路径是前端，前端开发工作量初步预估就要一个半月。并且，在 3 月初该研发工程师还有其他任务，怎么办？

经过沟通，我们研发组内达成一致：SDK 研发主导方案设计，前端研发进行确认。通过这种方式，极大地释放了前端的人力，由 SDK 研发主动承担额外工作量，保障整体项目的有序开展。

2.2.2. 总有一些意外

做完排期后，正当一切按照我们的计划正常推进时，在 3 月中旬接收到一个消息：前端的研发工程师因个人原因计划到 3 月底离职。整个项目的前端就一个研发工程师，如果在 3 月底离职，将直接导致整体计划全部失去意义。怎么办？

为了解决这个问题，我的脑海里出现了两种解决问题的方案：

• 尽快找到其他前端研发人员接手；

• 协调即将离职的人员延缓离职时间，把核心模块开发完成后再走。

在明确了项目组资源捉襟见肘的前提下，我开始找这位同学进行沟通。此时，第一次发现沟通的结果将如此重要：直接决定了整个项目组是否能达成目标。

基于之前项目长期合作积累下来的信任，以及站在对方角度考虑问题的思路，我们达成了共识：延迟半个月离职。我知道这个决定对于一个即将离职的人付出了多少，直到现在，仍然想和他说一声谢谢。同时，开始着手安排新的前端研发来进行交接，达到平稳过渡。

2.2.3. 和时间赛跑

时间过得很快，转眼整体开发即将结束。因为前端工作量客观上来说确实太多，无法按照预定的时间进行提测，相较于计划需要延期两到三天。此时，测试同学已经做好测试的准备，怎么办？

为了解决这个问题，我们首创了分批提测的方式：

1. 已完成部分功能的 SDK 先进行提测，和测试同学沟通优先测试 SDK 的相关功能；

2. 等到三天后，前端进行二次提测，再进行整体功能的测试。

虽然从测试角度来说该举措带来了一定的风险性，但是在当时的环境下，这是我们和时间赛跑的一个有效手段。

到现在依然记得，在项目组里我们有一种共同的感受：每一天都是在和时间赛跑。

3. 技术重构项目

「SDG 技术架构演进」狭义的理解就是对后端进行一次技术重构，该项目和上述项目的一个本质区别在于：这是技术驱动，而非产品驱动。对于我个人而言，该项目是首次接触。同时，从技术栈的角度来说，后端的知识也不太了解。整体来说，这个项目的挑战性相对于上述项目来说不是一个数量级的。

3.1. 会议纪要真的很难

在没做这个项目之前，一直认为做会议纪要真的太简单了，会议上一些重要的结论记录下即可。可是，第一次开会我就彻底懵了：后端研发同学和跨产品线的同事梳理接口现状、明确依赖哪些接口、接口的提供时间等。一场会议下来，将近有三四十个接口，各种英文单词缩写，完全不了解含义，对于结论也不是特别明确。因为研发同学他们要集中精力沟通和梳理问题，会议纪要由我来记录比较合适，怎么办？

我开始恶补后端相关知识体系，从代码层面到架构层面。虽然不懂具体实现，但是起码要了解到各组件的名称、含义、作用。有了这些基础后，在会议之前把有可能涉及到的词汇和接口名用模板建立好。在会议过程中，我开始学着速记，比如单词用首字母代替。后续对于自己不太确定的结论，会进行重述和二次确认，达成一致后再记录到纪要里。形成纪要后，再和研发进行确认和梳理。这样，会议纪要就完成了。

也许有人会问：为什么需要这么麻烦的记录会议纪要？因为前期大家对于项目现状、问题、期望往往是模糊的，需要通过一次次沟通去梳理清楚这些问题点，而承载的产物就是会议纪要。

3.2. 往前推动一点点

由于本人是研发出身，性格也不是特别 Open。在推动跨产品线配合时，还是存在一定的顾虑。比如各端同学是否有时间、没有收到消息回复直接去电是否会产生打扰等。

在前期推动的过程中，发现如果顾虑太多，本可以当天开始的会议将会延到第二天，一个上午的会议将会延期到下午。意识到这个问题后，怎么办？

克服自己的杂念，改变错误的主观感受，以一个纯粹的态度来处理事情。慢慢逼着自己去往前推动一点点，到后面就会发现很多事情豁然开朗，因为你认清了自己。先审视自己的内心，试着了解真实的自己，再慢慢的去改变自己，这个过程一定是痛苦的，但带来的收益是巨大的，你会找到一个崭新的世界。

3.3. 让协作更加舒服

前期和其他产品线配合的时候，我们依赖对方的一个接口，之前已经约定好了联调的时间点。到了那一天，对方按时给我们提供了服务包。不仅如此，对方还给我们提供了一份接口调用说明文档，包括调用的示例和环境的相关部署。从这个小点，我一下子想了很多，为什么他可以做到这一步? 也许很多人都可以做到按时提供接口，但他在这个基础上多做了一步：提供调用示例和使用说明。这样，我们在使用时完全不需要二次沟通，十分顺利的进行了集成。此时我在想：我们能不能做到？

从这一刻开始，我们也开始考虑如何让协作的更加舒服、超出预期。后续我们采取了很多动作：提供一个表格，标注了依赖事项和期望对方提供的时间节点。达到的效果是双方不用沟通，直接在表格里填写就能实现双方的意图。这样省去了沟通的时间，提升了双方的协作默契度和效率。

3.4. 发现问题、解决问题

在项目的进行过程中，我有一个深刻的感受是发现问题、解决问题。其中，很难做到的往往是发现问题。很多人通常看不到眼前的问题，因为思维惯性告诉我们这一切理所当然。比如在项目早期，我们的例会形式是围绕着 BigPicture 展开，在 BigPicture 里可以直观地看到研发任务的具体状态。通过例会，我们检查实际的进度和计划是否有出入。到了后期，项目进入到测试阶段，此时我们的问题是如何保证整体 Bug 修复进度是符合预期的，此时 BigPicture 已经解决不了这个问题。因此，我们的例会形式转换为每天过 Jira 看板，针对具体的 Bug，明确当前状态以及修复计划。

4. 项目经理的三个意识

经过了这两个项目的锻炼，对我本人来说是受益匪浅的。这里我总结了下，项目经理需要具备三个意识：大局意识、危机意识、服务意识。

4.1. 大局意识

项目经理不能被流程所束缚，而要去理解流程背后的原始诉求。要了解流程的初衷，而不是记住当前的形式，只有这样，才能真正理解为什么需要流程。总有一些标准是别人给不了你的，总有一些规则是需要你来设定的。在项目的进行过程中，要始终站在全方位角度来思考问题、解决问题。不能局限于细节，要始终让自己具有大局观。比如一个人由于自身没有空，问题解决不了，你非要和他死磕么？可以选择绕过去，找到其他人来解决该问题。

4.2. 危机意识

研发可以对沟通中的分歧进行妥协，项目经理需要识别出本次分歧背后的根本原因，并进一步评估是否会产生其他的影响。项目经理经常需要考虑的一个问题是：出现了延时，我们该怎么应对？

没有完成项目的最终交付，任何一个环节都可能出问题。因此，我们要有危机意识。

4.3. 服务意识

在项目的进行过程中，经常会出现一些真空区：严格意义上没有明确的责任人，但是必须有人去做。比如约会议、写文档。我们要能牺牲个人的时间，成就大家的时间，让这些专业的人有时间去做专业的事：

1. 和第三方进行对接时，我们是否可以把文档建立好，提供表格供别人填写？这样对接方不用沟通便知道自己该怎么配合；

2. 提供产物给第三方时，我们是否可以提供一份集成文档，让别人不用问你便知道如何集成，用文档来降低沟通的成本；

3. 研发说自己没有时间，我们是否可以和他的上级沟通，协调他近期专心地去做这一件事情。去解决实际的问题，而不是一味地催进度。

5. 我眼中的项目经理

以我目前的经验来看，项目经理不仅仅是项目风险的控制者和项目进度的跟进者，更要能做到主动地发现问题、分析问题、解决问题，真正给项目组同事带来实质性的帮助。

就像电影《食神》里提到的：人人都可以是食神。我的理解是：人人都是项目经理。无论工作还是生活，把一件事当成一个项目来跟进：有目标、有计划、有结果。

在这个过程中客观地审视自己的内心、了解自己、改进自己，一定能够成就更好的你。

文章来自公众号——神策技术社区