敏捷開發:專案管理的一些思考
誤區
之前我沒有專案經驗,在上一家公司的專案管理上,我只是照葫蘆畫瓢。
產品發起,整個專案沒有專案經理這一說。或者說有,但卻真的感受不到,一丁點也感受不到。
產品發起會議,或者開發發起會議。無論誰來發起會議,一般都會針對於某一具體需求或者某一具體實現方式。
沒有具體的任務規劃,任務拆得不夠細緻。這個和開發自身有關係。當然那時的公司確實沒有一些指導性質的模板和導師。
任務分得不夠細緻,就會導致工期評估差距比較大。
各種O們的臨時緊急需求,很多O沒有技術背景和專案管理背景。很多時候提出的需求都是發生在專案開始過程中。
都是很急的需求,不得不重新估算時間和排期。開發為了避免延期風險,就是讓產品排優先順序,然後我們根據優先順序估時。
直到有必要的需求都在這個迭代中計劃上。
沒人全域性把控,產品從產品角度,開發從開發角度,業務從業務角度。始終沒有一個最終的協調人。
產品在對各種O的對話中,氣場和身份不足,導致需求基本是提出就會安排。即便是請出青島總負責人出面溝通,最終的結果一般就是接受。
之前我們是青島為開發,北京為產品、UI、前端、測試。異地溝通。電話會議是常有的事情,私下的臨時溝通電話更是家常便飯。
資訊同步、開會、理解程度 都會造成溝通上的成本增加。
緊急需求上線後,三個月沒人反饋。問了才知道,財務提的需求他們沒用過。
開會一般都會臨時決定,發起人會準備資料,但是其他人提前看資料準備問題的情況極少。導致會議冗長效率低。
解決
現在來看,無論如何,我們在知道這些問題,但是為什麼不去處理呢?應該還是習慣了,即便是整個專案非常掙扎,依然是按老規矩走。大家都是困在了這個圍牆中。
我現在也有了一年的專案管理經驗,初入門道。只是對自己的過往進行一下分析解決。
以上的誤區和問題,我覺得需要一個有經驗並且有點能力的人來帶領這個專案團隊。
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分鐘,微調任務;統一思想;確認周迭代目標;
地點:工位
週三:如果需要可以開一個簡短溝通會
我們自己維護的計劃和交付,簡單高效。團隊協作,互相可看。
我們的產品是剛畢業的新人,我們互相指導學習。
他最近也在研究使用者故事如何寫好。他打算下週先打印出來,大家看看自己感受一下。
最近我看完了一本敏捷開發相關的書籍,同時推薦給了他。我們想單獨摘出好的或者值得討論的地方,大家圍在一起拿出半小時討論一下也未嘗不可。
還有一本我正在看,可能我實踐經驗不足。總是感覺一般般的感覺。思路不是很清晰。
有讀過的朋友可以發表一下看法。
總結
敏捷我們在路上。不為敏捷而敏捷。
我們互相提高,互相幫助,能力提升,升職加薪。生活質量更好。
大街上敏捷一大堆,根據實際情況摸索敏捷之道。發揮大家的能力,提升大家的能力。為大家帶來點實際的東西。為企業帶來點實際的東西。
專案管理根本目標是把專案管好,專案管好,大家更加自信,互相也都信任。所以專案管好是專案組良性迴圈的根本。專案經理要多花大力氣去關注,去學習。
謝謝關注公眾號
相關推薦
敏捷開發:專案管理的一些思考
誤區 之前我沒有專案經驗,在上一家公司的專案管理上,我只是照葫蘆畫瓢。 產品發起,整個專案沒有專案經理這一說。或者說有,但卻真的感受不到,一丁點也感受不到。 產品發起會議,或者開發發起會議。無論誰來發起會議,一般都會針對於某一具體需求或者某一具體實現方式。 沒有具體的任務規劃,任務拆得不夠細緻。這個和開發自
產品思維學習(五)--產品敏捷開發和專案管理
一般產品人員進行過需求採集,分析,篩選後就會進行產品的設計。 在產品設計的過程中會產生PRD(Product Requirement Document 產品需求文件 ),如果是新產品或者在大公司一般還
基於JIRA的Scrum敏捷開發的專案管理
Scrum開發的步驟及準備 Scrum敏捷開發的關鍵字就是增量、迭代,他更重視專案團隊之間的現場溝通,不向傳統瀑布式開發那樣需要萬事具備,才開始開發,Scrum在大方向和小故事點確認好了後,團隊就可以開動了。 Scrum的團隊一般都不大,一Scrum團隊人數一般在10人左
敏捷開發與專案管理實戰之敏捷需求分析
敏捷開發中,全體成員都會參與需求分析。但是,通常多數的開發人員和測試人員他們的能力和經驗不足以勝任需求分析工作。這意味著全體成員參與的需求分析活動需要一個扮演導師角色的人帶領大家去進行有效的需求分析。本文以作者黃文海帶領
Masterlab 1.0 釋出,基於敏捷開發的專案管理工具
Masterlab是基於事項驅動和敏捷開發的專案管理工具,參考了Jira和Gitlab優秀特性發展而來。適用於網際網路團隊進行高效協作和敏捷開發,交付極致卓越的產品。 1.0 更新內容如下: 新功能 簡化安裝過程及文件,增加了圖文安裝過程 事項的附件可以通過移動端
線下活動【北京】敏捷開發:促進項目管理創新變革
經理 如何 image ext p s 優秀 pla cnblogs 項目經理 您在項目中是否經常遇到項目目標不清晰的問題? 您在項目中是否經常遇到項目需求不斷變更的難題? 您在項目中是否經常遇到跨部門跨專業溝通不暢的困惑? 您在項目的執行過程中是否面臨
技術走向管理一些思考
popu 傳統 tails 人才 建立 團隊 新的 程序 業務部 在《IT項目管理》一書中針對IT行業定義了一個新的“工種”--多才多藝者,並預言未來的IT產業中多才多藝者的重要性將逐漸凸顯。多才多藝者即是具有技術背景,同一時候了解業務部門、能規劃和實施IT計劃、添加商
Eclipse整合Git做團隊開發:分支管理
在日常開發工作中,我們通常使用版本控制軟體管理團隊的原始碼,常用的SVN、Git。與SVN相比,Git有分支的概念,可以從主分支建立開發分支,在開發分支測試沒有問題之後,再合併到主分支上去,從而避免了直接在主分支修改程式碼。 本文介紹如何使用eclipse管理Git分支。
敏捷開發—大型專案團隊的持續快速交付之道
大型軟體的團隊有效協作對專案成功起到越來越關鍵的作用,“敏捷之旅廣州站——精進之旅”的活動,請來了業界敏捷專案管理的專家做了幾場公益性的講座,涉及敏捷開發應用和網際網路專案管理的一些實用的方法,本文結合個人體會做個總結。 敏捷開發實際上是一種增量迭代開發模式,對於直接面向市場最前
敏捷開發在專案中的應用心得
1. 極限程式設計在專案中的應用 最早接觸極限程式設計的概念是在2010年看的一本書《解析極限程式設計--擁抱變化》,當時並沒有一下子看完,之後斷斷續續的讀著。但在是實際專案中並沒有真正的應用。 在2011年3月份進入一個3500多萬的專案中,在調研和開發的過程中,遇到
敏捷開發:一種思想
敏捷開發流派有很多,但是萬變不離其宗。 個體與互動 勝過 過程與工具 可以工作的軟體 勝過 面面俱到的文件 客戶協作 勝過 合同談判 響應變化 勝過 遵循計劃
敏捷開發:做一個合格的Scrum Master
圖片來源於網路 Scrum Master: Beauty and Beast 在Scrum敏捷開發中有三種主要的角色:Product Owner(產品負責人,簡稱"PO"); Scrum Master(敏捷教練); Team(團隊)。其中,Scrum Mast
瀑布開發模式和敏捷開發模式的區別和思考
瀑布開發模式: 瀑布開發模式有以下顯著的特點: 1.嚴格把軟體專案的開發分隔成各個開發階段:需求分析,要件定義,基本設計,詳細設計,編碼,單體測試,結合測試,系統測試等。 使用里程碑的方式,嚴格定義
敏捷開發:持續整合與持續交付
敏捷開發是我們的常聽的名詞,什麼是敏捷開發? 說讓開發更簡化更高效等於沒說。。敏捷開發的關鍵詞是:持續整合與持續交付。 一個Java專案,一個人怎麼搞: 一個人寫程式碼 => 自己打包 => 自己機器編譯=> 自己部署 =>
敏捷開發:60分鐘掌握敏捷估計和規劃
估計和規劃在軟體開發中是必不可少的活動,那敏捷方式下我們如何做呢?以下是今年5月份內部做的一個培訓PPT,希望對大家有所幫助。 敏捷個人俱樂部QQ群:40961321 加入敏捷個人俱樂部QQ群說明
敏捷開發:編寫開發文件的利與弊
敏捷開發學習總結: 思考開發文件的利與弊 文件是個好東西,這是不可否認的,但是太依賴文件也有弊端,下面我從不同的度來分析一下文件的利與弊,然後思考在敏捷開發時,文件又是如何進行的。從 公司的角度來看,編寫文件有如下好處: a1) 公司使用的是瀑布生命週期(或序列式開發,
敏捷開發與個人管理
1、概論 敏捷開發,其實道理很簡單,但是太多的事情是道理簡單卻做不到。 敏捷開發(Agile)的核心是去中心化,扁平化結構,擁抱變化,習慣不確定性,當然,還有最重要的迭代。 2、三種角色 在上面這張圖中可以看到,在Scrum
C#.架構設計(一)敏捷開發:敏捷開發聯盟、開發工具、開發方法、C#敏捷開發
一、什麼是敏捷開發? 敏捷開發就是一種辦事流程,加快產品等研發。敏捷就是少文件,多迭代,多交流,更多的責任放到了工程師、專案管理者身上,從而加快產品的研發週期。說白了,就是如何在Team中,組織大家更快更好地做事情,不過其主要應用在軟體專案管
敏捷開發必備的管理工具
為什麼選擇 Leangoo? 很簡單,因為它夠簡潔,夠輕量,上手夠快! 因為我們的工作中有各種事物要處理,我們需要這樣的敏捷開發工具來幫助我們解決問題並清晰的展開工作。Leangoo可以幫助我們管理事務,需求管理,迭代管理,缺陷管理,測試管理,排列優先順序等,隨時隨地可以瞭解到團隊以及專案的
用Leangoo敏捷開發工具如何管理使用者故事?
使用者故事(英語:User story)是指從使用者的視角來表達軟體需求的一種方式 使用者故事不能夠使用技術語言來描述,要使用使用者可以理解的業務語言來描述。使用者故事可以幫助研發團隊理解真正的使用者需求是什麼,也可以促進業務人員和研發團隊的溝通和協作。 一個好的使用者故事包括三個要素: