項目管理那些事兒

        項目管理首相要講的就是管理二字，其實更多的PM我所經曆和接觸的都還沒有脫離技術圈子，于是産生了所謂的項目指導，或者本身對技術沒有追求或者缺乏技術經曆的，更應該被稱為項目委派，前者細緻到已經提開發人員想好了技術細節，後者則是搞懂需求後一股腦的告訴開發人員，至于實作細節—放羊。

        當然，也還有一些人過于執着于一些形式化的東西，聽說極限程式設計很好，于是極力按照細節行為去做雲雲。我抛出問題，絕沒有諷刺的意思，其實出現上述問題都很正常，有些是邁向務實正确的大道上必須經曆的路程。好的，有志于做管理的同志們，首先要回答自己這個問題：做項目管理到底是為了什麼？

        控制項目，架構，人員安排，跟蹤…

        項目管理其實就是一個目的：在項目成功傳遞的前提下，控制成本。說白了，就是錢。很多對于技術和管理有追求的人可能會有些反應不過來，很正常，大家都是做技術的，總習慣将自己的圈子看的很重要。做項目的載體是公司，公司的目的是什麼？賺錢，你能通過項目管理做好項目，控制好成本你就能給公司賺錢。

         是以說做好項目管理首先你要跳出技術圈子，站在比項目本身還高的角度來了解問題，這個管理才算你半隻腳買入了門檻。懂得了這個道理，你們就會正确的了解，所謂的OOD，OOA其實不是什麼技術的升華，其實是成本的要求使然，期限程式設計雲雲其實都是為了通過靈活以及反複測試機制降低項目的風險，提高傳遞品質進而賺到錢。是以了解開發模式的核心在于了解這種模式解決的問題是什麼，基于此再來使用，基于國情基于項目實際情況加以删減和修改，做IT的人很容易被人識别出來，因為他們的圈子更多的積聚在技術上面，這一點可以說做技術的一種局限。

         回到操作層面，我們到底要管理什麼呢？我的角度，三方面：客戶，項目，開發人員。做管理是一個接口崗位，其上是客戶，提出需求的人，其下是開發人員，客戶的需求如何貫徹到開發人員取決于你這個項目經理的分析和排程。對于客戶，首先不能帶有感情色彩，有的人鄙視，有的人敬畏，其實他們不過是拿錢免災的人，對于他們應該采取的政策就是打拉結合。所謂打，就是對于他提出來的超越系統之初定義的需求一定要回絕堅決，最好找出足夠充足的理由，比如邏輯上的不通，拉長工期導緻項目品質問題雲雲，或者和他們談二期。拉就是盡量和他們維持一種比較友好的關系，說實在的，小型民企不知道，中大型的民企和國企的接口人，你想要和他們維系一種良好的關系，要麼你身上擁有者一種江湖的匪氣兼具一種睿智，要麼就是在某些領域專業的讓他五體投地，每個人都有自己的氣質，不要生搬硬套，我見過各種類型成功的項目經理。

        項目經理需要分析，需要思考。作為高層不需要做實際細節工作，但是卻要求在高屋建瓴提出各種架構性的東西作為下層人員的指導，這種架構性的東西是真正開創性的東西，将一些抽象的，零散的東西整理歸納層可實作的，系統性的東西。做系統項目，首先是要有一個系統性的思想作為基礎，開發出來才會系統。客戶說希望點一個按鈕出一個報表，你要抽象出來報表生成功能，這個生成功能相比對則是計算，資料擷取，計算需要規則，擷取需要資料源等等。項目經理自己首先要把這些捋順了，對于下面才有指引。

        從客戶，需要一個項目分析作為過渡，到項目本身的管理，管理是一個很泛泛的概念，大而空洞的說教，但是也是包羅萬象，看你的體會了。IT項目管理有幾個主線一定要有，并且形成文檔：

1.       計劃。一個詳細的計劃，所謂詳細我認為應該細化到天，一個以原子需求為機關的計劃，計劃是讓人遵循的，但是不是死的，而是不斷調整的，有新功能，新任務，添加，調整，大家至少要知道當下我們的目标怎麼樣，而且作為上司一定要有一個重視計劃的意識，這種意識要讓下屬深刻的體會到。我從來都是反對團隊加班，每個人負責自己的任務，能完成為什麼要加班，沒能完成任務，在配置設定時沒有提出異議，就需要加班，經理安排任務要考量，成員接受任務也要評估。

2.       裡程碑。計劃是讓大家知道任務量，裡程碑則要求大家知道執行任務的階段性時間點，裡程碑之前的任務可以拖延，但是到了裡程碑這一天，必須要完成指定任務，如果提前沒有提出異議，那麼責任就在完成人。

3.       項目人員架構/角色。項目比較忌諱扁平式，上面一個PM下面一群PG，這說明什麼，職責都在PM這邊，要麼PM管的真的很多，要麼PM實際沒管什麼，這兩種結果都可怕。至少一個人負責技術，技術的解決方案，核心代碼；至少一個人負責共通代碼，他一定要十分熟悉共通代碼，當有人想要向共同檔案比如Helper檔案添加方法時，必須要通過這個人，确定沒有類似的方法再添加，一定要控制住代碼的體積，減少備援，項目的混亂多半源于備援。一個人控制存儲過程，這個人需要非常熟悉了解資料庫中的存儲過程，添加過程要加以指導，否則SP的龐大和實作方式的不經濟也是項目糜爛的重要原因。至少一個人負責頁面UI。可能項目的類型和要求不一樣，核心分内容和子產品也各有不同，大家根據自己的情況進行設定，總之一定要有人負責重要部分，有角色來承擔責任，否則放羊，項目越到後來越可怕（短期項目可能還好說）。

        上述三點是必須開會指定的，有權才有責，清晰才有遵守，如此這個項目的管理架構算是搭建起來，所謂架構，就是大家都去遵循的準則，架構内部提供某種運作機制，對于遵循的行為産生結果，項目架構如此，管理架構亦是如此。

        管理另外一個方面就是開發，開發也要遵循一定的架構，首先就是技術架構，這個是硬架構，這個我就不多說了，那是架構師的事情，開發的軟架構就是“約定”，一些無法依靠架構來實作的，這裡我隻想強調一件事情，就是，一定要重視第一本程式，第一次功能實作。首先是頁面樣式，第一本做出來的是以後大家要去模仿的，某種類型功能的第一次實作也是大家要模仿的，一定要開評審，或者一定要和負責技術的人溝通好，設計好，什麼是項目的基礎，第一本程式就是基礎。

        項目是人幹的，那麼到了團隊成員這個層面，這裡對于團員我覺得關鍵要搞明白三個問題：

1.       什麼時候該做什麼事情。這一點通過訂立計劃和裡程碑可以實作；

2.       怎麼去幹。我們建立的責任人制度就是要讓一些人負責指導和規範的職責讓他們知道項目的功能需要怎麼來開發；

3.       為什麼要這麼幹。這一點就有點培養人的意思，大家做一個項目一定是要有所獲得，而且要知道為什麼，通常都是需要交流，組織一些教育訓練或者座談，還有稽核流程，這些都可以将資訊在團隊中流傳。

        洋洋灑灑的寫了一些自己的經驗心得，有些可能說的有些抽象，知之者一聽及明，不知者可能還需要一些經曆，不過這些都是成長的過程，很多的問題我是在探索之中，歡迎大家互相讨論，抛開理論的焦灼，一些實際問題更有意義。