写给我的第一任助理

团队

以下是部门组织架构图。

产品工作

所有的工作都围绕着“需求”展开，作为需求方，我们要做的，就是向团队进行需求的解释和沟通。

两种方式：文档和语言

1制定需求

产品在各个阶段“目标——对象（用户）——内容——结构——细化”由粗到细地制定需求，并产生相对应的“需求文档”，这些文档就是用来解释需求，形式完全可以灵活多样（不仅仅是通常理解的文字文档，如果你能画漫画，说不定会更受欢迎~）。

2输出需求

需求文档将给所有项目团队的小伙伴们看，确保“用户们”能够通过文档理解你的想法。

然后用各种方法解释这些需求，确保所有人都理解需求的原意。

3管理需求

我们当然希望需求不要再有改动，可惜这只是一个美好的梦想。每个负责任的成员都会向我们提一些建议，有些建议会转化为新的需求。

新需求的管理工作更加繁琐，因为牵一发而动全身，改了某个部分可能对前后的工作都有影响。因此要尽量避免需求脱离你的控制，避免无限制的需求变动导致项目延期。

4项目

鉴于我对于小伙伴们各自工作一知半解的程度，通常不纠缠具体细节，我们只需要在项目计划中对时间节点和里程碑（某个时间完成了某件事情）进行跟进，大家会自己掌握工作进程。

小伙伴们在时间范围内完成了自己安排的工作，说明一切顺利。

避免（重要）

在完成文档的过程中我犯了个严重的错误。导致我把几个小时打出来的文字删去了一半。因为我试图向你描述清楚每一件事情，同时向你灌输一些专业严谨地内容。我试图让你读完这篇文章就变成专家了。

这是我极力避免的事情。

所以我特地在这里予以说明：

我建议你的每一份文档都适合一个外行人流畅阅读（起码能够读懂大部分内容）。因为你不一定每次都碰到相同知识水平的成员，比如你就是这样一个菜鸟。或者即便都是专家，但是所涉及的领域不同所理解的内容也不尽相同。

之前我被教导对设计师使用设计师的语言，对程序员使用程序员的语言（鉴于这实在需要巨量的知识库，而我要承认力所不逮不愿意在大家面前班门弄斧）。不如使用外行人（通俗）的语言，看上去是有点蠢，但是起码每个人都能明白你在说什么。

我们总是在强调产品的可用性，我们在制作文档的时候也应该保证这份文档的“可用性”。

如果你用通俗的语言向我解释问题，我也会很感激。这样我就不用装作自己比你懂，然后偷偷去百度了，我们可以大大节省时间。

（希望修改之后的文档不会让你觉得太艰涩）

总结

开发产品的流程可以套用在大部分事情上。按照“目标——对象（用户）——内容——结构——细化”的方式去处理，我们就不会惧怕任何一无所知的事物。

不要纠结形式和内容，重要的是用对方能理解的方法表达清楚自己的想法。

Ps：如果你发现有件杂事没有人做，就接过来，反正最后总是我们做的哈哈哈

第一篇：嗨！菜鸟~我们来谈谈你的新工作（习惯篇）

第三篇：嗨！菜鸟~我们来谈谈你的新工作（文档篇）

第四篇：嗨！菜鸟~我们来谈谈你的新工作（产品思维篇）

#专栏作家#

GaraC，知乎账号：GaraChenV，人人都是产品经理专栏作家，专长研究用户体验，虐待各种形式的键盘。关注物联网、互联网金融、LBS等相关领域产品。专业扫描各种书籍，爱好：收集各种乐谱和奇怪的书。

本文系作者独家授权发布，未经本站许可，不得转载。