2017.4.16, 深圳, Ken Fang
客觀的說, 互聯網企業的特點是：許多的產品 （不是所有的產品）在研發的時候, 並沒有特定的客戶、使用者。更不用說分析需求了。
互聯網企業的許多產品, 在研發剛開始的時候，往往是隻能根據過往類似的產品經驗、過往市場的經驗, 去制定產品初期的方向。然後，快速的迭代，快速的推出產品，快速的獲得市場反饋，快速的應變。
也就是說，在互聯網企業, 開發產品最大的挑戰是：
你必需在
1. 摸索
2. 堅持
3. 應變
三者都兼顧下, 去開發產品。
SAFe 的 PI 會使互聯網企業認爲不適合, 是因爲互聯網企業認爲（或者說是誤解）:
SAFe 的 PI 可使他們做到堅持，卻限制了他們能做到摸索與應變。
互聯網企業的管理很開放、自由的。所以，在互聯網企業, 鼓勵大家多多提供產品的特性, 是比較容易做得到的。
也就是說, 在互聯網企業, 較容易接受的產品開發的模式是:
1. 持續規劃
2. 持續架構
3. 迭代快速發佈 (價值流持續發佈)
SAFe 在實務上, 對於原先使用瀑布模式的產品開發團隊, 提供了ㄧ個較容易理解與接受的敏捷開發模式。
當然, 我們更期望產品開發團隊, 從瀑布模式到 SAFe，能再持續改善到：更能響應外部變化的 “持續規劃”、“持續架構”、“迭代快速發佈 （價值流持續發佈）”。
SAFe 提供了ㄧ個很好的實踐；PI Planing; 解決了ㄧ個因架構、需求依賴, 所造成的團隊間依賴的問題與挑戰。
但, PI Planing 能解決架構、需求的依賴, 所造成的團隊間依賴的問題與挑戰的前提是：
至少是要能在ㄧ個 PI 的週期以內, 架構、需求的依賴必需是要能維持不變的。
很遺憾的是:
互聯網企業的許多的產品, 架構、需求的依賴, 往往是在迭代內便會發生改變的。
所以, 我的說法是:
SAFe 解決了由 “靜態” 的架構、需求的依賴, 所造成的團隊間依賴的問題與挑戰。
而互聯網企業現在真正要解決的是：由 “動態” 的架構、需求的依賴, 所造成的團隊間依賴的問題與挑戰。
採用何種產品開發模式、版本發佈節奏? SAFe、Less、Scrum、CMMi、 迭代、瀑布、PI、 價值流持續交付。
應該只取決於：
1. 產品的特質
2. 人員的背景與素質
3. 自動化環景的成熟度。
我們應該是從這三個面向中，爲團隊 “設計”出適合團隊的產品開發模式。
但，真正的重點是:
這設計出的產品開發模式，只是ㄧ個 “起點”。
團隊應該要在這起點上，持續的優化出更高效的產品開發模式。