极速实操|仅13天,包含4个子平台的大系统原型,以这种匪夷所思的方式实现了……

19 评论 10098 浏览 101 收藏 11 分钟

本文作者以其最近接手的产品为案例,复盘一次快速从0到1的系统级产品原型开发,并分享其中的心得。enjoy~

作为产品汪,理想中完美的一天是这样的:

早晨来到公司,确认各项功能进度,查收邮箱,和同事们在阳光正好的落地窗前讨论需求,你挥斥方遒,你势不可挡。再泡杯咖啡,根据计划设计今日要做的原型任务,准备好明日的工作内容之后下班。

晚上回家,看书学习,分析国内外竞品,最后怀揣着明媚的梦想安然入睡。

但啪啪打脸的现实也许是:

莫名其妙的项目直接砸到你脸上,缺乏了解更缺乏人手,老板一副“我不管你有什么困难,反正必须在Deadline前提交像样的原型/方案!”的表情。你历经撕逼、吵架、加班、心力交瘁,但依然不尽如人意。

对了,这才是常态。

认真回想历经我手的大大小小几十个产品,能给予充分时间好好琢磨推敲的幸事,概率几近于0(泪眼)。新产品也好,版本迭代也好,绝大多数都是在拉满红线的局面下,想(苟)方(延)设(残)法(喘)达成预定目标。

不少产品汪尤其是新手产品汪,恐怕对此尚不太理解和适应。节奏和经验的累积速度,实际上重在于实操。 So,今天咱就复盘一次快速从0到1的系统级产品原型开发。

以我最近接手的产品为案例——当一个从天而降的项目来势汹汹时,你可能遇到的真实的节奏、真实的困境,以及真实的收获。

简要产品背景如下:

  1. 系统规模:包括4个关联性子平台,形态是PC+移动端,共计6侧。主模块近200个。
  2. 周期:2周内必须给甲方1.0版。
  3. 合作模式:我做原型,另一搭档补充细节和简单交互。
  4. 个人时间管理:朋友公司的新项目,因此我必须在有限的下班后时间完成。

以下是个人的一些做法分享,不一定所有做法都正确或最佳,也欢迎有相似经历或者不同看法的小伙伴来探讨。

Ready ?GO!

1. 功能列表,是整体控制的利器

尽管该项目沙地暗坑不少,但由于在签合同时已拟定功能列表,算是优势之一。如果没有,功能列表通常也会是我第一份提交的文档。

一开始勾勒出需求范围,并尽快和干系人达成共识,是后续一系列发展顺利进行的重要基础。

格雷戈·麦吉沃恩《精要主义》有一句话印象颇深: 设定界限会带来自由。

  • 定功能优先级,拿着它好沟通调整。
  • 做需求原型,以此作为checklist避免遗漏。
  • 控制整体进度,在功能列表上清晰标注,让所有参与人明白目标和进度以此降低沟通的时间成本。

一箭N雕啊。

切记不要直接打开Axure开始刷原型。没错,最终的输出是需求原型,或许还是工作量让你抓狂的原型,但磨刀不误砍柴工,时间如此紧绷压缩,一旦返工就会打乱阵脚,甚至付出远超预期的代价,得不偿失。

大力出奇迹的方式,此处真心不适用。

2. 需求原型,一层层抽丝剥茧地做

老规矩,按照优先级,而不是对着功能表从上到下做。遇到这类短周期+复杂的系统,处理需求上我有两个习惯。

2.1 功能列表,只标最!重!要!的功能模块

第一轮把核心页面建立起来,第二轮继续标注剩下范围里的最重要功能,第三轮、第四轮……以此类推。

就像画一幅画,从轮廓到细节层层递进。

万一灰常不幸地只来得及做第一轮(比如这次),那么,至少可以保证提交可用的V1.0成品。

优先级呢,多半处于动态变化。在这13天“从0到1”的日子里,每天我会发最新的版本给搭档,同时告知以下内容:

  1. 接下来我会开始做什么。
  2. 剩下的需求,预计自己多久可以搞定。
  3. 同时确认,优先级有没有发生变化。

2.2 设计原型时,快速抓样本

把你脑海中的产品库,接触过的、设计过的、经手过的、使用过的、听说过的……全部扒出来,找到类似场景和可移植的元素。

你说抄袭也好,山寨也罢,我的目标就是在极短时间内熟悉该产品的真实使用场景。仅在2D的原型上脑补情境难免单薄,5D的使用体验带来的参考信息量就大多了。

总而言之,资源越有限,越得聚焦在关键事件上。尽量不返工,尽量不废话,尽量简洁明了地利用原型表达想法。压力重重,彼此的时间都非常宝贵。

3. 尽量避免因为工作量爆表,而找不熟悉的队友

多人协作可不是抓个壮丁就可以呐。尤其来势猛、节奏快的case。

