你知道厨房的学徒吗？我在一部美食漫画里看到了厨师学徒的工作内容，除了基础的打扫卫生之外，还需要将食材准备好，包括清洁， 加工，装盘等等。

　　所以我们的设计师同学除了将废弃方案帮助开发过滤掉，还得像助理一样帮助开发把所需要的材料准备好，这其中就包括切图与标注。

借助由标注和切图构成的通道，设计师和开发之间的协作才会通畅，不会出现反复询问这里几个像素，哪里什么颜色的问题。

　　同样是作为开发的守卫，产品经理的通道又是由什么构成的呢？

　　产品经理的“标注”

　　当然，我们需要向开发人员输出的产物，不会只有需求文档，但最重要的便是“需求文档”。

　　我们把需求文档理解成设计师的标注，也许会比较困难，换个思维，需求文档所要达到的目的与设计师的标注相同，是否能够更容易理解呢？

这是一个段子，也是我最近才看到的一个真实的段子：

产品经理：你把talkingdata统计加上。

程序员：写个文档要加哪些统计。

产品经理：好。

文档：

1.talkingdata增加全局统计。

2.统计日活，留存，使用时长。

The end

程序员：…

这是另一个段子：

产品经理：老板，这个是我这个版本想做的功能，我们要像微信一样，让用户自己上传视频文件。

老板：要做多久。

产品经理：我让开发他们10天做完，开发那边说没问题。

老板：这个功能量不少，难度也不小，开发能做完吗？

产品经理：做不完，那就是开发技术不行，反正我的需求已经给他们了，他们也答应了10天做完。

文档：

1. 发布流程增加上传视频的功能。

2. 可以把手机本地的视频文件上传到服务器。

我的读者，你们怎么看这两个段子？

作为守卫而言，产品经理与开发之间的通道完全破碎了，不仅不能减少研发成本，反而不断的增加研发成本，最终的结果就是沟通障碍。

人们的本能是趋吉避凶的，程序员也遵从这个定理，明明知道需求有问题，为什么还要去做？

拖着，没做，是因为你没写需求，最后大不了被骂一顿。

最终被踢出局的不会是程序员，而是这位完全没有意识到守卫职能的产品经理。

这是一份我学生写的需求文档，实际开发过程中，便可以起到标注的作用。

我相信，现在大部分的产品经理没有意识到“守卫概念”，也可能这只是我的一种个人认知。

但至少不要坚持做一位“坑经理”，向设计师学习，将我们起到标注作用的需求文档发挥出他应有的价值。

　　关于信息传递

在团队协作过程中，我们需要将一条信息多次传递，而每一次都会出现信息丢失以及变形。

产品经理与团队中的其他角色的关系，并不是上下关系，我尤其要强调这一点，产品与设计也好，与开发也好，我们都是属于不同的部门，只是在一个相同的项目组里而已。

我们的关系更倾向于任务的前后关系，产品经理在项目的开始位置，接触最多的信息，过滤最多的信息，然后将自己的思维传递给下一个环节，可能是设计师，可能是开发。

每一个环节都会比下一个环节收获更多信息，一层一层过滤下来，最终到测试手上的产品才能是最合适的产品。

而这中间最大的风险地带便是我们信息传递的通道。

我们理所应当的认为设计师就应该要标注，要切图，但到了自己身上时，却会排斥需求文档的撰写，甚至极不耐烦。

也许你的想法真的很好，但如果不认真对待想法的传递，我其实想建议你换个行业。

当我们在抬头仰望遥远的未来时，当我们大谈用户需求时，当我们考虑市场痛点时，你没有发现，谁才是我们产品经理第一批用户？