项目开发的第一步:谈谈产品设计和需求文档

2021年3月8日16:38:38 发表评论 1,218 次浏览

本文概述

前言

我必须坦诚——我不是产品经理或负责产品设计的,我只是一个苦命的程序员。所以我为什么要关心产品设计呢?需求和开发文档有什么用?老实说,我觉得这东西没什么用——在从前,写了不少代码后,才发现这么简单的东西是非常有用的。而且我以前也学过原型设计和UI设计,也是不知道为何用这些浪费时间的东西,但是最近也慢慢开始理解了。

假如现在要开发一个项目,“想要开发X”这仅仅还是一个IDEA——首先,你可以马上创建项目进行开发,没有对这个IDEA有任何描述,只是可能在脑子里想了想,或者听过被人说过一点点,可能你会做一些文字记录吧!

这样是没问题的,没人阻挡你写代码——但是从何写起?直接创建类实现还是使用TDD?界面如何实现?桌面端、Web端移动端?没事,没人阻挡你写代码,也没人说你没学过编程或UI设计,没人说你算法写得不好,没人说你不帅……

——但是这样做的后果90%左右都是悲剧收场,一种可能是你写不下去了,为什么?(这我就遇过),因为中途可能失去了方向,我会做,但是我要做什么呢?另一种可能是完成项目了,但是非常差(我也经常有)——比较多,项目还是可以用的,但是做得看着非常勉强,不标准。

后来我有开始使用文字先记录要实现的需求,写代码的时候就根据这些需求逐一实现,奇怪!这非常奇怪!这在告诉你,你的任务就这些,做完项目就算完成了。再后来我学会开启项目前先详细设计一下,包括界面布局、代码实现方式。

到目前,我决定使用一般流行的方式——相对标准的需求文档,依据需求文档来开发,依据一个详细的需求文档,就是开发的全部任务了,想那么多没用。

本文讨论需求或开发文档带有我作为程序员的角度,一来也是为了令自己能更好独立开发,二来也想分享一下我的想法给大家,有不标准的地方莫见怪。

产品设计的第一个问题

需求文档还是开发文档?需求文档还是原型图?需求文档还是手绘图或交互原型图?……你是否有听过类似的争论?总有人开始指责别人不知道何为产品设计,指责别人不知道什么是需求文档,另外还有关于交互、体验和原型设计争论。

我认为,这没什么好争论的,若是岗位不清晰,那只是:小公司没钱,产品经理可能什么都做(甚至编码),大公司有钱,可能岗位区分更清晰。但并不是说大公司就是标准,而是只让几个人仅仅做体验或原型那样更专注,效果可能更好,但是成本大呢!

维特根斯坦说:能用就够了!你可以详细分类,但是总是在概念上争执不下并不能解决实际问题呢!实际上这些争论的概念都是在产品设计的范畴内。

这个问题也只是顺带提一下,概念很难做本质上的区分的(哲学的说,你无法得到任何概念本质上的定义),达到我们交流的目的,达到实用的目的就够了。

产品需求文档要多详细?

你是否问过这个问题?需求文档及其每部分要描述到多详细?记住:无论是交互动态式、静态式、文字、图片、语音、视频描述,都不会有一个最本质的描述,一个好的描述就是它刚刚好能提供下一步的实现。

什么意思呢?例如你在做产品概念化分析的时候,描述刚好能提供给下一步定义需求文档即可;而界面交互原型图,其描述刚好能提供给程序员实现即可,也就是说,这个描述不是那么泛的,开发人员刚好能理解并且能实现即可。

但是你看概念化分析、简要需求文档和原型图描述其详细程度是不一样的,都是相对而言,我们不需要每一步都要绝对详细,但是也不能随便描述。

下面介绍产品设计文档的全部内容,你可以把它当做一个模板看待,但是我建议是你理解了,而不必总是记住模板。

IDEA:产品概念化

