项目管理 - UCD大社区

互联网产品需求管理思考1-统一需求管理

yeeach — 2010-04-05 16:34:27

对于互联网公司而言，产品需求管理是产品研发的核心环节，产品需求的正确与否直接影响产品开发周期、产品开发成本、产品运营成本，甚至直接决定了产品市场竞争力。根据统计：产品开发中40%～60%的问题都是在需求阶段埋下的"祸根" ，在测试阶段及运营阶段发现需求阶段植入的问题，解决的代价是需求阶段发现问题的68～200倍。

关于需求管理的故事很多,列举一些常见问题：

某天老板问起：我很久以前提过一个需求，提过以后就没下文了。产品经理无辜地说：有提过吗，是给我提的吗？
某个销售谈起：我很久以前提过一个需求，当时被产品否掉了，觉得不重要，现在竞争对手就靠此功能赢得了众多客户。产品经理无辜地说：当时是被否掉了，但你后面再没有提过，因此在后续产品开发中当然没考虑此需求
某天老板提起：某个产品的某个功能很不错，于是乎大家加班加点地开发实现了类似功能。等到产品开发出来后才开始找客户、找卖点。
销售们抱怨：产品人员、开发人员闭门造车，只关注技术，不关注客户需求。产品及技术无辜地说：销售人员根本描述不清楚需求，我们已经按照他们需求开发出来了，他们还是不满意。
销售人员只管销售目标的完成，客户反映的信息不能传递到产品及技术部门。研发部门主动到销售人员那里了解市场信息时，他们往往说：“我只管销售，你先把产品拿出来再说”
某个客户在社区里投诉：xx产品的xx功能做得太差了，已经投诉过几次都还没有改善；但产品及技术无辜地说：他这功能相对于其他产品功能优先级很低，因此暂时不考虑
竞争对手某个杀手级产品的功能其实以前公司很久以前就做了，但后来没有持续完善，导致“起了个大早，赶了个晚集”
某个产品越做越大、越做越乱，直到有一天无法维护时候整理产品功能才发现，里面有一堆乱七八糟的需求，这些需求怎么来的、现在哪一个客户在使用此功能，谁都不知道
公司层面产品相关利益者都参加的需求收集会议也开了很多次，但大家对于产品需求的理解还是没有统一
与竞争对手的产品比较，产品功能比竞争对手全面多了，但还是竞争不过竞争对手的产品
某个产品离职了，大家才发现，对产品最熟悉的人只有这个产品经理，没有任何文档及功能说明，有的只是网站页面和代码

对于大部分互联网公司而言，都意识到了产品管理的重要性，因此都有相应的产品管理流程，但为何以上问题仍然屡见不鲜呢？

以上问题的根源在于：

1）、没有对各种需求有效地分层分级，对不同阶段需求的目标没有明确的定义

2）、没有建立一个横跨市场和产品研发部门的组织机构来统一负责收集市场需求，并将其传递给产品研发团队

3）、缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系”；

4）、没有建立一套跨部门的端到端的业务流程来指导市场需求收集与传递工作

5）、没有一个客户需求分析工具来指导系统性地收集客户需求

1、互联网产品需求来源

一提到需求管理，产品人员及技术人员都会异口同声地说：软件需求管理，我们有啊。我们的软件开发过程遵循CMMI3、RUP、XP、SCRUM等开发过程，需求管理是我们进行开发的最重要阶段。

我们这里所指的“需求”不单纯只是技术术语的产品需求、软件需求，还包括：

客户所想所需：Needs、Wants
市场需求
产品包需求：Offering Requirement
产品需求
开发需求

相对于传统软件开发过程，互联网企业的需求管理来源更加多样化，包括：

1）、外部来源

客户需求：客户在使用产品过程中所提的建议和意见；以及通过客户访谈等手段得到的需求
竞争对手产品分析：直接作为竞争对手产品的客户试用，获得竞争对手产品相关信息
社会化媒体：搜索引擎、IM、BBS、Blog、SNS社区、Blog、Twitter、百度知道等社会化新媒体
传统媒体/竞争对手软文等
合作伙伴
行业分析

一些竞争对手分析的手段可以参考电子商务企业竞争情报分析工具

2）、内部来源

公司产品战略
客服人员：包括呼叫中心（电话、短信、传真、邮件等）、在线客户（IM、BBS、留言板、WebCall等）
运营人员：所谓互联网产品是运营出来的，任何成功产品不可能一蹴而就。公司内部运营人员在运营中产生的需求是重要的需求来源渠道。
市场营销人员
销售人员
财务人员
技术支持
网站用户行为分析：包括网站用户购买行为、点击流等

2、统一需求管理的意义

由于需求来源的多样化，就要求在公司层面对需求进行统一的管理，以保证能够：

1）、建立端对端的需求管理流程，实现技术与市场的无缝结合。

2）、深入理解行业，成为行业专家：对于互联网企业而言，必须深刻理解所在行业的特征及行业用户的痛点才能够推出有竞争的产品，因此必须首先成为所在行业专家。产品需求本质代表了行业用户的需求，通过产品需求的持续积累，可以加深对于行业理解，从而成为行业专家，能够推出更符合行业需求的产品

3）、知识的传承：通过对需求持续统一的管理可以保证知识的传承，避免产品需求知识积累在几个人脑袋里。

4）、主动收集需求，准确把握市场机会点

5）、产品创新：通过产品及产品间原有需求的优化、借鉴、组合等手段来达到产品创新的目的。

我们这里的所说的“统一需求管理”比RUP中的更为宽泛，包括：

公司层面统一的需求管理组织支撑体系
公司层面统一的需求管理流程制度
公司层面统一的需求管理工具

4、怎样实现统一需求管理

在实现公司层面需求统一管理，华为及IBM所采用的IPD过程很有借鉴意义，核心思想在于：

1）、组织支撑

通过建立一个横跨市场和产品研发部门的组织机构来统一负责收集市场需求，并将其传递给产品研发团队

2）、端对端的流程

所谓“端到端流程”是区别于职能式的产品开发模式，建立的产品开发流程是跨部门的、关注业务实现的、客户到客户的业务流程。企业中与产品需求相关的主要有三大流程体系：市场管理流程、产品开发流程、需求开发流程。在市场管理流程的第一阶段（了解市场阶段）、在产品开发流程的第一阶段（概念阶段）都会定义客户需求的收集活动，用需求开发流程来支撑需求收集活动。

可以参考：华为IPD流程管理

5、统一需求管理一些思考

1）、所谓“工欲善其事，必先利其器”，一个好的需求管理工具对于需求管理有很大帮助。但工具不是万能的，关键还是使用工具的人，因此不用整天寻找完美的工具，而是要问一下自己：对于工具的使用热情我们能够坚持多久？

2）、工具本身并不能解决需求管理混乱的困局。核心问题还是需求管理的方法论、流程制度是否能够持续完善。成功需求管理的秘诀之一就是：持续积累、持续完善。

3）、我们很多时候忙于开拓新的市场需求而忘记了总结的价值。与客户、市场、销售、产品、技术、运营等相关人员定期对积累的各种需求（不单纯只是产品需求）进行“requirement review ”（类似于“cod review”），可以碰撞并挖掘出许多有价值的产品需求及卖点。

4）、对于运营型企业而言，各种行业需求的持续积累是企业最为宝贵的财富之一，也是产品创新之源。因此应当把持续的需求积累提升到公司战略层面。

关于项目范围的一点心得

小麦 — 2009-08-31 21:41:55

最近有一次全职项目经理的机会。这是第一次做真正的项目经理，所做的项目也是前所未有的困难：10天，做出一个新产品，几乎每天都有需求变更，中间还得交付一个Alpha版本与一个Beta版本供内测与公测。

现在项目几近完工，等待最后的上线。有一些关于项目范围（Project Scope）的心得，想分享一下：

1. 产品范围（Product Scope）不等项目范围。
简而言之，产品范围是指产品所具备的所有功能，而项目范围是指为实现这些功能，项目团队要做的所有工作。所以简单的用产品规格说明书来衡量项目进度是不正确的，比如为了实现一个好的架构，可能在前面70%的时间，一个产品功能都没有实现，而在到90%的进度时，所有的功能都完成了，但仍存在很多bug。所以在70%的时候，只根据产品范围来看项目的人会感到恐慌，而在90%的时候，他们又会错误的乐观。作为专业的项目管理人，应该要有这个基本的判断能力。

2. 处理好来自外部的项目范围变更。
最常见的一种情况就是产品需求变更。有一种错误的认为是，固化需求是项目经理的职责。其实项目经理是无权决定是否需要产品需求变更的，他的职责在于：对外告知所有的利益攸关方（Stakeholder），此需求变更导致的范围变更的代价具体是什么（预算超支、项目延期、加班、团队士气下降等等）；对内确认所有的范围变更都是可行的，且确保所有的项目团队都能准确及时更新到新的项目范围。

