正題：
使用者有新的需求 -> 新的需求需要新的功能才能支援 -> 我們要提昇使用者滿意度 ->加入新功能。
反題：
使用者喜好易懂的文件與好上手的功能 -> 功能越多使用者就越難用也越難學 -> 我們要提昇使用者滿意度 -> 停止加入新功能。
最近開始思考，做Framework Function越做越多，Complexity 與Learning curve就會越加重，我們或許滿足了某些開發者在一些面相上的需求，但卻要增加複雜度與知識門檻而讓其他的開發者痛苦。
我知道有幾個方法可以減緩這個矛盾問題尖銳的程度：
1. 花大量的時間人力，透過review文件、寫文件，去整理產品規格。
2. 開發產品的自動化測試方法。
3. 成立專責的QA團隊，強化QA流程。
而我也很清楚這些東西長期而言是無法躲避的問題，一定要去解決。
但我常在想，有沒有可能存在其他方案能夠在不傷害成長動能的情況下，緩衝這個問題對公司的創新動能造成的衝擊？
還是說有誰應該要走過來朝我的後腦杓巴下去，然後說：『別做夢了，醒醒點，該是效法那些 Russian 起床拿Vodaka 漱口，然後去-20C的戶外工作的時候了』
如果能讓我用 GWT 來當例子的話（當然，它很可能不能稱作一個 framework），我覺得這兩個命題應該是不矛盾的。
回覆刪除2.0 加入了 Cell Widget，功能真 xx 強大。退伍後曾經花兩天試圖鑽一下 source code 了解裡頭在幹麼，結果那兩天除了 WTF/min 產能爆增加之外，好像沒啥成果。反而是當 newbie 一樣按照文件用，啥問題都沒有...（雖然總有一天會爆炸的）
好玩的地方在於，GWT 壓根沒打算要你用 Cell Widget，你可以完全不知道有這玩意，但是照樣能把（簡單的）application 寫的不錯，最多就是寫起來囉唆一點、browser 執行起來慢一點......
雖然我不知道（不覺得）這能套用在 framework 等級的東西上，只是這樣的方向與結果應該是可以解決這個矛盾。雖然說那只是讓設計時的困難度加深更多......
當然，每個人都希望 tool, framework 使用能有多簡單就有多簡單、功能有多強大就有多強大（糟糕，又要接周星馳電影梗了）...
有功能就要有文件，有選項就需要做選擇。
回覆刪除而選擇要敢做下去，就要先瞭解選項的背後到底是什麼。
我是覺得這東西沒有躲掉問題。
或許加這種功能不會增加或只加一點點Framework的Complexity，但是學習心裡上的負擔是不會不見的。
當然我也想放大絕：不懂不要用、不爽不要用。
但東西畢竟不是自己做爽是要做對User有價值的，所以只好繼續在這種兩難上打轉了。
最好有一種超棒Feature可以加進去然後對User有價值十倍，卻又沒有增加外部API與Document...做夢。
可能要考慮closed loop design了 - 讓你的使用者非常熟悉某一種限定規格的使用方式 之後再加入其他的使用風格之後再讓他們選擇, 至少這樣做不會讓你與你的使用者的選擇oscillate about the norm of freedom. 打個比喻說 你有三塊樂高積木, 無論如何堆疊都是一樣高, 但是最能讓人理解的方式是將面積最大的放在下面, 因為那是人類現實生活中比較不抽象的思考方式, 同時也是能避免使用者在設計時存有疑慮的方式. 或許你可以讓你的使用者先看見選擇A道路的設計方式會有什麼後果與優勢, B道路與C道路各有何不同 依照使用者個案的需求, 你可以保證的結局都在你的掌握之中. 這樣應該會比較明瞭.
回覆刪除這確實是組織Document或者說Knowledge path的好策略。
回覆刪除不過我想知道的是存不存在一種開發目標能夠透過開發能量提昇目前客戶的滿意度，但不用去寫『給User看的Document』、且相較於framework加新功能，這個開發目標不用去擔心『complexity 累加造成的環境相容性與向後相容性』的問題。
就像iPad、iPhone出出來沒什麼Doc，我妹還是可以玩的很快樂一樣，一代出一代她有錢就買下一隻把上一隻賣掉，然後她對Apple的忠誠度就越來越高...
開發Framework產品最大的痛苦就是，User寫的程式與產品一定是Coupling，不論一開始產品API規劃的多好，時間過去客戶越多，你能加能改而不會踩到哪位客戶腳趾的空間就越小、而Document越多越雜、QA的成本則會指數上升...
當然一個軟體系統總有一天要面對熱寂的，但如果能撐到產品所生存的環境市場開始日落西下的時候也夠本了。
簡單的說，因為團隊善長的是開發，別的能力目前都還在逐漸培養中，所以我在想一個能透過開發新功能來持續提昇使用者滿意度卻又減緩軟體產品本身老化速度的抗老化配方拉。
所以才叫二律背反...一整個矛盾啊。