项目管理之规范化风险

 我曾经看过不少的软件项目管理的书,比如《PMBOK》,这些书中把项目管理拆分成N个环节,每个环节都有输入输出。除了一些敏捷开发的管理方式外,其它的方式,无一例外,都会产生大量的文档。这种生搬硬套的方式,带来极大的风险与浪费。

人掌控技能的过程


一个人在缺乏经验的时候,没有方向性的时候,喜欢做的,或者唯一能做的,就是模仿,跟小孩开始的时候,学说话,和学走路一个道理。小孩模仿自己的父母,而项目管理,模仿的,或是自己老板,自己上司,或是道听途说的大公司的管理模式,再剩下的,就是一些参考书式的管理模式。

不管模仿的对象对还是错,优还是差,无论如何,在没有任何的方向的时候,如同你在虚空中,有一小块地方给你站着,你会非常有安全感,那怕那是一坨屎。有也比没有强。

在模仿者里边,有人会习惯于模仿,把模仿到的,无论对错,优差,都变成了习惯。而不是当成是探索。

同样从最初的模仿者里,也有人会总结提炼,结合自己的实际情况,具体情况具体分析,使用适合自己的管理方式。

交集与并集


我们说普遍性的产品,一定是简单的功能,通用的功能,因为这种普遍性的产品,而向的,不是你一个人,而是所有的用户,不是满足所有用户的并集,而是要交集。世界上是没有任何一家公司的产品能够做到满足用户需求的并集的。

既然是交集,那就是说,你有很多的需求,这种普遍性的产品是无法做到,或者需要你花费更多的成本去间接实现的。

从交集的特性可以看出来 ,比如:{1,2,4,}和{2,5,7,8} 两个集合的交集是2, 没有任何两家公司的是一样的,也就是说,没有任何两家公司的集合是完全一样的。既然存在这种客观性,那么,生生把其它公司的是管理模式,要么是自己碰到的问题,对方没碰到,还没有解决方案。要么是,拿过来,自己本来就没这种问题,还学着别人做,解决自己本就不存在的问题,那就是一种浪费,极大的浪费。

从执行的资源有限的角度,就注定决策的方向是交集。但并集一样是存在的。这种并集的行为,存在于理论的书本之中。理论研究的目的,就是穷尽所有可能性。这是从理论研究的方向就注定了无限接近于并集。如上边提到的参考书《PMBOK》。

而我们现实中,是否可以采用并集的解决方案?答案是,你如果想体验一下如何把一家公司搞跨,或者把一个项目搞跨,那就试试吧。

任何现实的执行中,必然面临的一个问题,那就是资源的有限性。有限的资源下,做事情必然是需要收敛,而不是发散。以并集的方式做,也就意味着,有相当大的一部分工作,其实是不需要做的。如果真要在软件项目中去做,这跟拿钞票去点篝火没有任何区别。

对岸花香


人都有追逐完美的特性,以为补上自己缺的,就完美了。

但凡在这一种心理起作用的时候,人其实就容易失于理性。这个时候,站的视角,更多的是一个信徒的视角,大家都知道,信徒大都是盲目与迷信的。

对岸花香的一种心理是对已,自己对事物的判断失准问题。这里边还存在另外一种现象。吹嘘对岸花香。比如十几二十年前我们常听到的段子:一些出国回来的人说,国外的月亮比中国圆。

这种心理的话,不是出于补自己的缺,解决自己的问题。其背后的是彰显自己见多识广。这种是赤裸裸的吹嘘。比自己看到的对岸花,觉得花更香,更为不理性。

这样来说,对岸花香,有点抽象。举个软件工程的例子。

不管是哪一种市场营销,企业管理的书上,都提倡用户第一,用户是上帝,用户的需求一定要满足。 而在软件开发项目中,一个像点样的需求,从设计到实现,成本都是以万为单位,一般般都过10万,如果你做的是软件项目,就算是互联网项目,你的用户跟你提我需要什么样什么样的功能,这是我们公司需要的。你这个时候会满足他的需求吗?

