重慶諾懷軟件有限公司軟件開發(fā), app開發(fā), 微信開發(fā), 小程序開發(fā) - 軟件開發(fā)

項目管理案例分析（一）

eliza — Tue, 19 Jul 2016 05:17:18 +0000

以下的這個案例非常常見，相信大部分項目經(jīng)理都遇到過類似的問題。

項目背景：

某項目的主要工作已經(jīng)基本完成，經(jīng)核對項目的“未完成任務(wù)清單”后，終于可以提交客戶方代表老劉驗收了。在驗收過程中，老劉提出了一些小問題。項目經(jīng)理張某帶領(lǐng)團隊很快妥善解決了這些問題。但是隨著時間的推移，客戶的問題似乎不斷。時間已經(jīng)超過系統(tǒng)試用期，但是客戶仍然提出一些小問題，而有些問題都是客戶方曾經(jīng)提出過，并實際已經(jīng)解決了的問題。時間一天一天的過去，張某不知道什么時候項目才能驗收，才能結(jié)項，才能得到最后一批款項。

請分析發(fā)生這件事情可能的原因：

（1）合同中缺乏以下內(nèi)容：

項目目標中關(guān)于產(chǎn)品功能和交付物組成的清晰描述；
項目驗收標準、驗收步驟和方法；
對客戶的明確服務(wù)承諾；

（2）項目實施過程中控制出現(xiàn)問題：

在項目實施過程中沒有及時傳遞項目進展?fàn)顟B(tài)報告給客戶，因此客戶對項目的質(zhì)量情況不了解；
沒有讓客戶及時對階段交付成果進行簽字確認；

（3）客戶對項目質(zhì)量信息不足，怕承擔(dān)責(zé)任，因此不愿簽字；

（4）合作氛圍不良，客戶存在某種程度的抵觸情緒，雙方缺乏信任感。

請說明張某現(xiàn)在應(yīng)該怎么辦？

只能采取補救措施，靠加強溝通來解決問題。

就項目驗收標準和客戶達成共識，確定哪些主要工作完成即可驗收通過；
就項目驗收步驟和方法和客戶達成共識；
就項目已經(jīng)完成的程度讓客戶確認。例如出具系統(tǒng)試用報告，讓客戶簽字確認；
向客戶提出明確的服務(wù)承諾，是客戶沒有后顧之憂。

請說明應(yīng)當(dāng)吸取的經(jīng)驗和教訓(xùn)：

項目合同中要確定項目成果的正式驗收標準、驗收步驟、驗收方法和運營維護服務(wù)承諾等；
加強項目執(zhí)行過程中的控制，及時向客戶提供項目績效報告，讓客戶了解項目進展；設(shè)置階段性成果的驗收，并讓客戶對階段性交付成果進行簽字確認；范圍的變更要按照變更控制程序操作；
項目文檔要齊全，使項目進展有據(jù)可查；
項目經(jīng)理應(yīng)及時與客戶溝通，努力促成雙方的良好合作氛圍。

諾懷博客標簽:

把項目交給自由職業(yè)者還是軟件公司？

Caven — Fri, 16 Jan 2015 09:52:36 +0000

當(dāng)您打算開展一個軟件項目的時候，會面臨很多問題和選擇，其中之一就是到底把項目交給軟件公司來做呢？還是外包給軟件開發(fā)自由職業(yè)者？最近跟幾個朋友都討論到這個問題，故寫此文，試圖對二者進行一些對比，給您一個參考。

結(jié)論：軟件公司和個人職業(yè)者，沒有絕對的高下，只是相對來說在某些方面各有優(yōu)勢。因此它們都有自己所適合的場景，總體來說，要根據(jù)您所處的情境來選擇：

1）如果您對價格比較敏感，有較多時間來管理自己的項目，同時項目較簡單，技術(shù)風(fēng)險不高，適合于一個人在短期內(nèi)完成，可以更多地考慮自由職業(yè)者；

