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

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

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

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

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

更多讨论尽在 [url]http://iamsujie.com/3000/3012/[/url],欢迎大家来讨论相关问题





 本文转自 iamsujie 51CTO博客,原文链接:http://blog.51cto.com/iamsujie/153799,如需转载请自行联系原作者


相关文章
|
11月前
|
前端开发 程序员 测试技术
程序员成长第十二篇:做好项目计划
程序员成长第十二篇:做好项目计划
77 0
|
存储 运维 架构师
架构师到底该不该写代码?
选取了一部分大家可能会感兴趣的问题,汇总此文。
912 0
|
项目管理
漫谈项目管理之:面对严重的技术问题,你应该怎么做?
  接到紧急电话,你匆忙的赶到用户现场。初步分析后,你大吃一惊:可以确定,这是一个方案设计阶段的重大失误,现在暴露出来,导致项目中的所有工作全面停顿。   此时此刻,作为项目经理,你马上要做那些事情?   你想到了什么? 组织技术人员进行讨论,对技术问题进行分析?非常好,这是必须要做的工作。
1385 0
接手新项目的感受
又要开始新的开发了,项目代码统计了一下,有2400多个文件,30多万行代码,而且这个只是系统中子系统的一个项目,整个项目几十个系统,每个系统内部又有几个子系统项目。
1024 0
|
敏捷开发 测试技术
敏捷开发中如何写好用户故事?
敏捷开发中如何写好用户故事?
3386 0