在工作中，很多时候，我们都需要就一个问题提出一个解决方案，这时候，我们很可能需要产出一个文档来供大家讨论，并指导下一步工作计划。
问题可大可小，形式上是否叫它为一个项目并不重要，重要的是为了解决这个问题，项目规划和方案设计的流程是一致的。就大数据平台构建的语言环境来说，它可以是整个平台体系的搭建方案，也可以是具体某个组件如调度系统的建设，还可以是某个具体的功能点或问题改进比如用户任务脚本的依赖关系分析，系统稳定性的提升等等。
一篇项目规划和设计文档的好坏，往往决定了一个项目整体的调性和可预期的产出结果。但是，这么重要的文档，真正能写好的同学却并不多，很多同学甚至可能都没有意识到它的重要性，而仅仅是把它当作领导要求的一个软件流程的规范来简单应付，怎么快怎么来。
事实上，撰写项目规划和设计文档，最重要的不是文档的模版和格式，而是里面的具体内容，它往往需要结合实际客观环境因素来综合考虑，平衡取舍，是一个需要充分脑力活动的工作。尽管如此，在大多数情况下，还是有一些相对通用的指导原则可以帮助我们更好的完成这项工作。
本文侧重于方案的需求分析到概要设计部分，因为这部分内容通常是最容易被大家忽视，也最需要方法论和“端正的思想”来指导的 ；）而详细设计相关内容，考验更多的是技术的深度，以及如何做到全面周到，我计划在后续文章中另行阐述。
方案规划设计文档的好坏，几乎完全取决于这一部分内容。但多数同学在这一部分内容身上，往往花费的时间却是最少的，常见的方式，就是“直奔主题”，上来就写具体要做的事
如果项目背景，目标的描述不能起到这个作用，那这一节内容就没写好，因为项目方案文档就缺乏了根本的出发点，后续的内容都没有了好坏对错判断的基本依据。
项目核心需求和项目目标有什么区别？实际上没有严格的区别，只是对需要解决的问题的概括抽象程度的不同，或者描述角度的不同。
而项目核心需求，可以理解为了解决背景描述的问题，为了实现那几个目标，进一步推导出来的，在当前系统环境或方案框架体系中：必须要提供的产品功能形态，或者是必须满足的关键特性，又或着是不能违背的约束条件。你也可以理解为用更技术的语言进行细化描述的项目目标。因为目标和背景的不同，可能同一件事推导出来的核心需求也不同。
这么说比较抽象。举个例子，如果我想构建一个数据交换服务或ETL系统，那么上述各环节的内容可能是（简化的写）：
讲完区别，继续回来讲，这部分内容的要求。很多同学在写这部分方案的时候，很容易把需求和实现手段混为一谈。所以：
原因也很简单，脱离了目标谈手段是没有意义的，很容易导致方向做偏，使得最终的结果产出背离了项目最初真正的需求出发点。
实践中，做成什么样和怎么做有时候很难绝对分开。一句话的描述方式可能既包含了目标需求也包含了实现手段。那么，怎么判断这部分内容写得是否满足要求呢。
如果你描述的侧重点只是需求的一种实现方式，而这个需求可能还有更多的其它实现方式，或者即使真的只有一种实现方式，你所描述的内容的也只是因果关系中，间接的因而非直接的果，那么很可能你描述的就只是手段而非目标。
如果看文档的同学看完只知道你要做什么，而不知道做这些是为了什么？是否做这些就足够了，还应该做点别的？是否有别的解决方案，又或者做完了到底有什么用。那么也很可能是因为你把需求和实现手段混为一谈了。
核心需求必须是本质的，一定要实现的功能，它是一个原则，不是工作列表。不要事无巨细，凡是想做的都列在上面，那样反而淡化了项目最根本的诉求。但它也必须足够全面，要能确实解决项目目标中所提出的要求，应该用适当抽象的语言概括一个完整的事项。
总结一下，核心需求的根本目标是，让参与项目的同学有方向感，能够知道这个项目最终想要通过提供哪些能力，满足哪些约束条件来解决问题，至于怎么实现，具体要做哪些事，那是下一步才需要回答的问题，简单来说：先选择做正确的事，再考虑怎么把事做正确。
这一部分内容，从实际操作的先后顺序来说，未必是第二步，很可能在我们总结前面的背景，目标，核心区需求的时候，就需要加以收集和分析。
不过，从方案文档的角度来说，放在这里，是为了进一步细化问题，分析目标，核心需求与当前现状的差距在哪里，具体有哪些实际问题需要解决。为后续具体的实现方案，准备必要的输入信息，确定工作的优先级，重要性，项目迭代的步骤等等。
需要强调的是，现状和问题分析，要围绕前面的核心需求的条目展开，两者是强关联的，不要相互脱节，各讲各的
所以这部分内容，难的是如何发现问题，很多做技术的同学往往容易陷入只关心技术难点，只能看到技术问题的局面中，而实际上，更多的问题往往是整体流程如何设计更加合理的问题，而不是技术方案绝对对错的问题。
尽管行文上不难，但它的重要性，也往往容易被忽略，很多情况下被简单对待。实际的情况是，很多项目的方案计划往往是在对现状问题相关信息没有充分收集和分析的基础上就做出来的。导致项目方案后期不断调整，或者一期一期的总是在小步迭代，甚至不断推翻重来。而最终使用方真正关心的问题却一直没有得到重视和解决。
这部分内容，强依托前面的核心需求和问题分析工作，没有做好前面的准备工作，千万不要着急开始动手“规划”方案！！！
做什么和前面项目目标的要求刚好皆然相反，需要输出明确的可执行的事项，而不是模糊的不可执行的要求。
具体做的每一件事情，都要和前面的核心需求和现状问题对应上。如果你发现有些工作，和前面的目标没有任何关联性，那么考虑一下目标是否需要再评估调整，或者这件事情根本就是不重要的。
要做的事项列表，是一个经过归纳思考以后的总结，而不只是一个个零散的事情的随机列表。需要有重点和优先级。如果有必要，以归类，分组等形式结构化的组织相关联的事项。
完整的事项列表，应该是一个和最终目标对应的完整解决方案，而不仅仅只是完成目标工作中的某一个环节。
比如面向用户的终端产品项目，需要包括整个产品的交互逻辑，业务流程的规范设计等等，而不仅仅是对底层系统实现和后台功能点的设计。
这点很多同学也很容易忽略，总觉得功能和架构的实现才是有挑战，需要规划的内容，而产品的形态并没有花心思去琢磨，事后开发前端时才来考虑。实际上后者可能才是真正影响项目成功的关键，也很可能会影响到底层架构的设计和取舍。类比一下，好比一个用户产品都开发完了，才来考虑埋点，数据采集和数据分析的工作，这时候就很被动了。
前期方案文档，没有必要列出详细的技术方案细节，只需要一个整体的技术方向选型和初步的架构设想。但是，如果是涉及到核心需求能否有效满足的关键的技术点，有可能影响整体的架构或产品实现的，那就有必要就可能的方案的进行详细的评估并得出初步的结论。
方案中有不明确的地方，即使没有时间调研，也不要简单的略过不写，要在文档中明确的把问题写出来，给出下一步调研的方向计划等。归根到底，方案文档中，对每一个已知重要的问题，都需要一个明确的结论或者可以后续跟进的计划，以免事后遗漏。
再强调一下，做什么和怎么做就是手段，既然是手段，就要写得足够具体，具体到有明确的可落地实施的事情，有明确可以衡量的标准，或者针对当前存在的一个具体问题，不要在这个地方又写得像目标，没有明确的可执行的点。
这是做什么和怎么做的进一步延伸，需要强调的是整个项目如何实施的整体步骤计划，而不仅仅是简单的列一下每项工作的人员和排期，
需要分析系统可能的迭代步骤（包括可能的短期应急和长期解决方案），上下游依赖梳理，需要协同进行的工作，最终项目上线时可能的业务迁移，数据迁移，系统集成等等外围工作的安排。
如果不是工期严格要求，deadline为导向的项目，整体的依赖和步骤往往才是在项目规划阶段需要重点阐述的内容，也是有可能对整体产品的进度，风险产生影响的事项
而具体工作工期的安排，说实话，多数情况下，反到没有那么重要。如果整体工作和步调没考虑周全，工期排得再科学，再精细，也毫无意义。
总结一下，什么时候做什么事，最重要的目的，不在于工期的计算，甚至也不是人力资源的安排，而是为了理顺事情依赖关系，控制可能的意外风险，提升项目开发进度的可控性。
方案规划设计文档，绝对不是为了满足流程需要凑数的文档，也不是头脑风暴式的简单记录。它的根本目标，抽象来说是：明确问题，圈定范围，确定重点，阐明路径。本质是为了统一认识，控制风险。它应该是一个问题经过思考以后的输出的答案，而不是问题的调查报告，笔记或备忘录。
它很像一个议论文体裁，事实，分析，结论缺一不可。所以，无论你的方案文档写的多么翔实，如果只是相关内容细节的罗列，只议不论，缺乏抽象总结，还需要阅读文档的同学再去揣摩项目意图，或者看完以后对项目所要做的工作为什么要做，重不重要，要做成什么样都不明确的话。那它就只是一个不合格的半成品，不能对后续的项目开发工作发挥实质的指导和规划作用。
围绕最终目标，输出完整的端到端的解决方案，而不是局部环节的方案。需要从最终产品/功能形态的角度考虑要做的事，而不是仅仅考虑底层技术实现。
事项目标列表，不要仅仅罗列要做什么事，更重要的是说明想要得到的结果，而不仅仅是描述实现手段。
所有工作事项，需要明确思考过实施步骤，重要性和优先级，结合目标和需求，进行抽象归纳，而非简单随机罗列。
要有明确的计划排期，但更重要的是，要完整的分析思考可能的上下游和周边工作依赖。排期只是结果，完整的梳理才是关键。
如果开发同学看完文档，无法根据后续开发过程中遇到的实际情况，调整工作事项和优先级，完善和改进这个文档，那么大概率这个项目方案文档是没有写好的。因为这个文档可能只起到了事项罗列和工作安排的作用，却没有起到指导思考，授人予渔的作用
如果看完文档，这个项目的最终产出你无法预见，你对项目的目标最终能否实现无从判断，那么这个项目方案文档大概率也是没有写好的。因为这个文档自身的归纳总结可能还没做到位，风险和问题可能还没有评估清楚，还需要走一步看一步。
写项目方案文档，不是八股文，所以本文的内容并非绝对的教条，你当然可以根据项目的实际情况和复杂程度自行调整，但前提是你真的知道你为什么要这么做，而不仅仅是为了偷懒
本文多数内容是各种观点，注意事项，结论和目标，具体如何做到这些，每个同学都可以自行思考。当然除了思想和目标端正，每个环节，其实也有一些具体Tips和checklist可供参考。下一次再说，下一次再说吧。。。
本文写的各项原则，在我们之前的项目实践上实际都有体现，有兴趣结合实例比对参考的同学，我再厚脸皮再推一下这本书 《大数据平台基础架构指南》
是根据用户需求转化而来的技术实现需求，需要针对用户提出的产品目标进行细分，总结出具体的每一个功能点，再针对每一个功能点细分为各种不同的操作流程，对每一个操作流程进行技术化定义。也就是说，需求
则是站在开发人员的角度来软件需要实现的功能、各个模块和其重要性、以及业务流程等。......
之前的文章，整理了一下，补充了一些内容，做了一些更新，现已出版上市了。无耻的推广一下哈；）淘宝，JD都有现货，Amazon貌似还是预售状态中感谢博文视点的@侠少，感谢各位替本书
推荐语软文的朋友们，感谢之前蘑菇街大数据团队的各位小伙伴。目录列表：第1章 大数据平台整体建设思想11.1 什么是大数据平台11.2 大数据平台的建设目标31.2.1 别人的大数据平台是怎样的31.2.......
什么是元数据？在前面的集成开发环境建设相关文章中，我们也提到过，元数据metaData狭义的解释是用来描述数据的数据，广义的来看，除了业务逻辑直接读
处理的那些业务数据，所有其它用来维持整个系统运转所需的信息／数据都可以叫作元数据。比如数据表格的Schema信息，任务的血缘关系，用户和脚本／任务的权限映射关系信息等等。管理这些附加metaData信息的目的，一方面是为了让用户能够更高效的挖掘和使用......
我是一名程序员，从正值青春年华的 24 岁回到三线城市洛阳工作，至今已经 6 年有余。一不小心又暴露了自己的实际年龄，但老读者都知道，我驻颜有术，上次去看房子，业务员肯定地说：“小哥肯定比我小，我今年还不到 24。”我只好强颜欢笑：“你说得对。”从我拥有记忆到现在进入而立之年，我觉得，我做过最明智的选择有下面三个：1）高中三年，和一位女同学保持着算不上朋友的冷淡关系；大学半年，把这位女同学追到......
前面放完建设四个现代化大数据平台乌托邦理想的大卫星，接下来的文章得谈谈具体组件的生产了。第一篇，先来讨论一下大数据开发平台的核心组件之一：作业调度系统。作业调度系统是一个相对复杂的系统，涉及的内容繁杂，针对的场景多种多样，实现的方案千差万别。本文重点谈理论，会先从大的场景划分的角度对市面上的各种调度系统进行分类讨论，然后再针对具体的作业调度系统，探讨一下各自的优缺点...
，详细说明页面信息，明确交互设计，防止信息遗漏，提示沟通效率，确保开发人员可以明确理解页面设计并完成页面开发。主要标明字符限定，链接跳转，交互细节，校验，显示隐藏情况产品需求
PRD做好准备工作：调研，确定产品目的：价值主张，确定用户原型、用户目标、用户任务，定义产品原则，产品原型，可行性，可用性，概念，验证，
