在項目中每個人都有相應的角色，應該承擔一定的職責。本文就項目中經常發生的職責的錯位與越位進行舉例說明。

      簡單說來，職責有廣度和深度兩個方面。例如，一個從事代碼編寫的程序員職責的廣度局限於寫代碼、單元測試等，但不應該包括系統架構設計、測試計划制定；此職責的深度就是寫出好的代碼（易懂、易改、Bug少等）。

      本文中的職責錯位主要是指沒有達到職責要求的廣度和深度，越位是指做了職責范圍外的事情。

      1、今天到現在都是TMD什么事？！到現在連一行代碼都沒寫！——某項目經理說

      評論：在國內很多公司中項目經理其實就是高級程序員經常需要從事代碼編寫的工作，針對此情況項目經理職責廣度上包括代碼編寫。但是從此話中隱約能夠看出，該項目經理把代碼編寫作為項目經理的主要職責來考慮，那么就是錯位。因為，即使從事代碼編寫的項目經理的職責中代碼編寫不應該是主要。

      2、公司某位員工要走，從項目經理的直接上級到公司的最高領導都關心此事——某現象

      評論：如果該員工確實公司中的頂梁的那根柱子，那么這些領導來關心此事情有可原；如果這種事情是偶爾發生，那么也勉強能夠說的過去。如果不是這兩種情況且這種現象經常發生，那么領導們你們已經越位。也可能是該項目經理做的不好，需要他們來review這件事情，那么請下決心替換該項目經理；如果不是這種情況，那么請給項目經理管理他團隊的權利。

      3、公司最高領導對項目需求討論過細——某現象

      評論：如過項目足夠重要，需求足夠復雜，那么作為公司最高領導參與項目需求討論過程情有可原。但是，此事公司最高領導參與的方式是不是更多以需求評審會議的形式參與，這樣公司最高領導參與了需求的討論，另外也給負責提需求的人員足夠的空間。如果不是這樣，那么領導越位了。

       4、項目組中負責WEB前端開發的組長去問主要需求提出人員“這個功能要不要呢？”——某現象

       評論：這個問題對100個負責替需求的人員問一下的話，估計99.9的回答都是“要這個功能，為什么不要呢？！”，結果又增加了一個功能。首先該組長職責包括去需求的討論嗎，包括與需求提出人員直接溝通嗎，包括決定需求的取舍嗎。根據一般情況來說，以上幾個問題的回答是否定的，那么該組長就是越位。如果此時偶爾發生，那么說明該組長越位；如果經常發生說明項目經理沒有建立需求的提出、討論、評審、取舍的流程，說明項目經理職責的錯位。

      5、主要需求提出人員找到項目開發組中的某些人員直接就需求的問題進行溝通——某現象

      評論：此問題4類似，項目組內的人員不是說不能與需求提出人員進行直接溝通，如果發生直接溝通時更多的內容是就需求進行明確，而不應該包括需求的取舍。如果經常發生此事說明項目經理職責錯位。

     6、需求提出方與開發方的組員之間直接溝通較多較頻繁——某現象

     評論：作為兩個方面，每個方面都應該有個接口人，統一負責本方與另外一方的溝通；如果雙方成員互相之間直接溝通較多，較頻繁，那么很多問題就無法控制。比如需求方A人員與B人員可能就某同一問題作出不同解釋，那么開發人員可能對同一問題采用不同的做法。此事說明項目經理職責錯位。

      7、過多參與編寫代碼——某現象

      評論：正像問題1所說，項目經理可能需要參與代碼的編寫，但是這絕對不應該作為項目經理的主要職責。同時，如果項目經理的上級也直接從事代碼編寫，甚至從事數據庫設計、開發任務分配、需求的討論、開發計划的制定，那么請問項目經理做什么？！嚴重的職責越位！

      8、會議內容過細——某現象

      評論：如果會議是技術會議或者是項目中下層人員參加的會議，那么會議內容較細則無可厚非。但是如果參與的人員層級很高，那么內容過細，那么則說明高層的職責錯位，因為這么細的內容他沒有必要參與，結果卻參與了。

      總結：項目中中下層人員經常發生的現象是職責錯位，項目經理以及高層人員主要發生的是越位以及錯位。