公司發展過程中的軟件質量管理

創業初期,公司的核心資產首先是人,然後是現金,最後纔是代碼,因爲前期來說能搞出東西纔是最實在的;
創業中期,公司的核心資產首先是現金,然後是代碼,最後纔是人,因爲活下去纔是最重要的,如果代碼沒有管理好,最後也容易死掉;
創業後期,公司的核心資產是文化,我理解爲各種原則,什麼該做什麼不該做,原則可以規劃代碼,可以規範員工做事方式,也可以儘可能地保護員工;原則因爲足夠簡單,所以容易傳承,隨着公司做大,最終形成企業文化;

風口的本質

風口的本質是資本跑馬圈地。

前幾年獨角獸企業滿天飛,資本市場日益膨脹。互聯網圈流行雷總說的一句話:“風口過來,豬都能飛”;在那個時候,身邊的人張口一個項目,閉口一輪融資。在當時的人們看來不去創業,不去拉投資,似乎就顯得很傻。

當然,那個時候我也隨大流去創業,幾年前的那會,我們做的是一個智能硬件的項目,在當時的我們看來,項目看起來蠻靠譜的,最後當然是黃了。黃的原因有很多,但是總結起來也就那麼幾點:定位、團隊、資本;

自身能力肯定是一個大問題,因爲當時也才畢業一年,自己也算不上大神級別的人;但是這不是最根本的問題,根本問題我覺得還是團隊定位和項目定位的問題。團隊的定位錯在一開始想掙大錢,而項目定位錯誤在主要負責人急於掙錢,而那個項目需要資本的完全投入才能快速做成;

經過那件事情之後,我開始注意培養自身能力,我也慢慢看到所謂風口的本質不過是一場資本的遊戲;現在的我看來,既然是資本遊戲,自然是有資本的人才能玩的轉的,誰的資本大,資源多,那這場遊戲的勝率就大很多,至少相對於沒有資本的人來說是這樣;很多草根跑去跟大佬搶肉喫,一開始就錯了;更有一些人失敗了埋怨大環境,埋怨資本家,真的沒必要,草根嘛,能活下去就不錯啦,然後慢慢把事情做好,總能夠喫到一點肉;當然也有跑偏的,我有個同學,草根出身,一開始想着掙大錢,一開始搞了個小公司,雖然掙錢,但是他掙得不多,那點錢距離他的理想差太遠了,於是他奮發圖強,最後終於掙到了大錢,只不過他乾的是套路貸,去年作爲頭號進去了;

那草根不能有遠大抱負了嗎?也不是,只不過現在和以前世道變了;以前草根只要敢拼敢闖,借錢承包個煤礦,承包個工程,指不定就發跡起來了;現在的掙錢的大項目基本都被資本盯上了,包括灰色和黑色的,大資本家們也整天在盤算怎麼掙大錢,對於草根來說,基本就沒有什麼優勢了;草根的出路在哪裏?與龍共舞或者紮根底層纔是更好的出路;

意識到這點後,我老老實實找了個公司上班,用心的工作和覆盤,在公司的發展中透過公司遇到的問題看背後問題的本質;因爲對於我這種草根來說,只有紮實的研究某個細分的,前期不需要大量資本注入的領域,才能真正做成事;

風口上成立的公司

我自己是15年畢業的,那就從15年講起吧。15年那一會正好是移動互聯網風生水起的時代,也是萬衆創業大衆創新的時代,那個時候聊得最火的一切和資本有關,就好像那個時候資本突然變得不要錢,樓市,股市,創業,融資,各種各樣的口號和新詞重出不窮,搞得好像不懂幾個新詞就融不進當時的深圳一樣。

我自己搞安卓開發的,當時印象最深的是隨便一個培訓出來的工資都很高,我當時是在大學時候跟着老師做項目,心想着怎麼着也應該比培訓出來的高。實際上並沒有,當時我特別羨慕那些人,水平不怎麼樣但是工資卻很高(當然後來很多都因爲幹不下去轉行了);安卓開發在當時有一個很大的缺口,很多傳統公司急需轉行,好多是瞎轉,各大媒體鼓吹一句口號:不轉行等死轉行找死;

