需求设计：构建用户想要和需要的产品 pdf epub mobi txt 电子书 下载 2025

简体网页||繁体网页

☆☆☆☆☆

[英] 克里斯·布里顿 著，爱飞翔 译

图书标签:

• 需求分析
• 产品设计
• 用户体验
• 用户研究
• 软件工程
• 敏捷开发
• 产品管理
• 设计思维
• 需求工程
• 可用性工程

出版社： 机械工业出版社

ISBN：9787111564720

版次：1

商品编码：12077213

品牌：机工出版

包装：平装

丛书名： 计算机科学丛书

开本：16开

出版时间：2017-05-01

用纸：胶版纸

页数：253

内容简介

本书由IT专家亲笔撰写，详细讲解了情境驱动设计。全书共三部分，13章。第壹部分（第1-4章）引出了情境驱动设计及设计的体系，以及这种设计方式与现有的设计方法的异同；第二部分（第5-11章）详细讲解了应用程序的设计，如何设计需求，如何确保应用程序与其他程序及数据库协同动作，用户界面的设计与易用性，数据库设计，以及技术设计的原则与结构；第三部分（第12-13章）是本书的收尾部分，其中第12章讲解了程序设计中的安全问题，第13章总结了前面各章的重点，并展望了应用程序开发的趋势。

目录

Designing the Requirements: Building Applications that the User Wants and Needs
出版者的话
译者序
前言
第1章　情境驱动设计入门1
1.1　对需求进行设计1
1.2　什么是设计7
1.2.1　专项的设计9
1.2.2　有计划的设计10
1.2.3　工程化的设计11
1.2.4　设计方法小结13
1.3　像工程学那样来开发IT应用程序14
1.4　重视IT架构14
1.5　小结15
第2章　设计体系16
2.1　为什么应该建立设计体系16
2.2　情境设计19
2.2.1　任务19
2.2.2　用户组21
2.2.3　数据表21
2.2.4　任务之间的消息21
2.2.5　任务之间的依赖关系22
2.2.6　把所有元素统合起来23
2.2.7　对情境设计做分析24
2.3　集成设计25
2.4　技术设计29
2.5　用户界面设计31
2.6　数据库设计32
2.7　实现33
2.8　这样做真的是工程化的设计吗34
2.9　小结37
第3章　复用现有的方法及做法38
3.1　敏捷38
3.1.1　个体与交互胜过流程与工具39
3.1.2　可行的软件胜过繁杂的文档40
3.1.3　客户协作胜过合同谈判41
3.1.4　响应变化胜过遵循计划42
3.1.5　小结43
3.2　逆向设计43
3.3　用例45
3.3.1　原子性45
3.3.2　设计层次不明确46
3.3.3　用例本身比较模糊47
3.3.4　大型的用例文档难以理解48
3.3.5　用例对工程化的设计起不到帮助作用48
3.3.6　小结49
3.4　成本估算问题49
3.5　BDUF为什么如此笨重52
3.6　迭代53
3.7　品质54
3.8　测试与检验55
3.9　把现有的做法运用到情境驱动设计之中56
3.10　学习型的组织57
3.11　小结58
第4章　大型应用程序所面临的问题60
4.1　应用程序的大小体现在多个维度上61
4.2　大型项目所面临的问题63
4.2.1　需求问题64
4.2.2　缺乏终端用户的支持65
4.2.3　技术设计有问题67
4.2.4　采购与外包69
4.3　能够避免大型的项目吗72
4.4　小结75
第5章　应用程序与业务的关系76
5.1　理解业务流程76
5.2　不能表示为流程的应该怎么办80
5.2.1　业务服务81
5.2.2　资源管理81
5.2.3　评审与监测82
5.3　用更广阔的视角来观察83
5.4　将商业策略运用到应用程序的开发中85
5.4.1　开发速度85
5.4.2　在成本、性能、可用性之间权衡86
5.4.3　试验性的商业计划86
5.4.4　利益要等多久才能变现86
5.4.5　安全需求86
5.4.6　针对现有的企业文化来做设计86
5.4.7　为公司所追求的文化气氛而做设计87
5.4.8　为计划的变更留出余地87
5.4.9　为打造学习型的组织提供支持88
5.4.10　非商务型的应用程序88
5.5　分析88
5.5.1　流程的格式是否正确88
5.5.2　对依赖关系进行分析89
5.5.3　目标分析91
5.6　小结92
第6章　应用程序与用户的关系93
6.1　添加详情93
6.1.1　任务细节94
6.1.2　任务片段97
6.1.3　共同目标组98
6.1.4　数据表98
6.1.5　消息99
6.1.6　非功能型的需求100
6.1.7　使用情境设计的人101
6.2　确定各类用户102
6.2.1　办理业务流程的用户103
6.2.2　对工作进行监控的管理型用户103
6.2.3　使用本程序数据的其他应用程序的用户106
6.2.4　执行数据分析的用户107
6.2.5　执行应用程序管理工作的用户108
6.3　对情境设计进行分析109
6.3.1　流程层面的分析109
6.3.2　任务细节分析110
6.3.3　数据表详情分析111
6.3.4　用户组详情分析112
6.3.5　消息详情分析112
6.4　对情境设计进行评审112
6.5　小结114
第7章　应用程序与其他IT项目的关系115
7.1　集成设计116
7.1.1　应用程序116
7.1.2　服务117
7.1.3　数据库119
7.2　服务接口设计122
7.2.1　定义服务接口123
7.2.2　设计可复用的服务127
7.3　现有的应用程序128
7.3.1　确定现有的应用程序128
7.3.2　替换现有的应用程序130
7.3.3　用现有的应用程序来制作服务133
7.4　回顾设计流程134
7.5　小结135
第8章　用户界面设计与易用性137
8.1　逻辑用户界面138
8.2　把任务描述转化为单击操作141
8.3　易用性145
8.3.1　功能146
8.3.2　信息147
8.3.3　导航147
8.3.4　文本148
8.3.5　帮助148
8.3.6　直观而亲切的应用程序149
8.3.7　针对易用性进行设计150
8.3.8　监测易用性152
8.4　事务与任务完整性152
8.5　用户界面设计与其他细节设计之间的关系155
8.6　小结155
第9章　数据库设计157
9.1　数据库设计157
9.2　数据库设计理论163
9.3　程序员与数据库设计者之间的关系170
9.4　数据访问服务172
9.5　NoSQL173
9.6　小结177
第10章　技术设计的原则178
10.1　单服务器环境下的高性能原则178
10.1.1　缓存179
10.1.2　多线程与多元处理181
10.2　多服务器环境下的高性能原则184
10.2.1　前端并行184
10.2.2　后端并行187
10.3　高弹性原则190
10.4　测试与性能评估的必要性192
10.5　技术设计的流程193
10.6　小结196
第11章　技术设计的结构197
11.1　程序结构197
11.2　什么是框架201
11.3　各种编程语言203
11.4　选择编程语言及框架207
11.4.1　选择与公司的技能组合

