爲何要中止使用產品路線圖並嘗試GIST規劃

在此以前，我創造了公平的產品策略，路線圖和項目甘特圖。如今我再也不這樣作了，由於我發現了一個更好的選擇。
首先，這是我之前作的事情：戰略→藍圖→項目計劃→執行，並不斷迭代。

這種形式的計劃須要花費大量的工做，而且只是讓全部利益相關者贊成這是一項艱鉅的任務，但投資回報率很是低。並且這些計劃很快就會與現實脫節，由於計劃越長越容易犯錯。我花了一段時間才意識到，我發佈的那天，個人花哨的路線圖和項目甘特圖已通過時了。此外，這個流程就像一個瀑布（不一樣於瀑布式開發），這意味着幾乎沒有靈活性的空間，流程頂部的變化會致使從新計劃和項目取消，而且在底部產生巨大的連鎖反應。敏捷開發解決了瀑布式開發的問題，但沒有改變計劃瀑布
。而後，這對創新和文化產生影響，因爲路線圖只容許在一些大型項目中被提供，所以您必須優先考慮並預先殺死許多潛在的好想法。在自上而下的組織中，贏家的想法來自管理層。在自下而上的組織中，得到勝利的想法變得很是重要，所以推銷和炒做如今是強制性的產品管理技能。
那麼，還有什麼選擇呢？
GIST

這是我在谷歌工做時開始使用的計劃系統，多年來根據精益創業和敏捷開發的原則進行了進一步調整。我已將它介紹給多家公司，結果很是一致-輕量級計劃專爲變革而設計，下降管理開銷，提升團隊速度和自主性，更好地跨公司協調，最終提供更好的產品和解決方案。
該系統在其主要構建塊以後稱爲GIST：目標、思路、步驟-項目和任務。每一個都有不一樣的計劃範圍和變化頻率，雖然咱們可能會使用不一樣的工具來跟蹤這兩個指標，但它們共同構成了公司和團隊須要作的全部核心規劃。

目標
「若是你告訴別人目標在哪，但不知道如何達成目標，你會對結果感到驚訝」 -George S. Patton.

大多數戰略計劃都犯了一個嚴重的問題-他們指定解決方案（使用技術X，與Y公司合做，發起國家Z）而不是目標。目標更能把控局勢，不須要太大的管理開銷，並且更加健壯，相比之下，解決方案可能會根據現場狀況來來去去，但目標始終保持不變。
目標體現的原則是，他們根據預期結果描述公司戰略：咱們但願在何處，什麼時候以及如何知道咱們達成目標。每當組織中的任何人想知道「咱們爲何要作這個項目？」時，目標應該給出答案。我最熟悉谷歌的目標，每一個季度咱們都會以目標和關鍵結果（OKR）的形式精心闡述咱們的目標。有些人認爲OKR是Google如此成功的緣由之一。

想法
「若是你想要有好的想法，你就必須有不少想法。大多數想法都是錯的，你必須學習的是哪些東西要扔掉

」 -Linus Pauling
想法描述了實現目標的假設方法。這裏的關鍵詞是假設，由於能夠有不少想法去實現一個給定的目標，但最多隻有三分之一的想法會產生積極的結果（一般比例更差）。經驗豐富的領導者，產品經理和設計師的想法沒有比平均水平更好的成功率。
因爲GIST中的緣由，咱們從不預先扼殺想法，咱們將想法進行優先級排序，管理思想，或選出最容易被炒做/投放/政治化的想法。這就是咱們所作的事情：
·收集dea Bank中的全部想法，最多見的是電子表格或數據庫，歡迎全部想法，Bank可無限期地持有數百個想法。

·按優先順序將盡量多的想法添加到測試中，這是Step-projects的工做。

步驟-項目
「思想大而起點小」 -Google’s 8 pillars of innovation

選擇一個有前途的想法是頗有誘惑力的，咱們把它變成一個9-18個月的項目並開始執行。這是一個常見的錯誤，也是一個很是昂貴的錯誤，在一個未經證明的想法上度過幾個季度甚至幾年，這可能會在垃圾箱中投入大量資金，由於大多數想法都不值得投資。
相反，咱們將這個想法背後的大項目分解爲小步驟項目，每一個項目不超過10周，而且一次執行一個。例如：草稿→原型→MVP→雛形→測試版→發佈
根據Lean-Startup的Build-Measure-Learn原則，每一個步驟項目實際上都是一個測試這個想法的實驗。在一個成功的過程當中，咱們將在更長的時間內和更多用戶面前爲每一個步驟項目提供一個更完整版本的想法。

最終產品一般比咱們最初想象的要好得多。
因爲步驟-項目很是小，咱們避免了長項目的全部使人討厭的反作用，咱們可以以更低的投資和更快的學習來測試更多的想法。不起做用的想法會提早放棄，有效的想法會得到更多投資。提出一個想法，隨着想法變成現實，並在幾周內不斷經受考驗，這對每個參與者來講都是使人難以置信的自由和愉悅的。

任務
最後，每一個步驟-項目都被分解爲小規模活動，咱們稱之爲「任務」。敏捷規劃工具，看板和其餘現代開發項目管理技術很好地涵蓋了該系統的這一部分。在這個級別上沒有什麼須要改變，惟一的區別是這些工具的頂層仍是敏捷模式。

規劃週期
使用GIST進行規劃是多層次和反覆的：
·目標一般設定爲一年或一年以上的時間-這是咱們但願鼓勵長期思考的地方。它們在年初定義，每季度進行評估和調整，由於咱們也不想追求過期的目標。

·不斷收集想法並肯定優先順序。咱們永遠不會中止尋找新的想法。

·步驟-項目在季度開始時定義。該團隊選擇了本季度但願實現的目標和想法，並相應地定義了步驟項目。季度步驟項目列表（一般存儲在電子表格或數據庫工具中）每1-2周進行一次評估和從新肯定優先級，與任務迭代計劃同步。

·根據團隊的首選開發方法計劃1-2周的任務，例如Scrum sprint計劃，並天天進行調整。

在上面的例子中，團隊正在並行處理有關兩個目標的四個想法。Idea 2
已成功完成第1步和第2步。Idea 3已經在其第一個步驟項目中失敗，所以被放棄，這爲其餘3
個想法作更多工做留出空間。

你還須要路線圖嗎？
我相信你不用。路線圖一般用於如下目的：
·工做計劃-但願到如今爲止我確信你不須要而且不須要路線圖。

·

內部溝通-個人經驗是，同事和董事會成員很容易理解並接受目標，想法和步驟項目的語言-
這不是一個艱難的過渡，他們欣賞現實主義和真實性。固然，整個計劃系統應該對公司中的任何人和董事會都是可見的。
·外部溝通-與客戶和合做夥伴對「正式路線圖」的指望可能最高。一如既往，咱們的工做就是將討論從功能轉移到潛在需求。使用GIST，您能夠給出答案，例如「咱們的目標是在第三季度末以前處理產品間協做。我不能確切地說它將如何運做-咱們正在考慮一些想法並保持敏捷，但咱們應該在第二季度結束時得到MVP。你想成爲一名早期測試人員並給咱們反饋嗎？「運氣好的話，這比任何路線圖都要好。

譯者：MadPecker 原文做者：Itamar Gilad 做者介紹：Google product manager (Gmail, Youtube) 原文連接：https://medium.com/@itamargil...

本人創業團隊產品MadPecker，主要作BUG管理、測試管理、應用分發， 網址:[www.madpecker.com]，有須要的朋友歡迎試用、體驗！ 本文爲MadPecker團隊產品經理譯製，轉載請標明出處