後來我才明白,那只是媒體販賣焦慮的一種方式,就和我們現在看到的各種公衆號和新聞媒體鼓吹的一樣一樣的,那些隨便轉行的小公司們,東搞搞西搞搞,把自己的老本一點點賠進去了,也沒見激起一個水花;最後不得不大規模裁員,然後沉下心來思考下一步怎麼走;

前面說的這類公司佔據了轉型的的大都數,還剩下一些理智一些的老闆沒有瞎轉型,只是在自己的領域往移動端雲端擴展;這類老闆做事謹慎,更容易給人靠譜的感覺;既然是試水,自然是採用一步步試錯,小步迭代,快速疾走的方式,一步一步的捱到了現在;

有人把15年到現在的各行業發生的大事件叫做洗牌,我更加願意理解成爲資本諸侯跑馬圈地的過程,因爲洗牌的話會重新分配,而實際上現在的小公司如果沒有依靠在什麼繫上真的很難活下去,哪怕是一些真正做實事的公司,如果沒有加入某個派系,基本也都艱難的活着;

熬過來的小公司

在資本肆虐的年代,人才也更加願意往更高的地方流,對於小公司來說,能夠找到那麼一兩個人才的,實屬萬幸;在我熟悉的移動開發領域,基本是這樣的:

項目初期

首先成立一個移動開發部,然後招一個價值觀相近肯出力的組長,然後由組長招一批能幹活的下屬,然後這個項目組就算成立了。由於是新項目,老闆給的預算不會很高,因此找過來的員工也不會有很強的能力,項目組長也不見得有多強的能力,但是有一點是肯定的,這個項目組能正常運行起來;

爲了節省成本,這個時候一般是沒有很多繁瑣的流程,至於項目經理,產品經理,技術總監,架構師可能都是同一個人。這樣的好處當然是減少了一些溝通成本,而且在當時看來應該是非常優化的結果。

這個時候項目組負責人爲了讓上頭儘快看到效果,可能會通過縮短開發週期的方式加快產品功能的開發,也就是我們常說的堆功能;其實對於老闆來說他也只能看到功能,因此這個時候老闆聽說又開發出來一個新功能,那自然是相當開心的;

項目中期

項目開發進入深水區,一些麻煩的問題開始顯現,由於前期質量管控不嚴,或者架構設計已經不適用當時情景(我一直覺得架構沒有好壞之分,只有合適與否,如果在一開始原本不需要複雜的架構搞了個很複雜的架構,反而是脫褲子放屁,不僅不能提高效率不說還把當時做開發的人累屎,所以架構方面沒啥好說的,很多就是適合當時的架構,當然不排除一些給自己加塞搞一些華而不實架構的,不在本文討論範圍內);

在軟件領域產品質量問題基本都是代碼質量導致的,這個包括了代碼運行的穩定性和健壯性,這個是顯性的,當時就能夠發現的。還有一些隱性的,諸如代碼規範,文檔,編碼質量等;

到了這個階段,軟件開發和維護人員可能已經換了一波人了。前人自然是沒有少給後面的開發和維護人員埋坑,不管是有意還是無意,坑就在那裏了。新來的開發人員有兩種選擇:勇敢的踩坑或者機智的避開。多數人自然是選擇後者,畢竟對於自身來講風險最少,誰願意和上級彙報的時候說我寫代碼bug越寫越多呢?

這些機智的人處理的方式多種多樣,總結來說就是儘可能的多寫一些相似的類或者方法,把自己認爲可行的代碼放進去,原來的代碼能不動的儘量不動,實際上對於管理者來說也希望有儘可能少的bug,畢竟有很多bug可不是一件讓人開心的事情,老闆不好和客戶交代,程序員還得加班;

隨着開發人員的更替,結果自然是項目代碼越來越臃腫,代碼的可讀性也越來越差,維護代碼的成本也日益增加,解一個bug或者在原有功能上擴充顯得越來越難。慢慢的,原有的人手開始不夠支撐整個項目的運行,必須增派人手。

