敏捷開發：項目管理的一些思考

誤區

以前我沒有項目經驗，在上一家公司的項目管理上，我只是照葫蘆畫瓢。

1. 產品發起，整個項目沒有項目經理這一說。或者說有，但卻真的感覺不到，一丁點也感覺不到。

2. 產品發起會議，或者開發發起會議。不管誰來發起會議，通常都會針對於某一具體需求或者某一具體實現方式。

3. 沒有具體的任務規劃，任務拆得不夠細緻。這個和開發自身有關係。固然那時的公司確實沒有一些指導性質的模板和導師。

4. 任務分得不夠細緻，就會致使工期評估差距比較大。

5. 各類O們的臨時緊急需求，不少O沒有技術背景和項目管理背景。不少時候提出的需求都是發生在項目開始過程當中。

   都是很急的需求，不得不從新估算時間和排期。開發爲了不延期風險，就是讓產品排優先級，而後咱們根據優先級估時。

   直到有必要的需求都在這個迭代中計劃上。

6. 沒人全局把控，產品從產品角度，開發從開發角度，業務從業務角度。始終沒有一個最終的協調人。

   產品在對各類O的對話中，氣場和身份不足，致使需求基本是提出就會安排。即使是請出青島總負責人出面溝通，最終的結果通常就是接受。

7. 以前咱們是青島爲開發，北京爲產品、UI、前端、測試。異地溝通。電話會議是常有的事情，私下的臨時溝通電話更是屢見不鮮。

   信息同步、開會、理解程度 都會形成溝通上的成本增長。

8. 緊急需求上線後，三個月沒人反饋。問了才知道，財務提的需求他們沒用過。

9. 開會通常都會臨時決定，發起人會準備資料，可是其餘人提早看資料準備問題的狀況極少。致使會議冗長效率低。

解決

如今來看，不管如何，咱們在知道這些問題，可是爲何不去處理呢？應該仍是習慣了，即使是整個項目很是掙扎，依然是按老規矩走。你們都是困在了這個圍牆中。

我如今也有了一年的項目管理經驗，初入門道。只是對本身的過往進行一下分析解決。

以上的誤區和問題，我以爲須要一個有經驗而且有點能力的人來帶領這個項目團隊。

1. 確認項目經理

可是按照我上家公司的狀況，通常會立經驗豐富的主管直接管理這個項目。

當時的狀況是，項目主管在項目上的精力徹底不夠，甚至說項目管理在項目主管心中的優先級比較低。

根本緣由，青島做爲研發中心，技術基因強大。不少技術管理人員，沒有意識到項目管理的重要性。

組織架構主要是垂直單線架構，技術-主管-經理-總監-CTO。無非是本身下面的人多，按照業務或者大項目分了組而已。

若是讓開發做爲項目經理，

首先這個開發是否願意承擔項目經理職責？

是否真的可以賦給項目經理一些實權？

是否有鼓勵機制，好比晉升優先或者獎金等？

建議：

增強項目管理意識；

增強項目管理能力；

必要的話能夠做爲量化指標來看；

加入一些激勵機制；

2. 培養主動性

由於技術基因影響。主管或者經理出於「好心」考慮。

他可能會考慮到，若是把項目管理中的某些事情分配給組員，會不會引發反感？會不會影響在組員中的美好形象？

也算是確實分下來一些，好比項目規劃和估時以及排期。可是我沒經驗的，是否是能夠稍微引導一下？

領導總想爲老好人，可是這樣本身手頭的任務分不下去。

下面的人也得不到成長。

建議

對組員有必定的規劃和成長要求，而不是聽任其隨意生長（有必定風險）

領導應該提升自身的管理能力，管理技巧。而不是憑經驗論。

定時關切Review分下去的任務，從結果或者過程提出建議和優化。

3. 確認好需求邊界

產品經理和負責人，確認好需求邊界。飄忽不定的需求給項目的打擊是很大的。

開發在搖搖墜墜重估時，此時的估時確定會有達量的冗餘，由於以前需求的變更，上線時間一改再改。

在加上，主管、經理偶爾砍幾刀。因此開發在估工時都會冗餘不少。爲了被砍，爲了需求不定。

建議：

確認好需求，可將項目週期縮短，小版本迭代。

強化項目上線時間約定，鍥約精神。不只僅是開發要遵照。其餘人員最好也能嚴格遵照。（當初這個作起來真的比較困難）

信心是作出來的，幾回項目的延期和需求的變動會嚴重打擊你們的信心和士氣。因此按時上線很重要。

規劃得有，可是是否是能夠考刪掉遠在4個月之後的需求。

4. 緊急需求

好比財務的一些緊急需求，其實確實緊急，可是使用頻率很低。

是否是能夠有另外一種解決方案？不必定非要按照財務提出的那種設想。

咱們達到並知足了他們的目標，後期再去作頁面更加直觀。

好比要一個訂單查看頁面。那我使用程序定時拉取新訂單推送到企業微信或者釘釘。結果也是很是滿意的。

不必定非要作一個頁面，不少時候作成一個頁面，你們會發揮本身的產品意識，增長一些沒必要要的按鈕、功能和邏輯。

建議

深刻了解需求，而不只僅是一句話，也不是根據用戶提出的需求來作，用戶到底想要什麼？--他就想要有訂單能及時知道。

緊急需求是否真緊急，也得看使用頻率。使用頻率低，是否有其餘方式實現。

能擱置的暫且擱置一下，以前就我一我的開發，不少本來緊急的需求由於開發不夠，擱置了也就擱置了。而後甚至有的都本身消失了。

5. 高效開會

會議開始前，你們幾乎麼有預習的習慣，會上不少時候沒有主持人，你們就問題會討論很深，致使時間不可控。

