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