人人都是产品经理——iamsujie

2007年底之前，也就是开始做产品设计师约1年以内，我一直只是很单纯的在做产品设计、以及大产品设计，在为产品所发起的一个个项目中，扮演的是一个设计师的角色，主要负责“做多少、怎么做”的问题，那会项目经理是开发经理兼任，他负责“何时做、谁来做”的问题。

后来公司发现这样的一些弊端：

对设计师的考核是产品的商业价值，比如用户活跃度等等，而这些指标和产品的用户体验关系极大，大家知道，想把产品的用户体验做到极致，让用户轻松，必然的代价就是我们受罪，特别是开发的同学要额外做很多他们看起来价值不大的细节，比如一个最简单的登录页面上的2个输入框，一个填帐号，一个填密码，想体验好一点，就要考虑如何限制输入内容长度，如何控制输入非法字符，如何给用户提示等很多问题。简单说一下输入帐号的长度控制问题，就又要考虑是点击“登录”提交表单时判断？鼠标焦点移动到密码输入框时判断？还是输入帐号时随时计算长度直接判断？……

开发同学的考核一般来说是项目的完成情况，Bug数量，很显然，如果他们做项目经理，矛盾就自然而然就发生了，开发的同学会倾向于简化项目，尽量少做、做自己熟悉的，使得项目顺利完成 & bug很少，但是做出来的东西商业价值不足、用户体验不好。

由于上述原因，公司决定让产品设计师兼任项目经理，这样对我们的要求就更高了，于是我也渐渐的有机会接触了项目管理方面的事情，发现这块“硬功”也是一个产品设计师必备的素质，于是，我们向着全能战士——产品经理，又跨了一大步。

话说一个事物必然有它的两面，如果你只看到了一面，必然说明你只看到了系统的一部分，我还是比较相信在哲学层面上，很多东西都是“守恒”，或者说“对立统一”的。那么这么做的缺点又是什么呢，留个悬念，后续在一些有关组织结构的文章里再做讲述。

回到本系列，先谈论了做产品与做项目的异同。在做项目的过程中，我体会到创业公司，或者大公司里的创业型团队，特别是对于互联网、软件行业，有一颗敏捷之心很重要，所以这部分里有不少关于敏捷的描述。此外举例了适合创业型团队的项目管理方法中的几个关键点，比如Kick Off、评审会，最简单的一句：计划与控制，就是项目管理。

大大小小的项目做了几十个，自然的发现另外2点提高效率的事情：流程与文档。

流程的作用，是把经常做的事情固化，以提高效率，下文有例子描述了简单的需求流程，再举个不好的例子，如果阿里有一位同事不幸去世了，那公司一定会起个紧急项目来处理这件事，而如果是华为，就可以走流程了。项目与流程是对立统一的关系，并且可以互相转化，后面也会仔细描述。

文档管理主要谈到了两块：一是模板管理，文档为什么要有模板？我们有哪些常用的文档模板？各个模板的目的是什么？相应的又应该怎么设计？举例说明了一些文档具体应该如何写，已经贴出来的有最最常见的UC；二是版本管理，提到了版本管理的目的，有哪些常用的版本管理方法及其优劣，顺便讨论一下文档轻重的问题。

这个系列还没有结束，这篇算是一个阶段性小结。

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

先来一点科普，做项目的目标无非是多快好省：范围多、时间短、品质高、资源省。但又要马儿跑又想马儿不吃草的事情是没有的，有理智的老板也都明白这一点，所以我们通常是在上述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民工必杀技——加班，天天加班，天天加班还不要加班费……我们期望的是老板看得到，公司有前途，明天会更好……

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

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

2008年夏，又培训了，《项目化管理》，每周上4天班上2天课还是有点累的，不过培训的收获也不小，整理一下。

整体感觉Eric老师还是很不错的，授课技巧很好，在项目管理方面也确实资深（十几年前在李嘉诚一个净利润1k多亿的项目中，就已经是一个子项目的高级PM），课程讲了较多“道”的东西，较少“术”的内容，需要听者有很深厚的功力才能收获更多，自己感觉有不少内容是听得懵懵懂懂，要点记录如下：

1.  课程网站：www.21pm.com，右上角有Eric课程精彩点。

2.  PMBOK的九大知识体系，应按照life circle理解，而不是9个模块分别理解。

3.  ABCDE经典游戏：

a)  A+有企业所有权，A是CEO有经营权；

b)  A要做正确的事：明确目标、提供资源、核查；

c)  B要正确的做事：上令下达、多快好省、帮A找到目标；

d)  CDE倡导提问文化。

4.  存在即有理！（不是存在即合理）

5.  项目型管理vs运作型管理

a)  项目：跳跃式发展，有始有终（毛泽东，打江山易，但在价值链上更重要）；

