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

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

01 尷尬的交付

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

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

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

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

3、集成需求:對別人的集成,充分開放、集成便捷、數據全面;集成別人,兼容性好、多樣、高效、方便。

你胸有成竹,因爲你都做過這些事情,ERP風格見多了,數據需求不就是數據庫設計和存儲嗎?集成需求就是WebAPI接口。

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

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

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

02 倒過來想

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

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

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

  • 驗收能通過嗎?

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

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

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

  • 是要做數據庫還是數據倉庫;

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

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

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

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

03 量化

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

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

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

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

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

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

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

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

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

04 文檔化

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

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

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

項目管理文檔規範

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

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

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

05 業內實踐

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

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

再如持續集成,我們是要交付一個可運行的軟件,倒着來想,最好的做法就是讓軟件一直處於可運行的狀態,那就是持續地做集成。

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

  • 寫新聞稿;

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

  • 寫用戶文檔;

  • 寫代碼。

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

06 總結

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

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

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章