前言/序言

　　前言DesigningtheRequirements:BuildingApplicationsthattheUserWantsandNeeds在对IT应用程序开发思考了大约15年之后，我终于写出了这本书。20世纪90年代后期，我开始做IT架构，当时写了一本名叫《ITArchitectureandMiddleware:StrategiesforBuildingLarge,ScalableSystems》的书（那本书的第2版是与PeterBye合写的，于2004年出版，现在还可以买到）。那本书讲的是构建集成应用程序（integratedapplication）所需的技术，以及怎样确保应用程序的可扩展性、高可用性以及安全性。那时还有其他一些人也持有类似想法，由于我们的基本思路是向开发者提供一些可复用的服务，使其能够通过集成技术来迅速拼装应用程序，因此，业界把Peter与我所提出的那种解决方案称为面向服务的架构（ServiceOrientedArchitecture，SOA）。SOA显然有很多优势，但实际上并没有发挥太大作用，因为其中好像缺了点什么。我从一开始就怀疑，缺少的那个东西，应该是应用程序的开发。换句话说，我们没办法很好地回答“怎样开发SOA应用程序”这个问题。此问题也可以表述为：“有人向我提出了一些要求，我该怎样确保最后得到的是一套SOA解决方案，而不是一个单独的应用程序呢？”接下来的几年里，我对于架构问题想得少了一些，而对应用程序的开发问题，则想得比较多。

