写点什么

一个程序员眼中的项目经理

发布于: 刚刚
一个程序员眼中的项目经理

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. 我眼中的项目经理

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

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

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


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

发布于: 刚刚阅读数: 2
用户头像

公众号:神策技术社区 2021.03.09 加入

公众号:神策技术社区

评论

发布
暂无评论
一个程序员眼中的项目经理