家里老人有这些特征,宝宝放心让他们带,保证比亲爸妈带得还好

年轻父母为了生计,有的不得不在宝宝很小的时候就外出离家打工,心里除了挂念宝宝,还有愧疚。当然他们更放心不下一件事,那就是,老人带孩子,会把宝宝带好吗?

其实,宝宝带得好不好,并不是根据监护人的年龄来决定的,而更看重养育者的知识层次、生活习惯、育儿理念。

如果家里老人是以下类型,宝宝就可以放心让他们带,保证比亲爸妈带得还好。

生活规律、早睡早起的老人

不少老人习惯早睡早起,总是7点左右吃晚饭,不到9点就准备睡。同时生活又很规律,早晨几点出去锻炼,几点回来吃早饭,早饭后散步,中午固定在12点到12点半吃饭…..其实这样的老人是最适合带宝宝的。

为什么?育儿专家们都说,宝宝出生后,最需要的是安全感。安全感除了从养育者无微不至的照料中获取外,十分固定的生活规律也能给予。站在宝宝的角度看,如果你提前预知下一顿饭在什么时候吃,吃完多大一会儿该出去干什么,什么时候回来,什么时候关灯睡觉,这样是不是有种“一切尽在掌握”的稳定感。这就是安全感的雏形。可见,宝宝跟着生活规律的养育者,受益会很多。

反观如今的年轻父母,能规律生活的并不是很多。晚上刷手机熬了夜,白天就晚起会儿,中午一看时间晚了叫个外卖,晚上又不知道什么时候才睡。这样毫无规律的作息是会给宝宝带来困惑的。

因此,如果家里的老人生活规律,宝宝让他们带就会放心很多。而年轻爸妈就算为了宝宝,也建议尽量作息规律些。

情绪平稳、没有大起大落

宝宝在刚出生的第一年,是没有自我意识的。他们的情绪和养育者息息相关。因此,如果养育者情绪反复无常,会给宝宝心理造成极大伤害,同时也会体现在身体上,比如总是精神萎靡,或者生些小病等等。

老人们经历了一辈子的大起大落,情绪上相对来说比较平和,不容易像年轻人那么急躁。因此,如果你家里的老人情绪一直很平稳,那宝宝就放心让他们带吧!

同时,如果妈妈产后有抑郁倾向,家里人就要及时协助妈妈养育宝宝,这样才能让宝宝获得更好的照料。

耐心又体贴

料理宝宝吃喝拉撒的日常,既琐碎又无趣,有时还可能充满挫败感。比如,刚喂宝宝吃完奶就吐了,刚换上干净衣服又拉了一身。这对养育者的耐心绝对是极大考验。而宝宝的安全感,正是通过感知到你的“及时又耐心”的照料才建立起来的。因此,家里的老人如果耐心又体贴,那可真是块宝,会比脾气急躁的宝爸宝妈更合适。

其实,宝宝刚出生的头三年,由爸妈照料自然是最好。但如果出于条件限制无法做到,只能委托老人,只要老人符合以上特征,同时又很固定没有频繁换,宝宝照样能从老人那里获得情感链接,建立安全感。为此父母不必自责,也不必太过担心。

你家宝宝是谁带大的呢?

自从用了敏捷,天天在开会? 4大Scrum会议如何才能有意义?

4大Scrum敏捷会议要怎么“敏”才有意义,敏捷的核心是什么?如何掌握核心4大Scrum会议的精髓?一个Scrum要怎么安排,有哪些必备要素?

加入敏捷团队的第一周,团队每天都围成一圈在墙角开会。

加入敏捷团队的第二周,站的有点累,我换下了我的高跟鞋,换了一双方便舒适的平底鞋……敏捷就是小步快跑嘛!

加入敏捷团队的第三周,嗯……哪里不对? 为什么每天都在开会,我已经没有时间开发了……

文章概要

