敏捷開發(fā)適合什么樣的團隊?
如今互聯(lián)網行業(yè),每天有無數(shù)的公司倒下,同樣也有無數(shù)的公司站起來。越來越多的人將「敏捷開發(fā)」搬上臺面大談特談,或是為了搶占市場先機、或是為了不斷修正需求方向、或是表現(xiàn)出相當?shù)膭?chuàng)業(yè)精神進而“騙取”資本熱錢。有太多太多的原因讓人們追捧「敏捷開發(fā)」,這些追捧既有目的性極強的也有無腦跟風的。我在好多論壇或者交流群也見過有人問關于自己的團隊適不適合「敏捷開發(fā)」的問題。
所以今天,我來說說究竟什么樣的團隊才適合「敏捷開發(fā)」。
1. 小團隊
這點應該毋庸置疑。
從生活經驗上來看,小動物一般用敏捷來形容,比如兔子、貓(當然,大動物也有,如:這頭豬真胖,但它竟然還這么敏捷)。
小團隊不會出現(xiàn)大團隊那種尾大不掉的情況,「敏捷開發(fā)」進度可能每天都會變化,小團隊有著更低的管理成本,產品經理可以很好的把控整個團隊節(jié)奏。
當然,小團隊也是要五臟俱全的。
2. 需求聚焦
如前文所說,大家采用「敏捷開發(fā)」肯定是有目的的。不管什么目的,肯定是為了快速響應、快速上線。這時,產品需求一定要聚焦、再聚焦。
有太多團隊都是開發(fā)到后期突然要改一些不影響大局的東西,比如界面不好看、Icon不精致、交互不酷炫、需求Cover面窄。這些東西放在普通開發(fā)節(jié)奏的團隊中是沒有大問題的,但是在「敏捷開發(fā)」團隊中,只會拖慢整個團隊進度,本末倒置。
3. 工作內容無邊界
及時補位的思想是要深入到每個團隊成員心里的。
「敏捷開發(fā)」的團隊或是初創(chuàng)團隊一般都是一個人當好幾個人用,每個人都是多面手(這也是好多朋友覺得小公司好的一點,即負責的內容多、成長快),原因就是他們的工作沒有邊界。
比如底層開發(fā)生病了,中間層大哥一定要頂上;比如QA人手不夠了,產品經理寫測試用例并參與測試也是常見的事。
4. 團隊無明顯短板
越小的團隊越容易暴露問題,木桶理論在小團隊中更容易體現(xiàn)。
「敏捷開發(fā)」過程很容易被團隊中的短板所影響,這事雖然其他成員也有及時補位的精神,但每個人精力畢竟有限,我們還是希望能夠每個人各盡其職。補的應該是未知的突發(fā)情況,而不是可預見的短板,這兩個本身就不是一回事。
5. 互相信任
團隊目標必須高度一致,并且相互信任,盡量少的辜負其他人。
產品絕對信任開發(fā)評估結果,開發(fā)絕對信任產品發(fā)起的需求等等。少質疑多溝通,才能快速實現(xiàn)目標。
好多大團隊都會有各種需求評審、用例評審,每天文山會海,而「敏捷開發(fā)」會盡可能簡化這個流程。但是我們要說的評審只是手段,目的還是要錘煉產品需求。因此糾結于是否該簡化評審流程的朋友們,請嘗試理解“不要把手段當目的”這句話。弱化評審的前提一定是產品經理自己已經將需求想明白,即滿足團隊預期、滿足產品預期,再進行交付。
6.擁抱變化
之所以采用「敏捷開發(fā)」,真正的目的是快速響應、解決問題。當外界環(huán)境發(fā)生變化的時候,一定要及時接受并擁抱變化。
所謂的變化來自兩方面。一方面是外部變化,比如產品方向和預期不符、市場反饋不好等;一方面是內部變化,比如效果圖或者交互真的需要改動才能上線等。
面對這種未知的問題,團隊里的相關人員需要及時調整心態(tài),一起擁抱變化。
總結
「敏捷開發(fā)」需謹慎,一定要捫心自問團隊是否滿足上面說的幾點。
「敏捷開發(fā)」不是萬能的,解決問題才是王道,切勿盲目崇拜。
PS. 「敏捷開發(fā)」過后,產品經理一定要整理文檔,否則快是快了,什么都沒留住。切記,切記?。?!
作者:一條產品狗
來源:簡書
原文鏈接:http://www.jianshu.com/p/6a7cc750f709
本文由 @一條產品狗 授權發(fā)布于人人都是產品經理,未經作者許可,禁止轉載。
你好,我想咨詢下,對于已上線的項目,新需求獨立且特別多的項目,我們如果管理項目要好一些。多個業(yè)務部門提需求,需求多,還要求都要立即實現(xiàn),新需求插進來,要求不能影響之前提的需求的進度,還要立馬把新需求完成。針對這樣的項目,請問有什么好的管理辦法嗎?