有效軟件生產的八項規則

在我的職業生涯中，我參與了多個現實生活中的軟件項目，並觀察了各個層面的事情是如何完成的：決策制定、實踐採用、團隊建設、招聘、技能分配等。顯然，不同的方法產生了不同的結果. 作為一個以改進為導向的人，我注意到並收集了最有效的做法和最佳實用技巧來幫助我工作。

從觀察中學習是一種艱難而漫長的方法。 我會非常樂意更早地從書本中獲取這些知識。 不幸的是，我沒有找到關於該主題的內容。 所以我決定與其他尋求這種知識的人分享我的經驗。 希望它可以為他們節省幾年的個人研究。

在本文中，您將了解如何通過生產堅固可靠的軟件產品，將維護量減少 5 到 10 倍，從而超越行業平均水平。 我可以毫不謙虛地說，在過去的 10 到 15 年裡，我（個人和我的團隊）已經超出了所有人的預期，留下了成功的痕跡。 經理們再高興不過了。

有一次，我的團隊在極短的時間內完成了一個重要項目，為此我們獲得了更高管理層授予的“高績效團隊”獎。 所有這一切都無需熬夜和周末讓自己筋疲力盡。 只是正常的工作。

你看，有效的軟件生產知識本身就是一種力量。 事實上，這是一種即使用簡單的語言解釋也沒有多少人能夠掌握的黑魔法。 你會免費得到它。 如果您想被視為軟件生產魔術師，請繼續閱讀。

這是給誰的？

讓我在這裡做一個重要的、重要的、重要的免責聲明。

我向那些需要提高生產力的人解決這個問題。 並非生活中的一切都與生產力有關。 也不是所有的軟件項目。 在某些情況下，您的表現不會受到評判。 顯然，這些做法在那時無濟於事。

這些技術對團隊領導、架構師和項目經理最有用，儘管高級軟件開發人員也可以從中受益。

規則 1：了解 IT 心態

IT 行業是科學、技術、藝術和商業的混合體。 如果不充分了解這些方面，就很難在那裡導航。 最大的問題是行業本身相當複雜； 因此，最佳實踐也很複雜。 你需要學習很多東西並通過大量練習來驗證你的知識才能取得成功。

令人難以置信的技術更新速度使其變得更加艱難。 你十年前學到的任何東西都不再需要了。 所以你需要加快學習速度。

綜上所述，我們可以說，在 IT 領域的成功不是基於先天的技能或感覺，而是基於實際的例子。 永遠不要“跟隨直覺”或僅僅基於感覺相信，包括你的感覺。

如果是，這個想法值得考慮。 否則，需要一個非常好的和非常詳細的解釋，說明選擇這條路徑如何讓你的團隊生活得更好。 如果它通過了此測試，請安排一個輕量級的概念證明項目，通過實驗證明它適合您的環境。

這裡要理解的重要一點是，解決方案沒有對錯之分，因為解決軟件問題的方法有很多。 但是，對解決方案的理解有好有壞。

如果一個人可以清晰地詳細闡述想法，或者將採用這種解決方案與團隊成功聯繫起來，從而說服其他團隊成員，那麼我們可以依靠這個人的遠見，並希望獲得很高的成功機會。

規則 2：不要混合軟件生產和軟件開發方法

軟件生產以軟件開發為基礎。 然而，這兩者有著完全不同的目標、心態和實踐。 試圖用另一個領域的方法解決其中一個領域的問題會產生荒謬的結果。 重要的是要了解區別並為每個世界使用適當的方法。

軟件開發是藝術與工藝的結合。 無論自動化工具和軟件開發方法如何，藝術組件將始終存在。 因此，解決開發任務需要最大限度地集中註意力並屏蔽所有其他干擾信號。

激勵有經驗的開發人員的最佳方式是以排除所有人為因素的純技術形式向他們展示任務。 所有要求也應以技術語言表達。 它們應該易於驗證，以使他們能夠在單獨的研究階段朝著目標前進。

