銘文：
丈夫看著髒兮兮的孩子，對妻子說：好吧，我們該把這些孩子洗掉還是生個新孩子呢？
以下是我們的團隊負責人以及 RAS 產品開發總監 Igor Marnat 撰寫的文章的第二部分，內容是關於激勵程式設計師的特殊性。 文章的第一部分可以在這裡找到 -
在文章的第一部分，我觸及了馬斯洛金字塔的兩個較低層次：生理需求、安全需求、舒適性和持久性，然後進入下一個第三層，即：
III - 需要歸屬感和愛
我知道義大利黑手黨被稱為“Cosa Nostra”，但當我知道“Cosa Nostra”如何翻譯時，我印象非常深刻。 「Cosa Nostra」從義大利文翻譯過來的意思是「我們的事業」。 名字的選擇對於動機來說是非常成功的（我們拋開職業，在這種情況下我們只對動機感興趣）。 一個人通常會想成為團隊的一員，做一些大的、共同的、我們的事情。
陸軍、海軍和任何大型準軍事部隊都非常重視滿足歸屬感和愛的需求。 正如我們所見，在黑手黨中。 這是可以理解的，因為你需要強迫那些沒有什麼共同點的人，他們最初並沒有組成一個志同道合的團隊，他們是透過徵兵（非自願）聚集在一起的，他們有不同的教育水平，不同的個人價值觀，冒著生命危險，真正將自己的生命奉獻給某個共同的事業，將自己的生命託付給戰友。
這是一種非常強烈的動機；對大多數人來說，感覺自己屬於更大的事物，知道自己是家庭、國家、團隊的一部分，這是極其重要的。 在軍隊中，制服、各種儀式、遊行、遊行、旗幟等等都是為了這些目的。 對於任何團隊來說，大致相同的因素都很重要。 符號、企業品牌和企業色彩、用具和紀念品都很重要。
重要的是，重大事件有其自己的可見體現，可以與之相關聯。 如今，公司擁有自己的商品、夾克、T 恤等已成為常態。 但強調公司內部的團隊也很重要。 我們經常根據發布結果發布 T 卹，並將其贈送給所有參與發布的人員。 一些事件、聯合慶祝活動或整個團隊的活動是激勵的另一個重要因素。
除了外在屬性之外，其他幾個因素也會影響團隊的歸屬感。
首先，存在一個每個人都理解並對其重要性進行評估的共同目標。 程式設計師通常希望了解他們正在做一件很酷的事情，並且他們作為一個團隊一起做這件很酷的事情。
其次，團隊必須有一個整個團隊都在場且僅屬於該團隊的溝通空間（例如，在 Messenger 中聊天、定期團隊同步）。 除了工作問題之外，非正式的溝通，有時對外部事件的討論，輕鬆的閒聊——所有這些都創造了一種社區和團隊意識。
第三，我要強調在團隊中引入良好的工程實踐，以及與公司接受的標準相比提高標準的願望。 實施業界內接受的最佳方法，首先在團隊中，然後在整個公司中，讓團隊有機會感覺到自己在某些方面領先於其他人，引領潮流，這會產生一種歸屬感到一個很酷的團隊。
歸屬感也受到團隊參與規劃和管理的影響。 當團隊成員參與討論專案目標、工作計劃、團隊標準和工程實踐以及面試新員工時，他們會產生參與感、共同主人翁感和對工作的影響力。 人們更願意執行自己所做和表達的決定，而不是別人提出的決定，即使這些決定其實是一致的。
生日、週年紀念日、同事生活中的重大事件——聯合披薩、團隊贈送的小禮物都會給人一種溫暖的參與感和感激之情。 在一些公司，習慣上會為在公司工作了5年、10年、15年的人頒發小型紀念牌。 一方面，我不認為這對我取得新成就有太大的激勵作用。 但顯然，幾乎所有人都會因為沒有忘記他而感到高興。 這是一種事實的缺乏會讓人沮喪，而不是事實的存在會讓人興奮。 同意，如果 LinkedIn 在早上提醒您並祝賀您在工作地點成立 10 週年，但公司裡沒有一個同事祝賀您或記得您，那可能會很遺憾。
當然，很重要的一點是團隊組成的改變。 很明顯，即使團隊中某人的到來或離開是提前宣布的（例如，在公司或團隊通訊中，或在團隊會議上），這並不能特別激勵任何人取得新的成就。 但如果有一天你在你身邊看到一個新人，或者沒有看到一個舊人，這可能會是一個驚喜，如果你離開，那就完全不愉快了。 人不應該悄無聲息地消失。 尤其是在分散式團隊中。 尤其是當你的工作依賴另一個辦公室的同事突然出現並消失時。 這樣的時刻絕對值得事先單獨通知團隊。
一個重要因素，英文稱為 所有權 （「佔有」的直譯並不能完全反映其意義）。 這不是一種所有權的感覺，而是一種對你的專案的責任感，當你在情感上將自己與產品以及產品與你自己聯繫起來時的感覺。 這大致對應了電影《全金屬外殼》中海軍陸戰隊員的祈禱：「這是我的步槍。 這樣的步槍很多，但這一把是我的。 我的步槍是我最好的朋友。 她是我的生命。 我必須學會像擁有自己的生活一樣擁有它。 沒有我，我的步槍就沒用了。 沒有步槍我就一無是處。 我必須把步槍打直。 我必須比試圖殺死我的敵人更準確地射擊。 在他向我開槍之前，我必須先向他開槍。 就這樣吧……”。
當一個人長期致力於一個產品，有機會對它的創造和發展承擔全部責任，看到一個可以工作的東西如何從「無」中產生，人們如何使用它時，這種強大的感覺就會產生。 長期在一個專案上合作的產品團隊通常比短期組建、以流水線模式工作、從一個專案切換到另一個專案、不對整個產品承擔全部責任的團隊更有動力和凝聚力。 ， 從開始到結束。
四． 需要認可
一句善意的話也會讓貓咪高興。 每個人都受到對自己所做工作重要性的認可及其正面評價的激勵。 與程式設計師交談，定期給他們回饋，慶祝他們出色的工作。 如果您有一個大型且分散的團隊，定期會議（所謂的一對一）非常適合此目的；如果團隊很小並且在本地合作，則通常會在日曆上沒有特別會議的情況下提供此機會（儘管定期會議）一個就夠了，仍然需要，你可以少做一些）。 manager-tools.com 上的經理播客詳細介紹了這個主題。
然而，值得牢記文化差異。 美國同事熟悉的一些方法並不總是適用於俄羅斯的方法。 對於來自俄羅斯的程式設計師來說，西方國家團隊日常溝通中所接受的禮貌程度最初似乎有些過高。 俄羅斯同事的一些直率特徵可能會被其他國家的同事視為粗魯。 這對於跨種族團隊的溝通非常重要；關於這個主題已經有很多文章；這樣一個團隊的經理必須記住這一點。
功能演示（程式設計師展示衝刺期間開發的功能）是實現這一需求的良好實踐。 除了這是一個暢通團隊之間溝通管道、向產品經理和測試人員介紹新功能的絕佳機會之外，它也是開發人員展示其工作成果並表明其作者身份的好機會。 好吧，當然，也要提高你的公開演講技巧，這永遠不會有害。
在聯合團隊聚會上用證書、紀念牌（至少是一句善意的話）來慶祝特別傑出的同事的重大貢獻是一個好主意。 人們通常非常重視這樣的證件和紀念牌，搬家時隨身攜帶，一般都會百般愛護。
為了標記對團隊工作更重要、更長期的貢獻、累積的經驗和專業知識，經常使用等級制度（同樣，可以與軍隊的軍銜制度進行類比，此外，以確保從屬關係，也可達到此目的）。 年輕的開發人員通常會加倍努力才能獲得新星（即從初級開發人員轉變為全職開發人員等）。
了解員工的期望至關重要。 有些人更有可能受到高等級的激勵，即被稱為建築師的機會，而另一些人則相反，對等級和頭銜漠不關心，並認為加薪是公司認可的標誌。 與人們溝通，了解他們想要什麼以及他們的期望是什麼。
透過給予更多的行動自由或參與新的工作領域，可以表現出對團隊的認可和更高的信任。 例如，一個程式設計師在獲得了一定的經驗，取得了一定的成果之後，除了依照規範實現自己的功能之外，還可以從事新事物的架構工作。 或涉足可能與開發不直接相關的新領域——測試自動化、實施最佳工程實踐、幫助發布管理、在會議上發言等。
五、認知和自我實現的需要。
許多程式設計師在人生的不同階段專注於不同類型的程式設計活動。 有些人喜歡進行機器學習，開發新的資料模型，為了工作閱讀大量科學文獻，並從頭開始創造新的東西。 另一種更接近調試和支援現有應用程序，其中您需要深入挖掘現有程式碼、研究日誌、堆疊追蹤和網路驗證碼數天或數週，並且幾乎不編寫新程式碼。
這兩個過程都需要大量的智力努力，但它們的實際產出是不同的。 人們相信，程式設計師不願意支持現有的解決方案；他們更願意開發新的解決方案。 這其中不乏智慧。 另一方面，我合作過的最積極、最團結的團隊致力於支持現有產品，在支持團隊聯繫他們後發現並修復錯誤。 這些傢伙確實是為這項工作而生，並準備在周六和周日外出。 我們曾經急切地處理過另一個緊急而複雜的問題，要么是31月1日晚上，要么是XNUMX月XNUMX日下午。
有幾個因素促成了這種高水準的積極性。 首先，它是一家在業界享有盛譽的公司，團隊與其有聯繫（請參閱「聯繫的需要」）。 其次，他們是最後的前沿，他們後面沒有人，當時沒有產品團隊。 他們和客戶之間有兩個層面的支持，但如果問題到達他們那裡，他們就無處可退，沒有人在他們身後，整個公司都在他們身上（四位年輕程式設計師）。 第三，這家大公司擁有非常大的客戶（國家政府、汽車和航空企業等），並且在多個國家擁有非常大規模的設施。 結果，總是複雜而有趣的問題，簡單的問題都是靠前幾級的支援來解決的。 第四，團隊的積極性很大程度上受到與之互動的支援團隊的專業水平的影響（有非常有經驗和技術能力的工程師），我們始終對他們準備的數據的品質、他們進行的分析充滿信心， ETC。 第五，我認為這是最重要的一點——球隊非常年輕，所有的人都處於職業生涯的初期。 他們有興趣研究大型而複雜的產品，解決新環境中新的嚴重問題，他們尋求專業地匹配周圍團隊、問題和客戶的水平。 這個專案結果是一所優秀的學校，後來大家都在公司取得了不錯的職業生涯，成為了技術領導者和高級經理，其中一個傢伙現在是亞馬遜網絡服務的技術經理，另一個最終跳槽到了谷歌，而所有他們中的一些人仍然對這個計畫記憶猶新。
如果這個團隊由擁有 15-20 年經驗的程式設計師組成，那麼動機就會不同。 當然，年齡和經驗並不是100%的決定因素；這完全取決於動機的結構。 在這個特殊的案例中，年輕程式設計師對知識和成長的渴望產生了極好的結果。
一般來說，正如我們已經多次提到的，您必須了解程式設計師的期望，了解他們中的哪些人希望擴展或改變他們的活動領域，並考慮這些期望。
超越馬斯洛金字塔：結果可見度、遊戲化和競爭，沒有廢話
關於程式設計師的動機，還有三個更重要的點肯定需要提及，但將它們納入馬斯洛的需求模型就太人為了。
首先是結果的可見性和接近性。
軟體開發通常是一場馬拉松。 研發工作的成果會在幾個月甚至幾年後顯現出來。 去到一個遠遠超出地平線的目標是很困難的，工作量是可怕的，目標很遠，不清晰，不可見，「夜色漆黑，充滿恐怖」。 最好把通往它的路分成幾段，開闢一條通往最近的那棵看得見、可達、輪廓清晰、離我們不遠的樹的路——然後向這個近在咫尺的目標走去。 我們希望付出幾天或幾週的努力，獲得併評估結果，然後繼續前進。 因此，值得將工作分解為小部分（敏捷中的衝刺很好地服務於這個目的）。 我們已經完成了部分工作——記錄它、呼氣、討論它、懲罰有罪者、獎勵無辜者——我們可以開始下一個循環。
這種動機在某種程度上類似於玩家完成電腦遊戲時的體驗：他們在完成每個關卡時定期獲得獎牌、積分、獎金；這可以稱為「多巴胺動機」。
同時，結果的可見度也非常重要。 清單中已關閉的功能應變為綠色。 如果程式碼寫好了、測試了、發布了，但是程式設計師可見的視覺狀態沒有變化，他就會感覺不完整，不會有完成感。 在我們的版本控制系統的一個團隊中，每個補丁都會經歷三個連續的階段——構建構建並通過測試，補丁通過代碼審查，補丁被合併。 每個階段都以綠色勾號或紅色十字在視覺上標記。 有一次，一位開發人員抱怨程式碼審查時間太長，同事需要加快速度，補丁掛了好幾天。 我問，這對他來說實際上改變了什麼？ 畢竟，當程式碼寫好、建置完成、測試通過時，如果沒有註解的話，他不需要注意發送的補丁。 同事們自己將審查並批准它（如果沒有評論的話）。 他回答說：“伊戈爾，我想盡快得到我的三個綠色勾號。”
第二點是遊戲化和競爭。
在開發其中一款產品時，我們的工程團隊的目標是在其中一款開源產品的社群中佔據顯著位置，進入前三名。 當時，沒有客觀的方法來評估某人在社區中的知名度；每個大型參與公司都可以聲稱（並定期聲稱）自己是第一個貢獻者，但沒有真正的方法來比較參與者的貢獻之間，及時評估其動態。 因此，沒有辦法為團隊設定一個可以在某些鸚鵡身上衡量的目標，評估其成就程度等。 為了解決這個問題，我們的團隊開發了一種工具來衡量和視覺化公司和個人貢獻者的貢獻 。 從動機的角度來看，這只是一枚炸彈。 不僅是工程師和團隊不斷監控自己的進步以及同事和競爭對手的進步。 我們公司的高階主管和所有主要競爭對手也以 stackalytics 開始了他們的一天。 一切都變得非常透明和可視化，每個人都可以仔細監控自己的進度，與同事進行比較等。 工程師、經理和團隊設定目標變得方便快速。
在實施任何定量指標系統時出現的一個重要問題是，一旦實施了它們，系統就會自動努力優先考慮實現這些定量指標，從而損害定性指標。 例如，完成的程式碼審查數量被用作指標之一。 顯然，程式碼審查可以透過不同的方式完成，您可以花幾個小時對複雜的補丁進行徹底的審查和檢查，檢查測試，在您的工作台上運行它，檢查文檔，並在您的業力中獲得加一次審查，或在幾分鐘內盲目點擊幾十個補丁，給每個補丁+1，並獲得+1的業力。 有一些滑稽的例子，工程師點擊補丁的速度如此之快，以至於他們給 CI 系統的自動補丁+XNUMX。 正如我們後來開玩笑說的：“走吧，走吧，詹金斯。” 就提交而言，也有很多人使用程式碼格式化工具檢查程式碼，編輯註釋，將句號更改為逗號，從而增強了他們的業力。 處理這個問題非常簡單：我們使用常識，除了定量指標之外，還使用基本的定性指標。 團隊工作成果的利用程度、外部貢獻者的數量、測試覆蓋水平、模組和整個產品的穩定性、規模和性能測試的結果、接受核心評審者肩負的工程師數量綁帶、項目被納入核心項目社區的事實、是否符合工程流程不同階段的標準——所有這些和許多其他因素都必須與簡單的定量指標一起進行評估。
最後，第三點——不廢話。
開發人員都是非常聰明的人，並且在他們的工作中非常有邏輯性。 他們每天花費 8-10 小時來建立長而複雜的邏輯鏈，因此他們可以即時發現其中的漏洞。 在做某件事時，他們和其他人一樣，想了解為什麼要做這件事，以及哪些方面會變得更好。 您為團隊設定的目標必須誠實且現實，這一點極為重要。 試圖向程式設計團隊推銷一個壞主意是一個壞主意。 如果你自己不相信一個想法，或者在極端情況下，你沒有不同意和承諾的內在狀態（我不同意，但我會這麼做），那麼這個想法就是糟糕的。 我們曾經在一家公司實施了一個激勵系統，其中一個要素就是提供回饋的電子系統。 他們投入了很多錢，帶人去美國培訓，總的來說，他們投入得很充分。 有一次，在訓練結束後的談話中，一位經理對下屬說：「這個想法不錯，看起來可行。 我自己不會給你電子反饋，但你可以把它給你的員工並要求他們提供。” 就這樣，沒有什麼可以進一步實施了。 當然，這個想法最終沒有結果。
來源： www.habr.com