我们来聊一聊,4大Scrum敏捷会议要怎么“敏”才有意义?

敏捷会议的核心要义
Scrum会议前期准备会议
如何掌握核心4大Scrum会议的精髓
一个Scrum要怎么安排
敏捷的核心是什么?
我的程序员男朋友有一天和朋友约了晚饭,然后意识到当天是一个重要节日又不想爽约,他小心翼翼地问我,晚一些需不需要来找我?

我说:你不用来了。

男票沉默了大概3秒。没有接话。

我说:你是不是在理解这句话什么意思?

他尴尬地哈哈大笑,说:如果我理解成因为你约了饭会比较晚,就不用再辛苦跑一趟了,那我就放心不过来了。如果理解成你生气了,我是不是还是来一趟比较好。

你看,小到情侣互动,大至软件开发,企业管理,我们都会遇到以下几个终极问题:

对方到底需要什么? 而我们的大方向解决方案是不是达到了要求? (例如:怎么理解“你不用来了”这个需求)
我们的沟通是不是有效,问题是不是被及时提出并找到解决方案。(例如:怎么发现沉默的那三秒是以为还在思考)
我们的是不是会及时反思自己的行为,提出建议让团队可持续发展。(例如:我需要怎么样更清楚地表达自己的意愿,或者男票对节假日更敏感一些)
敏捷开发的魅力所在,也正是冲着这三个问题来的。以Scrum为例,理解Scrum是什么,和瀑布开发有什么区别,有一个很好的框架概括——

角色Roles
仪式/会议Ceremonies
产物Artefacts

