软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。
软件的需求主要分为三个层次,从低到高依次是系统需求、用户需求和业务需求。系统需求主要是从系统角度来说明软件需求,包括功能需求、非功能需求和设计约束。
功能需求:规定开发人员必须在系统中实现的软件功能,满足业务需要。
非功能需求:系统必须具备的除功能需求外的特性,其中包括软件质量属性。
性能需求:响应时间、吞吐量、资源利用率等。安全性、可靠性、可维护性与易用性等等。
设计约束:系统的限制条件或补充说明,如系统必须采用国产数据库系统。
UML 用关系把事物结合在一起,主要有以下四种关系(也就是类与类之间的6种关系):
依赖(dependency):两个事物之间的语义关系,其中一个事物发生变化会影响另一个事物的语义。
关联(association):描述一组对象之间连接的结构关系。
聚合(Aggregation):两个对象是整体与部分,可以分割。
组合(Composition):两个对象是整体与部分,但是无法分割。
泛化(generalization):一般化和特殊化的关系,描述特殊元素的对象可替换一般元素的对象。
实现(Realization):一个类或多个类实现一个接口,其中的每个类分别实现接口的操作。
无尽空虚 发布的最新帖子
-
软件需求
-
企业基础设施的标准抽象
在现如今,没有人会再去质疑一个平台团队采纳 Kubernetes 作为自己的基础设施的合理性。事实上,在2020 年时,Kubernetes 项目已经非常接近于地完成了它最重要的使命,即:为云计算基础设施带来一层可以让平台团队基于此构造“一切”的平台层抽象。
现在我们已经能够看到,今天的云原生社区已经开始广泛认可 Kubernetes 项目作为“The platform for platform”的定位与价值,越来越多的平台、团队开始基于 Kubernetes 构建所需要的上层平台,面向终态的声明式 API 与其背后“辛勤”工作的控制器,为“构建基础设施层抽象”这个充满了挑战的技术难题,提供了一个可以在复杂度与可用性之间互相平衡的一个好的解决方案。正是如此,Kubernetes 项目才拥有了庞大的集成生态,让这个“企业基础设施的标准抽象”,逐步成为了业界公认的事实。
而更为重要的是,Kubernetes 真正的成功之处,是在于它真正押注的是构建抽象的方法而非这些抽象本身。在绝大多数情况下,企业基于 Kubernetes 构建上层平台,都会引入各种各样其他的抽象作为补充。
长久以来,业界对云计算的认知,一直围绕着“SaaS + PaaS + IaaS”这样经典的三层架构模型展开。然而,在 前几年,随着云原生技术的极大普及,我们却发现这个模型似乎正遭受着挑战。
现如今的云原生技术,以 Docker 以及容器这个创新性的技术革命为基础,又取经典 PaaS 之所长,最终在业内所有人士的关注下,以 Kubernetes 生态为载体而最终落地。
此外,对于“SaaS”来说,云原生带来的容器化软件打包与交付体系和 Kubernetes 底座,也已经极大地改变了云端软件的分发与运维方式。所以,无论是 PaaS 也好,还是 SaaS 也好,本质上正在被“云原生”的技术浪潮迅速“压平”,在这种背景下,传统“水平”划分云计算体系的方法其实已经变得难以自洽。
Kubernetes 的成功,极大使能了“平台构建者”这个以往被人们遗忘在企业成本中心(Cost Center) 里的重要角色。事实上,Kubernetes 之所以能够取代 Docker 生态成为今天云计算平台上的主角,很大程度上是这个群体做出了最终的决定。否则,按照 Docker 所触达到的用户群体规模以及其在开发者生态中的被接纳度, Kubernetes 几乎毫无胜算。
但与此同时,Kubernetes 之上的平台构建生态,在今天依然是高度集中的。这种平台构建生态的高度集中,与云原生希望构建的“普惠式”未来,显然是不相符的。当然,既然技术发展还没有跟上愿景,那么云原生社区也就不会停下脚步。
-
人机交互技术
人机交互技术(Human-Computer Interaction Techniques)是指通过计算机输入、输出设备,以有效的方式实现人与计算机对话的技术。人机交互技术包括机器通过输出或显示设备给人提供大量有关信息及提示请示等,人通过输入设备给机器输入有关信息,回答问题及提示请示等。人机交互技术是计算机用户界面设计中的重要内容之一。
人机系统包括人、机和环境三个组成部分。人机界面是人与机器进行交互的操作方式,即用户与机器互相传递信息的媒介。在人机系统模型中,人与机器之间存在着一个相互作用的“面”,即人机界面。人与机器之间的信息交流和控制活动都发生在人机界面上。介于用户和计算机之间,是人与计算机之间传递、交换信息的媒介,是用户使用计算机的综合操作环境。
人机界面设计师处理的是人与硬件界面和人与软件界面的关系,而硬件界面与软件界面之间的关系则通过计算机技术来解决。人与硬件、软件的结合构成了人机界面。传统的人机交互是研究用户与计算机系统间往来的交互。新的人机交互可划分为人、计算机以及交互这三个要素。HCI 1.0关注于人们可以亲眼看到、亲耳听到的界面设计或音效制作。HCI 2.0规定的范围得到了拓展,它特指从2000年年末开始流行的Web 2.0环境下的人机交互。
软件工程与人机交互视为两个相互独立的学科。 共同点是人机交互用到了软件工程的产品功能需求软件工程会限制人机交互的发展; 不同点是:首先,软件工程师与人机交互设计师关注的重点有很大不同。软件工程师经常是以系统功能为中心交互设计人员则以用户为中心。 其次,交互设计的评估方式也与一般软件工程方法存在不同:交互评估通常基于真实用户,评价机制也往往来自于用户使用的直观感觉。 再次,以往人机交互与软件工程经常是分开讨论的,一方面软件工程较少提及交互团队在产品设计中的重要作用,另一方面人机交互也很少谈及其与软件工程的密切关系。
-
Jumpserver跳板机各类用户的区别
Jumpserver跳板机的用户分别有jumpserver 用户、系统用户和管理用户、普通用户和特权用户这几类
admin管理员用户:这个用户是最大权限的用户了。可以增删改查平台上面的任何一个地方。比如:增删改查用户,增删改查资产,增删改查授权规则。
WEB界面里面的管理用户:这个管理用户是存在于资产服务器上面的用户。就相当于你服务器上面的超级用户。
这个用户是给Jumpserver系统平台用的,jumpserver会用这个用户去服务器上面拿到服务器的一些信息。比如:cpu,内存,硬盘,型号等等。所以说这个用户的权限要大。jumpserver还会用这个用户去帮你在服务器上面创建系统用户。这个用户你必须要先在你的服务器上面创建好。WEB界面里面的系统用户:这个用户就相当于你服务器上面的普通用户。最终开发,测试...登录到服务器上面的用户就是这个用户。这个用户你可以不用先在服务器上面创建好。管理用户会帮你去创建的。
系统用户:系统用户是 JumpServer 跳转登录资产时使用的用户,可以理解为登录资产用户,如 web,sa,dba,而不是使用某个用户的用户名跳转登录服务器; 换言之就是用户使用自己的用户名登录 JumpServer,JumpServer 使用系统用户登录资产。
系统用户创建时,如果选择了自动推送,JumpServer 会使用 Ansible 自动推送系统用户到资产中,如果资产(交换机)不支持 Ansible,请手动填写账号密码。
-
增长产品经理如何理解产品增长
首先,我们需要了解增长的定义,增长是一个很大的词,不只是拉新,而是对用户的全生命周期负责。增,用户数量的增加,关注用户获取的效率,追求ROI的最优化。长,用户价值的成长,关注用户激活、留存、活跃、流失预警及召回,追求生命周期总价值最大化。通过投入资源,来以最低的成本,获取最高质量、最高数量的用户。
ROI=收益/成本,收益=根据用户的总生命周期价值,计算单个用户行为的价值,例如某行为UV价值是0.8元这种。
成本=为了引导用户完成这个行为的成本,成本小技巧,部分用户高成本,部分低成本,打平总成本即可,例如pdd红包部分券部分现金。基于主链流程的增长: 用户获取阶段:这个阶段即是尽可能多的增加用户触达,这部分可以是结合市场部门,也可以是结合第5点的用户推荐,当然还有一种就是寻找蓝海渠道
用户激活(新客转化):这一步的意义把第一步触达的用户进行转化。常见的策略是针对当下有需求用户发福利刺激下单、补贴+引导完成核心行为(Aha时刻)、针对暂无需求用户增加记忆点。
用户留存(产品价值):这个属于产品设计问题了,产品核心价值是什么,满足了什么用户在什么场景下的什么需求。是否可重复满足等等,这块一般属于业务线来负责,此处暂且不谈。
用户转化(商业化or复购):该处是针对非交易型产品,对于交易型产品,此处即是促进用户复购,一般是通过会员、业务线自己做策略来进行增长,同上4,属于产品设计问题Or会员体系设计问题,此处暂且不谈。
用户推荐:这块一般可以是在用户完成核心行为(下单后),进行策略引导其进行好友分享,邀请好友助力or炫耀一下。
-
APP如何适老化
面对人口老龄化现状,产品应当结合适老化趋势进行相应设计,以此让老龄人群也能方便、安全地使用产品,赋予产品以设计温度。
2021年第七次全国人口普查数据显示,我国60岁及以上的人口占总人口的18.7%,人口2.64亿,65岁及以上的人口占总人口的13.5%,人口近2亿。
滴滴老人打车:入口:首页快捷导航中老人打车。介绍:滴滴专门针对老年人推出的打车模式,可一键叫车,操作简单、大字、无广告。特色功能:电话打车, 如果老人不会打车,可通过打电话方式叫出租车。
懒人畅听大字版:入口:新APP,直接下载懒人畅听大字版。介绍:这也是一个针对长辈推出的音频类APP。有书库、推荐、精选、我的4个栏目。首页分类清晰简明,操作简单。特色功能:可语音搜索内容,操作方便。音频内容丰富。
上面是市面上比较熟知的、针对大家开放的适老化产品。从这些产品中,我们可以总结以下6个维度,是我们做适老化产品必须要考虑的。
名字上:产品名称或用户模式,要避免老年版、老人版、适老版。市场上用得最多的是大字版、大字模式。关怀版、关爱版、长辈模式、极简版、无障碍版等。主要结合自己的产品特性来确定。
UI界面上:界面字体、图标要大,这是基本要求,方便视力下降的长辈长辈。界面文字和背景对比度要高,方便识别。界面文案,要让老人易懂。
交互上:交互上要简单直接,减少复杂操作。能一键操作的就一键操作,能不输入文字的就不输入文字。交互方式要统一,让老人家知道每次操作会出现什么。关闭按钮、操作按钮一定要大、要明显,不要出现倒计时自动跳。
信息结构上:内容可以多,内容要做好清晰分类,清晰易懂。信息导航不要多个维度嵌套,不要让长辈晕头转向。信息层级不宜过深,2-3层为宜,不要让长辈迷路。
功能上:要考虑哪些功能该提供,哪些不该提供?是否要针对老人单独提供内容推荐算法?是否要针对老人提供一些专属的功能或服务?如果是复杂操作,比如预订餐馆、打车,记得提供电话预订模式。如果是在线客服,记得提供电话客服。
态度上:虽然工信部对APP适老化有时间和名单要求。但是如果你把这个当做一个政治任务,你就输了。人口老龄化严重,老年人基础大,APP适老化,是互联网发展必然。唯有认真探索,站在父母角度考虑产品设计,才是应有的姿态。
一个APP的适老化态度,反应公司、团队和产品的价值观。个人以为,这是最重要的。
-
从设计角度深挖需求——用户调研
用户调研是了解用户最便捷的手段,能够反映出用户真正想要的东西,完善需求。为了确保我们开发的产品是用户真正想要的东西,我么可以在做出产品之前去了解用户的需求,或者是对产品功能改版后对用户进行用户调研也是评判产品改版可行性的一种方式。
卡片信息(Card Sorting):观察用户是如何理解内容和组织信息,用来帮助你的产品更合理的组织信息。
情景访谈(Contextual Interviews):走进用户的现实环境了解用户的工作方式,生活环境等等情况。
焦点小组(Focus Groups):组织一组的用户进行讨论,让你更了解用户的理解、想法、态度和想要什么。
启发式评估(Heuristic Evaluation):可用性的检查方法,让一些行内专家对网站产品进行指导。
单独访谈(Individual Interviews):一对一的用户讨论,了解某个用户是如何工作,知道用户的感受,想要什么和他的经历。
平行设计(Parallel Design):对同一个产品进行分开的设计,从而比较选择一个最佳方案。
人物志(Personas):构建一个虚构的人来代表大部分用户,设计团队围绕这个虚拟人物设计开发产品。
制作原型(Prototyping):利用简单产品原型进行相关的小规模测试,从而避免因开发过久、到后期才发现问题而造成的较高成本。
问卷调查(Surveys):利用网上或纸张的问题对用户进行发放填写,从而收集用户对产品的反馈意见。
任务分析(Task Analysis):通过任务分析了解用户使用你产品时的目标和操作方式,习惯。
可用性测试(Usability Testing):请用户来试用你的产品,完成测试。从而得到你所想要的东西。
用例子(Use Cases):描述某个用户使用产品时的情况,包括目标和行动。
内容化(Writing for the Web):对产品进行内容上的整理、优化。让用户更容易的了解你所表达的内容。
用户调研,是一种吸引人的、高效的用户体验的方法。要求调研专员或设计师通过调研领域工具收集问题、分析问题、总结问题的一种方法。其中B端设计师要以用户体验为中心的理念围绕用户如何使用产品完成工作、希望工作和需要工作的这三点提问,根据用户反馈信息来优化产品交互界面和ui界面。
怎么获取更多的用户让用户使用我们的产品;当我们的产品到了有用户有流量的阶段产品用什么方法进行盈利。横向的看有以下三种概念帮助我们区分产品需求的比较重要的三个纬度:
需求的等级:刚需是根据“弹性需求”而言的,弹性需求就是不是用户必须要实现的需求只是为了增强用户体验感而添加的需求,而 “刚需”是用户必须满足的需求从字面解释就是用户必须需要的东西或者是必须要做的事情。
发生的频次:高频是指用户的想实现的一个需求欲望在一定周期内产生的频率。
用户的痛点:是指用户在解决自己需求时产生的困难,也就是用户没有使用我们产品时用户用他自己的解决方案来解决自己的需求时做带来的困难。
-
To B 产业观察时代
为什么To B这么热?大家都知道这两年To B赛道真的很火热,我们可以从美股SaaS公司看到,去年很多To B SaaS企业都突破了百亿美金;下表中可以看到标出的部分也就是EV/NTM Revenue,也就是企业的市值除以未来一年的预期收入;平均18.7x,中值 16.1x;所以说美股市场给了SaaS企业服务的公司非常高的市值。
企业服务市场趋势,传统软件SaaS化:以前很多做一次性部署的传统软件,通常都是大项目,流程复杂,实施起来成本非常的巨大,现在已开始转向轻量化的解决方案,也就是SaaS化。SaaS化不管对于甲方乙方都有很多好处。价格便宜了,决策更容易,并且云计算已然成熟,不用买那么多的硬件。
IT决策业务化:以前我们在做决策的时候,通常都是搞定老板、CEO等等,请吃个饭或者喝个酒来进行;但是现在,在SaaS化的前提下,已经不是搞定老板了,而是搞定业务部门负责人,原理也很简单,现在软件的客单价没那么高,从部门经费里就报了。
IT资产费用化:不做财务的小伙伴可能不太理解,举个例子,在没有云计算的时代,比如迅雷,刚开始做互联网的时候需要买一堆服务器、带宽等等,有很多固定资产。
我们把投资逻辑分成两部分来看:看事:是否刚需:不管任何投资这个都是第一重要的,只有刚需才能够往后面继续发展;企业服务对于企业来讲就两方面,要不你能帮我赚钱,要不你能帮我省钱。看人:看人是比较简单的,我们对To B企业的CEO画像其实就八个字——行业老炮+超级销售;这都是To B公司中很重要的存在。
-
下一个十年,开启内容战略时代
如果你问我:下一个十年,什么会决定一家企业的增长力?我会回答你:是内容。为什么不是数字化?不是大数据?因为我始终相信一点:数字化和大数据最终会成为“基础设施”,是每个企业无需做特别投入,就会拥有的东西。
就是一条广告从上线到没人看,它“活”了多久。显然,内容需求会呈现幂次成长。内容生产会和产品生产一样,成为企业的重投入。内容的生产能力,将决定企业的增长效率。
内容的生产能力,将决定企业的增长效率。当你一周之内,要生产数以千计的内容时,量变会引发质变,内容的生意将变成另外一幅模样。
内容不止于营销,将成为企业的战略能力,那么,内容的影响力边界就会扩散到广告之外的领域。首先波及到的地方,就是渠道。
渠道的去中心化:从收租,到共赢。我们常常大谈特谈媒体的去中心化,但是很少有人看见渠道的去中心化。在过往几年里,无数新型渠道崛起,这些渠道不仅分散了传统渠道的销售额,还渐渐形成了另一种动销模式。内容的影响力边界正在从广告,扩展到渠道、产品、组织上,成为企业未来最重要的战略能力。放弃内容营销,开启内容战略,才能把握好下一个十年的增长秘钥。
-
运营人私域能力自检清单
私域运营是当下运营人普遍需要接触的运营领域,利用私域运营,商家或平台可以有效降低成本,直接触达用户,进而推动增长。那么,若想从事私域运营,运营人应当具备哪些能力?
从行业来看,目前私域流量运营做得最好是在线教育和电商,如果你是在线教育运营人且拥有还不错的私域运营能力,或许电商是你不错的下个赛道,除此之外适合私域运营的行业还包括:在线教育和线下教育、快消品、美妆、白酒类、内容资讯、医美、社区团购、线下餐饮、实体门店(便利店、超市、奶茶店)、珠宝、茶叶等。
私域运营体系搭建能力
引流能力:从公域到私域引流,这里主要指的是免费方式。关键在于找到精准渠道,设计内容诱饵,涉及到引流路径设计,比如是被动还是主动加粉?是直接进群、加个人号,还是加公众号?
全域流量调取能力:从自己在其他流量平台已有流量引流到微信私域,其他流量平台,包括淘宝、天猫、抖音、快手等,关键在于设计引流路径,目的是沉淀到微信私域体系,进行后续反复触达和激活,扩大整体私域流量池。
投放及换量能力:从公域到私域引流,主要指的是付费方式。为什么有免费方式,还需要付费方式?因为效率更高,且用户群更精准。
触达和激活能力:从流量承接到微信的第一个载体出发,几个载体怎么打配合,形成触达互补能力,关键设计公众号信息触达频率及内容设计,个人号和社群及朋友圈如何打配合,在不让用户感到反感的前提下,完成用户激活。
成交模型设计能力:根据产品设计私域成交体系,包括个人号成交模型、社群成交模型、朋友圈成交模型、和直播成交模型。
召回体系设计能力:前提是搭建基于SCRM的流失预警,从而明确什么样的用户即将流失。最好可提前计算召回ROI,然后设计召回体系,什么时间用什么渠道和内容召回什么样的用户。
微信全生态流量闭环搭建能力:微信私域各种载体的流量闭关搭建,包括微信号/企微客服号、微信群、公众号、小程序、朋友圈、视频号等。