相比之下，軟件生產更多地屬於企業管理領域。 您一方面了解客戶的需求，另一方面了解您可以使用的團隊資源。 因此，現在您嘗試引導您的團隊努力實現目標。 同時，你也可以估計自己的進度，給老闆一個周密的計劃。 那裡的重要技能是了解客戶的願望、了解團隊的優勢以及傳達正式的計劃和時間表。

話雖如此，我想強調的是，軟件開發中的許多角色都在這兩個世界中工作——在業務和技術之間架起一座橋樑——例如團隊領導、架構師、分析師和項目經理。 擔任這些角色的人應該能夠輕鬆地在兩個現實平面之間行走，並了解何時該談生意，何時該談藝術。

規則 3：使用持久存儲作為人類記憶的擴展

人類的記憶，雖然容量驚人，但也有其局限性。 你記得事物的準確性和持續時間都無法預測，當你忘記時，就無法隨意回憶。

這就是我們使用持久內存存儲以可預測的速度移動的原因。 這與您在事後很久創建並供其他人使用的用戶手冊之類的正式文檔無關。 這是關於在工作期間使用文檔作為您記憶的外部擴展，以幫助您完成軟件開發過程。

我建議您在遇到不重要的任務或涉及多人的任務時記錄您的想法和計劃。 盡量讓它便宜。 不要創建帶有公司標誌的正式文件。 一個好的工具是包含您的項目空間的公司 wiki。 為任務或問題創建專用頁面（30 秒）。 然後在每次有想法或要與他人討論時更新它。

在開會時，說“等一下，讓我把它放下”，然後花 10-30 秒以書面形式表達出來。 寫作不應該是廣泛的，但它應該是完整和連貫的，就像你將整個想法轉移到紙上一樣。 稍後，您或任何其他閱讀您的文章的人都應該像您現在理解的那樣清楚地理解它。 這個技巧可以節省大量時間，但可以讓您即時記錄。

這種技術有兩個目的。

首先，它通過用力將其壓入石頭，將您的進步鎖定在通往成功的道路上。 不再有某人忘記某事、一次又一次地重申同一件事或重新談判已經談判過的同一件事的風險。

其次，你要理清思路，把困擾你的問題拋在腦後。 現在你的頭腦渴望下一個挑戰。 多麼提高生產力！

這適用於任何規模的項目或任務。 對於更大的空間，您將擁有更大的空間以及隨著項目的發展而逐漸增長的頁面層次結構。 這裡的重要概念是在開始建立快速內存轉儲協議的任務之前準備文檔空間和結構！

對於喜歡技術類比的人，我會將我們的思想比作具有強大處理能力但操作內存有限的處理器。 你基本上可以一次考慮一件事。 在這個類比中，您的文檔用作持久存儲，而您的大腦以迭代的方式解決複雜的問題。 在某個時候，您決定開始下一次迭代，閱讀以前的文檔，並將當前狀態加載到您的操作內存中，考慮一段時間並根據您的新發現更新代碼和文檔。 一步一步，直到完成。

綜上所述，我不鼓勵人們一次處理很多任務。 相反，你的任務越少越好。 不過，真正為人工優化的工作情況並不多，而且可能需要多任務處理，並且您必須以某種方式處理它。 上述技巧有助於更好地處理它。

規則 4：停止在正式的時間估算上浪費時間

沒有兩個項目是相同的。 下次你做類似的項目時，你會有不同的客戶、不同的目標、不同的團隊； 甚至可能是不同的技術。 即使使用標準工具和組件，您仍然需要自定義它們的配置和架構。 當您處理軟件項目時，請記住它們涉及 50% 到 100% 之間的自定義工作。 它們需要研究、討論、思考、試驗和其他高度不可預測的活動。 在實踐中，您可能會在表面上看起來與您之前所做的完全相同的項目類型方面遇到巨大差異。 一個新的項目類型，通過擴展，幾乎不可能準確估計。

如果它如此不可預測，那麼項目經理應該如何提出項目時間表並堅持下去？

文獻中描述了一種正式的方法。 即，將整個項目拆分為更小的步驟，估計每個步驟需要多長時間，然後通過結合各個部分的工作長度來計算項目總長度。 MBA課程中教授的這種方法背後有大量理論。

不幸的是，再多的數學也無法挽救它。 這種方法是出了名的不准確，以至於它完全不可用和不切實際，更不用說它是多麼的耗時。 我從來沒有見過一個項目經理在沒有任何調整的情況下使用正式的計算方法，即使是在方法論狂熱者中也是如此。 即使公司嚴格要求使用這種方法！ 事實上，表現最好的經理使用完全不同的替代方法，如下所述：

一個好的項目經理會注意到項目類型、環境、所涉及的資源、組織類型以及影響實際項目長度的所有其他工作方面。 當然，沒有人需要僅僅從自己的錯誤中學習。 這種觀察可以直接也可以間接進行； 例如，通過書籍或研究其他人完成的項目，甚至只是將知識傳授給他人。 這種統計頂級知識改進了個人項目進度導航。

我想強調上述方法的兩個重要後果。

首先，估計精度隨著經驗而提高。 一個沒有經驗的人用他們擁有的任何強大的方法論武裝起來，是不可能擅長的。 其次，即使是最好的估計也只是在統計方面是好的。 也就是說，可以說某個項目可能需要四到十二個月的時間。 假設這是正確的，人們應該明白該項目有 50% 的機會運行超過其 8 個月的平均時間。

了解統計預測具有如此不可思議的效果。 一個聰明的經理只會對這樣的項目進行 12 個月的估算，然後提前完成它，讓每個人都驚嘆不已。 換句話說，沒有人會期望一個團隊能按照項目進度執行一天。

對項目經理及其老闆的一般建議是停止在正式的時間估算方法上浪費時間。 相反，鼓勵收集有關項目持續時間的統計信息，並在整個公司內共享這些信息。 我知道一些公司在全公司範圍內實施了這種方法，從而產生了驚人的預測精度。

規則 5：了解轉換任務和兼顧優先級的成本

人類的思想是由大自然驚人地設計的。 儘管它令人難以置信，但它也有其局限性。 換句話說，它旨在在特定領域和特定類型的任務中表現出色。

開發人員的頭腦絕對是軟件開發的重要資產。 作為項目經理，您是否有興趣更好地理解它並將其置於表現最佳的位置？

讓我們簡單地說，避免過多的理論。 請記住，在您需要從自己或他人的經驗中學習之前，理論只會帶您走這麼遠。

人腦具有很強的解決問題和產生想法的潛力。 不幸的是，並非總是能夠挖掘這種潛力，主要是因為為了支持創意的產生，您需要同時將所有問題的部分一起保存在您的活動記憶中。 這就是為什麼解決複雜問題會經歷一個簡化階段的原因，當一項任務被概括或重新制定以刪除不重要的部分並同時減少內存中保留的元素數量時。 換句話說，我們既可以解決一個非常狹窄的複雜問題，也可以解決多個簡單問題。

但是，該比率不是線性的。 增加你同時做的事情的數量會極大地削弱你解決問題的能力。 這就是為什麼人類總是使用並將使用角色分離作為生活優化的原因。 兩個人分別處理兩項任務會比他們同時處理兩項任務更快地取得突破。

另一個重要的人類思維特徵是它無法像計算機那樣立即在任務之間切換。 確實，您不能隨意停止思考某事。 你也不能立即開始全速思考一個新概念。 空中交通管制操作員完美地說明了這種心理慣性。 即使他們正在看雷達並看到全貌，他們仍然需要將其加載到內存中才能快速運行。 新操作員需要十分鐘才能看到屏幕，然後才能在換班時更換舊操作員。

更糟糕的是，我們不能隨意忘記事情。 我們所學的一切都會留在我們身邊，隨著時間的推移逐漸消失，佔據我們可以用於新知識的空間。 更糟糕的是，這種影響有時會因“未完成”的感覺而更加複雜。 忘記已經完成並且將來不再需要的東西要容易得多。 而當你把事情放在一邊待會兒完成時，你的大腦自然會緊緊抓住標記為“供將來參考”的信息，不願讓新知識取而代之。

好的。 現在我們已經概述了切換任務的想法，讓我們看看它在現實生活（可以說）思想實驗中是如何工作的。

