对需求的误解
同学们经常提及的需求变更，其实变更的并不是需求，而是需求的实现方案。
首先，我们要对需求和方案进行区分。
需求包括以下几个方面，需求背景，需求目的，需求范围，需求的详细规格，以及错误处理方式。
UI/UE/UX，前端，后端，共同实现了需求，是同一个解决方案的不同侧面。
因此从广义上来讲，开发者之间的内部沟通，不属于需求变更范畴。
软件的大部分问题，存在于开发者之间的沟通上面，而不是开发者对需求的理解上面。
只有理解了什么是需求，才能衡量出需求是否变更了。
在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。
从方法到目的
实现一个目的有多种方法，如何看到这些方法的共性呢？
最快的方式就是找到这些方法要解决的问题。
软件是以解决问题为目的的，不能解决问题的软件没有任何作用。
这要分两方面来说，
其一，当产品经理发起需求变更时，我们要积极配合。因为，需求变更的主要原因在于当前软件不能解决某些问题。
不配合，那么做出的软件就没有用，我们的工作就没有价值。
其二，我们要知道当前软件要解决的问题是什么，才能灵活的改变策略。
甚至可以利用工程师的领域特长，找到更合适的解决方案。
变更与管控
我们不怕变化，怕的是对变化失去控制。
当产品经理发起需求变更时，我们要重新安排未完成任务的优先级，这是需要与产品经理沟通的。
因为，变更是需要成本的，意味着原计划要做的某些事情不能做完了，我们得让他们知道。
我们自己首先得有一个任务列表。
然后以优先级的方式管理待办事项。
知识共享
不同的人，对需求的理解不同。
每个人都会按照自己的方式去实现想法。
如何设计一个策略，怎样实现这个设计，大相径庭。
因此，我们要预先做一些知识的分享。
在设计阶段排除问题，会比在实现阶段排除问题，成本低很多。
我们不妨谈一谈，我计划怎样解决这个问题，我打算怎样实现。
因为，很有可能，这个计划就是错的。
主动去沟通
如果我想改某个文件，担心其他人也在改，以后合并起来麻烦，怎么办？
去问他/她。
某位同学的代码我看不懂，不敢改怎么办？
去问他/她。
产品经理对需求的描述不清楚，我理解不了怎么办？
去问他/她。
交互稿中文案可能有错误，逻辑矛盾，怎么办？
去问他/她。
测试提了一个缺陷，可是我不知道在说什么，也不知道在哪个场景中会出现，怎么办？
去问他/她。
"问"，这个简单的动作，会节省大量的时间。
如果不想打断别人的工作，可以用一些非即时沟通工具。
或者走到他旁边，让他注意到你时，你再发问。
提问，并不愚蠢，不问才蠢。
要相信大部分工程师都是喜欢被问的。
让设计灵活响应变更
好的设计，在变更中灵活响应。
这实际上是对设计提出了更高的要求，不止是实现功能那么简单了。
因为现实世界是发展中的，业务场景也在与时俱进。
因此，需求本身不可能是不变的。
软件是一个解决动态问题的方案。
程序设计是用来解决发展中问题的。
我们要看到问题的发展趋势，结合整个过程进行设计。
给未来留下余地，不局限于当前状态进行设计。
需求你怎么改都行，因为你不得不改，我也不得不照做，不然软件本身就没用了。
但是我的设计保障我修改的成本最低。
原谅别人的失误
人非圣贤孰能无过。
我们会因为手误打错代码，也会因为大脑一时短路犯逻辑错误。
那么，产品经理同样也会对需求理解和描述产生偏差。
我们不能要求别人做到完美。
一方面，我们要原谅他们，但要让他们知道大家的代价。
另一方面，我们要听思想，不要听描述。抓住中心思想，忽略细节。
严于律己，宽以待人。
结语
大部分软件从业者，没有软件工程相关的培训，也没有阅读过相关书籍，
是依靠自己的感觉来做软件的。
结果会沿用一些不恰当的类比来理解软件，
也会逐渐形成小作坊式的软件开发过程。
当团队规模扩大时，问题就会越来越严重。
不过，没关系，这有什么。
痛了才会想办法去解决，也无需过度设计。
只是现在我们是否该学一些软件工程的知识了呢？
参考：