开发人员最舒服的研发模式

很多公司中，开发人员和产品总会有无穷无尽的扯皮，扯到最后，双方都很疲了。产品也不想搞新的创新了，技术也不愿意优化技术路线了，按照最保守的方式治疗就好了，即使上线拖期，也是产品的问题。

这篇文章不想讨论是技术问题还是产品问题，而是关注一点：产品设计出来的UI/UE可能会给开发造成不必要的麻烦，或者说，在满足功能的前提下，做一些调整或变通就能极大的降低开发成本。

在传统的模式下，总是产品设计原型，技术去实现，往往技术是被动的，也很难解决上面的问题。

在我的团队中采用了一种新的模式：先技术实现，然后产品设计。

这个模式取得了非常好的效果，大幅提升了开发速度，软件的架构也高度优化，同时能够达到产品的设计要求，有的时候甚至有惊喜给到产品。

先说一下背景，我们的团队主要负责开发低代码平台，在开发过程中也会遇到上面的问题：

1. 为了实现产品经理设计的效果图，花了很多开发时间，但是从技术角度看，有些功能细节可能不值得这么大投入；
2. 真正开发完了，才发现设计阶段想得很好的功能，或者说觉得应该很好用的功能，真正用起来，感觉很别扭，又需要调整。

以portal的开发为例。如下图

第一个阶段（其实也就是第一个迭代），先让开发人员实现页面布局功能，包含拖拽，设定每个块的尺寸；

第二个迭代，实现最基本的几个类型的块，比如：表格，饼图，柱状图，这个时候，数据是通过sql直接从数据库取得的；

第三个迭代，增加地图组件；

第四个迭代，找了一个正在实施中的OA项目，这个项目中就有一个portal页面，不过这个页面是前端和后端开发手搓的。让低代码开发人员参照这个实际项目的portal，用最直接的技术路线实现以下；这个迭代增加了导航入口和列表；

第五个迭代，产品经理开始介入了，对于上述组件的配置方式和实现的细节提了一些细化的要求，不是通过原型图，而是文字描述；这个迭代增加细化了列表和导航的配置方式，显示方式更灵活了，以及一些以其他的改进；

第六个迭代，开始进行更细致的改进，包括环境变量的，文字模版等等，增加了日历组件。

至此，基本上达到了一个可以演示，可以进行项目试用的portal设计器的版本。后续还要通过实际的项目落地进一步完善。

上面提到了6次迭代，其实每次迭代也就1-2天，整个加起来也不到两周时间；每次迭代开发完成，都是以演示的形式进行交流，开始几次迭代是技术经理给出改进的需求，后面的迭代是产品经理和技术经理一起给出改进需求。

有几个优点：

1. 整个开发过程以技术架构为核心，用最短的技术路径实现最常用的功能。
2. 开发人员的主动性充分发挥，开发效率非常高，而且架构很合理；
3. 基本上没有什么浪费的工作，通过多次迭代，即使有设计偏差，也可以用很小的成本纠正；
4. 对于产品经理也很友好，随时可以看到产品，体验产品，对于进度充分可控，随时调整需求；
5. 开发和产品都表示情绪稳定；

有几点也需要特别注意：

1. 开发人员要有足够的经验，独立作战能力强，最好是全栈；
2. 适合于产品模块从零到一的快速搭建，不适合业务系统的项目开发；
3. 产品经理也要有足够的经验，对应用场景有充分的理解，这样一来，才能根据迭代的进展不断调整和优化产品需求；