有關技術管理的一些思考

2022-09-17 11:30:23 字數 2586 閱讀 8410

這些天裡工作的環境發生了一些微小的變化,可能以後對基層開發的程式設計師也會有更加具體的影響。上週參加 open party 時,重點聽了《那些失敗的專案們》,分析了乙個專案的提出、實施,直到最後失敗的過程。我也在想乙個技術團隊究竟應該用怎樣的一種管理方式,才能讓技術團隊的效率達到更優。

我分了幾個小主題,下面一一講來。

乙個程式設計師一天有多長時間在高效率地工作?

雖然現在絕大部分 it 公司都聲稱是 8 小時工作制,但作為開發一線的程式設計師們一天裡真正在高效工作的時間,絕少能超過 4 個小時,甚至一般只有兩個小時左右。這是我這兩年半以來對我自己和跟一些朋友交流得到的結論。而對於乙個有經驗的程式設計師來說,高效率時段和心不在焉的情況下,工作效率可以差上10倍或者20多倍。我曾經有過用兩個多小時的時間把半個星期的任務都完成的經歷。

因為真正高效的時段非常少,所以加班在我看來是根本不必要的。如果團隊裡的人個個都精力十足,能力超群,一天能高效工作4個小時,那是非常了不起的。不過這樣就引出了下乙個問題,既然加班是不必要的,那為什麼會時常不得不加班呢?

為什麼要加班

一句話來概括,之所以需要加班,是因為白天的時候程式設計師們都沒有好好幹活。

那些主管、老闆們聽到這話時先不要著急去找程式設計師算賬,先想想自己的管理方式有沒有問題。程式設計師們的工作特點是,他們要面對各種細節問題、權衡各種實現方案、測試已實現的功能。這是一種很需要細心和耐心的工作,典型的腦力勞動。要讓程式設計師們進入這種狀態,你需要為他們提供必要的條件。在我看來,這條件是如此地簡單,那就是:不去打擾他們。

當你全神貫注地做一件事的時候,有人跑過來問了你乙個問題,你花了5分鐘去給他講,等你講完時,卻發現很難再進入到剛才那種全神貫注地狀態了。有些程式設計師們對這種事情極為反感,有些則是會用極簡潔的語言給對方講,因為一旦囉嗦起來,程式設計師們可能就再也做不下去了。也因此,這些人經常會被人認為是「缺乏溝通能力」。依我看,這不是溝通能力的問題,這反而是對工作負責任的態度。

做為程式設計師的上司,應該想想,在你的公司裡,程式設計師的工作是支援別人(為別人答疑解惑),還是開發產品。如果是後者,你是否又過於強調了溝通能力?要知道如果程式設計師的工作是做出高質量的軟體產品,那你就應該讓他專心做好這一件事,別讓他又寫**又當客服。程式設計師不專心,白天的溝通太多,就不能做完工作。只好等到晚上加班,別人都走了,他在沒有干擾的情況下才有可能進入高效的狀態(注意我說的是有可能)。

我所理解的「溝通能力」

我不認為僅僅能夠耐心地給別人講問題就算是溝通能力強。我認為對於程式設計師來說,溝通能力首先表現在你寫的**要容易讀懂,當別人接手你的**時,不至於讓對方過於旨解。同樣地,你也要善於讀懂別人的**,程式設計師的思維、設計全部都體現在**裡。可以說,只要你有**,你就應該盡量自己弄明白原作者的意思,盡可能不去動不動就問別人。理由同上面所說,減少對他人的干擾。

其次,溝通能力還應該體現在所寫的文件中。如api介面文件,把每乙個api的功能、引數型別、返回值型別、異常情況等等都用簡潔的、沒有歧義的語言描述出來。這樣讓後來的人有據可查,不用到處諮詢他人就可以在你的基礎上開發。對於程式設計師來說,文件不要求生動形象,但必需要沒有歧義。有這樣的文件,當有人再來回跑來跑去問你問題時,你可以直接讓他去看**或者文件,你需要專心地做手頭上的工作。

