【产品经理】产品增效项目落地,项目反哺产品成长

发布时间:2023年12月17日

产品和项目是相辅相成的关系,产品的规范、成熟,为项目的快速落地提供支撑,项目的落地反哺产品,促进产品的成长成熟。

在这里插入图片描述
软件工程的初期是,我们需要什么,就立项项目,通过项目实现需要。

随着项目的增多,发现项目的相似度很大,甚至于有一些部分能够直接重用。则逐渐将能够重用的部分整合在一起,形成一个新的产品。

产品和项目需求越贴合,项目实现的效率就越高,项目落地的代价就越低。

随着项目的变多,类型的扩展,产品本身的复杂度就会提升,乃至于成为一个专门的课题。这也是当前低代码平台兴起、火爆的原因之一。

产品或工具的本质,都是为了降本增效。

产品的规范、成熟,为项目的快速落地提供支撑;项目的落地反哺产品,促进产品的成长成熟。

一、低代码平台产品

低代码产品要解决两个问题:一是常见系统所必备且相似的模块复用;二是降低系统开发的难度。

基于模块复用,几乎所有系统都需要的权限、组织、用户,就成为了低代码平台的基础部分;

基于降低开发难度,通过页面及元素的拖拉拽完成系统搭建成为设计指导方案,表单、工作流、报表就成为了低代码平台的核心模块。
在这里插入图片描述
整体的梳理过程,构建了低代码平台各功能模块的相互联系,厘清了各模块的优先级,从而形成低代码平台成长蓝图:

第一版本:搭建基础:

权限、组织、用户为系统的基础模块;

应用开发工作台,为应用开发提供基础环境;

第二版本:核心模块搭建:

表单、流程、报表为系统的核心模块,作为低代码搭建系统的核心工具;

集成应用,补全应用开发及发布的整体流程,实现应用开发的完整生命流程;

第三版本:补全更多业务场景:

APIX 支持接口编排,实现更多的业务流,丰富实现路径;

图表,提供更为丰富的展示方式,为大屏效果奠定基础;

数据模型,打通另一种低代码搭建的指导方案,通过模型复原页面交互;

第N版本:完善业务场景,提升用户体验:

通用数据处理平台,提供数据同步、数据清洗、数据应用的能力,实现数据再利用;

消息,支持平台消息,提高复用率……
在这里插入图片描述

二、项目实现及管理

在产品还未建立起来的时候,兄弟们就只能亲身上场,真枪实干,去把项目一个个抢出来。

产品出来了,针对新的项目,那必须带着产品上阵。这是产品得到验证的第一步,也是关键且很难的一步。毕竟这是产品的初次露面,想象的很美好,实际上可能并不是那么肥四?

涉及到的问题大致包含:

  1. 产品在项目中使用并不完全贴合,需要基于项目需要改造;
  2. 除开产品已有部分,其他需求都需要新做,那高低代码如何融合,以及融合的效率如何;
  3. 在项目执行过程中,产品完成升级,是否将最新产品合并到项目中来;

针对项目来说,赚钱才是根本,所有项目过程中的决策都应该以成本是否最低来考量。

当然,在具有代表意义的项目上,就有可能需要背着产品扛过去。产品在初始项目中使用,总是会存在各种各样的问题。若是完全用成本来考量,可能产品上前线的机会就会很渺茫。

在项目具有典型场景的情况下,需要用项目验证并打磨产品,这时候就不得不上了。用这一个项目的打磨,让产品某一个模块成为标准产品,在未来相似的项目上,就能够获得直观的回馈。这算是成本考量,只是这个成本是长远、多个项目下的综合考量。
在这里插入图片描述
随着产品的发展,各个版本产品都会有开发出来的项目,从而形成一个复杂的树,乃至于网。确保良好的溯源记录,在代码树的管理上,需要应用好tag,做好各个上线版本的封版。同时,配合文档等记录,可以进行产品、项目各自的溯源。

若每个项目完结不再有后续,那么溯源实际上并没有那么重要。毕竟,新的项目基本都会基于最新产品去开发。

项目嘛,软件嘛,要的是啥,要的是升级呀,要的是扩展呐,要的是更智能啊?这是啥,这是机会呀?也就是钱啊?

我们的产品升级了,有更好的应用,有更好的能力,你们要不要升级一下?

你们的操作要优化?业务数据要调整?人员结构要调整?

可以的,我们可以这么做这么做,这不需求就来了嘛。
在这里插入图片描述
在线下,卷起来的现在,每个人怎么可能只有一个项目呢?那作为项目经理,需要项目中面面俱到、无微不至嘛?有时间有精力,可以的哇!但一个人哪有这么多精力呢?!