产品从哪里来的?无中生有还是像有的天才那样突然想到的?第一个IDEA从哪里来?什么灵感?要灵感吗?你是否有和别人讨论过开发什么?“如果你能开发一个X,可以Y的就好了”,比如我一个同学就和我说过:“可以开发一个可以识别花的软件吗?”。

本人学过一些哲学,必须说,首先有产品的第一个IDEA——这个还真有点偏向自由意志。因为这个IDEA是从何而来的——这是无法形式化的,无法形成一个有效模式,使得你按照这个模式就有新的IDEA了。你得佩服有的人真的是天才,突然有个绝妙的IDEA、并付诸实现的人真的是极少极少。

哲学里经验论有一个著名的英国哲学家:休谟(Hume),看过他是如何解释想象力的:你可能经常玩微信,即使你不会开发软件,你也能描述得出微信软件的颜色、形状、布局、运行流程等等(经验印象,impressions),但是你第一个颜色的经验多数都不是来自微信,而是你出生的时候看到的。你或许可以详细描述红色,可以区分得了粉红和深红(impressions)。所以不要担心,你即使不玩微信抖音,也并不会真的比别人落后,你只是不习惯而已。

但是休谟的经验论并不能解释第一个IDEA首先从哪里来的,他的意思是说:你目前实现得到的实物(软件或硬件),都是来自于你的经验(这些impressions的组合)。例如你能想象狮身人面像、能想象一个脚是两个车轮的人,有人可能说我并没有看过狮子怎么办?好吧,但是你有毛发、柔软、眼睛、嘴巴、头……这些经验,所以就算你没看过你也是可以想象得了的。

综上所述,一个产品在最初的时候,它来自一个IDEA,而设计产品就是在概念化这个IDEA、并同时使用经验impressions详细描述这个概念,一个产品就是由所有这些impressions组成的,而它们是如何组合的是自由的。(所以,并没有一个东西叫做X产品,X只是所有这些经验impressions的集合,是不是很哲学?哈哈)

IDEA:产品概念化

什么是IDEA?这个是非常随便、非常自由的,就像上面说的开发“能识别花”的软件就是一个IDEA,你可以随便想——但是这个也不能表明人有自由意志,因为我们能说出这样功能的软件,也是因为之前有过相同或类似的经验了,请不要忘记:没有人有绝对100%的新IDEA使得他绝对与众不同,如果你发现你的IDEA已经有人做过了也不要紧,尽管采用;如果你认为你的IDEA是绝对100%不同的,你可能不是脑子长草了。

什么是impression?比如红色、淡红就是,当然这个太仔细了(这可以在原型设计中体现出来)。再比如,我们要实现识别花的软件,你可以立即想到——如果是移动端的,你就知道要有界面了(你有过关于界面的经验);另外识别花可以使用摄像头或上传本地图片(你有过这些使用图片的经验);如果你是个资深码农,或许你会想到这个功能需要使用机器学习;既然可以识别花,为什么我不添加多几个功能呢?再令它可以识别小狗和蟑螂吧,识别蟑螂是不是很刺激!

另外还需要服务端吧……想想就头大,如果你认为自己很牛逼,想到就马上实现——那肯定很辛苦,因为你只是大概想了一下(我以前就经常这样的痛苦)。

举个综合的例子,入门开发比如我就有一个开发聊天软件的美梦,然后开始着手设计这个软件,例如聊天窗口你会如何设计呢?90%概率你都是采用左右的方式显示吧?(多数经验都是这种形式)展示好友列表你会如何设计?八成都是类似微信或QQ的方式,因为你的关于好友列表的印象多数都是来自QQ或微信的。

——所以,抄袭并不可耻!抄袭不可耻!所谓X不抄袭或不够创新,一个可能是:在软件里X的形式不常见、X形式常见但很少,而抄袭就是常见的成分太多了——但是都来自经验,哲学的来说,它们并没有什么区别,都没有100%创新。