产品经理说，我要加一个功能，那么项目经理应该为他评估此功能的增加，可能会导致项目延期。更积极的是，与产品经理一起评估，制定出合理的变更方案。其中值得一提的是，避免产品经理单线的与项目成员达成变更，而未经项目经理确认。

3. 处理好来自项目内部的范围变更
一个有趣的名词叫“渡金边（Gold Plating）”：比如某个优秀的开发人员，为了追求完美而擅自决定为它打造一些更好的效果。这看起来是很值得鼓励的，但它的危害性是，项目可能为此付出更多的代价：时间、金钱。原本两天可以完成的工作，变成四天才能完成。这是一种项目范围失控的情况，所以项目经理要理智的阻止这种情况的发生。向所有的项目成员明确，什么是需要做的，什么是不需要做的。

总而言之，项目范围的管理，就意味着项目经理要随时掌控项目的边界，并确保所有的项目成员，所有的stakeholder都知道这个边界在哪里。

相关话题：项目管理源地址：http://www.mikkolee.com/243

设计项目开始前，9件需要了解客户的事情

2009-06-02 01:40:08

原文作者：andelaydesign
原文链接：9 Things to Understand About a Client When Starting a Design Project
译者：格

作为设计师，你的每个客户和项目都是独一无二的。有些事情，你需要了解或者熟知你的所有客户，才能为他们做出最好的设计。建设一个有效的解决具体业务需求的网站，需要设计人员准确理解很多业务的细节。

在这篇文章中，我们会看到9件设计师与客户在设计开始前需要讨论的事情，以增加成功的可能性。这些是围绕去了解客户业务与需求的话题，而不是像付款与最后期限这样的合同问题。

1. 商业目的

几乎所有的商业行为都有任务与远景声明。如果你想要设计出真实反映业务和对客户有效的网站，了解基本的商业存在原因与他的目标是绝对有必要的。

如果你不清楚客户的核心职责或者他们存在的原因，一定要在开始向目前把这些问题弄明白。虽然是很简单的资料，但是没有他们，项目很有可能误入歧途。

2. 具体产品与服务的业务

一旦清晰了业务存在原因，熟知具体事项与客户是如何从业务中得到收入也是非常重要的事情。无论是建立电子商务网站，还是普通的信息站，或者任何其他类型的网站，有必要知道客户准备为网站用户提供什么。

3. 客户的用户统计数据

讨论业务的产品和服务会让你获得有关为产品与服务付费的用户的更多信息，有效果的网站是以用户为中心，这个对身为设计师的你是至关重要的，你的客户需要准确的了解谁将使用这个网站，谁是有可能对提供的业务感兴趣。

尽可能多的获取这方面信息是非常好的做法。比如目标用户的年龄，性别，职业，收入等等，这些对确定网站的设计风格非常有帮助。此外，为搜集更多有关用户对产品与服务感兴趣的原因而建立网站，有利于提高潜能。

4. 企业文化

好的网站能反映企业，使之成为整体市场营销和企业形象有效的一部分。为了创建能准确表现企业的网站，你需要在一定程度上了解他们的企业文化。很多时候你可以通过业务人员了解他们的文化（如果可能的话）。与不同的员工进行交谈，与不同的客户或者用户交谈（如果可能的话），通过观察其现有的营销材料，比如小册子，名片和广告。

5. 目前网站需要改善的地方

如果你的项目是需要对现有网站重新设计，这个时候你需要知道的一个重要事情是为什么他们选择了重新设计，特别是为改善现状重新设计他们制定了什么？是因为他们网站上了岁数仅需要换换面貌？还是因为发生了业务发生了重大改变需要新的设计与信息？还是提供的新产品和服务不属于旧的网站的一部分？还是现在的网站不能为新的业务提供有效的帮助。虽然这是非常合乎逻辑需要考虑的事情，但是需要你向客户索取资料，并弄清楚他们着手重新设计的原因，这是许多人不会想到你需要完全明白的。

6. 他们对新网站的期望

假如目前网站存在失败或者过时的具体地方。一定要深入了解客户对新网站提高业务水平的期望是怎样的。期望是决定他们对你的工作的满意度的巨大因素。所以为了满足用户，知道项目最终的结果是什么非常重要。

7. 项目成败的决定性因素

网站的新设计会给企业带来令人满意的感觉改善。但是最终将有其他的影响因素，决定项目的成败。作为设计师，有效的工作会给客户带来提高业务的网站设计。清楚的认知项目成败的因素是非常重要的。也许是成功仅仅在于增加了销售量。也许是网站更准确的反应了企业的重大事情。无论是哪种，知道如何衡量能帮助你把重点放在合适的方面。

8. 他们选择你做设计师的原因

有如此众多的自由设计师和设计公司可供选择，很明显客户选择了你是有原因的。也有一些是使客户觉得你是最合适的人选的相关事情。这也许因为你以往作品中的具体项目。也许因为在签约之前你表现出的有效沟通和对细节的关注。也许是因为你的定价。

无论是何种情况，有些关于你或者你的工作的事情，是鼓励你的客户和你一起去了解其他设计师。这一决定背后的原因往往会帮助你更好的了解他们想要的或者对你的期望。

Whatever the case may be, there is something about you and your work that encouraged the client to go with you over other designers. The reasoning behind this decision will often help you to have a better understanding of what they want or expect from you.

9. 他们维护网站的计划

目前几乎每一个网站的设计开发都会使用某种类型的CMS.他们不断维护更新网站的需求影响着CMS的选择和如何建立网站。

他们计划增加新的页面与经常在存在的页面改动图片和文字么？他们需要各种各样的模板，为不同的目的建立特定页面吗？他们仅仅是偶尔或者很少更新页面么？理解客户不断前进中的需求能帮助你决定为特定的项目使用正确的CMS。在某些情况下，客户可能已经有了他们想使用的 CMS,但是这样的情况不经常遇到。

相关话题：项目管理源地址：http://www.yeeyan.com/articles/view/61966/44096

产品管理和项目管理的区别

imacg4 — 2009-04-20 00:31:07

简介

产品管理和项目管理的区别，从一个产品经理的角度出发而写

你要是想当个差劲的产品经理，那就把产品管理(product management)和项目管理(project management)混为一谈吧。这两个词如此相像，是因为它们表达的概念非常相似。产品经理也要管理项目，因为他们需要确认项目的完成情况。两个职位都是管理角色（不对吗？），所以所需的技巧和经验基本相同。项目经理只是一帮碍事的人，成天想着从产品经理的手里夺走项目控制权。

你要是想当个优秀的产品经理，就得了解产品管理和项目管理之间的不同。除了名字看着差不多之外，产品管理和项目管理之间有着巨大的差别。把二者混为一谈是常见的情况，甚至有经验的产品开发人员也会犯这样的错误。

项目经理的责任是产品的成功交付——在确定目标、划定范围、固定时限、给定预算等限制条件下的一次性努力。项目经理的工作内容包括资源配置、问题与风险管理、以及协调几乎所有完成项目所必需的元素。至于项目与产品的关系，项目的任务可能是开发新产品、增加产品功能、以及产品的新版本或扩展包的开发。项目完成后，项目经理通常会转向新的项目，而这新项目通常和不同的产品有关。

产品经理的责任则是保证产品全方位、各阶段的成功。在新产品开发项目结束、项目经理奔赴新的任务后，产品经理仍要管理产品，贯穿产品的整个生命周期。这时其他与该产品相关的项目可能启动，产品经理将自始至终参与其中，制定项目目标、引导团队完成既定商业目标。

两种角色间的一个挑战是：二者的关系可能表现为一种冲突。产品经理为了满足目标客户需求可能想加进去很多功能，而项目经理为了保证项目按时不超预算地交付可能想把范围控制得尽可能小。传统定义（可能本文前述定义也是如此）通常把项目经理错误的描述为仅仅关心按时、不超预算的完成项目，对产品是否符合市场或用户的需求漠不关心。

好的产品经理和好的项目经理能够在这些冲突中建立一种平衡。好的项目经理清楚，项目的真正成功不是根据其是否按时完成或是否超出预算判断的，而是根据它是否满足了预定的整体目的和具体目标来判断的。好的产品经理也清楚，如果项目不断延期无法上市，或花费超出预算过多导致无法完成，那再多的功能也失去了意义。

特别地，对于基于网络和技术的产品，项目管理和产品管理之间的混淆特别常见，这种混淆对于不了解二者区别的组织来说还有潜在的危害。Rob Grady在《你是网站项目经理还是网站产品经理（第一部分）》中写道：

在网站对业务的重要性日益提高的今天，它们——不幸的是——仍被作为项目来对待。这种现状成了一个问题，对达成业务目标、确立优先级、掌握管理一项新生的核心业务功能的正确技术都是障碍。如果网站已经成为或始终是一项核心的业务功能，其需求就会比项目管理需要的更多。当网站成了一个产品，它需要一系列的项目驱动来达成业务目标。

以下是一些关于项目管理和产品管理的要点，值得牢记在心：

