我在B公司（为了保密，所以公司名称用‘B公司’代替）担任的是产品经理（PM）一职，由于B公司对公司架构进行了调整，我们整个产品部都被撤掉了，不再保留PM这个职位，因此离开，以下是我在B公司任职期间，对自己的职业生涯做的各个项目的总结。

文章尝试使用了一些复盘的思维去写。

B公司社区回顾目标

社区的目标是2017年4月份完成第一期的规划（不包含手机端），6月完成第三期规划（包含手机端）。

B公司社区评价结果

1.B公司论坛在四月份的时候按照原来构想完成了任务中的开发计划，实际上线在5月份。

2.到了五月份，第二期的计划如期的进行，并且提前完成了相关开发任务。手机端开发暂缓。

3.六月份，第三期的任务也完成了，不过完成的质量和速度不好。

4.七月到九月与其他项目做兼容，接入到B公司商城当中。

B公司社区分析原因

1.由于测试的时候发现比较多的问题，所以修复问题到正式发布到cn测试站用了大概2周的时间，任务上线实际上是五月份。

2.由于有了测试的经验，在底层方面做了技术上的优化，所以第二期的任务如期完成。不过手机端的任务由于B公司建站那边的任务比较重，我们这边没争取到相关的开发人员过来。而且设计人手也不足，所以就暂停开发手机端。

3.第三期由于项目组有人员离职了，影响了相关的开发进度。

4.由于公司社区是所有项目当中做得最快的，所以担当起了项目的排头兵，进行各种试点工作，比如说进行兼容尝试，不过在兼容的过程中，也发现了很多运维上的问题，以及B公司商城方面的框架问题，所以工作开展起来进度比较慢。另外B公司商城本身的开发工作就比较紧张，突然加入这些开发事项，打乱了本身B公司商城的计划。

B公司社区总结

1.人员变动大。B公司社区一直以来得到的资源就不多，项目组的人员发生变动比较大，从原来的2个后台，1个前端变成了最后只有1个后台人员。前前后后变换了3个前端人员，2个后台人员，而前几个前端人员的代码书写不规范，以及技术人员的水平有限，导致维护代码的难度加大。

2.资源少。在我接手B公司社区前，得到的资源非常少，没有产品人员跟进，导致规划有点混乱，而且没有设计人员，导致界面做出来异常难看。

3.需求改动少。在跟进社区之后，第一件事就是确定过了需求，规划好要制作的功能，并且迅速完成原型图，让技术人员能够根据原型图来进行开发。

4.代码要规范。由于前端代码不规范，导致了跟其他项目做兼容时，出现了各种问题，项目的速度也因为代码的原因而拖慢了，所以社区花费了2个月的时间去进行重构，如果从一开始就避免的话，就可以节省2个月的人员投入。

B公司学院回顾目标

B公司学院在6月15号的时候进行规划，并在2天时间内完成原型图，然后交给技术人员去进行开发，项目在6月份完成。

B公司学院评价结果

B公司学院在6月按照进度完成。

B公司学院原因分析

1.规划的方向做出了调整，原型比原来的计划多花了1天时间。

2.规划清晰明了并且符合技术的开发，技术知道开发的重点。

3.设计稿在很早之前就确定下来了，节省了等待设计的时间。

B公司学院总结

完善良好的规划，技术人员的配合，设计稿的尽早确定，都对项目的进展有很好的帮助。

B公司PMS回顾目标

PMS是B公司公司的总后台，拥有管理其他项目的关键配置的权限，另外拥有OA系统，员工的日常办公都要在PMS里面去进行。

B公司PMS评价结果

1.开发完成得较早。

2.使用频率低。

3.很多页面的UI都不如人意。

B公司PMS原因分析

1.前期投入的人员较多。在前期时投入的技术人员都是各组的精英，因此完成的时间在这么多个项目当中算是比较早的。

2.复杂程度高。由于这个项目是总后台，所以复杂程度相对来说比较高，测试起来也会比较困难，而且其他子项目也在开发阶段，所以使用的频率就更少了，没提现出这个系统的重要性。

3.人员离职影响。由于之前负责该项目的产品人员离职了，留下来的文档也不足以解释清楚各个功能的作用以及原理，所以接手所需要的时间比较长，而且在后期补全文档的时候也花费了大量的精力。

4.测试资源不足。产品新接手，对于项目的了解度不够高，而测试的资源本来就不足了，在有限的时间内难以完成对整一个PMS进行测试。

5.前端人员资源不足。测试出来的那些结果，有很多一部分都是UI上的，而PMS在那个时候并没有负责跟进的前端人员，导致测试结果出来了也被搁置了一段时间，没有跟进修复，导致后来有人手了再跟进时，花费了比较长的时间。

