刚看完“无问西东”，电影里说人总归还是要留下些足迹（文字）的，那么赶紧跑图书馆来留下些文字。
最近去瑞士启动了一个新的项目，那么早上做项目，晚上总结留下了一张张思维导图来记录当时的感受，
手稿如下，字写得不好请见谅：）
首先你得知道这个软件写出来是做什么的，因为不同的应用场景对软件要求是千差万别的。
例如，机械控制？那可能需要实时性高；订票系统？那需要并发性好，还有数据准确性要高；购物系统？简单，好看，好用，操作不反人类......
所以第一重要的东西就是，Domian Knowledge领域知识。
领域知识
领域知识，怎么获得？当然是找三类人（产品经理，领域专家，服务工程师）。
产品经理：是他定义的产品，他当然一般知道用户的关注点和痛点是什么，他一般也是在这个行业中摸爬滚打了很多年，你让他给你讲这个行业是个什么情况，
这个产品大概应该做成什么样子，为什么要做这个产品，他一般都有自己的一些想法（当然有时候也不是非常全面的）
领域专家：他一般知道客户生产产品的流程，知道客户会怎么使用系统来帮助他们提高产品质量或生产效率，他也知道这个行业的基本技术水平在个什么高度（现在市面上的软件能帮客户产品做什么方面的管控，如何提高生产效率和产品质量），也知道按照客户流程这个产品应该怎么做测试
服务工程师：也就是你这个软件产品交付给客户使用之后，他们负责和客户交互，解决使用和简单技术问题。所以客户的一些反馈，客户如何真正使用软件，以及客户心情他们是都知道的。他们是软件使用的老师傅。
抓住这三类人，你将获得巨大的领域知识，这样你提供给客户的功能不再只是可运行的系统，而是在不断的给客户提供价值。
需求文档
人都是靠需求驱动的，马斯洛归纳了人类的5大基本需求。软件当然也不例外，软件也是靠需求驱动的，粗略的可以分成两大类--功能性需求和非功能性需求。
所以需求文档必须包含这两部分。
功能性需求：主要描述系统的行为要求。这个一般产品经理都会写，只是详略程度各有区别。
非功能性需求：主要描述系统的性能要求。
性能要求一般包括：易用性，效率性，维护性，安全性，可扩展性，等。
性能要求看似不起眼，而且很多情况下产品经理会漏掉定义这些。然后性能要求其实是驱动软件架构最重要的元素，所以项目开始这些也要定义清楚。
拿到需求之后有以下这些动作是要做的
- 需求的澄清：先阅读产品经理写的需求文档，然后将每条需求大概的用你自己的语言给产品经理讲一遍，看看你的理解是否正确，有疑问的话直接问，因为这些疑问迟早要回答的，越晚回答越对项目造成风险。（在你发问的过程中你会发现其实很多需求产品经理也都没想透彻，你发问帮助他思考，当然也是帮助自己不要写无用的代码）
- 需求排优先级：需求一定是有优先级和版本发布最小功能集的。如果你不能挖掘出这两个东西来，你很难做成功这个项目。如果产品经理说说有的需求都重要，请给他100块钱，然后说：“假设你只有100块钱来买软件功能，请将这100块钱分配到不同的需求上，钱越多表示越重要。”这之后你自然能知道需求的价值和粗略的优先级。需求文档拿到之后还有一个重要的策略是最小集，你说：“如果我们人手实在有限，只能提供软件最基础的功能，请你告诉我软件上线，哪些功能是必不可少的。”这之后你大概就知道项目的范围了。这样一般一个有经验的项目经理大概就能知道产品按时上市的可行性了。
- 需求文档经过前两步，项目目标，可行性和真实需求应该会比以前清楚不少了，那么后面项目经理一般会让开发组出一个项目估算。我只能告诉大家这个时候的估算，一般都不是太准的，但是我们可能试着提高估算的准确性。这里有个技巧就是把需求用User Story（https://www.mountaingoatsoftware.com/agile/user-stories）的方式来描述：As ...(role) I want ...(function)..so that...(purpose) 就是作为什么样的角色我需要什么样的功能，这个功能的目的是什么。可以发现当产品经理提出一个需求的时候你最想问的一般是“你为什么要这个功能，这功能谁会用？那他一般怎么使用？”，当然有时候“你为什么要这个功能？”听起来有点aggressive，但是却是个好问题：）
- 有了上面的用户故事，你们团队就可以开始做估算了。估算一般用计划扑克会比较好。当软件有技术难点时一般时间会估得比较不准，所以我建议尽早将系统难点研究一下，之后动手了才能真正知道有多复杂，说不定很简单呢。人对于自己不了解的东西总是有种恐惧感，估算的时候有时会估出一个“天文数字”。估算不是只做一次，第一次估算只是大概看看人手是否足够，技术点时候没太大risk，而不要太在意准确性。估算可以不断修正的，你了解得更多也会估得越准。
- 需求的利益相关者：这一条虽然放在最后，其实最重要：）请确保参与项目的利益相关者都在同一个理解层面上也就是on the same page。所以前期开会要尽量要求所有利益相关者一同开会，对整个项目有个相同的认识，而且对于项目的范围，目标，时间，质量达成协议，这样才好继续后面的工作。千万不要孤立或遗漏了重要的利益相关人员，或开很多小范围的讨论会议，这样很容易浪费时间，达不成共识，项目注定失败。还有一些重要决定请一定邮件、文档记录，签证画押~~
需求之后的产出物
- 需求定好了之后一般就可以产出一个基本的系统架构设计了--这个出来之后才好开始技术研究或相关编码
- 需求定好了之后一般就可以产出一个Mile Stone和交付计划了-- 这个出来之后才好安排相应的测试和其它资源
项目成功最最最最重要的部分，写在这了
角色定义和授权
- 这个很重要有了角色定义，项目中的角色就有了责任将这个角色扮演好，其它人有问题也可以找到相应的人员，也消除了一部分人不管自己的事情，老去盯着别人
- 授权也很重要，各个角色有什么权利，管哪些方面定义好了，就不会有模糊领域大家都不管，或者资源不听使唤
需求文档 -- 描述了做什么，什么不做，做的假设是什么
用户故事描述需求--可以捕捉，这个功能是谁要的，为什么要这个功能
软件架构设计--架构设计怎么来满足需求中的非功能性需求和功能性需求
估算--用来给项目计划提供支撑和合理安排资源
项目计划--给管理层一个时间节点和期望，相应的时间节点做资源安排等
后面找时间写后面几篇：
--全新的软件项目，好的开始决定了成功一半！（架构设计）
--全新的软件项目，好的开始决定了成功一半！（团队）
最后给大家show一下我在瑞士买的本子，我喜欢用思维导图捕捉思想，在瑞士偶遇了这个本子，大小纸张都很合适：）
