百木园
当我们开始接到一个需求，开始分析做方案，后面推进到研发并上线，那么这个过程可以当作一个研发项目。很多人在初入职场时，可能对整个推进方法不甚清楚，因此，本篇笔者从项目的角度出发，以一个项目的角色来看待分析，产品如何推进项目进度。请跟随笔者的脚步往下看吧。
注：本文写作思路借鉴了部分PMP的相关内容。
一、项目立项
1）何时立项
对于互联网内需求而言，因一般采用敏捷方式，故每个功能点一般均不大，故一般弱化立项流程。那么我们可以认为，当团队内决定做这个需求时，即该需求作为一个研发项目已经立项。
2）立项意义
对于传统瀑布式流程而言，立项意味着内部工作的正式开始，开始投入人力、物力、财力去完成这件事情。但对于互联网而言，喜欢小步快跑、快速试错，因此其更多是一种方案提报的认可，同时同步告知相关人员，该项目启动了。
既然如此，那么传统的项目启动会是否必要？笔者建议，针对大型或重要的研发项，还是需要启动会的。首先一件事情的成功，是需要大家的认可的，召开启动会，可以体现事情的重要性与价值，凝聚人心；同时可以将大家对事项的认知拉齐，便于后续工作推进。
3）立项的判断价值
首先，与大家分享两个成本，沉没成本与机会成本。
因此在判断是否值得立项的时候，可以从投入产出比，以及与战略方向契合度的角度来进行考虑。
投入产出比指：当研发用时差不多的情况下，如何获得收益更大的价值，一般使用北极星指标作为收益判断准则或其余关键指标。
机会成本指：研发只能在一个时间段内干相对固定的工作，我干了一个就得舍弃另一个，但很多时候需求是各有各的道理，很多可能体现的价值维度方向不同，那么该如何抉择呢，一般选用与公司战略想符合的，这样多部门形成合力从而取得最大化。
ps：如果决策层对投入产出比或公司战略选择经常错误，那么可能就需要考虑这艘船还能走多选的问题了。
二、项目启动
每一个研发项，均有其目的与想要达到的效果，为了能在规定时间内完成该目的，故一般需要确定其内容（即范围边界）。
1）需求范围
在开始项目前，一定要明确需求的目的，围绕目的进行需求内容的确认。
详情可以借鉴《高价值完成B端需求设计总结》的内容，在此不多做阐述。
2）预期进度
此处不是指研发侧完成该需求的进度，指的是业务侧推进与此研发侧相关配套业务的时间点。为了保证业务的效果，那么一般需要与业务侧的时间点打配合，从而调配内部的资源。
3）干系人
在推进研发侧时间前，需要梳理清楚本需求涉及到的相关方。对于B端而言，如上线后是哪个部门负责推进，哪个部门进行执行，甚至还会有对于此需求关心的负责人是谁，如果涉及到资金的还会有出资方是谁（预算在哪个部门）等等。
对于B端而言，内部体系比较复杂，决策人与使用人以及相关方均需要注意，在分析出干系人后，对推进整个事项均有好处。
4）项目成本
在除了研发成本外，还有一块需要注意，每一个功能上线后，都要有配套的运营成本，甚至配套的成本不一定低。
对于B端而言，内部培训推广，新功能加入业务流程后的新调整新考核是需要宣导下去的，这块内容虽然与产品人本身关联不大，但对于整个研发项上线后的落地推广，有一定的帮助。如果涉及到外部第三方的对接，那么梳理清楚关系人之间的关系后，梳理多方间的对接合作关系，对整个项目推进也是有帮助的（不同的商务关系，对于B端而言，往往会影响到对不同事情的处理态度）。
注：本模块除了需求范围外，其他可以理解为项目经理的职责范围，但了解此模块可以对整个研发项开好局，开头不走偏有很大帮助。对于B端而言，需求一般比较复杂，研发工作量往往比较庞大，因此从开始定好方向很重要，可以极大降低后期变更带来的影响。
三、项目进度
在项目完成所有需求内容后，将进入研发阶段，该阶段有2个特点：
注：对于产品人来讲，整个研发过程应不是关注点，只需要知道需要什么时候能完成上线即可，但为了最终产出物的可控，需对进度有一定了解，故对该过程也需要一定了解。
下面笔者对认为重要的点进行阐述：
1）进度把控
常规的研发管理中，对进度管控是有专业技能的，如研发协助工具，站会例会等，但对于产品来讲，没必要对研发进度管控深入过多。
笔者建议，可以通过把握关键点的方式，对当前进度进行了解：
- 通过按照预估时间点，在研发50%，研发完成进入测试等时间点介入了解下
- 通过研发侧的周报等方式进行了解
- 通过关键人物，如该项目的研发侧牵头人进行了解
- 通过研发群里，研发侧的沟通内容进行了解，如测试开始测试等来了解（比较耗精力，不建议）
该模块建议，可以通过产品与研发部门间的协调机制来解决该问题，如周报周会或者其他方式。
2）风险管理
在研发推进中，因为预期之外的各种，存在各种风险，作为产品人，最应该关心的就是外部风险，主要为业务侧风险。业务侧风险主要体现在业务变动带来的需求变动，以及需要业务部门配合的点，是否能结合研发侧节奏同步进行。
3）变更控制
在研发推进中，碰到需求调整是经常碰到的事情，但对于研发管理来讲，需求的调整带来了不确定性，因此是拒绝变更的。但我们作为产品人，是需要对所产出的最终产品的效果负责的，应当追求最大价值。
当碰到业务对需求提出优化建议时，需进行分析，判断该优化点的价值，并且分析下对研发工作的影响，如果需求改动不大，并且价值度高，则应该推进本次改掉，如果改动较大，则赢进行评估是调整研发计划还是放入下一版本。
按笔者个人建议，在进行调整时，当改动重要或较大时，需注意及时与领导汇报沟通（对产品效果的要求以及对研发成本的控制，是领导比较关心的事情）。
4）模拟测试
该处指的测试并非测试的专业测试，指的是在测试人员完成测试后，产品对所完成功能的业务检视，同时UI也需要，主要是看与所设计的是否有偏差，是否能满足业务诉求并带来价值。
该事建议在完成测试第一轮跑通，基本流程跑通时进行，因为此时检视基本可以全部走完，检视发现的问题还能够得到解决，若再晚进行检视，发现问题会偏晚，导致发现的问题会让技术重新调整后再提测，影响总体时间。
四、项目交付
在研发完成后，产品终究是要交付给业务需求方，故在研发完成后，将进行项目交付。
1）上线准备
在内部研发完成后，此时所交付物（所研发的产品）将从内部研发团队交付到外部业务团队手中，故需要对2方面进行准备。
对业务团队，进行操作培训，确保业务部门能够了解如何使用该产品，在上手后能立马使用。
对研发团队，上线时有些内容是需要提前准备的，如数据预处理、外部账号申请等，这些在研发团队评估后，也需要进行准备。
2）发版上线
在万事具备后，将开始进行上线，上线的话主要是研发团队的工作，研发团队需要按照之前产品提供的方案以及上线计划将代码发布到生产环境。
此时产品价值度比较低，但产品往往还是需要参与的，因为在发版时可能遇到不可预知问题，方便现场沟通现场解决。同时有些系统的话，可能还需要产品进行权限配置，或者其他一些配置内容。
当系统上线需要外部支持配合时，那么也需要产品经理或项目经理提前协调配合，确保上线时外部的顺畅。
其中有个注意点，关于app应用市场审核，iOS与安卓不同，需经AppStore审核后才能安装，故可以采用提前提交审核的方式来确保与安卓可一同发版。但若能做到兼容，便可灵活操作。
3）上线跟进
上线后，在业务开始使用后，也需要跟进业务的使用情况，可以查看业务的使用数据，并于业务回访获得反馈，必要时可进行优化迭代。系统必然是在改进迭代中走向成熟。
五、项目总结
在项目上线后，业务使用良好本项目获得业务认可，也意味着本项目即将结束，因此需要考虑本项目的得失，沉淀经验教训，为给整个公司的后续发展带来价值。
1）项目总结
在完成后，应当组织对项目进行复盘，回顾整个流程，对项目中好的点进行总结，对出现的一些问题进行回顾，并总结教训与改进方法。对于新的方法，可以纳入原有的流程中，对于新发现的注意项，可以放入checklist，为后续自查避免问题做依据。
做此项是为了后续能更好提高研发侧的效率，加强彼此间的协作。是团队的提升。此项一般可由项目经理或研发经理主持。
2）产品总结
在但产品之外，还需要对产品进行回顾，即分析产品设计与业务的契合度，回顾在完成需求时的历程。此项是为了作为产品人，更好提升自身能力的。可以从以下几个角度来进行复盘：
- 产品设计与业务的契合度，可以分析是否完成了解了业务的含义，在整个过程中是否有偏差，如果有偏差，偏差在哪里，发生偏差的原因是什么，在下次遇到问题如何分析会更好。此时更多是可以提升对业务的理解。
- 从接到需求到完成整个方案中，是否存在卡点（磕磕绊绊不顺利），如果有的话分析下是否经常在不同项目中会碰到这个事情，如果是那就是个人的短板，需要针对性强化，如果不是，那这次卡的原因是什么该如何解决。 此时更多是可以完善产品工作流，提升个人的产品技能。
以上是笔者对单个项目推进中，对阶段的划分以及如何推进的方法，各位在实际推进中会有自己的总结方法，希望能与各位多多探讨，也希望本文能对屏幕前的你有帮助！
给作者点赞，鼓励TA抓紧创作！
来源：http://www.woshipm.com/operate/5461980.html
本站部分图文来源于网络，如有侵权请联系删除。