2）如果您尋找的是長期穩(wěn)固的合作伙伴，而且很可能在將來擴充您的團隊；或者項目存在一定的技術(shù)風(fēng)險，工作量較多較復(fù)雜，需要團隊配合才能完成；又或者是您本人不太擅長管理軟件開發(fā)項目，那么找軟件外包公司應(yīng)該是個更好的選擇。

諾懷博客標簽:

企業(yè)信息化建設(shè)的三大誤區(qū)

Caven — Fri, 16 Jan 2015 08:42:35 +0000

最近有一個哥們很郁悶，找我訴苦：“我們現(xiàn)在軟件做得差不多了，但是實施起來難度很大，員工不愿意用，老板的意思是既然要做軟件，那么軟件就能要求員工必須用。軟件如何去迫使員工必須用呢？?”他夾在中間感覺非常為難，不知道該如何回復(fù)老板。這種情形，我一聽就感同身受，完全能夠理解他的處境，為什么？因為這現(xiàn)象在軟件行業(yè)，尤其是企業(yè)信息化的過程中，相當(dāng)常見。

過程一般是這樣：

1. 公司高層上套新系統(tǒng)，員工卻不愿意用；

2. 于是高層推出行政命令強迫員工必須用；

3. 員工依然不配合，當(dāng)被追究時，說軟件不好用；

4. 公司領(lǐng)導(dǎo)找到倒霉的開發(fā)團隊，說你的軟件必須要解決員工不愿意用的問題，這是你軟件的問題；

大家來評評理，到底是哪里有問題？

之所以會出現(xiàn)這樣的事情，究其原因有很多，然而主要的問題還在于大家對“企業(yè)信息化”的認識不夠到位，缺乏正確的方式方法。為了幫助大家少走些彎路，我這里總結(jié)了下企業(yè)信息化過程中常見的三大誤區(qū)：

誤區(qū)一：所有的問題都是軟件的問題；

這里我必須替勤勞實在的技術(shù)人員說句話，企業(yè)信息化的問題，還真不是僅用軟件就能解決的，這里面還有很多其它的問題，譬如企業(yè)文化的問題、變革的問題。為什么這樣說？因為軟件是為企業(yè)業(yè)務(wù)服務(wù)的，上新系統(tǒng)時，常常會對企業(yè)現(xiàn)有的業(yè)務(wù)流程、工作方式等帶來改變（通常都是企業(yè)管理層想對它們進行一些升級或優(yōu) 化），而這些改變常常會對一線人員帶來一些負擔(dān)（有時候僅僅是讓他做出改變就已經(jīng)是負擔(dān)了）。如何讓基層員工主動來配合或適應(yīng)這些變化，如何消除或降低基層對變革的抵觸，是軟件的問題么？

誤區(qū)二：基層用戶只需要拿到軟件去用即可；

這里我是替企業(yè)基層說句話，請不要忽略他們的需求，他們在工作中也會遇到很多問題，也需要有人能幫他們解決問題，而不是簡單地由外面來強加一套程序要求他用（通常這會增加他的工作內(nèi)容）。很多時候，實際的工作情況并不是遠離一線的企業(yè)高層所想象的那樣，更不是另一家公司的程序員所能理解的。如果他們對一線工作不理解，同時又沒有讓一線人員參與到整個程序的開發(fā)過程中，做出來的東西適用么？

誤區(qū)三：可以靠行政手段實現(xiàn)信息化；

這是長期處于權(quán)力中心的人，最愿意相信的假象。在企業(yè)里，公司高層傾向于認為通過行政命令，以及規(guī)章制度的要求，可以迫使大家接受信息化帶來的改變。然而不要忘了中國的老話“上有政策，下有對策”，在聰明的中國人面前，要讓他接受自己所不認可的東西，那是非常困難的。要么是做做表面功夫應(yīng)付下，要么就是暫時被動接受了，以后你沒盯這么緊了再反彈。無論是哪種情況，都讓企業(yè)無法充分利用信息化帶來的優(yōu)勢，甚至是根本達不到上軟件系統(tǒng)的初衷。

那么問題來了，既然這樣行不通，我們應(yīng)該如何做才好？出路在何方？

