在阿里当PM都须要作什么？Bella酱亲身经历告诉你！

有人说“一块儿在湖边吹过晚风的人，会记得更久一些吧”，那一块儿住过院的人，是否是能够刻骨铭心了？以前就想写篇文章总结一下本身前段时间当PM的经历呢，奈何发布了这个需求，还有另一个需求要发布，周末稍微有点时间了，又想睡觉续命，个人懒癌就又犯了:(哇哇，我也只是个孩子呀，咳咳，阿姨言归正传，因此因此，一拖再拖，直到在医院的这几天。

每个项目作完，或者跳出了一个温馨区，仍是要自我总结复盘下的，不是么？一来以一个局外人的身份，系统地看待下本身所作的这个事情，二则为本身之后回顾这段时光提供一些素材，否则，说不定之后本身会忘记呢~

如下来源于Bella酱在阿里当PM的经历的总结，若有不当，欢迎批评指正~

1.项目立项

作一个项目以前，你要清楚为什么要作这个项目，这个项目的价值和意义在哪里？若是是现有版本的大升级，那你还须要清晰的知道目前版本存在哪些问题，痛点是什么，扩展性如何，可维护性如何等等。同时还要肯定升级后的版本的目标，只有目标肯定了，后面技术方案选型的时候，你才会知道应该选取哪一种技术方案，由于你选的技术方案，要能足够实现你的目标。

对于中台项目而言，还要考虑2个问题，即兼容性和差别性。所谓的差别性，即指升级后的版本是否能够无缝兼容新接入一个行业？接入成本有多高？是否能够把一部分接入工做交由产品 or 运营同窗来作，解放一部分技术同窗劳动力？所谓差别性，即指升级后的版本是否能够支持不一样行业间存在的差别，是否能够作到相互隔离，互不影响。

通常状况下，我会选择用思惟导图来表达这些信息，图每每会比文字更简明直观一些，TL们的接受度也更高一些。

2.技术预研

这一阶段的主要目的就是基于上一阶段肯定的目标，调研哪些技术能够支撑你实现这个目标，这些技术理论上的可行可否最准转变为落地上的可行，能够拿当前业务场景以及数据作一个推演，数据推演ok以后，能够再作一个小的能够运行的demo，以证实该技术真正能够用在此项目中。

此阶段须要产出各个技术选型的数据推演图，若是推演过程比较复杂的话，也能够考虑再产出一份比较详细的Excel样式的数据推演图，每个步骤数据如何变化都要体现出来。另外，还须要产出各个技术选型可运行的demo。最后，须要产出各类技术选型的对比，表格形式或思惟导图形式均可以，切忌纯文字。基于上述对比，肯定最终的技术选型，而后就能够开始技术方案的编写啦~

3.技术方案编写

私觉得技术方案应该包含如下几部分，业务背景、场景分析、系统架构、应用架构、系统流程图、领域模型设计、存储模型设计、全局可用定义、功能模块设计、接口定义、项目里程碑等等，若是是须要出海的项目，还须要考虑下本地化方式、时区偏移、部署方式等等。

3.1 业务背景

业务背景主要是交代下作这个项目的背景，即为何要作这个项目，基于一个什么样的业务背景，也能够把【1.项目立项】中画的思惟导图直接放在这一pa。

3.2 场景分析

场景分析则主要是讲这个系统有哪些应用场景，若是可以列举出业务方的真实诉求，那是最好不过了。然而大多数程序员的生活，并不会直接对接业务方同窗，而是对接产品经理。

3.3 系统架构

系统架构推荐以图的方式来展现。开局一张图，剩下全靠讲，也不是不能够哈。Bella酱就有过这种经历，开局我放了一张图，而后看着大佬们讲了3个多小时。佩服佩服，那次经历也让我懂得，表达方式是何等重要。通常状况下我会这么画系统架构图，主要侧重于表达用了哪些中间件、什么数据源、什么应用、开放什么SPI、以及这其中各组件之间是如何交互的，最终能够支撑哪些业务。

3.4 应用架构

应用架构仍然推荐图的方式来表达。我通常这么画应用架构图，主要侧重于表达应用由哪些模块组成，每一个模块包含哪些功能，各模块之间的层次关系，哪些应用包含哪些模块。另外，这张图中也是能够把用了哪些中间件、什么数据源，支持哪些业务场景画上的，这样这张图会更完整一些，即便不看系统架构图，单单看这一张图，也是能够明白整个项目的设计的。

3.5 系统流程图

系统流程图以流程图为主，能够辅以文字说明，或者表格说明，因为这个和业务逻辑紧密相关，此处再也不举例。

3.6 领域模型设计

领域模型设计，这一阶段是很是有必要的，先肯定领域模型，后再根据领域模型肯定存储模型，并不是全部的领域模型都要转换为存储模型，从而保存到数据库中。领域模型设计过程当中，要十分清楚系统总体流程图，能够结合上个阶段的系统流程图，来推演一下，根据这些领域模型是否能够推演出系统的正常正确运行。图为主，辅以必要的文字说明此领域模型设计如何让系统运行便可。

3.7 存储模型设计

存储模型设计，须要详细到表中每一个字段的设计，字段类型、是否为主键、是否须要建索引、是否可为空、是否为分表字段等等。表结构设计表格展现便可。存储模型设计，仍是建议图片的形式表达，方便展现各表之间的关系。

3.8 全局可用定义

全局可用定义，主要定义一些通用的方法、枚举类、共同的约定等，以免各个应用or各开发人员定义一套本身的方法、枚举等，以确保同一个字段or同一个方法等在系统内惟一。

3.9 功能模块设计

功能模块设计，即各模块的详细设计，这里应该尽量详细，能够举一些例子，确保负责此模块开发的同窗看文档便可明白要作什么，以及如何作。必要的话，能够各模块再出一个详细的技术方案。

3.10 接口定义

接口定义，呐，很少作解释，记得写清楚入参、出参、接口名字，入参和出参记得用自定义类来接收，不要忘记实现序列化哟~

BaseResult、isSuccess、getData、getErrorMessage、buildErrorResponse、buildSuccessResp这些基础的类和方法也不要忘记呀！

3.11 项目里程碑

项目里程碑，即项目的时间节奏，例如开发时间、联调时间、提测时间、发布时间等，此时也应该肯定各类资源了，确保相关同窗能够在你计划的时间范围内投入项目中。

3.12 其余

若是你的项目须要出海，那你还须要考虑系统的部署方式、本地化、时区偏移、系统所需中间件是否支持等等。

4.项目过程把控

只有好的方案，项目过程把控不到位，最终也是没法交付一个使人满意的产品的。那如何才能使项目按照既定计划有序进行，同时又能保证交付的质量呢？

做为一个项目的owner，你须要作：

1. 技术方案要切实可行
2. 明确整个项目的时间节奏，每一个阶段应该交付什么可衡量的结果，每一个阶段之间的关联性，不能按时交付的影响
3. 明确每一个人所作的事情，每一个事情须要作多久，交付结果是什么
4. 是否可阶段性提测，阶段性验证
5. 识别项目中存在的风险，风险是否可控
6. 大促封网，和上下游依赖这些因素也要考虑
7. 测试人员等相关人员须要提早锁定

具体到action上面，则能够考虑下下面这些：

1. 日会了解每一个人的进度、风险点、须要协助的点等
2. 各个阶段的可运行单测是必须的
3. 按期review代码(例如一周一次)，check真实进度，owner或owner&相应开发人员参加便可
4. 制定开发规范，保证代码风格统一
5. 功能拆分尽量细，一个功能点最好不要超过5天，尽可能控制在3天以内
6. 开发总体自测ok以后，对项目进行总体code review，同时提测
7. code review以后修改的代码，所有修改完毕以后，要进行总体的回归测试，回归测试期间除bug问题，不容许再修改代码
8. 发布避开大促封网，发布以前肯定依赖方发布时间点，看下发布顺序有木有要求

其中，应重点关注项目中的风险，不管是何种缘由，本身可控or不可控因素形成的，现状偏离计划的事情，都属于项目风险，应尽早抛出来，并且应尽量保证你但愿看到这一风险的人看到。其次，风险不是抛出来就完事了，还要考虑下是否能够cover掉这一风险，是否须要其余人协助，须要的话，也应尽早提出来。最后，尽量多给测试留一些时间，你永远不知道测试过程当中会发现什么问题。

5.交付清单

交付清单的意义不只仅在于给到产品同窗，让他check他所提的需求咱们已实现，还在于咱们自身对这个项目的一个回顾，另外，交付清单也能够给到测试同窗一个最强王者辅助的做用，测试人员对比交付清单便可知道本次项目的全部功能，方便他们测试。因此，交付清单应尽量详细，和TC 不冲突哦~

推荐思惟导图+Excel+文字的形式展示。

6.发布前准备

主要是一些资源准备，例如线上服务器、线上DB、线上mq等等各类中间件及资源的准备。

其次，将项目中用到的SNAPSHOT 版本二方包替换为正式版二方包，替换完，记得再回归测试一下。

另外，还须要肯定依赖的上下游的发布时间，若是这次发布依赖上下游的发布时间，须要和他们协商好具体的发布时间，肯定到几点，以方便咱们到点check他们是否发布，以决定咱们是否能够发布。

咳咳，发布前也能够写一些工具，假如线上数据出现问题，能够经过这些工具修复数据。一名合格的数据卫士不该该直接订db，而应该经过工具来修复。项目上线，相应的工具也同步上线。

7.发布

发布过程当中，须要看各类监控，确保这次发布没有问题，才能继续大范围发布。

发布完成，还应该有线上测试环节，以check线上功能可用。

同时，须要跟进几天线上监控、报警、日志等，确保没有问题后，才算这次发布顺利完成。

8.复盘

我的的复盘是必须的，缘由我就很少说了。这里的复盘指的不是你对外分享/宣讲等等的复盘，而是对你心里那个真实的本身来说的复盘，在这个项目中本身究竟有没有成长，成长了哪些，哪些地方作的好，哪些地方作的很差，很差的地方下次可不能够避免or解决，这个项目有没有偏离你的初衷等等。

以上来源于Bella酱在阿里当PM的经历的总结，也许正在读这篇文章的你，所经历的项目历程，并不彻底match上面这个过程，也许是团队习惯问题，也许是项目时间节奏太快的问题等等，欢迎后台留言给我或者加我微信，告诉我你如今所经历的项目历程是什么样子的。

大家的关注、点赞、转发、收藏是我最大的动力。若是本文有任何错误和建议，欢迎批评指正~

我的微信公众号『Bella的技术轮子』，扫描下方二维码便可关注，期待你的关注～