很多公司中,开发人员和产品总会有无穷无尽的扯皮,扯到最后,双方都很疲了。产品也不想搞新的创新了,技术也不愿意优化技术路线了,按照最保守的方式治疗就好了,即使上线拖期,也是产品的问题。
这篇文章不想讨论是技术问题还是产品问题,而是关注一点:产品设计出来的UI/UE可能会给开发造成不必要的麻烦,或者说,在满足功能的前提下,做一些调整或变通就能极大的降低开发成本。
在传统的模式下,总是产品设计原型,技术去实现,往往技术是被动的,也很难解决上面的问题。
在我的团队中采用了一种新的模式:先技术实现,然后产品设计。
这个模式取得了非常好的效果,大幅提升了开发速度,软件的架构也高度优化,同时能够达到产品的设计要求,有的时候甚至有惊喜给到产品。
先说一下背景,我们的团队主要负责开发低代码平台,在开发过程中也会遇到上面的问题:
- 为了实现产品经理设计的效果图,花了很多开发时间,但是从技术角度看,有些功能细节可能不值得这么大投入;
- 真正开发完了,才发现设计阶段想得很好的功能,或者说觉得应该很好用的功能,真正用起来,感觉很别扭,又需要调整。
以portal的开发为例。如下图
第一个阶段(其实也就是第一个迭代),先让开发人员实现页面布局功能,包含拖拽,设定每个块的尺寸;
第二个迭代,实现最基本的几个类型的块,比如:表格,饼图,柱状图,这个时候,数据是通过sql直接从数据库取得的;
第三个迭代,增加地图组件;
第四个迭代,找了一个正在实施中的OA项目,这个项目中就有一个portal页面,不过这个页面是前端和后端开发手搓的。让低代码开发人员参照这个实际项目的portal,用最直接的技术路线实现以下;这个迭代增加了导航入口和列表;
第五个迭代,产品经理开始介入了,对于上述组件的配置方式和实现的细节提了一些细化的要求,不是通过原型图,而是文字描述;这个迭代增加细化了列表和导航的配置方式,显示方式更灵活了,以及一些以其他的改进;
第六个迭代,开始进行更细致的改进,包括环境变量的,文字模版等等,增加了日历组件。
至此,基本上达到了一个可以演示,可以进行项目试用的portal设计器的版本。后续还要通过实际的项目落地进一步完善。
上面提到了6次迭代,其实每次迭代也就1-2天,整个加起来也不到两周时间;每次迭代开发完成,都是以演示的形式进行交流,开始几次迭代是技术经理给出改进的需求,后面的迭代是产品经理和技术经理一起给出改进需求。
有几个优点:
- 整个开发过程以技术架构为核心,用最短的技术路径实现最常用的功能。
- 开发人员的主动性充分发挥,开发效率非常高,而且架构很合理;
- 基本上没有什么浪费的工作,通过多次迭代,即使有设计偏差,也可以用很小的成本纠正;
- 对于产品经理也很友好,随时可以看到产品,体验产品,对于进度充分可控,随时调整需求;
- 开发和产品都表示情绪稳定;
有几点也需要特别注意:
- 开发人员要有足够的经验,独立作战能力强,最好是全栈;
- 适合于产品模块从零到一的快速搭建,不适合业务系统的项目开发;
- 产品经理也要有足够的经验,对应用场景有充分的理解,这样一来,才能根据迭代的进展不断调整和优化产品需求;