網路城邦
上一篇 回創作列表 下一篇   字體:
從需求到設計讀書心得
2021/01/08 00:02:04瀏覽1894|回應0|推薦2

上次去選書來讀時,沒看到有興趣的新書,於是到處亂找,挑到了這本書。

仔細讀了之後,覺得這是意外的驚喜。

這本書值得讀一次以上,這是傻蛋的感想。

比較對象呢,可以和Peopleware和人月神話比較看看吧,都可以算是和資訊軟體專案管理有關的,只是面向各自不同。

這本書是談需求的,傻蛋工作經驗也算蠻多了,看過大量不能算成功的專案,基本上,都是從需求這一環就掛點了,然後,各種掙扎無濟於事。

技術能力好,沒用,管理方法再細緻,沒用,需求不對,商業模式與整個運作的走向就不對,後面越是用力,通常只會帶來更多的麻煩與壓力。

實際上,最難的是做好需求分析工作,後面的步驟,都是有所根據的,相對來說就是具體的,可以有方法可以套用,可以設法做好。

反而一開始的需求,常常,就是老闆的一時興起,沒有想得很清楚,於是就開啟一個專案那樣,很容易就草率的決定了需求,然後接著就各種不順了。

需求分析真的很重要,以前沒看過這本書,真的可以說是,運氣不好喔。

 

話雖如此,這本書的翻譯,傻蛋覺得卡卡的。

特別是requirement,需求,特別翻譯成需求要件,就是感覺不是很順。

用粗體來對這個需要強調的需求做加重應該比較合適吧,當然這是傻蛋自己的看法啦。

不過這本書如果不看翻譯版本,對英文不夠好的人來說應該壓力也蠻大的就是了。

這本書的風格是,稍微有點好笑的那種吧,不是那種特別正經的風格,這種書如果讀原文,那就累了。

傻蛋不滿意的就是需求要件,而這個需求要件整本書到處都是,所以就覺得差了點,其實已經算不錯了。

書裡面用來說明需求分析確認作業的幾個案例,都相當刻意與好笑,超級粉筆專案啊,電梯資訊系統啊,一種交通工具的設計,都很有特色,不會讓人打瞌睡。

能把觀念說得清楚,還讓整個風格活潑有趣,給原作者一個讚喔!

 

那來說說傻蛋從這本書的閱讀得到的一些心得吧。

 

語意曖昧是個很常見的問題,如果不把它當一回事,你的需求分析肯定一蹋糊塗。

如果你不想把需求搞清楚,那你很容易就會傾向於使用曖昧的語意。

然後,把真正困難的部分,用蟑螂必殺器那樣的概念,推給別人。

就是那個,咻,碰,蟑螂就被解決了,決定這件事的人,往往不是需要實現那個蟑螂必殺器的人,到底怎麼具體讓蟑螂被咻,碰的解決掉,是別人的事。

一個專案要成功,要能成立,如果關鍵難點是一個什麼的必殺器,然後提出專案的人不想去注意這些細節,只想找個好凹的人推過去,這樣的專案,大概率是要做死的吧。

關鍵問題需要被放大,需要被謹慎的分解,做腦力激盪,並充分的研究與討論,以找出確實可行的方案,這種情況下,是不允許曖昧的定義的。

 

好,這是傻蛋的吐嘈而已。

 

需求分析,重要的是讓眾人意見和致,大家能有共識,能朝相同的目標一起努力前進。

所以不要心存僥倖,總想要忽略糊弄最複雜困難的部分,而是要把問題攤開來看,務必讓大家都清楚關鍵的點是什麼,將如何實現。

這本說有很多那種,一步一步的檢查步驟,或許還稱不上必殺技,但也是相當的實用。

可以拿來設計SOP,用來當檢查表的草案或標準流程的參考框架。

每一個章節的心得與建議,大多很適合拿來當自我檢查表喔。

隨便抓個例子,進行需求分析作業時,常犯的錯誤是我們給客戶需要的東西,而不是客戶想要的東西。

我們是如此的自以為是,客戶當然不會喜歡我們的解決方案,是吧?

 

當然,這本書主題很多,傻蛋現在也很懶,全部寫完搞不好比這本書還厚。

就寫傻蛋對這本書核心觀念的解讀吧。

 

減少需求曖昧,讓需求變具體,可以增加可控性。

但,需求分析的終極目標,並不是把所有模糊都消滅乾淨,讓專案可以用可控制如預期的方式進行到底而已。

需求分析作業的目標還是要創造價值,是要找出更多可能性,找到有價值的想法與機會,這一點至少和有效率的確實完成任務一樣重要,甚至,更重要。

如果整個專案能創造的價值不高,就算管理得再精緻,最多也就那樣而已。

如果為了更細緻的管理而扼殺可能的機會,反而是捨本逐末。

避免語意曖昧與逃避現實的心存僥倖,並不意謂只要做好這些可以有技巧的步驟與檢查表的細節都做好,專案就會創造最大的價值。

不要扼殺創意與可能性,這一點,很重要,最好的解決方案,常常不適最專業,最聰明的,而是看到燈下黑,啊哈何不那樣做就好,那樣不受控制的跑出來的。

 

有些行為則是比較值得警惕的。

需求應該公開透明的討論,而不應以偷渡的方式加進去。

成功偷渡,偷偷的添加了自己想要,又不想被別人挑戰的想法,當下可能有種我贏了得感覺,但被發現的時候,得到的往往是憤怒喔!

重點是符合客戶的期望,而不是自己的期望,畢竟沒有買單的客戶會想被當成笨蛋。

 

分析功能時,可分為顯著,隱藏,附帶三種類型,透過分類法,設法找到更多隱藏功能。

對於功能裡暗示解決方案的字詞,要設法轉化為問句,找出更多隱藏功能,而不是陳述解決方案的形式。

充分討論分析功能之後,再把需盡力達成的功能整理出來。

 

功能之後是分析特性。

功能的特性。

可以分類為必須,客戶想要,與設計者認為可忽略的三類。

配合特性,對功能的掌握會更具體。

 

功能與特性都確定下來後,要來決定限制。

限制越多越明確,越容易得到具體可執行作法。

沒有限制,很可能會導致無法實現的專案。

不過限制固然有益,但,限制會讓解決方案的解空間變小。

過度的限制,可能整個解決方案就是無解。

安全可行與擴大可能的解空間需要抓到平衡,絕對安全的設計往往沒多大價值。

另外,限制反而可以帶來設計的自由,限制搭配標準化,反而會更靈活。

喔喔,那,限制到底是什麼?

那個蠢方法老闆或客戶絕對不會接受,這就是具體的限制啦。

 

對產品的功能,特性,限制都有充分的掌握後,接著要釐清的是偏好。

產品專案的價值,在於滿足客戶的期望的程度,所以,需要掌握偏好。

可以設法對偏好做設計,讓偏好可量化,以方面製作成圖表,好讓解決方案的好壞,可以不用全憑直覺感覺那樣武斷的決定,以輔助需求決策的品質。

 

最後就是整理出期望表了。

這一套作業程序下來,對於需求分析如何滿足客戶的期望這件事,就有了一個框架做法可以當基礎了。

而實際上,大多數的情況,需求的解讀都是靠感覺,靠不知道怎麼評價的小聰明吧,反正最後成王敗寇,贏家放的屁都是香的。

 

最後對需求做決策時,決策可以分為三種,選擇,假設與強迫。

選擇是根據有效的需求分析,是綜合各種情況下主動做出的對整體最有利的選擇。

假設則是資訊不足或因為作業錯誤,只能草率的不肯定的定義。

強迫則是不可抗力的限制,不是從有效分析決策方法而來,而是由法律或其他不可抗力的因素而需要被迫接受。

假設更需要寫下來,因為假設意謂風險,設計者要保護自己,對於假設就更需要得到書面確認。

正式書面紀錄非常重要,而且不只是具體需求內容,還要記錄當初被列為假設或限制的理由。

因為隨著時空環境的變化,以前的限制,或許已不再是限制,反而成為機會,若沒有清楚記錄下來,莫名所以的限制,往往會繼續發揮限制的作用。

正式的需求文件一定要有客戶簽名背書,畢竟口頭上的需求共識沒有意義,因為都只是說說的而已,事情有變時,大家都可以不認帳。

 

好啦,這本書確實是很有方法的,傻蛋只是很草率隨便的摘要一下而已。

很多精華部分是被忽略的,有興趣的讀者可以自行發掘吧。

光是回顧並整理的過程,傻蛋都覺得有一些收穫的說。

把大辣辣的想法具體轉化為可行的產品方案,這個設計的工作,第一步的需求分析是很重要的步驟。

如果不擅長這個步驟的技巧,那麼,在發揮創造力的工作上,我們將不具有競爭力,只能在變化很小的領域裡面,做些代工或專案研發之類工作,能分到的市場的餅,那會十分有限的喔!

( 不分類不分類 )
回應 推薦文章 列印 加入我的文摘
上一篇 回創作列表 下一篇

引用
引用網址:http://classic-blog.udn.com/article/trackback.jsp?uid=pondin&aid=155174283