产品需求分解通论

一个产品人员假设完全不懂技术！！当面对一个空无即没有需求状态下，就会开始去找需求。找到一个单一需求后交个技术完成。这个过程很单纯没有什么好讨论的。就好比说：喂哪有个狗窝这有几个木板，我画个图，技术把它做出来。

当他有了狗窝之后开始考虑这里能不能住人？能不能大一些？能不能安个烟囱？弄个厨房？有几个卧室？要不要院子？也许还要有客人房？或许做酒店也不错？改成写字楼吧？

也许会有几个这么幸运的软件能够熬到酒店，当产品拿了一个写字楼的图片给技术的时候。是不是应该考虑技术是先盖屋顶还是先打地基？是先装修大门还是安装玻璃？是走楼梯还是走电梯？

在如此复杂的功能面前？如果产品说我只要简单的一个大楼，我真想一巴掌把他打出去？连楼和狗窝，大门和狗门都分不清楚地产品只能设计狗窝！先打地基和先盖屋顶都分不清的设计往往会从先最简单的安装大楼玻璃开始！

好吧如果软件太复杂没有摩天大楼来的直观，你可以想象先装玻璃的大楼是什么样子？

说软件工程师不了解用户需求非要一个对软件完全无知的产品来教他如何设计软件展示软件？多么滑稽有趣的场面？

既然是通论就说几个显而易见却被忽视的问题？

人们往往开始注意的是需求的难的部分而不是全部！

人们往往只注意自己能看得到的部分而不是全部！

人们往往只关注自己懂的部分而不是全部！

所以基于以上3条人之常性，产品或半调子技术设计出来的软件可以通称呼为怪物！

因为软件的大部分是不可见，软件的大部分是不好懂的，软件的制作是有前后次序的

所以基于随机需求产生的软件也基本上是奇形怪状的拼装品。

软件的一个困境是不能提供一个直观正常的图纸，

和盖房子相比软件工程的基础太脆弱没有一个可以模式化的工作流程。

几乎所有的工程都不能100%的通用。没了基础的软件工程研发成分比例太大不能很好的

预测和规划项目整体。