但这不是不设计的理由,想到什么就设计得了,大家不要老追究或纠结那种100%的问题,试想下,大家学编程的算法若都来自《算法导论》,那么大家写算法的时候算不算抄袭了呢?大家都用JDK呢,是不是都是在抄袭?

另外,主要是要注意:就算你想借鉴别人的设计,你也不要完整copy别人的形式,做一个和别人一模一样的东西——这就说不过去了,我们应该盗取别人的IDEA,而不是别人的产品。

由上面的讨论,你可以看到:想象力决定了你的创新程度,想象力是用来将impressions组装成一个概念产品的。

为什么我会这么详细讨论产品概念化这部分呢?因为这部分太重要了,产品设计没有编码那么实际,如果本人不理解,产品设计看起来就是很虚幻的。这里找到了一个可catch IDEA的方式,概念化产品就是运用想象力用经验impressions组装它,产品需求文档就是在做件事。

产品概念化分析

有一个IDEA,有了一些关于这个IDEA的概念,总不能只是详细吧?——一定要记下来,你可以使用在笔记本上、使用一些自由的画图工具,想到什么就记录下来或画出来,任意你想表现的形式。

本人觉得这部分没有标准的形式,但是有几个可参考的:

  • 因为一个IDEA可能只是一个功能,所以很有必要再增加几个功能,或其它额外的功能,让软件不那么单一。
  • 尽量使用你的想象力把它描述出来,虽然还没到实现阶段,但是也要尽量具体,描述的太泛——你可能不知道自己在想什么。
  • 尽量描述全面,软件可能包括命令行界面、GUI界面、运行环境、服务器、客服端。

本人习惯使用windows自带的画图工具描述,你也可以使用思维导图,或者一些更为自由的画图软件。描述大概全面了就可以导出PNG图片到Axure中(你也可以使用Axure,但是个人觉得不方便),因为我的建议是把整个概念化和原型设计等等一些东西全部放到Axure中,这样就不用那么多工具切换来切换去了。

概念化产品描述不需要详细到实现上,最好是有经验的设计师吧:你能想到这个描述它在前端或后端是可以实现的,就够了。

产品简介

这部分主要是描述该产品的主要功能、市场价值、简要用法、主要特色等等,非重要信息,简要说明即可,主要是让看文档的人知道这个项目是做什么的。

需求文档版本

版本说明是描述文档每个时期的改动情况,但是你如何区分每个版本的区别呢?有人说我用红色字体标记清楚,拜托!别天真了!项目文档随着更新内容会越来越乱,或增加或删除,给你100种颜色的字体好不好,就算你标记了,你也区分不了,请不要使用说明字体标记的方法了!

如果你真的需要版本管理,请使用Git,GIT!或SVN也行,这才是正道!而且我推荐使用Git,也很有必要使用。

简要需求文档

由上面概念化产品的分析,我们可以得到一个草图(就是什么内容都可能有的图),这个草图包含了我们实现这个产品需要的主要东西,现在我们需要整理这个草图,尝试使用文字把这个软件的大体需求详细描述下来。

所以,你看产品概念化后输出一个草图,而输入这个草图,我们可以整理出更为精致详细的需求描述,输出则是一份简要的需求文档。

这里可以使用excel或使用Axure的表格简要把主要需求列出来,要注意这里还不是详细的需求,如果你使用Axure做了原型图,那么之后已经不需要再做详细的需求文档了。

表格至少包括两项:需求名称和需求描述,使用命令式的简洁描述即可,也不是营销,这是给开发人员和产品设计人员看的,所以不要写那么多余的描述。

要注意的是:有人设计人员可能没有这个部分的,这对于我来说很有必要,不管如何,整个产品文档的主要目的是详细描述产品的概念,以让它实现出来,你可以使用其它你喜欢的方式,能达到这个目的就可以了。

如果需求很多,尽量从简,因为这个只是大纲,详细的工作在交互原型图中做。

考虑需求时,可主要从设计角度和使用角度考虑。

产品结构图