其實，引入軟件系統(tǒng)跟引入一套新的管理流程一樣，涉及到企業(yè)變革管理的問題。企業(yè)領(lǐng)導(dǎo)層最好平時就打造一種精益求精、擁抱變化的企業(yè)文化。并且在上系統(tǒng)前，內(nèi)部充分溝通，讓大家了解到上這套系統(tǒng)對公司和他個人的意義，從意識上先讓員工接受這個變化并為之做好準備。同時，還要在系統(tǒng)開發(fā)的過程中，盡量讓員工代表多參與，使軟件能夠體現(xiàn)他們的需要，解決他們的問題（而不僅僅是企業(yè)領(lǐng)導(dǎo)層的），甚至是派員工代表跟軟件團隊一起工作。這樣在系統(tǒng)上線后，要求大家使用時，阻力應(yīng)該會小些。如果依然遇到員工抵觸，不要簡單歸結(jié)為是這個員工的問題（行政處罰）或者是軟件的問題。要深入溝通了解下他為什么不愿意用，到底是什么阻礙了他？是個人的問題就提供幫助（如進行培訓(xùn)），是軟件的問題就要求改正。另外，軟件系統(tǒng)也可以分為幾期逐步完善，小步快跑，不要試圖一步到位，這不但能降低實施的壓力，而且也符合“需求漸進明細”的規(guī)律。

希望這幾點認知，能幫助大家更加順利地實施企業(yè)信息化。?

諾懷博客標簽:

軟件開發(fā)項目管理-凡事預(yù)則立

Caven — Fri, 16 Jan 2015 08:38:42 +0000

近日，某軟件開發(fā)項目完成結(jié)項，在進行總結(jié)時，項目經(jīng)理提出了不少問題。其中大多數(shù)都是些常見的癥狀，并不是這個項目所獨有的，也不是以前沒見過的。于是問題產(chǎn)生了，為什么這些教訓(xùn)在不同的項目中?反復(fù)?發(fā)生？能不能采取些措施，來規(guī)避它們或降低這些問題的負面影響呢？經(jīng)過這么一思考，我發(fā)現(xiàn)在軟件開發(fā)項目的實施過程中，還真有不少問題是可以提前預(yù)見到的，與其被動等待事情發(fā)生后再去應(yīng)對，不如及早采取方案來控制它。正應(yīng)了中國人的一句古話：“凡事預(yù)則立”。

下面對這幾條問題及其對策，簡單進行下分享：

問題1：在項目過程中，客戶對平臺操作不熟，很多問題都來找團隊指導(dǎo)、答疑；而這些導(dǎo)致工作時常中斷，占用不少時間，卻又不在最初的工作范圍中，沒有報價；
問題2：客戶經(jīng)常出差，而且不通知團隊，項目組經(jīng)常聯(lián)系不上客戶；問題得不到及時反饋，影響項目進展；
問題3：客戶看到系統(tǒng)后，在測試過程中提出很多不在最初需求內(nèi)的改動；而這些改動所對應(yīng)的工作量又在最初沒有報價，同時客戶追加預(yù)算又很困難；
問題4：幫助客戶部署時，遇到很多問題，比如:服務(wù)器里面沒有安裝任何軟件，服務(wù)器太差，時不時的死機；導(dǎo)致工作量大大超出最初預(yù)期；

如果是做軟件的同行，這些問題看著都不陌生吧？是不是每個項目都有可能遇到？如果一件事情我們能預(yù)見到它很可能發(fā)生，而且又會對項目帶來不利影響，那么我們就應(yīng)該對其進行風(fēng)險管理，不是么？其實解決這幾個問題的對策也都很簡單，就是提前預(yù)案下而已：