正如每个产品都需要产品经理，每个项目也需要项目经理。
产品经理以为他们可以管理自己的项目，但仅凭这一点不能得出他们该这么做。
项目管理涉及的手段、才能和品质与产品管理所涉及的差别很大。
正如一个人难以身兼产品管理和产品营销二职，想找到一个同时胜任产品管理和项目管理两个角色的人也很难。
项目管理不是产品管理的垫脚石，产品管理也不是项目管理的爬墙梯。
好的项目经理和好的产品经理同样可贵。
找一个好的项目经理管理你的项目，这样你能成为一个更好的产品经理。
产品经理花在项目管理上的时间越少，可以花在产品管理上的时间就越多。
为了避免产品经理和项目经理之间的冲突，产品经理、项目经理和项目团队应该就共享的整体目的和具体目标达成尽可能多的一致。

注：本文在PM Hut上再版。

相关话题：项目管理源地址：http://www.yeeyan.com/articles/view/imacg4/37435

项目如何开始：怎样和客户一起搞定需求

西乔 — 2009-04-19 20:01:24

项目刚刚开始的时期，项目经理做的主要事情是搜集客户需求，这是一个项目经理非常头疼的阶段，合作的磨合刚刚开始，需求问题上的失误又会导致无穷的后患。

三种客户类型：

1 的确很专业。能提供基本可用的文档，能给出要求规范，能向你提出有价值疑问和担心。能快速回答你的问题。

2 以为自己很专业。 给的文档基本没法用。没法提供规范和标准，喜欢指指点点和挑毛病。只会向你提傻逼问题。基本回答不了你的问题。

3 啥都不懂。 不给文档。能给你几个参考范例（打开数个网站，告诉你我要做成和它们一样的。）只能等着你来问100个问题。。。

四种合作方式：

1 创始人直接和你接洽：
交流结果的协商余地很大，需求不易反复，细节不会被过分追究。更容易统一想法，执行力高，你能对项目和产品产生更大的影响。但往往甲方会过于急进。

2 项目代表和你接洽：
这是非常理想的状况了。甲方有一个产品经理或IT经理能作为代表，负责汇总甲方的所有需求和标准和你沟通，他有过与外包方合作的经验，知道危险的环节所在，能承担翻译和桥梁的角色，帮助你阻挡和说服不恰当的需求。能集中地承担责任，也会积极地和你一起规避项目失败的风险。非常lucky！

3 专业部门和你接洽：
IT部门或技术部门的某个高级别工程师负责和你沟通，你们会比较有共同语言，甚至惺惺相惜。技术方面的合作会很顺利，但是涉及到产品和需求，他们无法帮你挡住来自市场或内容部门的麻烦。合作开始后，很有可能在技术思路上产生分歧；如果在程序部分耽误了太多时间，而产品端被忽视，你有可能受到其它部门及上层的质疑。

4 市场部门（内容部门）和你接洽：
最好你先去烧烧香，准备好最坏打算。专业和思考模式的差异会导致你们关心的问题完全不一样。你首要满足了他们关心的地方后，切记留出不少时间来解决那些他们看不见但实际上非常重要的问题。另外你需要做更多的事，写更多的文档，主动和专业部门联系，力争和决策层有沟通。

如果你面临了第3和第4种状况，

请先熟悉一下甲方的组织机构。例如一般 内容型、媒体、渠道、宣传类项目的开发：

需求和市场部门沟通
功能和内容部门沟通
软硬广告位或专题等和销售部门沟通（如果是改版类，广告位合同可能提前半年签订，一定要和销售协调好）
技术、系统、安全、统计问题等和IT、网管、数据统计部门沟通
某些问题需要和总裁助理、行政等官僚部门沟通。
部分特别的内容需要和创意、美工、文案部门沟通

当以后确定需求的时候，如果发现这些部门的人没有参与，请提前与之沟通。

第1和第2种状况可跳过上述步骤。

八步流程:

第一步：听听客户想要什么。

以及预计工期和预算（这两件事上一点都不要腼腆，这是关系项目成本最重要的元素）。

第二步：提问。

1 项目的目的是什么。（品牌、渠道、流量、广告费、用户数、VC、其它商业模式）

2 甲方的优势和资源是什么。(钱，内容资源，人力大战，传统行业优势)

3 尽量提供可视的参照及借鉴对象。（应用上有没有可解决的。界面上比较喜欢哪个站点的设计。交互上有没有可参考的对象）

4 其它工程的细节问题。
比如（工期上的上下限是什么？
是否会需要与现有系统整合、是否需要数据迁移？是否会需要甲方的工程师合作？
是否有开发平台的限制？
是否有代码规范及标准？最终需要哪些开发文档和源码）

第三步：取得共识。

与甲方取得共识非常重要，保证你所理解的那他们所理解是同一个东西。这一步需要你根据掌握的情况列出提纲，画出草图或框架图。有参考对象的，标注上，哪个部分会比较像某某。

然后请甲方确认，这个框架是他们想要的。

第四步：给出工程时间轴。

到了这一环节，就需要你的项目经理组织所有团队成员坐下来讨论，先划分功能模块，然后讨论每个功能模块的可行性、难度、花费时间、bug发生率、测试耗时。再讨论一头一尾系统搭建和系统整合的所需时间。

项目经理对工程耗时和可行性完全心里有数后，画出工程的时间轴。包括并行状况，里程碑节点、测试期、缓冲期等（如何画工程时间轴，甘特图，我以后会专门写一篇）。时间轴要实事求是，并且预留好充分的缓冲期（工程师估时*2*110%）。

第五步：需求做减法。

大部分情况下，时间轴表现的状况都会超出客户的预期。如果客户对工期没有要求，也要提醒客户考虑项目可行性风险、市场等候成本、市场或战略变化导致的浪费。

韩磊有一篇《大褂还是内裤》的blog很形象地描述过这个问题。

所以要和甲方一起尽量对需求做减法。把整体需求拆成2~3期，落实只开发最基础和最必要的一期需求。

这时签订正式开发协议。
不要忘了计算需求文档和产品方案的费用。

第六步：撰写详细的需求文档。
《框架图》下载西乔的模版。可视化表现产品的框架、布局、细节、部分交互。
《流程图》》下载西乔的模版。理出产品的逻辑关系。
《功能需求文档》》下载西乔的模版。罗列功能、应用、交互上细节，分离基础件，作为开发分工和系统及数据构造的基础文档。

第七步：商讨需求文档

尽量召集甲方所有相关部门的负责人一起召开这次会议，商讨需求文档。

在阅读到你的需求文档之前，可能甲方的大部分人都对产品没有可视和具象的理解。也从未关注到细节和逻辑关系。所以需要产品经理从全局角度和逻辑线索讲解文档。

更可能发生的状况是，没有人坚持看完或仔细看过你写的文档。

所以这次会议是一场耐心和体力的考研。

文档作者需要分别向各个部门指出他们需要关注和拍板的地方，听取他们的建议，将任何变动要求都分类记录。

安抚情绪。解答困惑。控制需求变动。

第八步：定稿需求文档

分职能（部门）类建立表格文档。将会议协商中所有分歧性意见和变动意见都逐条写下。抄送所有相关负责人。并要求他们纠正分歧和确认变动。

所有会议中可能被提出但是未出现在此邮件文档中的意见，不会列入需求文档中。当然允许可以书面反馈补充。

根据确认过的反馈回复，修改需求文档。直到需求文档定稿。

协商讨论和文档修改可能经过2~3轮。所以需要项目经理提前提醒客户注意，搜集需求和文档定稿的时间线里程碑。如果这个阶段耗时过久，会严重延误整个项目进度。要求客户尽量集中地谨慎地提出建议和修改。

三种武器：

需求问卷：无论是面对专业还是不专业的客户，交流中都有很多没考虑到的遗漏点，这些他们看不到的点往往是最关键的点，也有可能是被客户故意规避掉的点。

此时撰写一份需求问卷非常有效。

问卷里提出重要的全局性的问题，需要客户逐条书面回答。

某些问题可以提供多个选项答案，及补充区域。
某些问题需要确凿的态度，Yes或NO。
不要提出需要客户写一大段表述性文字的问题。

需求问卷精简扼要，有针对性，重要，不要浪费客户的时间，不要把写字的工作量丢给客户。

书面确认：
书面确认一方面包括：所有讨论结果、建议和变更都要有书面文字备查。电话和开会上说说的这些口头表达都没有效应。这一点一开始你就要声明，甚至有必要写在合同里。

另一方面包括：你要尽量提供书面的可视化的东西来让甲方确认。
甲方很难完备或是提供适合工程使用的文档。所以千万不要在项目初期的需求文档上省懒。

邮件抄送：
邮件抄送一种明确职责的方法。对方可能不看你的邮件，但代表你告之过。
尽可能地抄送重要邮件给战略层，可以能避免一些重大问题的出现。

结语：

到此看起来，搜集和确定需求真是一件耗时耗力的工程。

其实在理想的工程项目时间分配中，1/3的时间用于确定所有需求和开发文档。 1/2的时间用于测试，解决bug，安全测试、压力测试等。真正用于开发的只应该占1/6。

当然web项目的开发肯定达不到这个理想状况。但是也由此可见需求阶段的重要性和工作量。这一阶段省一分力或有一分遗漏，到了项目后期可能需要十分力来弥补。

相关话题：需求分析项目管理源地址：http://blog.xiqiao.info/2009/04/17/277

如何做好“老板项目”

iamsujie — 2009-04-26 22:11:14

老板项目，就是指老板突然跟你说，我们要做个什么什么，然后你只有执行的份儿……的项目。什么，你们公司所有项目都是老板项目？很正常，那我们更应该聊聊这个话题了。

先来一点科普，做项目的目标无非是多快好省：范围多、时间短、品质高、资源省。但又要马儿跑又想马儿不吃草的事情是没有的，有理智的老板也都明白这一点，所以我们通常是在上述4个要求中做平衡。对比经典的项目TRQ：项目时间（Time）、项目资源（Resource）、项目质量（Quality），几乎一样。一点区别就是Q，我觉得Q = Quality+Quantity更准确，质量这个词其实包含了“品质”和“数量”两个含义，而我所经历的项目，Q更多的是表达Quantity，一般来说，品质高这点是不会舍弃的（不排除有特殊场景），所以可变的是项目范围。

综合一下，我们做项目就是在时间要求、人财物花费、项目范围三点上做平衡，不妨就继续叫做TRQ吧。

来一个真实场景回放：“你突然被老板叫到办公室，他和蔼可亲，又情绪激动的对你说，小某啊，组织上有个重要项目要交给你，blablabla，省去半小时，这都不关键，最后一句：某月某日之前一定要发布！”似曾相识？嗯。首先恭喜你，通常这样的“老板项目”都是重要的项目，说明老板信得过你。然后你要反驳了，恭喜什么啊，我牙还没刷呢，连做什么都不知道，居然TRQ的T已经定了？！

是的，当时就是这样。

传统项目管理中的那一套，先需求，知道要做什么以后，再组织协调资源，最后推算出时间计划，在这里跑不起来啦。我脑中突然浮现一句话，改编如下：做项目，特别是老板项目就像被强奸，与其无畏的反抗，不如好好享受。

于是，阿Q的我们找到了理论支撑：Agile，敏捷！不是么，更多的时候我们都是被动敏捷，或是被老板逼的，或是被用户逼的，或是被对手逼的……人类的本性应该还是恐惧变化和不可知的吧，不知有多少人看到这里内心在呐喊——我爱瀑布模型！

所以有公司在价值观里宣扬“拥抱变化”真是很积极的一种人生态度。那我们来拥抱敏捷吧，看看在TRQ三方面应该如何享受：

T是给死的，可以试着商量一下，但一般很难改变，如果是老板的老板给老板定的，那就更甭想改了。通常，每一级任务的下放，老板都会给自己留一小段时间做缓冲，但是我们可千万不要在定项目计划的时候算上老板留给自己的这段时间，反过来，我们订计划的时候应该再给自己留一段，这些都是最后救命用的。

Q是可变的，先说Q，一般越大的老板给出的指示越战略性，越不具体，所以具化出来的Q就可大可小了，所以开始的时候，尽量发挥自己的聪明才智，先天马行空的爽一把，把Q搞大搞大搞大，并合理的算出一个巨大的R，然后，你就可以欣赏到老板因为无法付给你这么多R而自己砍Q的表演了……当然，我们应该尽职的帮老板排出各种功能的建议优先级和所耗资源，好让老板知道刀该往哪里挥。

R是丰富的，老板项目么，第一优先级，R就是大大的有，其他项目统统让路，让多少路，这个问题应该抛回给老板决定，我们只提供专家意见，狮子大开口：让的越多越好！记住，千万不用在这个时候就帮老板着想，应该怎么节省R，那样反而不讨好，老板会觉得你思路不开阔，没劲，我有过一次做了个项目方案，十几个人就搞定，沾沾自喜，结果老板说：你先给我照着100个人做这么久来规划。

真的这么爽？

当然不是，有时候你发现，老板比较猛，Q都帮你想好了，那只能说没劲，也别废话了，甩开膀子干活呗。更悲剧的是，R也是不足的，就那么几棵人，又要在固定的T下做这么多Q，绝望？不至于，我们还有最后一招IT民工必杀技——加班，天天加班，天天加班还不要加班费……我们期望的是老板看得到，公司有前途，明天会更好……

如果这样还做不完，那只能说——老板丧失理智了！兄弟，撤吧……

最后谈谈，老板项目到底好不好？从个人角度，如果是纯项目经理，这就是本质工作，无所谓好坏，而对于我们这样做产品的同学，老板项目没有成就感（有成就感的项目是自己去做用户/市场研究，然后发现问题，发起项目），而好处就是接近老板，无需多说；从老板/公司角度，效率高，决策风险大，其实，这和民主与专制的区别是很像的。

相关话题：项目管理源地址：http://iamsujie.com/3000/3012/

前苹果员工揭开苹果内部互联网项目真实情况

胡维 — 2008-08-13 23:25:56

曾在苹果公司邮件列表（Mailing List）后台长期工作的前苹果员工Chuq von Rospach 透露了 MobileMe 上线初期糟糕表现的真实原因，并且试图揭开乔布斯写给 MobileMe 项目组的那封内部邮件（史蒂夫·乔布斯点评MobileMe）及苹果互联网项目新的负责人艾迪·库埃（Eddy Cue ）的真实情况。

内容如下：

Rospach ：我知道，很多我认识的朋友和人们参与了MobileMe 项目，我为他们感到难过。但真实的情况是 MobileMe 还没有准备好就上线了，结果非常的糟糕。史蒂夫和苹果都不能容忍这样重大的失误。我想我的上司已经开始弥补这一失误了。

史蒂夫在那封邮件中说：“ 与 iPhone 3G 、iPhone 2.0 软件以及 App Store 同时发布 MobileMe 是一个错误。我们当时都已经在超负荷工作了，如果将 MobileMe 推迟发布，则可以避免许多问题。”

没错，史蒂夫说的绝对是正确的。但是要记住，放话让 MobileMe 通过的也是史蒂夫。（作为一个偏执的完美主义者）史蒂夫从来都不害怕说“还没有准备好”然后把某项工作叫停重来。史蒂夫准备 MacWorld 大会的开幕主题演讲是出了名的，哪怕距开幕还有不到24小时，如果史蒂夫对文字材料不满意，还是会叫人重写。

所以史蒂夫对此事要负有很大的责任，不过需要补充说明的是：负责向史蒂夫汇报实际情况的人告诉史蒂夫“一切已经准备就绪了”，而且史蒂夫信任他。因此那个向史蒂夫汇报情况的人是失职的，他让包括史蒂夫和苹果在内的每一个人都颜面无光。这同样也不是在苹果公司继续职业生涯的好办法。

在我看来 MobileMe 上线的糟糕表现关键不在于是苹果还是 MobileMe 项目组造成了这一问题，最大的失败在于苹果公司对“计划失败”的容忍能力，在于项目组不愿意告诉史蒂夫“我们还没有准备好”。他们认为自己可以让 MobileMe 在上线的时候正常工作，但结果很糟糕。不过假设 MobileMe 上线之后一切正常的话，我想这才是更糟糕的结果。

苹果的某些部门和项目组只顾自己的表演，把苹果的 IT 数据中心当作主机设备，还有一个项目组在苹果的核心 IT 群组之外运行自己独立的外部 IT 。因此艾迪·库埃才被调来负责建立和管理苹果的核心 IT 群组。

艾迪·库埃这个名字对大部分苹果员工来说也不是熟悉，不过他正在变得像乔纳森·艾弗一样对苹果的成功至关重要。他的专长是让苹果的在线服务能够稳定运转的后台基础架构。他领导的部门曾负责过苹果的在线商店、iTools （也就是后来的 .Mac 服务）和 iTunes store ，都是不引人注目的部分，但也是让耀眼的公司前台能够顺利运转的内核。

艾迪的新头衔将是互联网服务副总裁，负责苹果所有的互联网服务—— iTunes 、 App Store 和 MobileMe ，并直接向史蒂夫汇报。

事实上，让我非常惊讶的是艾迪·库埃居然没有被猎头公司看中过，还有提姆·库克（Tim Cook）也是。在苹果公司，如果你能够坚持到最后，成为史蒂夫信任的核心团队成员（当然，这并不容易）你就能够一直留下来。苹果一般不找猎头公司挖同一级别的公司的高层。

原因很大程度上是因为，为史蒂夫工作太难了。不过如果你能做到的话，那你接下来就能做很了不起的事情，并且会让你上瘾。相信我，在苹果公司你不会看到像雅虎或 Google 那样找人来当公司的CEO ，这在苹果公司的最高层团队也不会出现。

艾迪·库埃真正的本事是能够按照史蒂夫的要求，执行，并且在预订时间前完成工作。

