PRD

实战总结:我是怎么从0到1做后台业务系统的?

发布日期:2022-04-21 21:32   来源:未知   

  从0到1设计一套系统,是一个产品经理成长的必经之路。在过去几年中,我积累了很多企业内部业务系统从0-1的经验,本文重点将其进行抽象总结,并总结那些掉进去的坑和是如何解决的。

  2.原有的业务模式基本都为线.公司原有系统已经不能支持业务发展,且迭代成本已经比较高时;

  而想要做到以上两点,其实和用户侧从0-1的本质没有区别。但是在各个环节还是有所差异,接下来进行细节的介绍。

  需求调研在现实中,一般都是领导层决定战略层,决定做还是不做,而由资深的产品经理来落地执行。一般来说我们通常要做的是找到最优路径,也就是系统设计。而在找到最优路径之前,有时候需要完成先了解现在的实际情况(A在哪里),以便产品方案不是空中楼阁。

  1.系统使用方多的时候,内部调研很容易出现多方说法不一致的情况,此时一定要多方汲取意见,多总结思考找到正确的道路;

  2.外部调研的时候,其实不在于系统本身和竞品对标,而在于商业模式。我们可以与其它人进行交流,也可以通过一些软件服务商公开的软件服务,吸收其设计精髓。

  3.业务方前后说法不一致:注意产出业务流程图,并且一定要与实际操作人确认一下。通常如果是战略项目,一般可能是与业务领导先沟通,然后指派其它同事进行细节沟通。而这个指派人,很可能并不是实际操作人,而是实际操作人的领导。这个时候,注意要和实际操作人的交流和确认。细节会决定成败。

  方案设计找到了A点,知道了B点在哪里,接下来就是要设计最优路径。这个环节,考验的是产品经理的设计能力。这其中最终需要产出的就是原型和prd交付开发。为了我们的设想更好的被理解,其实可以借助这些以下这些内容:

  功能架构图功能架构图,可以很好的帮助大家理解系统都包含哪些功能模块,和哪些系统可能有交互。如果是一个工具型项目,可以采用我之前我画过的发票系统的案例。

  功能架构图最好是一个完整的构想,然后将本次做和不做的内容通过颜色区分。方便以后迭代。

  流程图流程图常见的就是泳道图。但是有时候用泳道图表达感觉比较重的时候,其实也可以用时序图来表达。此处在网上随便找了个时序图,感兴趣同事可以自行去查看。

  1.如果是与外部系统交互时,外部系统已经有现成的接口,可在流程图里说明说的是哪个接口,否则很可能会用错接口,或者与最初设想有所偏差。

  功能点列表如果系统细节太多,一定要有功能点列表,此处不止方便下游同事理解,也方便自己查看设计疏漏。

  有些观点认为在原型上的标注能够代替prd,但我认为还是值得花时间去认真写。此处将帮助自己再次检验在有限的时间里自己的方案还有没有疏漏,而且是交付下游的重要凭证。

  以上都是工具和表现形式,而通过以上工具和表现形式,最重要的是传达出自己的设计思想和全部的设计细节。在从0-1的设计中,由于细节太多很可能会有一些细节遗漏,所以我自己做了一份产品走查表,用于审阅自己的设计有没有缺失,此处大家也可以自己做一份属于自己的走查表。

  项目落地从0-1的系统设计,找到了最优路径只是万里长征的第一步,接下来的落地过程才是一脑门官司。前面的设计做的越完善,在落地过程中就会越少问题。

  此环节如果想要更顺利,我的经验是需要和开发负责人配合紧密,更大的去促使开发负责人的发挥能动性。而为了我们的设想能更好的落地,产品经理最好不要当甩手掌柜,越深的参与越能让系统的实现和自己的设想偏差越小。

  相信大家在这个环节都被遇到过很多坑,不一一言表,此处说几个重要的地方怎么避免:

  1.开发评估时间过长:在方案设计环节一定要完成好功能点的拆解,这样在这个环节会更快的完成功能的省略;

  2.在开发过程中加人:此项是项目管理中应该避免的,但是有些时候为了赶工期确实会存在这样的情况。这个时候产品经理最好主动给新进入人员讲解背景和需求,不然此处会是一个出现问题的点;

  3.开发过程中发现产品细节疏漏:挺起胸膛,这是产品争取但是不能完全避免的,所以发现记得加,在修改的地方标注上改动和日期。如果影响了工期,记得要评估好为什么会影响,看是不是确定一定要影响;

  4.验收环节发现系统实现与设计偏差过大:这个环节再发现就搞不赢了,一定要在前期开发设计的时候参与开发方案的评审,以及在测试初期看一下开发实现,避免出现这个情况。

  业务系统的设计最重要的是符合并引导公司内部运营需要,能节省业务操作,并且能支持业务扩展。所以系统设计更多的需要我们理解商业模式和业务模式,依靠我们的逻辑思维能力,找到属于我们的最优路径。澳门精准资料论坛大全