零经验也能做企业端项目

希望伙伴,从项目开始,注意将所有资料(与项目相关的对话截图、邮件、文件、录音等)都放在一起,直到最后封存。一方面便于查找,另一方面便于自己复盘。

PS:为了能让更多0经验的伙伴学到更多的东西,接下来我将逐步细化。在此期间,给阅读带来不便请谅解。同时,也希望更多的人能分享干货,解决问题,而不是理论。这也是为什么许多书和文章看完了很爽,做还是不会做,因为你们读了太多理论。

0.沙盘推演


对于0经验的B端项目,最难的可能就是无从下手。而且如果是第一次合作的项目而言,可能只给一次机会。那么,如何利用当下条件做好这件事呢?

于是想到了沙盘推演,这四个字有很多定义,我的理解是战前模拟演练。记得原来在下五子棋比赛的时候,面对陌生的对手经常要在脑中模拟上百遍各种情况,只为了能找到一个赢的战法。

0.1 找棋谱

拿到的是订机票的合作项目,在与B端接触之前,看了看市面上两个知名的产品:携程和去哪儿。以小白菜的心态分别玩了2遍,然后用纸和笔去画了一个订机票业务。当自己不知道怎么做的时候,会向先人学习,就像学习先人留下的棋谱一样。

因为自己不容易集中精神,所以会经常只带纸笔手机找一个干净的地方去整理思路。视野内的事物越少,越容易专心做事。当然,每个人都有自己的办法,这个不拘泥于纸笔。

我是一个野蛮生长的产品,所以只会笨办法–实践。按照自己画的设计,假装是用户亲自去买机票试试,一路将自己的感受,想知道的信息以及问题都记录了下来,然后在对比已经上线的产品看看,别人是怎么处理的?为什么?

经过几次修复之后,仿真品已经初具模型了。

0.2 流程再造

因为我要做的是通过语音交互的方式来获取用户信息,并以语音的形式将结果告诉用户。所以,需要根据自己的需求将初始模型进行改造。

第一步:机械式。我一般是习惯将一个产品从逻辑层到用户层进行纵向拆分,然后在逻辑层上进行进化方向的拆分,第一步,只要求能从头到尾的走下来。

第二步:正常人模式。在机械式的基础上,会模拟一个正常人在不同场景下进行标准话式交互,以此来不断丰富逻辑。

第三步:调皮捣蛋式。在第二步的基础上,会模拟一个诚心捣乱的人来玩这个,比如:说着说着突然松手了,语音不全造成必要信息缺失等。

以上三步目的是尽可能的发现这个产品更多的问题,每一步到想不出来即可。

0.3 自我思辨

此过程主要是模拟两个小人来对话,试图通过多角度分析的方式,以简单好用舒适为核心,对流程再造后的模型进行剪裁和完善。比如:在查询结果,语音输出的情况下,因为受技术和交互方式的影响,所以要尽量言简意赅的同时还要满足用户核心需求。

如此,我就会问自己,没有什么信息你绝对不买这个飞机票?钱,还有什么?… 期间会发现用户在购买东西的时候是有一个很长的决策链,因为人脑是一个单线程CPU,同时只能处理一件事,因素间一定有优先级存在。

如此,经过沙盘推演,一定会有许多问题和自己的猜想存在,接下来就是寻求答案的阶段–收集信息。

1.收集信息


收集信息阶段,个人建议,不管你有没有经验最好都要从0开始,保持空杯心态。因为环境等因素一直在变,固守原有经验可能蒙蔽你的眼睛而看不到新生的变化。这个阶段,腾讯的伙伴做的比较好,他们有一个比较好的体系,大家可以多与同行交流,多学习。

两点需要注意:

1)自己先行
2)保持和一线业务人员及目标用户充分沟通

我一般喜欢问别人之前,自己先尽可能的了解清楚,然后有问题有针对性的去请教别人。一方面,锻炼了自己。另一方面,可以节约对方的时间。在询问对方的时候,要记得你的目的是获取信息,而不是去理论和争辩,就把自己当小白,专注自己眼前的目的,别人怎么评价你,是别人的事,你管不了,也没必要浪费时间。当一个能做好事情的小白吧,哈哈~

1.1 自己先行