“KEEP THE DAMN THING A SECRET UNTIL STEVE ANNOUNCES IT.”

他的团队都必须在完成前保持沉默，同时也意味着他们需要在未知的领域创新，完成那些根本不存在但又需要存在，而且不符合常规 IT 标准的东西。

换句话说，为艾迪·库埃工作同样也不比为史蒂夫工作轻松。所以，我也常常警告一些人，除非你想鞠躬尽瘁，否则不要到艾迪·库埃的团队去工作。我认识他们中的很多人，都是些像艾迪和史蒂夫一样疯狂的人。我也曾有机会到他们的团队去工作，但我不想受那样的折磨。不过，在那样令人感到害怕的环境下，他们却仍然做出了很棒的工作。

所以，你可以打赌，MobileMe 会稳定的。

（原文见这里）

相关话题：项目管理源地址：http://apple4.us/2008/08/post-138.html

项目管理之TRQ之我的理解

没有文化，吃药是吃不好的！ — 2008-09-01 23:32:28

项目管理－－TQR

前几天参加的 21pm的项目化管理，之前也看到有读者建议我分享一下对于TQR的理解，我整理了一下我自己对其的一些想法。

T: Time 完成项目所的时间

Q：Quality 项目完成时候的质量（成果）

R： Resource 完成项目需要的投入的资源（人、物）

大道至简，如果用最简短的话来描述项目管理的目标，就是4个字：“多快好省”。

在过去的项目经验中，对于T、Q、R经常出现的状况是：

T是要求最高的，IT企业，经常会在确定一个项目的时候，首先确定的是期望发布的时间。而结果也是最悲惨的，往往是实现不了的。这样的项目是屡见不鲜的。在我自己的身边，我自己感觉实际上每一个月都在发生。发生类似项目，我自己觉得会有一个共性就是：老板项目。在产品发展管理中，要非常值得关注避免的一个事情就是“避免老板成为产品经理”，但是遗憾的时候，这种事情也是经常在身边发生，而老板变成产品经理的一个后果，非常典型的就是上述先定T的项目会发生。老板经常会说的是：这个东西嘛，很容易的。这个时间差不多了。我并非在鄙视老板。而是反应一种现实状况是老板往往忘记细节，而产品发展中，细节往往会占用更多时间。
Q是可悲的，互联网产品项目，我觉得有一个很有趣的地方是，需求可以砍了再砍，如果时间不够，第一反应是砍需求，大不了做个一期、二期、三期嘛。似乎这个已经成为共识了。这时候最痛苦的莫过于产品经理，需求要不断的变更，而项目结束后产品是否能满足用户需求呢？往往会出现偏差，很多时候，砍掉的就是用户体验的东西。追求快，而忘记了体验。
R我们有的是，互联网公司最缺的就是开发资源，但是项目里面往往有的是。经常是项目结束一看，哇塞，我们居然投入了如此多的人力啊。但是有一个通病，对于人力的使用，往往不能精确，而且是浪费很多（变更多啊），项目管理要求资源投入精确到小时，我想问，现在互联网公司有几个做到了？

因为坐在车里面等人，所以脑子有点混，写的有点乱，有兴趣的朋友可以在后面跟帖一起讨论。

后面我想会再写一个如何提升项目管理的帖子。^_^

相关话题：项目管理源地址：http://www.kimihome.net/?p=214

淘宝社区的项目总结

蓉儿 — 2009-01-08 21:27:08

淘宝社区本来是一个浩大的工程，有幸能够临时介入到这个项目中来，负责消息中心的mockup设计，还是小激动了一把。由于之前的线框图飞飞已经做出来了，视觉上也是对前期已有的风格的延续，所以做起来也没有太多的困难，但是由于线框图是很早之前做出来的，根据业务的需求变更很多地方都有改动，未涉及到的小细节也要花功夫考虑，我还是在项目过程中学习了很多。废话不多说，下面就举几个有代表性的例子。

1. 确认分组

当别人加我为好友，收件箱会有消息提示。

“确认”的动作包含第一步：“确定此消息” ；第二步：“好友分组”；第二步的动作是可选择的，也可以跳过这个操作直接确定消息。

当然这就存在一个问题，是把这两个操作合并到一个选择框呢？还是分别在两个弹出框中操作？于是有了两个方案：

方案一（分布操作）：

点击“确认”出现确认框

确定后会在消息中出现

，然后再进行好友分组操作，这样做的缺点是要分两个操作，用户会觉得比较麻烦，而且有的用户在第一步操作后会忽略掉第二个操作。

方案二（合并操作）：

这样合并操作的风险就是可能会对动作造成混淆，原先还考虑到是否将好友分组则叠起来，点击后再展开，跟pd商量了后还是直接显示，这样不容易忽略掉好友分组的操作，而导致确认后无法进行分组动作。

2.收件箱发件箱

由于收件箱和发件箱都会有我发出的信息和被人发给我的信息，因此在划分上需要清晰。

收件箱主要是显示收到的信息，不管第一封发件人是谁，只要有收到的信息都在这里展示，新消息用高亮的颜色进行划分，并且在消息栏置顶显示。如果涉及到针对一个留言来来回回很多回复对话，信息页面只显示两行的内容，要想看全部的信息只有点击后进入详情页面查看。

发件箱显示我发的邮件，如果有人回复我的话，新消息还是在收件箱里看到，但如果我载回复的话，新消息就在发件箱里，消息栏显示的是收件人头像（后来想想很简单，不过为了防止混淆还是说清楚点）

3.发短消息

选择好友的时候会一种情况，就是用户没有任何好友，点击后会出现提示框来邀请好友。原先的原型是这样：

考虑到该提示框是隐藏在”选择好友“点击这个动作背后的，进行了改进：由系统判断无好友时，在选择栏上方直接显示提示框。

等等，这样好了么？还没有。细想想，其实如果用户没有好友的话，选择好友也是没有意义的，最后把下方的选择框全部去掉了。而当用户友好友的时候才出现，这样就去掉了不相关的操作，只留下能够操作的控件。

小结一下：

1.前期一定要对整个产品了如指掌，而不要等出了问题才去弥补，这样风险更大。

2.多沟通，不要怕麻烦。有的很细节一定要问清楚了在做，不要想当然的认为，有时候自己理解的东西不一定别人也是这么认为。

3.对产品的每个细节都要把握，每个功能点前前后后是否搞清楚了？页面是否一致？有没有考虑到极限情况？有没有相矛盾的逻辑？功能点是否可以精简，有没有多余的操作让人混淆？等等。

先说这么多，每天积累一点点。

获得大型项目的成功：平衡任务和目标关注度

stan — 2009-01-18 22:38:36

获得大型项目的成功：平衡任务和目标关注度
2008年11月

译者：stan
原文地址：http://www.spring.org.uk/2008/11/getting-big-projects-done-balancing.php

心理学研究认为，大型项目取得成功的关键，在于不断地在任务和目标之间切换关注点。

成功地完成大型复杂项目可以带来巨大的商机，科学或艺术价值。不幸的是，这类项目，由于其本身的性质，在其前进的道路上具有摇摆不定的无穷可能。

项目早期的"打嗝"可以给积极的干劲造成混乱，对良好的判断产生疑惑，对细节失去关注。有很多的原因可以解决这些问题，或者把这做成一件糟糕的工作，我们只能选择其中之一。这就是为什么从心理学角度来洞察会受到欢迎。

近来心理学研究表明完成大型项目的关键因素之一，是对宏伟愿景和独立任务的平衡。也就是要明白，什么时候应该密切关注项目的每一个组件细节，什么时候应该抬起头对项目全貌进行概览。

两个新的心理学研究报告发表在《人与社会心理学公报》和《人与社会心理学》杂志上，对如何在任务和目标之间分配我们的关注点提出了建议。这些技术可以帮助我们避免因早期的失败导致延期，对进展保持良好感觉的动力，直至我们的最终目标。

如果你想跳过这些实验，可以直接阅读“如何平衡任务聚焦和目标聚焦”一节。

应对士气失败

在前进的道路上，我们如何应对失败，决定了我们是否能取得最终的成功（或其他结果）。这就是Houser-Marko 和Sheldon在2008年做实验观察人们在思考独立任务和其总体目标时对失败如何反应的原因。

第一个实验的参与者玩一个计算机文字游戏，评估其用词能力。开始他们被告知最主要目标是达到最好的级别，在此过程中，他们不得不在每一个独立任务中得到尽量多的点数。

在完成每一个任务后，试验人员会告诉他们这一轮做得怎么样。但是，这些信息完全是虚构的，仅仅是为了营造4种不同的试验环境。他们会得到这4种反馈：

“你正在向着A迈进。”参与者说他们正向着这个游戏中的最高级迈进。
“你正在向着D迈进哦”参与者说他们最多只能达到最低级
“这一轮你达到87%”参与者认为他们做得还不错，仅仅就这个任务而言。
“这一轮你达到了47%”参与者认为他们做的很糟糕，但也仅仅是在这个任务中。

