<th id="7w293"></th>

<button id="7w293"></button>
<th id="7w293"></th>

        <dd id="7w293"></dd>
      1. 咨詢熱線

        0371-86158370

        警惕降本增效!軟件開發不可忽視的四大誤區 (二)

        如果您正在尋找相關產品或有其他疑問,可隨時撥打服務熱線,或點擊下方按鈕與我們在線交流!

        2024-01-17 10:02:51 發布者:超級管理員

        二、管理懶惰與重度規范化問題

        還有一個誤區就是來自于規范化,為什么規范化也會形成干擾呢?規范化不是好事么?如果一個事情是很容易能看出來問題的,就不會叫做誤區了。我們都能明白,日常生活中,最可怕的人就是面像和善的斯文敗類了,對吧?因為你被表象迷惑了。

        繼續舉一個例子:比如某個團隊復盤研發效率低下的問題,復盤的過程,會去追究為什么研發效率低?原因是他們的團隊的同事在這些模塊接口的調用用法之間老是搞錯,或者找不到正確的用法,于是又另起爐灶開新的接口,形成各種垃圾代碼山?;蛘哒f把接口用錯,模塊重度耦合,牽一發動全身,等等。這些都會制造很多的時間成本,而且還必然會導致一些質量問題。
        所以,面對這種情況,如果技術管理的主導者,自己的技術能力不夠強悍而又厭倦了無休止的討論后,會很容易能夠想到的,不需要太動腦子的方法就是:“我們要增加注釋,把接口的規范統一整理,把架構和目錄統一整理,要讓軟件變得更加易讀,架構更加清晰”。當然,這個內容本身是很正義的,聽起來也貌似很美好?!咀ⅲ核麄兇蟾怕蕸]有能力去想到,員工能力培養的方法問題,技術骨干的甄別技巧問題,以及,其實應該由技術總負責人自己親自設計架構等核心因素… …】
        一個聽起來很正義的事情要推行下去的話,是容易得到大家的支持的。但是真是去推行的時候就會發現問題了,因為沒有去定義注釋寫到什么程度是合格的,架構清晰到什么程度是合格的,于是就需要有專人來做這樣的規范。
        這個時候團隊里面就會開始形成了分工,會有專人來負責這些規范化的事情,而負責規范化事情的同時,他的 KPI 和他的核心職責就是讓規范足夠的極致。這一下就開始完蛋了
        大家可以想象到一定會有過度的規范制定出來。因為既然有專人來干這個事情,就會有人把這種事情當做 KPI 或者 OKR。這種規則,即便嚴苛,但因為一開始這個是所有人都舉手所贊成支持的事情,后面怎么可能自己又跳出來反對呢?所以,反對的聲音都是很渺小的,于是他們的團隊的成員就會形成一種:”我感覺這件事情有點不對,但是我又說不上來哪里不對“ 的感受。
        最后的結果是什么?就是會開始形成一些有意或無意的抗爭,或者是執行怠慢。
        那么負責執行規范的人就會發現規范大家都很支持,卻很難執行,因為大家有反抗情緒。他們的領導層往往會在事后,收到執行上出現困難的一些聲音之后,開始舉行一個反思會,或者說復盤會,去思考他們這么做是對的嗎?
        他們很快會發現這件事情上,單就規則本身來討論,它一定是一個正確的事情,所以他們沒有辦法去把復盤出來“這個事不需要繼續進行”的結論。而且大概率會復盤出另一個結論,就是:“這件事情要繼續做,而且是堅決的做,沒有執行好是因為不夠嚴格,規則還不夠明細,獎懲措施沒有落實到人。做得好的應當獎勵,樹立標桿,執行不好的人要有懲罰!”
        接下來,他們就會開始細化如何用更強制的措施讓這個事情能夠執行得更好,怎樣甑別那些干擾的人,不愿意嚴格執行的人。而強制的措施最容易想到不太用動腦子就能想到的解決方法就是打分,打分就可以量化,就不用去個例化分析了,因為個例化分析太難了,團隊的人那么多,情況那么多對吧?
        他們急切地希望制定很多的一刀切的規則標準,拿著這些一刀切的規則和標準去要求大家,這樣才不會老是遇到爭議。
        根據這些標準來量化大家做的事情,這個時候團隊的失敗就進入到中后期了,因為他們所有的時間和精力就開始圍繞著分數去進行工作了。團隊成員的目標倒是很明確了,把分數做高就對了。但是,這是整個團隊的最終目標么?
        監管團隊的人在制定規則,他的 KPI 他的思考變成了思考規則,而做事情的人變成了圍繞分數去進行工作。
        本來我們是應該圍繞著產品的成功去工作的,但是,這個產品如何才能成功這件事,是誰在負責?這個時候,已經幾乎沒有人負責了,只有領導大老板自己一個人在負責。但是他又想不明白有什么不對勁?因為他安排下去做的事情都是圍繞著他的目標想要做好而推導出來的事情,最后卻做得一團糟,所有人都在努力,卻都沒有圍繞最終目標去做。
        其實背后的原理就來自于一個偷懶的行為:就是他們不想具體案例具體分析了,他們希望制定統一標準之后,大家統一地來套這個標準就好了,不要有誰去挑戰規則。這個才是問題的癥結。
        當然,實用主義也不是說我們就不要規則了。因為有些事情它的量級很高,量級很大,如果每一個問題都要具體案例具體分析,大家也累不過來。這種時候,是需要真正的技術領導者來統籌全局的,對問題的洞悉不應該來自于層層傳遞,而是本身的深度理解。
        例如大部分軟件足夠龐大后,會碰到多線程帶來的穩定性問題,會引入層層疊疊的規范和規則,以及層層疊疊的架構保護措施。幾乎無窮無盡,最后還是解決不干凈線程問題。而我會要求企業微信的線程數量嚴格控制,io 都是一個線程,網絡也都是一個線程,再加上 UI 主線程,常規情況下只有互不干擾的3個線程。當然,也允許特例,但是非常有限,都需要懂這套規則背后原理的人來審核。幾年下來,企業微信這樣一個幾千萬行的超大型軟件系統,幾乎不會遇到任何線程上的質量問題。這為我們的快速迭代提供了極大的助力。當然,這個只是無數措施中不起眼的一小條而已。最關鍵的是,主負責人,自己理解是否對。
        當然,團隊里的核心人物數量有限,當事情的量級達到一定程度的時候,我們一定會迫不得已會用一些自動化的或者說一刀切的規則化的方式去做事情,這些規則化實施的時候,一定要遵循一個原則:就是這個規則面對一些個例的時候,要有一個方法去衡量邊界,越界的,就必須有足夠能力的技術 leader 來獨立分析解決問題。要不然技術 leader 干什么呢?只管人不管技術就不是合格的技術 leader 了。
        規則不能貪多,不能一開始就妄圖制定涵蓋一切的規則。規則太多就沒有辦法做到每一條規則都完美化了。當我們定規則定得太快太多,又長時間不更新不回溯,它們就會形成我們前面講的失敗的案例的結果。

        所以規則要少要精,而且要時常復盤,對一些不能夠完美化的規則,要及時地清理。不要太過懶惰地試圖去批量的進行規范化,規范化一定要有節制。尤其是,有些事情,過去這樣做是對的,今天,不這樣做可能才是對的。


        相關產品
        更多推薦
        科技·質量·服務·創新

        科技·質量·服務·創新

        提交需求

        如果您對我們的產品感興趣,或者我們有什么可以幫助到您的,您可以隨時在線與我們溝通。 當然您也可以在下面給我們留言,我們將熱忱為您服務!

        快速響應給予技術咨詢答復

        專業優質軟件服務

        成熟領先產品解決方案

        專業可靠合作伙伴

        免費咨詢 0371-86158370
        免費獲取報價

        獲取報價

        銷售熱線銷售熱線:0371-86158370

        返回頂部

        首頁 在線咨詢在線咨詢 一鍵撥打一鍵撥打
        亚洲成人久在线