为什么突然要做产品结构图了?我也不知道呢,我也是借鉴别人的。觉得也算有点必要,它的作用是能在逻辑上纵观整个项目,它是做原型设计和编码设计的前奏或准备。

如果不理清一下整体结构就开始设计,可能会有些乱,结构图的作用就提现出来了。结构图包括两部分:数据结构图和界面结构图。

程序的主要功能就是处理数据,不管是什么软件,不是处理数据的话,请问它还有存在的必要吗?只是可能数据不仅只是数字和字符串。

我们主要是参考概念化后的草图和简要需求文档,然后提取整个程序需要的所有数据,数据的表现推荐使用思维导图的形式,简洁清晰,做完导出到Axure即可。数据结构图除了提供给交互原型设计,主要提供给编码设计。

另一个是界面结构图,为什么是界面结构图呢?因为对于用户来说,这个软件的界面就是用户对它的全部印象了(包括命令行界面),界面是这个命令行的外界表征。这部分同样推荐使用思维导图制作。

记住:做每一步的描述,都要回头看看,有没有满足上一步或之前的需求。比如做数据结构图,对照简要需求文档,看看这些数据是否足够实现项目了;做页面结构图,看看这些页面是否符合所有这些需求了。

界面交互原型图

交互原型图是产品文档最主要的内容,通常交互原型图是对项目需要的每个界面逐个设计,其界面是完整的界面。除了设计实现的产品实际效果外,一般使用软件如Axure制作的的原型图还需要带有标签注解说明,标签的主要作用就是解释界面元素的作用和操作,充当详细的需求文档说明。

如果你不打算在这里添加标签注解,那么下一步你就要详细书写需求文档了,所以还是建议使用标签,Axure的Default元件库中有标记元素。你还可以利用Axure,给界面的每个需求详细用数字标记,这样开发人员看文档时一目了然。

产品用例图

有些产品设计是不做用例图的,有的则做,有人说对开发人员的帮助不大。我建议还是做一下主要的用例,制作用例图一般是使用excel或Axure中的表格,它和需求文档类似,或者使用图片的形式。

用例文档主要是从使用者的角度详细描述软件的使用情况,一般包括用例名称、执行步骤和预期结果。我建议是做软件整体最主要的用例就行了,写太详细的用例作用不大(除非提供给测试)。因为我觉得用例的最主要作用的供程序员开发或测试的,比如方便TDD开发,所以如果产品设计人员不懂编码,那么用例文档可能用处不大。

整体功能流程图

功能流程图也是一个逻辑图,它和结构图是类似的。功能流程图帮助我们理清该项目整体的所有执行路径。当然,可能你不需要做的详细到代码上去,只需在逻辑上是比较详细即可。

这个流程图可以让开发者找到回家的方向,以前有时我会感觉自己深陷在一个页面的一个功能上,久久不能自拔,看下流程图,看看你做到哪里了。而且流程图还给出这个程序的主要执行路径。

编码设计

这部分一般产品文档可能是没有的,编码设计可能交给架构设计师了。我个人则需要这部分,毕竟我是个程序员,编码设计主要就是根据数据结构图和交互原型设计接口了,设计接口主要参考TDD和数据结构与算法。

总结

本文讨论项目开发的产品设计和需求文档,主要是概念化产品这部分比较详细,其它没有示例,真是不好意思,我现在也是在做一个产品文档,具体内容就不方便展示了,但是可以展示页面结构,如下:

需求文档模板结构

虽然其它部分没有提供截图,但是我觉得主要是明白概念化产品就可以了,我们就是在把这个产品的概念详细清晰的描述和展现出来,而其中的相关步骤只是把它细化了。

而且,我认为产品设计最重要就是概念化产品了,它不是虚幻的,并非胡思乱想,它是把一个简单的IDEA从想像到描述、到原型模拟,并最终实现的过程,概念化产品就是把我们的想象力变成现实。

OK,终于写完了,牙肉好痛,天哪!!!!!

木子山

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: