共计 778 个字符，预计需要花费 2 分钟才能阅读完成。
这是一个实在的故事，来源于一个开发的敌人。
他们是一个守业型公司，老板守业开始，为了省钱，外围的资源投放在技术端（人力老本），产品人员招了个 2 年教训的产品经理。我的项目从开始做的第一周，长期不停地撕逼开始了，碍于我的敌人是个技术人员，口才与撕逼的能力远远弱于产品经理。痛苦不堪（尽管不抵赖，然而那个产品妹纸还是长得能够哈）。如果您也遇到过这种问题，点个赞 哈哈。
他把这个事件通知了我，而后我教了他两招，而后取得了比拟显著的成果。其实这个事件咱们私下也剖析了，当初往往很多产品经理入行是通过经营、或者 UI 设计转成的产品，这种类型的同学有劣势有劣势，有时对业务分明或者对审美比拟优良，然而往往不足对技术、逻辑层面的思考，然而他们的语言表达能力丰盛，感染力强，而产品的对手方的技术人员往往不太长于语言的表白，这种状况下沟通不免比拟艰难。其实外围的思路就是让产品经理深度参加交付，而不是简略的梳理需要，让产品经理有实现的逻辑思维，这样能力无效解决产品与技术交换的问题。
我倡议的办法：
1、找了个低代码开发的根底框架，私有化部署起来了
2、让产品经理学会页面配置（CRUD、图表展现、首页展现），这个很快就搞定
3、产品的每个按钮触发的逻辑 能配置的就配置，配置不进去的再补充原型图 + 文档（文档我也举荐了个协同文档，黑纸白字哈哈）
4、每次产品的思路与设计实现后，用配置的页面，先给大家讲，个别在讲的过程中产品往往会发现大多数的逻辑问题
5、讲完后，让技术人员做性能反讲，让产品来判断是否正确
通过这种形式，反而效率晋升了十分多，扯皮的事件大大降低。其实让产品有粗浅的技术交付思维，其实对整个我的项目来讲大大降低了有效的开发需要与变更节约。
最初，把这个低代码框架分享给大家，也心愿能帮到须要找开发平台的大佬们，开源地址：https://gitee.com/software-mi…
