海王捕鱼|街机海王捕鱼免费安装

返回首頁  設為首頁            資源已找到,加載中...... 請稍等!         網站地圖 | 娛樂網  | 科技吧  | google地圖  

網站首頁網絡學院站長工具網絡紅人酷站推薦左右博客網站工具虛擬世界網絡資訊熱門事件
文章 圖片
高級搜索
軟件需求變更怎樣才能合理控制
軟件需求變更怎樣才能合理控制
點擊數:158 更新時間:2016-6-5 14:59:52 | 【字體:

  上圖是一副非常有名的畫作,名為『從主教花園望見的索爾茲伯里大教堂』,作者康斯太勃爾,英國的著名油畫家。某年某月的某一天,康斯太勃爾去他的金主大教堂的主教Fisher先生(后面簡稱大魚)家里玩。大魚主教跟畫家先生說:“親愛的畫家,你幫我畫一幅畫吧。把我和我美麗的妻子以及我這大教堂一起畫到畫里。我要把畫留在教堂,成為鎮堂之寶。當然,我是給錢的,于是康斯太勃爾先生很高興的接下這個項目。
  畫家開始了辛苦的工作,經過一段時間終于把這幅畫完成了。畫家畫這幅畫時可能心情不好,所以在教堂塔尖上方的天空有一片烏云。大魚主教看到這幅畫后,很不滿意。雖然畫家把主教大人、主教夫人和教堂都畫進去了,但是兩口子只在左下角露了個背影,這也就忍了。“下面那幾頭牛是怎么回事,為什么比我們占的鏡頭還多?”主教問。畫家說:“你沒看懂?我是在恭維您呢,是說您和您夫人好牛!”,大魚先生沒什么話說了,然后又找到了新的吐槽點:“為什么天空的云都是烏云?”。他邀請畫家再去他家做客,重新觀察,以便于修改畫作。畫家很不高興了,就單獨把畫展出了。展出之后得到很多好評,于是回信給大魚主教:“你看,大家都說很好看,不用改了。”,大魚主教收到信后也怒了,回信就說了一句話:“給我改!!!”。
  從回復文字的三個嘆號上可以看出——主教很生氣、后果很嚴重。這就是關于需求的故事,請您再看上圖,看看教主和教主夫人被畫到了哪里?您能找到嗎?
  從上面案例中您看到了哪些與需求相關的問題?為什么導致客戶不滿意并被要求重畫?
  1、需求表達不到位。大魚教主想要一幅畫,畫里有他們夫妻二人和教堂,需求表達完后,并沒有再對需求進行更具體的說明。除了以上要求外,畫作里是否還可以加些其它元素?人物要求畫正面還是背面?畫作的背景是什么?需要表達什么樣的情感?
  2、沒有與客戶認真溝通需求。當主教讓畫家畫一幅畫時,最初只是一個想法,并沒有太具體的要求。細節需要畫家一點點的引導,從而勾勒出畫作的輪廓,這個輪廓就相當于產品的原型。與客戶溝通好需求并得到客戶認可后再開始畫作,需求變更的可能性就會大大的降低。
  3、需求理解不正確。畫家在畫作里多畫了一些牛,并認為這樣會更好,寓意深刻,可以表達出大魚主教和夫人“很牛”的意思,還根據自己情緒需要將天空畫得“烏云密布”。這說明畫家沒有正確理解客戶意圖,把需求想當然化了。我們應該合理控制需求,合理規劃需求,不能隨意的增加或刪減需求,這都是不正確的。需求的管理也不應該是一人堂,要有需求評審等需求審核流程,讓相關人一同參與、共同把握需求。
  4、沒及時讓客戶參與。在畫家進行創作的這段時間里,畫家并沒有邀請大魚教主來看畫作,這也就錯過了最后彌補的機會。當整個作品完成后,客戶才有機會看到作品,得不到客戶認可的產品再努力也是徒勞。
  5、不愿聽取意見。當客戶明確提出自己的意見后,畫家還是一意孤行,將作品拿出來展覽,這對客戶來說是種傷害。即表現出對客戶的不尊重,又表現出了自己的自大。這就相當于還沒得到客戶、相關領導認可時,私自發布產品,它所產生的后果可能是無法想像的。所以,難怪主教生氣。
  從上面故事可以看出,項目的成敗與需求關聯非常密切。如果想要做好一款產品,從需求調研、需求分析、文檔梳理、需求評審每一步都要走的堅實,不可以走過場。一點的疏忽都可能導致產品的失敗,需求變更,也就再所難免。有的需求變更是無法避免的,如客戶、領導在產品開發階段要求增減需求;有的需求變更是可以避免的,如需求調研的不夠充分、分析的不到位、評審的不夠嚴格。只要我們更虛心一點、更認真一點,需求管理流程更規范一點,許多變更都是可以避免的。
  針對需求變更要早發現、早預防
  需求變更避免不了,既然不能避免,那我們就要敢于直面慘淡的人生。引入需求變更管理機制,以降低需求變更帶來的風險。需求變更管理的核心是減少變更所產生的影響,而非消滅變更。通過變更管理可以降低開發返工、重工的工作量,以減少項目風險。需求變更屬于需求管理范圍,同時也屬于風險控制范圍,對于產品經理要隨時關注產品,定期對需求進行跟蹤,做到“早發現、早治療”,以防病入膏肓后才下手。那樣,可能癌細胞已經擴散了。對已變更的需求要做到文檔標記更新,編寫需求變更說明,保證需求與開發工作一致,不要出現“兩層皮”的現象。從技術角度考慮,技術架構要做到可擴展,以彈性的架構來解決變更的需求,把變更造成的影響降到最低。
  需求變更流程
  當發生變更時,正規的流程需要走變更申請,申請后組織人員對變更進行分析、評審,以判斷變更是否必要,對項目的影響有多大。又必要又緊急的需求要排到開發計劃中,盡快安排開發;對必要不緊急的需求要考慮是否可以放到下一版本安排開發;對緊急不必要的需求,要根據項目實際情況考慮,是否可以不要?對不緊急也不必要的需求應該直接砍掉,無須變更。評審完成后,對于需要安排開發的變更需求,先整理變更需求說明書,以幫助開發人員、測試人員了解變更內容,指導技術人員開發。
  如何分析需求變更的合理性?從哪些方面著手?
  1、從業務方面分析。需求變更基本都是因業務變化而產生的,當發生變更時,我們也要從業務角度多思考,變更的是否合理,是否必要,與產品定位是否相符,能給產品帶來哪些好處?如果不做變更是否可以?
  2、從技術方面分析。變更會對開發有多大影響,需求變更的部分是否已經開發?開發到什么程度?工作量多少?是否可以通過技術框架的擴容性很好的解決變更?
  3、從項目方面分析。從項目角度考慮,變更會使項目的時間、資源、費用上產生多大影響?影響是否能夠承受?本次變更的需求必須本版本開發完,還是可以放到下一版本迭代開發?
  從以上三方面分析清楚后,變更的需求脈絡也就理清了,變與不變、現在變還是以后變也能分析得透徹。
  總結:
  需求變更對每一位產品人來說都會經常遇到,產生變更的原因很多,有外在的、有內在的,但不論是因為什么產生的變更,遇到了就要正確的、合理的分析、評估,給項目以正確的指導。如果項目前期進行了大量的調研、跟蹤、分析、評審,并請客戶盡早參與,許多變更是可以避免的。如果,技術框架設計的可擴展,程序設計的可擴容的話,當發生變更時也可以把變更對項目產生的影響控制到最小。防微杜漸、未雨綢繆,還是那句話:“早發現、早治療”。最后,以“扁鵲見蔡桓公”的故事結尾。
  扁鵲進見蔡桓公,(在蔡桓公面前)站了一會兒,扁鵲說:“您在肌膚紋理間有些小病,不醫治恐怕會加重。”蔡桓公說:“我沒有病。”扁鵲離開后,蔡桓公說:“醫生喜歡 / 習慣給沒病的人治病來當作自己醫術的功效。” 過了十天,扁鵲再次進見蔡桓公,說:“您的病在肌肉里,不及時醫治將會更加嚴重。”蔡桓公不理睬。扁鵲離開后,蔡桓公又不高興。
  過了十天,扁鵲再一次進見蔡桓公,說:“您的病在腸胃里了,不及時治療將要更加嚴重。”蔡桓公又沒有理睬。扁鵲離開后,蔡桓公又不高興。
  過了十天,扁鵲(遠遠地)看見桓侯,掉頭就跑。蔡桓公于是/特意派人問他。扁鵲說:“小病在皮膚紋理(之間),湯熨(的力量)所能達到的;病在肌肉和皮膚里面,用針灸可以治好;病在腸胃里,用火劑湯可以治好;病在骨髓里,那是司命神管轄的事情了,(醫生)是沒有辦法(醫治)的。現在(病)在骨髓(里面),我因此不再請求(為他治病)了。”
  過了五天,蔡桓公身體疼痛,派人尋找扁鵲,(扁鵲)已經逃到秦國了。蔡桓公于是病死了 

文章錄入:admin    責任編輯:admin 
  • 上一篇文章:

  • 下一篇文章:
  • 【字體:
     網友評論:(只顯示最新10條。評論內容只代表網友觀點,與本站立場無關!)
     

    相關文章
    沒有相關文章
    最新推薦最新熱門
    專題欄目
       
    站長吧
    海王捕鱼 湖南快乐十分遗漏统计 云南快乐十分走势100 oK2929香港正牌30码开奖结果 精准三中三不改料论坛 贵州快三形态一定牛 快乐12胆拖对照表图片 安徽快三开奖视频结果 北京快3中奖助手 青海西宁快三正规吗 河南快3开奖号码今天