[轉譯]軟件團隊：培養使命感，而不是製造緊迫感

原文出處：Don’t create a sense of urgency, foster a sense of purpose.

試圖創造緊迫感的努力幾乎老是拔苗助長

我領導着軟件開發團隊。不可避免的會有人（CEO、股東、顧客）但願咱們能進度更快點兒。我常常會被問到-「你以爲團隊當前有強烈的緊迫感嗎？」，或者更直接的「你能讓團隊感受到更強的緊迫感嗎？」 更多的請求比較隱晦，但也換湯不換藥 - 「我真的但願能讓這個項目完成，但它尚未火力全開。你能再推動一把嗎？」

截至目前，對於他們全部的疑問個人回答都是 - 不。我不會試圖給團隊製造更強的緊迫感。你也不該該。緊迫感並非目的。試圖創造緊迫感反映的是個由來已久、關於匆忙和快速的悖論 — 這個悖論讓你以爲你若是並不老是忙着，那你已經落後了。

只要你不是天天24小時都在產品上工做（坦率說，哪怕你是），那你就很容易相信進度還能再快點兒。畢竟咱們都想要快。要作到事情永遠比已經完成的多，進度快一點可讓咱們早點完成；好像團隊只要再忙碌一點，咱們就不用面臨艱難的選擇。

那些有過拼命按時出門卻把鑰匙落在家裏的經歷的人都知道：匆忙常常拔苗助長。惶恐不安、狂亂的步伐更在乎結果而非過程當中的行動、這也致使了負面的後果。

欲速不達

理論上，專業的軟件工程師、設計師和產品經理會總指望提交專業質量的成果 - 並不肯走那種可能會損害其成果質量的捷徑。現實中，咱們都有愉快地工做、讓咱們的工做符合公司發展方向的主觀願望。可即使是最頂尖的團隊也沒法對壓力免疫。因而小事就開始堆積 - 沒時間修復的用戶體驗的小問題、測試覆蓋率降低、未能監測關鍵流程以及新功而產生的技術債務。

無從創新

匆忙且持續的壓力下降了咱們保持積極主動的能力。咱們不會多花20分鐘思考來理解設計意圖、避免浪費多日的工做。咱們沒法意識到一個瀏覽器插件自己是個徹底錯誤的方案，咱們應該中止在上面的投入。方案返工也須要時間，因此同意緊迫性的環境裏一般不鼓勵返工；可是就是那幾分鐘或者幾小時，能夠節省下後來成周、成月的時間。

微觀管理

試圖製造緊迫感須要付出額外的管理成本。員工來的早嗎？他們待的晚嗎？工做成果夠嗎？但對於領導團隊而言，有更多的大且深刻的問題值得他們關注。並且微觀管理會侵蝕團隊的信任。當心不要過快地釋放這種觀點 - 即使你不會陷入微觀管理，你可能會錯誤的鼓勵團隊中的經理們去這麼作。

快速失效

里程碑所帶來的生硬的緊迫感會快速的失效 - 在工做過程當中、職業生涯中都是如此。對於有經驗的軟件工程師和設計師（正是你最須要他們才智的那幫人）而言，這會讓你顯得挺業餘，而且不會帶來長期的忠誠度。

信息倒置

當關於緊迫性的溝通變成了最高優先級、更重要信息，其餘諸如咱們爲什要討論這個項目、以及誰會由於這個項目受益等 - 這些會帶來更大價值的信息 - 就被淹沒了。

使命感

讓咱們扔掉緊迫感去尋求使命感吧。使命感是一種對努力的目標的深入理解，同時也是一種傾注時間和能量的渴求，這個使命因咱們想對世界產生的影響而共鳴。

使命感是對咱們事業的沉浸，同時也推進着咱們的行動。使命感讓咱們更快更聰明的奔向共同的目標，也意味着良好的判斷：由於咱們都理解了 - 對於咱們共同創造的事業，咱們的行動會帶來哪些短時間和長期的影響。

強烈的使命感表現出來，能夠是當一個軟件工程師看到一個潛在的顧客與某個工做流爭吵的時候，願意留下來很晚讓這個工做流變得簡單一點；也能夠是一個設計師花費了整個週末而作幾回計劃外的迭代，只因他們沉浸於手上的問題，而且但願給出更好的方案。

結果就是，當你中止了製造緊迫感，潛伏在你團隊中的激情和動機得以釋放，讓正確的事情以正確的步調來完成。

營造使命感與製造緊迫感是不一樣的。一個有高度使命感的團隊看起來很像一個有高度緊迫感的團隊。產出很是高，成員很是投入。但其中最主要的區別在於你做爲領導者所作的工做差異很大。

製造緊迫感就是關於截止時間、嘮叨和催促進度。培養使命感則不一樣，它是共同的努力，而且須要堅信，你的團隊成員會把他們的使命感轉化爲持續增長的效率。

你做爲團隊領導者的主要工做，就是僱傭合適的團隊成員，而且花時間激發他們的使命感。幫助團隊成員理解他們工做的影響，速度就會隨之而來。

---

後記：任何觀點都有它對應的時間和空間上的上下文。個人觀點不是說咱們能承受時間上的浪費。管理（並最終放棄）跟不上合理進度的員工是每一個公司都須要發展的能力。絕大多數合理的組織須要可預測性，而且有充分的理由設定深思熟慮的截止時間。並且每一個公司都但願能快速的發展。關鍵是不要讓緊迫感自己成了一個目標。