一,項目管理的模型
從傳統瀑布流到現在的基于快速迭代的各種靈活的模型和管理框架,發展非常迅速,而且也逐步被引入到各個非
軟件開發領域里去.新的企業也在嘗試著比較新的
敏捷開發的實踐.比如減少冗余繁雜的文檔,項目估時,站立會議等.
有些成功了,有些也失敗了.失敗的幾乎都是因為團隊本身的成長限制了執行的力度,或者與團隊現有的管理模型有所沖突,導致各種不適應,最終放棄.我們自己也在這方面做著很多的整合嘗試,卻最終因為缺少比較接地氣的工具而受了不少挫.
也有不少實際的問題,比如:
1,每個人互相不太知道對方做了什么,所以到了涉及到其它人相關的模塊時,無法確定自己是否應該繼續還是停下來.
2,我的代碼寫完了,測試總是遲遲不能得到通知.
3,如果總是在需要跟別人交互的時候打擾別人,又會讓整體的效率降低.
4,TM,PM也缺乏對項目的整體的直觀的管控.
…
這樣的類似的問題很多,各自也有各自的解決方案.我們采用了一種比較安靜的做法,整個過程不希望總是打斷別人.并且可以實時的監控所有人的行為,比如正在做什么,哪些是做完了的,哪些是正在做的,哪些還沒有開始.是不是有任務被移交到了我這里(比如需要
測試的部分).
我自己也能一目了然的知道我所有的
工作,并且能以非常直觀的形式看到我每天的工作.管理者也要能非常清楚的看到整個團隊的工作.
二,工具的用戶體驗和工具的實際效果.
如果沒有更合手的工具,大家往往不愿意使用.
比如畫軟件原型,有很多原型軟件如Axure,但是很多人還是更喜歡用筆在紙上畫.只有真正某個軟件足夠便利而且節約很多時間,大家才會轉到這個上面來
在一直以來的
項目管理里,也一直在調研不同的項目管理工具,最開始的Project,TFS,很多開源的軟件,網站等各種應用.卻一直沒有找到一個很適合我理想中的工具,我的需求也很簡單:
1,一個自由公開的白板,
2,一個直觀查看所做任務的日歷
3,一個燃盡圖,知道項目是否延遲還是提前
4,跟其它組或者公司進行協同.
另外一個需求是:我的個人倡導,我希望建立一個共平自由的合作環境.
我大致說一下傳統的軟件的做法和我的沖突:
1,在我調研過的系統中部分是有白板的,但是操作上比較麻煩一些,我希望能直接拖動就能達到目的的.
2,普通認為表格是最好的表達形式,比如所有的任務列表,bug列表,可以通過搜索,排序等方式進行管理.每次要分析今天哪些人做了哪些事,需要一次一次的篩,一次一次的分類看.我是覺得挺累的.
3,軟件項目往往會產生的情況是前期松,后期緊,甚至超期,我希望知道是什么原因導致了這種情況的發生,當前項目進展是否是健康并且正常的.我只需要一個燃盡圖.而現在的往往做得比較復雜.
4,跟其它組或公司的配合,這個組和公司并不一定是軟件開發團隊.比如客戶公司的營銷團隊,設計部,開發部等.需要整體協作起來.
5,我希望所有團隊成員都是平等的.沒有等級關系,沒有項目經理,組長,組員的層級關系,沒有誰對誰負責.因為一個項目是大家共同努力的結果,每個人都應該對最終的結果負責,每個人都應該有自我協調能力.
我的需求不太多,但是我希望足夠好用,而且直接有效.
三,團隊協作和軟件
從一個游戲來看團隊協作
我以前曾經玩過一個游戲,相信也有很多同行也玩過,游戲很簡單.在一個空房子里,擺滿很多凳子,然后由一個人被蒙上眼睛,由另一個人在旁邊指揮,什么地方應該轉彎,什么地方應該往前走,最后到達目的地,再一次,摘掉眼罩,由他自己決定.兩次的速度相關是非常大的,結果也是顯而易見的. 所以細節的實現更應該去相信員工自己,讓員工自己來解決,而不是事無巨細的管理.
從版本管理軟件的發展來看團隊協作
大家在工作中肯定有用過很多版本管理軟件,比如有名的有: vss,svn,git每一個都有各自鮮明的特點.
Vss: 它有這樣比較明顯的特點,整個過程基于鎖定和解鎖,如果你想修改某個文件,需要先鎖定簽出,然后修改完后再提交,提交結束后便解鎖.這時如果有其它人需要修改這些文件,需要等別人提交后才能解鎖,簽出,然后修改完成后再提交.他對版本的管理是依賴于同時只有一個人使用一個文件,當然你可以選擇vss支持的另一種更開發的模式,但是這個已經放棄了vss本身的優點,利用版本管理軟件來建立起一個有序的開發的流程.以消除文件編輯的沖突. 同時帶來的負作用就是大家往往一半時間在等待其它人提交釋放鎖,而且在修改完成后,時刻要記得去提交.簽出時也小心翼翼.
Svn:從vss過渡到svn,是一個自我解放的過程.每個人可以自由奔放的修改然后提交,如果提交的文件里沒有別人修改的文件,就只管提交,如果有,更新下再提交.在實際工作中,因為大家實現的是不同的模塊,90%左右的沖突都由svn本身的合并功能解決了.只有極少部分需要手動合并,這要歸功于svn的強大的合并功能還有忽略文件的配置等.它把可能的沖突轉給的團隊線下自身來解決,事實上,人的可調控性遠遠好于軟件的強制性,很快采用這個版本管理軟件的團隊,制定出了一套協作的方案,使每個人的工作獨立,相互沒有影響,當然也同時促進了團隊的架構水平和管理水平.
Git:從vss過渡到git,則是一種更大的自我釋放,它的歷史版本管理,不再完全依整服務器,文件提交也不再完全依賴網絡,他可以僅僅只是先提交到本地,在本地積累到一定程度后,再一起提交到服務器.可以說一個本地副本在提交到服務器前就是一個svn,一個分支,你可以自由的回滾,可以最終提交你的決定.更多的工作交由線下自身來解決.
他們也呈現出了一種從封閉到開放,從軟件限制轉到人為管理轉化的過程.很可喜的是每一次轉化都極大的提高了生產率.也同時提高了團隊的管理水平.
再回顧企業管理,總監下有經理,經理有部門,部門有組長,組長有成員.一級一級管控.如果有個辦公室需要買一本書,可能需要給組長申請,組長再提交部門審批.一級一級.從想買到實際買到可能已經過了一周了.一周后,可能這本書就沒必要買了.當然在大的企業管理里,這樣沒什么問題. 但是我想如果把這種層級關系放開,由扁平化的組織結構來管理,再制定一定的機制讓人員自我管理.這個效率會高很多.當然可能也會非常混亂.
對于小的團隊來說,如果所有成員扁平化,每個成員都是團隊里重要的一員,每個人都有權力做所有的事情.我想這一定會是一個更高效的團隊.我舉幾個例子:
1,如果團隊成員因為有病不能來,但是項目又要求他這方面的工作完成,我可以直接拿過來他的任務然后完成它.
2,如果我有一個模塊開發完成,我可以直接拖到測試員,測試員直接接手測試.
3,測試員完成測試,反應出一些問題,可以直接遞回我做修改.
我想權力越大,操作就會越謹慎,我們不應該總是把大家綁得死死的.大家有了靈活性,反而不會去做一些實際上會逾越自己權力的事情.只在必要時去做.這個必要性,線下大家討論制定出一個協議,然后執行即可.就好像我們制造了一把斧頭,但是我們不規定別人如何去使用他,線下我可以幫他們推薦一種比較好的揮斧方式,但是如果他喜歡,他也可以用別的方式來揮斧達到更好的效果.
還想說點什么
如果你是一個程序員,你是不是很想分享你的一個驚天的發現,可能是一個js的游戲開發框架,可能是你寫的一個無比牛比的demo,有可能是你找出一個許久沒有解決的程序的bug.也許是你花了兩天時間最終配置起來的nodejs成套的開發環境.你是不想希望得到別人的關注,領導的關注,希望有一些成就感.那么你肯定也希望有一個能寫點什么的地方.所以也希望有一個知識庫,可以展現自己.