实验者希望能观察到在不同分组中的参与者，将会被什么样的因素影响：他们的好（或坏）的感觉（心理学家所称的正面和负面影响）和他们在这次测试中所表现的预期应该是一个整体。具体地说：不管是整体目标还是某个独立任务，在完成的过程中，对成功或失败的感知，是如何影响动机的？

他们发现，被告知做的不好造成参与者感到糟糕并降低了积极性，这毫无意外，而他们真正的兴趣点在于，是否关注的层面影响了动机----单独任务还是整体目标。他们发现的确如此：那些被告知做的糟糕但只在特定任务上做得糟糕的参与者没有感觉不好，也没有预期将来会很糟，

因为他们聚焦在最主要目标上。这样看来，当在一个任务上作的不好的时候，最好是就事论事，而不是因此重新审视最终目标。

真实世界的动机

这在实验室中是一个不错的发现，但是Houser-Marko和Sheldon想要看到的，是这个结果是否能在这现实世界中被观察到。因此，他们设计了一个类似的实验，但这次参与者是有真实世界目标的。由于他们是学生，被给予的主要目标是达到某一特定课程等级。然后，他们被要求为自己每个星期设定一定的时间去学习以实现这一目标。

这些学生被分为两个组，一个组被要求重点关注他们的独立任务，即每周学习时间来评估他们的进展；另一组被要求关注主要目标，即获得的某一课程的具体等级。

真实世界的结果支持了实验室的结论。正如之前的情况，做的不好、并把重点放在整体目标上的参与者，经历了更多的负面的情绪，他们认为实际的成绩会差一些；相反，那些做得不太好、但侧重在他们独立任务上的参与者，却经历了较少的负面情绪并认为他们的成绩会更好一些。

看到成绩

这意味着更加积极的情绪和较高的动机，是由于持续专注于低层面任务而不是最终目标造成的。但有两个原因不能忘记目标。第一个是在现实世界实验中，那些成功完成任务的参与者，才会更好的关注最终目标，如果失败则不行。这样，他们经历了更加积极的情绪，并认为他们会做得更好。

第二个我们不能忘记目标的原因，是我在最近一份就如何提高自我控制的研究报告中证明的。它表明，用抽象论据和高级分类的方法有助于提高对手头任务的实行。实验的参与者侧重于结果而不再是继续盯着他们的任务。乍一看这些结论是冲突的：一方面说要看到已有成绩，而另一方面说要以任务为关注点。那一个是正确的呢？

实际上他们最初并不矛盾，这一切取决于环境。在目前的实验中，参与者评估进展、以任务为关注点，这种情况下是非常有用的，尤其是当任务比较难、容易失败的时候。但实际上，当他们关注到任务本身时，自我控制实验表明：把目标铭记心中，这对动力更有益。

如何在关注任务和关注目标之间找到平衡

以下是实际中的研究方法：

坚持一项任务并付诸实施，始终保持将最终目标铭记于心中。靠整体操控，抽象思维和高级分类来提高自我控制。向着你的终点迈出第一步，道路漫长，需要更多的关注最终目标。
在对有可能失败的困难任务进行评估的过程中，保持对任务的关注。在评估过程开始的时候，关注每一个单独的步骤通常会更好。将最近一次失败和最终的目标相提并论，会摧毁你的动力──相反地，要少关注最后的成功而多思考独立任务。
一旦任务比较容易或者结束就在眼前，心理选择上目标关注会再次重现。这会增加积极情绪，减少负面情绪，提升对成绩的预知。

想象一下，这就像一个百米赛跑运动员。赛跑之前，视线穿梭在赛道与撞线之间；枪响瞬间，眼神凝固在地面与双脚之间。霎时，抬头，赛道，终点，只有一个目标：终点线。

只不过大多数项目都会比9.69秒长一点罢了。

网站活动类项目用户体验的总结

regon — 2009-01-21 22:41:21

当接到一个活动的时候，不管是什么类型。作为一名UE应该明确活动三要素。（只要遵守了活动三要素，就算你的框架不好，引导不好。至少活动不会跑题。）

活动三要素
活动目的：活动希望达到的目的
诱因：赠品，利益，兴趣爱好，连带推动
引导：友好的引导

避免无趣的活动
避免繁琐的注册，展示产品，
避免用户一眼看透你的商业目地
避免消费者雷达
合理利用人性的弱点，好奇，同情，虚荣，满足，表演，从众，认同，窥探，欲望，抵抗，自我保护

活动的后期维护
活动好比“一棵小树”，上线了就代表你把他栽到了地上。需要对它浇水，时时爱护，才能保证小树沐浴在灿烂的阳光下。
1 活动内容页及时的更新
2 活动结束后，结束提示页要做到，友好性，目的明确性
3 本站以外的链接是否及时的更新了
4 别忘记论坛，博客等别推广地方的信息保持同步

主动引导用户行为：顺着需求方的思路，和自己的以往经验做出的用户行为判断

被动引导用户行为：当用户不接受主动引导时，其实是用户心理排斥的一个反应。要设计出新的方案，尽量挽回用户。

内容关联不能随便摆放？

目的：内容关联，是我们站在用户的角度上思考用户还想看哪些资讯。

看看图例，你会更加清楚
A 型　－ 关联内容在首页：首页进行内容关联。小型活动，或是你自己都觉的活动没什么意思，就用内容丰富它吧

B 型 －　关联内容在活动结果页：活动很好玩，目的很明确，何必在一开始就分散用户注意力呢。

C －　哑铃型：活动很平凡，内容不是很丰满，处于A,B型中间。最安全，但也是最保守的方案

主流互联网公司的产品项目流程

ryansigma — 2009-03-01 14:09:44

偶然看到的阿里巴巴一张产品设计流程图，对比了一下目前mtime的产品流程设计，发现基本上是一模一样的。看来国内主流的互联网公司的产品研发流程基本一致。我也简单讲解一下，说不定可以帮助到有志成为互联网UED设计者的后来人。

点击看完整大图

这套流程不知道是不是从美国人民那引进而来的，记得好几年前看了一本书，叫《用户体验的要素》，当年看完了可以说一头雾水，不知所云。作者说的“战略层、框架层……”云云，最后还画了一张类似楼房设计图的画，来解释整个UED的设计流程，现在回想，实际做下来，也不过就是上面这张图的流程而已。

首先，需求分析

需求来自于多方面，比如公司的战略目标，UV或是P/V；也可能是商业需求，比如放入购物车的转化率或是活动参与率；更有可能来自一些用户的呼声，某些活跃用户慨叹“有了XX功能就好了”之类的。但是最有可能的还是需求还是来自于历史数据的总结，比如某产品明显没人用，或是用户不活跃，那么这个产品就是需要优化的。有时候需求甚至来自于“XX网火了，它的模式是否能复制？”这样的理由。总之，作为一个产品设计者，不要幻想你就是在那想最牛的设计是什么样的，然后画个原型出来一鸣惊人一把，绝大多数的时候，新产品或是优化的需求都是跟着公司的大方向在走，有时候需求的收集甚至是挺痛苦的事情。当然也不尽然，如果有用户访谈的话会有趣不少，从中收集的需求也往往会让你很是吃惊，用户访谈的问卷设计也是一门很大的学问，有时间可以再详细的写写。

总而言之，经过需求分析，并且拿出历史数据来证明你的论点，你可以提交一个新产品或是产品优化的报告了，这个报告可以是PPT，也有可能是个流程图，拿着这个报告去跟团队PK吧。

原型设计

有了需求，就可以真正开始着手设计了。最开始的原型设计是低保真的，可以拿纸画，但是只能给你自己看看；大多数情况下还是使用visio、fireworks等，这些家伙有个缺点就是只能展示一下样子，没办法展示交互；最新的解决方案是Axure RP，一个可以实现链接、弹出层等交互功能的web原型设计软件，最大的缺点应该就是不好用，不方便。如果是重展示的产品，比如门户网站的频道页，还是使用fireworks这种高视觉仿真的；如果是人机交互性特别强的产品，比如“群组里发帖功能”，那最好还是Auxure RP，画的时候是费点力气，开会讨论的时候可以省不少口舌。

原型设计的方法和哲学，基本就可以讲一本书了，这篇文章只讨论流程，不追求细腻了。

画完了以后团队内部讨论，再跟领导PK，也就是所谓的专家意见，经过一番激烈的辩论和修修改改之后，终于拿出了一个产品部内部满意的高保真交互原型作品。这还没到松一口气的时候，比较重要的产品的话，还会要求你要拿着这个原型去跟用户开体验会，会上你需要观察用户，并向他们提问，提问的问题大致就是“第一感觉是什么？第一个想要点击的是哪？最让你感到迷惑的是哪？”，这个对一个UED设计师是一个比较大的挑战，你需要足够的洞察力和判断力。其中还有一个经验之谈，受访用户大都会根据自己的经验乱提一通建议，然后自己略感洋洋得意，这时候一定要记得体验会的目的是收集用户的体验，而不是专门去听取非专家们的意见。选择性的摘取了用户的反馈后，你需要提交一个用户体验测试报告，报告中会提到这个设计最大的问题，哪里是流畅使用的障碍。之后再按照此报告对症下药，对原型做出修改。

