大型開發(fā)團隊產品失敗之痛:項目參與者的本位思想
按道理說大型團隊的資源和人力都要比小團隊要豐富得多,為什么做出來的東西卻經常容易失敗呢?MojoTech的創(chuàng)始人兼CEO Nick Kishfy認為,這主要是因為屁股決定腦袋:項目的參與者存在本位思想,沒有人對最終產品負責。對此他提出了一套可行的解決方案。
有一樁軼事說的是小雞和一只豬的故事。
故事大概是這么講的:
一頭豬和一只小雞在馬路上走著。
小雞說;“嘿豬,我在想我們應該開一家飯館!”
豬回答說:“嗯,也許吧。那應該起什么名字呢?”
小雞回應說:“叫‘火腿與雞蛋’如何?”
豬想了一下說:“不要。我都獻身了,而你卻只是參與而已。”
這是一個有趣的故事,但它聚焦了一個問題,在開發(fā)產品的問題上,這將意味著成功與失敗的差別。
項目管理與產品所有權
技術界給歷史更久的既有企業(yè)施加了巨大的壓力。
成為一家“技術”公司存在很多的壓力——要快速、有求必應、敏捷,要開發(fā)出偉大的產品(這畢竟是“公司的未來”),但其實這些團隊大部分都不知道怎么去做。
團隊往往有項目和任務經理,但他們都是在相互獨立的IT、設計等部門內工作的,而在很多情況下,沒人對整個產品擁有所有權,所以也就沒有一個領導來統(tǒng)一自己的團隊。
而這個會變成一個很大很大的問題。
傳統(tǒng)項目管理的消極影響
這種組織辦法的危險是因為:當煙囪式的部門只對最終產品的一小部分負有責任時,他們受到的激勵是要完成自己的任務,而不是為產品整體創(chuàng)造出最好的結果。
但好產品是不可能由一個四分五裂的團隊各自為政這樣做出來的。
個別部門的“需要”必須讓位于產品的需求,否則的話你最終就解決不了對的問題。
比方說,假設設計團隊拿到了產品的初步概述并被告知了交稿的截止期限。但在第一階段的過程中,開發(fā)團隊碰到了一個障礙,這個障礙需要作出困難的取舍;要么關鍵的設計要素需要變更,要么如果實施新的技術解決方案的話,整個項目都要延誤。
這是產品團隊經常都要面臨的艱難選擇,但在基于任務的項目管理環(huán)境下,每一只孤立的團隊都會為對自己最有利的事情進行抗爭。在這里的情況下設計團隊不希望返工重新調整自己的工作……如果項目延誤的話,好吧,“那是開發(fā)者的問題”。
如果致力于一個產品的每個人對最終目標不負責任(實現(xiàn)想要的結果的成功產品),那么這支團隊在做出這些艱難決定時永遠都會遇到極大麻煩。
就像小雞一樣,每個人都參與了,但沒人全身心奉獻。
產品管理:一個更好的方案
在一個到處都是小雞的世界里,豬就是國王。
正如我們定義那樣,這只“豬”就是產品所有者——對成功產出負責的那個人,在開發(fā)和推向市場期間負責指導產品的那個人。
產品所有人被授權對與產品有關的東西做出決定。
他需要做出權衡,確保產品滿足你的用戶的需求。
他說:“我們的用戶已經明確指出他們需要這些功能。要開發(fā)出來?!?/p>
但他還說了:“我們不需要你提出的另外那3項功能。不要浪費時間去開發(fā)了?!?/p>
然后他又說:“我們需要改變這一設計的方向。我們來做吧?!?/p>
產品所有者就這樣來引導產品走向最終結果:一次成功的發(fā)布,實現(xiàn)了原來的目標。
可這個角色大多數(shù)且根本就沒有。實際上,“產品所有者”角色往往由部門經理擔當——你覺得他們會為誰的利益去爭取呢?
產品團隊應該是什么樣子?
如果你希望設定一個產品管理方案,那就需要重新組織,讓團隊像一個產品所有者匯報,而不是部門經理??赡芪覀冃枰⑦@樣一個“產品所有者”角色。
你將需要更多的豬而不是小雞來讓這件事情起效,如果你的組織已經有很多層級的話這實施起來會有點困難。
但重組的痛苦會讓你以比舊的項目管理方案快得多的速度創(chuàng)造出好得多的產品并推向市場。沒有拖泥帶水,執(zhí)行會更加干脆。
相反,你會得到一支統(tǒng)一的團隊,大家會有統(tǒng)一的目標,也就是產品的成功發(fā)布,而不是部門貌合神離的一起工作。
KPI將會聚焦于商業(yè)價值以及對用戶的價值上,而不是考核部門的生產力指標。而整個團隊將會理解“成功”的真正樣子如何怎樣,而且將會團隊在那些目標背后。
如何實現(xiàn)這種產品管理方案?
我的最好建議是從小處開始。
- 挑一組人,這些人應該是愿意并能動搖組織現(xiàn)狀的人。
- 你必須至少有一個足夠資深的人去克服其他部門沿用舊的項目管理方案的慣性。
- 賦予這支團隊更多的責任,讓他們?yōu)橐粋€明確定義的KPI負責。
- 從你可以個用戶帶來價值的最小項目范圍開始。這樣的話你就能夠找到試驗成功的方向。
- 避免使用針對不同目的創(chuàng)建的現(xiàn)有工具和流程。
- 要盡可能讓你的新產品團隊獨一無二。讓他們選擇自己的工具和流程。然后支持他們的決定。
把豬帶進雞舍
從一種工作的項目管理方式切換到另一種工作的項目管理方式是一個很大的改變。這是衡量成功和追求成功的全新方式。
這會讓人感覺比較冒險——因為這不僅僅是在打打勾。
你還會面臨著小雞的抵抗。許多員工對于僅僅做被告知要做的事情感到很舒服,對產品的設計和定義做出貢獻就不一樣了。
但這種改變是值得的。
結論
我們的團隊不止一次被召喚去拯救因為本文提到的原因而跑偏的項目。
公司也許會錯過新產品的幾個截止期限?;蛘邤?shù)月(或數(shù)年)后他們最終發(fā)布了新產品——但卻發(fā)現(xiàn)自己的用戶并不認賬或者不知道該怎么用。
他們需要修補產品,而且要快。
幾乎在每種情況下,我們發(fā)現(xiàn)都是牽涉到了很多人但是卻沒有一個人對最后結果有所有權。
如果你的組織在及時發(fā)布產品上遇到了困難,或者未能適應市場,那我建議你先從所有權開始。
作者:Nick Kishfy
原文地址:blog.mojotech.com
譯文地址:http://36kr.com/p/5063731.html
版權:人人都是產品經理遵循行業(yè)規(guī)范,任何轉載的稿件都會明確標注作者和來源,若標注有誤,請聯(lián)系主編QQ:419297645
很強,我們目前也處于這樣的階段。單我覺得