b)  项目老板最高境界：无为而治（德治？）；

c)  运作：常规，周而复始（邓小平，守江山难）；

d)  运作老板最高境界：大道无术；

e)  中国的传统：生产制造大国，擅长做运作型管理。（iamsujie补：这和农耕文明肯定有关系，而项目型管理明显有西方的狩猎、游牧文明的影子）

6.  项目三重限制：T（时间）、R（资源）、Q（质量、数量）：

a)  多快好省：数量多、时间短、质量高、资源少；

7.  项目要让两个人满意：Boss、Customer，但两者的目标往往是矛盾的！所以要Balance，达到win-win，项目要“物有所值”而不是“物超所值”！

8.  项目的大小级别：

a)  Portfolio（组合项目）>Program（大型项目）>Project（单一项目）>MD（交付件，通常15人以内、6个月以下）；

b)  MD往下再分就是WBS（任务、工作包、活动）。

9.  项目的三边六拍：边行动边计划边修改；拍脑袋、肩膀、胸脯、桌子、屁股、大腿。

10.  WBS相关：

a)  六把刀：

i.  先管理（追求：快、省）再产品（追求：多、好）：形成模板；

ii.  动名结构：动词模板偏管理，任务级；多年积累形成固定的名词模板，偏产品，工作包级；

 iii.  最底层作业：action，用工作量衡量（！=工期）；

iv.  暂不考虑资源限制；

 v.  头脑风暴：不批评、不排斥、不评论；

vi.  不排序：工作分解开始要“滴水不漏”，重完整性，不考虑流程。

b)  WBS做完，就：心中有树！叶子做完项目就完成，树枝都是模板！

c)  有经验的项目可以自顶而下，无经验可以自下而上。

11.  三点估算法：工作量，（最乐观+最悲观+最可能）/3，对比（1+4+1）除6的方法。

12.  项目预算（资源、时间等）中，B应该找A要一个备份资源，但尽量不要动用。

13.  action plan–>工作量–>关键路径–>工期–>Baseline：

a)  因事择人：把高手调入关键路径；

b) 工作串行多（不愿分解）消耗T，并行多（不善分解）消耗R；

14.  收买人心：团队为各自的任务买单，承诺最可能时间，任务分配矩阵的表格最后要老板签字！

15.  以人为本：软件项目的主要成本是人力。

2008年夏，参加了2天的名为《产品经理需求工程实务》的培训，和去年的《产品需求管理》培训内容大约有60%的重合吧，但经过一年，还是听出了大于40%的新东西。

有关需求：

Ø 需要（Need，客观上需要，解决方案）、欲望（Want，主观上想要，内心深处的目的）、需求（Demand）；用户经常跟你提他以为的Need，但我们要挖掘出Want，再转化为真正的Need可实现的Demand。

Ø 需求收集听的技巧：“聚焦于人们的期望而不是问题”，期望–>基本功能，问题–>增值功能。我的理解应该是：基本功能一定要听用户的，增值功能往往是设计师主导的。

项目管理范畴：

Ø OBS（Organization Breakdown Structure）产出物：项目管理的方法、体系；WBS（Work）产出物：进度计划；PBS（Product）产出物：产品模块；FBS（Function）产出物：用例。

Ø 项目计划，传统：功能–>工作量–>人力–>工期；SCRUM：迭代周期（一周~一月）–>人力–>功能范围。一正一反，很有意思。

Ø 项目每日站立例会，每个人只能说3句话：昨天做了什么？今天要做什么？碰到什么问题，如何解决，需要什么帮助？

Ø 功能点工作量估计：宏观–>专家法；微观–>执行者自评（最悲观 + 4*最可能 + 最乐观）/6。

综合方面的：

Ø 模仿 + 改良–>创新，随着时间的推进，“有可能遇到，但不要奢望”突破式的创新。

Ø 领导的四个层次（比较扯蛋的）：“亲力亲为”，“活着（松下幸之助）”，“活过（邓小平）”，“没活过也行（耶稣）”。

Ø 企业成功四个模式：拥有资源（国企），生意模式（ali），拥有核心技术（Intel），管理/营销强（P&G，Nike）。

Ø 要找到自己产品的“最”，人们只能记住“第一”、“最”。

Ø 自己的想法：IT公司要做的事情都是类似的，都有那么几块，但是每种职位做什么事情在各个公司都有所不同，并不用在意，只要每件事情都有人做就行了。这其实就是产品的用户体系里“权限”和“角色”的关系，所有公司都有那些权限，但是各自有独特的“角色定义”，在阿里PD的角色对应经典定义就是：部分“产品经理”的权限 + 部分“开发/系分/架构”的权限 + 部分“项目经理”的权限。