高效推进B端项目进度方法总结

1、高效推进B端工程进度方法总结当我们开始接到一个需求，开始分析做方案，后面推进到研发并上线,那么这个 过程可以当作一个研发工程。很多人在初入职场时，可能对整个推进方法不甚清 楚，因此，本篇笔者从工程的角度出发，以一个工程的角色来看待分析，产品如 何推进工程进度。请跟随笔者的脚步往下看吧。注：本文写作思路借鉴了局部PMP的相关内容。一 工程立项1）何时立项对于互联网内需求而言，因一般采用敏捷方式，故每个功能点一般均不大，故一 般弱化立项流程。那么我们可以认为，当团队内决定做这个需求时，即该需求作 为一个研发工程已经立项。2）立项意义对于传统瀑布式流程而言，立项意味着内部工作的正式开始，开始投入人力

2、、物 力、财力去完成这件事情。但对于互联网而言，喜欢小步快跑、快速试错，因此 其更多是一种方案提报的认可，同时同步告知相关人员，该工程启动了。既然如此，那么传统的工程启动会是否必要？笔者建议，针对大型或重要的研发 项，还是需要启动会的。首先一件事情的成功，是需要大家的认可的，召开启动会，可以表达事情的重要性与价值，凝聚人心；同时可以将大家对事项的认知拉 齐，便于后续工作推进。3）立项的判断价值首先，与大家提供两个本钱，漂浮本钱与机会本钱。因此在判断是否值得立项的时候，可以从投入产出比，以及与战略方向契合度的 角度来进行考虑。投入产出比指：当研发用时差不多的情况下，如何获得收益更大的价值，一般使

3、 用北极星指标作为收益判断准那么或其余关键指标。机会本钱指：研发只能在一个时间段内干相对固定的工作，我干了一个就得舍弃 另一个，但很多时候需求是各有各的道理，很多可能表达的价值维度方向不同， 那么该如何抉择呢，一般选用与公司战略想符合的，这样多部门形成合力从而取 得最大化。ps :如果决策层对投入产出比或公司战略选择经常错误，那么可能就需要考虑这 艘船还能走多项选择的问题了。二,项启动每一个研发项均有其目的与想要到达的效果为了能在规定时间内完成该目的， 故一般需要确定其内容（即范围边界）。二,项启动1）需求范围在开始工程前，一定要明确需求的目的，围绕目的进行需求内容确实认。详情可以借鉴高价值完

4、成B端需求设计总结的内容，在此不多做阐述。2）预期进度此处不是指研发侧完成该需求的进度指的是业务侧推进与此研发侧相关配套业 务的时间点。为了保证业务的效果，那么一般需要与业务侧的时间点打配合，从 而调配内部的资源。3）干系人在推进研发侧时间前，需要梳理清楚本需求涉及到的相关方。对于B端而言， 如上线后是哪个部门负责推进，哪个部门进行执行，甚至还会有对于此需求关心 的负责人是谁，如果涉及到资金的还会有出资方是谁（预算在哪个部门）等等。对于B端而言，内部体系比拟复杂，决策人与使用人以及相关方均需要注意， 在分析出干系人后，对推进整个事项均有好处。4）工程本钱在除了研发本钱外，还有一块需要注意，每一

5、个功能上线后，都要有配套的运营 本钱，甚至配套的本钱不一定低。对于B端而言，内部培训推广，新功能加入业务流程后的新调整新考核是需要 宣导下去的，这块内容虽然与产品人本身关联不大，但对于整个研发项上线后的 落地推广，有一定的帮助。如果涉及到外部第三方的对接，那么梳理清楚关系人 之间的关系后，梳理多方间的对接合作关系，对整个工程推进也是有帮助的（不 同的商务关系，对于B端而言，往往会影响到对不同事情的处理态度）。注：本模块除了需求范围外，其他可以理解为工程经理的职责范围，但了解此模 块可以对整个研发项开好局，开头不走偏有很大帮助。对于B端而言，需求一 般比拟复杂，研发工作量往往比拟庞大，因此从开始

6、定好方向很重要，可以极大 降低后期变更带来的影响。三工程进度在工程完成所有需求内容后，将进入研发阶段，该阶段有2个特点:.所需时间可评估，可对过程时间进行精准评估，过程可精细化管控.此阶段耗时占整个研发阶段的占比拟大，故此阶段（从开发、联调到测试）为进度的重点管控阶段注：对于产品人来讲，整个研发过程应不是关注点，只需要知道需要什么时候能 完成上线即可，但为了最终产出物的可控，需对进度有一定了解，故对该过程也 需要一定了解。卜面笔者对认为重要的点进行阐述：1）进度把控常规的研发管理中，对进度管控是有专业技能的，如研发协助工具，站会例会等, 但对于产品来讲，没必要对研发进度管控深入过多。笔者建议，