再经过一番PK和讨论，恭喜你终于拿出了大家都满意的作品，作为产品设计师的你，最大的任务就算完成了。

视觉设计

拿着沉甸甸的原型，交给UI设计师，确保他们领会了你的精神，并且嘱咐任何疑问随时来找你。这里又有一个经验之谈，就是GUI设计师往往会对你的产品加一些他认为比较美观的东西，这个时侯一定要毫不手软，坚决砍掉。一定要秉持的一个理念是，GUI设计师不应该在原型体验基础上，增加任何附加元素，这是对最初的用户体验的一种伤害。举个简单的例子，你写了一个栏目名叫“粉丝群”，他为了美观又在栏目title下加了一个英文的“fans club”，这个就是增加了不必要的附加信息。

视觉设计肯定也要经过一番讨论和PK，UE设计师在其中的角色就是把关者，一定要捍卫自己的体验设计，这时候对自己产品的深刻理解非常重要。

html切割

对UE设计师来说乏善可陈，这个时侯最好是开始着手为开发组书写需求文档。

开发

文档写好了就和开发组的同仁开需求确认会，把你要实现的功能讲清楚了。开发过程中，UE设计师要做的就是答疑。

内测版上线

测试组的同事测好了，就会交给你验收。你需要做的是看看开发的同事是不是真的按照你写的需求文档上那样，弹出窗口，或是向下展开。

注意这个环节中有可能再来一次用户体验会，你需要做的也和之前差不多，可能唯一多的一样就是真诚的祈祷，不要提出很致命的产品流程缺陷，那就前功尽弃了，虽然不至于推倒重来，但是需求变更确实是件麻烦事。

产品上线

终于上线啦，欣喜的看着用户讨论它的同时，你有可能需要配合业务部门组织一下新产品的推广，当然只能作为辅助啦。

然后再开始观察历史数据，收集用户需求，提出优化……循环啦。

传统企业怎么开展b2c项目

全胜 — 2009-03-01 15:22:19

前段时间写了一篇：“传统企业老板做电商的出路”，后来有几个人在QQ上问我，传统企业怎么样才能做好电商，我回答说，传统企业最好做电商投资。因为那时自己对传统企业做电商感到很失望，也迷惘了一阵子。后来认真一想，这样回答有些偏面，传统企业如果能很好利用电子商务，那竞争实力是很强的。

传统企业做电商的优势在于产品这一块，那怕他自己没有生产产品。做起产品来，无论从产品款式设计、产品质量控制、产品库存管理，都是做得很好的，电商人士无法比拟。

产品线，我一直认为是做电商最重要的部分，产品质量好，产品外形漂亮，是电商的核心竞争力。而价格、库存、服务、物流、用户体验都是围绕产品拓展开的。产品是第一关、是基础，传统企业做电商在第一关就强于电商人士了。

传统企业做电商，最大的困惑在于不知如何去做，原因在于传统企业不懂技术、不懂设计、不懂互联网。就像电商人士不懂一个产品是怎么出来的一样，包括我现在还很好奇一个箱包要进行多少次工艺才能出来一样，箱包制作成本、时间、人员我更无法去估算。平台的运营和产品的营销是关键，电商人士强于传统企业。

上面是探讨传统企业做电商的优势与劣势。全胜下面和大家探讨传统企业如何去开展电商项目。

一、物色电商人才，这个是绝对关键。在人才未到位之前，不要开展任何网站线的进程。怎么找人才？最好的办法是找专业的人才腊头公司或电商服务公司（如广州博商）来推荐。而老板所要看的，是人才的适应性，能否适应老板的性格，能否很好相处及沟通。

在这里提示一下，传统企业做电商常范的几个错误：
1）传统企业一般第一步是做网站平台，以为做平台是最紧要的，卖产品那能没有平台呢？我认为这是错误的观念。做平台容易，做好平台难。而传统企业对平台的要素不了解，这时，最容易被一些网站建设公司或所谓的电商系统公司给忽悠了。好些企业花了血本买回来一个垃圾的平台，还当作宝贝一样对待。一句话总结：被所谓的公司给忽悠了；

2）到人才网站花钱做招聘广告，然后来了一大堆人。这时，老板就开始选人，交流再交流。据我接触的一些老板的经验告诉我，他不会问什么专业知识，一般会问你怎么去做这个项目，怎么去做推广等等。印象最深的一次，老板问我“怎么使他们的网站能卖产品”，我跟老板说到“BtoC”，他问我什么是“BtoC”，我到时就朦了。最后能应聘上的应该是老板眼中的人才了，这人才的风险是很大的。一句话总结：被所谓的人才给忽悠了；

二、项目分工，这个是绝对重点。没有分工，在运营过程中肯定会出现我正文开头提到一篇博文中的情况，对整个项目发展很不好。怎么分工？老板管好你的强项产品线，电商人士管好你的强项网站线。这样的组合，即有老板实干家的稳重步伐去做产品，又有电商人士梦想家的心态去做网站，优势互补，各占其位，是最好的选择了。至于电商人士怎么去运营网站，东西太多，这里就不讨论了。

三、总体考核。在资源和资金明确的条件下，让电商人士去分配资源和资金。什么都让你选择了，你总得给我一个具体实施方案和期望目标吧。有了这个，传统企业可以从宏观上去考察整个项目的运作情况，发现不对，可以暗地找专业公司去评估整个项目的进展，从而整个项目在自己的掌握控制之中。

以上简单地探讨传统企业如何去开展电商项目，还有很多不足的地方，请同行的朋友赐教（互联网拓展人脉群：1583802）。我想，只有更多传统企业去开展电商项目，整个电商行业才会繁荣起来。目前，电商行业最缺少的就是电商方面的人才，希望各位电商人士与我同行，沉下心来，努力实践和学习，早日做一个电商行业的精英人才，为电商行业贡献全部力量。

项目反思

CC — 2009-03-08 03:49:23

这两个礼拜做了个项目，不得不承认有点失败。虽然本身的需求不确定性，导致小组人员非常被动，一定需要和客户反复确认，而客户往往又会由于这一版的设计而产生新的设计要求，最让我被动的是，本身的设计是平面设计，小组成员中没一个是平面设计出生的设计师却被要求这个项目的平面设计要求最高。让我非常地无奈。但是我想我最大的问题就是对这个项目本身的不满情绪，导致我消极应对了整个项目上进度上的管理。

不过还好，人们总是从失败的项目中可以总结到教训的。这个项目让我确实学到了不少东西。

切忌需求模糊的情况下开始工作。千万别听信什么“你们先做，稍后我来修改”。
切忌在短期项目中尝试新的技术。千万别把新技术带到为期只有一周的项目中去做，哪怕效果再炫，没有完成，就是没有完成。
切忌带着不满情绪去处理项目。项目的失败只能说明作为管理者的失职，负面情绪显然不会带有什么好处。
切忌用对的人去做错的事。空闲的时候，可以让一个不擅长平面设计的人来做练习，可是当要求很高的时候，别指望交互设计出生的人做出让平面设计出生的人满意的设计作品来。
在项目延期的情况下，必须尊重客观实事，不能带个人愿景去处理事情。
作为一个管理者，必须公平公正，否则极易出现企业“反淘汰”情形。即由于员工与企业组织的价值观发生冲突，会造成诚实的员工求去，不诚实的员工反而留下。

创业公司的项目管理困境

人月神话 — 2009-03-29 05:05:26

原文:http://www.javaeye.com/topic/336479

公司是一个创业型的公司，对于公司项目管理的现状，我认为存在如下的问题

没有测试人员，清一色的开发人员，我跟boss提过这个问题，他认为功能比较简单，而且不是很好测试，不需要测试，而且厉害的测试人员不好找，最后在我的坚持下还是让一个开发人员兼职来做测试了，但是测试的也只是产品中的一个部分而已。

注：在开发团队的专职化分工中，测试是最需要优先独立的工作岗位。在团队早期可以是需求分析员兼职测试工作，还不行的话可以是开发间的交叉测试，但是最怕的就是自己写的代码自己测，正如医生往往无法看自己的病一样，会犯很多同向思维的错误。

公司没有组织架构，我认为需求分析、架构、设计、测试等人员角色要明确，同时要分成几个小组，每个小组负责一块，但是boss的意见是，我们是创业型的公司，大家都是平等的，不需要搞这些，大家积极性很高，一起做就可以了。所以，公司只有boss和技术总监有头衔和分工，其他人都是开发人员，遇到任务就挑几个人一起做。而且，技术总监的话有决定性的作用，其他人都是干活的，遇到问题，都找技术总监。

注：在测试分工后再需要分工的就是需求分析工作。需求分析在软件开发中具有很重要的地位。很多软件开发的问题都是需求分析不到位，导致后续大量的需求变更和范围蔓延。需要分析更多的是需要从业务和用户的角度来看待问题，而开发人员往往很难做到这一点。