有的會能一個電話解決的就不必拉這個拉那個來開會。這種儀式感不重要，開會也不是拉家常。

爲了讓領導知道此次會議的重要性，這個項目的重要性。拉着領導一塊兒開：

可是領導的事情多，不少時候在會上他們是一直回覆信息，其實當時是比較尷尬的，領導不能專心處理問題。咱們看着領導沒用心聽，不瞭解的同事還覺得領導不聞不問呢。

建議：

發起人拉羣，提早@人提醒你們關注和看會議內容。

發起人作會議：主題、流程、最終結論

確認會議主持人，隨時控制會議進度。有些細節會後溝通。

領導能夠沒必要參加需求討論會，把會上討論的疑難問題，會後單獨和領導會報，再拉一個小會議電話溝通確認便可。

 重要項目啓動會、項目上線等會議儘可能簡短，領導全身心參加。保證你們的鬥志，統一思想達成一致。有些形式必需要有的。

6. 相關方

開發與客戶溝通少，由於兩地溝通，基本是產品做爲翻譯官將業務轉成需求轉達給開發。

開發沒有感知用戶的存在。

建議

多聽聽用戶怎麼說。

你們達成一致，每個月電話會議或者視頻會議溝通一次。會議能夠控制在1小時之內，氛圍能夠輕鬆，主要是手機需求以及反饋問題。

若是有多個業務部門都是相關方，那麼主要思想就是設置按期溝通（規律的按期溝通）

7. 轉變

優勝劣汰的企業付薪給咱們，咱們就要服務於這個企業用戶。甚至說服務好用戶。

咱們開發也要主動從自身求變。好好說話，真心替咱們的用戶思考過問題。

從產品和業務角度承認業務優先級，而不是牢牢盯着開發重構、新技術的應用。

建議

轉變意識：我想爲大家服務；

我能力不行，可是我能主動學習項目管理知識和經驗，並在項目中實踐，反思，再實踐。

我要爲我開發的產品負責，它的迭代，扔給它的需求，和它相關方，它的應變能力。

主動一點，也許事情看起來並無那麼難。

如今的我，咱們

新的公司，給了我不少的機會，糾正了我不少認知，我也從實踐中反思了不少，收穫了不少。

公司的組織架構是矩形架構：橫向職能，垂直項目

項目首先會有項目經理，項目經理有必定的項目經理獎金。固然項目經理要履行項目經理的職責。都會有績效。

項目經理，開發，產品，測試，DBA，運維，PMO 這些會組成一個項目組。

整個項目組會在項目經理的引導下，開發項目直到上線。而後迭代下一版本。

如今項目中，有使用瀑布開發，有使用敏捷開發。

我所認知的一點是，各個職能團隊人員雖然屬於職能。可是基本會長期泡在各個項目中。

項目中學習到的東西，在項目中的成長也是很重要的。因此項目經理有必定的敏捷角色中PM的角色：引導你們，賦能給你們。

咱們正在嘗試的敏捷（嘗試）

其餘團隊物理面板：

咱們團隊的面板：很是簡單

項目並行和項目特殊性，咱們採用周交付，不肯定哪一天交付什麼（特殊需求除外）。

由於項目爲運維性質的項目，有開發，緊急需求，客戶答疑問題較多。時間不太可控。

而且你們積極性都很高，不必要求必須排滿周開發任務。

本身開發完直接到需求池，領取最優先級的需求，或者幫助其餘組員分解開發任務。

業務需求 + 技術需求 雙向需求驅動，佔比5：1。

周最高優先級佔比 1：4

這樣你們不會由於具體時間的衝突致使交付的壓力。周交付的任務爲必須交付的最小單元（本週必須交付）。

不必的會議去掉，咱們基本都坐在一塊兒，不去會議室。工位周邊就能夠開會。電腦操做隨時記錄，會後發出來。

週五：計劃會（15：00 ~ 15：30）

10分鐘，材料都是平時積累，會前整理完

地點：工位

目的：回顧上版本迭代精進結果。分析過程問題緣由，總結問題。認知好與不足，下版本迭代重點要解決的問題。；討論新需求優先級；達成一致周最小目標。

週五會後 + 週一開會前

這段時間，是你們緩一緩，總結本身規劃下週的時間。

磨刀不誤砍柴工，想好怎麼作，才能預知困難和風險。

對新需求進行任務拆分，需求理解，任務具體估時。

週一：迭代會（10:00 ~ 10:15）

15~30分鐘，微調任務；統一思想；確認周迭代目標；

地點：工位

週三：若是須要能夠開一個簡短溝通會

咱們本身維護的計劃和交付，簡單高效。團隊協做，互相可看。

咱們的產品是剛畢業的新人，咱們互相指導學習。

他最近也在研究用戶故事如何寫好。他打算下週先打印出來，你們看看本身感覺一下。

最近我看完了一本敏捷開發相關的書籍，同時推薦給了他。咱們想單獨摘出好的或者值得討論的地方，你們圍在一塊兒拿出半小時討論一下也何嘗不可。

還有一本我正在看，可能我實踐經驗不足。老是感受通常般的感受。思路不是很清晰。

有讀過的朋友能夠發表一下見解。

總結

敏捷咱們在路上。不爲敏捷而敏捷。

咱們互相提升，互相幫助，能力提高，升職加薪。生活質量更好。

大街上敏捷一大堆，根據實際狀況摸索敏捷之道。發揮你們的能力，提高你們的能力。爲你們帶來點實際的東西。爲企業帶來點實際的東西。

項目管理根本目標是把項目管好，項目管好，你們更加自信，互相也都信任。因此項目管好是項目組良性循環的根本。項目經理要多花大力氣去關注，去學習。

謝謝關注公衆號