一个项目的坎坷一生

大家好，我是苍何。

目前呢，主要是负责部门的项目管理和团队管理相关工作，今天想和大家分享一下企业级标准的项目管理流程以及苍何的实践。

通过本文，能帮助你更快的在企业中上手项目并定位好自己的角色，别人一脸懵逼，你却早已遥遥领先✈。

大家是否想过一个问题，一个项目为什么要管理呢？

之所以要管理，是因为通常一个项目需要多人协同共同完成，也会涉及多个岗位和角色，比如 UI、产品、开发、测试、运维等，那多人共同完成一个项目，没有完整的项目管理流程就会乱了套，东做东的，西做西的，最后可能会面临项目延期的风险。

由于 PmHub 项目就只有二哥和我两人，但我们同样遵循大厂的项目管理流程，该有的一个不能少，只是我们两充当了很多的角色而已。

在说 PmHub 项目管理流程之前，还是有必要给大家讲一下正规公司应有的项目管理流程。

企业级标准项目管理流程

先来看一张完整的项目管理流程图：

可以看到企业级标准项目管理流程一共可以分为 5 个阶段，分别为：立项阶段、需求阶段、开发阶段、测试阶段、上线发布阶段。

立项阶段

通常立项会有项目启动大会，我们习惯称之为 kick off，立项里面的工作内容通常包含团队组建，计划确定及 kick off。

团队组建是最考验项目经理及领导水平的环节，通常一个项目需要多少人力资源是要经过充分评估的，还需要上几次会议。在招人方面，技术是衡量的一方面，另外更重要的是「感觉」。

有时候感觉对上了，就对上了，毕竟是要一起征战的，所以招人方面感觉很重要。

团队组建后，需要制定相应的计划排期，通常也会和需求一块做，需要制定计划评估工期。等一切都完结后，就是令人激动的誓师大会了（像极了誓师大会）。大会结束后，一切尘埃落定，就会来到下一个环节。

需求阶段

这个阶段基本是产品经理发挥用武之地，但其实也是整个产品和项目最核心的环节，就像是订好方向一样，通常这个阶段需要写很多的文档，以下这些文档需要有个印象：

• BRD：商业需求文档，有点类似于商业计划书，一般重大项目或者大公司会写。
• MRD：市场需求文档，包含市场分析报告、竞争对手分析等信息。
• PRD：这个就是经常听说的产品需求文档了，大部分项目可能都只有一个 PRD 文档或者是将 BRD 和 MRD 统一结合到了 PRD 里面（我觉得是产品经理为了省事，但这有时候没什么不好）
• FSD：功能详细说明，有点类似用例文档，一般很少有正经人写，通常放在了 PRD 里面，用以说明产品界面和业务逻辑的细节。

每个公司或项目并不会都写这么多文档，比如我在阿里就最多只见过 BRD、MRD 和 PRD，大部分项目往往只有一个 PRD，当然了如果你们公司连 PRD 都没有，那确实有些不按套路出牌了。

最需要扯皮的地方是需求评审会议，大家以后工作开这种会，一定要认真，小心被下套，仔细评估需求，哪些能做，哪些不能做，需要多少时间心里一定要有数，通常是技术负责人来扯皮 battle，如果你遇到一个什么都「好好好」的 leader，那相信我，你会很惨。

开发阶段

开发阶段其实就是程序员该正式干活的时候啦。

稍微大点的公司，接到需求后，不会立马就开发，而是会写系分文档，也就是系统分析文档，如果你还不会写，也不知道具体模板，可以在语雀模板中新建自己试着写一写。

比如 PmHub 在开发之前也是写了系分文档的，并且我是建议我组内的小伙伴都最好写，在开发之前脑子里面有数，并做好设计，会极大的提高开发效率。

我觉得最主要的事要包含系统设计流程图、架构图、数据库设计、API 接口设计以及排期。

写完系分设计，需要进行评审，会拉上组内的开发和测试进行评审，这个时候 PD（产品经理）可以不参加，有些不懂技术的产品，参加了没什么用。

最主要的是大家都认可你的设计。特别是前后端需要对接接口规范等。

一切顺利后，才可以开始编码，大家可以看到，编码其实是后面的环节，用我以前同事的话来说就是，“文档会议搞几天，编码就 1 天”。

也就是一切都设计好后，编码起来其实是很快的，出问题的概率也会低很多。

通常在大公司都会要求开发自己写单元测试，但现在听说单元测试这事全部交给 AI 来完成了，真是大快人心，要知道以前苍何光写这玩意就花费不少时间。

PmHub 没写，但不排除有时间会用 AI 加上的可能性，感兴趣的小伙伴也可以自定添加并提交 PR，一起参与进来维护哦。

测试阶段

早在刚工作的前几年，对测试比较痛恨，因为以前总是相信自己的代码不会出现问题，结果每次都测出来有问题，搞的人还不自在。

