綜合管理:小公司如何做項(xiàng)目管理

字號:

我所在的公司和大多數(shù)國內(nèi)IT公司一樣,十幾到幾十人的規(guī)模,每次在做完項(xiàng)目過程中我們都會感覺很累,老板其實(shí)也很累,在小公司老板更像是一個項(xiàng)目經(jīng)理的角色,很多東西都沒有流程化的東西可走,所以很多事情都要等老板拍板后才可以繼續(xù)下去,員工在很多時候就會感到迷茫,隨著公司規(guī)模的擴(kuò)大,公司也意識到?jīng)]有一套規(guī)范的項(xiàng)目管理方案是萬萬不行的,自己在這方面也摸索的一段時間。
    我首先接觸的是敏捷開發(fā)的方法,但很快我就感覺這個方法行不通,至少對于我們是這樣,因?yàn)槲覀儫o法保證和客戶以及業(yè)務(wù)人員及時溝通,一個月見幾次面就很不錯了,而且我們的開發(fā)人員也并不具有敏捷能力。后來接觸了下CMMI,CMMI對于小公司就更不靠譜了,它龐大的身軀足以把一個小公司壓垮,如果僅為一個證書的話,我建議完全可以向o6z訂購,但不可否認(rèn)的是CMMI也有很多優(yōu)秀的地方可以借鑒。那么我對小公司項(xiàng)目管理的看法是一定要精簡,做到不是傻瓜都能夠理解并且能夠執(zhí)行,況且很多項(xiàng)目經(jīng)理(老板)也并不是領(lǐng)域?qū)<?。在此我想簡單談?wù)勎覍m合小公司的項(xiàng)目管理方案的一些想法,所謂基本適合就是80%適合,我要是說100%適合那我是在扯淡,另外20%怎么辦?那就像06z所說的那樣,靠經(jīng)驗(yàn)這個王道。
    一、需求開發(fā)和管理
    首先要談的是需求這個東西,那么什么是需求?需求就是掏錢買你產(chǎn)品的人一些需要,只要是客戶的需要,不管是合理不合理那都是需求。其實(shí)很多開發(fā)人員都意識需求的重要性,那么真正去做需求的人有多少呢?需求應(yīng)該是包括需求開發(fā)和需求管理這兩個過程,這里有個特別的情況是對于自主研發(fā)的項(xiàng)目,我接觸的項(xiàng)目也是這種情況居多,于是我們認(rèn)為自己就是客戶,所以需求開發(fā)做的很簡單甚至跳過去,結(jié)果后期的需求管理非?;靵y,我覺得既然自己是客戶,那就要當(dāng)好客戶這個角色,在做客戶時應(yīng)完全忘卻自己是個開發(fā)人員,同樣要把需求做全面。很多教科書上都說應(yīng)該做需求,但關(guān)于怎么做的問題上卻和實(shí)際情況差別比較大,以下是我關(guān)于需求該做什么以及怎么做到一些看法。
    1 需求調(diào)研
    我覺得需求調(diào)研非常的重要,1年前我還打算做一個在線教育服務(wù)平臺,理念就是淘寶在網(wǎng)上賣商品,我在網(wǎng)上賣教育資源,我提供網(wǎng)上交易場所,簽約的老師、學(xué)校以及培訓(xùn)機(jī)構(gòu)提供可交易的服務(wù),這種服務(wù)可以通過視頻、音頻、在線PPT、文本的形式展現(xiàn)。忙活了好一陣,發(fā)現(xiàn)這個市場早就有很多人做了,而且這個市場并不是很好做,首先在網(wǎng)上學(xué)習(xí)的人有幾個?并且先不說前期推廣需要海量資金就是所需要的那么些高性能服務(wù)器丫也買不起!這件事就此擱淺,結(jié)果信了馬云的邪,2年后你還想創(chuàng)業(yè)你在創(chuàng)業(yè)!我覺得這就是典型的需求調(diào)研沒做好,沒有對用戶需求做調(diào)查,沒有考慮同行競爭,沒有考慮可行性!另外還要考慮括行業(yè)標(biāo)準(zhǔn)和法律規(guī)定,比如前些時候國家就出臺了關(guān)于辦視頻網(wǎng)站的政策,我覺得你丫沒有足夠的背景就不要往火坑里跳樓。總之根據(jù)所做行業(yè)情況盡可能的把需求調(diào)研做全面,這樣才可以保證項(xiàng)目首先是可以賺錢的。那么文檔要寫嗎?我覺得可以不要正式的文檔,小公司的人手本來就不夠用,要把主要文檔化工作集中在重要的環(huán)節(jié)上,對于需求調(diào)研,本來就很雜亂,完全可以記在工作筆記上,放到需求分析的時候整理。
    2 需求分析
    為了得到用戶的金錢,我們總是在說,用戶是上帝,用戶永遠(yuǎn)是對的,盡管背地里在說客戶端壞話:“你丫錢給的倒不多,要求還真少,這需求根本不合理,是正常人的邏輯嗎?”,如果你想活下去,終我們還是要想方設(shè)法滿足用戶的要求。用戶是個外界因素,我們是無法控制的,那么我們只有盡可能改進(jìn)需求分析的方法來盡量減少不必要的麻煩。那么我覺得日本人做法倒是可以借鑒,在有條件的情況下派專人去現(xiàn)場,隨時記錄關(guān)鍵性的需求,即使不能去現(xiàn)場也盡可能的獲取盡可能多大信息,不要指望開發(fā)后去獲取什么有價值的東西。那么是否應(yīng)該做個原型給客戶看看?我是覺得這不大合適,因?yàn)槿绻?xiàng)目周期短的話,等你做好原型,黃花菜都涼了。但我覺得等到需求做到差不多的時候可以做用戶界面,所謂用戶界面就是用戶接口,是和用戶打交道的地方,所謂一圖解千言,有了界面用戶會清楚自己所買的東西在未來會是個什么樣的東西,再者開發(fā)幾個有說明性都界面倒是不會暫用很多時間。等到需求確定下來后就要整理成文檔了,這個是很重要的一步,是做設(shè)計(jì)時候的重要憑證和依據(jù),這個文檔就是用戶規(guī)格說明書,所謂規(guī)格就是有規(guī)范的格式和內(nèi)容。
    3 需求評審
    我們已經(jīng)有了較正規(guī)的文檔了,那么下一步就是召集所有開發(fā)人員開會,好有客戶代表參加,盡管我是很厭煩開會,但該開的會還是要開到,因?yàn)橹拔矣龅竭@種情況,開發(fā)人員根據(jù)設(shè)計(jì)文檔寫代碼,可是他并不知道自己在開發(fā)什么,站在自己的角度想一下,如果自己都不確定自己做的東西,即使有再完備的設(shè)計(jì),也會對開發(fā)毫無興趣,只會讓自己覺得自己是個代碼機(jī)器。所以所有人員參加需求評審是讓大家知道自己在做一件有意義的事情,自己正在滿足社會的需要,自己在為和諧社會做貢獻(xiàn),即使你從沒那么想過,那你敢保證的你的潛意識沒那么想過嗎?人是要有社會滿足感的吧。另外開會前一定要準(zhǔn)備關(guān)鍵有價值的議題,據(jù)我觀察需求評審會容易扯到不著邊的話題,所以主持人要控制話題,會議控制在2-3個鐘頭,好做成幸運(yùn)52的形式,所有人員一定要互動起來,否則就變成了個人演講。需求也做了,會也開了,那么要求客戶簽字吧。
    4 需求管理
    需求管理是在開發(fā)開始之后進(jìn)行的,這也是另所有人頭疼的一件事,之前做完一個項(xiàng)目后,客戶經(jīng)常打電話找我們,改過來改過去,后來我聽到電話,血壓都要升高50個百分點(diǎn),后來索性就不接電話,客戶就在網(wǎng)上找我,搞的我連QQ都不敢登,但躲是躲不掉滴,客戶直接打我手機(jī),丫的真煩人,見過難纏的,沒見過這么難纏的。后來轉(zhuǎn)念一想,難道這種情況真的不能避免嗎?至少是可以大幅度的緩解的吧。這就是我們需求管理中的變更管理沒做好,改了哪些地方自己都忘記了,后是跟著感覺走,拆東墻補(bǔ)西墻。在這里我建議要建立需求跟蹤矩陣表,有了這個表我們至少可以對要修改的地方有了依據(jù),迫使我們?nèi)フ{(diào)查到底是改什么地方,怎么改,后改成了什么樣??赡苣銜f客戶需要大幅度修改原有計(jì)劃,很難跟蹤到具體某一項(xiàng)需求,那么我覺得這是由于前期的需求開發(fā)沒有做好,在后期客戶進(jìn)行實(shí)質(zhì)性的修改的幾率是很小的,比如客戶要求我們做個OA系統(tǒng),后總不會要我們改成個門戶網(wǎng)站吧,在舉個例子,在比如你開發(fā)一個ERP系統(tǒng),客戶自己的業(yè)務(wù)流程不會輕易的改變吧,總不至于把盤點(diǎn)這個業(yè)務(wù)改成一個報(bào)表系統(tǒng)吧。如果真是這樣,我們完全有理由告訴客戶,你丫乖乖掏銀子,我們再給你們開發(fā)2期工程,要改,沒門!
    二、項(xiàng)目規(guī)劃和項(xiàng)目監(jiān)控
    上邊我簡要談了項(xiàng)目管理中的需求開發(fā)和管理,那么在這里就和各位以閑話家常的方式討論下項(xiàng)目規(guī)劃和項(xiàng)目監(jiān)控。項(xiàng)目規(guī)劃、項(xiàng)目監(jiān)控其實(shí)也是項(xiàng)目管理中比較核心的工作,也是很多開發(fā)人員敏感的話題,因?yàn)檫@兩個東西與公司的領(lǐng)導(dǎo)和員工關(guān)系都非常的密切。
    先從我以前的學(xué)校說起,以前我們學(xué)校有片荒地,當(dāng)時的領(lǐng)導(dǎo)覺得學(xué)校應(yīng)該搞綠化,于是組織在荒地上植樹,不到一年換了一個校長,這位校長覺得學(xué)校應(yīng)該抓體育運(yùn)動,決定再造一個足球場,于是把樹移走,造了一個足球場,再后來北京奧運(yùn)會來了,學(xué)習(xí)為了迎合綠色奧運(yùn)的理念又開始植樹,這就是沒有規(guī)劃和監(jiān)控的典型例子,結(jié)果是勞民又傷財(cái)。當(dāng)然對于學(xué)校來說,有國家財(cái)政的支持,有資本這么折騰,可是對于小公司做項(xiàng)目來說,這么折騰幾下估計(jì)很快就要犧牲了。
    事實(shí)求是的說大多數(shù)小公司在這兩個方面做得很少有令人的滿意的,小公司的老板其實(shí)也會意識到公司在項(xiàng)目規(guī)劃和監(jiān)控方面做得不咋地,但很少能做到有效的改進(jìn),其實(shí)這個也是有很多方面的原因的,以我自作多情的猜測主要有以下兩個原因,對于小公司,盡管盈利不是很多,但基本還是可以撐下去的,老板會覺得管他亂不亂,公司總之每個月還是有盈利的,少就少點(diǎn)吧,多干幾年自己的下半輩子基本有別墅有車了,所以比較保守,要是改革吧,萬一雞飛蛋打怎么辦?還是本分點(diǎn)好,小心使得萬年船。其實(shí)是對項(xiàng)目規(guī)劃和監(jiān)控其實(shí)需要大量的成本,老板覺得錢應(yīng)該花在刀刃上,搞這些東西就是在*。再者更惡劣的老板有病就亂燒香,就有想想借助CMMI這個洋玩意治病的,其實(shí)很多老板都蠻喜歡CMMI的,CMMI就是假定人就是一個機(jī)器的部件,可以替換可以不停的運(yùn)轉(zhuǎn),總之管機(jī)器總比管人省心吧,結(jié)果是萬分的矛盾,銀子撒了一大把,收效卻甚微,甚至比以前更亂,大家做的都不開心。與其聽咨詢師們拿什么高深的方法論來瞎掰,不如我們談點(diǎn)實(shí)際的,想就以下議題來和各位消遣。
    1 工作量估算
    對于工作量估算很多項(xiàng)目經(jīng)理(老板)喜歡用數(shù)學(xué)公式來計(jì)算,可能數(shù)學(xué)公式更加的客觀和科學(xué),ok,,看看市面流行的計(jì)算方法吧,常見的是基于代碼行的數(shù)學(xué)模型,那么這里存在不少問題,工作量估算主要是為了在項(xiàng)目進(jìn)行中進(jìn)行有效的項(xiàng)目監(jiān)控,那么軟件開發(fā)尚未結(jié)束,誰知道后的代碼行有多大?代碼經(jīng)常會被修改,那么修改的代碼算不算?如果算,那么代碼修改越多難道能說明工作量越大?代碼效率的區(qū)別也是很大的,假如一個10行代碼可以實(shí)現(xiàn)的東西被寫成50行,難道能客觀的反映工作量?還有2種比較高級點(diǎn)的方法是基于功能點(diǎn)和COCOMO的方法,那么我想問的是它們的公式中的系數(shù)該怎么定?那么不少咨詢師忽悠我說,根據(jù)自己的實(shí)際情況來定唄,那么我想問的是,算命是迷信,電腦意味著科學(xué),那么用電腦算命算不算迷信?所以我是主張這里還是要靠人的經(jīng)驗(yàn)來估算,大家可以在項(xiàng)目周會上對工作量進(jìn)行充分的估算,在估算時要同時考慮到項(xiàng)目執(zhí)行的難度,根據(jù)經(jīng)驗(yàn)給出合理的評估。
    2 任務(wù)分配
    大多數(shù)的做法是將整個項(xiàng)目劃分成一個個可以獨(dú)立執(zhí)行的原子任務(wù),這些任務(wù)要劃分優(yōu)先級和難度,至少心理有個數(shù),并且每項(xiàng)任務(wù)要制定負(fù)責(zé)人。那么問題就出在這個任務(wù)分配上了,軟件開發(fā)是一項(xiàng)智力創(chuàng)造的活動,如果按CMMI假設(shè)的那樣,在分配任務(wù)時忽略人的因素是萬萬不可取的,我就有血的教訓(xùn),不久之前做一個ruby的項(xiàng)目,然后開始在公司內(nèi)部隨便抓了幾個有點(diǎn)ruby基礎(chǔ)的人,也沒太顧忌別人的想法。做著做著,覺得他們有點(diǎn)心在曹營心在漢,平時還是抱著本thinking in java看,做ruby也是在敷衍了事,結(jié)果是代碼質(zhì)量不行,需要大規(guī)模的修改。當(dāng)然按理說員工應(yīng)該服從公司的安排,做一樣就要做好一樣,但員工也有員工的規(guī)劃,你去叫他做他壓根就不喜歡的事只能說明管理有問題。
    另外還有一個普遍性的問題是能者多勞,有個朋友剛進(jìn)公司動手能力很強(qiáng),也非常的積極,每次做項(xiàng)目都分給他難累的任務(wù),做著做著也就厭倦了,這時老板會忽悠你說,你能力強(qiáng),要挑起公司的大梁,以后公司壯大了給你個什么職位,我覺得這就是在扯淡,這就是我經(jīng)常見到的忽悠式的管理,很多管理手段完全靠人情,很多人都是在這種環(huán)境中被忽悠長大,到后怎么樣?被忽悠了幾年還不是另謀高就了,所以指望人情化管理的公司很難長大。我覺得該講原則的地方就要講原則,在任務(wù)分配上給能力強(qiáng)的分配少而精的任務(wù),而且要考慮到員工自己的想法,有些人想做java架構(gòu)師,你叫他做oracle dba就不合適,有些對ui設(shè)計(jì)感興趣,你叫他做系統(tǒng)分析員也不合適,有些人就喜歡搞技術(shù),你硬要叫他做管理也是不合適。
    3 進(jìn)度管理
    在做進(jìn)度之前,一項(xiàng)重要的任務(wù)是識別關(guān)鍵任務(wù),很多進(jìn)度表進(jìn)行任務(wù)安排時將各項(xiàng)任務(wù)平均分的特點(diǎn)為覺得極不合適,有些任務(wù)比較難處理,而且許多后續(xù)任務(wù)依賴于該項(xiàng)任務(wù),那么這項(xiàng)任務(wù)就應(yīng)該配備更精良的人手和充裕的時間,依我的經(jīng)驗(yàn)80%的時間都是在處理這些20%的關(guān)鍵任務(wù)上。這里還有個比較重要的問題是時間安排,我聽很多項(xiàng)目經(jīng)理說時間安排要盡可能的緊,也就是比預(yù)計(jì)要靠前,這樣員工才有緊迫感。我覺得這是不可取的,首先即使你按原計(jì)劃進(jìn)行,八成也是要要延期的,那么這就會導(dǎo)致項(xiàng)目嚴(yán)重延期,長此以往,項(xiàng)目延期成了家常便飯,不延期反而不正常,于是大家都成了老油條,那么進(jìn)度表不就是廢紙一張,毫無約束力而言嗎!我覺得根據(jù)實(shí)際情況指定個合理的進(jìn)度表是比較重要的,或許你會說項(xiàng)目還是在延期,那我覺得是你項(xiàng)目估算沒有做好,項(xiàng)目延期在10%左右比較正常,否則就可以調(diào)查是什么原因?qū)е逻M(jìn)度滯后,如果是客觀原因,以后完全可以延長項(xiàng)目時間,總之一個合理的進(jìn)度表比較重要。
    4 項(xiàng)目獎金
    這里牽扯到一個錢的問題,據(jù)我了解國內(nèi)大多小公司很少有項(xiàng)目獎金這么一說,年底給點(diǎn)路費(fèi)就不錯了!國內(nèi)的大多數(shù)項(xiàng)目經(jīng)理更像是一個技術(shù)負(fù)責(zé)人,根本沒有用錢的權(quán)利,我就曾像公司申請項(xiàng)目獎金,結(jié)果計(jì)劃全盤泡湯,給的理由很荒唐,說項(xiàng)目獎金不好分配,給張三多一點(diǎn)吧,李四不爽,反之亦然。我心理暗自想:“你丫不想給就直說唄!”,這里會導(dǎo)致一個問題,就是“項(xiàng)目經(jīng)理”憑什么約束成員,大鍋飯的道理我也不想再解釋了,總之結(jié)果就是3個月的項(xiàng)目就得做個5個月,其實(shí)老板的小算盤看似很精明,其實(shí)未見得,雖然項(xiàng)目獎金能省就省了,那么工作效率的下降所帶來的成本的提高,孰輕孰重?長遠(yuǎn)一點(diǎn)說,產(chǎn)品質(zhì)量的下滑導(dǎo)致的項(xiàng)目維護(hù)的成本你計(jì)算過嗎?依我的經(jīng)驗(yàn),3個月的有效工作時間其實(shí)也就是1個月,這已經(jīng)不錯了。不過項(xiàng)目獎金的分配確實(shí)是個難問題,但有沒有項(xiàng)目獎金和分配合理與否是2碼子事吧?由于我也沒有能耐申請到項(xiàng)目獎金所以也就沒有深入研究這個問題,只得望梅止渴,看看人家華為了,員工根據(jù)能力分等級,加上年限、加班、表現(xiàn)得出個權(quán)值來計(jì)算。總之現(xiàn)有雞才能有蛋,這個問題需要更深入的討論。