本文作者以其最近接手的产品为案例，复盘一次快速从0到1的系统级产品原型开发，并分享其中的心得。enjoy~
作为产品汪，理想中完美的一天是这样的：
早晨来到公司，确认各项功能进度，查收邮箱，和同事们在阳光正好的落地窗前讨论需求，你挥斥方遒，你势不可挡。再泡杯咖啡，根据计划设计今日要做的原型任务，准备好明日的工作内容之后下班。
晚上回家，看书学习，分析国内外竞品，最后怀揣着明媚的梦想安然入睡。
但啪啪打脸的现实也许是：
莫名其妙的项目直接砸到你脸上，缺乏了解更缺乏人手，老板一副“我不管你有什么困难，反正必须在Deadline前提交像样的原型/方案！”的表情。你历经撕逼、吵架、加班、心力交瘁，但依然不尽如人意。
对了，这才是常态。
认真回想历经我手的大大小小几十个产品，能给予充分时间好好琢磨推敲的幸事，概率几近于0（泪眼）。新产品也好，版本迭代也好，绝大多数都是在拉满红线的局面下，想（苟）方（延）设（残）法（喘）达成预定目标。
不少产品汪尤其是新手产品汪，恐怕对此尚不太理解和适应。节奏和经验的累积速度，实际上重在于实操。 So，今天咱就复盘一次快速从0到1的系统级产品原型开发。
以我最近接手的产品为案例——当一个从天而降的项目来势汹汹时，你可能遇到的真实的节奏、真实的困境，以及真实的收获。
简要产品背景如下：
系统规模：包括4个关联性子平台，形态是PC+移动端，共计6侧。主模块近200个。
周期：2周内必须给甲方1.0版。
合作模式：我做原型，另一搭档补充细节和简单交互。
个人时间管理：朋友公司的新项目，因此我必须在有限的下班后时间完成。
以下是个人的一些做法分享，不一定所有做法都正确或最佳，也欢迎有相似经历或者不同看法的小伙伴来探讨。
Ready ？GO！
1. 功能列表，是整体控制的利器
尽管该项目沙地暗坑不少，但由于在签合同时已拟定功能列表，算是优势之一。如果没有，功能列表通常也会是我第一份提交的文档。
一开始勾勒出需求范围，并尽快和干系人达成共识，是后续一系列发展顺利进行的重要基础。
格雷戈·麦吉沃恩《精要主义》有一句话印象颇深： 设定界限会带来自由。
定功能优先级，拿着它好沟通调整。
做需求原型，以此作为checklist避免遗漏。
控制整体进度，在功能列表上清晰标注，让所有参与人明白目标和进度以此降低沟通的时间成本。
一箭N雕啊。
切记不要直接打开Axure开始刷原型。没错，最终的输出是需求原型，或许还是工作量让你抓狂的原型，但磨刀不误砍柴工，时间如此紧绷压缩，一旦返工就会打乱阵脚，甚至付出远超预期的代价，得不偿失。
大力出奇迹的方式，此处真心不适用。
2. 需求原型，一层层抽丝剥茧地做
老规矩，按照优先级，而不是对着功能表从上到下做。遇到这类短周期+复杂的系统，处理需求上我有两个习惯。
2.1 功能列表，只标最！重！要！的功能模块
第一轮把核心页面建立起来，第二轮继续标注剩下范围里的最重要功能，第三轮、第四轮……以此类推。
就像画一幅画，从轮廓到细节层层递进。
万一灰常不幸地只来得及做第一轮（比如这次），那么，至少可以保证提交可用的V1.0成品。
优先级呢，多半处于动态变化。在这13天“从0到1”的日子里，每天我会发最新的版本给搭档，同时告知以下内容：
接下来我会开始做什么。
剩下的需求，预计自己多久可以搞定。
同时确认，优先级有没有发生变化。
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——
