TO G项目全流程复盘
此次项目本人从前期商务接洽、售前工作、招投标工作，初期需求采集工作、方案设计工作，中期产品设计工作、产品研发测试工作、项目管理工作，后期项目交付和持续运营工作，全流程参与。本次复盘也是一次全方位的项目复盘。
一、项目背景
此项目业主方为某市某区网信办，项目由某大型国企作为总集成方，某软件服务央企作为软件部分分包商，我司作为的该央企软件外包服务商。
软件部分包括<舆情大数据监测管理系统>（PC）和<网信指令交办系统>（PC&App），主要解决舆情监测预警和后续的网信指令交办问题。
二、目前成果
目前项目合同涵盖功能和其他需求功能已完成开发工作，并已完成验收交付工作。合同中目前“对接其他舆情系统”尚未完成，“舆情简报”功能改版功能尚未完成。
项目自试运行以来共更新迭代9个版本，后续会根据网信办用户和镇街用户反馈持续优化迭代项目，同时做好日常运行的运维工作。
三、项目各阶段复盘
1. 产品需求阶段复盘
由于此项目本质上是一个TO G建设交付类型的项目，不同于团队研发的标准化产品，交付类型的项目需求相对不可控，而客户需求蔓延，可能会导致：
- 前期为能够顺利拿下项目，没有充分考虑客户需求与团队资源匹配度问题，导致技术团队无法完成客户需求，导致项目延期或违约；
- 中后期为能尽快满足用户需求完成验收工作，对业主方的需求来者不拒，扩大项目范围，反而导致项目迟迟无法交付上线；
- 需求的蔓延带来研发成本、采购成本的超支，最终项目利润不足；
- 业主方需求的随意变更或蔓延，团队疲于满足用户会使团队成员产生抗拒心理，影响团队氛围，打击团队士气。
在处理用户需求问题上，前期团队尽可能满足用户需求，所以我们也同样面临2、3、4点的问题，导致项目迟迟无法交付，团队士气受挫。为了解决当前问题，我做了以下改变：
- 从商务层面上，对比签订合同约定，与客户再次明确合同中项目范畴、验收标准和交付时间，以推动客户尽快验收。
- 从产品层面，将新需求进行记录，放入需求池中，作为项目二期建设规划。
- 从研发层面，对于势必增加的新需求，与产品和商务评估新需求的变动的费用成本和时间成本，增加收费项。
对于交付类型项目不管是在前期需求调研、需求搜集，中期产品设计、开发编码，后期项目验收过程中，作为项目负责人都应从商务、产品、研发层面强化需求边界意识，让团队成员认识到需求边界的重要性，严格控制项目边界，以便更加顺利推动项目。
2. 产品设计阶段复盘
产品设计的前提是对业务本质的理解，通过对业主方需求和业务模式抽象出产品框架和业务流程，具象成具体的产品功能。
由于此次项目对我来说是一次全新的项目，所以在前期我也参考了许多成熟产品的资料，但发现市面上大多数同类产品更多地聚焦在舆情信息监测舆情，而对后续舆情处置、指令交办没有过多的涉及。这里就需要思整个系统的核心到底是什么？
通过前期与业主方的多次沟通，发现其实系统的核心非常明确，通过信息化手段和相关技术，实时监控掌握网络舆情信息，同时建立起多机协同、多部门参与、信息共享、共商共治的网络突发事件处置体系。
在理解业务核心后，接下来需要将前期搜集、思考的信息抽象到产品框架中。
首先应该为了完成从舆情监测到指令交办，是怎样一个流程？这些流程中会涉及到哪些角色和关键节点？每一个流程这些角色的输入和输出是什么？到下一流程的限制条件？流程是否可逆？出于对上面流程的思考，梳理除了以下业务流程：
作为一个完整系统，除关键业务流程外，还需要一些基础配置和支撑管理的模块，这里我们考虑了包括：用户管理、权限管理、消息推送、数据统计、审计日志、基础配置管理等。
由于本项目还涉及到原有系统的整合及历史数据的迁移，我们也设计统一应用管理模块。以下是我们对系统架构的抽象：
接下来我们要做的就是对产品功能的梳理和罗列，对前期所有信息和知识的整合，我们对业务流程和产品框架进行了进一步拆解成产品功能，进而进行产品原型设计。
产品原型设计本应是与业主方进行前期沟通、团队内部（研发、测试、UI）评审的重要工具手段，但在这里我犯了2个非常严重错误：
- 在产品设计的时候太重功能，而轻视用户体验。网信办用户在处理舆情上的工作是非常繁杂、琐碎的，但我没有过多地在易用性层面考虑问题，导致用户体验较差。
- 在未将产品原型与业主方沟通确定的前提下，直接进行内部评审进入开发阶段，导致产品在第一个版本给业主方试用时，发现很多功能并非业主方真正想要的东西，反馈不好。
鉴于第一版存在的问题，通过和业主方及研发团队的沟通，我们决定在保留基础功能的前提下，对系统进行重新设计。
对于重新设计的系统，我更多地从用户视角出发，深入了解网信办用户和镇街用户的日常工作状态以及工作量，在保证正常功能流程能跑通的前提下，更多地考虑产品的易用性和灵活性问题，比如重复问题的一键生成模块，流程自定义等。
同时为了避免之前设计的功能并非业主方需要，我在后续的设计过程中，每完成一个版本的设计提前和业主方沟通，明确后再投入开发工作，也避免了开发团队反复修改。
产品经理在设计产品的时候免不了会带有一些主观意识，但产品设计绝不是依靠某个人的感觉和判断来完成的。对于建设交付类型的项目，我们需要同时考虑业务可行性和技术可行性，与客户充分沟通确认设计原型和与研发团队评审产品实现是同样重要，所以在产品设计的时候需要在产品维度、技术维度和用户维度之间随时切换。
3. 开发测试阶段复盘
编码研发是对产品设计的具体实现，在开发测试阶段我更多的工作在于协调、配合研发工作的顺利进行，同时把控整体项目进行。
由于和团队的成员有较好的默契，同时内部也有标准的研发流程，所以整个研发过程较为顺利，工作进度也没有出现较大偏差。这里讲一讲我们团队的整个研发测试过程。
1）我们在前期与业主方接触时，就提前与研发负责人商量，做一些技术储备，以方便在后续明确需求后可尽快展开工作。主要涉及到爬虫技术和移动端开发（团队成员之前均没有写APP经验）。
2）在需求明确后，正式研发工作开始前，由我与研发负责人从共同商量制定项目的研发计划表。表主要涉及的内容包括系统功能、研发人员、各自职责、研发周期等。
3）每周进行一次全体的研发进度会，总结上一周工作以及下一周的工作安排；每天由研发负责人跟进研发进度，评估进度情况。对于研发滞后或者紧急情况，及时进行工作调整。
4）对于需要多客户端联调的情况，提前与相关负责的同事约定时间，以便大家可以集中精力做同一件事。
5）在保证项目质量和进度的同时，也需会时常关注开发人员的情绪和想法。产品经理对需求的把控能力非常重要，但是做到面面俱到往往很难，研发人员的反馈和一些思考，比如在一些流程和技术上的考虑，也是需要重视的。
6）在测试阶段，我们采取的是开发一个模块、测试一个模块的方式。
由于开发资源有限，且时间非常紧，我们的测试团队在开发完成一个模块后，会马上安排测试人员进行相关测试，这样做的好处是，开发人员可以避免在做到后面工作的时候，还需要抽出时间精力重新熟悉前面的代码，同时也可以避免前面的bug导致后面的开发过程中的错误。
4. 上线阶段复盘
真实的使用环境总会有意想不到的问题，所以在系统完成开发工作后，我们与业主方商量尽快上线投入试运行，以便在真实环境下发现问题、及时整改。
首先上线前我们内部进行了多次系统性测试，避免在上线当天出现意外；在上线当天我们的研发时刻关注系统使用情况，若出现突然情况能够及时解决；在正式上线前，对业主方及其下属单位进行了系统培训，让用户提前了解系统功能。
同时准备好系统培训PPT、系统说明书、系统演示视频等资料，避免部分客户出现不知道系统使用方法的情况；同时与用户组建系统讨论群，建立反馈机制。
我们内部项目相关人员也全员加入讨论，避免部分同事没有及时回复消息，而导致网信业务不能及时开展。
当然我们在前期同样也遇到了大多数项目刚上线时的问题：系统运行不稳定，总会时不时地出现一些或大或小的问题，这些问题可能是因为产品设计时没有考虑周到而产生的问题，也可能是程序上的bug，也可能是用户的使用环境不支持等。
这期间我们需要做的是对产品质量进行严格把控，出现问题及时和研发同事沟通尽快解决问题，如果出现较多问题也会降低用户对系统的不信任。
一般来说在一段时间的试运行整改调优，同时随着用户对新系统的逐步熟悉，系统的运行会逐步走上正轨，也可以较好地支持业主方的日常工作。
5. 其他情况复盘
由于我们整个团队处于创业阶段，这里在各方资源、成本非常有限，这里我也讲一讲对于创业团队以及项目过程中遇到的一些其他问题。
其实不管是在创业公司还是大厂，资源总是有限的，而我认为创业的本质就是梳理已有资源，并充分利用、协调这些资源创造出对用户有效用的产品，并能持续创造价值。
我们整个项目团队的人员构成是：项目负责人兼产品经理（1人）、Java研发工程师（1人）、前端研发工程师（1人）、 安卓开发工程师（1人）、QA（1人）、UI设计师（外包）。在团队内部资源非常有限的情况下，我们的解决方案是——复用。团队的每个人都在尽可能地接触和学习自己的知识盲区，在有需要的时候能顶上。
在文章最前面我提到，我作为项目负责人从最开始的商务接洽到后续的运维管理，我是全流程参与。对我而言，以前的工作主要聚焦在对外采集用户需求、对内进行项目管理，但在此次项目中的商务接洽、市场推广、售前方案，招投标方案等都是我以前没有接触的工作，属于我的知识盲区和恐慌区，但在团队处于创业资源匮乏期，走出舒适区是必不可少的事情。
当然不光是我，整个团队的成员都在复用，也都经历了走出舒适区的阵痛，好在我们扛过来了。创业就是摸着石头过河，就是不断地去触及新的领域，不断地在困难和挑战中磨练自己。我相信也只有这样的团队才能经得住市场的考验，能够生存下来。
再说一说成本问题，一个企业能不能活下来依靠健康的现金流，能不能活得好依靠的是利润率。
在前期商务接洽与招投标的阶段，我们确定的价格的利润空间还比较大，所以在采购一些外部服务的时候，还没过多地关注成本问题（我们是在中标前就已经开始了部分工作）。
但后来由于原本与我们合作的总集成商在招投标的时候出现失误，被现在的总集成商中标，而原本的总集成商又变成了分包商，导致在总集成商在与我们的谈判中，被分走了大部分利润，这也是因为我们前期没有做好足够的风险把控和成本预算。
所以在我们做任何决策前，我们都应该警醒自己，每一个决策都会影响项目成本，所以我们在做决策前，需要花更多的时间去权衡投入产出比、甚至是代替方案。
四、后续进展说明
目前项目已经正式投入运行使用，运行状况良好。我们原本也是将本次项目作为示范类型的建设项目，后续将逐步在本市其他网信办推广使用，作为标准化产品。
正如在成本问题里我提到，活下来的关键是现金流，而建设类型的项目大多回款周期较慢，我们作为创业团队也需要足够健康和持续现金流业务才能进一步考虑活得好不好。所以目前我们也正在积极地通过与外部伙伴合作将产品SAAS化，提供标准+定制化服务，以求能有更大的突破。
本文作者 @蹦蹦怪
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