少開會

我曾經參加過乙個兼職的專案,專案的負責人找來的幾個人也都是兼職的,在不同的公司工作。有一次商量設計方案,負責人說要聚在一起討論,也就是開會。對於我們這些人來說,從不同的地方坐半天地鐵跑到一塊,就為了開乙個1小時的會,這實在太不合算了。我當時說其實根本沒有必要讓大家抽出晚上的時間跑過來,直接在網上說就足夠了。不過那個負責人說面對面的溝通效率高。呃……我為了過來和你面對面的溝通1小時,要花1個半小時的時間在路上,反正我是不相信這種方式的效率會高……

在《rework》裡看到一種觀點,說你把10個人叫到一塊,開了1個小時的會,就相當於浪費了10個小時。其實遠不止10個小時。參會的人要準備,聽會的人被打斷工作,加起來有可能浪費超過20個小時。

關於結對程式設計

結對程式設計是在敏捷開發中提到的一種程式設計方法,即兩個人共用一台電腦,乙個人寫**,另乙個人對他的**實時檢查。我一向不主張這種做法,在我看來,這種做法有兩個弊端:

首先是違背了我前面所說的,不要去打擾工作中的程式設計師。結對程式設計恰恰是對工作中的程式設計師不停的打擾。試想一下,當你在實現乙個比較複雜的邏輯時,你旁邊的人不停地在說「可能有更好的辦法……」、「變數名寫錯了」之類的話,你還能專心地寫下去嗎?反正我是覺得不能了。我甚至感覺,如果在我寫程式的時候背後有人在盯著我,我都沒辦法寫下去。

另乙個弊端是,在旁邊監督的人往往不如親自寫**的人想得仔細,因為他不寫**,沒有親自參與到開發一線中去,就不會很專心,容易形成敷衍於事的情況。搞結對程式設計,不僅極大降低了其中乙個程式設計師的開發效率,還幾乎白白浪費了另乙個程式設計師的人力。

不要以加班為榮

領導往往容易認為,肯加班的員工就是好員工。要我說,完全不是這回事。首先加班是不必要的,前面已經說過。如果出現了不得不加班的情況,那就是領導沒當好,程式設計師沒幾個願意晚上加班的。恰恰相反,如果乙個員工很少加班的話,說明他的效率高、能力強,反而應該給予獎勵。而目前的薪酬制度,使得加班多的能多拿加班費,受到領導的重視;而真正的高效率員工往往被視而不見,只能拿基本工資。加班幹活的員工不一定是好員工(但加班自學深造的一定是好員工)。

技術管理思考

其實技術團隊大家都很聰明,很多人認為他自己肯定比你更聰明,技術更好,那麼大家為什麼要聽你管理呢?自己的經驗是,首先為大家開好頭,其次過程中要為大家掃清細碎的事情,最後並結好尾巴。總之是乙個服務員型的角色,同樣自己也要做專案當廚師的角色,這樣就能不離開團隊,和團隊一起戰鬥。這樣的壞處就是要為這個專案操...

技術走向管理一些思考

在 it專案管理 一書中針對it行業定義了乙個新的 工種 多才多藝者,並預言未來的it產業中多才多藝者的重要性將逐漸凸顯。多才多藝者即是具有技術背景,同時了解業務部門 能規劃和實施it計畫 增加商業價值 培養公司內外部關係的人。想想還覺得蠻有道理的,因為在這場不知持續多久的o2o 傳統行業網際網路化...

有關程式設計和工作的一些思考

在這裡,作者講到專業技能和非專業技能兩種.專業技能一般具有不可遷移性,我把它理解為知識能力中的深度,非專業技能可以理解為在實際應用中無法直接顯現的技能,比如抽象思維,歸納能力,設計能力,或者解決問題的能力.除此之外,作者還把一些 旁門左道 歸入到非專業技能裡面,比如溝通能力,自我管理,或者其他學科領...