拿到项目以后,我一般会去从各个方向进行调研,当然这也要看你的时间和目的。比如,当你想要在行业战略上布局,那你就要看清这个行业,以及你面前的这个企业是否为龙头,是否能为你打开整个行业做强有力的信任背书。

但是,当你没有这个时间的或者目的没有这方面需求的时候,你可以选择性的去调研信息。如果有可能,我还是挺建议大家做全,像CEO一样思考,甚至比CEO看的更清,虽然你不用去决策,但有时候你看的更远,会把产品生命力做的更长更有活力。而且在小公司,有可能CXO也会和你聊这些,因为你是一线,了解更多内幕。同时,在此过程中你会成长过多,甚至可以请教CXO来学习,丰富自己。不过如果不是CXO主动问你,你最好不要轻易说这些,可以留在心里做验证,因为什么你懂的,具体还要看你的环境哈。

1.1.1全局看

拿到一个项目,一般我会从各个角度去分析,每个角度都会有不同的收获。

举个例子:
玩地图的时候,可能都体验过缩放。以手机版的百度地图为例,当你无限缩小的时候,你会看见这个亚洲,这时候,中国就是一个整体,你会看到蒙古在上,蒙古的上面俄罗斯那么….大,一定是偷了咱们国家的地,哈哈。这时候你在把中国当作一个整体,去分析和它同等级的事物。

OK,来咱们放大,当你看到省市的时候,你能看到兰州,重庆,昆明…,再放大能看到区县…。到此为止,有没有人想过,为什么在看到区县的时候,看不到省市,看不到俄罗斯?

有人会说,不是一个地域级,百度地图就这样等等,想想你会看上海是否挨着俄罗斯么?但你会看到中国和俄罗斯挨着,上海在中国里面且不是在北边。

其实,这是基于咱们的目的和视野所限。

目的,当我们目的是只分析上海和俄罗斯的位置关系时候。我们只需要地图上显示俄罗斯和上海就可以,其他不希望标注,因为它们会让你眼花缭乱!与你的目的无关。随着我们的目的不同,会看到不同的区域(这个区域是泛化,可以是视野区域,可以是心里区域,可以是大脑区域等等)。

视野,我们的视野有限,而且处理复杂信息的能力也有限。所以我们需要将事物进行分层看待,从不同层次去看,有侧重点的去分析。(同时,从不同层次看有利于建立金字塔思维,因为大脑总是在不停的进行自动归类,当你给的信息过多,分析归类系统就会忙乱,你也会感到不舒服。具体可以看《金字塔原理》这本书。

下面,我们将整个项目作为一个整体进行全局看

  • 将这个项目扔到市场上

分析行业情况及发展趋势(整体分析)
逆趋势的项目未必是好项目;超前趋势的项目有诸多不测需要提前预防;落后趋势的项目虽然会有很多前车之鉴,但同时也可能是快被淘汰的;趋势中的项目前有借鉴后有参考,平行有诸多竞争,压力则稍大些,所以需要分析下全局的情况,这样我们才知道该注意什么,哪里需要着重,哪里需要剪裁。

1)分析发展趋势和与大趋势相符的龙头企业[横向分析]
分析发展趋势要多看历史变化,分析什么因素导致了历史变迁,少看分析家的个人观点,多看事实依据。分析龙头企业,借鉴经验(了解),学习(熟悉),逆袭(改进)。

2)分析行业上下游,看相互作用情况[纵向分析]
看上下游可以看到业务链是什么样的,相互之间的牵制关系又是什么,以及发展趋势。有可能你所做的东西,正在被上下游慢慢吃掉,比如中关村的柜台电脑零件售卖中间商,此时你还要做柜台么?你愿意也可以。

分析同行情况及发展趋势(局部分析)

1)看竞品公司,发展脉络(发展史等数据),公司间关系[横向分析]
2)看竞品,分析竞品优缺点并追其原因(竞品的优缺点可能是公司、产品经理、技术等因素导致,切莫光了解优点缺点就停止,因为有些缺点你可能不会出现,有些优点你也学不来),竞品间关系[纵向分析] ,有时候看竞品看多了,会发现一条Copy链,然后你只需要看源头就好了。

  • 把项目扔到公司内

向内:此项目对于公司内的影响:产品业务、资源(有时候B端业务做好了会带来资源置换)、其他(资金,团队士气[做了一个很有名的单子]等等)