(图片来源:https://www.visual-paradigm.com/scrum/what-are-scrum-ceremonies/)

其中,冲刺会议(Scrum Ceremonies)就是通过4种不同的交流方式,来解决上面三大问题:

如何确保开发期间有清晰的需求
团队如何及时沟通并推进进度
如何有日常反思保证团队的可持续发展
这些会议,不是流程,也不是为开会而开会。这恐怕也是他们在英语中不叫Meeting,而叫Ceremonies(仪式)的原因吧。

Scrum会议前期准备:需求明晰会议(Backlog Refinement)

为了方便大家思考/想象,这里以小明给女朋友准备6月礼物为例。在女朋友的产品需求池Product backlog里,可能会有如下需求:

我想要有安全感;
我想要有一个惊喜;
我想要有一个包。
我可以负责的告诉你们,这类不清晰的需求在没有完善之前都应该丢在需求池里面,清晰以后才可以开始产出。

当然考虑到小明的求生欲和实际操作的复杂程度,他需要绞尽脑汁和女友讨论出具体几个需求。这个确认需求及其优先顺序的过程/会议, 就是Backlog Refinement。

这个过程中你会发现她并不知道自己要什么。或许可能知道,但并不愿意直截了当的告诉你。

很多客户也是一样的。

作为Product Owner, 总之你不要逼他们,你要引导。

同时记住:你认为的需求并不一定是真的需求。

这个过程中,Product Owner只负责理解客户需求,不提供解决方案。

通过沟通,很(if you)快(are lucky),你的需求就会清晰起来。假设以下是排到了优先级别的需求。

作为你女朋友,我希望可以XXX,这样我就可以有安全感
作为你女朋友,我希望可以XXX,这样我就可以有很多安全感
作为你女朋友,我希望可以XXX,这样我就可以有更多安全感
作为你女朋友,我希望可以XXX,我会感动哭
作为你女朋友,我希望感受到类似XXX,我会觉得超级惊喜
作为一个有品味的女子,我想要有一个XXX的包,这样我会觉得XXX(XXX的位置,作为女生,我还是编不出来……)
接下来,冲刺就可以开始了……

如何掌握核心4大Scrum会议的精髓

图片来源:https://www.visual-paradigm.com/scrum/what-are-scrum-ceremonies/

1. 冲刺计划会(Sprint planning): 万事俱备,只欠冲刺

这是第一场真正意义上的Scrum会议。Team、Scrum Master、PO坐到一起,规划冲刺的内容。作为软件开发项目,进入规划冲刺的用户故事,用户故事应该已拆分完成,并且完成了视觉设计。在冲刺的过程中,任何人不能单方面擅自变更冲刺内容。

会议目的:通过预计用户故事,确定在这个冲刺中的迭代目标。

与会者:开发团队,scrum master,产品负责人

时间:冲刺开始时。

持续时间:通常每周一小时的迭代。例如:为期两周的冲刺将在两小时的计划会议上开始。

会议准备:产品负责人已经排好优先顺序

产物: Sprint Backlog

在以上的案例中,小明经过衡量自己的钱包时间和理解力,决定选用这2个故事:

作为你女朋友,我希望可以XXX,这样我就可以有安全感 (故事价值:13)

作为一个有品味的女子,我想要有一个XXX的包,这样我会觉得XXX (故事价值:8)

并且这2个故事经过沟通,需要有接受标准Acceptance Criteria, 即完成到什么样的程度,算是满意。一般是用可以量化的标准,而不是看心情。

所以这个会议的魅力在于,沟通清楚团队自身的能力和让用户清楚自己到底需要什么。接受标准的提出,也会让测试在一开始就有清晰的方向。

2. 每日站会(Daily stand up):有事早奏,无本退朝

这样做的意义在于:让整个团队清楚地知道在这一个冲刺周期内各项任务的进展,所有任务是否能够按时完成。

与会者:开发团队,scrum master,产品负责人。

时间:每天,通常在早上。

持续时间:不超过15分钟。不要预订会议室并坐下来站起来。站起来有助于缩短会议时间!

敏捷框架:Scrum和看板。

Daily Scrum看上去像是对女友的每日汇报——

我昨天去了哪里;
今天打算去干吗;
你有什么不开心我来让你开心一下;
每个团队成员需要回答的问题,真的是极好的吾日三省吾身——

你昨天完成了哪些工作?
你今天计划做哪些工作?
目前的困难及障碍?
这个会议的魅力是,让团队每日有一个沟通的习惯,有任何问题都可以及时解决,甚至调整计划。同时,这个会议最重要的注意事项就是要短,平,快,不要让15分钟变成讲故事或者长篇大论。Scrum Master负责消除团队面临的障碍。

3. 产品展示会Demo:见天见地,见客户

这个会议最重要的工作是功能和成果演示,验证用户故事的实现场景,并接受评价。

参与团队:开发团队,scrum master,产品所有者

可选:项目利益相关者

时间:冲刺或里程碑结束时。

持续时间:30-60分钟。

团队应该只展示那些符合“完成定义”的事项,也就是全部完成,不需要再做工作就能交付的成果。这个成果或许不是完整的产品,但至少是一项完整的、可以使用的功能。

比如,小明在两周内完成了第一个关于安全感的故事,给女票买了一款旅行意外险,只要她点头就当日生效。

因为时时和女友沟通需求和确认期待,这个充满浪(cao)漫(dian)的用户故事和解决方案正好是这个女友的需求。并没有什么特别的惊吓。

第二个买包的故事因为女友对于颜色还没有选好,被延期到下个冲刺。

反思会(Retrospectives):

冲刺回顾会一般在本次迭代发布之后的第二天或当天下午召开,会议时间最好不做具体的限制。

与会者:开发团队,scrum master,产品负责人

时间:迭代结束时。

持续时间:60分钟。

技术总结

作为一个团队,要让这个冲刺回顾过程有效,团队需要相互信任。
必须记住基于项目和技术问题的讨论和争论;对事不对人,不能把技术和业务讨论牵扯到人身攻击上去;
大家要对自己的流程和结果负责,要集思广益,共同寻求问题解决之道。
最后,团队确定一个最值得改善的地方,将其设定为下一个冲刺迭代的首要任务。

一个Scrum中的每个会议要怎么安排

这四个冲刺会议出现在每个冲刺中,渗透到了计划(Planning), 执行(Implementation), 产品展示(Review)和复盘(Retrospective)的每一个环节。类似于一个小瀑布开发,但因为每个用户故事都做了合理分割,不会区分特定的开发和测试阶段。同时,团队之间又会有充足的交流和反思。

从Salesforce看,如何理解并设计CRM系统?

为了设计好该类型的产品,特地去研究并分析了该领域的巨头产品——Salesforce,通过分析该产品的设计逻辑和思路,对自己的产品产生一起启发和思考,并且在实际设计过程中面临的一些问题也同时分享出来,以期给大家一些启发。

为什么是Salesforce

对B端产品接触较少的人可能对Salesforce不太了解,但是只要涉及到B端,一定会提到Salesforce这个B端领域的巨头,特别是国内的B端产品或多或少都收到Salesforce的影响。

根据互联网女皇玛丽·米克尔最新发布的2019年互联网趋势报告:Salesforce公司以1250亿美元市值牢牢占据B端领域市值第一的地位,并且在全球互联网企业市值中排名第11位,力压我们熟知的Uber、Booking、美团、百度等公司。

是什么支撑起了Salesforce如此高的市值?

抱着研究和为自己产品找想法的目的,试用了Salesforce的免费试用版,顺便说一句Salesforce提供长达30天的免费试用期,并且开放所有的功能,足以看出Salesforce的自信和开放程度。

Salesforce总体的设计逻辑

由于Salesforce已经是一个非常完整的生态,涉及到企业的方方面面,因此本文只分析Salesforce的CRM,及销售管理系统。Salesforce整个产品的设计是任务和目标导向的,从主页的设计就可以看出,Salesforce在分析公司时,采用如下的公式:

业务流=目标+任务

先制定整体的业绩目标,然后目标通过时间段拆解成每个阶段甚至每天的任务,任务则可以拆解成具体的客户,而客户又来源于漏斗:潜在客户→业务机会→联系人→客户。

如下图所示:

通过这种方式,Salesforce将不同公司的销售业务都抽象出共通的模型,从而设计更加通用的形式。不得不说,Salesforce对业务的拆解比国内大多数同类型公司更加细致和用心。

从菜单导航看Salesforce对销售进程的理解

首先看菜单栏,和一般同类型的产品相比,采用比较少见的横向菜单布局,从视觉上对用户更加友好。

并且,每个模块下拉菜单都只有新建或者历史记录两栏。对比国内的CRM产品会在下拉菜单中加入很多子栏目,Salesforce设计更加简洁,尽量把功能都放在一个页面里,通过合理的布局让用户减少点击的操作步骤。并且,当用户习惯了该产品之后,会发现想要新增内容会非常方便快捷。因为新增对于销售是一个比较高频的需求,不管是新增客户还是任务等。

从菜单导航设置来看,Salesforce对整个销售的各个进程考虑的非常全面。

从客户设置就可以看出,Salesforce将客户分成客户、联系人、潜在客户。

从功能设计可以看出,三者的区别是:客户是已经确定有交易关系的主体,而一个客户会对应多个联系人——即一家公司会派出多个员工和其他公司接触。比如会从一般的业务人员到部门领导甚至到公司高管,Salesforce充分考虑到现实商业接触中多层级的接触模式,因此这方面考虑的还是非常细致的。

如下图所示:

潜在客户则是和公司没有确定正式的合作关系,但是已经有初步接触有发展成客户前景的其他公司。

由于公司刚接触的时候往往只会派一个人进行初步接触,所以这里没有设计多个联系人情况。当和潜在用户接触时,Salesforce对该类型事件主要抽象成两个模块:进程状态和任务事件,这也符合绝大多数公司做市场时候的需求。

Salesforce提供仪表板的功能来监控业务指标和分析销售进程,这也是国内CRM产品比较少使用的形式。

在仪表板中,Salesforce关注的数据指标主要包括:每个阶段的销售额;salesforce定义的销售阶段包括:qualification(可以理解成接触阶段)、need analysis(评估阶段)、negotiation(协议阶段)、closed won和closed fail(交易成功和交易失败),以及交易成功和交易失败的客户来源和具体客户。可以看到,也是以完成业绩目标为导向,来分析完成和失败的原因。

总结

总结一下:Salesforce在设计CRM产品时,首先从大的维度定义产品要实现的目的,在这里就是完成业绩目标,然后通过将目标拆成每阶段的任务——就是获得足够多的客户数量。

而客户则来源于层层的转化,通过这种方式,产品的逻辑和架构逐渐清晰,也为接下来设计自己的产品提供了思路。

设计自己的CRM产品 1. 如何分析并找到核心需求?

既然分析完了Salesforce产品,为什么要先分析需求?

首先,上述的Salesforce产品,是分析了大量公司真实的业务需求,包括其他产品的思路,从而提炼出最核心的需求设计成这种形式。因此,设计产品的核心还是要从需求出发,分析并找到核心的需求,才能找到真正的高效的业务流转方式。

B端产品需要和大量的一线业务人员沟通需求,确定他们的痛点和难点,而由于这些业务人员大多是从自己的视角出发,一碰到问题就容易产生新的想法,因此这种需求往往是“拍脑袋的”。

而作为产品经理,需要根据业务人员所说的需求抽丝剥茧,找到需求的共同点,从而提炼出核心需求。B端产品面临的难点往往是定制化和通用性的取舍,一方面是要根据业务人员的实际需求设计产品,另一方面则需要抽象出通用和共同的东西,形成一定的通用性组件,从而实现产品的良好的可拓展性。

这里推荐需求分析的PSP方法:即P(Person,角色)、S(Scenes,场景)、P(Paths,路径),下面通过一条具体的需求来说明如何进行分析。

首先,这条需求非常不明确,主要体现在没有说明如何录入和查看哪些信息,这时候就需要和一线业务人员进一步明确,查看的是哪些客户信息。

当明确完之后,需要确定录入的方式是通过手动录入,还是其他接口来自己导入,后续和小李沟通细化发现是通过上一步筛选出来的用户。因此,可以通过对接上一步产品的数据库,来实现数据的自动导入,并且增加手动录入和修改的功能,防止数据有错误。

因此,该需求的核心点是:快速确定客户信息,因此通过自动导入比手工录入和批量录入都更能解决问题。

同时,通过PSP方法,需要明确不同角色的使用场景和路径。在该需求中,主要涉及到管理员、销售两种角色,录入功能应该只针对销售,因为他们是距离客户最近的人员,第一时间会了解到客户的新的信息。而修改功能应该只针对管理员,因为他们负责管理销售,因此他们有权修改客户的进程等相关信息。

2. 设计产品的过程中需要注意的三个问题

在确定完核心需求并确定了产品的基本架构和框架之后,接下来再具体设计过程中还需要时刻注意以下几个问题,从而设计的产品有更大的合理性和可拓展性。

1)数据从哪里来,到哪里去?