关键有些测试，爱专牛角尖，觉得自己找出来个 bug 就牛逼哄哄的，一副把自己高高在上的样子。

但随着经验的丰富，我开始有些观念的转变，我开始看中测试这个岗位，没有好的测试，产品是个不完善的产品，也终究走不远。所以我们团队，我直接搞了 2 个测试，追求极致的产品。

测试阶段通常需要写测试用例，一般会在系分评审之后，也有些是同步进行，也就是在 PRD 出来之后，开发和测试都要同时写文档了。

用例评审也是很关键的，作为开发需要仔细听，确认和需求是否有出入。评审完他们会按照测试用例来进行冒烟测试，当然有些还有黑白盒测试等，在上线后，哈需要进行线上回归验证。

通常是在 TAPD 或者禅道中进行 bug 的管理，这是企业中用的比较多的，但大公司通常有自己的管理方式。

上线发布阶段

我当年在蚂蚁，上线之前可是要做一堆的工作，先是要提上线评审，经由 leader 以及各方面负责人同意过后，要在平台上做发布前的一堆准备工作，数据库、灰度环境、回滚策略、影响范围等。

总之上线前的这一堆流程走下来，我都够吃好几桶泡面的时间了（手动狗头）。

总结下来，就以下 9 字箴言：

可监控、可灰度、可回滚！

上线后一定要能监控系统性能，通常我们会有测试来把控，可灰度意思是可以灰度小批量流量先进来测试，防止大批量流量进来后导致系统奔溃。

可回滚是指的，一旦出现问题，能有迅速的回滚方案应急。

上线到正式环境前，通常还会有预发布环境，预发布环境用的和生产通常是一个库，用来专门模拟生产数据，做最后一轮测试。

发布到线上后，还需要做一轮回归测试，之后才可以放心的给用户使用。越是分工明确的公司，上线发布流程就会越复杂。

PmHub 项目管理流程

立项阶段

PmHub 是我和二哥一起参与的开源项目，所以人员组建方面就我们两，计划主要我负责来制定，如果要说项目启动大会，我想是在 2024-03-03 号，会议就我们两，但该安排的计划一个没少。

需求阶段

我们是直接在语雀上进行的需求管理，两个人效率会高很多，基本上需求明确，没有过多扯皮的事情发生。

每周二我们都会进行一次会议。

当然了我们还有 PRD 文档以及产品原型设计稿，

人少有人少的好处，但人少进行评审的时候，能听取到的不一样的声音相对应的也会少，对评审来说，有不同的声音能激出更多的火花来。

开发阶段

PmHub 最主要的开发量是在后端流程及项目服务，前端和其他的用户管理都是用的若依那套，你如果熟悉的话了解起来更快。

在开发阶段，我们写了系分文档，也进行了评审，虽然不是大公司的项目，但 PmHub 毕竟是作为企业级开发项目，该有的一样都不少。

这也方便你在面试的时候和面试官吹，你就是 PmHub 的开发成员之一。

整个开发工作特别是微服务改造工作是复杂的，因为我们人少，再加上都是兼职，都是下班和周末搞搞，所以效率整体比较一般。

算下来估计真正开发的时间，满打满算，也就是 2 个月左右。

测试阶段

项目开发完毕后，我和二哥会开始体验适用，去找 bug，我们就直接用的语雀进行的 bug 管理，就 2 个人比较随意一些，但基本上够用了。

下面是我们的 bug 池子：

由于上线 2 个版本，单体和微服务，所以有时候兼顾的不过来，如果你发现项目中的 bug，可以在 GitHub 上反馈给我们，会记录在缺陷池子里面。

发布阶段

发布上线是我来完成，因为有线上体验地址，且微服务真的吃内存，我的那个小服务器根本顶不住，于是咬牙，花了 1000+ 加了配置，就是为了打造一个真实的体验地址。

但依旧不敢火力全开，毕竟还是内存有限，等最大做强有经费了，我会考虑再升级配置，目前只能将就着用了。

上线发布后，我们还内测打磨了接近一个月，官宣文案、优化展示、最后是大家看到的 PmHub。

整个推广，我们目前只是在公众号推广，算是小批量公测吧，后面我们通过迭代打算多在其他一些平台推广，当然了小伙伴们如果觉得 PmHub 确实有帮助到你，或者帮助到你拿到了 offer， 也可以帮我们宣传宣传哈，感谢。

结语

通过这篇文章，大家应该知道 PmHub 是如何从 0-1 慢慢孵化出来的吧，所以一个好的项目的产出，真的不容易，至少近半年来，我的业余时间基本全部投入到 PmHub 上了。

大家看了标准的项目管理流程后，结合 PmHub，面试的时候也有的放矢，最关键的是，进入企业中，也会得心应手，这是我们希望达到的目的，以上，感谢阅读。