向外:此项目对公司在外的影响:声誉、行业资源、竞争力、其他。会不会因为这个项目与B端发生变化,关系上、发展上等

1.1.2 局部看  (整理到此11.26 24:00)

层次分析:看你做的项目是否是B端的一部分,如果是,尽量整理出层次关系,例如订机票:

Untitled.png

  • 整体上

1)看此项目首尾连接情况
通过订机票的上链接,我就知道这个项目的目标人群是企业人员,同时通过对企业业务了解,发现他们这块业务是刚刚开始做,他们在这块业务是全新的等等情况。(当然,我说的是微信服务号上的,电话客服模式他们早就有了)

2)看此项目的一线人员
谁是订机票的一线人员

3)看整体性限制
比如订机票的业务整体基调就是正式、稳定、效率。

4)看此项目的涉及人员
比如这个项目:谁是决策者?谁是API提供者?谁是12580方的产品?谁是业务员?他们各自的负责范围是什么?决策范围是什么?最佳沟通方式是什么?他们在组织结构中是什么样?他们各自的职位和个人诉求是?等
项目相关人员的组织关系图很重要,可以让你第一时间找到最有效的人,快速处理你的问题。

5)看此项目之前已经存在的问题
这个多数直接找B端一线人员或者使用这个产品的用户处分别获得。

  • 局部上:

Untitled.png
将项目展开,如果复杂需要你做多层展开。

横向:
看模块间关系,牵制及影响
比如:查询机票和机票结果之间的关系,机票结果是否能回道查询机票,是不是比如有查询机票过程才能到达机票结果,查询机票对机票结果的影响是?比如查询机票环节的时间不对,机票结果中允许用户修改?等等

看模块间传递情况
比如:查询机票给机票结果传哪些信息?这些信息需不需要第三方获取,如果需要,在项目估期时候就要考虑第三方的不稳定因素,如果有连调,还要考虑连调造成的项目延期等等因素。

纵向:
看单模块内部情况
比如:查询机票需要从用户哪里获取到时间、地点、仓位等信息,在对话交流获取信息中,如果用户没给你时间、地点,你要先问那个?内部问答流程是什么?用户会不会有捣乱的情况或者喜欢性缩短说话?例如:5号,这个5号是这个月的?还是下个月的?

看单模块对外连接点
比如:收集完信息,最后一步再进入查询结果前需不需要让用户进行二次验证?等

看单模块影响质量的因素
比如:查询模块最后的信息准确率会受语音识别准确率、语义理解准确率等影响

到这里,是不是有1000个草泥马在心中跑过?为什么要这样?一方面,你只有比B端更了解业务,才能做出好的产品,另一方面,在这里过程中你会有很多疑问和不知,带着这些疑问和不知去问B端人员或者用户会更有收获。反而没有准备直接去问会收获很小,因为有时候你不问,对方也不会说,甚至有些他们都没想到等等。

1.2 找到核心,项目边界

这个阶段,要找到项目的核心是什么?什么是主要的?什么是次要的?项目要做到什么程度?时间给多少?验收人期望的结果是什么?

这个阶段主要是和各个相关人做博弈的时候,切记一定要尽可能的把需求确定下来,做到什么程度,做成什么样,越细越好,拍死了(你能确定多细,全基于你前面的调查和对业务的了解),以后谁要改,就让他们加时间(保护好你的技术、设计哥哥姐姐们的心情)。

1.3 充分交流
经过1.1的磨练,到此你已经有一定基础了,甚至是砖家了。此时,需要从头开始将这个业务流程和一线人员或者相关人对一遍,看看你调查的和他们实际操作的中间是否还有问题。不懂就虚心问,千万不要装明白,后面死的就是你。

2.项目实施

项目实施阶段,不同项目可能复杂度不一样。但只要抓住关键点,还是可以做好的。记住项目的管理核心是时间,任何的问题和变动都围绕时间而发展。不断的时间拖延,只会让团队感觉疲劳。如果想做更好,可以放下一个版本,让大家在心里有一个阶段性的休息。

2.1 版本剪裁

1.项目层分大功能版本。