以前任务没有详细计划，只有到阶段性计划，比如到什么时间做出什么东西出来，结果也是老是拖期。我说这样不行，需要把计划细化下去，细化到每个人每周做什么，boss接受了，但是定了计划，结果还是没法按时完成，也很郁闷。其实是因为设计阶段没有搞清楚要都要做那些事情，任务定的不够全。

注：没有计划原因往往并不是不想做计划，而是团队无法做出一个切实可行的计划。而无法做出可行计划的原因则是团队无历史数据的和经验的积累。无基本的一些项目管理方法，变化再快也需要做计划，通过变化来反思计划和估算如何改进。

公司的保密措施，公司对于下面员工防范的心还是很重的，核心业务只有技术总监知道，其他人也是只知一二，所以就导致，大家开发的时候，每个人只是搞一块，集成到一起就遇到很多问题，这点我也提过，尽量让大家每个人精通自己的部分，熟悉整个组的任务，了解整个项目的情况，这样做起事情起来才会主动考虑全局的内容，但是效果好像不明显。

注：完全不需要每个人都要了解所有的功能模块，但是每个人需要了解整个系统所涉及的基本业务和背景。集成出现的问题往往是跳过了架构设计，没有清晰的定义清楚组件和接口。

公司的作息时间。经常加班，以前加班周一到周五加晚上，周六一天，后来改为周一到周四的晚上，现在项目已经一年多了，都是这样度过的，大家都是疲惫，但是boss也不管。加班的主要原因是老拖期，boss很不满意。同时，每天有很多人迟到，大家迟到好像已经习惯了，我算了一下，有些人迟到的时间比加班的时间还要多。我是想建议boss干脆别加班了，让大家上午按时加班得了，但是我无法说出口，免得boss怀疑我不想加班。

注：普遍的一种现象。再次可以回顾在敏捷里面的严格记录下，每日反馈的40H工作制的意义。不加班的可行性正在于避免拖延，日事日毕的严格纪律执行，高效率的工作。

以前做了一年了，从来没有好好集成测试过，我提过意见说要持续集成，但是boss认可，但是没有采取措施，后来在我的强烈建议下开始找人持续的集成测试。公司还有很多模块，因为没有测试环境，做了很长时间，一直都得不到稳定。

注：又是敏捷的重点，持续集成，每日构建和冒烟测试。有效的降低项目后期风险。在软件开发中我们需要的是可视化的进度。迭代，持续集成，看板，FDD都是尽量使项目进度可视化的方法。

最后说一下，我以前做过4年的项目经理，来到这个公司也只是负责某个模块的开发，本来我也不该多嘴的，我以前提过一些项目管理的建议，boss都不认可，我也懒的说了，后来定的目标老是实现不了，boss才想起来，让我来协助技术总监把项目管理搞起来，但是呢好像我的想法和他们的想法总是有一些差异，而且底下很多员工都不喜欢项目管理（谁也不想被人管着吧），所以呢，很多措施也难以实现，我的想法是稍微规范一点，boss的想法是尽量简化，发挥大家的积极性就可以了。但是，我觉得激情的特点是短暂的，不能持久，如果一个几年的项目，靠激情是无法支撑的。所以，我还只能尽量的提一些建议，如果不接受，也就算了，懒得管了，混吧。

注：一个人无法改变一个团队，当所有人都不去寻求改变了的时候，团队文化基本就停滞了，大家都是得过且过的态度，团队自然也无生命力可谈。

推进项目的诀窍

panda — 2009-03-20 13:00:24

和大家明确了KPI和项目计划之后，明显感觉大家是跑起来了。同样也看到了我们在项目推进中的困难，今天也正好说一下推进项目的诀窍。

首先是心态，创业的心态，主人翁的心态，不要问这个问题谁负责，问这是谁的责任，把梦想和目标当成我们自己的事情来做，自己为自己的梦想而奋斗着！这是推进力的源泉，我们是一支使命必达的团队。
推进力的最高境界，就是让大家自我推进。优秀主导者并不是把自己的方案灌输下去，而是说明问题，激发合作伙伴的潜能，让他们提供更好的方案。这是推进力的核心。典型代表就是L同学。我观察L同学总是不遗余力的解释问题的严重性和用户的困惑，让设计师和工程师自然而然的觉的，不解决这个问题，实在是太对不起客户了。（虽然L同学被我们戏称”L前戏”，L同学总是能激励合作者们提供超出期望的方案。）说白了，忽悠，也是种能力。
深入，再深入的挖掘问题。很多人随便两下就可以看出的问题，S同学经常用 “挖”“刨”这些词来对待。优秀的PD和UED不仅要刨根问底，还要带着刨祖坟的心态去对待问题。L同学的前戏很长，其实详尽的描述问题意味着他对问题深入透彻的理解，也有助于合作伙伴抽象出来看清楚问题的本质，其实是把大家的讨论抽象到更高的层次上了。 Heidi Share 给我的BLOG：Define the problem before solving it 这不仅仅是产品经理所需要具备的素质，更是UED所需要具备的素质。Design = Solve Problem ，问题都搞不清，还不如把自己给Solve了呢。其实只有挖准了问题，才能有真正的推进力，不然就真成了大忽悠了。
抽象思维的能力。大家（包括我）总是花了很多时间在讨论具体的界面方案，每当我们豁然开朗的时候，总是抽象了一下，方向做了些调整。我很担心大家陷入界面方案层面的思考太多，以至于没有时间去思考功能逻辑本身的合理性。所以陷入细节的争论之前，先抽象一下，讨论一下问题的本质，也许更高效一些。抽象思维能力在交互设计师的素质里也谈到了，同样适用于前端和视觉，这是深入挖掘问题的前提能力，不然，……

关于分工合作的职责问题，我不想花精力去划定明确的界限了，我们是创业的伙伴，我们是为共同理想和目标奋斗的人，而不是只关心份内工作的打工仔。希望，不仅仅是希望了，我们UED也一定会成为一支结果导向，使命必达的团队。

UI设计师在产品项目中需要做什么?

nick — 2008-10-13 09:35:53

随着规范的产品设计流程的引入,每一个岗位在产品设计中所起的作用以及所承担的责任越来越清晰,但是有些时候,我认为并不能因为清晰的产品的设计流程,给大家划清一个职能界限,做出一副这方面不关我的事,我只做好UI就好了.

按照一个常规性互联网产品项目流程走下来应该是:

1.制定MRD(Market Requirements Document).
市场需求文档。获得项目发起部门的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。

2.制定PRD(Product Requirements Document).
产品需求文档。进步一细化，这部分是PM写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有 UI/UE支持，出高保真的demo，开发将来可以直接用的那种。

3.用户分析报告
搜集相关资料分析目标用户的使用特征、情感、习惯、心里、需求等，提出用户研究报告和可用性设计建议。这部分工作也可和团队配合完成。时间与项目需求允许的情况下，更可以制定实景用户分析。

4.产品架构设计
这里涉及到比较多的界面交互与流程的设计，根据可用性分析结果制定交互方式、操作与跳转流程、结构、布局、信息和其他元素。

5.产品原型设计
就是将页面模块、元素进行粗放式的排版和布局，深入一些，还会加入一些交互性的元素，使其更加具体、形象和生动。

6.界面UI设计
如果很倾向于图形界面设计，这儿是你最喜欢的部分。但一定要结合循环讨论过的分析结果做设计，否则你的作品很难被人信服。色调、风格、界面、窗口、图标、皮肤的表现是本环节的关键。

7.界面输出
这方面主要由页面工程师与前端程序员配合,将界面代码化。

8.分析使用者报告,做出完善调整.
多部门共同参与的，包括可用性的循环研究、用户体验回馈、测试回馈。同时，UI人员也应该把一些可行性建议进行完善。很多设计师做了东西不喜欢改，这是一个大忌。

但就目前许多公司而言,拿到UI设计师手里的,就是一份什么说明都没有的VISO图,这给许多UI设计师造成一种错觉,觉得我只需要做效果图就可以了,对于其他环节一概不理,导致了在设计产品界面的时候,因为掌握的信息不足,设计出来的界面全凭个人喜好,但是当面对用户的时候,却是一点竞争力都没有.

我认为UI设计师在项目初始,就应该加入其中.包括了解项目的市场定位,盈利模式,竞争对手等等,而通过分析竞争对手用户界面,可以给UI设计师一个初步的图形概念,而通过参与用户调研,用户分析能够获取到用户特征,年龄,需求,喜好等方面的信息,这些方面的信息,在风格定位,把握上起到至关重要的作用.通过了解产品架构,知道什么功能应该做,什么功能应该突出,在参与了以上工作的制定后,相信许多UI设计师对自己所要设计的产品,已经是信心十足了吧.后期在通过分析使用者报告,用户反馈等方面信息,做出界面上的调整,这样一来,一个完善的产品就可以面市了,而这个产品,再也不是一个全凭UI设计师个人喜好所设计出来的产品了..