如何讓產品研發保持節奏感？

不少管理者在產品研發中都遇到過這樣的問題：原本預計8個月就要上線的產品，作了一年功能才完成70%；deadline臨近，產品目標卻遲遲完成不了；原本月底要發版本，卻發現還有成噸的bug沒有處理……

那麼，做爲管理者，如何確保可以2周發佈一次版本？產品功能完善時既快又穩定呢？

作產品就像馬拉松，節奏感很重要

我是個喜歡跑步的人。在參加馬拉松比賽時，若想取得好成績，首先要了解本身的身體情況，好在比賽中根據本身的身體情況不斷調整跑步姿式和速度，保存體力，在終點前進行衝刺。

產品研發和跑馬拉松其實差很少。在整個過程當中，我一樣須要不斷調整團隊的工做狀態，保持節奏感，不能全部問題都用無限制的加班來解決，這樣容易進入惡性循環，你們也會產生不良情緒。

想要造成節奏感，我認爲首先要讓工做更聚焦。工做明確了，你們勁兒往一處使，就會很容把目標實現，並且溝通上也會減小不少阻力。

偉大領毛主席曾說過：面對強大的敵人時，咱們要集中火力，各個擊破。差很少就是這個意思了。

固然，光有主張是不夠的，還要有實現方法。我在管理團隊過程當中，走了不少坑，也在爬坑的過程當中總結出了一些心得，在此整理成文，與你們分享。

讓工做更聚焦

記得本身第一次負責項目時，天然是躊躇滿志，天天認真整理需求，把任務列表塞得滿滿當當，爲了按時完成產品上線的目標，要求團隊加班加點趕進度，夢想着有朝一日成爲CEO，迎娶白富美，走上人生巔峯。但讓我疑惑的是，這種方式非但沒有加快進度，反而讓團隊作起事來變得更拖沓了。

後來經大師指點，一語驚醒夢中我：實現不了的目標，等於沒目標。

是啊，定個那麼大的目標，你們天天都不知道作到哪算完，一想後面還有那麼多……去他大爺的，老子去逛京東淘寶了！

通過此次教訓，我決心改變本身的管理方式。

我總結了一下，團隊效率低下的主要緣由在於沒有明確的目標感，致使你們最終失去了工做熱情。因而我就想，若是把冗長的任務列表變成一個個可完成的小目標，會不會能讓你們更有幹勁兒呢？

隨後，我開始將項目拆分紅許多個小目標，每一個目標都單獨安排計劃，目標中的任務也很少，大概2周就能完成的量，而後一次只作一個目標，完成了再作下一個。經過這種方式，加強你們的目標感，讓工做更聚焦。（以下圖）

將項目劃分爲幾個階段目標，一次集中完成一個目標

嘗試了這種新的管理方法後，一個月下來，我能明顯感受到團隊效率有所提高，你們更有幹勁了，須要加班的狀況也愈來愈少。

跟蹤進展，及時調整目標

但隨之又產生了新的問題：

因爲制定計劃時每一個任務的工時都是預估的，加上有緊急bug須要修改的狀況，或是用戶反饋須要儘快解決這種突發性事件，很難保證目標能夠按原計劃完成。

爲了讓目標可以按時完成，我天天早上到公司，都會先開20分鐘左右的站會，總結一下前一天的工做，同時制定當天的工做計劃。

一方面，明確每一個人當天的工做內容，讓你們的工做目標保持一致；另外一方面，根據目標的進展狀況及時調整計劃內容，確保計劃的可完成性。尤爲是在前期，你們對預估工做量都不太熟練的狀況下，更須要及時調整目標。

若是不管如何目標中的任務都沒有作完，我也會結束掉這個目標，將未完成的任務移至下個目標中。

至於爲何不惜移動任務，也要將目標結束，這個我後面再說。

首先我要解決如何制定當天工做計劃的問題。

前面我提到，開早會時很重要的一部份內容就是明確每一個人的當天工做內容。固然，明確不能只是嘴上說，管理是須要落到筆頭上的，必定要有記錄。

但問題是，在自己已經有了一層目標計劃的前提下，如何在計劃中再作一層計劃？並且，管理層級過深的話 ，查看起來也不方便。

這着實困擾我好久，直到採用列表+看板切換的方式，我纔將這個問題解決。

我在列表中將目標計劃制定好以後，按流程將看板分爲待處理、進行中、已完成三個任務欄。目標下全部任務先分配到「待處理」中，早會時，我會將你們當天要作的任務統一拖入「進行中」。

這樣作有兩個好處：對於我來講，列表模式更方便添加任務，制定目標計劃；而對於執行的人來講，看板模式讓他們只需關注「進行中」的任務就好，不會被目標中的其餘任務所幹擾。

選擇當天要完成的任務，拖入「進行中」

但這個方法有一個侷限。

對於列表和看板兩種模式都支持的工具，適應性會很好；若只有看板，加上目標管理也能夠用，但制定計劃時體驗性稍差；若是隻有列表模式，因爲自己層級太深，不建議用此法。

別把bug和任務放在同一個「籃子」裏

另一個比較難解決的問題，就是bug管理。

之因此說它難，是由於產生bug這件事自己是不可控的。就像打地鼠遊戲同樣，你不知道它們會在何時蹦出來，也不知道一下會蹦出多少來，你還不能不理，不然它跟你玩game over。
所以，開發人員常常得放下手頭工做去處理這些活蹦亂跳的「地鼠」，這很是影響進度。
要解決這個問題，我就得避免將bug與任務放在一塊兒，不然天天都有新bug進入當前目標，我就永遠也別想完成它了。

我通常會將bug與計劃分不一樣的項目管理。測試先將bug記錄在單獨的項目中，標記一下bug的緊急程度，回頭由我來決定哪些bug能夠進入到當前目標中優先處理。

在制定目標時，我也會預留出1到2天的時間，專門處理突發事件和bug，具體時間要看實際的bug產出量和緊急程度而定。

將須要修改的bug添加到開發計劃中

有時候會出現這種狀況，直到產品上線，項目中還會有上百條bug沒有解決。

其實這是很正常的狀況，我不會妄想將bug都處理完，由於bug是永遠處理不完的，只要保證它們不會影響功能和穩定性，那麼這個產品自己就是健康的。

這也是bug單獨管理的另一個緣由，避免被這些「場外因素」打擾。

確保目標必定要完成

最後咱們來講一說，爲何目標必定要完成這個問題。其實寫到這裏，你們已經可以發現，上面寫的這些內容，都是爲了達成一個目的：完成目標。

你們可能會問，爲何不惜調整計劃也必定要保證目標完成呢？

其實緣由很簡單：只有團隊目標按時完成了，你們才能把目標當作切實的標準去看待。

雖然一開始，因爲目標任務量設定不夠合理，或是bug產出過多，可能會致使一些任務沒法完成。但只要堅持下去，你就會發現，目標制定會愈來癒合理，遺留的任務愈來愈少，完成的目標愈來愈多。它會由一種儀式變成一個標準，你們在完成任務時會不斷產生成就感，讓你們專一於眼前的目標，並將這種高效的工做狀態一直保持下去。

如此，節奏感就天然而然創建起來了。