技術團隊堅持的總則-對錯原則(上)

工做了這麼長時間，對一些項目管理方面的見解和經驗抽出時間總結下，今天就開一個系列，談談如何一點一滴的改善咱們認爲難以駕馭或處理的問題。

誠如咱們作技術，作面向對象編程同樣。其實作任何事情或任何行業都有一個基本原則或準則，這就至關於一個最基本的底限，若是這個最基本的原則都遵照不了，就不用談去作任何事情或者作了多久的事情，只能說你的工做還處於一片混沌中，就算目前還沒出問題，可是早晚會出問題。跟咱們作面向對象程序的設計同樣，遵照最基本的原則「開閉原則」，若是你用面向對象的語言，而不遵照這樣的原則，就是個人程序對擴展關閉，意料之中的事情或變化任意修改原有的架構(或者不能稱之爲架構和設計)，長此以往原有的東西恐怕會變得沒法維護和運行，最後不得不廢棄掉原有的東西，而從新來一遍，可是新的東西可能還會陷入原有的循環。

引用他山之石，我今天就來談談項目管理中的對錯原則。

何爲對？何爲錯？若是一個團隊連對「對錯」的理解都沒有達到一致的共識，或者你們自顧自的工做處於鬆散狀態。那麼請注意了，不管如今大家多麼忙，手頭上的事多麼多，請先放下這些事情，先一塊兒坐下來各自談談本身對工做中對錯的理解，他人或者團隊的管理者一塊兒對全部人提出的發生的對錯的事情達成一致的結果，必定要把你們達成一致的東西記錄一個地方，你們一塊兒去遵照，不論是團隊的普通成員仍是管理者。

具體的「對錯原則」是什麼？其實就是---對的保留，每一個人都要按對的作，按對的方式去思考和處理問題；錯的摒棄，之後堅定不要再發生，或者不能按錯誤的方式處理問題和思考問題。

咱們能夠想想，假如一個團隊裏或者我的明明知道本身或別人作事的方式是錯的，不去糾正，錯誤之風氾濫，後果是什麼？只能是好的東西愈來愈少，錯誤的東西愈來愈多！

例子：

 

公司實行彈性工做制，正常上下班時間早晨9點-下午18點，因爲團隊實行彈性工做制，最晚能夠10點上班，19點下班。公司制定此規定的初衷確定是好的。

團隊裏6我的，A、B、C、D、E、F。

早晨A(家住的比較近，喜歡早到公司早把事情解決)、C君9點到公司了打開電腦，一看昨天開會時訂的需求有個細節必須和B君(家住的稍微遠點，路上可能會堵車)討論，不然今天的工做就被blocking住了。可是因爲彈性工做制嘛，B君家住得又比較遠，B通常又快10點的時候才能到公司。A只能先放下手頭的工做，找點其餘的於如今工做或其餘的事情去作了，只能等到B來了以後才能一塊兒討論，而後繼續今天的工做。

B君呢，因爲一來公司以後就和A君討論需求，需求和流程弄清以後，A就去開發本身負責的模塊。B也去忙本身的事情了，B忙了個昏天黑地，忽然間有個技術問題本身不是特別清楚理解的比較淺，可是本身的模塊中須要更加深刻的使用，可是貌似C對着塊很是熟悉，一擡頭髮現辦公室裏就剩下本身和E了，一問C和其餘人呢？E答道：如今都18點15了，其餘人早下班走了。

B嘆了口氣，看來得本身解決了。B從網上搜了好多例子，看得雲裏霧裏的，搞到了8點左右，一看錶得趕忙回家了，只能明天讓C看看本身到底弄得對不對。

D君是團隊的經理，通過一段時間的觀察，每週你們的集體討論，發現了諸如此類和那類的問題。D提出咱們你們工做日的9：45到公司，18：45下班，這樣你們的工做都處於一個同步狀態，有問題也好找到人及時溝通。你們對此達成了共識。

這個例子說明了一個簡單的問題：好的東西不規範利用，也會變成壞的東西。表面開來整個團隊因爲沒有一個總體的上下班時間點的共識，可能會形成團隊時間上的浪費，從而可能致使項目延期。

 

上面的例子看起來小事一樁，可是從小事看出你們因爲沒有一個共識形成了團隊資源的浪費，最後你們達成了共識，在最大程度上既沒破壞公司的制度也知足了每一個人的利益，而且好好的利用了團隊的資源沒有形成任何浪費。