项目管理，你没意识到的“人”和“方法论”

最近慢慢在做一件事：把一些工作上的内容，变成一张张围绕关键字的知识图谱。当然，我知道，这是个非常大的坑，需要整个职业生涯来不断填补。

但是我想，这个还是很有意义的，不仅对自己，也对别人。而且我觉得，maybe可以找到一群有同样想法的小伙伴，一起做知识图谱，一起相互share？

花了两个下午的时间，简单的整理了一张有关于互联网中的项目管理的相关内容，主要包括：

• 项目的简单定义；（简单）
• 项目的简单分类以及项目分类的意义；（简单）
• 项目管理涉及的阶段以及各阶段中需要的注意点；（详细）

具体大图谱如下图：点击放大或者下载原图可以看的清，至于要不要收藏，就随意了。

 

看图的童鞋们应该会发现，以上的图，主要展开描述的还是项目管理中项目流程的相关内容，应该可以帮助到以下几类童鞋：

1. 对项目流程没有概念的童鞋，普及下基本知识；
2. 对项目流程有基本认知，但只知“点”不知“线”，心中对某些部分有疑惑的童鞋；
3. 对项目流程有完整概念，仅当作一个各流程注意点的梳理的童鞋；

当然， 整理项目管理知识图谱的终级目标不在于对项目流程的整理，而在于对不同维度的项目做分类整理，找出分别的核心、特点是什么，以便于在实际工作中做交叉借鉴。 而这个部分，就不在上面的大图中分享了，一来内容太多太杂，二来即使分享了也可能看不懂，三来是自己也没有整理出太多的分类，暂不献丑。

除了以上一些图的内容之外，下面我想重点提一下看似比较“空”，但细想下来非常“干”的几个点：

一、项目中的人，才是最应该被关注的

立项后，需要“人”来推进、来执行。有些项目只需要一个人就可以完成，有些项目需要很多人来协作完成。当然，在互联网里，已经没有多少事情是一个人就能跟全能勇士一样都搞定的了。那么，很多不同的人在一起，就容易出现很多问题，例如：

1. 相互不明白对方在说啥，需要一个能沟通到双方的 “翻译” ；
2. 相互不认可对方的观点，需要一个能考虑各方想法的 “平衡木” ；
3. 人会懒散、会惰怠、会不思进取，需要一个能合理鞭策众人的 “推进器” ；
4. 人会迷茫、会没目标、会没有安全感，需要一个随时出现的 “指路牌” ；
5. 人会生气、愤怒、互骂傻逼，需要一个能消除不良情绪的 “净化器” ；

…还有很多其他的情况…

以上，有可能会不同组合的出现在不同项目中或者多次出现在同一个项目中的不同阶段里，当然，依不同项目和不同项目组成员而定：

• 有些不解决，项目就没办法推进下去，例如上面的a；
• 有些不解决，项目可以推进但是比较迟缓，例如上面的c、d；
• 有些暂时不解决也可以，但某一刻爆发出来可能很危险，例如上面的b、e；

如果说，身处项目的“大家”还可以仅从自己的角度考虑问题，但是， 作为管理项目的人是万万不能把自己仅当作其中的一份子，而是要在适当的时候抽离出来，感知大家的情绪变化，作出相应的解决才可以。 

把项目里的每一个人比作水，项目比作船，水能载舟，亦能覆舟这个道理已经老生常谈了。

二、合适的方法论和工具才是最好的

这一点是用来怼以工具、以方法论为上的企业、团队或者个人的。网上很多文章、很多人都在鼓吹好用的工具和好用的方法论，但却从来不结合具体的背景和应用的场景，简直是耍流氓。

当然，工具和方法论本身并没有错，但容易错的，是用的人。还记得东施效颦的故事咩？

西施病心而颦其里，其里之丑人见而美之，归亦捧心而颦其里。其里之富人见之，坚闭门而不出；贫人见之，挈妻子而去之走。彼知颦美，而不知颦之所以美。

美人皱眉，依旧美；丑人皱眉，更丑。同一种行为，在不同人身上会有巨大的不同，使用工具和方法论也是一样的道理。

不同的公司，不同的项目，项目流程、参与的人员以及需要得到的结果都会有很大的不同，根本是没有办法用“标准”、“统一”的方法来一概解决呢？因项目制宜才是王道。