對策1：既然每個客戶在項目過程中，都需要或多或少的技術(shù)支持；那么制定項目計劃時，團隊直接跟客戶溝通所需要的支持內(nèi)容；或者根據(jù)客戶背景來判斷所需支持程度的大??；并且把這部分工作內(nèi)容放入計劃中；
對策2：每個項目都需要客戶的參與和配合，都是在跟客戶互動的過程中完成的。那么，團隊能否一開始就跟客戶確認好其參與方式和參與程度？或者把項目需要客戶參與的地方先明確告知？如果開始有這么一個溝通，就能發(fā)現(xiàn)“客戶可能會經(jīng)常出差”，這樣就可以在項目安排上做出對應(yīng)的調(diào)整。譬如項目早期需求溝通更深入一些，減少執(zhí)行過程中對客戶的依賴；或者把工期拉長以配合客戶行程，etc.；
對策3：需求的變化是必然的，目前為止，還沒有聽說過需求不發(fā)生變化的軟件項目。而且，在客戶看到系統(tǒng)的那一刻，會產(chǎn)生幾十個上百個新的想法，都很正常。問題在于，這些變化可能導(dǎo)致工期延長、費用增加的事實，雙方如何應(yīng)對？如果一開始大家沒說清楚，當(dāng)變更發(fā)生時，各持一詞，就很容易演變成討價還價和扯皮，如果一開始雙方達成了共識，那么屆時都有準備，按照流程處理即可，皆大歡喜；這只需要在項目啟動之初，雙方溝通確認下需求變更處理流程，“預(yù)”一下；
對策4：大多數(shù)軟件項目，都需要幫助客戶部署；而每個部署，都必然涉及到部署環(huán)境和服務(wù)器配置的問題；團隊事先向客戶了解下其部署環(huán)境和服務(wù)器配置，再進行相應(yīng)的工作量估計，自然可以規(guī)避；

總之，這些問題不難提前想到，對策也并不復(fù)雜，只需要項目經(jīng)理們多“預(yù)一預(yù)”就可以規(guī)避不少風(fēng)險。項目上諸如此類的問題有不少，身為項目經(jīng)理，除了關(guān)注項目的任務(wù)，還應(yīng)該多注意下跟客戶配合互動這個層面。雖然每個項目都存在其獨特性，但項目中經(jīng)常遇到的一些問題也是有共性的，好的項目管理就是要能事先預(yù)見到這些容易出現(xiàn)的“坑”，并準備好對應(yīng)的"蘿卜"，才不至于臨陣磨槍。

諾懷博客標簽:

如何確?？蛻鬌emo的成功

Caven — Fri, 16 Jan 2015 08:26:47 +0000

前兩天有個項目，客戶要求在3月17號前要完成第一期工作，因為他在3月17號安排了一個重要的演示（Demonstrate），團隊根據(jù)客戶的要求，制定了在3月14號給客戶提交版本的計劃。3月14號當(dāng)天，由于工作整合時發(fā)現(xiàn)有較多問題，未能成功交付，于是整個團隊在3月15號（周六）主動加了一天班，終于在3月15號完成提交。3月17號（周一）來上班時，發(fā)現(xiàn)客戶對交付物進行了驗收，并且提了一些需要修改的Bug，要求盡量在當(dāng)天改完。當(dāng)天經(jīng)過團隊的努力，修改好了客戶反饋的Bug，并且再次提交。晚上，客戶發(fā)郵件說程序無法工作，未能成功演示，郵件中充斥著不滿的情緒。為什么團隊成員的努力工作，卻未能換來客戶的肯定和滿意？到底是哪里出了問題？如何才能避免這樣的場景呢？

仔細分析下這個案例，不難發(fā)現(xiàn)下面這幾個事實：

A - 項目交付之后，客戶總是需要一些時間來驗收，團隊也需要一些時間來修改Bug，程序才能達到穩(wěn)定狀態(tài)；

B - 總是會出現(xiàn)些預(yù)料之外的事情，譬如整合時的問題，譬如提交后客戶無法運行的問題等，這些預(yù)料之外的事件會消耗掉不少時間和精力；

C - 上述兩個問題是可以提前預(yù)見的，因而可提前規(guī)劃對策，這樣會將其負面影響降到最低；

對此，總結(jié)出來的經(jīng)驗教訓(xùn)是：