增派人手必然導致整個項目成本的上升,對於一些有實力的公司還能撐下去,通過擴招的手段解決當下的問題,資金實力沒那麼強的就比較慘了,公司的資金鍊不容許無限制的人員擴招下去,而且人員的擴展必然帶來管理成本的擴招,管理體系必然是越做越大,最終會由於資金鍊斷裂而解散掉整個項目組甚至把公司拖垮;

這真是應了馬太效應:強者越強,弱者越弱

那麼資金實力強一些的公司的老闆也不是傻子,項目組不可能無限制擴展,當項目的支出超過紅線,迎接這個項目的要麼是被砍掉要麼是調整;調整有幾種方式,一種是通過思加壓力迫使員工加班以節省開支,另一種是招一個懂質量管理的人進來專門負責質量管理,還有一種就是從內部培養出一個質量管理人員出來;

這三種方式裏面,第三種當然是最靠譜的,但是很多公司用的是第一種方式。一方面是有些老闆沒有意識到是代碼質量的問題,另一方面是公司成本控制不容許花高價錢招一個懂質量管理的人進來;不管怎麼樣,第一種方式都是很容易把項目拖垮的;

項目後期

項目交付階段,原來埋得那些坑再也藏不住了,問題一個個暴露出來,項目組的壓力也越來越大,公司的資金鍊也越來越緊張,其實在這個階段,不擴招的話項目維護不過來,招人的話前面的那些問題又會出來,所以最靠譜的方式就是控制瓶頸;

敏捷開發裏面有一本很有名的書《一個it運維的傳奇故事》,裏面很重要的理念就是瓶頸理論,通俗點來說,項目就像一條流水線,分爲上下游,當流水線中間某一塊堵住時,管理者會下意識以爲是上游生產效率低下導致,實際上,癥結點就在中間堵住的那環,疏通了,問題也就解決了;

項目管理的疏通和水管的疏通有一點區別,水管的疏通我們不需要擔心上游大量的水湧下來水管會壞掉,但是在項目中需要考慮,如果突然把節點疏通,必然導致下游短時間承受較大壓力而出現故障;穩妥的方式是先控制上游的產出,讓瓶頸處的壓力不再增加。然後慢慢疏導瓶頸,經過一個較長的疏導後,問題自然就解決了,項目也就理順了;

這個裏面主要的就是前面說的代碼質量,一方面要項目中懂質量管理,上級要明白質量管理的重要性。另一方面下游需要將代碼質量管理控制到位,不是表面上的減少bug數量。而是從編碼上梳理每條業務運行的經絡,明確實現思路,確保編碼質量;

如何提高代碼質量

上面說過,要提高代碼質量,一方面是要統一編碼方式,使代碼通俗易懂,另一方面是疏通業務流程,讓每一條業務實現有據可查且條理清晰;

《代碼整潔之道》是一本專注於提升代碼質量的書,但是對於沒有閱讀習慣的人來說把這本書看完是一件比較痛苦的事情,同時我們也不可能要求每個員工通讀這本書,及時都堵了也不一定都吸收進去了。因此最好的辦法是管理者將裏面的精髓抽象成原則性定義;

成功的公司都有自己的原則定義,比如華爲研發內部就有《華爲C語言編程規範》,阿里巴巴不僅有相關的文檔,還將約束做成代碼檢查插件,我們在idea的插件倉庫就能直接安裝,在開發過程中給與規範提示,更加高效;

我覺得,如果想要用一句話總結如何提高代碼質量的話,那就是:

儘可能的少說廢話,儘可能的多幹實事;

廢話就是那些對於當前場景來說可以省略的話;
實事就是能夠實際解決問題的事,處理問題抓住本質而不是邊邊角角,一真見血的把事情搞定;實事是有實在意義的事,半成品是沒有意義的,只有成品纔有意義。因此多做實事就是多做成品,少做半成品;

廢話和實事不是絕對的,就比如我寫這篇文章,我現在制式想做一個記錄,那麼裏面很多廢話我就懶得刪了,因爲對於我來講,刪了反而耗費時間,我只是純粹的記錄,如果能幫助到別人自然是很好,沒有那也無所謂,畢竟我這篇文章是寫給自己看的;

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