前面北哥陆续总结了程序员成长过程中应具备的核心能力，Java程序员的成长之路，架构师成长之路，这篇文章分享我曾经参与的一个MVP版本产品的研发交付经历，借此聊聊项目管理的那些事。

作为一个程序员，每个人都避免不了参与各种各样的产品和项目的研发支撑工作。在我曾经的工作经历中，有一个产品的研发支撑和交付工作，至今让我记忆犹新。

01 背景

产品的背景是，公司已经上线了一个垂直行业的互联网产品A，通过解决信息不对称提升信息传输效率，获取了大量的行业用户。但仅仅通过解决信息不对称，能创造价值和带来的营收都相对有限，因此公司决定深度介入到行业的全流程，打造出一款可以覆盖用户需求全流程的产品，以提升用户粘性和创造更大价值。

产品启动时，我作为一个资深开发工程师，刚加入到公司不久。公司是一家刚成立一年多的创业公司，公司大部分人员都是业务人员，技术团队不超过20人，大部分都在支撑迭代已上线的产品A。我作为新加入的技术人员，被任命负责这个产品的服务端开发工作，兼整个产品的项目管理负责人。

02 挑战

接到这个任务时，我还从来没有独立负责过一个产品的项目管理工作。而当时面临的一些客观条件，也让我对这个任务有些望而却步。

业务知识欠缺：作为一个技术人员，大部分的经历都是写代码自测上线，很少深入到行业里面了解业务需求和痛点，而这个垂直的业务对我来说更是陌生。

团队人员不完善：在产品启动时，相关的业务人员刚刚招聘到位，而项目组的人员除了我作为服务端人员外，其它人员都还没有确定，包括产品经理、测试等专职人员更是欠缺。

技术体系落后：因为公司还处于创业阶段，投入到技术研究上的精力较少，大部分技术还是相对传统。在已上线的产品A中，后端系统采用了单体架构，随着产品用户量的快速上升，系统性能开始劣化，经常在高峰时段出现间歇性宕机问题，因为人员少、时间紧、需求多，技术升级进展缓慢，每次都只能通过升级服务器配置的方式来解决。

流程和规范缺失：作为一家刚成立不久的创业公司，产品更新快，研发迭代周期短，研发流程随意性大，可能随时会因为一个线上bug而临时改动代码上线。项目管理流程缺失，没有专业的项目管理工具，日常信息传达基本靠口头沟通。

产品前景不明：虽然确定了产品大的方向，但具体到产品细节，有哪些业务场景，业务流程如何流转，如何通过产品化去实现对线下业务流程的改造等等还未确定。而整个产品是否最终能够成功完成业务预期的目标，还是可能沦为一次失败的尝试，一切都处于未知之中。

无论是业务产品本身，还是团队、技术体系和流程都存在着不同程度的未知和不确定性，虽然有着种种顾虑和担心，但既来之则安之，程序员的最大乐趣和价值就是去发现和解决问题，与我来说，也算是开启了一个完整产品的从0到1打造过程的历程。

03 措施

针对前面所述的问题，在整个产品的项目管理中，我们是这样做的

梳理业务

业务需求永远是产品落地的首要前提。

首先，和业务团队的专家深入交流。虽然业务团队也刚刚组建，但好在都是有着行业内数十年的线下经验，和他们不断的交流，让我快速了解了行业知识和业务特点，搞清楚了业务在线下运营过程中的核心流程和关键点。

其次，参加了业务组织的线下访谈。了解了目标用户的核心需求和痛点，发掘目标用户的用户画像，提炼出可以产生用户价值的需求点。

最后，通过线上的用户调研问卷，收集一定用户量下的用户的相关选择，验证新产品需求的真实性和使用的意愿度，对用户非重点关注的需求进行了精简。

经过一周左右的时间，大致确定了用户的核心需求，把业务流程可以线上化的点梳理出来并细化，形成了一个初步的MRD文档（业务需求说明书）。

确定目标

业务需求理清楚后，接下来开始确定目标。

产品目标：考虑到产品是从0到1从头开始，核心的诉求是优先开发核心流程，快速上线，快速试错。因此和业务运营人员对业务需求进行了不断的精简，确定了产品的MVP（最小化可行产品）版本功能，并以MVP版本最快速能够上线为目标。

运营目标：根据确定的MVP版本的产品功能，业务运营人员确定了产品上线后的运营目标，包括一段时间内的拉新用户量、业务单量、业务GMV等。

研发目标：根据产品的MVP版本功能，粗略预估需要的人员和时间，确定产品上线可使用的大致时间点，以此时间点倒推作为运营、研发等团队各项工作计划开展的依据。

组项目团队

在目标确定后，大家开始分头在各自邻域，制定详细的目标分解计划，推进本领域内工作的进行。

我作为这个产品的项目管理负责人，也开始进入到对整个产品的交付实施阶段。

首要解决的是人的问题。

产品人员：产品需要提供出PRD（产品需求说明书），研发才能够根据PRD内容进行设计和编码。但公司没有专业的产品经理，找到了公司的一位UED人员（用户体验设计），让他从UE的角度给出产品的原型图和交互流程图，作为产品PRD的基础。

开发人员：整个产品在展现层面分App端和网页后台，因此需要有Android、iOS、Web开发和服务端开发各一人。公司的A产品的上线，已经储备了相关人员，分别借调了一名Android、iOS、Web开发人员。我因为对整个项目了解较深入，同时承担了部分需求文档的编写、服务端的架构设计和编码工作。最终组成了四人的开发小组。