在一定时间内,先划分出一个不超过60%总时间的基础版本,这个版本只留下核心功能,核心功能是对这个项目而言,没有这个功能则不能使用。比如:对于B端API平台,没有登录注册也能用,商务可以在后台配置,那么登录注册就可以后做等,只不过会让商务忙碌一阵。但是,如果API平台,没有API是不行的,这个就是必做功能。

之后,在划分阶段性版本,版本的划分仅对当下阶段情况而言最重要的优先。

2. 各版本内在进行小版本切分

此版本切分,尽量保持模块间低耦合(相互依赖低),尽量保持单人短时间可完成。这个目的在于快速沟通和测试。

我切的小版本基本上都是一个人1-3天,如此每天早晚会和相关人员及时沟通,看看是否有问题,保持及时沟通可以了解整体情况以及在初期就发现问题。项目管理或者产品经理,都是对项目和产品管理,而不是对人管理,人只是帮你较好的完成这个项目而已。PM在团队中主要是协调,使整体向既定方向发展,那么对于协调岗位而言,沟通是必要的。

此阶段,希望尽量粘死技术负责人:哥,这个能做吗?有其他办法吗?你看这样行不行?这个这么难,大概要花多少时间?…记住,只是调查,不是确定要做,所以不要给技术透露过多肯定的言词。

2.2 内部项目评审

内部项目评审的时候,我们最好按照“金字塔”模式(金字塔原理是本书,有兴趣可以看看)来叙述。先确认项目方向和核心是否正确,再确认顶层框架是否正确,再逐个结构展开,

细化。如此,内部评审人员可以分阶段听,有些人听完方向和核心就会走了。因为方向对了,核心对了,剩下的就是怎么走了,总体上不会偏移。

说到这里,有些人会说了,你前面划分不是白弄了嘛?其实不然,在你划分的时候,其实是你需要考虑所有资源的时候,划分完后,你可以很清晰的知道哪些必做,哪些不可做,哪些费时间,哪些问题可能会大,这样在评审的时候,让你更有自信来表达。否则,对方一问,你都没考虑过,只能打鼓脸冲胖子的自己臆断,为了保持自己不被看扁或者评审会上露怯。知己知彼,方能百战百胜,你需要比评审的所有人都了解全局才行。

内部项目评审是最终敲定要实现什么,以及谁负责配合哪部分,那个决策人对哪块内容负责等。记住你是协调人,不是决定人,所以,你要做博弈。当遇到和自己想法不一样的时候,如果你没有经验或者不是很确定,请记录下对方说的想法,并先尝试做做。如果做出来不错,那有可能是自己问题,如果做出来不对,就立刻分析不对的原因,并找到解决办法。最后,嘿嘿,当初谁说的来着?找TA,有理有据有气势,哈哈 (偶尔逗比一下,毕竟所有有人都希望做好这个项目)

评审会议结束之后,先解决会议遗留问题,然后重新整理,带着整体资料找技术聊。

2.3 可行性分析

继续粘着技术哥哥们,是们。在这里将项目总体概括性的和技术沟通下,看看其中还有没有潜在的技术风险,哪些需要自己去协调和调动资源。这里尽量让每个参与的技术都张嘴表达,让技术负责人尽量少评论和碾压。

这个环节的目的是让大家充分了解项目,以及对后面可能遇到的技术瓶颈,提前做出准备,同时,通过技术表达,对这个项目去区分哪些是突破型拳手,哪些是老司机,哪些是稳定输出,哪些是打酱油的。

这样,有利于你和技术负责人划分人员,如果你公司是民主自由的,你需要在关键点做出不合适的判断。在项目实施过程中,还要有针对性的对打酱油和突破性拳手增加沟通频率,突破型的容易进入挑战疯狂模式,需要及时鼓励,夸赞,引导。打酱油的需要看看进度和质量,鼓励,备份等,所有拳手要提前交代好,任何问题只要1个小时没有想法没有头绪,就立刻和技术负责人、CTO等有经验的人沟通,无解就要立刻和PM及时沟通,不是说明技术不行,而是要保证整个的进度。不要在一个点上浪费太长时间。做一个黑脸时间管。

将技术的所有情况了解以后,下来自己整理,然后与相关技术单聊,没问题以后,开始排期。

2.4 项目排期

1.先排基础版本,后续版本等基础班快完的时候再说。