乍一看很像哲学家苏格拉底所说的“从哪里来,到哪里去”的哲学问题,但是这其实也是设计该类型产品的一个底层逻辑。

C端的产品数据是明确的来自用户,而B端产品的数据往往来源于其他和系统和产品的传输,因此明确清楚系统的数据从哪里来,以及如何流转是设计该产品的第一步也是最基础的一步。

拿自己设计的系统为例:由于本系统是针对客户设计的销售管理系统,因此最重要的客户数据来自于H5和小程序收集的客户信息,包括客户自己填写的手机号和其他基本资料。

因此,首先要和技术确定开发相关的接口去接收和传递数据到系统中。当数据进入到系统中后,要确定数据的流转规则,也就是先后顺序和对应关系,本系统采用的是三级分配的原则,也就是数据到最终的销售和经过三层的分配,如下所示:为了设计好该类型的产品,特地去研究并分析了该领域的巨头产品——Salesforce,通过分析该产品的设计逻辑和思路,对自己的产品产生一起启发和思考,并且在实际设计过程中面临的一些问题也同时分享出来,以期给大家一些启发。

为什么是Salesforce

对B端产品接触较少的人可能对Salesforce不太了解,但是只要涉及到B端,一定会提到Salesforce这个B端领域的巨头,特别是国内的B端产品或多或少都收到Salesforce的影响。