團隊向客戶提交的日期（Deliver Day）比客戶的演示日期（Demo Day），至少要提前三個工作日；這段時間將用于客戶驗收測試、修改Bug、配置和部署演示環(huán)境、預(yù)演、以及應(yīng)對預(yù)料外的事情；
如果中途情況發(fā)生變化，無法準時提交，需要盡早更新計劃，并且及時跟客戶協(xié)商對策；譬如Cut掉一兩個功能、加班趕工、或是延后演示日期等；
建議客戶提前一天進行一場預(yù)演；
1. 調(diào)試好演示時要使用的環(huán)境和設(shè)備；
2. 準備好演示時要用到的數(shù)據(jù)；
3. 過一遍演示時將展示的功能；
提前獲取客戶的演示清單，包括將演示的功能列表、操作順序等；團隊內(nèi)部根據(jù)演示清單測試，盡量保持與客戶操作的一致性；
提前了解演示現(xiàn)場的環(huán)境，包括網(wǎng)絡(luò)環(huán)境、設(shè)備、操作系統(tǒng)、瀏覽器等；

諾懷博客標簽:

軟件開發(fā)金科玉律之-不要重復(fù)發(fā)明輪子!

Caven — Thu, 17 Apr 2014 08:29:05 +0000

?? ? 以前有個小朋友，特別有好奇心，也喜歡動手搗騰。有一天，他做出來了一個圓圓的，會滾動的東西，感到特別興奮，到處去向別人展示自己的"新發(fā)明"。結(jié)果他發(fā)現(xiàn)別人一點都不稀奇，原來這個東西叫做“輪子”，早在幾千年前就有了，現(xiàn)在已經(jīng)發(fā)展出了上百種的不同規(guī)格、材質(zhì)、樣式，自己的這個相比之下太不完善了，根本不能算是什么發(fā)明。這個小朋友，現(xiàn)在就藏在我們的心里，尤其是經(jīng)驗不夠豐富的程序員身上。

??? 幾年前我曾經(jīng)做過一個項目，經(jīng)過長時間的掙扎之后，項目依然失敗了。主要的原因之一，就是我們重復(fù)發(fā)明了太多的輪子。事情是這樣的，時任項目核心開發(fā)人員的同事很有鉆研精神，也相當(dāng)自信，當(dāng)時客戶提出的一些基本功能，譬如用戶管理、輸入驗證、內(nèi)容管理等，雖然市面上隨處可見現(xiàn)成的模塊和控件，可他總是覺得那些做得不夠好，說不如自己重新做一個方便，而且重新做更能符合客戶的特殊需求。我當(dāng)時作為PM，雖然對此略有質(zhì)疑，但看他自信滿滿很有激情，而項目時間也很寬松，就同意了。后來僅僅輸入驗證這個功能就推翻重來了三次，最終還是選用了一個現(xiàn)成的控件直接用，因為他做出來的太不具備通用性，十分難以維護；同時，用戶管理模塊也做得千瘡百孔，極不穩(wěn)定，出現(xiàn)了很多Bug和考慮不周全的地方，最后也不得不去找現(xiàn)有的成熟的組件替換。結(jié)果，這些“重復(fù)發(fā)明輪子”的開發(fā)工作，不但耗費了大量的時間、金錢和精力，而且也沒能發(fā)揮預(yù) 期的效用。事實證明，現(xiàn)成的控件“輪子”（開源的或收費的），經(jīng)歷過時間的檢測和眾人的改進，總比自己重新?lián)v騰出來的要更成熟、更穩(wěn)定，同時也更加省事、好用。我們在這個項目中花費了這么多時間、金錢、心血，終于證明了“不要重復(fù)發(fā)明輪子”這句話是很有道理的，這個慘痛的教訓(xùn)讓我迄今記憶猶新。

??? 雖然此事已經(jīng)時過境遷，但近些年來我發(fā)現(xiàn)有很多人都在“重復(fù)發(fā)明輪子”，尤其是在我們軟件開發(fā)這個圈子里面，年輕的小伙伴們充滿了發(fā)明輪子的欲望和激情，就好像那個可愛的小朋友一樣。因為他們覺得這樣做會讓自己學(xué)到很多東西，如果做出來了也會很有成就感。確實，成長和成就的確是他們所需要的東西。可如果你是客戶，你會愿意為此承擔(dān)更高的費用和風(fēng)險么？如果你是項目經(jīng)理呢，在成員練手跟項目成功交付之間，哪個更重要？