　　我刚开始编写应用程序，是在20世纪70年代后期。从那以后，我主要是在系统与环境软件的领域中进行bug修复及设计工作，我花了很多时间去修整数据管理软件，偶尔也会修复几个编译器或操作系统的bug。在这个过程中，我对系统软件的设计与编程有所接触。其后，我开始从事数据库和资源库的设计工作（对于版本控制问题，我有很多话要讲，但奇怪的是，没几个人愿意听）。到2000年的时候，我对计算机技术的很多方面都已经有了一些经验，但由于自己并没有直接从事大量的应用程序设计与编程工作，因此我还无法坦然地走到应用程序开发者面前，指出他们的做法是彻底错误的。

　　那时的程序开发专家对架构并没有多少兴趣，而是在开发方法上面彼此较劲。有些人崇尚BDUF（bigdesignupfront，大设计先行），他们提倡根据UML（UnifiedModelingLanguage，统一建模语言）来做设计，提倡要安排好设计的结构，要用良好的文档描述这套设计，并且要在质量控制流程的监督之下完成整个设计。还有一些人崇尚敏捷（agile），他们认为应该尽快交付软件，然后通过一系列短期的迭代来对软件进行完善，使其满足利益相关者的需求。这两派的关键分歧，在于开发者与利益相关者之间究竟是什么关系。BDUF派认为两者是契约关系，认为软件开发项目应该有一个正规的需求收集环节，而敏捷派则认为应该把软件的功能分成小块，只有在准备实现某个小块的时候，才需要去制定详细的需求，而且认为应该在当前这一小块完工之后，就尽快把可用的软件拿给利益相关者去看。他们希望能够从利益相关者那里不断地获得反馈意见，并据此对软件开发的走向持续进行微调，以便最终实现出正确的产品。笔者试着把这种敏捷开发方法讲给IT领域之外的人听，那些人觉得这不太可靠，然而敏捷派对BDUF派的批评，则确实引起了共鸣。因为利益相关者在没有看到实际运行的软件之前，确实不太了解他们当时提出的那个程序到底会做成什么样。合约并没有一种神奇的能力，可以保证做出来的IT程序一定会讨人喜欢。

　　这两派都不能够让人了解SOA究竟为什么开发不出来。对于他们来说，这个问题似乎并不存在。

　　那么，应用程序的开发为什么会背离SOA呢？一个原因在于，很多IT项目无法在预算之内准时交工，而且也拿不出利益相关者想要的产品。这就给IT开发者造成了压力，而IT开发者在压力之下的一个反应，则是严格划定项目的范围。他们想要控制项目范围之内的所有事务，同时对范围之外的事情不闻不问。这种应用程序开发项目所实现出来的成果，是一个单独的应用程序。如果只做一个大项目，那就会得到一个大程序，如果分成很多小项目来做，那就会得到很多小程序。此外，由于大型IT项目特别容易失败，因此开发者总是愿意把大项目分成多个小项目，从而做出很多小的程序，而不是只做出一个大的程序。但是另一方面，IT架构师却总想劝说程序开发者不要去构建单独的应用程序，而是应该构建一些服务，并且构建必要的机制，使这些服务能够合起来满足项目的需求。架构师的这种想法，当时并没有实现。在21世纪初，笔者开始认真地观察应用程序的开发过程，这一观察我才发现，原来内向的开发项目会做到如此令人震惊的地步：就连程序员和数据库设计者之间的关系都相当紧张。程序员对当前项目的目标太过专注了，他们没心思去想这些数据应该如何在各种组织之间分享并管理。

　　于是，笔者打算对应用程序的开发做出第一个变革，我要找出一种对架构有利的方式，使得每个应用程序都能对整体的架构起到推进作用，而不是破坏作用。

　　如果项目变得内向，那么其中一个原因就是需求变得内向，换句话说，这是因为开发者只关注某

《体验至上：深度洞察用户需求，打造颠覆性产品》 在这个信息爆炸、产品迭代飞快的时代，无数的产品如同流星般划过市场的天空，短暂闪耀后便归于沉寂。然而，总有一些产品能够脱颖而出，深深扎根于用户心中，成为他们生活中不可或缺的一部分。它们不仅仅是满足了基本功能，更触及了用户的深层情感，引发了共鸣，甚至改变了人们的生活方式。这背后究竟隐藏着怎样的秘密？答案并非高深的算法或炫酷的技术，而是对用户需求的极致理解和精妙设计。 《体验至上：深度洞察用户需求，打造颠覆性产品》这本书，将带你踏上一段探索用户内心世界的旅程。它不是一本教你如何写代码、如何进行市场推广的枯燥指南，而是一本关于“人”的书，一本关于理解和连接的书。我们将深入剖析那些真正成功的背后，是如何将对用户的洞察转化为切实的行动，最终创造出让人们“想要”且“需要”的产品。 第一部分：拨开迷雾，看见真实的用户 我们常常误以为自己了解用户，然而，用户的行为、偏好和真实需求，往往隐藏在表象之下，需要我们有敏锐的洞察力和科学的方法去发掘。 超越“表面需求”的陷阱： 很多时候，用户直接表达的需求，仅仅是他们解决当前问题的“权宜之计”，而非根源性的渴求。我们将学习如何通过观察、倾听、同理心，去挖掘那些用户自己都未曾清晰表达的“潜在需求”和“未被满足的痛点”。这包括深入理解用户在使用产品过程中遇到的挫败感、不便利，以及他们内心深处渴望达成的目标和期望。 用户画像的深度构建： 用户画像并非简单的年龄、性别、职业堆砌。本书将引导你构建出更加立体、生动、有血有肉的用户画像。我们将探讨如何通过用户访谈、焦点小组、行为数据分析等多种方式，深入了解用户的生活方式、价值观、动机、决策过程，以及他们在不同场景下的情绪波动。一个丰满的用户画像，是连接产品与用户的桥梁。 场景化思考的力量： 用户并非孤立地存在，他们总是在特定的“场景”中与产品互动。我们将学习如何站在用户的角度，去还原和理解他们在一个完整的情境下（包括时间、地点、环境、周围的人、以及他们的目标）如何思考、行动和感受。只有在具体的场景中理解用户，才能设计出真正贴合其需求的解决方案。 同理心——同频共振的基石： 同理心是理解用户的核心能力。本书将提供一系列练习和方法，帮助你培养和提升同理心。通过角色扮演、情感地图绘制等方式，让你能够真正“走进”用户的世界，感受他们的喜怒哀乐，从而设计出能够触动他们情感的产品。 第二部分：从洞察到设计，构建有温度的产品 用户洞察的最终目的是为了指导产品的设计。如何将这些宝贵的洞察转化为切实的产品功能、用户体验和互动方式，是本书的重点。 用户为中心的设计流程： 我们将系统介绍用户为中心的设计（UCD）流程，强调从用户的需求出发，贯穿整个产品生命周期的设计方法。这包括需求分析、概念设计、原型制作、用户测试和迭代优化等关键环节，确保产品始终围绕用户进行打磨。 故事板与用户旅程图： 如何将抽象的用户需求转化为具体的产品场景？故事板和用户旅程图是强大的可视化工具。我们将学习如何绘制生动的故事板，描绘用户与产品互动的关键时刻；如何构建用户旅程图，全面展现用户在使用产品过程中经历的每一个接触点、情绪和痛点。这些工具能够帮助团队快速对齐，并发现设计中的改进空间。 原型设计与快速迭代： 在早期阶段，低保真甚至高保真原型都是验证设计想法的有效手段。本书将分享不同类型的原型制作方法，以及如何通过用户测试快速收集反馈，进行小步快跑的迭代优化，降低开发风险，确保产品方向的正确性。 情感化设计： 优秀的产品不仅仅是功能齐全，更能够引发用户的情感共鸣，带来愉悦、信任、甚至惊喜的体验。我们将探讨如何通过视觉设计、交互动画、文案措辞等多个维度，为产品注入情感，使其不仅仅是一个工具，更是一个能够与用户建立情感连接的伙伴。 信息架构与导航的艺术： 清晰、直观的信息架构和导航是用户顺利完成任务的关键。本书将深入讲解如何组织和呈现信息，让用户能够轻松找到他们所需的内容，并流畅地在产品中穿梭，避免迷失和困惑。 第三部分：产品落地与持续优化，让优秀产品生命力旺盛 一款优秀的产品并非一蹴而就，它需要在落地过程中不断被验证和优化，以适应不断变化的用户需求和市场环境。 跨职能团队的协作： 产品设计的成功离不开设计、开发、产品、市场等各部门的紧密协作。本书将强调如何打破部门壁垒，建立有效的沟通机制，让所有团队成员都能理解并践行以用户为中心的设计理念。 数据驱动的洞察： 用户反馈不仅仅来自访谈和测试，更蕴藏在海量的行为数据中。我们将学习如何收集、分析用户行为数据，从中发现使用习惯、潜在问题和未被满足的需求，并将这些数据洞察转化为产品优化的 actionable insights。 A/B测试与实验设计： 如何在上线后对产品进行持续优化？A/B测试是有效的手段。本书将介绍如何设计和执行A/B测试，科学地评估不同设计方案的效果，从而做出数据驱动的决策，不断提升产品性能和用户体验。 用户反馈的系统化管理： 用户的声音是产品改进的宝贵财富。我们将探讨如何建立有效的用户反馈收集渠道，对反馈进行分类、分析和优先级排序，并将其融入到产品迭代的循环中。 打造可持续的用户体验： 产品的成功是一个持续的过程。本书将引导读者思考如何建立长期的用户关系，持续关注用户的变化，并不断创新，让产品始终保持活力，满足用户与时俱进的需求。 《体验至上：深度洞察用户需求，打造颠覆性产品》不仅仅是一本书，它是一套方法论，一种思维方式，更是一种对用户体验的极致追求。无论你是产品经理、设计师、创业者，还是任何希望打造出真正受用户喜爱产品的从业者，本书都将为你提供宝贵的启示和实用的工具，助你在这个充满挑战的市场中，构建出那些能够长久陪伴用户，甚至改变世界的颠覆性产品。让我们一起，从用户的心出发，创造非凡。