根据互联网女皇玛丽·米克尔最新发布的2019年互联网趋势报告:Salesforce公司以1250亿美元市值牢牢占据B端领域市值第一的地位,并且在全球互联网企业市值中排名第11位,力压我们熟知的Uber、Booking、美团、百度等公司。

是什么支撑起了Salesforce如此高的市值?

抱着研究和为自己产品找想法的目的,试用了Salesforce的免费试用版,顺便说一句Salesforce提供长达30天的免费试用期,并且开放所有的功能,足以看出Salesforce的自信和开放程度。

Salesforce总体的设计逻辑

由于Salesforce已经是一个非常完整的生态,涉及到企业的方方面面,因此本文只分析Salesforce的CRM,及销售管理系统。Salesforce整个产品的设计是任务和目标导向的,从主页的设计就可以看出,Salesforce在分析公司时,采用如下的公式:

业务流=目标+任务

先制定整体的业绩目标,然后目标通过时间段拆解成每个阶段甚至每天的任务,任务则可以拆解成具体的客户,而客户又来源于漏斗:潜在客户→业务机会→联系人→客户。

如下图所示:

通过这种方式,Salesforce将不同公司的销售业务都抽象出共通的模型,从而设计更加通用的形式。不得不说,Salesforce对业务的拆解比国内大多数同类型公司更加细致和用心。