方法论上，典型的例子莫过于 敏捷开发 了。很多团队都非常崇尚敏捷开发，因为敏捷开发快速、高效、短平快，能够让资源合理使用并且团队沟通更密切。但是真的用过敏捷开发的团队，才知道其中的坑到底有多大。有关于这点，之后可以专门写一篇有关于产品迭代中的使用敏捷开发的文章。（ps：我说坑大，并不代表不好用，只是要做适当的适应性变化）

工具上，例子就太多了，例如：产品经理一定要用Axure、Sketch画原型啦、团队协作的工具一定要是Jira啦、禅道最好用之类的，这里就不再多描述了。

我知你深浅，你知我长短，合适自己的才是最好的。恩，我说的是工具和方法论。

三、不同项目之间具有借鉴意义

这点我说不太好，只能简单描述一下。项目的分类可以有很多：行业、用户群体、规模程度、复杂程度、主导偏向等等。看似完全不同的项目，很有可能在某一维度是同类，那么就存在有可借鉴的地方。

举个传统做法和互联网做法的项目差别：

一直都很火的摩拜、ofo，其实从公共自行车这个概念来说，并不是完全新鲜，n年前很多地方政府就已经推出了政府公共自行车，凭公交卡固定停车点借取和扣费。

但是从另一概念来说，又算是新鲜，通过互联网走量沉淀资金，至于资金用来干嘛，有很多故事可以发生嘛～

这个还是我在一开始说的，总结不同项目的核心、特色，将不同的项目用同样的维度或者通过同样的核心和特色联系在一起，然后再做广度的借鉴，才对实际工作有本质意义。

四、人人都是项目管理人

按照以往的说法，项目管理是应该由专门的项目经理来做，但是其实现在很多互联网公司是没有专门的项目经理的。不管是大公司还是小公司，都是由一个个的项目组组成，不同的组根据需要做的事情，更多情况下，其实是由某个岗位或者某几个岗位的同事（一起）兼顾。

那么就会出现一个好问题，谁来兼顾？无他，两方面因素决定

1. 项目的属性： 更加偏向技术、业务还是运营？复杂还是简单？大还是小？
2. 项目成员的属性： 是否更加会协作以及安排协作？能力是否合时宜的厉害？

举个相对“复杂”的例子：

某次产品迭代，为期1个月，主要的迭代内容包括：

• 移动端新增2个业务功能、优化2个业务功能；
• 前端新增1个功能、技术重构某个大模块A；
• 后端新增3个功能接口、技术重构某个大模块B；

你们觉得这里面有几个项目管理人比较 合适 呢？我觉得是 至少 是3个：

• 1个移动端负责移动端小项目的管理；
• 1个前端负责重构A的小项目管理；
• 1个后端负责重构B的小项目管理；

至于整体的产品迭代，有可能是以上三个人中的一个，也有可能出现第四个人选：产品经理。

当然，以上举例在实际情况中，也有可能出现只有一个人hold住的情况，但我是万万不提倡的。

举以上的例子呢，想说明的是几点：

1. 看起来再小的项目也有可能再细分成小小小项目，并且我希望大家能尽可能的把需要细分的细分出来，让更专业的人来做这部分的项目管理，毕竟即使再厉害的人也不可能懂所有细分的事情；
2. 对一个项目来说，项目管理人可以是一群，而不是一个，并且我建议尽量是一群；
3. 当然一群项目管理人会有一个协调性的问题，不过一般一群中会有一个人统领整个大项目的管理，如果没有，那么需要有这么一个人；

来啊，跟着我喊：

人人都是项目管理人！

人人都是项目管理人！

人人都是项目管理人！

啊～～快逃，有人丢臭鸡蛋了～

写在后面：

其实为什么会生出做自己的知识图谱呢，有几方面的考虑：

1. 自己一个个阶段需要做总结，以前多用文章形式写一个个点而不是框架系统性的知识。现在想要写框架，但又觉得用文章的形式写基本知识比较费时间，还是图谱快速又简单，不需要太纠结措辞又可以及时增改；
2. 很多比我经验浅的小朋友有时候就是需要一个能够讲清某个关键字的框架性东西了解全局，而我觉得市面上并没有特别好的内容；

当然，我更希望的是，可以找到几个一样愿意写知识图谱并且贡献自己图谱的人，无论是产品、运营还是开发，甚至其他行业的人，例如金融等，大家能够通过图谱来分享知识，给其他人的开阔思考问题的广度or深度。

#专栏作家#

killifer，微信公众号：killifer，金融资讯&工具类产品经理。脑洞大、笑点低、间歇性“有毛病”的理工科实力逗比少女。

本文原创发布于人人都是产品经理，未经许可，不得转载。