只画原型的产品同学，我建议你这样做！

编辑导语：我们常常说“知易行难”，而作者却感受到“知难行易”，特别是对于刚入行的产品同学或者职场新人来说，非常容易忽略这一点。围绕这一点，作者用了三个小故事进行分析，希望能给你带来启发。

众所周知， “知易行难”和“知行合一”一样，都有着广泛的共识基础 。

毫不夸张地说，“知易行难”几乎都曾是每个人的座右铭，用以激励自己不要好高骛远，要踏实落地，勇于实践，提醒自己“知道”和“得到”之间还有两个字“做到”。

但是，最近这几天我深深感受到“知难行易”，而对于这个认知，刚入行的产品同学或者职场新人很容易忽略，但这十分重要。

上周发生的三个小事儿，分享给大家，希望也能带给你一些启发。

01 我们是小公司，我只画原型，不写PRD

这两年，我在面试应聘者时主要从三个维度进行能力衡量：专业能力、学习能力和协作能力。

专业能力意味着你当下的能力变现水平，学习能力则意味着你的未来拓展边界，协作能力则是更高纬度的整合力表现 。

上个月招聘了一个产品经理，工作经验也就两年左右，算是刚入门的初级产品，“野路子”、“产品不成体系”是我面试他时最大的感受，但愿意招聘他的原因也很简单：学习能力强，值得培养。

他逻辑还是很好的，思维也不错，说白了就是以往的产品工作没有人带，平台太小，没有系统化的学习基础，比如，他在需求传递时主要就是靠原型设计，几乎没有写过需求文档。

事实上，这是不少中小企业的共同特点，甚至很多规模不算小的团队在业务紧迫驱动下也没办法完全遵照流程，对产品经理的要求，只要能画原型完成需求传递就好了。

不夸张地说，在很多公司的很多时候，产品经理只输出原型真的是个常态。

但是， 原型设计也好，需求文档也罢，都不过是我们进行需求传递的重要载体而已 ，如何快速、高效地完成需求传递才是主要矛盾。

就拿我们公司来说，也是因为现在市场业务进展比较紧迫，流程也相应进行了优化，一般只需要产品经理只需要提供原型设计即可，需求文档根据自身情况来定，一般都是后期补写归档。

就在上周，这个新来的同事做好了一个原型设计，在我们内部评审时，我发现完全无法支撑需求的传递，比如，我问他数据来源、业务规则、交互逻辑等等，他总是有遗漏。

会后，我带着他复盘，他也感到很困惑，一直以来，他在原型设计上总是存在或多或少的问题，每次评审都有遗漏的地方。

怎么解决呢？

我告诉他，时间紧、任务重是客观原因，但不是瓶颈，从我们产品自身来说，能改进的地方仍然不少。

虽然我们只输出原型，但是我们要搞清楚“原型设计”和“需求文档”的各自价值， 原型设计更多的是体现界面和交互逻辑，需求文档则是对数据逻辑、字段规则的详细描述 ，这些是指导开发的重要依据。

明白了两者的各自侧重点，就可以找到融合的方法，比如，如果我们只输出原型设计时，我们就应该也必须把需求文档的核心加上去。

需求文档的核心是什么呢？

主要就是页面元素，就是对业务规则、数据输入输出的解释，如果我们有意识地做了这个工作，就可以只通过原型就实现需求的高效传递。

你看，同样只是做原型设计，理解的不一致带来的结果当然不一样，找到真正的因，比去执行更难，也更有价值。

所以，我把早些年的原型拿给他看，告诉他，把需求说明写在原型设计上是我们的原型设计规范。

事实上，根据镜同学的多年观察， 这种把原型设计和需求文档兼容的方式，开发反而最乐于接受 ，因为对他们的效率帮助最大。

02 半路兼职项目经理，大家不太配合怎么办？

上周还让另一个产品同学兼任了一个项目的项目经理，这个项目已经启动了两周，但是进展比较缓慢。
他向我反馈，大家工作不是特别配合，可能工作各有侧重，但整体协作效率很慢，沟通成本很高。
他是怎么解决的呢？

他很用心，对项目也很负责任，他逐一找每个人去聊，去沟通，去尝试协调解决项目的问题，但是效果不持续，时间一长大家又恢复了老样子。

后来他找到到我，反馈了很多问题，我和他一起去会议室仔细复盘，我们很快就找出了解决方案。

事实上， 每个问题都有一个本质解和N个现象解，我们有时候只是找到了现象解，并没有找到本质解 。

这个问题的解决方案也很简单，因为我们定位到了本质解，我们发现项目管理是脱节的，并且不够正式，所以大家责任意识不强。

于是，我们编制了多个项目文件，将原先匆忙上马的项目所遗漏的工作逐一补齐，比如，《项目成员分工明细表》、《项目进度规划表》等等。

然后，以群公告和邮件的形式主送项目成员，并抄送相关领导，嘿，你别说，效果立竿见影，大家对项目配合力度立马上升几个台阶。

所以，你看，找到问题原因比去执行解决的过程更难，也更有价值。

03 向领导沟通汇报的艺术

上周我们技术部门的一个Java开发工程师和我沟通，向我哭诉绩效被领导打了0.9，领导对自己的工作不是很满意，沟通存在严重障碍，问我解决方案。
我了解了他的基础情况：领导交代的工作他几乎都是在把详细设计搞完之后，到了最后一步才和领导对接，结果到点发现好像领导的想法又变了，领导还责怪自己对产品需求理解不到位。

导致的结果就是，详细设计需要重新再做，自己加班辛苦不说，还会因此拖累团队进展，让自己有苦难言，自己成了项目的“罪人”。

说实话，这个同学其实是很老实的程序猿，话也不多，逻辑思维能力也很强，但是过于喜欢钻研，有时候会分不清主次，浪费不少时间。

他询问我，要不要针对这次绩效的事儿，先找技术总监沟通下。

我的建议是， 在解决问题之前不要做任何解释，因为任何解释，哪怕他是客观现实，也会被当做借口，显得很苍白 。

那怎么解决呢？

先要找到问题的原因，通过分析发现他沟通是存在问题的，和领导的沟通断层了，有时候甚至一周都没有主动汇报过开发情况。

这才是问题的根本所在，所以，我建议他要主动寻求改变，在详细设计时先要列出一个设计大纲，并把这个设计大纲可能遇到的技术问题，都主动向领导汇报沟通。

一方面让领导帮你把控方向，另一方面让领导知道你的工作动态。

相信不少初入职场的同学主动或被动的都有这样的经历，有的是担心耽误领导时间，有的是不好意思，所以，总是在工作快结束时才进行汇报。

但这已经造成了沟通断层，保持强联系才是解决问题的本质解。

最后想说的是，“知行合一”都是每个职场人追向上的终极信仰，这当然值得欣慰和尊敬。

不过在这之上，咱们还应当有个基础的认知共识：知难行易。

正如，伟大的民主革命家孙中山先生所言：“行之非艰，而知之惟艰。”

先有“知难行易”，而后又“知行合一”。

也许，这才是永恒解。

#专栏作家#

产品大峡谷，公众号：产品大峡谷，人人都是产品经理专栏作家。七年B端产品经理，供应链物流与金融领域，擅长需求设计、业务指导、商业观察等。

本文由@产品大峡谷 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。