知識型工作者只有讓他們感到被尊重，被認可才能激發出他們的工作熱情。制造業工廠監工式的管理方法，絕對量化的考核指標在知識型團隊管理中將會失效，
這是管理人員面臨的挑戰，德魯克也在《卓有成效的管理者》中對管理者和這種監工做了明確區分，其中的觀點是監工是上司，但不是管理者。
一個抱著積極、認真負責，打拼事業心態的員工做事的有效產出和機械完成任務的人員的有效產出是多么的不對等，這里不需要再列舉各類研究結果。尊重是激勵文化構建的基石，如果沒有尊重，激勵就是空中樓閣亦或是短暫的激情。本篇筆記重點談談在項目管理過程中對如何給予員工足夠的尊重。
1、項目的意義
成就感是讓團隊努力向前的最好激勵方案，任何項目的成立都是有意義的，如果能夠讓整個項目團隊時刻清晰的認識到自己是再做一件對部門、乃至對公司意義重大的事，則往往能夠煥發出團隊很強的戰斗力。受到關注就會給人被看重感，人就感覺到要對事情付更多的責任。
推薦策略：
1）項目啟動時，高層領導進行動員，宣傳項目意義
2）項目中期，規劃負責人/項目經理要能定期發出一些市場人員/客戶對項目的期望
3）項目結束后，高層領導要能夠反饋項目獲得的成績
2、項目時間估算
我個人比較推崇的估算方法是自下向上的估算（具體可以上篇文章：時間估算的三步曲），自下向上的估算能夠給予項目組員一定的發言權及主人翁感，并且能夠調動大家責任心，通常大家愿意為自己的決定負責，但是如果是領導直接壓下來的任務尤其比較緊急時，通常有些抵觸。當然在自下向上的估算中，要有專家進行指導和把關，包括估算漏掉的哪些事情，項目組內例行需要消耗的時間等，并且針對”獅子大開口“的時間需要進行討論，達成一致。
在這種估算方法做出的項目計劃下，如果項目最后出現了問題，盡管項目經理要承擔直接責任，但是項目團隊成員通常會比較自主的愿意與團隊共度難關。因為決策是大家一起制定出來的。
推薦策略：盡量使用自下向上+專家指導的方法進行估算，如果有人員到位或者估算周期的有限制，至少要保證關鍵人員的參與，而慎用自上向下的估算方法.
3、善用加班文化
IT公司加班是件很自然的事情，如果哪家公司沒有加班情況，反而會讓人感覺不正常。做為項目經理應該首先理解，加班雖然是IT公司的普遍現象，但是確實是組員為了項目做出了額外的奉獻，他們犧牲與家人團聚的時間，犧牲了休息時間，甚至影響了健康。這種行為值得我們尊重，我們要小心使用這項權力。
1）不要動不動就拋出一句“這個今天搞不定，就打地鋪解決”等，這種言論是對員工額外奉獻的一個嚴重的漠視，而且帶著很強的個人意愿
2）時時保證項目的進展的透明性，可以通過周會，日報的形式在團隊中發布。當遇到趕工時，跟當事人講解當前團隊面臨的困難，總之，加班是個艱難的決定，是為了整個團隊的績效，不是項目經理的個人意愿
3）任何加班時項目經理都應該盡量身先士卒帶隊
4）在一些公共場合，尤其有上級領導在時，公開表揚那些為團隊做出很多額外貢獻的人
5）績效考核肯定以結果為導向，不能以加班多少論英雄，但要有其他措施安慰最辛苦的人
推薦策略：加班是一種奉獻精神，我們要小心使用，認真對待。不能簡單的當做管理者的權力，輕言肆用，否則久之必招其離心。
4、開放溝通的團隊氛圍
人都希望自己能夠有發言權，能夠對關心的事情產生影響。上至國家領導人的選舉，下至日常的工作生活。如果發言權被長期壓制，就會產生壓抑和叛逆的心理。因此構建一個具有開放溝通的團隊氛圍則顯得很重要。而往往言路開明后，項目經理總是能在一些討論中，得到很多比預期更好的解決問題的方案。一個強權的管理者，容易獲得一定程度上的執行力，但是容易被自己的盲點擊敗。而一個開明的管理者，往往能使用集體智慧，獲得跟隨者，更容易產生威望。
推薦策略：
1）項目沙盤等關鍵策略制定時，要全體項目參與討論
2）項目經理鼓勵大家發現問題，提問問題，對于好的措施，能夠采納執行
5、責任到戶 VS 大鍋飯
從頭到尾的責任到戶制應該是最理想的工作分配方式了，在這種分配方式下，團隊成員有一塊自己土地，通常愿意花更多的時間與精力去耕耘（例如：某個全新的模塊），如果這個模塊又是他一直想嘗試的方面，那將會更加完美，我們有理由相信他將會在這里充滿了激情。
然而世界上總沒有十全十美的事情及百分百通用的方案，盡管責任到戶制如此之好，但是在某些項目上我們達成不了這樣的期望。
我所親身經歷過的兩個版本就遇到了這樣的狀況。兩個版本的共性是：在一個很大的系統上做覆蓋面很大的，很多小點的修改（例如：更換所有UI系統），但是基于老系統的復雜性及歷史問題，項目在中會遇到很多bug，各種各樣，在bug沒有查到原因之前并不好確定這個問題誰改動引發或是誰的責任，這種情況下責任到戶制會出現失效。在面對系統這么多的bug時，項目經理很容易想到一種方法：“那就是給大家分配bug數，下指標，每天每人要解決3-4bug等”。兩次項目經歷中，項目經理確實都想到了這種方法，區別是前者實施了，后者被我阻止了。原因如下：
1）團隊組員容易產生不被尊重感，被當成解決問題的機器
2）團隊之間的協作會發生困難，而且過度強調這項指標，例如誰每天不修改完這個bug數，就要加班到10：00之類的，會導致部分組員開始取巧，每天爭搶容易處理的bug
3）沒法發揮人的主動性，將團隊目標和個人目標相背離
這種情況下大鍋飯的機制似乎更合適一些，如果團隊沒有達成目標則需要一起想辦法或加班解決，而不是將這人歸咎個某個人。
推薦策略：在正常項目中盡量使用責任到戶制，而對于一些特殊項目，則選用大鍋飯制，沒有一成不變的方案，具體情況具體變通。
相關鏈接：
項目實戰筆記之一：高效會議的組織方法
項目實戰筆記之二：風險管理
項目實戰筆記之三：時間估算的三步曲