產品失敗的十大根本原因,任何一條都足以摧毀一個團隊!

ADVERTISEMENT

ADVERTISEMENT

翻譯:@Yibo設計

我看到在絕大部分公司用的都是相同的基本工作方法,我不禁想提醒這和那些好公司的實際工作方法相去甚遠。

我不得不提醒你這討論出的結論可能會非常令人沮喪,甚至你覺得有點太打擊人,如果是這樣,我覺得你可以停在這里不必往下看了。

讓我們從絕大多數公司仍在用之創造產品的過程開始,我會試著不發表評論,我們僅是描述這個過程:

任何事情都始於想法。在大部分公司,想法來源於執行董事,或者關鍵的利益相關者,或者企業主,或者大客戶(或潛在客戶),但是任何情況下業務的不同部分都有一大堆事情需要去做。

現在大部分公司想要在路線圖中確定這些想法的優先順序,他們這樣做基於兩個理由。首先,他們想要我們優先專注於最有價值的事情,其次,他們想預測事情何時能準備好。

為了做到這一點,通常會有某種形式的季度或者年度計劃會議,會上領導就這些想法思考並協商出一個產品路線圖。但是為了確定優先順序,他們首先需要為每個項目提供某種形式的商業案例。

ADVERTISEMENT

一些公司會形成正式的商業案例,一些則是非正式的,但不管是哪一種,歸根到底,關於每個想法都需要了解兩點:

  1. 它將賺多少錢?
  2. 它將花費多少時間或金錢?

然後用這些信息來提出下一個季度有時也可能是一年後的產品路線圖。

在這一點上,產品和技術部門有他們自己的工作節奏,通常是按照項目的優先順序,從最高優先級依次往下走。

一旦一個想法被確定為最高優先級,產品經理需要做的第一件事就是和項目利益干系人討論,將想法具體充實化,並提出一系列的“需求”。這有可能是用戶故事,也有可能是某種形式的功能細則,但目的都是為了和設計師以及工程師溝通需要創建的是什麼。

一旦需求被收集起來,用戶體驗設計團隊(假設公司有這樣一個團隊),就需要提供交互設計,視覺設計,以及物理設備情況下的工業設計。

最後將需求以及設計細則交給工程師,這時敏捷開發最終登場。

無論如何,工程師通常會將項目劃分成一系列的迭代——在敏捷開發模型中這稱之為“sprints”。想法構建出來可能需要1- 3 次敏捷迭代。

ADVERTISEMENT

很希望QA測試是這些敏捷迭代過程中的一部分,如果不是,QA團隊應該用其他的測試跟進,確保新產品和宣傳的一致,同時不會引進其他問題(稱之為“回歸”)。

一旦我們在QA團隊那拿到了綠燈,新想法可以最終部署給真實客戶了。

在我第一次見面的絕大多數公司,無論大小,重要的是他們的工作方式,並保持這樣的方式工作了很多年。但也同樣是這些公司,他們不斷抱怨著缺乏創新,從想法到落地需要非常長的時間。

你也許已經意識到,當我提及敏捷開發的同時,幾乎今天的每個人都宣稱是敏捷開發,而我剛剛描述其實更多的是瀑布過程。公平說來,對於工程師,如果他們能夠給更廣闊的瀑布環境,他們能做的其實和敏捷開發一樣多。

OK,既然大部分團隊都是敏捷開發,但為什麼那是如此多問題的必要理由呢?

我現在想做的就是將這些點連接起來,向你展示為什麼這種普通的工作方式要實際為大部分失敗的產品努力負責。

ADVERTISEMENT