产品设计体会(3012)如何做好“老板项目”

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

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

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

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

是的,当时就是这样。

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

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

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

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

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

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

真的这么爽?

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

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

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

产品设计体会(6001)几个项目的成败

回顾一下2007经历的5个项目,成功或失败在不同的阶段。

先简单描述软件项目的生命周期,其他项目也应该大致如此:战略规划,需求分析,开发,测试,上线,运营维护……加深体会了一个基本常识:问题出现的越早,越早调整项目规划,损失越小。

第一个是在压力测试阶段怎么也过不了,无法发布。我不是技术出身的,所以具体原因也不太清楚,感觉问题应该是出在系统设计上,测试的时候功能都跑的很遛,但模拟数千人同时使用的时候始终很慢,改了几个礼拜仍然没法解决,最后由于人力资源的问题,和考虑到这个项目的重要程度,只好把项目砍掉。

第二个是在需求分析阶段结束,因为集团的政策因素,项目转移给别的团队做了。这次可以说是完全不可控的,也让我加深了对“项目发起应该是‘从上到下’”的认识,无论哪个项目,没有上层强有力的支持完全就是白搭,而且自己努力很多会觉得很失落。

第三个是在市场扫描阶段结束,收集到的信息让我们觉得不值得继续做下去。一句老话:早一步是先驱,再早一步是先烈

第四个算是成功了,发布升级、运营维护一整套走完,这个项目从2006年底开始一直到现在,现在我也逐渐移交给同事,大家会继续做下去。这个项目是让我学到最多的,特别是到了项目上线以后,还有很多事情需要做,比如和客服、技术支持、财务以及其他在商业上合作部门的协调;对产品整体调整的需求管理;等等。

iamsujie补充:这个产品在2008年,几乎没有投入的情况下,帮助公司其他产品吸引了不少用户,而且自己也有几百万营收,很不错

第五个是和外部合作的项目,这是个非常牛B但挑战也非常大的项目,因为一些我无法控制的原因,不太顺利,最终延期了将近半年发布,而且也无法满足最早的商业目标,我做项目协调人学到了很多项目管理方面的知识,仅此而已。

产品设计体会(3001)产品与项目

产品和项目到底有什么区别,扩展开说,做产品和做项目最大的不同在哪里?产品经理和项目经理(都是PM,有时候自己都搞不清说的哪一个)职责的不同在哪里?一直困扰了我很长时间,直到2007年秋天,开始有了一点浅浅的体会,姑且随便说说。

有一个比喻,你找裁缝做一件衣服,对于裁缝来说就是一个项目,而服装厂要做一批成衣,那就算一个产品。现实一点的例子,阿里旺旺的E客服功能是一个项目,而阿里旺旺就是一个产品;网店版子帐号模块是一个项目,而阿里软件网店版就是一个产品。

项目是定制的,个性化的,为了满足一个或一批特定的客户需求;而产品是服务一个用户群的,通用的。这就意味着,项目要服务好那个特定的客户;而产品不能为了个别用户的需求去定制,必须考虑用有限的资源去满足更多的、能有更多回报的用户。

项目是相对短期的,较少后续工作的,可以结束的(称为“结项”);产品是相对长期的,不存在所谓的“结束”,只能是“生命周期完结”。所以不可能有一个已经“完成”的产品,只存在不断完善中的产品,直到这个产品被新产品替代,已经没有存在的价值,它才会“生命周期完结”。

所以,产品不能做成项目,但有的时候产品越做越发现,继续做下去的话,那些功能只能满足产品的部分用户,为了避免把产品做成项目的集合体而臃肿不堪,我们就需要细分市场了,这时候产品可能就要升级为“产品线”,下面按不同的细分市场,推出不同的产品,表现形式上或者叫版本、模块、什么都行,但本质仍然不是项目。一般来说一个互联网产品上线半年到一年后,再发展就要碰到这个问题了。

而对于两个PM,各自看中的基本修养也有很大区别。

Project M项目经理,看中的是执行力与控制力,项目经理决定谁来做,何时做,是正确的做事。他是接到一个任务,“我要把它完成”!

Product M产品经理,看中的是判断力与创造力,产品经理决定做不做、做多少、做什么,是做正确的事。他是产生一个想法,“我要把它实现”!

一个外部驱动,一个内部驱动。