嗨！菜鸟我们来谈谈你的新工作（流程篇）

　　写给我的第一任助理
　　这是一个菜鸟产品经理写给她的菜鸟产品助理的入职培训教材，教材分为“习惯”“流程”“文档”“产品思维”等几个部分。
　　在流程篇中，我将向你介绍一个通用的流程和我们的团队构成，你也可以从中了解到你将参与的工作内容。同时我希望能够带给你一个合乎逻辑的做事方式，使你在接到一个新任务的时候不会手足无措。
　　开始吧
　　流程
　　举例一个故事来进行产品开发过程的说明：
　　一个动机
　　盘古开天辟地后，女神女娲在茫茫原野中行走，她倍感寂寞，她需要陪伴，于是她想要一些能够陪伴她的生物。
　　女娲决定聘请一个团队帮她完成这件事。
　　产品目标
　　创造一个陪伴女神度过漫漫时光的物种。
　　用户需求
　　这个物种和女神长得差不多，要能陪女神说话，要能陪女神度过长久的时光。
　　内容与功能需求
　　拥有智慧能够思考、能够学习进步、能够繁殖扩张、能够新陈代谢。
　　界面交互设计
　　外形如同女神，拥有头脑，四肢等部件
　　为了确保功能，需要放入五脏六腑，各种器官
　　信息架构
　　用骨架把“人“支撑起来
　　布局与导航设计
　　眼睛放在上面，是为了看得更高；嘴巴放在下面是为了食用方便；耳朵在两侧是为了听得更广阔
　　视觉设计（设计）
　　黑头发黑眼睛，双眼皮长睫毛穿上衣服（差点忘了）
　　开发与测试（开发）
　　让人类活动起来，看看有什么错误需要修正。
　　以上是一个传统的产品开发过程（设计与开发的工作不详述）
　　我们再来看看团队成员在开发过程中的位置和工作内容，图中描绘的是各个部门担任主要职责的阶段（你可以对照我们的项目文档）。
　　团队
　　以下是部门组织架构图。
　　产品工作
　　所有的工作都围绕着“需求”展开，作为需求方，我们要做的，就是向团队进行需求的解释和沟通。
　　两种方式：文档和语言
　　1制定需求
　　产品在各个阶段“目标对象（用户）内容结构细化”由粗到细地制定需求，并产生相对应的“需求文档”，这些文档就是用来解释需求，形式完全可以灵活多样（不仅仅是通常理解的文字文档，如果你能画漫画，说不定会更受欢迎）。
　　2输出需求
　　需求文档将给所有项目团队的小伙伴们看，确保“用户们”能够通过文档理解你的想法。
　　然后用各种方法解释这些需求，确保所有人都理解需求的原意。
　　3管理需求
　　我们当然希望需求不要再有改动，可惜这只是一个美好的梦想。每个负责任的成员都会向我们提一些建议，有些建议会转化为新的需求。
　　新需求的管理工作更加繁琐，因为牵一发而动全身，改了某个部分可能对前后的工作都有影响。因此要尽量避免需求脱离你的控制，避免无限制的需求变动导致项目延期。
　　4项目
　　鉴于我对于小伙伴们各自工作一知半解的程度，通常不纠缠具体细节，我们只需要在项目计划中对时间节点和里程碑（某个时间完成了某件事情）进行跟进，大家会自己掌握工作进程。
　　小伙伴们在时间范围内完成了自己安排的工作，说明一切顺利。
　　避免（重要）
　　在完成文档的过程中我犯了个严重的错误。导致我把几个小时打出来的文字删去了一半。因为我试图向你描述清楚每一件事情，同时向你灌输一些专业严谨地内容。我试图让你读完这篇文章就变成专家了。
　　这是我极力避免的事情。
　　所以我特地在这里予以说明：
　　我建议你的每一份文档都适合一个外行人流畅阅读（起码能够读懂大部分内容）。因为你不一定每次都碰到相同知识水平的成员，比如你就是这样一个菜鸟。或者即便都是专家，但是所涉及的领域不同所理解的内容也不尽相同。
　　之前我被教导对设计师使用设计师的语言，对程序员使用程序员的语言（鉴于这实在需要巨量的知识库，而我要承认力所不逮不愿意在大家面前班门弄斧）。不如使用外行人（通俗）的语言，看上去是有点蠢，但是起码每个人都能明白你在说什么。
　　我们总是在强调产品的可用性，我们在制作文档的时候也应该保证这份文档的“可用性”。
　　如果你用通俗的语言向我解释问题，我也会很感激。这样我就不用装作自己比你懂，然后偷偷去百度了，我们可以大大节省时间。
　　（希望修改之后的文档不会让你觉得太艰涩）
　　总结
　　开发产品的流程可以套用在大部分事情上。按照“目标对象（用户）内容结构细化”的方式去处理，我们就不会惧怕任何一无所知的事物。
　　不要纠结形式和内容，重要的是用对方能理解的方法表达清楚自己的想法。
　　Ps：如果你发现有件杂事没有人做，就接过来，反正最后总是我们做的哈哈哈
　　第一篇：嗨！菜鸟我们来谈谈你的新工作（习惯篇）
　　第三篇：嗨！菜鸟我们来谈谈你的新工作（文档篇）