在项目排期里,我建议评估时间为:1、2、5、8、13、20、30. 如果技术说要10天就记录为13天,因为时间越长,其实准确度越低,而且随着时间变长,中间不可避免的会插入及时问题。

他们说完以后,你自己记录时候,每个时间要乘以1.5(这个是风险系数(包含人员生病,因其他因素拖延等问题。这个系数根据团队自己衡量,我遇到比较好的团队能做到1.2,还有的要2.0),然后用OmniPlan或者其他工具排期。但是你对上说的总时间要X2。这个是你最大极限,若过程中发现团队超过了1.5,则需要你赶紧查找问题,及时解决。

2.排自己的进度表

项目排期,什么时间需要调度什么资源,什么时间需要检测,什么时间需要开始下一个版本等等。你要比技术至少提前2天开始。 自己的表自己看,同时记录每一天发生的重点事,作为自己的项目经验积累,比如12号,某人生孩子了,记录下,反思自己为什么没考虑到,等等。

如此,开始吧

2.5 保持沟通和效果追踪

每天至少要早晚各一次与相关人员沟通以及追踪效果,便于调整。

初期的沟通重点是项目,确保每个人都清晰,我们在做什么?我们做的目的?对TA有什么好处(鸡血、大饼…)?等等。

中期和中后期,重点在对各个人员情绪变化的追踪,及时关注每个人的健康情况等(你的伙伴在专心努力,你则要做好你能想到的事,如此才能保证整体的前进步伐)。

后期,重点在项目质量、人员心理变化、进度等方面

每个时期的重点都是动态的,根据自己的情况调整,发现问题尽早解决,不要拖…………..就好,另一个,如果你是PM,记住你就是打杂的,精通业务、心理、管理、沟通、情绪控制的专业打杂!哈哈,我一般都定位为小白心态,因为这样才不会蒙蔽眼睛,发现更多问题。

再说一遍,如果你是PM,你是做协调的,让整体保持良好运转。

3.测试和验收

测试是最费时间的阶段,同时又是很重要的阶段,因为需要通过测试来检测项目质量,可以透过忙碌之下,看到项目本质的东西。但是,测试往往又是恶心的阶段,同时又是比较难的阶段。

3.1 测试

这里我先简单说下测试方法:

理想条件测试:

1)全程测试

主要目的看能不能从头走到尾,哪怕是机械的,输入固定的。

2)全路径测试

是这将测试部分的流程图画出来,然后把每条路径都测试一遍,看看有没有问题。

3)全量测试

正常值,边界值,超边界值,临界值,意外值

举个例子:六位数字密码

正常值:238753
意外值:你是逗比吗?,999.88,iamcat,空格
边界值:999999,000000
超边界值:1000000,10000(位数)
临界值:999998,000001,99999,00000,空(值和位数)

测试不只是结果,测试时候将遇到的情况所感受的情绪放大,然后顺便做下用户体验优化。
下面来说说测试重点,每个项目的侧重点都不一样,所以要根据自己的目的而有阶段性的测试。
比如我的项目是对企业用户,所以测试是稳定优先级最高,然后是效率,最后是用户体验。
但这个也往往是用户的逆向感知,用户拿到手第一反应是好看吗?用着用着顺手不?卡壳不?速度反应快不?最后是,能不Crash吗?

所以,由于时间有限,我就将稳定设为99%稳定,效率在1秒以内,用户体验整体不需要操心费脑子,美观?呵呵哒,看时间吧。

为什么如此?你再美再操作简单,老Crash,你受得了?尤其是着急买机票的时候。好不容易稳定了,买个机票一个操作给我2分钟后才回应,起急不?

做任何事,想想重点是啥?哪些可以妥协,哪些不可以,不是你说了算,是用户说的算。

现实条件测试:

此时,让朋友或者目标用户替你试用,不要有任何指导和解释,只鼓励和倾听,如果面对面,观察下TA操作的停顿点,表情的变化(困惑?欣喜?),操作顺序是否如你所想等等。

3.1.1 小测试

在项目实施过程中,要按照小版本进行快速测试,目的是尽早发现问题,一方面是技术问题,一方面是项目设计问题,便于快速调整,以及后续版本避免同样错误。

3.1.2 阶段测试

一个小阶段(3-5个小功能)就要测试一下,看看问题,因为前面小测试,已经尽可能的测试好每个功能了,所以这次重点放在功能之间会不会有问题。

