以下的這個案例非常常見,相信大部分項目經理都遇到過類似的問題。 項目背景: 某項目的主要工作已經基本完成,經核對項目的“未完成任務清單”后,終于可以提交客戶方代表老劉驗收了。在驗收過程中,老劉提出了一些小問題。項目經理張某帶領團隊很快妥善解決了這些問題。但是隨著時間的推移,客戶的問題似乎不斷。時間已經超過系統試用期,但是客戶仍然提出一些小問題,而有些問題都是客戶方曾經提出過,并實際已經解決了的問題。時間一天一天的過去,張某不知道什么時候項目才能驗收,才能結項,才能得到最后一批款項。 請分析發生這件事情可能的原因: (1)合同中缺乏以下內容: 項目目標中關于產品功能和交付物組成的清晰描述; 項目驗收標準、驗收步驟和......
當您打算開展一個軟件項目的時候,會面臨很多問題和選擇,其中之一就是到底把項目交給軟件公司來做呢?還是外包給軟件開發自由職業者?最近跟幾個朋友都討論到這個問題,故寫此文,試圖對二者進行一些對比,給您一個參考。 結論:軟件公司和個人職業者,沒有絕對的高下,只是相對來說在某些方面各有優勢。因此它們都有自己所適合的場景,總體來說,要根據您所處的情境來選擇: 1)如果您對價格比較敏感,有較多時間來管理自己的項目,同時項目較簡單,技術風險不高,適合于一個人在短期內完成,可以更多地考慮自由職業者; 2)如果您尋找的是長期穩固的合作伙伴,而且很可能在將來擴充您的團隊;或者項目存在一定的技術風險,工作量較多較復雜,需要團隊配合才能完成;又或者是......
最近有一個哥們很郁悶,找我訴苦:“我們現在軟件做得差不多了,但是實施起來難度很大,員工不愿意用,老板的意思是既然要做軟件,那么軟件就能要求員工必須用。軟件如何去迫使員工必須用呢?”他夾在中間感覺非常為難,不知道該如何回復老板。這種情形,我一聽就感同身受,完全能夠理解他的處境,為什么?因為這現象在軟件行業,尤其是企業信息化的過程中,相當常見。 過程一般是這樣: 1. 公司高層上套新系統,員工卻不愿意用; 2. 于是高層推出行政命令強迫員工必須用; 3. 員工依然不配合,當被追究時,說軟件不好用; 4. 公司領導找到倒霉的開發團隊,說你的軟件必須要解決員工不愿意用的問題,這是你軟件的問題; 大家來評評理,到底是哪里有問題? ......
近日,某軟件開發項目完成結項,在進行總結時,項目經理提出了不少問題。其中大多數都是些常見的癥狀,并不是這個項目所獨有的,也不是以前沒見過的。于是問題產生了,為什么這些教訓在不同的項目中反復發生?能不能采取些措施,來規避它們或降低這些問題的負面影響呢?經過這么一思考,我發現在軟件開發項目的實施過程中,還真有不少問題是可以提前預見到的,與其被動等待事情發生后再去應對,不如及早采取方案來控制它。正應了中國人的一句古話:“凡事預則立”。 下面對這幾條問題及其對策,簡單進行下分享: 問題1:在項目過程中,客戶對平臺操作不熟,很多問題都來找團隊指導、答疑;而這些導致工作時常中斷,占用不少時間,卻又不在最初的工作范圍中,沒有報價; ......
前兩天有個項目,客戶要求在3月17號前要完成第一期工作,因為他在3月17號安排了一個重要的演示(Demonstrate),團隊根據客戶的要求,制定了在3月14號給客戶提交版本的計劃。3月14號當天,由于工作整合時發現有較多問題,未能成功交付,于是整個團隊在3月15號(周六)主動加了一天班,終于在3月15號完成提交。3月17號(周一)來上班時,發現客戶對交付物進行了驗收,并且提了一些需要修改的Bug,要求盡量在當天改完。當天經過團隊的努力,修改好了客戶反饋的Bug,并且再次提交。晚上,客戶發郵件說程序無法工作,未能成功演示,郵件中充斥著不滿的情緒。為什么團隊成員的努力工作,卻未能換來客戶的肯定和滿意?到底是哪里出了問題?如何才能避免這樣的場景呢? 仔細分析下這個案例,......
以前有個小朋友,特別有好奇心,也喜歡動手搗騰。有一天,他做出來了一個圓圓的,會滾動的東西,感到特別興奮,到處去向別人展示自己的"新發明"。結果他發現別人一點都不稀奇,原來這個東西叫做“輪子”,早在幾千年前就有了,現在已經發展出了上百種的不同規格、材質、樣式,自己的這個相比之下太不完善了,根本不能算是什么發明。這個小朋友,現在就藏在我們的心里,尤其是經驗不夠豐富的程序員身上。 幾年前我曾經做過一個項目,經過長時間的掙扎之后,項目依然失敗了。主要的原因之一,就是我們重復發明了太多的輪子。事情是這樣的,時任項目核心開發人員的 同事很有鉆研精神,也相當自信,當時客戶提出的一些基本功能,譬如用戶管理、輸入驗證、......
最近丟了個價值8000美金的項目,剛開始不到一周就被客戶叫停,以前從未發生這樣的事情,被上了非常昂貴的一堂課。為了讓這堂成本8000美金的課程價值最大化,我覺得有必要把從中得到的經驗教訓分享出來,希望能警醒更多的項目經理,幫助更多的人少走彎路。 事情是這樣的:上周五有一個項目啟動了,這是個老客戶轉交過來的新項目,要得比較急,因而客戶也特別關注項目的進度。通過最初的溝通,我們應允客戶每天給他發日報反饋項目進展,但由于人員受其它項目影響,未能及時到位,直到本周三項目都未能投入多少時間,因而項目經理也一直未發日報。到了周四,客戶要求Skype溝通,并且在溝通中又特別強調了需要日報反饋項目進度的問題,同時團隊也答應周四晚上......
1. 明確范圍 如果說要把整個項目(假設持續2個月,分為4次迭代)的范圍,在一開始就明確下來,對我們、對客戶都很困難,因而這個期望不太現實;更可行的辦法是把范圍的明確,也拆分成更小的單位,譬如按照每個迭代(每兩周)來明確;我們雙方只要保證,對這兩周要提交的內容,有明確的共同認識即可;然后不斷循環; 明確下來的范圍,要有個Task List或者Plan來作為以后判斷是否發生范圍改變的依據; 2. 范圍變更 如上所述,如果每兩周一個迭代,每次迭代都有明確的Task List或Plan;那么在這個過程中,任何不在這個List和Plan中的任務,都可以視為需求變更、范圍變化; 這種變更,需要在客戶剛提出來時,就進行評估,明確告訴客戶這個改變所需要的額外時間,......