銘文：
丈夫看著髒兮兮的孩子，對妻子說：好吧，我們該把這些孩子洗掉還是生個新孩子呢？
以下是我們的團隊負責人以及 RAS 產品開發總監 Igor Marnat 關於激勵程式設計師的特殊性的討論。
創造酷軟體產品的成功秘訣是眾所周知的——組建一個由酷程式設計師組成的團隊，為團隊提供酷想法，並且不會幹擾團隊的工作。 優秀的開發人員很少見，而且很受歡迎。 一些招聘人員甚至表示，他們的印像是，培養出一名很酷的程式設計師比從市場上僱用一名程式設計師更容易。 除了招募方面的困難之外，每個特定開發人員的經驗、他對現有產品的了解及其開發歷史往往是不可替代的，或者補充起來很困難且耗時。 因此，如果您很幸運並且已經擁有一支很酷的程式設計師團隊，那麼激發他們的積極性就很重要。 僱用和培訓新的開發人員，組建一個團隊幾乎就像生孩子和養孩子一樣困難和耗時。
讓我們考慮一下程式設計師（程式設計師團隊）動機的主要因素，使用馬斯洛金字塔來提高演示的清晰度和結構。 如果您還沒有聽說過馬斯洛金字塔，那麼它並不是一個無可爭議的，但非常流行且具有說明性的美國心理學家亞伯拉罕·哈羅德·馬斯洛的理論，他提出了一種基於人類需求層次結構的個人動機理論（見下圖）。
馬斯洛將個人的需求依照層次排列，從生理需求到潛在發展和自我實現的需求。 馬斯洛理論的一個關鍵假設是「一個人在較低層次的需求得到滿足之前無法體驗較高層次的需求」。 例如，如果一個人三天沒有睡覺或吃飯，那麼他就不能被知識需求或美感需求所驅動。
在詳細討論之前，讓我們先專注於一個明顯的事實——團隊是由人組成的，每個人都是不同的，每個人都有自己的動機結構。 除了每個人的利益驅動不同之外，每個人的生存狀態也不同。 有人正處於職業生涯的開端，正在考慮如何建立它，有人即將結婚，有人想要掌握一個新的學科領域。 對一個人來說重要的事情對另一個人來說完全不重要，明天一切都會再次改變。 為了正確理解這種情況，有一個簡單的補救措施——你需要思考它並使用它。 最重要的是溝通。
一定要與您的團隊談論工作以外的事情，建立非正式的關係。
那麼，現在讓我們來瀏覽一下馬斯洛金字塔，並考慮其等級是否適用於管理程式設計師團隊。
I：生理、生物需要：
當談到動機時，很多人往往首先想到的是薪水。 在這種情況下，我所說的工資是指薪酬方案的永久部分，它不以任何方式取決於結果。 這不適用於獎金、獎金和公司促銷。 在我們的案例中，我將其歸因於「生理需求」水平。 獎金、基於績效的獎金、選擇權和公司股票——我會將所有這些分類在其他級別。
在我看來，無論聽起來多麼奇怪，薪水都可以 使人失去動力 因素而不是激勵因素。 與程式設計師一起工作的特殊性在於，他們都是人，首先，非常聰明（該職業的一個特點），其次，受過深入和/或廣泛的教育。 通常，程式設計師除了其專業之外，還對他們為其創建產品的一個或多個主題領域有深入的了解。 此外，優秀的程式設計師對程式設計發展的歷史、演算法、標準等感興趣且熟知。 這同樣適用於他們的主題領域。 對於這個等級的人來說，薪水通常不是主要的激勵因素。
同時，對於程式設計師來說，缺乏公平的薪資，在他們的理解中，會讓人士氣低落，而且極大地士氣低落。 擁有公平的薪資是常態。 薪資遠高於標準（市場）——奇怪的是，這也是一個相當令人沮喪的因素。 一位同事曾經告訴我，美國一家大型動畫公司的一個程式設計師團隊，由於種種原因，拿到的薪水比市場水準高出兩到三倍。 正如他所說，他一生中從未見過如此無聊、懶惰和消極的程式設計師。 加薪的事實可能會在短期內產生激勵作用，但幾個月後，新的薪資就會成為常態，不再產生激勵作用。 總的來說，我想說，對於職業生涯初期的程式設計師來說，薪資因素更為重要，隨著他們的專業成長和發展，其重要性下降，其他因素開始佔上風。
第二個要點是團隊中薪資水準的公平平衡。 如果一個團隊感覺到某個成員的貢獻明顯較低，但報酬水準相同，這會降低整個團隊的積極性。 有時，管理者會試圖用金錢火上加油，透過將薪水提高到高於正常水平的方式留住精疲力盡或缺乏動力的員工。 從長遠來看，這通常只會產生問題——個人的積極性不會增加太多，或者增加幾個月，但團隊其他成員的積極性會下降。 在這種情況下，值得尋找其他方法，當然，除非這是一位獨特的專家，需要不惜一切代價保留，即使是短期的。
二. 對安全、舒適、一致的生活條件的需求：
70年前，汽車裡有爐灶可能是選擇汽車時的一個激勵因素；而那時它就超出了常規，成為了奢華的標誌。 現在，即使沒有空調也是無稽之談，而它的存在當然不會成為選車時的激勵因素。 所以10-15年前，方便的辦公、良好的五金、美味的咖啡、健身、彈性的工作時間等等。 可能是很好的激勵因素，但現在這已經成為優秀程式設計師的工作常態。 同時，他們的缺席將再次令人沮喪。
一個重要的消極因素是缺乏集中註意力和嘈雜的工作環境。 程式設計師的工作需要安靜和專注。 如果辦公空間無法提供開發人員一個僻靜的工作空間，那麼至少要確保同事之間的舒適協作，互不干擾。 最好把精力充沛、聲音大的同志團結起來，把注意力集中到需要的人身上。
現在，程式設計師的時間成本明顯高於他工作的硬體成本。 兩到三個顯示器、功能強大的電腦、為每個開發人員提供舒適的工作場所 - 應該成為任何公司的常態。 Joel Spolsky 的一篇文章很好地闡述了這個主題“喬爾測試：改善程式碼的 12 個步驟。”
舒適度的物理組成部分是最基本、最簡單的；現在我們來談談其餘的部分。
在許多公司，程式設計師的標準是靈活的工作時間和沒有服裝要求。 如果團隊工作的具體情況允許的話（例如，不與客戶、政治家或銀行家舉行會議），這是很好且正確的。
重要的是要有一個特定的時間窗口，讓整個團隊在本地一起工作，以便人們可以面對面地溝通和解決問題。 程式設計師本質上是下班後也不會離開工作。 通常情況下，無論他是否在辦公室，工作問題都會在他的腦海中重演，而好的決策往往來自辦公室之外。 鑑於需要做好事（我們將在下面討論），小規模的控制是有害的。 它不僅會降低工作積極性，還會降低工作效率。 實踐表明，在缺乏控制的情況下，一個積極進取的團隊更有可能工作得比必要的時間更長。 如果有控制的話，開發者可以朝九晚六坐在鍵盤前，但我認為結果會更糟。 俗話說，一個人可以牽一匹馬到水邊，一百個人也不會強迫他喝水。
這層次需求的描述也提到了免於焦慮和恐懼、沒有混亂以及對結構和秩序的需要。 這些也是極大影響隊內氣氛的極其重要的一點。
首先，不存在混亂、結構和秩序——團隊必須了解誰負責什麼、如何分配角色、需要做什麼、對誰、何時、產品的需求是什麼、管理層的期望是什麼以及客戶...其中大部分內容都應該正式描述，所有內容都應該定期討論。 如果沒有討論和定期使用，描述就不起作用。 良好的做法是定期討論它們並根據發布後的事後分析結果進行更新。
二是氣氛平靜、友善。 我們大部分時間都花在工作上，我們希望在沒有壓力、衝突或恐懼的情況下工作。 開發團隊通常在進度和客戶的壓力下工作。 沒有人需要同事和上級的額外壓力。 團隊的氛圍，一般來說，一群開發人員可以被稱為一個“團隊”，這是管理者直接而重要的責任，也是最重要的中長期任務之一。 因此，對於管理者來說，尤其是在團隊衝突的情況下，不要讓他們的發展順其自然，這一點很重要。 衝突管理是一個單獨的主題，值得單獨研究。
有兩種主要方式可以影響團隊的情緒狀態和同事的行為（如果有人在評論中添加，那就太好了）。 首先是你自己的行為。 個人榜樣對經理和團隊來說非常重要。 正如他們所說，牧師如何，到來也如何。 按照您期望同事的行為行事。 第二個是鼓勵正確的行為，可以說，阻止錯誤的行為。 與人們溝通，給他們回饋，有很多方法可以做到這一點。 一般來說，回饋是一個單獨討論的主題；它是激勵工作的一個重要部分。
關於氣氛的另一個注意事項，這可能看起來不尋常，但實際上很重要。 通常，開發團隊中的女性人數少於男性。 這些群體通常都是男性。 在這種情況下，在負載之下，有時團隊中會開始使用淫穢語言。 實踐表明，這對氣氛產生了負面影響，溝通逐漸變得粗魯。 您應該避免自己使用它並阻止在您的團隊中使用它。
開發團隊通常被稱為 R&D（研究與開發），其中研究構成了工作的重要組成部分。 這通常是很難編程和規劃的部分，否則就不會進行研究。 重要的是，團隊有權犯錯、主動、嘗試不同的選擇，這些選擇可能會成功，也可能不會成功。 錯誤是工作中正常的一部分，無法避免，但你可以研究、分析、從中學習，為未來做好準備並繼續前進。 起源於豐田的「五個為什麼」原則是找到問題根源的好方法。 懲罰錯誤是營造恐懼和不確定氣氛的好方法。 唯一的例外是，根據分析結果，發現錯誤是由於不專業的工作態度造成的，在這種情況下，可能需要做出人事決策。
談話開始前你的期望和情緒狀態很大程度上影響了團隊的氣氛。 在開始一場艱難的討論、某種報告或只是一場情感對話之前，你對談話對象的情緒和態度很重要。 我總是默認地相信並根據這個人真誠地盡力做到最好的事情來行事。 如果從你的立場看來並非如此，你需要冷靜地、詳細地了解背景，了解他哪裡做對了，為什麼他認為這是對的，以及我們的期望有哪些分歧。 通常事實證明，他們並沒有真正的分歧，只是他對背景的看法更完整或更新鮮，並且有一些你不知道的東西。 或者，相反，他不知道一些事情。 這在分散式團隊中尤其重要，因為人們面對面交流的頻率較低，而使用電子郵件和即時通訊工具。 對於一個由來自不同國家、分佈在不同時區的程式設計師組成的團隊來說，這一點更為重要。 這就是文化差異開始發揮重要作用的地方。
在困難的情況下，開車很容易，非常容易，但是開車回去就很困難，而且沉積物會殘留很長時間。 讓我舉一個最近經歷的簡單例子。 一位團隊經理迫切需要另一個國家相關團隊的經理就客戶的一些問題提供意見。 他在 Messenger 中 ping 一位同事，等了 15 分鐘，再次 ping，然後 15 分鐘後，他進入了其他經理也在場的大型聊天室，並輕微攻擊了該同事，措辭如下：“因為你不也許您能屈尊回答我，而且問題也不是那麼緊急？” 最後發現，我們的企業信差略顯呆板，同事根本沒有看到問題。 我不得不道歉。 一般來說，最好是從好的開始。 總是有可能犯一個嚴重的錯誤並在以後遇到麻煩；這沒有問題（儘管你不應該這樣做）。 總的來說，在我們這個行業工作的 20 多年裡，我只遇到過一次真正惡意的同事（！）。 幸運的是，我們很快就分手了。 事實證明，在絕大多數情況下，同事想要最好的、最了解情況的假設是正確的。
作為經理，您的任務是確保上下文的同步，以及對團隊中接受的期望、要求、截止日期和標準的共同理解。 這些看似小事，但團隊的氛圍正是由這些小事營造出來的。 從分散式團隊的角度來看，重要的任務之一是確保團隊成員定期進行面對面的溝通。 我不只一次地從程式設計師那裡聽說，例如，在支援團隊的工程師親自來找他們並一起工作之後，他們很高興繼續工作，親自為最近來找他們的 Pasha 提供幫助，雖然之前的帕夏只是信差中的一個圖標，沒有人會為了圖標而流連忘返。
順便說一句，我開始談論支援團隊並為我想起了一個典型的例子。 有一次，美國的一位客戶的產品出現了問題，負責他的實施的支援團隊的一位工程師（從俄羅斯借調）下班後留下來幫忙，但問題沒有解決，也沒有解決。 總的來說，他一直待在那裡，幾乎一直坐到早上。 這時，客戶的經理升級了問題，確定了問題對他們的重要性，並在晚上下班了。 升級過程已經在不同的時區取得進展，俄羅斯的支援經理開始嘗試提供協助，因為與客戶辦公室的溝通存在某些困難（VPN、連線問題、國家之間通話困難…）不知道那傢伙已經在辦公室裡坐牢並解決了問題，並試圖找到他。 他們直到早上（美國）才發現這個問題，當時問題實際上已解決並且產品正在運行。 他們立刻開始說到底是什麼，客戶的升級如此之大，沒有任何作用，你在哪裡，我們找不到你，等等。 不用說，由於這種行為，這傢伙的積極性非常低。 組織分散式團隊的工作是一個單獨的大主題，但記住兩件事很重要。 首先，溝通和氛圍非常重要，工作的成功取決於它。 其次，這件事本身是行不通的，必須分開、深入地處理。
與這種需求水準相關的另一個重要點是薪水。 不是工資的多少本身，而是改變工資的特定程序的存在。 公司必須有一種方法來確定不同級別職位的要求。 每個開發人員都應該能夠與公司討論他們對工作的期望，並了解他們的努力如何以及何時會影響他們的薪水。 與經理的定期會議、半年度或年度績效評估都可以達到此目的。 這又是那些其存在並不能明確激勵的時刻之一，但它們的缺席卻非常令人沮喪。
從對秩序的需要和規則的存在出發，我們需要遵守這些規則，並遵循團隊中所接受的正式和非正式的規範。 一般來說，我將其稱為“做好人”的需要。 這種需求的存在證實了微觀管理不是必要的，而是有害的。 為一個人提供工作所需的一切，讓他了解背景、優先事項，並在他的層級上提供行動和決策的自由就足夠了。 在這種情況下，他會感到信任，有機會做出自己的決定，為自己的決定承擔責任，並且能夠發揮自己的潛力。
另一個重要的點應該歸因於對秩序的需要和沒有混亂，那就是專注於任務的能力，沒有頻繁的上下文切換。 成為程式設計師需要時間和專注。 程式設計師真的不喜歡緊急放棄一項任務並切換到另一項任務。 程式設計師工作的必要部分通常不僅是程式碼的實際開發，還包括錯誤修復和協助處理客戶的請求。 提前規劃這些事情是值得的，這樣可以讓程式設計師在切換到另一項任務之前平靜地、完全地完成一項任務的工作。 最好的選擇是讓自己有機會自己規劃工作，提前確定優先事項和即將到來的任務，分配很長一段時間來完成一種類型的任務。 這個主題在書中有很好的描述“Google - 網站可靠性工程”，它很好地描述了規劃團隊工作的方法，以確保大型、高負載、容錯系統的運作和開發，以及從事軟體開發及其支援工作的工程師。
待續...
來源： www.habr.com