软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6743 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

18 | 原型设计:如何用最小的代价完成产品特性?

宝玉 2019-04-06
你好,我是宝玉,我今天想与你分享的主题是“原型设计”。
我们都知道,软件项目中很多问题都和需求相关,比如说需求不明确,需求变更。这些问题轻则导致返工造成浪费,重则导致项目失败带来巨大损失。所以在软件工程中,搞明白需求是一件至关重要的事。
上一篇我带你学习了如何分析需求的方法,而分析需求,同样也离不开工具的支持。所以这一篇,我将带你学习需求分析中原型设计的用法,借助原型设计,用最小的代价完成产品特性。

什么是原型设计?

对于原型设计,很多程序员可能比较陌生,但是对于产品经理来说,原型设计却是日常工作中最常用的技能之一。因为原型设计,是产品经理确认需求、设计产品最重要的沟通工具。
其实最早的原型设计,并不是作为一个需求沟通工具存在的。

原型设计的发展历史

早在上世纪 70 年代,在瀑布模型提出后,很大程度上改进了软件项目的开发。但是需求不明确、需求多变的问题从那时候开始就是一大难题。
《人月神话》的作者弗雷德里克·布鲁克斯(Frederick P. Brooks, Jr.)在《没有银弹 - 软件工程中的根本和次要问题》中第一次提出了:“在获取和制订软件需求时,将快速原型开发作为迭代计划的一部分”。
后来快速原型就逐步发展成为一个开发模型,叫快速原型模型,我在《04 | 瀑布模型之外,还有哪些开发模型?》这一篇里也有介绍。这种模型的特点就是快速开发,快速修改。目的是为了解决客户的需求不明确和需求多变的问题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(12)

  • hua168
    老师,问一个很low的问题,
    1.什么是模块呀?😢
    经常看到书中或开发说,自己感觉懂好像又不懂😂,
    一个类也是模块,但不懂为什么就是模块😓
    2.模块有哪些分类?一般说的模块是业务模块?
    3.模块间“高内聚低耦合”,像口诀那样,会背,但毫无概念,只知道模块尽量独立,那如果模块之间要进行通讯是不是用接口实现?如果有依赖关系越多的话的话那不是独立性越差?要实现“高内聚低耦合”,如果复杂一点的项目有难度吧?

    作者回复: 你说的这个话题其实属于架构下面的。

    在技术里面,模块其实是对某一种类型需求的抽象。举个例子来说,一个博客系统,博客的帖子是一个模块,评论是一个模块,用户是一个模块,帖子和评论又可以进一步抽象成内容模块。

    模块的分类看你是从架构层面看还是从业务层面看。比如说从架构层面看,一个普通的博客网站可以看成三层:UI层、业务逻辑层和数据访问层。其中UI层包含帖子列表模块和博客文章阅读模块;业务逻辑层则是帖子业务模块、用户业务模块。

    如果从业务层面看,包含博客阅读模块和后台模块,更偏向功能的分类。

    高内聚低耦合是架构里面的概念。因为架构设计,需要把大的系统拆分成小的模块,拆分后,还要通过约定的协议通信。典型的有前后端分离然后通过REST API通信,还有像类库之间直接通过公开的方法调用。

    低耦合意思是项目没有什么依赖,改动互相不受影响。比如说前端和后端之间通过API通信,只要API不变,无论你后端用什么语言,跟前端都没关系。

    高内聚指的是一个模块都是关系很紧密的代码,比如用户模块,所有用户操作的功能都在用户模块里面,关系紧密,也不需要依赖于其他模块。

    2019-04-08
    5
  • kirogiyi
    宝玉老师,文章太有用了,感谢! 每一期的专栏,要么能加深自己对某一方面的认识,要么能补充自己某一方面的新知识。

    一直以来,潜意识里产品设计都是产品部门的活儿,我一研发部门的怎么能插得上手,手太长也不太好看。在产品没有明确设计完成、设计周期比较长的时候,等待是惬意的(不忙,不加班),也是焦虑的(暴风雨在后头),只能干瞪眼。

    原型设计我也曾经玩过,不过玩得太浅,没玩到精髓,草草开始,草草结束,不太重视。今天看到宝玉老师对原型设计的讲解,补充了我所不了解的原型设计的优势:最小代价、最快速度,如果能保证高质量当然也是乐见其成的。

    另外,我想请教宝玉老师,在敏捷开发中产品部门怎样参与产品设计会更好,或者以什么方式参与会更好?

    作者回复: 首先你问的是产品部门参与产品设计,还是开发部门?

    首先从技术角度,好的产品设计要让产品设计在技术上实现不要成本太高,所以在一些技术难度高的设计上两边要多沟通确认,共同制定出技术难度适中,又满足好产品需求的设计。

    然后从产品角度,开发必须充分理解产品设计才能设计出符合产品需求的架构,才能开发出满足需求和好的用户体验的产品。所以开发需要多和产品设计反复沟通需求,然后将确认后结果体现在文档上。

    至于参与方式,主要还是看什么形式比较好。

    比如可以安排需求评审,关键节点让主要开发人员参与确认技术可行性和成本以及建议。

    比如有分批次的需求讲解会议想开发讲解产品设计,回答理解不清楚的问题。

    每个Sprint产品经理都要参与其中,及时和开发沟通确认需求不明确的问题!

    2019-04-08
    2
  • javaadu
    写代码这么多年,最欠缺的就是自己从零到一完成一个项目的经验。现在发现如果让这种情况持续下去会影响自己将来的发展前景。

    最近遇到一个问题:业务方的接入效率不高,我们组一直需要提供一个开发去支持,人效态太低。为了解决这个问题,我准备出一套自助接入系统,想了下主要的步骤:业务问题分析,对于接入来说就是总结固定的接入;出解决方案(这里需要自己去画原型);项目排期和需要的资源估计。

    如果可以解决这个问题,相信可以锻炼自己身体整体素质。

    作者回复: 这种和业务接口的事很锻炼人的,能帮助开发人员换位思考,多了解业务需求、使用场景。

    一开始不着急出接入系统,可以先人工做一段,然后在总结归纳,把能自动化的部分逐步用自动化解决。

    另外这类事情,一定要配合Ticket跟踪系统,所有提的需求、反馈的bug,都应该基于Ticket跟踪起来。

    2019-04-06
    2
  • 打工皇帝
    老师,我遇到一个变态领导,经常原型啥的确认了,视觉稿也确认了,开发出来后,他自己电脑看哪里不舒服又改,看到别人家哪里好看又要求改,需求一直变更,这种鸟不拉屎的人怎么处理,实在无奈。

    作者回复:
    视觉这种东西主观性太强,每个人都觉得懂一点,所以一般领导都喜欢发表意见。所以遇到喜欢发表意见的领导,不妨让领导有机会参与设计,对设计稿多确认,从粗到细,先确认大风格,再确认配色风格,再到局部细节。这样最后提出设计修改的可能要小一点。

    但要注意在确认的方法上,多让领导做选择题,而不是问答题。因为当你问的开放式的问题,那么你就可能得到不确定的答案,但是如果是在几种方案之间的选择,那么对于结果会更容易可控一些。比如说,你问领导:“这套设计方案怎么样?”他可能会提出一些不太可控的意见。如果你准备两三套设计方案,问领导:“你觉得这几套方案哪一套更好”,那么可能问题就集中在选择哪一套设计方案上。


    对于需求变更的问题可以参考 《20 | 如何应对让人头疼的需求变更问题?》里面的描述,核心是是要让领导意识到变更带来的成本,以及想办法提升领导变更的成本。

    当然如果你确定不是你自己的问题,确实是领导的问题,也无法改善,你也可以考虑换一个项目组换一个部门甚至换一个公司。

    2019-10-16
    1
  • tcny
    流程图是不是可以用原型设计工具代替,比如可以在墨刀里实现页面跳转功能。不过墨刀没有版本管理,不知道是不是必要的。我感觉很难说服其他人去画流程图。

    作者回复: 流程图是辅助的,可以被原型设计代替,但是有了会更清晰。

    这就像你的代码,看代码也能看懂 ,有个模块关系图,别人看会清晰很多

    2019-06-21
    1
  • tcny
    老师,在“产品信息结构图”那一块,您说极客时间App的“专栏”、“视频课程”、“每日一课”和“微课”点进去都是一样的,是指结构一样吗?在实现的时候,其实是划分到统一的“课程模块”,“专栏”、“视频课程”等是作为一个分类存在的,在数据库中就是一个字段。我从研发的角度是这样想,产品经理也要考虑这些吗?

    作者回复: 产品经理也会考虑信息架构,但是和开发的纬度不一样,开发是站在用户使用功能的角度,做信息架构时需要考虑哪些功能是不同模块共用的。而开发是站在实现的角度,看怎么实现可以重用代码。

    只是有时候正好两个不同维度的结果可能是重叠的。

    2019-06-21
    1
  • williamcai
    开发人员接到需求后,先设计低保真产品原型可以加深业务的理解,这个是很有必要的,产品站的角度要要比开发高。

    作者回复: 我觉得对于开发人员来说,设计原型是帮助理解需求的手段,并不是必要手段。只要能理解清楚需求,通过和产品经理多沟通,达到理解需求的目的即可。

    但对于产品经理来说,产品原型是很有必要的,因为这是最简单有效的确认需求的方式,最简单有效的让其他人理解产品设计的方式。

    2019-04-13
    1
  • alva_xu
    我的理解,实际上原型设计是一个完整的工作环,所以是遵循PDCA过程的。采用Axure Pro进行原型设计,据说可以在正式进行产品开发的时候可以重用代码。
    我的一个问题是,在目前前后端分离、Restful 风格的应用架构下,是否更容易实现原型设计时的代码的重用率,以提高开发速度?具体是怎么做的?

    作者回复: 以前在讨论开发模型的时候有介绍,快速原型开发模型有两种模式,一种是抛弃型的,就是用工具开发的这种;一种是演化型原型,就是类似于MVP,先做简单核心功能,然后不断演化,变成最终产品。

    如果你要提升代码的重复率和开发速度,这种前后端分离的呀,我给你的建议是你用一些第三方API云服务:
    https://www.apollographql.com/
    https://firebase.google.com/products/firestore/

    这样你就完全不用考虑后端开发了,直接用它们定制就好了。等到产品开发出来,你再考虑后端迁移。

    2019-04-10
    1
  • hua168
    老师,能否问一下:
    1. 什么是模块?
    2. 有多少分类呀?
    3. 要实现“高内聚低耦合”,模块之间的通讯要注意哪些?

    作者回复: 已经在另一篇留言回复

    2019-04-09
    1
  • dancer
    mark,做原型设计的三个步骤,静态页面,基本交互,完整功能
    2019-04-07
    1
  • 八哥
    用代码实现感觉更像POC。最开始原型还可以手绘,拍照。然后再用墨刀类工具画。
    2019-04-07
    1
  • 一路向北
    原型设计也是属于磨刀不误砍柴工。
    记得早期我们团队做第一个项目的时候,一个同事用这个原型设计的方式做了一个原型,和客户沟通后,稍作修改就成了最终做出的样子,大大提高了效率。客户也很容易就能够想象出产品最终的样子,甚至还能时不时的提一些建议。

    作者回复: 👍是的,原型设计对于产品设计阶段的作用蛮重要的。

    2019-04-10
收起评论
12
返回
顶部