从菜单导航看Salesforce对销售进程的理解

首先看菜单栏,和一般同类型的产品相比,采用比较少见的横向菜单布局,从视觉上对用户更加友好。

并且,每个模块下拉菜单都只有新建或者历史记录两栏。对比国内的CRM产品会在下拉菜单中加入很多子栏目,Salesforce设计更加简洁,尽量把功能都放在一个页面里,通过合理的布局让用户减少点击的操作步骤。并且,当用户习惯了该产品之后,会发现想要新增内容会非常方便快捷。因为新增对于销售是一个比较高频的需求,不管是新增客户还是任务等。

从菜单导航设置来看,Salesforce对整个销售的各个进程考虑的非常全面。

从客户设置就可以看出,Salesforce将客户分成客户、联系人、潜在客户。

从功能设计可以看出,三者的区别是:客户是已经确定有交易关系的主体,而一个客户会对应多个联系人——即一家公司会派出多个员工和其他公司接触。比如会从一般的业务人员到部门领导甚至到公司高管,Salesforce充分考虑到现实商业接触中多层级的接触模式,因此这方面考虑的还是非常细致的。

如下图所示:

潜在客户则是和公司没有确定正式的合作关系,但是已经有初步接触有发展成客户前景的其他公司。

由于公司刚接触的时候往往只会派一个人进行初步接触,所以这里没有设计多个联系人情况。当和潜在用户接触时,Salesforce对该类型事件主要抽象成两个模块:进程状态和任务事件,这也符合绝大多数公司做市场时候的需求。

Salesforce提供仪表板的功能来监控业务指标和分析销售进程,这也是国内CRM产品比较少使用的形式。

在仪表板中,Salesforce关注的数据指标主要包括:每个阶段的销售额;salesforce定义的销售阶段包括:qualification(可以理解成接触阶段)、need analysis(评估阶段)、negotiation(协议阶段)、closed won和closed fail(交易成功和交易失败),以及交易成功和交易失败的客户来源和具体客户。可以看到,也是以完成业绩目标为导向,来分析完成和失败的原因。

总结

总结一下:Salesforce在设计CRM产品时,首先从大的维度定义产品要实现的目的,在这里就是完成业绩目标,然后通过将目标拆成每阶段的任务——就是获得足够多的客户数量。

而客户则来源于层层的转化,通过这种方式,产品的逻辑和架构逐渐清晰,也为接下来设计自己的产品提供了思路。

设计自己的CRM产品 1. 如何分析并找到核心需求?

既然分析完了Salesforce产品,为什么要先分析需求?

首先,上述的Salesforce产品,是分析了大量公司真实的业务需求,包括其他产品的思路,从而提炼出最核心的需求设计成这种形式。因此,设计产品的核心还是要从需求出发,分析并找到核心的需求,才能找到真正的高效的业务流转方式。

B端产品需要和大量的一线业务人员沟通需求,确定他们的痛点和难点,而由于这些业务人员大多是从自己的视角出发,一碰到问题就容易产生新的想法,因此这种需求往往是“拍脑袋的”。

而作为产品经理,需要根据业务人员所说的需求抽丝剥茧,找到需求的共同点,从而提炼出核心需求。B端产品面临的难点往往是定制化和通用性的取舍,一方面是要根据业务人员的实际需求设计产品,另一方面则需要抽象出通用和共同的东西,形成一定的通用性组件,从而实现产品的良好的可拓展性。

这里推荐需求分析的PSP方法:即P(Person,角色)、S(Scenes,场景)、P(Paths,路径),下面通过一条具体的需求来说明如何进行分析。

首先,这条需求非常不明确,主要体现在没有说明如何录入和查看哪些信息,这时候就需要和一线业务人员进一步明确,查看的是哪些客户信息。

当明确完之后,需要确定录入的方式是通过手动录入,还是其他接口来自己导入,后续和小李沟通细化发现是通过上一步筛选出来的用户。因此,可以通过对接上一步产品的数据库,来实现数据的自动导入,并且增加手动录入和修改的功能,防止数据有错误。

因此,该需求的核心点是:快速确定客户信息,因此通过自动导入比手工录入和批量录入都更能解决问题。

同时,通过PSP方法,需要明确不同角色的使用场景和路径。在该需求中,主要涉及到管理员、销售两种角色,录入功能应该只针对销售,因为他们是距离客户最近的人员,第一时间会了解到客户的新的信息。而修改功能应该只针对管理员,因为他们负责管理销售,因此他们有权修改客户的进程等相关信息。

2. 设计产品的过程中需要注意的三个问题

在确定完核心需求并确定了产品的基本架构和框架之后,接下来再具体设计过程中还需要时刻注意以下几个问题,从而设计的产品有更大的合理性和可拓展性。

1)数据从哪里来,到哪里去?

乍一看很像哲学家苏格拉底所说的“从哪里来,到哪里去”的哲学问题,但是这其实也是设计该类型产品的一个底层逻辑。

C端的产品数据是明确的来自用户,而B端产品的数据往往来源于其他和系统和产品的传输,因此明确清楚系统的数据从哪里来,以及如何流转是设计该产品的第一步也是最基础的一步。

拿自己设计的系统为例:由于本系统是针对客户设计的销售管理系统,因此最重要的客户数据来自于H5和小程序收集的客户信息,包括客户自己填写的手机号和其他基本资料。

因此,首先要和技术确定开发相关的接口去接收和传递数据到系统中。当数据进入到系统中后,要确定数据的流转规则,也就是先后顺序和对应关系,本系统采用的是三级分配的原则,也就是数据到最终的销售和经过三层的分配,如下所示: