PM成长系列之项目初探（上）

谁践踏了优雅 2023-10-03 11:03 21阅读 0赞

### 前言 ###

历时4个多月，横跨2个年头的文章终于出炉。自项目进入结项阶段，一直被催着写《PM成长之路系列》，没错，“系列”，似乎不会仅有一篇，我曾一度认为这是此文难产的原因。毕竟，一系列论文总是比一篇论文难写的，知道自己要写一系列论文，不免会进行思考：需要写哪些内容？以哪条线为主线来写？哪些适合出现在第一篇文章？情节和难度是否需要循序渐进？曾多次构思文章大纲，最终均无疾而终，曾想过以自己的项目流程来记录自己的经历与成长，却又不知从何入手。且因项目不同于传统开发项目，代表性尚未可知，担心误人子弟；自觉经验与能力太过浅薄，不足以指导他人的项目管理过程。灵感来自于师傅给的一张流程图，这张流程图可能不是最全的，却足以概括自己所经历的项目流程。就以此图来讲述自己的这段经历，此文可能只能覆盖一半的流程，毕竟得为系列的第二篇留有余地。

### 初识项目 ###

先简单概述我浅薄的经历，毕业后初入公司，有幸得到Boss的“赏识”，身为项目助理能负责一个项目，见证并参与了一个项目从0-1的全过程。这个项目是使用微软的低代码平台Power Platform搭建一个企业应用系统，与传统开发项目有所区别，代码量大大降低，但对业务流程的了解需求大大增加。这个过程并不是一帆风顺，项目进度曾一度滞后、团队之间也有过争议、客户也曾提出质疑，但在多方大力支持下，项目成功按时上线。

下图是上文提到的合同项目基本流程图，没有涵盖全部相关方（比如UI设计师、测试人员、运维人员等），也并未详细绘出所有阶段，但足以展示项目经理参与的大致环节及所做工作。流程图比较容易理解，在此就不做过多阐述。

![017a76ebf57e3e0fcacb19662ff8e54f.png][]

### 好记性不如“烂笔头” ###

初接洽项目，既不懂技术，也未接触过业务，在师傅带领下，参与了售前阶段数次线上需求对接会议。当然，这时的我尚且懵懂，仅作为听众，连听懂客户的需求都十分艰难，更别提为客户提出解决方案。我所能做的事情就是以录屏的形式记录下整场会议，事后对于客户的需求文档中不明确的地方反复倒带。当然，并不是推荐大家都以录屏或录音的方式来进行记录，一方面，会后重放录屏或录音并进行文档整理非常耗时；另一方面，容易产生依赖，从而忽略会议中的重点记录。但无论何种方式，一定的记录必不可少。

### 不妨“动手” ###

售前阶段的需求挖掘和确认、demo的制作与演示阶段，我作为旁观者进行围观学习。参与客户的需求会议、研读文档确实让我初步了解到客户业务，看师傅与开发小伙伴做出的demo以及方案也让我对低代码平台有了一个大体的认识，但真正了解低代码平台来源于师傅的“逼迫”——使用Power Platform做一个小demo。

接到这个任务的我深感绝望，对着官方入门指导文档一步步操作，却也不得其法，多亏小伙伴远程手把手教学，让我成功做出一个小的demo。现在想想，那个手忙脚乱的周末，确实让后面的工作进展的更加顺利，至少知道了如何使用Power Platform开发一个最简单的可用版本，如何创建数据实体、构建表单页面、定义自动化工作流、配置权限等。当然，在之后的低代码平台调研中，我才发现这几个步骤是使用低代码平台开发应用的普遍流程。不可否认的是，参与开发过程甚至写一段代码确实能让初入项目的PM快速入门，更好的进入项目状态。

### 字斟句酌 ###

很快，我被安排根据客户的RFP（Request for Proposal）写项目计划书，并参与投标准备。第一次写项目计划书，确实不知从何入手，只能寻求团队及公司过往案例与模板。从经验丰富的前辈那获得项目计划书案例，撰写初稿，开发小伙伴补充技术部分，销售小姐姐填充商务与公司资信部分，“吹毛求疵”的上司反复提供修改意见，最终完成了项目计划书并进行投标工作。需要强调的是，项目经理对于合同以及项目计划书中有关项目周期、里程碑、工作内容等必须反复斟酌，尽量确保没有争议。当项目即将进入运维阶段，收到客户的运维时间确认邮件时，我才意识到自己当初对于项目计划书中的内容并未全部了解，对于项目上线后三个月的运维支持和采购的一年运维支持之间的工作内容差异、时间节点并未明确。

### “一个坏的架构比没有强” ###

整个开发流程及需求分析采用了敏捷开发快速迭代的方式进行。为了能快速让用户看到一个基本的可用版本，我们将整个系统按部门及事件流程进行划分，先实现一个典型部门的一个事件流程，不断打磨这个流程，再以此进行复制，完成其他事件流程以及其他部门事件，需求分析也按照部门进行。看似毫无毛病，也符合敏捷的思想，但是这个过程中，我们进行的并不顺利。

首先，客户部门众多，每个星期对两个部门进行需求收集与分析，并将已开发出的基础可用版本为用户进行展示。一方面，极大增加了需求收集与分析的工作量，我们反复地为用户重复部门间通用的需求以及版本演示，一定程度也阻碍了开发的进度。另一方面，部门间需求差异较大，根据之前已有的需求做出的系统并不能满足其他部门的需求，这也是导致一个流程反复更改、最后甚至还原到之前的某版本的重要原因。

其次，我们过于重视流程细节，忽略了架构设计。对于现有低代码平台资源能否实现用户需求的担忧，使得我们过分重视可行性研究，大量精力集中于以一个流程为例实现全部功能，忽略了系统设计阶段。这个疏忽导致的结果在后续流程复制中暴露无遗，造成了大量的返工，虽然项目按原定计划成功上线，但确实付出不少的工作量。后续我们在复盘时，一个小伙伴笑谈：一个坏的架构总比没有强。

需求收集过程进行到三分之一时，我们意识到这样的收集过程不仅费时费力，且无法短时间获得全部需求，因此我们调整了策略，选择将后续剩余部门的用户一次召集，进行需求收集以及版本演示。当然这种做法在后续开发以及试运行阶段也暴露出问题，没有对剩余部门进行深入沟通，一些用户自己也没有意识到的需求被我们忽略了，直到用户使用已开发完成的系统时并给出反馈时，我们才了解到这个流程的真正业务内涵。

整个需求分析过程涉及的部门和人员众多，业务流程跨度也较大，但客户的项目经理，将所有事宜安排的井井有条。和其他部门一个开发小伙伴闲聊时问过一个问题：你对你们组项目经理怎么看？得到的回答让我颇为触动，“有他在，我们很安心，他可以将所有事情都安排好，我们只需专注开发就好。”这让我也想起了师傅曾和我说过的话“你作为项目经理，要为开发人员挡住干扰，让他们专注于写代码”。我想，“定海神针”般的存在是对一个项目经理最大的认可了吧。而我，还远着呢。

[017a76ebf57e3e0fcacb19662ff8e54f.png]: https://img-blog.csdnimg.cn/img_convert/017a76ebf57e3e0fcacb19662ff8e54f.png