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

本文作者以其最近接手的产品为案例，复盘一次快速从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 协议