从需求到架构（二）：需求侧
小白做产品，从需求到架构（二）：需求侧 方法论+实践真实需求案例
需求方他们是不懂技术的，明确需求和可行性才是关键
真实的我的案例后面慢慢补充进去。
需求侧
前面文章说了，需求侧大体流程是： （客户、甲方）需求 -> 理解、明确需求（我们乙方）-> 讨论、评审，确定（可否做、大致怎么做） MVP方案、Demo
作为“技术”层的我们，一定要了解基本的客户需求，然后对需求进行详细明确理解，进一步探讨和分析，看是否可行，如果可行，开始合作并对款项、合同、文档等材料准备好，同时尝试快速做一个MVP或者Demo给客户看看。
这个阶段往往是比较困难的，因为客户不懂技术本身，可能知道类似“AI生成视频”这些宽泛的概念，但对客户的诉求，一定要说明哪块他们的理解可能是有误区的，哪方面是不可以做的，可替换的方案是什么等等等。另外可能想要的是什么样的一个东西，也就是最终的呈现形式、大致使用方式等，这些都是需求明确的，不然后续进展到设计开发会比较恼火。边界不仅仅是客户需求的边界，还有我们开发本身的边界，不是什么功能都能做的。
个人整理的方法论并不一定是完全可靠的，在实践中慢慢琢磨的方法论，目前我对需求侧主要分三个板块。
大致需求
至少了解客户是什么行业什么方向内容的需求，大致需要做个什么样的东西，用来干啥。
比如现在我接管的一个就是“我们有个游戏营销的业务板块，游戏公司需要让我们找一些投放达人然后做游戏营销传播，需要设计一套系统辅助我们公司该业务板块，方便员工提效。”
明确需求
这块要对需求进行明确的把控，不然后面含含糊糊的东西讨论和执行起来问题太多了。
- 定位：行业方向等的定位要明确，主要是让我们了解业务背景和内容。
- 受众、对象：给什么人用的，涉及什么群体。
- 业务流程：也就是需求内容的具体流程，里面设计哪些环节，各个环节会有什么情况等
- 内部资料、数据、等的明确，比如一张表啥类型的里面哪些字段啥的，从哪来的怎么整理的，这些明确好。
- 边界、约束：酷虎那边的边界点，各环节的边界点，我们开发的边界点。
- 其他可能补充的内容。
这里面<背景|业务流程|各环节数据>这三个点我觉得是相对比较重要的，如果能有一个人工样例最好不过了，而且是正式的业务内容样例哈，能跑通流程的。
讨论、评审、定方案
其实基本背景和需求明确好之后，基本就可以根据提供的内容和需求进行初步方案的讨论执行了，这时候可能还会与客户进行沟通商量，但这块基本上就算是把东西定下来了，然后有必要的话就开个评审会大脚讨论一番，有没有什么想法或者可能存在的问题神猫儿展开讲讲，不过得确保有一个基本的方案出来，如果不可行的话就需要跟客户说明白原因啥的，看是否可以换方案这些。
MVP、Demo
初步方案定好后同步进行Demo的制作，Demo可以是人工或者粗糙的Demo，只要保证通过某些工具、技术、方案能够实现背斜功能就行，做一版Demo也就在一两三周左右，当然也可以做MVP东西。
这个主要是给客户展示或者演示看的，说是不是襄阳达到这样的效果或者基本的预期。