如何使自己的创见落地？
本文首发于http://oliveryang.net，转载时请包含原文或者作者网站链接。
工程师的使命就是发现问题，定义问题，解决问题。
根据要解决问题的复杂度，这个过程中，团队内部或者相关团队之间可能要做大量的沟通和讨论工作。
通常来说，对一个idea品头论足很容易，但是要付诸行动，或者要求其它团队配合就很难了。很多时候Idea的提出者需要去考虑采取不同的沟通和讨论方式来逐步推进idea的落地。
本文尝试从以下方面去讨论一下项目建议(project proposal)的基础。
1. 完整的方案
个人认为，一个完整的问题解决方案，应该做到S.I.M, 即以下三个方面，
Story
就是讲故事。用户的痛点是什么，产品使用存在哪些问题，有哪些直接的或者潜在的需求。收集到了足够的用户信息，可以与用户共情以后，就可以清楚的定义问题了。
问题的定义是讲故事的关键。
一旦定义好问题，那么接下来就是解决问题后，产品在use case上有哪些具体影响。可能是对原有use case的改进，也可能是引入了新的use case.
总之，讲故事就是从客户和业务角度出发，把问题发现，定义，解决讲精彩，做到引人入胜。讲故事的最终目标除了让自己的idea更加成熟，更重要的是打动和吸引能和你一起做事的核心贡献者和项目的资助者。这在大的项目或产品里是至关重要的。
Idea
就是讲清楚解决问题的关键点。关键点就是解决方案里的核心价值或者说创新的部分。这些部分可以帮助我们决定是否要file patent.
另外，复杂的项目在这里需要给出概要设计(high level design)。这里主要有几部分，
- 项目架构(architecture diagram)
可以帮助大家理解不同子系统或者模块是如何配合在一起完成主要功能的。 - 应用主流程(application flow)
系统的主流程说明，比如data path flow, control path的flow, error handling是怎么样处理的。 - 关键挑战(key challenges)
这里是影响项目进度和能否落地的关键环节。要分析其中的技术难点，近早决定通过做原型来验证解决办法。
这部分是证明idea核心价值，保证项目最终可以落地的重要环节。如果不能做到可以根据这个设计去开始实施项目，那就需要再细化。
- 项目架构(architecture diagram)
Metric
为保证一个复杂的解决方案落地，常用的办法就是定义多个阶段性目标(milestone)。每个阶段的目标，项目的输出，时间线，如何衡量成败都要明确。
更重要的是，投入产出的分析(ROI). 项目实施的成本（开发测试人月，其它资源），还有项目的回报。越是投入巨大的项目，越需要ROI量化分析。相对来说简单的项目可以只量化投入，产出可以只做定性分析。
从组织内部不同分工和角色的角度看，S.I.M其实体现了不同角色对项目的关注点。
- 关注S的通常是管理层，产品经理，销售及市场人员。
- 关注I的通常是架构师，工程师，测试，IT运维人员。
- 关注M的通常是项目经理，管理层和team lead。
了解这些，有助于项目的发起者根据项目的复杂度和难点去组织自己的核心团队。例如，有人去专心攻克Idea里面临的问题。有人去思考Story的问题。而且项目的建议者还应该根据实际情况去和S.I.M场景下不同的人去交流沟通，逐步完善自己的项目建议。这也就是讨论和评审的意义所在。
2. 清晰的讨论和评审(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)。
3. 总结
提出，分析，解决一个复杂的问题需要的不仅仅是硬实力，还有软实力：沟通能力，领导能力，项目协调管理能力。这里面有不同的概念，方法，可能会涉及到商业技术领域的方方面面。更重要的是，需要不断的实践。
Project Proposal Basic 这个文档尝试从工程师角度出发，帮助工程师了解什么是一个相对完整的项目建议，如何去分阶段去输出调研成果。题目有点大，希望现在的版本会是一个好的起点。随着个人的认识不断深入，这个文档会持续更新。
写这个文档的时候也忽发奇想：S.I.M的框架是不是也适用于学习和总结一个产品或者软件项目呢？下一步可以尝试去实践一下。
