數位行銷
程式設計開發
脈絡驅動設計(context-driven design)簡介：
需求設計：
在當今的IT應用程式開發裡，蒐集需求的發法分為兩派，如下圖所示：
但不論用哪一種方法採集需求，如果有以下紅色警示的狀況，都會導致專案步入危機
企業管理者會針對所有問題提供明確的答案
剛開始很多管理者還未思考到細節的問題，其中有些人會含糊其辭給予模糊的答案，試圖將問題掩飾掉，並且管理者並非了解細節的人
->導致專案延遲及成本增加
所有利害關係人都會給一致的答案
經理與經理意見不同、經理不認同作業員的意見、公司總部不認同分支或部門經理的意見，不同的管理者會有不同的看法
->導致專案延遲及成本增加
所有的利害關係人都能被找到
只有一個人或少數幾個人真正在提供問題的回覆，而事實上這些問題需要有廣大的視野才能回答
->確認偏誤（confirmation bias）！導致專案延遲及成本增加
企業主管們會閱讀並理解需求規格，給予明智且思慮周到的回饋意見
確認偏誤！管理者會假設該應用程式會支援他們想要的功能，但事實上卻沒有這個功能，誤解了該應用程式的運作方式
->確認偏誤（confirmation bias）！導致專案延遲及成本增加
需求團隊給出很好的應用程式評估，資深管理者充分了解，並且做出正確取捨之後的抉擇
在小型的專案中很容易進行而且開發成功，但是當計畫日益擴大，與其它系統整合日趨重要，這個狀況會不太可能成立
->大型專案延遲及成本增加
解決方案：一套IT應用程式的需求是設計過程的產物-脈絡驅動設計
設計企業解決方案：
明確性：不仰賴別人提供需求，而是靠IT部門條理分明的將解決方案精確地描繪出來，讓人理解
無歧見：讓人們把自己定位為解決方案的評論者，把反對意見都攤在陽光底下，問題容易被解決
沒有未知或被忽略的利害關係人：強調回饋與開放，將報告傳送電子檔給所有人，便可以輕易的將他們牽涉進專案中
清楚的回饋意見：讓利害關係人輕易而精確地描述解決方案的錯誤，依此說明解決方案的正確樣子
成本估計與利弊取捨可被包含在設計過程當中：無法只靠營運設計給出成本的估計值，在擬定精確的成本估計之前，須更進一步的設計技術上的解決方案
企業管理者充分了解各種整合方式的選擇，能在這個領域上提出指導：整合的選項以設計的一部分呈現出來，不是以技術上的術語來說明
參考書目：寫給PM、RD與設計師看的設計需求分析
