项目管理之规范化风险

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

人掌控技能的过程

---

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

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

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

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

交集与并集

---

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

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

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

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

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

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

对岸花香

---

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

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

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

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

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

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

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

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

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

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

如何决策？

---

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

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

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

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

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

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

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

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

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

角色的拆分的好处：

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

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

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

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

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

说来说去一大堆，其实就是一句话：

具体问题具体分析。

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