项目管理,需要抓大放小。

项目要去详细、精细管理的话,五大过程组,十大知识领域,足够让人沉溺其中。

进行中的项目区分为“正常”或“异常”,直接就可以把项目的很大部分精力节省下来。针对异常项目,抓住关键部分,需求框架、技术框架、最小验证,这些没有问题,其它问题有也是小一点的问题,多加一个人、多给一点时间,也就搞定了。

再配合项目管理列表,周期性进行更新,通常性项目管理就没有大问题的。为啥是通常性的,那种本来就很难、很乱的项目,通常管理肯定是不够的!而通常性项目高效管理才能结余更多精力,应付那些非通常性的项目。

三、产品和项目相辅相成

在操作系统基础上,用产品构建解决方案,实现一个个项目。

产品模块越来越丰富,就会在广度、深度上平衡。每个模块要解决更为广泛的问题,通用性就要很强,而在指定方向的实现上,就会没有那么便捷。

在产品上就会逐渐细分:SaaS型应用,实施型应用,产品应用。

  1. SaaS型应用:此种应用只需要录入客户的基础信息,简单配置就可以使用;甚至于通用基础数据、字典数据,都可以系统内置;培训和咨询也都可以相对固定下来,落地的效率最高。
  2. 实施型应用:此种应用需要按照一定流程搭建应用,配合实施流程的培训,学习成本比较低,适用该流程的业务实现效率高,在框架内灵活度高。相比SaaS型应用,落地要缓慢一些,灵活度高一些。
  3. 产品型应用:此种应用需要了解各个产品的能力,配合产品培训,再梳理客户需求,梳理出实施通路,然后落地实现。整体学习成本较高,实现效率较低,但整体灵活度高,适用范围广。
    在这里插入图片描述
    SaaS型应用,如班组管理,就是指定了用户群体及管理的具体事项。在具体实施时,也无非就是明确使用人员账号及使用模块。整体的理念培训、使用培训都是一致的。

实施型应用,如设备集成,在了解产品设计基础上,了解设备协议,新建设备类型,完成设备接入;实施流程相似,只是不同协议需要深入了解,以及客户所拥有设备不同。
在这里插入图片描述
产品应用,如低代码平台,就需要了解各个模块的功能,然后梳理用低代码搭建什么系统,梳理完整通路的基础上,逐渐落地。这种方式前期的学习成本很高,但是应用面足够宽。
在这里插入图片描述
进行深度拆解后,要实现低代码平台的深度、快速成长,就需要使用各个层级的产品来搭建项目,从而进行更为深入的锤炼,使得产品各模块更加合理。也在搭建过程中,实现业务的深入理解,从而制作模板,让其他客户基于模板开发,再次极大提升效率。
在这里插入图片描述
要实现低代码平台,就是需要其完整解决方案的能力,在少编码的情况下实现系统搭建。而在项目落地上,需要更高的效率,用低代码平台本身产品应用,搭建实施应用则实现对产品本身的校验,还提升了项目实施的效率。这是良性循环的开启,至关重要!

在基于搭建的实施应用,搭建出来SaaS应用,就能够成为各个细分方向的解决方案,在深度上进行深远的拓展。

在产品实现上是有捷径的。

捷径不是偏门,而是少走、不走弯路!

在如下图所示,产品领域内,构建“产品应用”;通过“产品应用”搭建“实施应用”,实现“产品应用”的检核,尤其是各个“产品应用”使用在不同的“实施应用”上,他是否仍旧能够担起自己的责任。
在这里插入图片描述
通过“实施应用”搭建“SaaS应用”,本质就是打造解决方案,可以深入业务的深度部分,也反向验证、检核“实施应用”、“产品应用”。

低代码平台实现的捷径是:标杆客户的关键项目。

产品设计按照自身的设计原则,进行产品蓝图建设,然后进行“实施应用”、“SaaS应用”搭建模拟,验证设计的合理性。

在产品落地上,可通过标杆客户梳理解决方案,由解决方案梳理实施方案,由实施方案梳理产品模块,最终通过低代码产品搭建实现出来,实现整个通路的落地验证。

完成标杆客户的建设,是产品落地的实例,为推广、演示提供高可信的资料。且标杆客户本身在行业的地位,也会促进推广,形成自传播效应。

抓住标杆客户,实现客户需求落地。过程中,不自觉就完成低代码平台0-1的界线跨越。

人生也是有捷径的,少走弯路就是捷径。

文章来源:https://blog.csdn.net/qq_41661800/article/details/135017832
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。