如何给技术及设计提需求.pdfVIP

如何给技术和设计提需求 ？ 产品看似掌控大局 ，但是很多事情都不是自己 完成的 ，发需求成了产品经理的日常 ，给设计发 ， 给技术发 ，给策划发… 需求发出去之后 ，收回来的东西不满意也是常有的事情 ，于是吐槽也成了日常 ，然而吐槽也并没有 什么卵用… 金玉良言 ：所有问题都是自己的问题 ！别吐槽 ！想想我能做什么 ！ 提需求的3大要点 下面说明3个提需求的要点 ： 一、需求是人做的 ，人心是肉长的 需求之所以复杂就是因为需求是人来做的 ，如果是机器来做就太简单了 ：只要输入正确的命令 ，机 器会准确的帮你实现好。 有了人的存在 ，需求就会存在delay、错误、品质不够等问题。 但这并不 成为需求实现不理想的接口 ，为何别人的需求可以加塞在你的前面 ？为何别人提的需求 实现品质就比你的高 ？ 同一个忙 ，你找陌生人 ，朋友 ，亲人来帮 ，其过程和结果肯定是不一样的 ！ 那你 不 让对方成为你的朋友甚至哥们 ，就要看你的本事了。 二、发需求的方式 我相信所有人都经历过这么一种场景 ： 你发了需求 ，但是对方没有看到 ，于是在交付的那天你什么都没有收到 ！ 别怪别人 ！怪自己 ！ 发需求的方式强烈 议2种结合 ：邮件+口头 邮件 ：很正式 ，内容完整 ，并且容易回溯 口头 ：最好是口头 ，因为消息和邮件是繁多的 ，很容易被忽略 ，但是语言的交流是印象深刻的。如 果无法实现口头交流 ，最好是通过IM再提醒一下 ，让对方明确的回复已经看到邮件 ，加深印象。 三、需求内容需要符合“SMA RT 原则” Specif ic——需求必须是具体的 ，明确的 ，别摸凌两可 Measurable——需求必须是可以衡量的 ，要 够评价他的好坏 At t ainable——需求必须是可以达到的 （这个也是对方经常拿出来的理由 ，遇到之后参见要点一 ） Relevant——需求必须和其他目标具有相关性 ，没有意义的需求是浪费时间 ，要告诉对方意义何 在 T ime-based——需求必须具有明确的截止期限 SMA RT 原则非常实用 ，如果想详细的了解这个原则 ，可以点击这里—— SMA RT 原则 via MBA智库 技术需求怎么提 给技术提过需求的都有过类似的经历 ： 为什么需求这么简单 ，但是技术做出来的东西还是有问题 ？ 我的需求文档已经很详细了 ，为什么不按照文档里的来做 ？ …… 这些所有的不愉快往往都跟自己提需求的方式有很大关系 ，而不 只怪技术同学 ！ 下面就对比一下错误的提需求方式和正确的提需求方式 ： 错误的姿势 错误的方式 ： 1.脑袋里想好要什么 2.将想要的东西写成需求文档 3.将需求文档发给技术去做 4 .等结果 错误的方式往往都是错误的观念导致的。 错误的观念 ：技术是干活的 ，只需要按照我说的做就行了 ，不需要你自由发挥。 大部分给技术提需求的人都不是技术出身 ，对技术并不了解 ，如果技术沦为一个纯执行 ，那么就 成了“外行指导内行” ，何况技术部门又不归产品管 ，自然有很多矛盾存在。 另外 ，我们脑海中想要的东西写到文档中一定无法100%的还原 ，技术再去看这个文档 ，理解过程又 有一定折损 ，就导致我们想的和最终做出来的东西相差甚远。 核心问题 ：产品和技术之间信息是不对等的 ！每一步过程都有信息折损 ，导致了最终产出不理想。 正确的姿势 正确的方式 ： 1.不聊技术聊业务 ，先让技术同学充分的理解业务流程是什么 ，技术在业务中间的作用是什么 2.在技术同学理解业务的基础上共同讨论解决方案 ，列出可行的方案 3.业务人员和技术人员综合各种因素选择一种适合当前的“最佳方案” 4 .双方达成一致后再最后形成文档 5.文档中包含前端表现细节和后端流程图 （想了解文档怎么写可以百度一下“PRD” ） 核心问题改进 ： 让技术同学充分的参与进来 ，一同商量 ，确保在方向性上大家高度的保持一致 ！ 业务同学的解决方案不一定是最佳的 ，所以要发挥技术同学的优势 ，让他们也来出方案 ，讨论方案 。 不要在一棵树上吊死 ！方案细节不着急展开 ，先多出方案 ，然后再评估方案 ，确定方案 设计需求怎么提 说到设计就需要强调一下前文说到的“人心都是肉长的” ，设计人员非常感性 ，关系好图就做的好 ， 心情好图就做的好。 所以设计需求的重点不在于提需求的时间点 ，而在于平时关系和感情的积累 ！ 设计和技术的差异 下面把设计和技术来对比一下 ，让大家有一个直观的感受 ： 下面就是具体的建议了 ： 给设计足够的提前量 “这个需求今天就要 ！”这句话谁听到谁不