产品的设计

    因为我不是专业的产品设计人员，不太清楚如何专业的去收集需求，设计产品。这篇文章就从项目管理的角度去看一下产品的设计。作为管理者不可能所有的技能都掌握，最好的管理方式应该是让专业的人做专业事，但管理者要有能力去鉴别团队成员产出质量的高低。

      这里的第一个问题就是，什么样的设计才是一个高质量的产品设计。答案应该是细节够丰富、逻辑够缜密。其他的比如易用、好用这些就比较扯淡了，什么才算易用什么才算好用，根本就没有一个统一的量化指标去衡量。那么怎么算是细节够丰富，用什么形式才能把这些细节更好的呈现出来，怎么让团队的每个人都理解这些细节等等一系列的问题都出来了，逻辑够缜密也是一样。

    按我的标准来看，只要能把能把系统有那些角色在使用，每个角色用系统完成那些功能，为了满足这些功能系统需要分成那些模块，每个模块有那些页面，每个页面都长什么样，由那些控件的组成，每个控件相关的数据从哪里来，到哪里去，有什么限制。能把这些说明白，就算是细节丰富、逻辑缜密了。也能够拿来用来指导开发和测试了。

    为了能把上面这些说明白需要三种文档配合使用才行。

    a:需求文档：说明系统有那些角色再用，每个角色用这个系统完成什么业务，为了满足这些业务需求系统共分为多少个模块，每个模块的业务流程是什么样的，需要依赖那些其他模块，为了完成模块的流程又需要那些页面，每个页面用来做什么。这个文档需要产品经理来输出。

    b:原型：细化需求文档里提到的页面，说明每个页面的布局，由那些控件组成。这个文档也应该由产品经理输出。

    c:原型说明:以原型单个页面（一般包含增删改查功能及其附属页面）为单位详细说明一般以查询条件、列表项（含行操作按钮）、独立按钮及其附属页面为分类项详细说明控件之间的关联关系、字典数据来源含义、操作之后关联数据处理方式等。这个文档最好以会议的形式，由产品经理主导，组织项目经理、开发人员、测试人员及其相关业务人员共同参与，以原型为单位逐个讨论，最好由项目经理先整理一版初稿，由开发人员在初稿的基础上进行整理，这个文档将作为开发和测试的指导文档。会随着开发的进行而不断的更新。

    要保证开发人员能够理解自己负责模块的功能逻辑的前提是项目经理能够全面理解自己负责的产品，无论需求还是技术。由项目经理根据原型整理原型说明初稿可以有效的保证项目经理对需求的全面理解，同时经过整理也可以对项目中大致的技术难点有初步的了解和设计。而开发人员和测试人员参与自己负责模块的讨论并且负责会议时整理记录初稿也可以增加开发、测试人员对需求的了解程度。

    这个文档除了用来指导开发外，也会被用来指导测试用例的编写。