??? 我覺得如果出于練兵的目的，重新?lián)v騰一個輪子出來當(dāng)然是個好方法，就好像比賽開始前反復(fù)練習(xí)投籃一樣正常?？扇绻阋呀?jīng)上戰(zhàn)場了，已經(jīng)開始比賽了，已經(jīng)去幫客戶做項目了，這時候才來練習(xí)是非常不合適的。因為你很可能會因此而輸?shù)舯荣悺G掉客戶，而且因為你極其不專業(yè)的表現(xiàn)，會影響你的職業(yè)生涯。所以在公司里面，應(yīng) 該明確區(qū)分什么時候是練兵，什么時候是上陣，一定要杜絕上陣后才練兵的不專業(yè)表現(xiàn)。換句話說，工作中不要重復(fù)發(fā)明輪子，要練習(xí)投籃下場后自己慢慢練去，不要輕易浪費在賽場上的出手機會，just beprofessional.

諾懷博客標簽:

誠信：八千美金的一堂課

Caven — Fri, 21 Mar 2014 05:38:50 +0000

?? 最近丟了個價值8000美金的項目，剛開始不到一周就被客戶叫停，以前從未發(fā)生這樣的事情，被上了非常昂貴的一堂課。為了讓這堂成本8000美金的課程價值最大化，我覺得有必要把從中得到的經(jīng)驗教訓(xùn)分享出來，希望能警醒更多的項目經(jīng)理，幫助更多的人少走彎路。

?? 事情是這樣的：上周五有一個項目啟動了，這是個老客戶轉(zhuǎn)交過來的新項目，要得比較急，因而客戶也特別關(guān)注項目的進度。通過最初的溝通，我們應(yīng)允客戶每天給他發(fā)日報反饋項目進展，但由于人員受其它項目影響，未能及時到位，直到本周三項目都未能投入多少時間，因而項目經(jīng)理也一直未發(fā)日報。到了周四，客戶要求Skype溝通，并且在溝通中又特別強調(diào)了需要日報反饋項目進度的問題，同時團隊也答應(yīng)周四晚上向客戶提交2個功能點。而到了周四的晚上，客戶卻發(fā)郵件來強烈表示不滿，要中斷項目，原因是團隊當(dāng)天并沒有按照約定發(fā)報告給他反饋項目進展，承諾的2個功能也未能如期交付。更要命的是，與此同時團隊沒有給客戶任何說明和解釋。客戶說，他對這個項目的進展非常非常擔(dān)心，對整個團隊能否按時交付項目完全沒有任何信心。而團隊這邊卻認為雖然前期投入較少，但通過后面的努力，項目總體上是能夠按時完成的，只是當(dāng)天因為一些緊急問題影響了功能的提交和報告的發(fā)送，本打算第二天補上的，還未來得及補上，客戶就發(fā)飆了，似乎有點太小題大做了。這個案例里面存在哪些問題？大家可以慢慢分析，我想就把其中的誠信問題拿出來說下。

??? 所謂誠信，簡單點理解就是說到做到，答應(yīng)的事情要兌現(xiàn)。往小里說這是獲得客戶信任的基礎(chǔ)，往大了說這是做人的根本。譬如一個人你跟他合作，他答應(yīng)了你的事情總是跳票，不兌現(xiàn)，你還會選擇繼續(xù)跟他合作么？換位思考下，這個事情就是這么個簡單的道理。你答應(yīng)了客戶一些事情，雖然事情較小，但你若不兌現(xiàn)，就會很快失去客戶有限的耐心和信任。

??? 既然誠信如此重要，那我們要如何才能做到誠信？從這個事情中，我想能吸取如下教訓(xùn)：

