本章的内容相對而言較為簡單，大部分開發人員在大部分時候都不會接觸也不會關心。但是對于項目經理、制作人以及高管、老闆而言卻非常重要，因為它決定項目的進展方向和形式，甚至決定能否項目能否成功。
任何項目的開展都會受到當時所處的環境影響，遊戲開發也不例外。這些影響有些是好的方面，有些是不好的方面。作為項目經理，首要的任務就是能盡可能多的找出這些因素，然後登記在冊，以供後續的開發工程中随時查閱，以及及時解決和規避即将到來的問題。
這些因素主要來源兩大方面，事業環境因素群組織過程資産。
（項目影響）
1 事業環境因素
事業環境因素源于項目外部（往往是企業外部）的環境，它可能會對整個企業、項目組産生關鍵影響。一般來說項目團隊是無法控制事業環境因素的。它們會對項目産生各種限制、影響、或者指令型的條件。
具體表現為很多方面，比如：
- 市場條件：比如，你想在國内市場做MOBA類的手遊，那麼你得問問王者榮耀同不同意。你得知道MOBA類型遊戲的市場佔有率，近期乃至未來一段時間的市場走向，自己的競争優勢，以及最重要的商業模式。
- 法律限制：也很好了解，10年做棋牌遊戲和18年做棋牌遊戲就有本質的差別。再比如，防沉迷、實名認證、健康忠告、版署版号、軟著等等。
- 社會和文化影響 :這一般會涉及遊戲發行地區的文化。有很多東西是當地禁止觸碰的内容，比如國内的領土、政治；美國的種族；中東的宗教等等。
- 财務：老闆能給你支援多少錢進行項目研發。它會決定你的項目規模和工期。而規模和工期又會進一步限定遊戲的玩法和題材。
- 實體或者地理因素：大部分的遊戲公司都開在發達的一級城市，因為資源和人才擷取容易。
除了這些因素之外，還有很多很多的因素制約着項目的開發，比如内部賽馬機制（騰訊）、比如商業資料庫，學術研究、政府或者行業标準等等各種外部因素。
除了這些外部條件之外，項目組内還可能存在一些内部因素，比如：組織文化、結構和管理水準（典型的就是上司人的風格）；資訊技術軟體（DEVOPS 研發流水線）；資源可用性（一般是指人力資源）；員工的個人能力、項目能獲得的技術設施（比如，電腦組態、權限）等等。
這裡面，比較難以了解的可能是資源可用性。這個我們放在後面組織結構裡面解釋。
2 組織過程資産
組織過程資産源于企業内部，可能來自企業自身、項目本身、其他項目或它們之間的組合。它主要執行該組織特有并且正在使用的計劃、過程、政策、程式以及知識庫，這些内容會本質的影響對具體項目的管理方式。任何項目的成員都可以對組織過程資産進行必要的更新和增補。
這些官話要怎麼翻譯的簡單易懂呢？其實就是，你現在項目正在使用的習慣，開發計劃，人員之間互相配合的方式，以及在過往過程中積累的經驗，教訓、踩過的坑，噴過的人，打過的架，鬧過的沖突都是組織過程資産。
它甚至不止是目前正在用的，也可以是以前項目遇見過的，使用過的，解決過的都可以當做組織資産。
如果細分的話，它大概可以分為：
- 工件、實踐或者知識。
- 經驗教訓和曆史資訊。
- 完成的進度計劃、風險資料和掙值資料。
這裡比較難了解的名詞叫“掙值”。這個大家可以先忽略，後面的章節會有對此專門的闡述。現在粗略的可以了解為判定項目實際進度和預期進度之間偏差的一種資料。
除了上述的類别之外，它還包括 過程、政策和程式的類别，大緻為：
- 指南和标準（比如項目開發的邊界任務，導表究竟給策劃還是程式，美術資源的規格檢查交給程式還是美術？）
- 模闆 （這個很好了解，就是項目裡統一使用的各種文檔、報表等模闆）
- 供應商清單和合同類型（美術或者音樂外包的執行方式、導量、發行的分成）
- 變更控制程式、組織對溝通的要求
這裡要重點講一下第四條，變更控制程式、組織對溝通的要求。我認為這點要遠遠重要于其他三點。
前一章節，我們講過了瀑布類型的開發方式，它是一種預測型的開發方式。這必然會伴随着預測失敗，中途調整需求的情況。而變更控制程式就定義了發生這些情況之後要如何處理。涉及的人、事以及解決流程。這個在後面的章節會更進一步，更詳細的講解。
組織對溝通的要求，這個内容也很複雜。PMP裡的十大知識領域中有一項就是溝通。這會專門開一個章節來講述項目的溝通。但總的原則應該是當面溝通>視訊>音頻/電話>群>郵件>公告/論壇。
當然，除此之外，還有一個類别叫組織知識庫，它包括：
- 配置管理知識庫（遊戲開發裡每個功能表的配置情況，以及其他）
- 财務資料庫（跟一般人沒關系，項目經理、制作人和公司對賬）
- 測量名額資料庫 （比如，伺服器能夠承載多少人，導量的轉化率，用戶端同屏顯示多少人等等能量化的名額）
- 經驗教訓知識庫
- 以往項目的檔案
這裡面最重要也是最常用的應該就是後兩項了。經驗教訓會記錄項目碰到的每一個問題，以及解決人員和方式。當再次碰到類似問題的時候，可以快速查閱并制定解決方案。當這個項目終止之後，它會變成最後一項，以往項目的檔案。
3 組織結構
除了以上兩個因素之外，組織結構也會大幅度影響項目的開發方式和進度。
組織結構并非是大多數公司裡的部門架構，部門架構屬于項目資源的範疇，這在後面項目資源的領域會重點介紹。組織結構可以了解為，項目經理在組織内的職責、終責和職權的配置設定情況。
明确的組織結構有助于項目經理有效的行使權力、影響力、能力、上司力以及政治能力來成功完成項目。從項目經理的職權強弱來分類，從弱到強分别為：
- 職能型（集中式）
- 弱矩陣
- 平衡矩陣
- 強矩陣
- 項目型
這裡我們着重講解兩個極端，即職能型和項目型。其他三個在中間插值了解就行。
1 職能型
（職能型項目經理）
這是最弱的項目經理，一般是由聯絡員兼任。也可以了解為它是一個兼職的項目經理。這裡可以舉很多例子來闡述，但我相信小夥伴都很聰明1個例子就能明白。
我們這個系列的名字叫《人人都是項目經理》，它不是一種噱頭，而是任何人都有可能在某一個時刻擔任項目經理的職責。當然前提是你要搞清楚項目經理究竟是一個什麼樣的角色。這個内容我們會在下一章節講述。
回到剛才的内容上來，我們看看職能型的項目經理怎麼工作。
A是用戶端人員，在做某個任務的時候，發現需要額外的伺服器資料支援。他報告了用戶端主程，然後用戶端主程了解分析了需求之後，聯系了伺服器主程，伺服器主程安排了B跟A對接，完成該任務。
對應上面的圖可以看到，職員A此時是一個兼職的項目經理，由他發起，最終解決了問題。而用戶端主程和伺服器主程分别對應了職能經理A和職能經理B。
這裡大家可以發現，項目經理的職權是遠遠小于職能經理的。是以人人都是項目經理系列，A自己都沒發現自己當了一次項目經理。
總結一下，職能型的特點：
- 是兼職的項目經理
- 職業路徑清晰，但橫向聯系薄弱
2 項目型
（項目型項目經理）
這是最強的項目經理模式，大多數的遊戲開發都采用這種模式。項目經理對于項目事物擁有絕對的控制和話語權。能夠決定人、事、物的流程和走向。所有的人員決策資訊都彙總至項目經理，并由他最終拍闆。
很多較小的項目不會常設項目經理職位，一般由制作人+PA共同替代。制作人決策，PA監督。
這裡也總結下項目型的特點：
- 全職的項目經理
- 控制度高
- 重複配置
- 無家可歸
這裡需要解釋一下後兩個特點的含義。
重複配置是指每個項目都需要一個全職的項目經理，從人力資源上來說就需要對不同的項目重複配置項目經理這個職位。但開發過遊戲的小夥伴應該知道，這是必不可少的，非常少見一個項目經理管理多個項目，但是多個項目經理管理同一個項目卻比較常見，尤其是大型項目，一個項目經理完全配不過來。從管理學角度來說，每個人管理的極限是6-10個人，是以正常的遊戲開發部門，項目經理協調主程（們）、主策、主美、主測試等職能經理，共同完成對項目的管理工作。
無家可歸的含義是指，項目一旦終結，項目就需要解散，項目經理和成員就會在這一階段失去目标，變成“無家可歸”。當然實際上，肯定不會項目終結就被解聘變成真正的無家可歸，大都會投入下一個項目的工作中。
除了以上2個極端之外，其餘還有3個矩陣型的組織結構。
- 弱矩陣型
- 平很矩陣型
- 強矩陣型
這三個從弱到強指的是項目經理的職權。隻有最後一個強矩陣會出現特殊的“項目經理的項目經理”。
每種方式都有好處和壞處，矩陣的好處就是資源使用率高，有利于跨部門協作。而壞處就是，上司太多，管理難度大，資源争奪厲害。
這裡再舉個例子，比如公司有一個美術中心，那麼美術中心的老大就是職能經理。公司開了3個遊戲項目，每個項目都有一個項目經理，這些項目經理都要争奪對美術中心人力資源的優先權。而對于處在該美術中心的個人來說，他在某個或者某段時期可能需要面對多個“上司”的問詢和關照。
當然有人可能會說，統一提需求給美術中心老大不就行了嗎？當然可以，那就要看你的組織結構是屬于矩陣型的哪一種了。
最後附上一張項目特征圖。
4 PMO（項目管理辦公室）
上圖出現了一個奇怪的名詞——PMO。那麼，這最後一部分我們講講PMO是什麼。
把縮寫展開就是項目管理辦公室。這在很多公司都是沒有的職能部門，隻有公司到了一定的量級，項目開展多到一定程度，并且高層有相關管理的意識，才會出現這個組織部門。
它不參與具體的項目開發，但是會指導項目經理如何去統籌、管理項目。并且從更高的次元去提供資源、方法論、工具和技術共享等高層級的項目活動。
PMO根據對項目的強硬程度可以分為以下幾種類型：
- 支援型 基本不幹涉項目開發，從支援的角度出發，你可以把它當做是一個顧問，或者資源庫。
- 控制性 支援+要求服從 即會制定項目管理架構或者方法論，并要求使用特定的模闆、格式和工具。當項目遇到和PMO釋出的規則想抵觸的時候，要求項目整改以符合PMO的規則。即它是一個中型的控制，不會幹涉具體項目做法，但是要受限于一定的條件或者架構。
- 指令性 指令性的PMP會直接派遣項目經理管理和控制項目。注意 PMO組織本身并不會控制項目，控制項目的仍然是項目經理，隻是改項目經理需補單要遵從控制型的架構，還需要想PMO報告。
我遇到過的大部分PMO始于控制型，即基本不幹涉項目内容，滿足PMO規定的要求即可。但是在一些攻堅的項目或者重點項目中，還是有可能轉為指令型的。
項目管理辦公室會承擔整個組織範圍内的職責，在戰略支援、調整和創造組織價值方面發揮重要的作用。PMO從組織戰略項目中擷取資料和資訊，然後進行分析、評估如何實作更進階别的戰略目标。
另外PMO可以一次支援很多個項目，并且這些項目之間的關聯性沒有硬性需求，即可相關，也可不相關。
最後做個PMO職能的彙總：
- 管理共享資源，識别和制訂最佳實踐和标準。（管理功能）
- 通過項目審計，監督對标準的遵守程度。（監督功能）
- 制訂和管理政策、程式、模闆，提供指導和教育訓練。（指導和教育訓練功能）
- 協調“跨項目”的溝通。（協調功能）
項目運作環境旨在理順将要開始的項目内在外在的各種關系，它是項目的前置性的、偵查性的過程。如果在前期的梳理過程中發現無法按照預期的過程和收益走下去，那麼很可能會終止後面的工作。梳理的内容很多時候會變成商業論證的一部分，也有可能成為項目章程的一部分。
這些等我們後面講述ITTO的時候，會詳細闡述。
下一個章節，我們介紹項目經理本身。