想像一下，您有十個常規開發人員從事十個常規任務——每人一項任務。 假設我們可以將他們封閉在一個完美無干擾的環境中，那麼每個任務都可以在一定時間內由一個人解決。 整個事情只要完成最長的單個任務所需的時間。

現在，讓我們重複同樣的心理實驗。 這一次，我們將不斷在開發人員之間切換任務分配，沒有（重要）原因。 每天，每個開發人員都有一項新任務要處理。 更好的是，讓我們每小時切換一次。 他們多久能完成，你覺得呢？ 也許永遠不會。

第一個場景中的項目經理能夠有效地執行項目。 第二個設法“執行”了它，這是肯定的……從某種意義上說，他們促成了它的死亡。 恭喜。 這種扼殺項目的技術特別有效，因為除了浪費時間之外，它還將員工的士氣降低到零。

當上面的例子以純粹的學術方式呈現給他們時，大多數人都會同意。 然而，在現實生活中，他們在絲毫壓力下突然忘記了一切。 大老闆要求提供進度報告，或者客戶詢問某個功能的實施日期——幾乎任何外部事件都可以讓項目經理沖向團隊並表達他們的擔憂，然後是一連串的任務重新分配和優先級調整試圖在這里和那裡贏得一點時間，最終只會導致項目更加偏離軌道。

不幸的是，這是一個經常發生的現實場景。

一個好的經理會站起來，通過吸收情緒衝擊波並將其轉化為富有成效的未來討論項目來保護團隊免受此類輕微干擾。 這在情感上肯定很難，但這是讓團隊保持良好工作節奏並讓他們交付的唯一方法。

規則 6：使用架構評審作為改進系統設計的一種方式

IT 行業以過度工程和工程不足的概念運作。 當它在採訪中出現時，每個人都說過度設計是不好的。 這個問題很容易回答，因為這個問題本身傳達了“過度”的負面含義，即“太多”。 真正實用的知識是如何識別您的架構何時過度設計並在早期階段避免它。

讓我給你一些我在這方面久經考驗的建議。

首先，如果有另一個更簡單的解決方案提供所有所需的功能，則該解決方案可能被認為是過度設計的。 這意味著如果您不知道更簡單的解決方案，那麼您可以提供的任何最簡單的解決方案都是您眼中最好的解決方案，除非有人證明您錯了。

如果我們想像中的架構師真正追求完美的解決方案，那麼通常的架構審查可以保證它足夠優化。 不幸的是，架構審查至少需要一些其他合格的架構師。 在許多情況下，它存在不可用或不切實際的危險。 在沒有同行評審的情況下，架構師很容易犯常見錯誤。 讓我們一一審查它們並討論每種可能的補救措施。

最常見的錯誤之一是沒有考慮商業目標的設計。 顯然，任何工作活動都應該與最終消費者的滿意度或公司的成功或類似的業務需求相關聯。 然而，您經常會看到整個或部分設計的架構沒有考慮到這樣的目的。 推理要么不存在，要么歸結為使用盡可能多的現代花里胡哨。

在這種情況下，架構師不會做消費者支付的費用。 相反，他們為了自己的樂趣和樂趣而玩很酷的玩具。 這在正規行業是絕對不能接受的。 然而，無論如何，它似乎經常發生。

有時，問題在於架構師的個性以及他們對某些技術或工具的痴迷。 他們只是喜歡使用它們，無法連貫地解釋他們試圖解決的業務需求。 接近這種情況是另一種情況，當人們除了從小塊構建東西之外什麼都不知道。 當然，任何外部事件都會觸發他們潛入設計世界的衝動，並且永遠不會回到真正的客戶那裡。 即使最初的觸發因素可能是有效的商業投入，他們與現實的長期脫離也會降低他們藝術品的實用性。

解決這個問題很簡單，但需要自律。 一個好的建築師不應該接觸筆和紙，直到他們能夠清楚而誠實地回答自己為什麼需要它。 這種需求可能以不同的形式出現。 它可能是正式的要求、對產品改進的隱含需要，或者是新技術的出現，從而降低了以前的設計效率。 無論如何，只要架構師自己了解驅動力，它就不應成為正式的觸發因素。 然後他們可以用這種力量作為對他們設計質量的最終驗證。

