核心需求必须是本质的，一定要实现的功能，它是一个原则，不是工作列表 。不要事无巨细，凡是想做的都列在上面，那样反而淡化了项目最根本的诉求 。但它也必须足够全面，要能确实解决项目目标中所提出的要求，应该用适当抽象的语言概括一个完整的事项 。
总结一下，核心需求的根本目标是，让参与项目的同学有方向感，能够知道这个项目最终想要通过提供哪些能力，满足哪些约束条件来解决问题，至于怎么实现，具体要做哪些事，那是下一步才需要回答的问题，简单来说：先选择做正确的事，再考虑怎么把事做正确 。
其次，需要对现状和问题进行充分的收集和分析
这一部分内容，从实际操作的先后顺序来说，未必是第二步，很可能在我们总结前面的背景，目标，核心区需求的时候，就需要加以收集和分析 。
不过，从方案文档的角度来说，放在这里，是为了进一步细化问题，分析目标，核心需求与当前现状的差距在哪里，具体有哪些实际问题需要解决 。为后续具体的实现方案，准备必要的输入信息，确定工作的优先级，重要性，项目迭代的步骤等等 。
需要强调的是，现状和问题分析，要围绕前面的核心需求的条目展开，两者是强关联的，不要相互脱节，各讲各的
这块内容本身没有太特别的地方，就是现在实际情况如何，有什么问题，关键是如何把问题收集完整 。
所以这部分内容，难的是如何发现问题，很多做技术的同学往往容易陷入只关心技术难点，只能看到技术问题的局面中，而实际上，更多的问题往往是整体流程如何设计更加合理的问题，而不是技术方案绝对对错的问题 。
尽管行文上不难，但它的重要性，也往往容易被忽略，很多情况下被简单对待 。实际的情况是，很多项目的方案计划往往是在对现状问题相关信息没有充分收集和分析的基础上就做出来的 。导致项目方案后期不断调整，或者一期一期的总是在小步迭代，甚至不断推翻重来 。而最终使用方真正关心的问题却一直没有得到重视和解决 。
最后，是输出解决方案
定完需求目标，分析完问题和现状，接下来才是规划具体做什么，怎么做，什么时候做 。
这部分内容，强依托前面的核心需求和问题分析工作，没有做好前面的准备工作，千万不要着急开始动手“规划”方案！！！
那么具体写的时候有哪些注意事项呢？
做什么：
做什么和前面项目目标的要求刚好皆然相反，需要输出明确的可执行的事项，而不是模糊的不可执行的要求 。
具体做的每一件事情，都要和前面的核心需求和现状问题对应上 。如果你发现有些工作，和前面的目标没有任何关联性，那么考虑一下目标是否需要再评估调整，或者这件事情根本就是不重要的 。
要做的事项列表，是一个经过归纳思考以后的总结，而不只是一个个零散的事情的随机列表 。需要有重点和优先级 。如果有必要，以归类，分组等形式结构化的组织相关联的事项 。
完整的事项列表，应该是一个和最终目标对应的完整解决方案，而不仅仅只是完成目标工作中的某一个环节 。
比如面向用户的终端产品项目，需要包括整个产品的交互逻辑，业务流程的规范设计等等，而不仅仅是对底层系统实现和后台功能点的设计 。
这点很多同学也很容易忽略，总觉得功能和架构的实现才是有挑战，需要规划的内容，而产品的形态并没有花心思去琢磨，事后开发前端时才来考虑 。实际上后者可能才是真正影响项目成功的关键，也很可能会影响到底层架构的设计和取舍 。类比一下，好比一个用户产品都开发完了，才来考虑埋点，数据采集和数据分析的工作，这时候就很被动了 。
怎么做：
前期方案文档，没有必要列出详细的技术方案细节，只需要一个整体的技术方向选型和初步的架构设想 。但是，如果是涉及到核心需求能否有效满足的关键的技术点，有可能影响整体的架构或产品实现的，那就有必要就可能的方案的进行详细的评估并得出初步的结论 。
无关架构或进度安排的方案细节，没有必要写太多，可以后续再补充 。
方案中有不明确的地方，即使没有时间调研，也不要简单的略过不写，要在文档中明确的把问题写出来，给出下一步调研的方向计划等 。归根到底，方案文档中，对每一个已知重要的问题，都需要一个明确的结论或者可以后续跟进的计划，以免事后遗漏 。
推荐阅读
- 鉴别音箱的真假的方法 ae音箱真假辨认
- 野蕨菜致癌吗？
- 形容动物的词语形容动物的词语有哪些
- 饿的英文单词
- 老北京炸酱的做法求详细.
- 伦敦水晶宫的 特点
- 如何养成良好的习惯？
- 1984年的一分硬币价格 1984年2分硬币一去那里换
- 情绪爆炸，容易遇到中年危机的四大星座女是什么？
- 爱奇艺视频VIP 爱奇艺视频的vip怎么开?