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. 和工夫赛跑

工夫过得很快，转瞬整体开发行将完结。因为前端工作量主观上来说的确太多，无奈依照预约的工夫进行提测，相较于打算须要延期两到三天。此时，测试同学曾经做好测试的筹备，怎么办？

为了解决这个问题，咱们独创了分批提测的形式：

已实现局部性能的 SDK 先进行提测，和测试同学沟通优先测试 SDK 的相干性能；
等到三天后，前端进行二次提测，再进行整体性能的测试。
尽管从测试角度来说该动作带来了肯定的风险性，然而在过后的环境下，这是咱们和工夫赛跑的一个无效伎俩。

到当初仍然记得，在项目组里咱们有一种独特的感触：每一天都是在和工夫赛跑。

3. 技术重构我的项目

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

3.1. 会议纪要真的很难

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

我开始恶补后端相干常识体系，从代码层面到架构层面。尽管不懂具体实现，然而起码要理解到各组件的名称、含意、作用。有了这些根底后，在会议之前把有可能波及到的词汇和接口名用模板建设好。在会议过程中，我开始学着速记，比方单词用首字母代替。后续对于本人不太确定的论断，会进行重述和二次确认，达成统一后再记录到纪要里。造成纪要后，再和研发进行确认和梳理。这样，会议纪要就实现了。

兴许有人会问：为什么须要这么麻烦的记录会议纪要？因为后期大家对于我的项目现状、问题、冀望往往是含糊的，须要通过一次次沟通去梳理分明这些问题点，而承载的产物就是会议纪要。

3.2. 往前推动一点点

因为自己是研发出身，性情也不是特地 Open。在推动跨产品线配合时，还是存在肯定的顾虑。比方各端同学是否有工夫、没有收到音讯回复间接去电是否会产生打搅等。

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

克服本人的杂念，扭转谬误的主观感触，以一个纯正的态度来解决事件。缓缓逼着本人去往前推动一点点，到前面就会发现很多事件恍然大悟，因为你认清了本人。先扫视本人的心田，试着理解实在的本人，再缓缓的去扭转本人，这个过程肯定是苦楚的，但带来的收益是微小的，你会找到一个簇新的世界。

3.3. 让合作更加难受

后期和其余产品线配合的时候，咱们依赖对方的一个接口，之前曾经约定好了联调的工夫点。到了那一天，对方按时给咱们提供了服务包。不仅如此，对方还给咱们提供了一份接口调用阐明文档，包含调用的示例和环境的相干部署。从这个小点，我一下子想了很多，为什么他能够做到这一步? 兴许很多人都能够做到按时提供接口，但他在这个根底上多做了一步：提供调用示例和应用阐明。这样，咱们在应用时齐全不须要二次沟通，非常顺利的进行了集成。此时我在想：咱们能不能做到？

从这一刻开始，咱们也开始思考如何让合作的更加难受、超出预期。后续咱们采取了很多动作：提供一个表格，标注了依赖事项和冀望对方提供的工夫节点。达到的成果是单方不必沟通，间接在表格里填写就能实现单方的用意。这样省去了沟通的工夫，晋升了单方的合作默契度和效率。

3.4. 发现问题、解决问题

在我的项目的进行过程中，我有一个粗浅的感触是发现问题、解决问题。其中，很难做到的往往是发现问题。很多人通常看不到眼前的问题，因为思维惯性通知咱们这所有天经地义。比方在我的项目晚期，咱们的例会模式是围绕着 BigPicture 开展，在 BigPicture 里能够直观地看到研发工作的具体状态。通过例会，咱们查看理论的进度和打算是否有出入。到了前期，我的项目进入到测试阶段，此时咱们的问题是如何保障整体 Bug 修复进度是合乎预期的，此时 BigPicture 曾经解决不了这个问题。因而，咱们的例会模式转换为每天过 Jira 看板，针对具体的 Bug，明确以后状态以及修复打算。

4. 项目经理的三个意识

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

4.1. 大局意识

项目经理不能被流程所解放，而要去了解流程背地的原始诉求。要理解流程的初衷，而不是记住以后的模式，只有这样，能力真正了解为什么须要流程。总有一些规范是他人给不了你的，总有一些规定是须要你来设定的。
在我的项目的进行过程中，要始终站在全方位角度来思考问题、解决问题。不能局限于细节，要始终让本人具备大局观。比方一个人因为本身没有空，问题解决不了，你非要和他死磕么？能够抉择绕过去，找到其他人来解决该问题。

4.2. 危机意识

研发能够对沟通中的一致进行斗争，项目经理须要辨认出本次一致背地的根本原因，并进一步评估是否会产生其余的影响。项目经理常常须要思考的一个问题是：呈现了延时，咱们该怎么应答？

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

4.3. 服务意识

在我的项目的进行过程中，常常会呈现一些真空区：严格意义上没有明确的责任人，然而必须有人去做。比方约会议、写文档。咱们要能就义集体的工夫，成就大家的工夫，让这些业余的人有工夫去做业余的事：

和第三方进行对接时，咱们是否能够把文档建设好，提供表格供他人填写？这样对接方不必沟通便晓得本人该怎么配合；
提供产物给第三方时，咱们是否能够提供一份集成文档，让他人不必问你便晓得如何集成，用文档来升高沟通的老本；
研发说本人没有工夫，咱们是否能够和他的下级沟通，协调他近期分心地去做这一件事件。去解决理论的问题，而不是一味地催进度。

5. 我眼中的项目经理

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

就像电影《食神》里提到的：人人都能够是食神。我的了解是：人人都是项目经理。无论工作还是生存，把一件事当成一个我的项目来跟进：有指标、有打算、有后果。

在这个过程中主观地扫视本人的心田、理解本人、改良本人，肯定可能成就更好的你。

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