起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識項目管理，你沒意識到的“人”和“方法論”
最近慢慢在做一件事：把一些工作上的內容，變成一張張圍繞關鍵字的知識圖譜。當然，我知道，這是個非常大的坑，需要整個職業生涯來不斷填補。
但是我想，這個還是很有意義的，不僅對自己，也對別人。而且我覺得，maybe可以找到一群有同樣想法的小伙伴，一起做知識圖譜，一起相互share？
花了兩個下午的時間，簡單的整理了一張有關于互聯網中的項目管理的相關內容，主要包括：
- 項目的簡單定義；（簡單）
- 項目的簡單分類以及項目分類的意義；（簡單）
- 項目管理涉及的階段以及各階段中需要的注意點；（詳細）
具體大圖譜如下圖：點擊放大或者下載原圖可以看的清，至于要不要收藏，就隨意了。
【在新標簽頁中打開圖片，即可清晰查看】
看圖的童鞋們應該會發現，以上的圖，主要展開描述的還是項目管理中項目流程的相關內容，應該可以幫助到以下幾類童鞋：
- 對項目流程沒有概念的童鞋，普及下基本知識；
- 對項目流程有基本認知，但只知“點”不知“線”，心中對某些部分有疑惑的童鞋；
- 對項目流程有完整概念，僅當作一個各流程注意點的梳理的童鞋；
當然，整理項目管理知識圖譜的終級目標不在于對項目流程的整理，而在于對不同維度的項目做分類整理，找出分別的核心、特點是什么，以便于在實際工作中做交叉借鑒。而這個部分，就不在上面的大圖中分享了，一來內容太多太雜，二來即使分享了也可能看不懂，三來是自己也沒有整理出太多的分類，暫不獻丑。
除了以上一些圖的內容之外，下面我想重點提一下看似比較“空”，但細想下來非常“干”的幾個點：
一、項目中的人，才是最應該被關注的
立項后，需要“人”來推進、來執行。有些項目只需要一個人就可以完成，有些項目需要很多人來協作完成。當然，在互聯網里，已經沒有多少事情是一個人就能跟全能勇士一樣都搞定的了。那么，很多不同的人在一起，就容易出現很多問題，例如：
- 相互不明白對方在說啥，需要一個能溝通到雙方的“翻譯”；
- 相互不認可對方的觀點，需要一個能考慮各方想法的“平衡木”；
- 人會懶散、會惰怠、會不思進取，需要一個能合理鞭策眾人的“推進器”；
- 人會迷茫、會沒目標、會沒有安全感，需要一個隨時出現的“指路牌”；
- 人會生氣、憤怒、互罵笨蛋，需要一個能消除不良情緒的“凈化器”；
…還有很多其他的情況…
以上，有可能會不同組合的出現在不同項目中或者多次出現在同一個項目中的不同階段里，當然，依不同項目和不同項目組成員而定：
- 有些不解決，項目就沒辦法推進下去，例如上面的a；
- 有些不解決，項目可以推進但是比較遲緩，例如上面的c、d；
- 有些暫時不解決也可以，但某一刻爆發出來可能很危險，例如上面的b、e；
如果說，身處項目的“大家”還可以僅從自己的角度考慮問題，但是，作為管理項目的人是萬萬不能把自己僅當作其中的一份子，而是要在適當的時候抽離出來，感知大家的情緒變化，作出相應的解決才可以。?
把項目里的每一個人比作水，項目比作船，水能載舟，亦能覆舟這個道理已經老生常談了。
二、合適的方法論和工具才是最好的
這一點是用來懟以工具、以方法論為上的企業、團隊或者個人的。網上很多文章、很多人都在鼓吹好用的工具和好用的方法論，但卻從來不結合具體的背景和應用的場景，簡直是耍流氓。
當然，工具和方法論本身并沒有錯，但容易錯的，是用的人。還記得東施效顰的故事咩？
西施病心而顰其里，其里之丑人見而美之，歸亦捧心而顰其里。其里之富人見之，堅閉門而不出；貧人見之，挈妻子而去之走。彼知顰美，而不知顰之所以美。
美人皺眉，依舊美；丑人皺眉，更丑。同一種行為，在不同人身上會有巨大的不同，使用工具和方法論也是一樣的道理。
不同的公司，不同的項目，項目流程、參與的人員以及需要得到的結果都會有很大的不同，根本是沒有辦法用“標準”、“統一”的方法來一概解決呢？因項目制宜才是王道。
方法論上，典型的例子莫過于敏捷開發了。很多團隊都非常崇尚敏捷開發，因為敏捷開發快速、高效、短平快，能夠讓資源合理使用并且團隊溝通更密切。但是真的用過敏捷開發的團隊，才知道其中的坑到底有多大。有關于這點，之后可以專門寫一篇有關于產品迭代中的使用敏捷開發的文章。（ps：我說坑大，并不代表不好用，只是要做適當的適應性變化）
工具上，例子就太多了，例如：產品經理一定要用Axure、Sketch畫原型啦、團隊協作的工具一定要是Jira啦、禪道最好用之類的，這里就不再多描述了。
我知你深淺，你知我長短，合適自己的才是最好的。恩，我說的是工具和方法論。
三、不同項目之間具有借鑒意義
這點我說不太好，只能簡單描述一下。項目的分類可以有很多：行業、用戶群體、規模程度、復雜程度、主導偏向等等?？此仆耆煌捻椖浚苡锌赡茉谀骋痪S度是同類，那么就存在有可借鑒的地方。
舉個傳統做法和互聯網做法的項目差別：
一直都很火的摩拜、ofo，其實從公共自行車這個概念來說，并不是完全新鮮，n年前很多地方政府就已經推出了政府公共自行車，憑公交卡固定停車點借取和扣費。
但是從另一概念來說，又算是新鮮，通過互聯網走量沉淀資金，至于資金用來干嘛，有很多故事可以發生嘛～
這個還是我在一開始說的，總結不同項目的核心、特色，將不同的項目用同樣的維度或者通過同樣的核心和特色聯系在一起，然后再做廣度的借鑒，才對實際工作有本質意義。
四、人人都是項目管理人
按照以往的說法，項目管理是應該由專門的項目經理來做，但是其實現在很多互聯網公司是沒有專門的項目經理的。不管是大公司還是小公司，都是由一個個的項目組組成，不同的組根據需要做的事情，更多情況下，其實是由某個崗位或者某幾個崗位的同事（一起）兼顧。
那么就會出現一個好問題，誰來兼顧？無他，兩方面因素決定
- 項目的屬性：更加偏向技術、業務還是運營？復雜還是簡單？大還是??？
- 項目成員的屬性：是否更加會協作以及安排協作？能力是否合時宜的厲害？
舉個相對“復雜”的例子：
某次產品迭代，為期1個月，主要的迭代內容包括：
- 移動端新增2個業務功能、優化2個業務功能；
- 前端新增1個功能、技術重構某個大模塊A；
- 后端新增3個功能接口、技術重構某個大模塊B；
你們覺得這里面有幾個項目管理人比較合適呢？我覺得是至少是3個：
- 1個移動端負責移動端小項目的管理；
- 1個前端負責重構A的小項目管理；
- 1個后端負責重構B的小項目管理；
至于整體的產品迭代，有可能是以上三個人中的一個，也有可能出現第四個人選：產品經理。
當然，以上舉例在實際情況中，也有可能出現只有一個人hold住的情況，但我是萬萬不提倡的。
舉以上的例子呢，想說明的是幾點：
- 看起來再小的項目也有可能再細分成小小小項目，并且我希望大家能盡可能的把需要細分的細分出來，讓更專業的人來做這部分的項目管理，畢竟即使再厲害的人也不可能懂所有細分的事情；
- 對一個項目來說，項目管理人可以是一群，而不是一個，并且我建議盡量是一群；
- 當然一群項目管理人會有一個協調性的問題，不過一般一群中會有一個人統領整個大項目的管理，如果沒有，那么需要有這么一個人；
來啊，跟著我喊：
人人都是項目管理人！
人人都是項目管理人！
人人都是項目管理人！
啊～～快逃，有人丟臭雞蛋了～
寫在后面：
其實為什么會生出做自己的知識圖譜呢，有幾方面的考慮：
- 自己一個個階段需要做總結，以前多用文章形式寫一個個點而不是框架系統性的知識?，F在想要寫框架，但又覺得用文章的形式寫基本知識比較費時間，還是圖譜快速又簡單，不需要太糾結措辭又可以及時增改；
- 很多比我經驗淺的小朋友有時候就是需要一個能夠講清某個關鍵字的框架性東西了解全局，而我覺得市面上并沒有特別好的內容；
當然，我更希望的是，可以找到幾個一樣愿意寫知識圖譜并且貢獻自己圖譜的人，無論是產品、運營還是開發，甚至其他行業的人，例如金融等，大家能夠通過圖譜來分享知識，給其他人的開闊思考問題的廣度or深度。
#專欄作家#
killifer，微信公眾號：killifer，金融資訊&工具類產品經理。腦洞大、笑點低、間歇性“有毛病”的理工科實力逗比少女。
本文原創發布于人人都是產品經理，未經許可，不得轉載。
喜歡姑娘的風格
樓主的圖做得不錯，但是綠色還有搭配看上去十分辛苦。
也可以用IPMP的方式進行管理啊，那個體系不錯的。