评分☆☆☆☆☆

坦白说，刚开始拿到《需求设计：构建用户想要和需要的产品》这本书的时候，我以为它会是一本堆砌理论的学术著作，毕竟“需求设计”听起来就挺“硬核”的。但事实证明，我的担忧完全是多余的。作者的文笔非常流畅，而且善于用生动的案例来解释抽象的概念，这让整个阅读过程变得非常轻松愉快。我尤其欣赏书中关于“同理心”的部分，它没有流于表面地讲“要理解用户”，而是提供了一系列具体的方法，比如深度访谈的技巧、观察用户行为的要点，甚至是如何通过用户反馈来反思和调整我们对需求的理解。书里反复强调了“解决问题的本质”，而不是“满足表面上的要求”。这一点对我触动很大。很多时候，我们在做产品时，会陷入“功能堆砌”的陷阱，以为用户越多越多的功能就越好。但这本书让我明白，真正的产品价值在于它能否真正解决用户的核心痛点。它教会我如何区分“显性需求”和“隐性需求”，以及如何通过对隐性需求的洞察来打造出真正能让用户惊喜、甚至改变他们习惯的产品。读完之后，我感觉自己的思考方式都发生了一些微妙的变化，更能站在用户的角度去思考，也更能识别出那些真正有价值的需求点，避免走弯路。

评分☆☆☆☆☆

我必须说，《需求设计：构建用户想要和需要的产品》这本书，让我重新审视了“用户”在产品开发中的核心地位。过去，我可能更关注技术可行性、商业目标，或者甚至是自己的个人喜好。但这本书，用一种非常系统化的方式，让我明白了“用户”才是产品的最终价值所在。它不仅仅是让你去“问”用户想要什么，而是引导你去“听”用户的声音，“看”用户的行为，“感受”用户的体验。我特别喜欢书中关于“场景化需求”的讨论，它让我意识到，很多时候，用户的需求并不是独立存在的，而是与特定的场景、特定的情境紧密相连。理解了这些场景，才能真正设计出用户在需要时能够毫不犹豫地使用、并且能让他们感到惊喜的产品。书中还提供了一些非常有启发性的思考方式，比如如何通过“逆向思维”来发现潜在需求，以及如何将一些看似不相关的需求点进行整合，从而创造出全新的产品价值。这本书不仅让我学到了很多实用的方法，更重要的是，它提升了我对用户需求的敏感度和洞察力，让我能够更准确地把握市场的脉搏，做出更有竞争力的产品。

评分☆☆☆☆☆

对于任何一个产品经理、设计师或者创业者来说，《需求设计：构建用户想要和需要的产品》这本书绝对是一本值得反复阅读的宝藏。它不仅仅是一本“工具书”，更像是一位经验丰富的导师，在用一种非常人性化的方式指导你如何去做。我之前在工作中遇到的一个很大的难题，就是如何有效地收集和筛选用户需求，常常会收到很多零散、甚至相互矛盾的反馈，不知道哪个才是真正重要的。这本书提供了一个非常清晰的框架，它教我如何系统地去构建一个“需求漏斗”，从广撒网式的用户调研，到深入挖掘潜在需求，再到最终的需求优先级排序。书中关于“用户故事地图”的介绍，更是让我眼前一亮。它将复杂的项目需求拆解成一个个具体的用户场景，让整个团队都能清晰地理解产品的价值所在，也更容易进行沟通和协作。我特别喜欢书中关于“迭代”的思想，它强调了需求设计不是一次性的工作，而是一个持续优化的过程。通过不断地收集反馈、测试假设、调整设计，才能最终构建出真正满足用户需求的产品。这本书给了我很大的信心，让我觉得即使面对再复杂的需求，也有方法去应对。

评分☆☆☆☆☆

《需求设计：构建用户想要和需要的产品》这本书，给我最大的感受就是它非常有“落地性”。很多讲需求的理论书，读完之后总感觉离实际操作有点远，但这本书不一样。它提供的很多方法和工具，都是可以直接拿到工作中去实践的。我印象最深刻的是关于“需求验证”的部分。我们经常会犯的一个错误，就是凭感觉去判断一个需求是否可行，或者是否真的有市场。这本书则提供了多种行之有效的验证方法，比如最小可行产品（MVP）的构建、A/B 测试的应用，以及如何通过用户访谈来获取真实反馈。它告诫我们，在投入大量资源去开发一个功能之前，一定要先进行充分的验证，确保我们真正抓住了用户的痛点，并且提供的解决方案是有效的。这本书还强调了“团队协作”的重要性，它认为需求设计不是某一个人的责任，而是整个团队共同努力的结果。书中提供的协作工具和方法，也帮助我更好地与团队成员沟通，让大家都能在同一个频道上，共同为产品的成功而努力。读完这本书，我感觉自己对产品开发流程有了更深的理解，也更有信心去做出更明智的决策。

评分☆☆☆☆☆

这本书真的让我眼前一亮！我一直觉得在产品开发过程中，“设计”这个词似乎总是围绕着美观和用户体验展开，但《需求设计：构建用户想要和需要的产品》这本书，它真正地将“需求”这个核心概念上升到了设计的层面，而且是以一种非常系统和深入的方式。我之前接触过一些关于敏捷开发和用户故事的书，它们确实能帮助我们更好地理解用户的行为，但总感觉少了一点“为什么”。这本书恰恰填补了这个空白。它没有仅仅停留在“用户想要什么”的表面，而是深入探讨了“为什么用户需要这个”，以及如何从深层次的需求出发，去驱动产品的整体设计。我特别喜欢它关于“用户画像”的章节，它不仅仅是列举一些人口统计学特征，而是引导你去理解用户的动机、痛点、目标和行为模式，这些信息才是真正构建强大产品的基础。书中还提供了一些非常实用的方法论，比如 Kano 模型和 Jobs-to-be-Done 理论，这些工具帮助我从一个全新的角度审视现有的产品和潜在的改进方向。读完这本书，我感觉自己不再仅仅是一个被动接受需求的执行者，而是能够主动地去挖掘、去定义，甚至去创造那些真正能解决用户问题的核心需求，从而指导产品往正确的方向前进。这不仅仅是一本关于“怎么做”的书，更是一本关于“为什么这样做”的书，它给了我一种思维上的升华。

评分☆☆☆☆☆

妈妈从小教育我，人长得丑就一定要多读书……

评分☆☆☆☆☆

妈妈说不不错 性价比很高

评分☆☆☆☆☆

妈妈说不不错 性价比很高

评分☆☆☆☆☆

豁然开朗

评分☆☆☆☆☆

书本不错，买来主要是抽空阅读。希望有所提高。

评分☆☆☆☆☆

需要的书籍，阅读中

评分☆☆☆☆☆

好东西，京东自营，就是靠谱，就是快

评分☆☆☆☆☆

豁然开朗

评分☆☆☆☆☆

六一八搞活动买的，书便宜还是挺划算的。