从需求到产品落地,B端产品的几个常见问题

3 评论 3088 浏览 12 收藏 8 分钟

于C端产品不同,B端的需求和流程都有很大的差别。这篇文章,作者帮我们梳理了B端产品从需求到产品的几个常见问题,希望能对大家有所帮助。

B端产品往往是项目需求推动的,一般首先是定制化项目,在交付第一个客户之后或正在交付中,会以此项目案例为参考,去支持商务接更多同类项目。

当项目慢慢变多时,很多类似的功能可以复用,这个时候就需要用到产品和技术架构了,需要将可复用的部分很好的解耦开。

B端项目往往是复杂多样的,一般以某个项目为基础而衍生的其它项目也会签下来,如果项目比较大,一般企业会选择将不属于公司核心业务的部分外包找供应商做,但如果在评估完商业价值后,如果觉得这部分有想象空间,也会选择自己做。

一、B端产品的四阶段

B端产品开发落地可分为4大阶段:商机调研阶段、规划设计阶段、开发测试阶段、验收维护阶段。B端产品比较适合混合式开发,既有预测(也称瀑布)又有敏捷。

一般B端产品做项目的时候都需要签署技术协议,这个时候要约定交付的内容,也就是这个技术协议的内容。技术协议的详细程度影响了混合式开发中预测和敏捷所占的比例。

二、B端产品的技术协议

一方面,如果技术协议非常详细,那么就需要长周期的调研及设计,对于交付速度往往很难满足,但详细的技术协议对于项目验收却是非常友好的,一般情况,技术协议越详细,交付验收也会相对顺利,因为可以避免大部分扯皮。

另一方面,客户往往不清楚自己要什么,很难在项目开始的时候就定清楚,技术协议只能比较概括得写,快速签订也可以加速交付,项目可以快速开启,调研、设计、开发一起开展,采用增量式交付,客户采购产品都是希望可以快速交付的,有交付周期,交付周期越短的供应商将有更大优势。

三、B端从的项目启动和需求评审

项目经理拿到签署后的技术协议,组织项目团队开项目启动会议,会议后就可以正式开始干了,产品经理出详细的需求文档并拉着相关同事开评审会议,一般会拉着项目经理、研发和测试一起,项目经理代表客户方做需求把关,研发同事需要就设计方案做落地可行性的判断,测试同事需要从质量和验收角度来给出意见。

评审会议一般会耗时较久,产品经理需要切分需求,提前跟相关同事分别沟通需求,以免大家在评审会上才第一次看见需求,发现大的问题导致评审会议效率低下。往往评审会前,产品经理已经挨个聊过需求方案了,会规避掉大的逻辑漏洞。

四、B端产品的开发测试过程

产品同事根据评审会议调整需求文档,研发同事拿到评审后的需求文档,编写开发实现方案、各模块之间的接口对接方案,这个时候会从开发的角度进一步倒推需求的合理性;同步,测试同事编写测试用例,也会从另一个维度发现需求的漏洞。

产品、研发、测试,三方从三个角度完善整体设计方案,然后开干。

开发过程需要注意的是,整体开发节奏由产品经理把控,螺旋式迭代、增量式交付,目的是整个团队的工作效率最大化。具体怎么做才能做大化,不同的团队有不同的合作方式,需要大家一起讨论出一个最优合作方案。

五、B端产品的客户会签

在需求文档确定后,有一个非常重要的事情,那就是找客户确认是他要的东西,邮件确认最佳。客户确认后开干的风险就比较低了,万一客户说这不是我要的,那么可以重新调整需求,避免无效开发。

客户确认后,在正式开发过程中,一旦客户反悔要改需求,或者团队发现需求有问题要调整,这个时候就要启动变更流程,一切更改都要书面记录,邮件记录最佳。具体变更规则可以根据团队不同做调整,目的是大家都清楚并同意此变更,有迹可循。

六、B端产品的验收和维护

最终开发完成,得到一个测试通过的版本,进场交付客户验收。客户验收时,两方面将发挥巨大作用,一方面,是平时公司与客户的商务关系是否优良,另一方面,是项目开展过程中客户的参与度。这两个方面,在项目全过程中都需要维护。

验收通过后,就开开心心收尾款啦。然后启动后期维护,售后对接人需要了解项目情况,产品经理需要长期且定期收集客户反馈,研发团队持续的版本debug迭代,都是维护阶段要做的事情。

七、B端产品的战略合作及长期发展

验收和维护做到客户满意,那么此时是商务去探寻客户是否有更多商机的好时候。一旦首次合作愉快,双方公司就建立了信任关系,就可以考虑是否有战略合作机会,大家一起搞钱搞项目,happy ending。

本文由 @洗七七 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 这是谁写的

    来自河北 回复
    1. 我本人写的呀

      来自上海 回复
  2. 1

    来自北京 回复