以終為始:如何讓你的開發符合預期

張飛洪[廈門] 發表於 2021-10-19

本文共2103字,預期10分鐘閱讀完成,我是張飛洪,感謝您的閱讀。

01 尷尬的交付

不知道你是否遇到過交付不被認可的尷尬。工作這麼多年,不管是向上彙報,還是任務下發,你會發現扯皮總是無處不在。

老闆可能會告訴你我要做數字化,然後巴拉巴拉一堆需求:

1、類似ERP風格:包括業務模式,風格,型別(流程,表單,許可權,組織架構等…)。

2、資料需求:無處不來,無處不去,有過往必留痕(必須進行儲存),無處不支援,資料必須獨立存在,要成為核心驅動能力。

3、整合需求:對別人的整合,充分開放、整合便捷、資料全面;整合別人,相容性好、多樣、高效、方便。

你胸有成竹,因為你都做過這些事情,ERP風格見多了,資料需求不就是資料庫設計和儲存嗎?整合需求就是WebAPI介面。

等你吭哧吭哧幹了半年,老闆看了說這是什麼破玩意兒?我要的不是資訊化系統,是數字化系統,怎麼沒有大資料的影子?

確認後才知道,原來老闆要的是數字化的智慧系統,所謂的資料“無處不來,無處不去,有過往必留痕”在老闆的認知世界裡就是大資料,資料倉儲的東西。

以終為始:如何讓你的開發符合預期
雖然這是一個簡單的案例,但反映的卻是我們日常面對的真實工作場景:許多人都是剛剛聽到別人要求做的一個功能,就開始腦補接下來的一切。導致的結果,就是付出的努力毫無意義。那麼問題出在哪呢?因為我們欠缺了“以終為始”的思維習慣。

02 倒過來想

所謂的以終為始,就是倒過來想問題,把時鐘撥到里程碑的終點,並問自己三個問題

  • 最後我們交付的東西到底長什麼樣?

  • 我們的客戶會如何驗收我們?

  • 驗收能通過嗎?

如果結果是不可驗收的,那麼不論我們如何努力都可能變成白費。因為雙方的認知沒有共頻,或者是一個假共頻。

回到老闆對資料提出的需求:“無處不來,無處不去,有過往必留痕”。顯然這種需求是抽象和不可量化的。我們可以進一步向上求證:

  • 這個東西有沒有類似的系統;

  • 是要做資料庫還是資料倉儲;

  • 最終目的是想達成什麼?

當我們倒過來想的時候,我們不自覺地會有種追問,因為我們是要交付產品的,模糊的需求最後會導致雙輸的局面。

以終為始,說起來很簡單,但做到並不容易。因為我們習以為常的思維模式是順序的,第一步做完,做第二步;第二步做完,做第三步。這也情有可原,我們人類都是從遠古時代演化而來,在那個食不果腹的時代裡,倒著思考的用途並不大,人們甚至不確定自己能否見到明天的太陽。

幾十萬年的進化留給我們很多短視的行為和思考習慣,因為這樣的做法最為節省能量,把目光放長遠是需要額外消耗能量的。

以終為始:如何讓你的開發符合預期

03 量化

當我們明確了最終的交付物,我們才剛剛邁出長征的第一步。假如我們要設計一個系統架構,業務需求到位了,我們準備開始規劃我們的架構需求。於是你很快就羅列了成熟架構需要的素質:

以終為始:如何讓你的開發符合預期

我們先看第一個高可用設計,幾乎沒有系統不希望是高可用的,對使用者來說高可用當然是永不當機最好了。但是成本和投入太高,無法承擔。於是如何定義高可用就是一個大問題。

我們看下如何用數字來設計度量指標

以終為始:如何讓你的開發符合預期

我們應該根據什麼來選擇到底要幾個9呢?

  • 首先,我們要問業務能否滿足?

  • 其次,我們要問時間能否滿足?

  • 最後,我們要問人力能否滿足?

這是一個權衡和妥協的過程,當業務剛剛起步,資源不足的時候,我們可能會折中,選了三個9,當系統接入支付系統,我們會選擇五個9。

以上就是一個量化的過程,另外效能也是可以量化的,這裡不再舉例。人類之間是存在認知牆的,不量化不開工。

04 文件化

需求量化後可能散落在釘釘、微信等聊天記錄裡面,而且各自整理記錄後,表述各不相同,這也是一個極大的風險。

從規劃的角度看,如何把集體的共識無偏差地落實下來,文件化是唯一的依據。另外,文件的選擇也很重要,如何確保文件是唯一的,現在有很多的雲文件,比如飛書、釘釘、石墨、Office365等等都很不錯。

不同種類都有自己的規範:

以終為始:如何讓你的開發符合預期

專案管理文件規範

該文件包含了專案管理的整個生命週期,形成了一個閉環。對於經常寫文件的人來說,當你在動筆之前,不妨問問自己或者和團隊討論一下:

  • 文件的大綱應該是什麼樣的?

  • 大家是不是使用同一種協作文件?

05 業內實踐

事實上,在今天的軟體開發實踐中,已經有很多采用了“以終為始”原則的實踐。

比如測試驅動開發。測試是什麼?就是你這段程式碼的“終”,只有通過測試了,我們才有資格說程式碼完成了。當然,測試驅動開發想要做好,並不是簡單地寫寫測試。

再如持續整合,我們是要交付一個可執行的軟體,倒著來想,最好的做法就是讓軟體一直處於可執行的狀態,那就是持續地做整合。

有段時間,網上流傳亞馬遜 CTO 介紹亞馬遜是如何開發產品的:簡單來說,他們採用向後工作的方法,開發一項產品的順序為:

  • 寫新聞稿;

  • 寫 FAQ(常見問題解答);

  • 寫使用者文件;

  • 寫程式碼。

當你瞭解完“以終為始”的思維模式,再回過頭再來看這種做法,相信你就能理解為什麼亞馬遜要這麼做事情了。

06 總結

今天,我帶你瞭解了為什麼會出現尷尬的產品交付,我們是如何通過以終為始,倒過來想問題的方法來解決交付目標,同時我也講解了量化、文件化和行業的最佳實踐來輔助理解,希望我的講解能幫助到你,如果今天的內容你只能記住一句話,這句話是:凡事發生,逆向思考

最後,我想請問下你,在平時的工作或生活中,你是如何解決交付的尷尬的?歡迎在留言區寫下你的想法。

感謝閱讀,我是張飛洪,如果你覺得這篇文章對你有幫助的話,也歡迎把它分享給你的朋友