转载时请包含原文或者作者网站链接：http://oliveryang.net。
1. 问题！问题！问题！
工程师的使命就是发现问题，定义问题，解决问题。
根据要解决问题的复杂度，这个过程中，团队内部或者相关团队之间可能要做大量的沟通和讨论工作。
通常来说，对一个 Idea 品头论足很容易，但是要付诸行动，或者要求其它团队配合就很难了。 很多时候 Idea 的提出者需要去考虑采取不同的沟通和讨论方式来逐步推进 Idea 的落地。
本文尝试从以下方面去讨论一下项目建议 (Project Proposal) 的基础。
2. 完整的方案
个人认为，一个完整的问题解决方案，应该做到 S.I.M, 即以下三个方面，
-
Story
就是讲故事。用户的痛点是什么，产品使用存在哪些问题，有哪些直接的或者潜在的需求。 收集到了足够的用户信息，可以与用户共情以后，就可以清楚的定义问题了。 问题的定义是讲故事的关键。 一旦定义好问题，那么接下来就是解决问题后，产品在 Use Case上有哪些具体影响。 可能是对原有 Use Case 的改进，也可能是引入了新的 Use Case。
总之，讲故事的最终目标是打动和吸引能和你一起做事的核心贡献者或者找到项目的资助者 (Sponsor)。因此，它必需从客户和业务角度出发，把问题发现，定义，解决讲精彩，做到引人入胜。 这在大的项目或产品里是至关重要的。
项目的发起者一定要清楚，自己的项目需要在组织内部的哪个层级才能做决策。如果超出了自己层级的范围，一定要在技术线，管理线，资源线都找到自己的项目资助者。 有潜在利益冲突的人，级别再高，也不能做项目的资助者，公司的制度设计者和立项流程最好保证这一点。否则，就需要项目的发起者自己去操心了。
-
Idea
就是讲清楚问题解决的框架和关键点。框架是解决方案的鸟瞰图，它帮助别人从全局进一步了解 Idea 的全貌。关键点就是解决方案里的核心价值，及创新的部分, 或者是差异点。 关键点的独特性通常决定了我们是否可以提交专利 (file patent)。
因此，复杂的项目在这里需要给出概要设计 (High Level Design)。这里主要有几部分，
- 项目架构 (Architecture Diagram) 可以帮助大家理解不同子系统或者模块是如何配合在一起完成主要功能的。
- 应用主流程 (Application Flow) 系统的主流程说明，比如 Data Path Flow, Control Path flow, error handling 是怎么样处理的。
- 关键挑战 (Key Challenges) 这里是影响项目进度和能否落地的关键环节。要分析其中的技术难点，近早决定通过做原型来验证解决办法。
这部分是证明 Idea 核心价值，保证项目最终可以落地的重要环节。如果不能做到可以根据这个设计去开始实施项目，那就需要再细化。
-
Metric
就是项目管理的各个可度量的要素：范围 (Scope)，时间线 (Time Line)，质量 (Quality)。 为保证一个复杂的解决方案落地，常用的办法就是定义多个阶段性目标，即里程碑 (Milestone) 和完成的定义 (DOD: Definition Of Done)。
更重要的是，投入产出的分析 (ROI). 项目实施的成本（开发测试人月，其它资源），还有项目的回报。越是投入巨大的项目，越需要 ROI 量化分析。相对来说简单的项目可以只量化投入，产出可以只做定性分析。
从组织内部不同分工和角色的角度看，S.I.M 其实体现了不同角色对项目的关注点。
- 关注S的通常是管理层，产品经理，销售及市场人员。
- 关注I的通常是架构师，工程师，测试，IT运维人员。
- 关注M的通常是项目经理，管理层和 team lead。
了解这些，有助于项目的发起者根据项目的复杂度和难点去组织自己的核心团队。例如，有人去专心攻克 Idea 里面临的问题。有人去思考 Story 的问题。 而且项目的建议者还应该根据实际情况去和 S.I.M 场景下不同的人去交流沟通，逐步完善自己的项目建议。这也就是讨论和评审的意义所在。
3. 讨论和评审 (review) 流程
创新性的 Idea 需要一个宽松的讨论氛围和清晰的评审流程。
根据 Idea 的成熟度，可以考虑进行不同形式的讨论和评审 - Pitch，Presenation, Proposal
-
Pitch
早期的 Idea 可以利用 Pitch 的方式来做。主要关注点在 Story 和 Idea 方面。以建设性的建议为主，保证广度和覆盖面, 不要遗漏缺失关键点。 参与者以核心贡献者为主。头脑风暴 (Brain Storming) 等形式在此阶段使用效果可能会比较好。
-
Presentation
经过一定的调研，试错，讨论，形成了相对成熟的 Idea。此时的关注点仍旧以 Story 和 Idea 为主。但更加注重讨论的深度, 为项目落地做准备。这时的讨论和评审要注意把关键的贡献者和利益相关者 (Stakeholder) 都召集起来。
-
Proposal
通过阶段性的准备和调研，Idea 已经相当成熟。此时的关注点从 Story, Idea 转到 Metric。 不论是项目阶段的划分 (Roadmap), 还是 ROI 分析，都需要从项目实施和管理的角度出发去讨论调研。 这个阶段的最终评审要注意把所有利益相关者都召集起来，保证得到相应的反馈。 此外，这时需要的不单是利益相关者的反馈和口头建议，最终还需要获得他们的正式许诺 (Commitment)。
4. 总结
提出，分析，解决一个复杂的问题需要的不仅仅是硬实力，还有软实力：沟通能力，领导能力，项目协调管理能力。 这里面有不同的概念，方法，可能会涉及到商业技术领域的方方面面。更重要的是，需要不断的实践。
Project Proposal Basic 这个文档尝试从工程师角度出发，帮助工程师了解什么是一个相对完整的项目建议，如何去分阶段去输出调研成果。 题目有点大，希望现在的版本会是一个好的起点。随着个人的认识不断深入，这个文档会持续更新。
写这个文档的时候也忽发奇想：S.I.M 的框架是不是也适用于学习和总结一个产品或者软件项目呢？下一步可以尝试去实践一下。