找队友这事,一看平日的可用人脉(划重点:是可用,打战时能直接冲锋陷阵的那种),二看缘分。面前说了,很多事情并不都是大力出奇迹,搞到最后奇迹没出现,倒是悲剧和多米诺骨牌一样接踵而至,那就hin尴尬了。

譬如,你要花费时间和新队友磨合。TA的原型表达、工作习惯、沟通合作等等,瞬间和你无缝融合的可能性,其实蛮低的。

再譬如, 你要花时间检查确认队友的输出是否符合要求,万一没达到及格线,场面也挺尴尬的。

这回之所以我和搭档合作(虽然是第一次),有几个重要前提:一是,我们原先是同事关系,认识多年,熟悉工作风格。二是,他曾经看过我的设计原型,我对他的各方面技能也100%放心,足以让彼此有效预估,出现幺蛾子的概率自然降低不少。

4. 那些简单粗暴让人吐血的实战,告诉我们的事

4.1 完成比完美重要

精耕细作、匠人情怀,这很好,非常好,我丝毫没有否定其正面意义。然而,某个阶段或是特定条件下,产品狗的目标不是拿出一款惊天地泣鬼神的产品,而是,拿出一份能够让开发立马动工的、虽粗糙但可用的需求原型。

在我看来:只有完成,才有资格谈完美。

4.2 学会取舍

本系统包括4个子平台,共计PC+移动端有6侧,平台间存在千丝万缕的关联,在“2周”的时间红线下,1.0原型中我们主动放弃了其中一个子平台的移动端、以及不少不影响核心流程的功能及其细节说明(留着后续迭代实现,放心,路还长着呢)。

一个产品从无到有,必然是不计其数的权衡和博弈交织而成。学会取舍,学会选择,是握紧方向盘的有效方式。

否则……

“当我们丧失选择权的时候,别人会替我们作出选择。所以,要么慎重地选择有所不为,要么不由自主,任人摆布。”

4.3 累和压力,都是常态

不得不说,以这个系统的复杂性即便放在工作中,如此短的要求时间,也能把我折腾得够呛。更别提一边正常工作一边兼顾此项目,完全是白班+晚班的连轴转。

当你一天工作超过14小时,深夜面对复杂交错的功能点想流程、做原型,真是件特别恶心想吐的事情(如果有BGM的话,我觉得那一刻是《二泉映月》)。 更要命的是,一不留神神经紧张导致焦虑得睡眠,每天靠2大杯咖啡续命。

但也得做啊,摊手。

不是卖惨,所有职业均有它的不易之处。这些不过是产品狗极可能遇到的典型案例。很多一开始你觉得匪夷所思、完全不科学的任务,你最终都得想方设法连滚带爬地去实现、去完成,这,便是产品经理的关键使命之一。

用茨威格在《人类群星闪耀时》的鸡汤话说:“将无法实现之事付诸实现正是非凡毅力的真正的标志。”

用务实的话说:有艰难险阻,意味着你能获得提升空间。这么想想,是不是没那么累了?

好了,大致是这些。你们有遇到什么样“穷凶极恶”的工作任务不?说出来让大家开心开心,哦不,共同学习一下呗。

——END——

#专栏作家#

临公子,微信号公众号:临公子的后花园,人人都是产品经理专栏作家。一枚喜欢理财、健身、不爱灌鸡汤喜欢喝咖啡的产品汪。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Pexels,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 老板 能给个app功能列表么 👏🏻

    回复
  2. 怎么说呢 真不错!点赞点赞

    回复
  3. 我还以为你直接丢原型出来

    回复
  4. 很熟悉这样的场景,曾经的需求负责人,项目实施负责人,想转型做产品经理

    回复
    1. 我周围也有不少需求分析师转型做产品经理,其实需求负责人有不少优势呐。

      来自福建 回复
  5. 写得接地气,赞一个!

    来自重庆 回复
    1. 少年,我很欣赏你的眼光! :mrgreen:

      来自福建 回复
  6. 嗯?我刚才的手机评论好像都显示不出来?

    回复
  7. 确实如此。写的很赞,一直关注你公众号,不仅产品文写的好理财的也写很好啊。☺

    回复
    1. 谁让偶是一枚爱财的产品汪嘛(话说,上次偶写产品文已经是侏罗纪时期了,捂脸啊 😥 )

      来自福建 回复
  8. 赞同

    来自山东 回复
    1. Mua ~ 😉

      来自福建 回复
  9. 哈哈哈,辛苦了,临公子

    来自辽宁 回复
  10. 从“0”到“1”不求精细只求完成。赞

    来自上海 回复
    1. 因为每个阶段的目标,都不尽相同呐。

      来自福建 回复
  11. 很多时候真的完成比完美重要

    来自福建 回复
    1. 尤其在各种资源限制的情况下,先得把“1”立起来……

      来自福建 回复