6.很多地方没有做到数据的规范。由于很多UI的提示没有做到规范，所以都是按照各个技术人员的个人喜好和经验来进行制作，导致了有很多的地方都不一样，看上去不专业。

7.注意各项目的先后顺序。总后台完成的时候，各个子项目并没有完成开发任务。总后台的作用凸显不出来。

B公司PMS总结

1.在项目规划时，就及时做好各种规范。

2.根据项目的重要程度来调配资源，条件允许的话就固定人员，不要经常发生人员的变动，避免耽误工期。

3.作为一个总后台，应该在各个子项目完成之后再进行考虑规划。

业绩管理回顾目标

制作一个专门给营销人员查看业绩的系统，让各个营销人员都可以看到自己的排名、部门的排名、公司的排名，起到激励的作用效果。

业绩管理评价结果

开发周期只有五天，并且如期完成了销售部门的要求。

业绩管理原因分析

1.在PMS里面原本就拥有了话题功能，允许发表资讯并评论点赞。

2.在PMS里面原本就拥有了公告功能，允许发表公告，并且允许针对特定人群进行发布。

3.在PMS里面原本就拥有了组织架构的系统框架，可以直接引用，修改幅度不多。

4.拥有UC登录中心。登录采取的是UC的登录方式，帐号统计由一个后台来进行管理匹配权限，稍微做些修改就可以用到业绩管理系统。

5.技术人员稳定有经验。制作的开发人员都是技术经验丰富，而且曾经开发过PMS后台，了解代码结构。

6.设计部门的设计稿很快就确定下来了。

7.原型图补全的速度快。技术人员完成可以参考着设计图就可以进行制作了，里面的相关规则已经规定好。

业绩管理总结

产品人员得到需求之后，知道如何利用现有的资源，以最快的速度去完成，做出了较好的规划，并且符合对方需求。

微信配置回顾目标

制作一个微信公众号第三方平台，客户可以通过B公司的微信配置平台完成对自己公众号的管理。

微信配置评价结果

1.完成的速度较慢，超出预期完成时间。

2.存在技术在开发的过程中偷工减料的现象。

3.受接口的限制很高。

4.测试过程中发现很多问题。

5.服务器不稳定，增加了很多技术修复的时间。

微信配置原因分析

1.微信的接口时常进行更新变化，有些功能规划好之后才发现微信不提供接口，导致要调整规划。

2.由于是调用微信的接口，因此环境的稳定性很重要，当配置发生改变时，有些功能就会失效，必须技术人员去进行调整修复。

3.人员变动大，之前负责后台的人员离职了，开发人员进行了变更。

4.平台的粘性低，因此要把功能做得强大，所以一些功能会比较复杂，导致了开发难度加大。

微信配置总结

由于用户完全可以使用公众号平台去进行管理，另外由于微信团队的强大，功能的更新会比我们公司自己开发更快，而且自己开发会受限于微信提供的接口。从战略上来看，要这个平台需要一个稳定的团队时常维护才可以跟上微信的步伐。而要增加用户的使用黏性，只能把自身的平台功能强大，联合B公司其他项目来进行整合，提供一些微信团队无法提供的服务，同时使得用户用B公司的产品确实是产生了便利，那么B公司微信配置才能提高用户黏度。

APP管理回顾目标

用户设计好APP之后，通过APP管理平台自动生成APP安装包，内测没问题就可以自己把安装包上传到各大APP下载平台。

APP管理评价结果

1.开发人员严重不足，项目严重超期。

2.设计部分的项目完成时间晚，导致对接调整的时间急。

3.IOS的规则发生改变，导致项目规划出现严重偏差，改变很大。

4.当初UI方面规划得不太完善。

5.接口不稳定，很多地方需要修改。

APP管理分析原因

1.开发太慢，导致有很多规划都已经过时了。

2.原规划不好，很多细节没考虑，导致要处理这些细节时，需要花费大量的时间精力。

3.接口不稳定，经常要改，增加了很多无谓的时间。

4.项目复杂程度高，开发人员有点吃不消。

APP管理总结

遇到一些复杂程度高的项目，在前期规划的时候，就更应该花多一点时间去做考研去做规划，把每个关键的位置都要规划好，把整个框架搭建好，不然后期就要花费很多的时间去做调整，这样会延长项目的开发周期，甚至可能由于开发周期太长了，已经不合时宜而导致了项目的难产。

该项目的很多地方就是由于前期规划不好，导致在实际开发过程中，某一些功能的实现难度加大了。

我i在2017年10月31日整理交接文档，并于 2017年11月1日 离职

end