7、可以通过把握关键点的方式，对当前进度进行了解：通过按照预估时间点，在研发50% ,研发完成进入测试等时间点介入了解下通过研发侧的周报等方式进行了解通过关键人物，如该工程的研发侧牵头人进行了解通过研发群里，研发侧的沟通内容进行了解，如测试开始测试等来了解（比拟耗精 力，不建议）该模块建议，可以通过产品与研发部门间的协调机制来解决该问题，如周报周会 或者其他方式。2）风险管理在研发推进中，因为预期之外的各种，存在各种风险，作为产品人，最应该关心 的就是外部风险，主要为业务侧风险。业务侧风险主要表达在业务变动带来的需 求变动，以及需要业务部门配合的点，是否能结合研发侧节奏同步进行。3）变更控制 在研

8、发推进中，碰到需求调整是经常碰到的事情，但对于研发管理来讲，需求的 调整带来了不确定性，因此是拒绝变更的。但我们作为产品人，是需要对所产出 的最终产品的效果负责的，应当追求最大价值。当碰到业务对需求提出优化建议时，需进行分析，判断该优化点的价值，并且分 析下对研发工作的影响，如果需求改动不大，并且价值度高，那么应该推进本次改 掉,如果改动较大,那么赢进行评估是调整研发计划还是放入下一版本。按笔者个人建议，在进行调整时，当改动重要或较大时，需注意及时与领导汇报 沟通（对产品效果的要求以及对研发本钱的控制，是领导比拟关心的事情）。4）模拟测试该处指的测试并非测试的专业测试，指的是在测试人员完成测试

9、后，产品对所完 成功能的业务检视，同时UI也需要，主要是看与所设计的是否有偏差，是否能 满足业务诉求并带来价值。该事建议在完成测试第一轮跑通，基本流程跑通时进行，因为此时检视基本可以 全部走完，检视发现的问题还能够得到解决，假设再晚进行检视，发现问题会偏晚, 导致发现的问题会让技术重新调整后再提测，影响总体时间。,工程交付 在研发完成后，产品终究是要交付给业务需求方，故在研发完成后，将进行工程 交付。1）上线准备在内部研发完成后，此时所交付物（所研发的产品）将从内部研发团队交付到外 部业务团队手中，故需要对2方面进行准备。对业务团队，进行操作培训，确保业务部门能够了解如何使用该产品，在上手后

10、能立马使用。对研发团队,上线时有些内容是需要提前准备的，如数据预处理、外部账号申请 等，这些在研发团队评估后，也需要进行准备。2）发版上线在万事具备后，将开始进行上线，上线的话主要是研发团队的工作，研发团队需 要按照之前产品提供的方案以及上线计划将代码发布到生产环境。此时产品价值度比拟低，但产品往往还是需要参与的，因为在发版时可能遇到不 可预知问题，方便现场沟通现场解决。同时有些系统的话，可能还需要产品进行 权限配置，或者其他一些配置内容。当系统上线需要外部支持配合时，那么也需要产品经理或工程经理提前协调配 合，确保上线时外部的顺畅。 其中有个注意点，关于app应用市场审核，iOS与安卓不同，

11、需经AppStore 审核后才能安装，故可以采用提前提交审核的方式来确保与安卓可一同发版。但 假设能做到兼容，便可灵活操作。3）上线跟进上线后，在业务开始使用后，也需要跟进业务的使用情况，可以查看业务的使用 数据，并于业务回访获得反应,必要时可进行优化迭代。系统必然是在改进迭代 中走向成熟。五,工程总结在工程上线后，业务使用良好本工程获得业务认可，也意味着本工程即将结束, 因此需要考虑本工程的得失，沉淀经验教训为给整个公司的后续开展带来价值。1）工程总结在完成后，应当组织对工程进行复盘，回顾整个流程，对工程中好的点进行总结, 对出现的一些问题进行回顾，并总结教训与改进方法。对于新的方法，可以纳入 原有的流程中，对于新发现的注意项，可以放入checklist,为后续自杳防止问 题做依据。做此项是为了后续能更好提高研发侧的效率，加强彼此间的协作。是团队的提升。此项一般可由工程经理或研发经理主持。2）产品总结在但产品之外，还需要对产品进行回顾，即分析产品设计与业务的契合度，回顾 在完成需求时的历程。此项是为了作为产品人，更好提升自身能力的。可以从以 下几个角度来进行复盘：产品设计与业务的契合度，可以分析是否完成了解了业务的含义，在整个过程中是