3.1.3 全局测试

将版本整体测试下,重点在整体的稳定性和反应速度上。

3.1.4 全民参与

一方面是发现BUG,另一方面是极速提升和收集用户体验反馈。

以上将的东西要灵活运用,不要机械化。比如:小测试时候,我就可以全量测试 现实测试,因为需要快速反应问题。如此,可能没有走过全路径,但是对于你当初的一些设计意图,可以得到快速的反馈。

做PM一定不要死,分析问题,找到合适的方法来解决就好,不要拘泥于条框,固定思维。

3.2 验收

验收是给别人看的,其实项目如何自己最清楚,但要记住底线是对的起自己。当然,混也能过去,但最终是浪费自己时间,在做一件没有意义的事。

3.3 复盘

好啦,交差了,爽吗?先别急休息,立刻复盘整个项目:
复盘对于下围棋的人可能不陌生,下围棋的人有时候下完了会在脑子里过一遍,没走一步都会问自己,如果不这么走会如何?尽管下了一盘,但复盘给他增长了100盘的经验。

在团队里复盘,通过不断问对方,引导对方让其发现问题所在。不对人进行评论,聚焦在项目上。角色分工为:主持人,讲述人,提问人。主持人负责维持复盘的稳定。提问人在倾听讲述人讲述项目的过程中,记录学习点、问题点,讲述完以后,提问他。讲述人是讲述项目的人。团队里每个人都要讲,所以讲述和设问的人是相对动态变化角色的。
(建议控制在5人左右一个小组,分组进行。)

讲述内容:

[1]项目目的
项目目的是什么?重点是?

这主要反应项目或者产品有没有讲项目与相关人员沟通到位,传递到位。

[2]结果对比
结果如何?自己预期结果是什么样?最后结果如何?满意吗?为什么?

这个主要看团队人员对于这个项目是否满意,对自己的结果有和感想

[3]叙述过程
讲述一下,自己从接到这个人物到完成的过程 (此过程不要打断讲述人,认真倾听,有问题请记录下来)

[4]自我剖析
在这个过程中,自己有哪些问题?(看看你记录的问题,他自己是否认识到了)

[5]众人设问
大家根据讲述人说的东西,进行设问。设问有两个目的,一方面是学习,一方面是引导。

比如他说自己在做A功能时候迷惑,
你可以问:“哪些事情感到迷惑?”
回答:“没有方向,不知道该怎么做,该做B呢,还是做成C就行了?”
问:“做B会怎样?”
回答:“做B的话,我不知道能能否让反应速度达到2s以内”
问:“哦,有哪些因素影响速度?”
…一步步的分解下去,直到找到原因,注意语气要平和,要慢,配合对方思考的节奏。如果你说的太快,会有种步步紧逼的感觉。也千万不要说“我觉得应该这么做,这么做”,如此你帮了他一次,下次还能帮么?永远?得让他自己明白,自己学会分解问题,发现问题本质,整理自己的思路等

[6]总结规律
主持人做一下简评,很客观的评价讲述人做的值得赞扬的部分。针对他不好的地方或者不足的地方,找个对应的主题希望他能抽空做下分享。比如他登录没做好,“XXX,表扬。。。。。,对了,看你能不能抽空就登录部分给大家分享下,相互学习下….”,为了讲好这个,他要做准备,并且通过分享与其他人交流,进一步弥补了自己的问题。

一般,优秀的伙伴,都有自知之明,知道自己问题会自己弥补。如果你发现某人一直都是油油滑滑的,做事也不好,还总包装自己,这样的人就要早点处理为好。人做事不好可以改进,人不行,那就是严重问题了。

总结以后,换下一个人继续讲述。

(团队版本)复盘的主旨:
对事不对人的进行剖析:

1)提问不带主称位
比如你怎么没做?,最好是这块怎么做好呀?

2)提问不能用反问,
比如:怎么不这样做?

3)人有优缺点
在交流中,体会伙伴的感受,设问事为了帮助他进一步深思。

复盘也可用于自己。《复盘》也专门有这本书可以看看。
在此送给想要提升自己的一句墨子的话:行有不得,反求诸己。

未经允许不得转载:艺宵博客 » 零经验也能做企业端项目

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册