如何將設計思維應用到精益初創公司的軟件開發
- 2020 年 2 月 7 日
- 筆記
本文系譯文：關於將設計思維與敏捷開發相結合的嘗試 —— 成功與失敗剖析"
- 作者：BrianNeisler
- 譯者：Aceyclee
我們所說的設計思維，是指由 IDEO 公司的 Tim Brown 提出，並且正在改變全世界組織的設計思維，簡稱 DT。（譯者註：IDDO，當代最具影響力的設計公司之一）
該理念承諾帶來更高的生產效率和創新，促進與用戶建立更好的聯繫。
聽起來很不錯，對吧？所以我們親自嘗試了一下。
在這個過程中，我們取得了一些進展，也經歷了一些挫折，還遇到了一些其他事情。
如果您正在考慮採用設計思維，或者只是大體上考慮您的產品流程，不妨繼續閱讀本文，了解下我們的嘗試。
設計思維在科技公司中是什麼樣的？
簡而言之，設計思維流程針對的並非如何執行，而是如何在一開始決定應該構建什麼內容。
它以一個緊密的用戶驅動型反饋環路為中心。理論上，這個閉環可使您在開始寫產品代碼前儘可能迅速地驗證新的功能想法：
對於我們這樣的科技公司，設計思維意味着：
- 共鳴：產品團隊理解用戶的反饋。
- 定義：產品團隊將反饋納入問題池中。
- 設想：產品團隊和工程團隊集思廣益，共同提出關於如何解決問題的想法。
- 原型：產品和研發團隊採納最佳想法並共同構建出一個或多個原型。我們不會保留這些代碼，它們僅用於驗證。
- 測試：將解決辦法提供給用戶，看看是否解決了用戶的問題。
- 實施：如果解決了問題，由研發團隊構建相應的實際產品。
其結果是新功能首先在小範圍的產品中提供，然後由用戶驗證，最後才進行實際的開發工作。
這個過程中還有一個關鍵點：公司的所有部門之間會一直溝通。銷售部門不會在幾次交談後就告訴工程部門應該構建什麼產品，產品部門也不會告訴銷售部門直接賣我們想做的產品。
每個部門都會和用戶溝通，然後共同提出產品戰略。
過程：我們如何將設計思維和敏捷開發結合？
敏捷的好處在於您可以將項目細化，以便確定更合理的優先級。設計思維可同時在微觀和宏觀層面上支持實現敏捷。
微觀層面上，設計思維可用於驗證各項功能。它符合敏捷框架，可幫助我們在迭代計劃時始終專註於優先級最高的項目。
宏觀層面上，設計思維使一切工作回歸於公司的願景，提醒我們不斷重新評估當前工作，以長期為我們的用戶提供更好的服務。
設計思維似乎天生適合我們公司。
具體細節：我們完整的內部過程
現在介紹我們在 Serverless 公司內部是如何開展設計思維這六個步驟的。
共鳴：
我們在 Confluence (Atlassian) 上設置了一個產品類別板，公司的任何人員均可提交用戶問題。這些問題來源於任何真正可以發現實際用戶問題的地方，包括直接的用戶訪談、文章、論壇話題、漏洞報告和個人經歷等。
設想：
任何人員還可以提交如何解決已確定用戶問題的想法。我們的提交指南明確規定了所有解決方案均應從用戶的角度進行闡述。有什麼作用？要執行什麼操作？期望產生什麼結果？
定義：
產品團隊每周審查類別版塊，對需要進一步驗證或需要進一步發現的內容加以標註。
在審查的基礎上，我們會對每個項目分配以下一個優先級：
- 產品待辦事項列表（高優先級）
- Icebox（低優先級）
- 否決（直接拒絕）
原型：
產品團隊查看待辦事項列表，並共同擬定我們接下來要關注的原型。工程團隊接收原型，並將它們納入敏捷規劃管道。
測試：
如果一切符合要求，並且該想法可以很好地解決實際的用戶問題，我們會將其轉換成提案，納入到中期路線圖中。
實施：
這些提案闡述了我們接下來 3-6 個月之內要在生產環境中實際構建的最佳構想產品。此外，我們還會進一步圍繞每個提案定義 KPI，以便可以不斷地衡量所取得的成功。
目前有什麼作用？
設計思維目前的確給我們帶來了不少積極影響：相比於我們想一次性執行的大項目，我們的工作更專註於組成整體的細小部分；通過論壇、Slack 或者訪談，我們能與用戶不斷溝通，有助於我們保持坦誠相待；我們充分利用設計思維來確保一組經過驗證的功能得到實施。
儘管一些舊習慣仍然在無形之中影響着我們，到這我們目前的執行還不是很完美，但我們比較樂觀，也取得了一些進展。
不過，我們也發現了一些不足之處，至少對我們的團隊來說確實如此：
- 我們的公司規模並不大，而且設計思維雖然強調緊湊的迭代循環，但坦白而言，其本身是高度結構化且非常耗時的。其結構化程度過高，致使其不太適合我們這樣的小型初創公司。設計思維起源於諮詢領域，有時候這一點會體現得很明顯。
- 查看完提交的所有想法需要較長的時間。這意味着，提交想法的人沒有覺得他們在積極地貢獻，而是這個過程中存在很多的繁瑣程序。此外，任何優秀的產品團隊最後往往會拒絕收到的 90% 的想法，而得知提供的想法十之八九會被否決對提出想法的人來說是一件沮喪的事情。
- 我們的團隊大部分都是遠程辦公，分散在 18 個時區。由於時區協調性，並不是所有人都可同時參與會議，因此很難保持緊湊的結構化反饋環路。
此外，您可能時不時會看到 設計思維會抹殺創意 這樣的觀點，導致您不由地懷疑所作的努力。這時，您需要自行決定是否放棄。?
替代方案？
如此看來，設計思維並非十全十美。但老實說，我們也很難想像出其他替代辦法。
我們可以基本上捨棄流程，而是每月將所有人集中到辦公室，讓他們發表各自的看法。或者我們可以走另一個方向：始終讓一個開發組長決定所有開發人員應該做什麼，但如果這樣做，對產品流程提供想法和意見的人將少之又少。
我們或許可以採取 Google 的方法，讓團隊中每個成員各自分配出 10% 的時間來做用戶調查和調整新的想法（事實上，這主意聽起來還不錯）。
這又歸結到一個經典問題 —— 任何體系都存在缺點。但至少，我們已經有一個可用的體系。
總結
我們可能會繼續採用設計思維，也會在此基礎上做些試驗和調整。
您對此有什麼看法？您覺得怎樣改善設計思維會讓其更加適合初創公司？我們很期待了解別人是如何運用設計思維的！
傳送門：GitHub: github.com/serverless 官網：serverless.com
