技術債帶給我的啟發:解決Delay的最佳解法是不設Deadline

栏目: IT资讯 · 发布时间: 7年前

内容简介:上一篇提到還技術債前應該要找到比自己利害的人,如果你對打掉重練後的系統期望不小那還不能只找一個人,而是需要一個團隊,我們公司有一半以上的人就是為了新系統而找進來的,對於小公司來說我本來以為這已是一個大挑戰了,但過了一年多後的現在回頭看,這根本只是剛開始而已。對公司來說,稀缺資源就是時間和錢,還技術債的時間拖愈久,機會成本愈大,付出去的薪水愈多,市場風險也愈大,挑戰就是如何運用有限的錢在最短的時間把期望中的新系統建置出來。( 嗯,你又怎麼知道新系統建置出來後業績就一定會成長?所以真正的挑戰是:如何運用有限的

技術債帶給我的啟發:解決Delay的最佳解法是不設Deadline

上一篇提到還技術債前應該要找到比自己利害的人,如果你對打掉重練後的系統期望不小那還不能只找一個人,而是需要一個團隊,我們公司有一半以上的人就是為了新系統而找進來的,對於小公司來說我本來以為這已是一個大挑戰了,但過了一年多後的現在回頭看,這根本只是剛開始而已。

對公司來說,稀缺資源就是時間和錢,還技術債的時間拖愈久,機會成本愈大,付出去的薪水愈多,市場風險也愈大,挑戰就是如何運用有限的錢在最短的時間把期望中的新系統建置出來。( 嗯,你又怎麼知道新系統建置出來後業績就一定會成長?所以真正的挑戰是:如何運用有限的錢在最短的時間把期望中的新系統建置出來,把舊系統汰換掉,讓業績大躍進。)

先說在前,還技術債的心理掙扎過程其實非常混亂,但為了文章方便閱讀,我還是透過條列式的方式分享給大家,但實務上沒有什麼先後順序。以下的掙扎及心得可能只適用於現階段的我及我公司,請大家小心服用。

關於舊系統的挑戰就是忍著

既然決定要打掉重練了,雖然舊系統就是讓它保持正常營運就好,但因為它又承擔養活全公司的責任,所以除了不在舊系統上更新功能外,其它該做的我們還是盡量把它做好。但也因為一直沒有功能上的更新,讓我們有些舊客戶的流失、業績的不成長、業務在外被打槍、重覆出現的問題仍需要靠人工處理 …. 這些我都知道、理解、接受,就忍著。

關於新系統的挑戰就是面對 Delay

從游擊隊改為正規軍

公司從 0 到 1 的階段人數不多,都是打游擊戰,每個人都能獨立作業,決策快、行動快。但當公司階段到 1 了後,人數變多了,大家的動作不協調了、資訊有落差了、看法不一致了、衝突出現了,簡單說就是需要溝通的廣度、深度、困難度都加大了,溝通及決策的時間就拉長了,為了解這個問題公司就開始正規化,開始重新組織,除了我以外開始有其它主管,然後小心翼翼的不要讓公司長成自己討厭的那種公司一樣。( 也許就如資料庫設計一樣,未來也許會有一天需要反正規化 )。

不能只是 MVP ( 最簡可行產品:minimum viable product,簡稱 MVP )

大約開發接近六個月後我就忍不住找了 PM 和 CTO 討論,我說理論上我們應該先做個 MVP 先上線,然後就邊營運邊修正,才不會花了一大堆時間一大堆錢研發結果上線才發現結果不如我們想像,這樣風險比較小。但他們的回答說服我了,他們說 MVP 對於完全沒產品和已有舊產品的公司定義不同,對我們來說新系統的 MVP 總不能比舊系統還少還差吧?也不能功能只有和舊系統一樣吧?我們開發新系統是為了達到三年的近期目標,所以我們的 MVP 應該是對於目標來說是 MVP,而不是硬是為了幾個月內就必須上線的一個版本。最後我說服自己的想法是我的目標是要蓋大樓,這就是打地基,打地基本來就需要時間,想蓋多高就要打多深,如果我硬壓個時間要上線,他們就會蓋個預售屋給我,看起來漂漂亮高的,短時間好像也能住,但要再往上加樓層也加不上去。

不停的踩雷,不斷的 Bug,以前舊系統解過的 Bug ,新系統會再出現

雖然我知道系統不夠大是不會有 Bug 的,所以有 Bug 是正常的,但開發的過程中一直一直出現無法預測的問題,每每工程師信心滿滿的說我們找到方法了,但最後還是有問題,解了 A 跑出了 B,解了 B 跑出了 C,解了 C 一不小心 A 又跑出來,無邏輯的亂迴圈 …. 我是工程師出身,對於這種無奈的狀況很能理解也很能忍耐,但我又是公司的老闆,有股東、資金的壓力,幾個月後我一樣忍不住找了 PM 和 CTO 討論,我說我們不是都請有經驗技術很棒的人進來嗎?我們可不可以就用我們擅長的技術及方式來開發就好,就不用踩那麼多雷了?他們的回答說服我了,他們說如果我們只用擅長的技術,不用這些新技術、新架構會更難達到未來三年的近期目標,那打掉重練的意義就不大了。嗯,好啦,富貴險中求,一切以達到目標為前提,我已經做好會一直踩雷的心理準備了。

堅持不靠加班趕時程

一直以來我們研發內部有跑 scrum ,我們跑 scrum 有一個很大的原因是為了讓大家保有一定的開發節奏感。大約開發已經滿一年但還遲遲無法上線,我們的 PM 和 CTO 的壓力很大,所以他們和所有的工程師討論大家一起加個班全力衝剌讓新系統上線,但即使大家很有心的加班全力衝剌,最後證明還是失敗了,原因同上,每次覺得快要可以上線時,新的 Bug 又跑出來了,就算今天加班加比較晚,但因為隔天精神不好也會比較晚來,所以總的看起來加班又無法上線讓大家的開發節奏亂了、精神不好了,士氣低落,低級的 Bug 變多,時程上根本沒提早到什麼。所以我和他們說,我們恢復常態,不要加班,該怎麼做就怎麼做,我們沒有在摸魚浪費時間,如果慢那就是真的慢,想要快那就補人進來。

補人的時機不對還是慢

每個工程師的時間是固定的,但我們又想要縮短上線時程,最直覺的想法就是補人,所以我們也這麼做,但時機慢了。當我發現上線時程愈拖愈久的時候,我能做的就是對新系統的期望再聚焦、功能開發依目標重新排先後,這些都做了我能做的就是補人,但在時程緊繃的時候補人就錯了。就算再厲害的人進來,要能融入團隊到上手也要花個三個月,而這個三個月是需要有其它人協助的,也就是說你補進來一個人短時間內會拖慢某些人的時間,然後你期望他在三個月後能單兵作戰,但如果這個人不適合,你等於多花了三個月薪水再賠上其它人的時間,還把其它人的開發節奏打亂。我和 CTO 檢討,如果我們要補人應該是要在初期就把人補齊,只是我們一直遇到無法預測的問題根本無法估算該找多少人、怎樣的人才夠,一次找進太多新人對公司文化的衝擊會有多大?最後我們決定在新系統上線前不補人了,所以我的工作就只剩下寫寫文章了 XD (誤)

還技術債的過程帶給我的啟發

成長就是要靠挑戰,挑戰就是會犯錯,犯錯就要繳學費

我想要公司成長就要接受犯錯是常態,就不該因為犯錯而懲罰他人,但犯錯會需要繳學費 ( 時間和錢 ),在學費有限的狀況下,比較省學費的做法就是同樣的錯別再犯,留點學費來犯其它的錯,而我要做的就是把學費準備好。

保持信心,不安全感是正常的,生氣是最沒用的行為

其實 Delay 的過程就像西西弗斯滾巨石的感覺一樣 ( 註:西西弗斯是希臘神話中一位被懲罰的人。他受罰的方式是:必須將一塊巨石推上山頂,而每次到達山頂後巨石又滾回山下,如此永無止境地重複下去。在西方語境中,形容詞「西西弗斯式的」(英語:sisyphean)形容「永無盡頭而又徒勞無功的任務」),好不容易覺得終於可以上線了卻又出現了問題,時程又延後了,日復一日,周而復始。我當然會急會生氣,但我發現生氣其實是一種無能的表現,生氣根本就無法讓新系統上線,難道除了生氣我沒別的積極作為了嗎?我看到我們在前進了、問題在收斂了、重覆發生的問題變少了、開發的節奏感有了,情況正在變好,我的理性告訴我保持信心不用擔心,而我的不安全感只是因為雷踩太多還不知要踩多久的一種心理狀態而已,正常的。

只要合理不用怕花大錢,重點是投資報酬率

找一群比我優秀的人進來需要花大錢,建置一個新系統需要花大錢 ( 在 AWS 上我們目前有三套環境:舊系統正式環境、新系統正式環境、新系統測試環境,為了模擬真實狀況捉 Bug 我們測試環境用的規格等同正式環境 ),只要一個月沒上線,就是多花一個月的錢。沒花過大錢的人剛開始花大錢真的會怕,我不停的告訴自己創業不是為了要省錢是為了要賺錢的,而且是賺大錢,所以只要投資報酬率高、花的合理,該花的就花。

如果公司是一個人,那老闆是頭,員工是手腳,要保持手腳協調,頭是關鍵

老闆應該要做好頭該有的本份,要看的夠遠,聽的進忠言,嗅的出不對的氣氛,要會問問題,要會溝通,對於眾多的資訊要有獨立思考,對員工、客戶、股東要有心,這樣就夠忙的,其它的就不要想要自己去做了。如果發現手腳不協調亂抖動 (員工內亂),那是腦在亂放電 (老闆混亂),重點是醫腦而不是硬要弄個木板 (制度) 把手腳 (員工) 固定讓它不要抖,否則你會發現雖然它不抖了但也跑不快了。

方向比速度重要

很多人會說天下武功,唯快不破,但我覺得這是以方向明確為前提,不然你把眼睛蒙住快速出拳看看,看能打倒多少人?方向不對,動作愈快只是會離目標愈遠。打掉重練的過程中,如何取決新系統哪些功能該作哪些不該作,哪些該現在做哪些可以後做,這和公司的願景有關,而公司的願景和老闆的個人願景有關,所以我花了一段時間刻意讓自己獨處、看書、思考自己的人生方向,這段時間公司很像打開無人駕駛模式自行穩定慢慢前進。當我自己想通了後,公司的願景和使命就明確了,想達到願景該找怎樣的人?做怎樣的產品?就很容易決定了,之後進來的人對了事情進行就快了。【方向比速度重要】這句話我在一次 KKBOX 的參訪中,總裁 Izero 再提到,我就更加確定了。

設定目標比設定 Deadline 重要

我每個月都會和每位同事 one on one,有位同事提到每次研發部門設定 Deadline 然後就 Delay,設定 Deadline 然後就 Delay ….,大家也都很努力很認真,但就是這樣的結果,他都不知該怎麼回答我還需要多久才能上線,覺得對我不好意思。我說我們的研發部門目前就像困在迷宮裡,我們在無法判斷這個迷宮到底有多複雜有多大的狀況下,硬要綁個 30 天後會爆炸的炸彈在他們腳上,然後叫他們限時 30 天走出迷宮,這合理嗎?為了看他們因為緊張而亂跑,這就能在時間內跑出迷宮嗎?我覺得他們還沒跑出來前就會先累死了。Deadline 就像這個炸彈。好了,那如果 30 天後他們發現炸彈沒爆,這時我們再給他們綁一個新的炸彈,這會有用嗎?所以我覺得比較可行的作法是我們不設 Deadline 改設定目標,例如我們今天目標往前走十步,那不管體力好壞就是想辦法往前走十步,只要記得走錯的路不要再走,那總有一天可以走出迷宮。

嗯,我們現在還困在迷宮裡,預計 2019 年 1 月可以走出去,應該吧 XD


以上所述就是小编给大家介绍的《技術債帶給我的啟發:解決Delay的最佳解法是不設Deadline》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Java Message Service API Tutorial and Reference

Java Message Service API Tutorial and Reference

Hapner, Mark; Burridge, Rich; Sharma, Rahul / 2002-2 / $ 56.49

Java Message Service (JMS) represents a powerful solution for communicating between Java enterprise applications, software components, and legacy systems. In this authoritative tutorial and comprehens......一起来看看 《Java Message Service API Tutorial and Reference》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

html转js在线工具
html转js在线工具

html转js在线工具