項目管理工具,究竟緣起何處?(項目管理工具是什么)
前幾日在知乎看到一個問題:Trello等項目管理工具體驗如何?
本來利益相關太高不準備答,因為哪怕通篇說Trello好,有一句不好都有貶低對手抬高自己之嫌疑。
但是我發現題主問的是Trello等項目管理工具體驗如何,我個人理解,題主是想問:Trello這類項目管理工具的體驗——恐怕是對項目管理工具沒有了解的。那么正好借此機會,向大家介紹一下項目管理工具究竟緣起何處以及究竟Trello是否能夠代表項目管理類的工具。
01 這類產品都脫胎于看板式項目管理
首先,既然我們把這些產品歸為一類,那么就得明確他們的共性——都脫胎于看板式項目管理。那就究竟什么是看板式項目管理?
看板管理,常作“Kanban管理”(來自日語“看板”,カンバン,日語羅馬拼寫:Kanban,原名:傳票卡),是豐田生產模式中的重要概念,指為了達到準時生產方式(JIT)控制現場生產流程的工具。準時生產方式中的拉式(Pull)生產系統可以使信息的流程縮短,并配合定量、固定裝貨容器等方式,而使生產過程中的物料流動順暢。 看板管理方法是在同一道工序或者前后工序之間進行物流或信息流的傳遞。
通俗點說,就是源自車間生產的看板:
車間流水線上,一環扣一環,所有機器同時工作:
當2號機器的生產效率比較低,1號機器比較高的時候,就會堆積1號機器的產出物,造成積壓庫存、降低生產效率等問題。
所以,車間生產中,需要去判斷2號機器所積累的任務量,再決定1號機器是否繼續生產。如果2號機器積累的任務太多,1號機器就停產。當然,真正的車間生產要復雜很多,我只是舉個簡化的例子。
引一段對看板式任務管理的評價:
看板在各個行業領域的應用目的不同,所帶來的優勢也可能不同。基于看板的模型,有一點是很明確的,看板能夠將庫存量和實際消耗量對齊,限制生產中任何一點的過量庫存。只有當庫存消耗時才發出請求信號,讓生產端開始交付新一批產品。用需求量來控制生產率,讓整個過程變得可視化,避免生產端產能過剩。
而后,這套生產方法在其他領域發揚光大了。比如——軟件開發。
這套東西,在過去長這樣:
而在今天,就成了我們熟悉的各類看板式項目管理工具,例如Trello,以及Worktile。
隨手截了一個我司的bug反饋看板,是不是跟上圖換湯不換藥?
02 流程化是項目管理工具的內核
了解了看板的起源,我們可以來談談項目管理工具了。
先說一點,不少人對任務管理工具的理解局限于ToDoList,這是極其不準確的。這類項目管理工具的最大優勢,在于——流程化。而流程化也是一種思維,這種思維是項目管理軟件能帶來的,最寶貴的財富。ToDoList只是發揮了card/list這一級別的功能,最關鍵的board反而沒有體現。而card/list/board三位一體,才能構成看板式項目管理。
舉個例子:
我給你一個項目,把大象裝進冰箱里,你打算怎么辦?
你可能會想到宋丹丹老師說的——冰箱門打開-大象放進去-冰箱門關上
但是沒有這么大冰箱怎么辦?
我們需要這個大冰柜
大象從哪里來?
我們要找個買大象的渠道
運輸怎么搞定?
得找一輛大卡車
有沒有找到一種似曾相識的感覺?在工作中我們常會面對這種困擾——問題總是考慮不周全,實施過程一團亂麻、漏洞百出。這,其實就是因為缺乏流程化的思維。
例如我們得到了這個任務。那么粗略的想一下,大概分這樣幾步——
大象來源-運輸-場地準備-物料準備-實施-后續步驟。
而每一步,又可以細分,例如大象來源——
法律相關-資金準備-前期聯系-合同等
有了這樣的步驟,即便會出現狀況,也能在最大限度上保證項目的順利實施。同時,如果前期準備不到位,后期的計劃便相應的調整或者延后。這就是流程化的本質。
皮一下,設計了把大象裝進冰箱的項目
流程化思維,最好的應用場景就是團隊的工作。因為多人配合的情況下,企業會面臨很多問題,諸如:
- 信息不對稱
- 責任不明確
- 任務進展難以把控
- 項目流程經驗難以沉淀
- 項目執行過程無跡可尋
- 其他……
而看板式項目管理工具,能夠有效的解決這類問題。
03 這類項目管理工具的體驗究竟如何?
要談體驗,自然離不開需求。現在企業的工作和配合是十分復雜的。看板管理工具面臨著很多挑戰。既然我們也要討論Trello能否代表這類項目管理工具,那么我就以Trello舉例。
首先,看似全能,實則無能
這是Trello的一個空白看板,這里面什么都沒有,當然也就意味著你可以配置出任何你想要的項目。但是那只是理想情況下,現在如果一個產品團隊,想要以此實現需求管理。你覺得要怎么創建看板?
我相信,項目管理能力也好、流程化思維能力也好,永遠都滿足二八原則。能夠快速上手的人永遠都是少數。如果你很不幸的是那“八成”,那么這個空白看板的體驗可以說一點也不好。反倒是國內許多廠家,都引入了模板的概念。在一定程度上解決了不知道如何配置的問題。
Worktile的項目模板
其次,標準化的產品如何適應非標準化的需求
這個問題的難度,要比第一個問題復雜很多,可以說是整個SaaS行業都面臨的問題。
個人產品,尚不能滿足所有人的需求,面對企業復雜的需求,標準化的SaaS產品就更加顯得有心無力了。
例如:
任務的流程問題——即一個任務完成某一進度之后,流轉到哪里?Trello的邏輯是沒有流轉,通過手動拖動即可。但是如果是這樣一個看板,你又恰巧是新同事,你知道怎么拖動嗎?
有人會說讓設計師自己認領。
這么做沒問題。
在設計上有一個復雜度轉移的概念——
過去遙控器按鈕很多,但是電視上菜單很簡單。 現在遙控器就上下左右確認這幾個按鈕,但是電視的菜單復雜了很多。 復雜性從遙控器轉移到了菜單。
上面的做法,就是將復雜度由產品轉移到了制度上,制度的學習、規范,成員的犯錯,無疑都在降低著協作的效率。好的產品體驗,應該是降低用戶操作的復雜度的。如果我為了一個看板要多一項制度,那這可以說很不友好,體驗很差了。
類似的問題,不勝枚舉。例如:
- 利用不同維度對任務進行篩選;
- 項目的分類統計;
- 不同形式的看板展示;
這一點上我在Trello上沒有看到,但是國內主流的項目管理工具一直在試圖解決這些問題的。
在Trello的官網上,我看到這樣一句話——
Trello絕不會強加你不需要的功能。 對于希望使用除看板以外其他功能的用戶,我們有Power-Ups,如日歷、card aging和投票, 你可以打開這些功能。它是豐富功能的一種方法,但又不會 搞得復雜化,適合每個人。
我明明要解決住宿的問題,你給我一堆磚算什么?如果我想砌墻可能問題不大,要是摩天大廈真的不行。所以說,Trello簡化的思路,會有人追捧,但是這也將Trello局限在了中小團隊,或是相對簡單的項目流程中。
綜上所述,回到我們最初的兩個問題, Trello 等任務管理工具體驗如何?其實并沒有一個明確的答案。關鍵還是看企業具體的需求。如果只是簡單的ToDolist,那么任何一款工具都能有效滿足。如果是復雜的團隊管理、項目管理,建議親自體驗。國內外的項目管理工具,早已在看板的基礎上,發展出了眾多復雜而高效的功能;但是也剩下一些問題,還沒能得到解決。
回到第二個問題,Trello究竟能否代表這類項目管理工具,我的答案是否定的,而且我很討厭中國版Trello這個說法。這就好像脊椎動物雖然在身體構造上有著相似性,可是演化的方向完全不同,適應的環境、生存策略也都不同。藍鯨不能代表脊椎動物,Trello也不能代表項目管理工具。Trello的局限性我在前文已經提了幾點。在這些方面,國內廠商的思路和解決方案顯然更能適應中國企業的需求。
我們理解的簡化,是日常操作的簡化,而非功能上的簡化。
#專欄作家#
袁林,人人都是產品經理專欄作家。分享SaaS運營和企業管理/協作/辦公的相關知識
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Pexels,基于 CC0 協議