被公司拉到偏远地区封闭开发，进行了一周，每天超过12小时与技术呆在一起，有了难得机会和他们刺刀见红的“pk”，也算是有了充足的机会去了解这个团队，去锻炼我和技术沟通的能力。这几天总结的最重要的两个字就是“尊重”。
1.尊重1：我们的需求也需要站在技术的立场上。
产品经理有个常用短语叫做“需求”，或者前面加上两个字“用户需求”。我们常常会考虑用户想要什么，运营想要什么，希望他们用的爽，他们点赞。但是，这些需求最终落地是由技术实现的，你哪怕有吊炸天的想法和需求，也需要RD，一行一行代码敲出来。所以需求落地之前，也请站在技术的立场上进行考量，这就是第一个尊重。
我曾经被这样怒吼过：“你要不懂就别瞎说”。上文是这样的。我提了一个自认为很简单的需求，然后跟RD的经理说，这样其实挺简单的嘛。这显然是没有站在技术的立场上。技术在开发的过程中，不仅仅需要考虑交互，性能，还需要考虑数据库结构，基础架构等问题。如果产品经理肆意妄为，完全不顾忌技术的实现，就是对RD的不尊重。而尊重就要从最基本的了解开始。这对技术出身的人来说不是什么难事儿，但是对于很多非技术出身的产品而言就难得多。当然，我们去了解不意味着我们要上手写代码，我们要做的就是要明确技术的分工，了解基础的原理。例如：前端和后端工程师的分工，数据表结构搭建的原理等等，这些我就不展开说了。除了了解，我们还需要随时与技术保持沟通，从项目确立初期就与技术反复实现的逻辑和难度，再不降低用户体验和满足用户需求的前提下，寻找出最时候技术的方案。
2.尊重2：给出明确的需求。
明确的需求来自于三方面：明确的原型、明确的文档和文案、明确的语言表达。
我曾经陷入了一个误区，认为原型必须是高保真的，原型必须是炫酷的。接着我又陷入了一个误区，随便画几个框框，将区域划分明确就可以了。曾经看过有人讨论过我们究竟需要什么样的原型，我想说的是明确的原型。明确的原型包括，明确的跳转，明确的文案和相对明确的交互逻辑。
明确的跳转是指页面的跳转，点击完成、点击取消....等操作都要跳转至哪里，进入什么页面要明确。
明确的文档和文案：点击取消后是否要提示取消，保存成功之后提示什么。当然除了这些提示之外，各个字段的名称，各个字段的定义范围，例如，对于新用户的定义：注册但是没有已完成的订单单叫新用户，还是注册了只要下单管他成功与否都叫新用户。
明确的语言表达:在开发过程中需求的确认和需求的变更有时候是不可避免的，很多时候因时间的问题来不及更新文档，大家就要口头交流和确定一些事情，你一边更新文档，RD一边开发。结果发现修改的需求大相径庭。有个段子就是说，鲍尔默跟属下说你去给我买个诺基亚，结果第二天下属就把诺基亚给收购了。
明确的需求对RD的尊重在于，明确的需求使他们的工作量不会出现反复。开发出现反复是很常见的，有时候业务的突然调整，有时候老板的心血来潮（这个真挡不住）...但是什么东西都没调整就因为你文档说不明白，说的含糊不清，结果大家伙热火朝天的干了一番，最终你蹦出来说这不是我想要的，如果技术有把刀，定会砍死你。
因此明确的文档、原型和语言表达。1就是1，2就是2，没有模棱两可，没有这样也行，那样也行。讨论方案的时候可以有100种，但是最终方案只有1种。
3.尊重3：和他们在一起
当你手中有一个项目时，技术没离开之前，请和他们在一起。虽然有技术评审这种东西，但是在开发过程中，难免会遇到一些问题。这个时候就需要产品站出来确认问题，并评估解决方案。但这个时候你不在，回家了，大家熬夜为了这个项目出力，你回家睡大觉。想想RD们不给你画十万个圈圈么？
其实这三点都可以展开来说，如何了解技术，如何给出明确的需求，哪怕是和他们在一起战斗也是门艺术，你是不是要偶尔请大家吃个饭，别人在开发，你在那里玩游戏（那不如滚蛋回家）。但是，在做好每件事儿之前，先了解一下更为重要，每个人都有自己的方法论，但是道理都是一样的。尊重RD，尊重他们的工作，尊重他们的付出，这样才能得到别人的尊重。
最后的最后我想说，我喜欢和RD们在一起，他们是一群对事儿不对人的家伙，心直口快，单纯而可靠，甚至是可爱，会为了一个细节给你改上1天，也会因为你的愚蠢而破口大骂，也许是全公司里最可爱的一批人，为什么还不尊重他们呢？
网友评论