测试人员：整个公司只有一名专职的测试人员，在负责产品A的日常迭代测试工作。临时招人也来不及了，最后定下来，在产品上线前组织业务运营人员、公司开发人员做两到三轮的全员测试，保障产品质量可以按时上线。

就这样把整个产品的项目团队算是组建起来了。

kickoff会议

项目团队组建完成，即召开了kickoff会议（项目启动会议），业务人员对整个产品的背景、定位、目标、长期规划做了简单阐述，并以业务专家多年线下业务经验，向大家说明了产品上线后所具有的重大意见和价值，提升了大家对项目前景的信心。

我作为项目管理负责人，把项目的大致需求、项目的组织形式和人员分工、项目计划和项目组的同学做了分享。同时对项目过程中沟通计划做了规定，包括项目的例会、技术评审、风险预警等等。

需求评审

kickoff会议完成，接下来组织项目成员做详细的需求评审。根据UED同学产出的原型文档和交互图，结合我对业务的理解和补充，将产品涉及到的前后端系统流程和需求跟大家做了评审，针对一些遗留的问题，通过会议纪要的方式做了记录，会后陆续和业务人员做了确认。

定项目计划

评审完成后，开始制定项目的详细计划，包括技术设计、框架搭建、编码、联调测试、上线等各个里程碑节点的时间。搭建了项目管理工具，如wiki、jira等，建立项目组沟通群。跟项目组人员约定按照里程碑时间点交付相关产物，组织大家每日的站会，沟通项目进展，及时抛出遇到的问题。

设计、开发与测试

通过对业务需求的理解，产出了明确的前后端功能列表。设计数据模型表结构，并划分好相关的子系统和模块。

考虑到产品A已经遇到的性能问题，对继续采用产品A使用的技术框架有了一定的担心，决定构建分布式服务来支撑整个产品，引入了一些新的框架和中间件，将产品A的技术架构基本摒弃了。而这个决定在事后看来也埋下了一定的隐患。

同时开始搭建基础设施和系统框架，确定开发的代码规范和模板，一切准备就绪，可以进入开发了。

整个开发过程还算相对顺利，项目组人员少，遇到的问题可以及时沟通解决。

经过近一个月的开发和联调，整个产品涉及的系统基本全部开发完成了。按照项目的计划，开始转入全员的测试阶段。

虽然说是测试，但因为大家都不是专职的测试人员，缺少了详细的测试用例设计，只能根据产品的核心流程，在系统上进行全流程的操作以发现问题。

第一轮测试，由项目组的开发人员承担，大家更多还是站在开发的角度使用产品发现问题，解决一些代码上的bug。

第二轮测试，邀请了产品A的相关开发人员参与进来，他们站在开发的角度，以非产品开发者的身份来体验产品，提出问题。

第三轮测试，邀请了业务运营人员，让他们站在用户的角度使用产品，发现了不少新的问题。

上线发布

经过大家不那么充分的测试，产品即将进入到上线阶段。

我们提前制定了上线计划，将需要上线发布的内容逐一列出，并对相关上线依赖做了排序。因为是产品的首次发布上线，过程是曲折的，包括一些基础中间件的搭建、应用服务器的配置、系统的打包发布、App的证书与上架等等，大部分都需要一一确认，排查解决遇到的各自问题。好在最后终于在项目计划上线的时间点，按时完成了上线工作。

项目总结

MVP版本产品上线后不久，针对产品从开始到上线完成的整个过程中，做了项目总结，得出了一些结论：

做的好的

上下一心，目标确定，计划合理，配合顺畅

项目过程紧张而不混乱，充分利用了一些项目管理工具，提升了沟通效率

虽然项目人员配置不全，但发挥了全员的力量，互为补位

项目问题和风险及时沟通和暴露

做的不好的

产品需求不够详细，缺乏有效的需求评审。有些需求细节在开发中被陆续重新拉出来讨论。这也是因为团队人员缺乏专职的产品经理短板导致

服务端架构过度设计。在MVP版本阶段，分布式服务架构并不适合，耗费了较多的精力，而上线后的用户量实际并没有那么大

测试的不够充分，上线后还是遇到了一些新的问题

04 总结

回过头看这个产品的研发交付之路，虽然面临着一些挑战，但整个项目并不算是一个大型复杂的项目。对于我来说，也并不仅仅承担单纯的项目管理工作，还承担了需求分析、服务端技术设计与开发、测试甚至部分运维等多个角色工作。其中的一些做法，站在今天从项目管理的角度看，也不见得是合理的，但在当时的经验、环境、背景下，却也是我能想到的最好的做法了。

针对项目管理这个课题，有许多成熟的方法论，无论是PMP课程，还是敏捷开发相关内容，无不可以让我们具备更多的理论知识。今天也已经有许许多多的工具和软件可以提供给我们使用。通过这些软件和工具，可以帮助我们更好的做项目计划和项目跟踪，将项目过程中的流程如需求分析、评审、开发联调、提测、上线发布等串联起来，对项目的过程数据如会议纪要、bug、总结文档等进行有效管理，辅助我们把项目梳理好管控好。

项目管理涉及到人、资源、组织、进度、协调等方方面面，除了这些理论的方法、流程和工具的使用，我们真正在项目中，会遇到各种各样新的挑战，如跨团队跨地域的沟通和协调，资源的不足，时间的冲突等等，这实际意味着，更重要的是人在其中发挥的作用，通过人的各种行为去影响他人，进而让项目处于可控状态，而这正是项目管理的意义所在。

今天的分享，也是希望能够让大家有所启发，去思考如果是自己承担一个项目管理工作，你会关注哪些方面，可能会忽视那些方面，是否已经有了一套自己的方法。