??? 慎重承諾：一個事情如果做不到，就不要答應(yīng)，寧肯拒絕；答應(yīng)了卻做不到，兌不了現(xiàn)，這比你不答應(yīng)或少承諾一些，傷害力要大得多；
??? 如果答應(yīng)了，就要想盡辦法去兌現(xiàn)，盡自己最大的努力；
??? 如果盡了最大的努力，依然是無法做到，此時至少應(yīng)該及時反饋，第一時間告訴對方；并主動向?qū)Ψ奖磉_你的歉意，解釋你無法做到的原因；這樣能來得及再想其它辦法，也更能獲得諒解；

??? 總之，千萬不要像我們前面例子中這個團隊那樣，答應(yīng)了做不到的事情，并且沒做到時也沒有主動反饋和解釋，這樣是很糟糕的處理。中國古人講修齊治平，說明做項目跟做人，道理都是相通的。一個公司因為一次不誠信行為，會損失一個項目或一個客戶，如果這樣的行為在公司里面擴散開來呢？或者長期積累起來呢？一個人因為一次不誠信行為，會損失一個機會或一個朋友，如果這樣的行為在他周圍擴散開來呢？或者在他身上持續(xù)累積起來呢？所以誠信無小事，要從自我做起，要從點滴做起。

諾懷博客標簽:

從某軟件開發(fā)項目一期工作中學(xué)到的經(jīng)驗

Caven — Fri, 21 Mar 2014 03:45:58 +0000

1. 明確范圍

如果說要把整個項目（假設(shè)持續(xù)2個月，分為4次迭代）的范圍，在一開始就明確下來，對我們、對客戶都很困難，因而這個期望不太現(xiàn)實；更可行的辦法是把范圍的明確，也拆分成更小的單位，譬如按照每個迭代（每兩周）來明確；我們雙方只要保證，對這兩周要提交的內(nèi)容，有明確的共同認識即可；然后不斷循環(huán)；
明確下來的范圍，要有個Task List或者Plan來作為以后判斷是否發(fā)生范圍改變的依據(jù)；

2. 范圍變更

如上所述，如果每兩周一個迭代，每次迭代都有明確的Task List或Plan；那么在這個過程中，任何不在這個List和Plan中的任務(wù)，都可以視為需求變更、范圍變化；
這種變更，需要在客戶剛提出來時，就進行評估，明確告訴客戶這個改變所需要的額外時間，必要時，要協(xié)商延后當(dāng)前版本的提交日期Timeline；
同時，在平時要注意把這類小變更記錄起來，免得以后說不清楚哪些是變更，哪些是初始的要求；

3. 提交版本

如果跟客戶約定在每個迭代結(jié)束時提交版本，那就相當(dāng)于每次提交都跟客戶商量了一個明確的提交日期；這樣就不會太被動；當(dāng)然如果客戶覺得這個頻率有問題，也可以改為每周提交一次或者每周兩次提交；無論是哪種情況，都可以事先商量好，做好對應(yīng)的計劃和時間安排；這樣就可以避免倉促提交的現(xiàn)象；
提交版本之前，內(nèi)部一定要留些時間，譬如1天2天做為內(nèi)部測試和修改Bug的時間；必須內(nèi)部通過了才提交給客戶；這個是最基本的質(zhì)量保證流程；

4. 質(zhì)量

開發(fā)人員自測是最基礎(chǔ)的；如果測試人員得到的版本是不可測的，一看就有很多明顯的Bug；通常會要求測試人員直接打回給開發(fā)人員重測；只有過了自己這一關(guān)，下一個環(huán)節(jié)的工作才有意義；
如果開發(fā)人員的自測實在不知道如何才能改進，那么可以讓測試人員跟其結(jié)對，一起測試；這樣就能學(xué)到一些測試人員的測試方法和技術(shù)；幫助開發(fā)人員提高自測水平，在后期也可以節(jié)省整個團隊的時間；
對于經(jīng)常出現(xiàn)的Bug，開發(fā)人員一定要進行分析總結(jié)，看看哪類Bug是自己最常犯的錯誤，得到經(jīng)驗以后采取措施避免；

諾懷博客標簽: