缘由，最近有个项目处于一种进退俩难的状态。前期的需求极其简单，就是仿照现有的网站做一个类似的出来。项目是没有模板的，但是核心功能看上去并不复杂，所以约定就很简单。复制出一个当前正在运行的网站。结果我把这个网站当成是普通的仿站。根据当前的网站模板，拉前端页面，然后嵌套后端API来实现，从外表上看，已经实现了95%的复刻。但是随着复刻的深度，发现这是一个需要交易的网站，并不是只是实现功能即可，面临一大批的相关审核，而且手续还挺多。

然后走流程的时候发现，复制的时候，只是复刻了一个新客户端，还有推广端，而推广端的是没有数据，需要自己去脑补的，而更糟糕的是，复刻的网站本身并不完善，他们每周都有版本更新，导致你在交工的时候会发现永远也对不上最新版本，而老的网站版本因为各种原因发现并不能运营，也就是仿站的目标就是因为在运营里面出现了各种问题，导致系统在不断升级。而这个时候，你第一个版本的初心简单的仿站，发现变成了需要完成整个系统的业务逻辑梳理。

而到了现在这个时刻，终于意识到了问题。开发之前做的约定，其实是无效的，没有需求文档和逻辑功能的完整，就开始开发的程序，只是简单模拟对标站，最终会因为陷入对对标站的模拟，陷入业务逻辑层面的反复推翻和重做。所以终于意识到了，很多项目的烂尾，很可能并不是技术原因，只是因为成本原因，如果项目的最终实现无法用一个简单的交互给客户推演，最终肯定是会出现很难收尾的情况。

  开发过程里面，会有很大一部分项目最终都会开发失败，要么是开发周期明显超过预估的时间流程，要么是开发成本大幅度超过自己的预估。在这方面，显然是低估了项目需求文档的发挥的作用。项目需求越详细，项目完成的几率就越大，反过来，项目需求不明确的时候，前期开发的速度可能比较快，但是最终成品的时候，你会发现处于一种永远也做不完的状态。

  仅仅靠客户简单的描述，还有一些附加的说明补充，来开发产品，脑补出来的东西，经常性的会缺失交互的逻辑断层，而这些逻辑断层，直接导致开发的产品工期成倍的增加，最后开发者承受不住成倍增加的工期，要么项目开发失败，要么开发者承受不住成本压力自动放弃。所以产品经理和项目经理这个角色并不是会开发程序就可以替代掉。当软件复杂度很低的时候，程序员可以让客户简单描述，然后实现出对应功能，当项目复杂度一高，实现功能的逻辑性前后，程序员大概率是搞不懂为什么这么写，只是知道实现这么一个功能。而为什么出现这个功能，直接决定了后期可能存在的返工。

项目需求: 整理详细的流程描述，完成整个逻辑交互，并列出其中需要开发的核心点还有标注最终呈现的效果和逻辑弹性扩展。优先于页面需求标注成功实现的逻辑交互。
产品需求:根据项目需求，转化成简单的原型交互图，并确定一些稍微细节的交互流程。
UI : 将产品原型转换成可以看到的视图文件，并提供给开发程序的人员
前端程序员: 将UI原型图转化成各种客户端代码
后端程序员:实现项目后台的的完整具体逻辑。
测试:验收开发写的代码程序，根据项目需求进行验收   

项目需求如果定义错误或者模糊，需求定义错误，导致直接重做（意味着做的再快，其实也是返工） 需求模糊（意味着巨大的沟通成本，导致程序员需要不断询问产品定义需求逻辑。
原型交互，没有原型交互，项目成员独立开发情况下，每个人都会按照自己的一套理解构建交互，有的时候是错误的，不过当项目不是很大的时候，其实互相理解差距不大，不过当项目比较复杂的时候，理解差距就很大了。

在线相关协作平台:

蓝湖 https://lanhuapp.com/     项目文档 需求  bug整理反馈

墨刀 [墨刀 - 百万产品团队的共同选择 (modao.cc)](https://modao.cc/)   产品原型转化与查看  包括相关协作

PIXSO   https://pixso.cn/  产品设计协作一体