我们常看到的把用户当上帝的例子都是,在礼貌上把客户当贵宾,在生活上照顾无微不至。对用户的打骂,一定要笑脸相迎.... 这时候大家应该注意到了,这成本是很低的,最多就是几百块钱的需求。而且满足这些需求,即使收益无法预期,起码对自己当下的运营成本的增加,其实是微乎极微的。

而在一个动不动就以万为单位来计算的需求里,你真的确定你要都满足客户的需求吗?

也许有人会说,真正做到把用户当上帝,是挖掘用户需求的痛点,解决本质东西,不是解决表面问题。

没错,对岸花香,看的就是表面。我要说的,就是,不要看表面,看实质。

如何决策?


以解决问题的角度来决策。

比如在创业公司中,特别是互联网公司,这是一种先给别人货,别让用爽了,再收钱。或者根本不从使用者身上淘钱,而是猪在用,从狼身上要钱。

这种软件项目,软件外包的工作模式,有着非常大的区别。软件外包,甲乙双方,有需求,有合同,工程完工后,再收钱。起码有法律上的合同来约束拿到钱。

做互联网产品,最重要的,不是把东西做出来。而是做出来的东西,有人用。如果做出来的东西,没人用,全部的钱将打水漂。

当然,没有任何产品经理敢打包票,说自己设计的产品,到市场上,一定会受到欢迎,热捧。区别在于,有的人,加了验证环节,有的人没有,毕其功于一役,成则升天,死想当鬼雄。鬼雄当不当得成,我只知道,先烈是一定要当的。

互联网产品的软件项目,解决不确定问题,贯彻始终。而传统软件教育中提到的管理方式,比如说,瀑布模型,简单点说,就是把整个工程,拆分成多个环节:需求调研,需求分析,概率设计,详细设计,开发,测试,上线。

如果做的需求,符合大众的需求,也能收回来钱,这个开发过程,没有任何的问题。但是,万一,其实不是万一,应该说是,大多数情况下,花了几个月,甚至一年的时间做出来的东西,得不到认可,没人用,或者已经有竞品出现。你当如何?

如果一家互联网创业公司的老板对软件开发模式不熟,同时自己招来的人,也没有创业的经验,则很多人会生搬硬套这种管理模式。

比较常见的,除了生搬书本,还有生搬大公司的工作模式。比如,一个几个人的团队,还分出前端,交互设计,UI设计,产品经理,后端,架构师,项目经理。一个人一个角色负责一个小环节。

角色的拆分的好处:

1、 相对于通才,专才会更专业。

2、解决流水线上的不同环节的时间价值不同,瓶颈问题。

比如一家几个人的小公司,其它电脑小白使用电脑的问题,可以由程序员兼职解决。但当公司的业务量上去,需要开发更多的东西,程序员已经超负荷的时候,再让程序员来做这个工作,就明显不适合。这个时候,如果公司人数到一定程度,可能就需要配备一个专门的网管来处理这种事情。但这种拆分角色的提前是:1)两者时间成本不同。2)已经出现瓶颈。

而如果一个搭团队的人,没有这种意识,而照本宣科的方式,去照搬大公司的那一套,理由是:

淘宝,百度,微软...大公司就是这么干的。

说来说去一大堆,其实就是一句话:

具体问题具体分析。

这句话也是说起来容易,难在“分析”这两个字。能够做到专业的分析,是需要相应的知识与经历的。没有这些为基础,妄谈具体情况具体分析,其实是没有意义的,还不如去模仿,碰到问题,再解决问题。至于说如何分析,可以看看毛泽东写的《中国社会各阶级的分析》。一个分析中,如何囊括要分析的因素,分析的深度,都是学问,不是凭空想像的,也不是天生的。

你可能感兴趣的:(项目管理之规范化风险)