另一個更難檢測的問題與塊架構思維有關。 有這種心態的人認為，任何事情都有解決方案，並且所說的解決方案總是作為構建塊來實現的。 換句話說，它們直接將功能轉換為組件，而不需要整體評估架構。 當需要此類功能時，他們可能只是將提供所需功能的組件附加到系統。 大多數時候，這滿足了形式要求，但使系統處於不連貫的狀態。 新模塊的選擇不是基於現有系統兼容性，用於開發、支持，甚至公司的許可模式。 因此，團隊嘗試修改現有配置或通過現有系統容量實現此功能。 結果，系統的支持和維護逐漸變成了一場錯綜複雜的噩夢，緊隨其後的是性能下降。

這個問題沒有簡單的解決方案，因為系統工程是一門藝術，永遠不可能預測是否必須添加或可以避免新組件。 最佳實踐可能是保持積壓的維護和架構問題隨著時間的推移而積累，然後定期審查整個系統架構。 這種定期審查也可能會考慮新興技術。 因此，架構審查的一般目的不應該是解決問題，而是評估預期改進和整個系統的潛在可行性，以應對迫在眉睫的過時不可避免性。

規則 7：價值團隊成員

大多數 IT 行業專業人士在面試時被問到他們是否是優秀的團隊成員，或者他們是否在團隊中工作得很好。 然而，可能沒有人在文學作品中看到過明確的定義。 顯然，這樣的人通常會為團隊的成功做出貢獻，但很少有人能夠真正定義獨特的個人品質來確保這種成功。

我觀察到許多人在不同層次上工作，並看到他們的個人素質如何影響項目進度。 我想就對團隊合作最有幫助的個人品質提出以下幾點建議。

溝通

當然，首要的品質是溝通能力。

想像一個溝通能力為零的人。 當然，沒有收到團隊成員的反饋會使他們完全無用。 這一點很明顯，面試時沒有人真正衡量這個技能，這意味著只要一個人能說得好，這個技能就足夠好。

溝通不是二元是/否的技能； 它更像是一個信息傳遞窗口。 範圍越廣，信息交流就越快、越清晰。

由於該窗口的開放範圍在人群中差異很大，因此該窗口寬度的度量是團隊成員的一個重要特徵。 請記住，我們談論的是在這種情況下傳達信息，而不是順暢地交談或鼓勵人們或通過交談和交流來激勵或組織他們。

溝通方式也無關緊要。 信息可以口頭、文字、圖片或混合方式傳遞。 這個人可以說快或慢。 他們可以很友好，就像看著你的眼睛一直微笑，或者他們可以移開視線並用單調的聲音說話。 風格可能會影響你對同事的個人看法，但只要你清楚地理解他們的意思，任何風格都足夠了。

讓我們轉向檢測和測量溝通能力的實際案例。

一般來說，溝通技巧有兩個主要方面。 首先是願意分享信息。 有些人渴望分享，但有些人試圖隱瞞信息。 這種傾向或多或少是自然的，但可以通過自我激勵和訓練慢慢改變。 可以肯定的是，表現出一種信息共享意願的人將來也會表現出這種意願。 這就是為什麼該特質有助於預測候選人未來在團隊中的成功。

在現實生活中，試圖隱瞞信息的人很容易引起注意。 他們通常會故意提供無用的信息，而不是實際需要的任何信息。 或者，他們提出初步問題以將信息流向內，並儘量減少對“需要知道”事件的回答。 不管他們採取什麼策略，你最終都會覺得你沒有從他們那裡得到想要的信息，或者獲取信息需要付出太多額外的努力。

理解意圖很重要，因為某些類型的開放人員可能會向您提出初步問題以更好地理解您的問題，然後以最方便的方式為您提供答案。 打算隱瞞信息的人會問更多問題，只是為了避開談話，而不是回答你最初的問題。

溝通技巧的另一部分是適應聽眾的能力。

不同的人對話題的理解程度不同，溝通方式不同，甚至對具體細節的興趣也可能不同。 一些善於交際的人會根據聽眾的理解能力和準備答案以傳遞特定信息的能力來改變他們的對話流程。 在這樣的準備中，可能會問一些初步的問題來縮小聽眾的興趣。 “解決”溝通差異的能力確實是一項很棒的技能，因為它使我們幾乎可以在所有情況下實現理解。 另一方面，靈活的談話者有時可能會陷入無法解決的誤解死胡同。

了解優勢和劣勢

讓我們關注另一個對團隊合作者至關重要的個人品質。

大多數人都會同意，團隊環境應該比周圍的平均環境更友好，以促進協作並提高生產力。 因此，對於一個團隊來說，了解每個成員的強項和弱項以正確分配任務並以優勢彌補弱點非常重要。 這條道路上的第一步是讓所有成員誠實地衡量彼此的技能。 從心理上講，這可能很難，因為我們自然傾向於向他人隱藏自己的弱點，保護自己。

這就是友好的團隊氛圍發揮作用的地方。

因此，新成員有望按團隊規則進行比賽。 不幸的是，有些人即使在友好的環境中也不能放鬆警惕。 他們一生都表現得像獨狼。 這比他們強。 可悲的是，這種態度對團隊的努力沒有貢獻。

有一種簡單的技巧可以在面試中識別出這樣的孤狼。 他們從不承認他們不知道什麼。 當然，人們喜歡展示自己最好的一面，展示他們所有的能力，並嘗試解決每一個難題。 然而，每個人的知識都是有限的。 我們的極限塑造了我們的技能。 不承認限制意味著候選人將自己表現為多面手，無所不能。

當您聘請專家時，您可能希望避開這些人。 此外，這種傲慢的態度往往伴隨著另一個危險信號：不願尋求幫助。 尋求幫助的能力對於團隊合作是絕對必要的。 沒有它，我們就無法快速進步和發展。 這種固執的人會消耗公司的資源和時間，無限期地與艱鉅的任務作鬥爭，但從不尋求隊友的幫助。 有一個簡單的技巧可以在面試中發現這樣的候選人。 問他們一個沒有意義的問題或提及一些無意義的術語。 一個正常的、充滿好奇心的人只會說他們不知道並問它是什麼。 即使您強調沒有正確或錯誤的答案並且“我不知道”不會取消他們的資格，防御者也不會這樣做。

規則 8：專注於團隊合作組織

關於團隊合作組織的信息與上述任何先前主題的信息一樣少。 每個人都知道團隊合作更好，但如何建立和維護團隊仍然是一個謎。 然而，即使不可能涵蓋團隊建設的所有方面，我們至少可以在這裡探索一些關鍵的團隊建設技術。

建築專業知識

每個 IT 項目都是獨一無二的。 要在其中取得成功，需要學習和掌握項目細節。 它們可能包括技術和非技術知識。 非技術知識的一個例子可以是管理人員、客戶、技術支持團隊等的個人網絡。特殊技術知識是一般 IT 技能之上的附加細節。

例如，您可能需要了解 Maven 才能構建項目。 但是，確切的構建結構、屬性的位置和過濾仍然會因項目而異。 與任何類型的知識一樣，掌握這些細節需要時間。 人們投入的時間越多，他們的表現就越好。 時間是你擁有的最寶貴的資源。 您希望讓您的團隊成員盡可能長時間地專注於同一職能領域，以利用他們的專業知識並進一步發展他們，從而不斷提高團隊績效。

不幸的是，不可能無限期地這樣做。 從一方面來說，人們可能只是覺得無聊。 另一方面，您冒著失去他們的專業知識的風險，意外地使您的項目面臨風險。

讓我們看看是否有辦法在不影響團隊表現的情況下應對不利因素。

在團隊成員之間分配重點領域，讓他們在其中積累專業知識。 在某些時候，它們達到了足夠高的水平，在這個項目的範圍內是有意義的。 在這一點上，額外的學習努力不會顯著改善它。 沒有動力和挑戰，聰明的人會變得無聊並開始討厭他們的工作。

通過在其他地方為他們打開學習機會來防止這種情況。 讓他們了解項目和公司的技術堆棧，並迎接新的挑戰。 如果他們的興趣在項目範圍內，您將獲得雙重回報，即讓您的團隊保持挑戰並同時擴展有用的團隊技能。 However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

知識本身就是力量。 This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!