Problem space and solution space (問題空間 與 解決方案空間)
Problem space solution space (問題空間 與 解決方案空間) 圖片來源：https://hbr.org/2013/09/when-youre-innovating-resist-l 印象中 ，好像在哪裡曾看過一篇文章，但印象不深刻，是說著 Problem space and solution space (問題空間 與 解決方案空間) 我的工作的時間非常長，長時間下來，其實一直專注在解決客戶問題，而最近幾年我發現一件事情就是，『一個問題通常不會只有一種解法、你永遠不會知道這個問題未來會不會有另一種解法？』 一直以來，我們常關注在客戶要解決的問題，而忽略了『問題』 與 『解決方案』是完全獨立的個體，是我們自己將這個解決方案 "強行" 掛在這個 "問題" 上頭，但這是對的嗎？對客戶來說，是解決了問題，但長遠來說，不一定。對企業經營來說，對其他公司來說，或對你自己的發展來說都不一定，因為個解決方案框住了這件事情的本質。 我後來有一個體認就是， 一個問題永遠不會只有一種解決方案，有時，『忘掉所有的解決方案，並回歸到問題的本質』，有時我們才能夠跳脫出原本的框架，重新的思考問題的本質 ，因為問題本身可能其實與技術完全無關， 【問題空間 與 解決方案空間】的關係這就像是我們在做系統分析時，【商業需求 與 技術】之間的關係一樣，兩者本來就不搭嘎 ，同樣的商業需求，你可以用各種技術去實現，完全不需要被 "技術" 而限制住了你的思考，這也是我最近學習 DDD 領域驅動設計後，又在這方面產生了更大的體認。 因為 DDD 的 Problem Domain 也是希望我們關注在這個商業需求的問題本質上，而不要被外在的不相關（工具 / Solution / Others..）等牽絆而影響到我們去理解這個問題的本質，其實 DDD 就是在教我們這個概念，而 Bounded Context 與 Context Map 也是在告訴我們不要將兩個不搭嘎的問題牽扯在一起，這也會影響你最後如何套上正確的 Solution。 這算是最近學習 DDD 領域驅動設計的一些些收穫吧！ 參考資料： https://www.packtpub.com/product/hands-on-domain-driven-d...