美文网首页PMskill电商后台
如何设计好后台产品?

如何设计好后台产品?

作者: 徐薇薇 | 来源:发表于2017-08-30 01:07 被阅读73次

    从目的出发,后台系统是管理的建模,是指标、制度、责权利、流程的建模。

    微信公众号:weitalks

    总结:后台产品设计,最难的是抽象出实体以及实体的关系和相互动作,还有实体动作的各种case。基础工作是抽象出哪些不变定了或重复形成规律了,哪些会变了,变了会怎样(建议设计成多对多)


    目录:

    1、设计管理系统时应该知道的点

    2、相关图介绍

    3、需求管理的参考思路和步骤

    设计管理系统时应该知道:

    1、管理系统分析:

    凡是做管理系统的,相关制度文件是重要的需求分析来源,且管理系统是对人、事、物、条件/场景、规则的管理建模。所以思考时首先从管理上思考优化解决问题,再从软件系统思考优化解决问题

    to  c产品事件之间没有很强关联,着重场景;to b产品因为事件很多且事件之间强关联,着重流程。

    2、一个系统需具备:

    人事物可记录、数字化、可追踪、系统化(联系不孤立)、有边界(条件/输入/输出/规则)、可衡量(指标和量化)、标准化(去重)、流程化、自动化、可配置、可监控、是否可撤销、安全/隐私、可扩展、可回收、重要程度、频率。

    3、需求分析的思路:

    to c产品:

    to b 产品:

    上面业务分析欠妥,按下面来:

    在第一阶段的分解我们可以看到以主题域为主线索,具体的分解过程为目标系统-》主题域-》业务事件,其核心就是要将主题域或子系统作为一个黑盒来分析,搞清楚边界和其于外部用户的交互,通过理清楚上下文关系图后第一阶段的输出基本就很容易明确了,即业务事件+报表需求

    到了第二阶段则是以业务流程为主线索进行分解,具体为业务事件-》业务流程和业务活动-》领域类图和用例。在这个阶段我们看到两个重要输出,一个是静态的领域类涉及到领域建模,而领域建模的重点就是标识类,明确类之间的逻辑关系和数量关系,添加重要的结构规则。另外一个就是动态的用例

    需求采集:计划、渠道、活动、内容

    需求评审:筛选、分类、排序、审计

    4、需求规格说明书包含以下几个要素:

    4.1、背景/术语/约束-条件

    4.2、目标/范围/指标/盈利模式/产品风险

    4.3、涉及人员、组织架构和权限

    4.4、产品架构、总体业务流程和功能清单

    4.5、功能-业务规则/功能类型/业务实体/业务流程:业务实体一览图-类图/活动图/状态图

             业务规则包括模块、功能、详细业务逻辑描述、功能类型、涉及系统

    4.6、详细设计,包括角色说明、业务/操作流程、界面设计、字段描述及操作逻辑

    4.6.1、功能性需求,包括非用例功能性需求

    4.7.2、非功能性需求:架构/接口/安全/性能/界面

    4.8、参考文献/版本修订记录

    要求:需要系统做什么描述清楚,可行性/无二义性/可验证性

    5、需求分析时产出文档

    5.1、背景调查表

    5.2、涉众问题表

    5.3、条件/目标/范围/指标(项目双赢成功)

    5.4、制度文件、现状组织架构图和分权手册、现状流程架构、上下文关系、现状业务流程

    5.5、功能范围及与其他系统关系、流程架构总图、技术架构图、数据接口图、数据库/报表

    5.6、一级/二级/三级/四级/五级流程图、五六级操作指导手册、流程清单/树状图

    5.7、沟通及管理制度、绩效指标、部门角色岗位职责表、执行者/用例图

    5.8、可能产生的新问题

    5.8、问题分析表、需求变更表/版本更新记录、版本管理

    6、一个用例通常包含以下几个要素:

    触发事件(谁干了什么,触发了这个用例)、假设和约束、目标/主题范围/层次/指标、执行者、相关利益者、前置条件(在触发该用例相关操作前,用户、系统、商品等角色和业务实体必须达到的条件或状态)、后置条件(用例技术后系统所处状态)、最小保证、成功保证、业务规则(基于对象各种目的和实体各种状态抽象出来的场景和行为规则)、主成功场景-主流程/目的-步骤、分支流程、异常流程、数据变化、技术变化、输入/输出(表单/报表/接口)、重要程度-优先级、频率、发行版本、响应时间、执行渠道/平台。

    其中业务规则:行为/数据/界面的要求
    行为:主题域-》事件-》活动-》用例-》步骤

    案例:买东西(完整正式版本)

    主执行者:请求者

    语境中的目标:请求者通过系统买东西,并得到说买的东西。不包括付款方面的内容。

    范围:业务——整个购买机制,包括电子的和非电子的,正如人们在公司中说见到的一样。

    层次:概要

    项目相关人员和利益:

    请求者:希望得到她订购的东西,并且操作要简单。

    公司:希望控制花费,但允许必要的购买。

    供货商:希望得到任何已发货物的货款。

    前置条件:无

    最小保证:每一个发出的订单都已经获得有效认证者的许可。订单具有可跟踪性,以便公司只对收到的有效货物开账单。

    成功保证:请求者得到货物,修改预算,记入借方。

    触发事件:请求者决定买东西。

    主成功场景:

    1.  请求者:发起一个请求。

    2.  批准者:检查预算中的资金,检查货物的价格,完成提交请求。

    3.  买者:检查仓库的存货,找出最好的供货商。

    4.  认证者:验证批准者的签名。

    5.  买者:完成订购请求,向供货商发出PO(订单)。

    6.  供货商:把货物发送给接收者,得到发货收据(这一点超出了本系统的设计范围)。

    7.  接收者:记录发货情况;向请求者发送货物。

    8.  请求者:设置请求已被满足标志。

    扩展:

    1a)请求者不知道供货商和货物价格:不填写这些内容,然后继续。

    1b)在收到货物之前的任意时刻,请求者都可以修改或取消请求:

    如果取消,则把这个请求从执行处理中取消。(从系统中删除吗?)

    如果降低价格,则不影响其处理过程。

    如果提高价格,则把请求送回批准者。

    2a)批准者不知道供货商或货物价格:不填写这些内容,留待买者填写或返回。

    2b)批准者不是请求者的经理:只是批准者签名仍然可行。

    2c)批准者拒绝申请:送回给请求者,要其修改或删除。

    3a)买者在仓库中找到货物:将存货先发出,并从申请者要求的总购买者中减去已经发出的这部分货物量,然后继续。

    3b)买者填写在前面活动中没有填写的供货商和价格信息:请求重新发回给批准者。

    4a)认证者拒绝批准者:发回请求者,并将此请求从执行处理中取消。

    5a)请求涉及到多个供货商:买者创建多个PO

    5b)买者将多个请求合并:相同的过程,但是用被合并的请求标记PO

    6a)供货商没有按时发货:系统发出没有发货警告。

    7a)部分发货:接收者在PO上做部分发货标记,然后继续。

    7b)多个请求PO的部分发货:接收者给每个请求分配货物数量,然后继续。

    8a)货物不对或质量不合格:请求者拒绝接收所发送的货物。

    8b)请求者已经离开公司:买者同请求者的经理进行核实,或者重新指派申请者,或者返还货物并取消请求。

    技术和数据变动列表:无

    优先级:多种

    发行版本:几个

    响应时间:多样

    使用频率:3/天

    主执行者的渠道:网络浏览器、邮件系统或类似系统

    次要执行者:供货商

    次要执行者的渠道:传真、电话或汽车

    未解决的问题:

    什么时候从系统中删除被取消的请求?

    要取消一个请求需要那些权限?

    谁能修改一个请求的内容?

    请求中需要保留哪些修改历史记录?

    当请求者拒绝已经发送的货物时,会发生什么情况?

    申请和订货在运作上有什么不同?

    订购如何参考和使用内部存货?


    相关图介绍

    结构建模主要分析系统业务的概念及其关系,行为建模的工作,主要是分析系统的业务流程.

    结构建模:类图,对象图,构建图,部署图,包图。

    行为建模:活动图,状态机图,顺序图,通信图,用例图,时序图

    活动图:

    顺序图:

    涉及角色之间交互频繁

    下面是基本语法

    案例

    有条件分支下:

    状态图:

    用例图u:

    角色who在哪个系统上做了什么事情。

    用例表模板:
    目标,规则说明,条件,流程,异常,结束状态。

    部署图:

    和拓扑结构很相似

    结构图:

    包:

    表示用户之间的关系

    实战:考勤系统

    做to b项目是双赢。

    分析思路:

    业务分析:结构建模和行为建模

    战略分析/背景:

    需求分析(目标/涉众/待解决的问题/范围/范围/项目成功标准)

    目标:

    涉众/待解决的问题

    越是高层的涉众越容易准确全面提出自己期望,越是基层员工越容易提出界面级别的要求

    范围:

    项目成功标准:

    考勤系统的业务概念分析:可以用类图来画业务概念图

    类图分析的步骤:

    实体,属性,关系。

    业务概念图的重要程度和高难度:吃透需求和业务、数据库设计

    打卡记录:

    请假申请:

    请假类别既可以作为属性,又可以作为类。因为请假类别比较重要,可以抽象出类。

    外出申请:

    1)审批活地图

    2)审批状态机图

    3)申请类图

    外出申请审批内容,数据库表可以不必按照上图设计这么多类,在数据库中设计一张表就可以了。写这么多是想让自己工作占据主动。

    管理系统的进一步思考:

    如何应对多变的流程?

    执行者与用例分析:

    执行者有人或者系统两种。

    普通员工的用例分析:

    用例表:

    根据之前贴出的用例表模板来填

    行政员工、财务员工用例分析

    部门经理、总经理用例分析

    用例分析总结:

    非用例的功能需求

    系统的非功能性需求:

    安全、易用、性能、接口


    如何编写需求规格说明书?

    有先天缺陷的MIS系统:

    财务软件、CAD软件等行业软件能立马提高用户的工作效率,能很快为用户带来实际的价值,这类软件很容易做到受用户欢迎。这类软件与MIS系统最大的区别是,这类软件改善的是用户的工作技术和工作技能,而MIS系统改变的是管理习惯、工作思维习惯。MIS系统的实质就是用一套新的管理思想和工作习惯来要求你,它是管理思想的载体,并不是所谓的办公自动化,无纸办公这样的表面化东西。

    如何打造有竞争力的MIS系统?

    要熟悉该客户的业务,至少需要在客户的公司工作几个月

    怎样才能做一个能适应需求变化的设计呢?

    如何让团队队员也了解需求?

    如何让客户签署几十页甚至上百页的需求文档?

    确认不同级别的需求:

    让客户全方位参与需求:

    需求过程

    下图中的需求开放改成需求开发

    问题定义&&鱼骨图:要素

    业务事件/模块/报表:

    获取模板

    需求管理:

    1、需求管理项:

    2、基线、优先级、工作量评估:

    需求基线:目前特定版本下将投入开发的需求。

    优先级评价对象一般是每个主题域下的需求,评价类型一般是关键/重要/有用/一般。

    所以在进行优先级评价之前,先整理目前基线需求内部各个需求的关系,也就是wbs结构。

    优先级评价:业务价值(需求来源成本产出用户频率规模)》技术开发》项目管理

    需求来指的是老板合作方内部等

    需求拆解和优先级划分

    敏捷开发除了简化流程,还可以对完整的需求、完整的产品进行拆解,拆解的前提是,保证每一个模块都是完整独立。也就是说,这个拆解出来的单独模块是能够走通一个分支流程的。

    需求的拆解,需要遵循的是:独立模块,能够走通分支流程。

    例如,一个电商产品,其可能包括有商品、物流、评价、退货、优惠券等需求。如果要对这个产品的需求进行拆解,应该如何拆解?假如把商品模块单独出来,所做出来的产品能够管理商品,但是做出来之后也不可能能够使用,这时候用“独立模块,能够走通分支流程”的原则来代入,商品模块没有满足“走通分支流程”,有商品却不能购买,不能走通购买的流程,因此,这样拆解所做出来的产品,即使上线了,也是不能够使用的。

    优先级的划分,可利用KANO模型来进行分析:基本型需求、期望型需求和兴奋型需求。基本型需求是一个产品需要最先满足用户的,因此,对于一个从零到一的产品来说,这个是应该优先去做的,从基本需求到期望型需求,再到兴奋型需求,是一个从零到一的产品循序渐进的过程。

    优先级的划分,可利用KANO模型来进行分析:基本型需求、期望型需求和兴奋型需求。基本型需求是一个产品需要最先满足用户的,因此,对于一个从零到一的产品来说,这个是应该优先去做的,从基本需求到期望型需求,再到兴奋型需求,是一个从零到一的产品循序渐进的过程。

    产品策划提前两到三个版本的好处是,当开发过程中发现有余量时,可以把后续版本中的一些小的需求提前穿插到当前版本。

    一般而言,在一个版本里面,我只会设置一到两个重点的需求,其余需求皆属于可调整范围内。版本的重点不是看某个需求体量的大小,而是看这个版本的产品目标是什么。每个版本的产品目标都是在进行版本规划时已经明确下来的了。比如我会把电商类产品的需求分为四大类:拉新、留存、活跃、销售。

    工作量估(人周/人天)算:分主题域/分权重

    基线划定,迭代和管理:

    划定基线时按优先级筛选

    3、迭代:

    产生原因:如果一次迭代完成不了这些优先级的需求,可以分成不同的迭代。

    迭代安排:

    搜集每个需求对用户业务的价值、成本、风险、需求的规模、需求之间的依赖关系以及一次迭代可完成的工作量等方面的信息,然后确定出多个对于下一次迭代可行的需求组合.

    可行的需求组合:

    在满足可用工作量和依赖关系限制条件下,应优先选择那些优先级高的需求组合

    BUG>>影响付费>>影响客户核心行为>>客户>>公司战略>>需求价值做与不做的影响

    4、变更:统一渠道受理/统一管理平台记录

    变更放在待处理需求。

    注意变更产生的影响。

    变更影响范围:行为/功能/数据/界面/系统非功能性/业务规则影响

    常见变更类型:

    变更管理平台:

    5、需求跟踪:单个需求与系统(业务规则/架构/源代码/数据库/用例/文档)之间的关系。

    收集/评估/审核/变更影响分析/维护


    延伸:

    如何发现职责?职责强调的是对目的、目标、行为的抽象

    对象是行为和数据的统一体。职责来自于你的软件是如何工作。来自于软件的HOW。寻找和分配职责需要灵感,是一个创造性活动,是一个充满探索冒险发现新奇的乐趣活动,从下面几个方面寻找需求中职责:

    1.来自用例分析中顺序图消息发送

    2.构造invention、 约束表达、策略、算法、规格和描述都可以成为职责。

    3.系统要做的事情或要管理的信息

    4.将实体对象看成一个演员(拟人化),扮演一个角色应该知道哪些事情knows something、会做那些事情do sth.,能够控制或决定什么事情。

    另外可以看看这篇 业务建模的推导过程,业务系统模板可参考这个 

    复习时记得看看《火球UML》、《UML和模式应用》、《对象设计:角色、责任和协作》、《编写有效用例》、《OO系统分析员之路》

    业务流程图:

    http://blog.csdn.net/k7Jz78GeJJ/article/details/78644507?locationNum=3&fps=1

    相关文章

      网友评论

        本文标题:如何设计好后台产品?

        本文链接:https://www.haomeiwen.com/subject/fckadxtx.html