項目管理演進：初創公司與企業

初創公司玩撲克，大公司下棋。

谷歌開發者倡導者 Don Dodge 的這句話概括了在初創公司和企業中擔任項目經理的區別。

初創公司正在玩概率遊戲。 與撲克玩家一樣，最好的玩家總是贏，但有時會輸給業餘玩家。 在啟動項目管理中，您需要出色的執行力，但事實是，即使是最好的企業家也可能失敗。 與國際象棋一樣，企業項目管理系統需要更具戰略性，提前兩步計劃，並承擔更少的風險。

不全是黑白的

在我們深入探討這個話題之前，有一個警告是，有各種各樣的公司。 您可以再將擁有 100 名員工的公司稱為初創公司嗎？ 如果它增長到 200 或 300 名員工怎麼辦？ 有時 Uber 在媒體上仍被稱為初創公司，然而，Uber 現在擁有 12,000 名員工。 另一個區別是，由本科生創辦的創業公司與由具有 20 多年專業經驗的連續創業者創辦的創業公司非常不同，這些創業者之前可能曾在該企業工作過，並將那裡的最佳實踐帶回了他們的創業公司。

因此，在一家 5 人同地辦公的初創公司和一家在世界各地設有辦事處的跨國公司之間存在許多案例。 雖然本文將主要關注兩個極端，但對所有這些都持保留態度，並批判性地思考這些要點是否適用於您的具體情況。

初創公司與企業

有了這個警告，讓我們嘗試定義兩個極端，為我們的討論奠定基礎。 就本文而言，初創公司的特徵是：

• 一個位於同一地點的團隊（約 1-50 名員工），您通常會知道所有同事的名字。
• 角色定義鬆散。
• 聯合創始人非常積極地做出大部分決定。
• 公司正在虧損，而且沒有很長的路要走——生存是一個主要問題。

另一方面，企業看起來像這樣：

• 多個部門和地點。
• 您只了解您的直接同事，並與其他部門的少數人互動。
• 每個人都有明確的職責和等級。
• 該公司可能是公開的。
• 盈利能力和短期生存可能不是問題。

啟動項目管理

項目經理≈產品經理

理論上，項目經理與產品經理的職責大不相同。 然而，在創業環境中，這兩個角色通常會交織在一起。 如果您是一家初創公司的項目經理，那麼您可能會承擔更多傳統上在企業中所做的工作之外的職責。

初創公司項目經理的機會

快速決策和巨大影響

在啟動項目管理中，很容易做出重要的決定，因為在流程、其他團隊、客戶等方面沒有太多的依賴關係。像僱用新同事、更改主頁、添加新功能或延長最後期限可能是一次會議或 Slack 談話。 這賦予了項目經理權力，並創造了一種自主感。

創業公司是嘗試您的想法並專業成長的好地方。 您可以試用朋友告訴您他們在他的公司使用的新項目管理工具。 從 Scrum 遷移到看板怎麼樣？ 首席執行官回答說，無論什麼使您交付速度更快。 您如何看待實現允許以自然語言查詢您的 Google Analytics 的新聊天機器人？ 你不需要開發人員，午餐時解釋你的 CTO。 在企業中，所有這些都將是由專門的項目經理管理的獨立、大而長的計劃。

事情做的很快

初創公司的開發生命週期比企業短得多。 你今天可能正在構思，下周有一些東西要投入生產。 遺留代碼不多，因此開發人員不會抱怨代碼庫需要重構，因此能夠快速交付結果。 這使您可以與客戶保持持續的反饋循環，並真正變得敏捷。

易於適應或轉動

相同的交付速度和無依賴性使初創團隊能夠迅速改變方向。 一個著名的例子是貝寶。 自作為“手機密碼學”解決方案推出以來的前 15 個月，Paypal 進行了 5 次轉型。 支付市場瞬息萬變，PayPal 能夠在競爭中勝過 eBay，後者正在開發自己的支付解決方案，稱為 Billpoint。 PayPal 的敏捷性使其能夠更好地吸引 eBay 買家和賣家，最終導致 eBay 收購了 Paypal。

流體過程

通常，對於初創公司內部人員的運作方式，並沒有太多嚴格的流程和程序。 很多事情都留給常識和內部談判。 這是上述幾點實際有效的主要原因之一，即您可以更快地做出決定，並且不需要無數次的簽字。 當然，這不可避免地是一種權衡，這會導致其他問題，我們將在本文後面看到。 然而，對於一家正在尋找適合產品市場並試圖在競爭中勝過資金更雄厚、規模更大的競爭對手的初創公司來說，這是一個合理的權衡取捨。

初創公司項目經理面臨的挑戰

職責未完全定義

流暢的流程可實現快速直觀的決策。 當事情進展順利時，這是一帆風順的，然而，另一方面會導致錯誤和混亂的環境。 分解後，流程本質上是一個清單——需要採取哪些步驟才能實現結果。 流程通常是由於一些失敗而產生的，當同事開始互相指責沒有照顧好某件事時，公司開始創建一個流程，將決策簡化為明確定義的步驟，以降低此類問題發生在未來。

例如，新版本使客戶的網站崩潰。 公司裡的每個人都知道即將發布的消息，但沒有人通知客戶。 項目經理或大客戶經理是否應該聯繫客戶的開發團隊？ CTO 是否應該更加積極主動？ 經過激烈的討論，相關人員同意下一次特定員工將在發布前對特定行為負責，以確保不會再次發生這種情況。

這個例子是創業公司如何演變成公司的一個縮影。 隨著初創公司的複雜性與日俱增，人們會做出這樣的決定，並從日常運營中消除歧義。 然而，在達到這種狀態之前，通常會犯許多痛苦的錯誤。

議價能力弱

作為初創公司的項目經理，您更有可能參與外部談判。 聯合創始人可能會帶你參加後期的客戶會議，以代表技術或產品方面的宣傳。 在那次會議期間可能會出現很多問題和新要求，項目經理必須確保不會過早就可交付成果達成一致。 即使在會議期間，聯合創始人可能急於贏得潛在客戶並同意他們的條件，而沒有完全意識到新積壓項目的成本。 客戶可能會利用您的初創公司沒有長期跟踪記錄這一事實，讓您承諾超出您可以合理交付的範圍。

項目經理必須能夠反擊並要求更多時間與開發團隊一起評估新需求。 一旦您至少從團隊那裡獲得了粗略的估計，請將它們呈現給聯合創始人並進行討論，如果仍然有意義就同意交易的新條件。

捷徑造成遺留問題

在初創公司中，很容易處於恆定 MVP 模式。 作為項目經理，很容易推動開發團隊同意更緊迫的截止日期並為路線圖項目採取捷徑。 在聯合創始人不斷支持你的情況下，這似乎幾乎是必要的。 然而，俗話說得好——權力越大，責任越大。 如果你濫用這種權力，最終你的團隊將開始遇到遺留問題。 這並不意味著在未來的某個時候——您可能會在仍處於啟動模式時遇到這些問題。

例如，假設您的公司決定創建一個產品列表頁面。 它必須有多個過濾器來縮小結果範圍。 它還必須具有基於各種屬性的排序選項。 初始估計太大，您嘗試縮小所需的過濾器和排序選項。 最終，事實證明，大部分估計是整個系統 - 搜索並返回結果。 您問是否有任何方法可以更快地提供更簡單的版本。 一位開發人員建議使用按月訂閱的第三方解決方案。 其他開發人員談論依賴問題和遺留問題。 對您來說，這聽起來很完美，因為您可以更快地獲得 MVP，並且如果您決定放棄該項目，可以在以後取消訂閱。 只有在項目沒有報廢的情況下，Scrum Master 有機會重寫代碼時，他們才會同意使用第三方解決方案。

但現實情況是，除非 Scrum Master 在以後的 sprint 中真正提出技術債務任務並在時機成熟時為其辯護，否則該協議幾乎永遠不會實現。 如果列表頁面的初始反饋是積極的，項目經理的自然反應是開發附加功能，因為 MVP 只是一個測試。 6 個月後，您會發現添加新功能變得非常昂貴，但重構的成本更高，然後還有其他優先事項變得更加重要並掩蓋了最初的意圖。

誤報

在 IT 項目管理的情況下，當您的團隊開發了 MVP 並且您將最初的積極反饋作為產品與市場契合的證據時，就會出現誤報。 當您的利益相關者告訴您：“我已經向我們行業中最大的客戶推銷了我們的解決方案，他們說他們肯定會從我們這裡購買時，它甚至可能在此過程的早期發生。” 你開發它，然後他們實際上並沒有從你那裡購買它。

誤報是一個很大的挑戰，但有一種方法可以減輕它們。 Validately 的創始人 Steve Cohn 建議您應該驗證對解決方案的需求。 三個信號可以幫助你：

1. 甚至在您提供完整的解決方案之前，您的客戶是否願意花錢或投入資金？ 在交付解決方案之前獲得合同可能是您可以獲得的最佳驗證。
2. 您的客戶願意花時間與您一起開發解決方案嗎？ 時間就是金錢，每個人都有無窮無盡的積壓任務。 客戶越積極地與您一起找出需求，讓他的其他同事參與討論，徹底測試 MVP 並提供充足的反饋，您就越有可能走在正確的道路上。
3. 您的客戶願意利用他們的聲譽來提升您嗎？ 無論是在社交媒體上、在專業活動中還是以任何其他形式，當客戶推銷您時，他們都是在向您借用他們的聲譽，這證明了他們的真正興趣。

利益相關者管理

項目經理在初創公司中最重要的利益相關者通常是聯合創始人。 正如我們在機會部分看到的那樣，聯合創始人可以根據常識做出快速決策。 然而，問題在於，許多聯合創始人經常依靠自己的直覺做出決策。 對於在特定行業作為該領域的專業人士工作過並且現在決定創建一個 IT 解決方案來解決他們自己在工作中面臨的問題的聯合創始人來說尤其如此。

深入的市場知識對任何初創公司都非常有用，但是，在創建路線圖時不能僅僅依靠它。 大多數初創公司的願望是創建一個可以在國際範圍內擴展的解決方案。 即使同一市場上有多家公司，它們也不一定會以相同的方式解決問題。 聯合創始人可能非常了解他以前的公司是如何做事的，但這並不能轉化為了解其他公司，尤其是其他國家的公司如何解決同樣的挑戰。

聯合創始人往往堅持自己的信念，需要一個獨立的項目經理來平衡他們的觀點。 項目經理的工作是在產品發現的早期階段向聯合創始人宣傳數據驅動的決策制定和敏捷開發的重要性。

企業項目管理

項目經理≠產品經理

隨著初創公司成熟並成為大企業，隨著工作變得更加具體，不同職位的角色也越來越明確。 即使在企業中，也存在項目經理和產品經理重疊的情況。 但是，項目經理傾向於更多地關注項目的運營方面，而產品經理則負責執行。

項目管理辦公室（PMO）

隨著公司的發展，他們的項目組合也隨之增長。 新的項目經理加入並帶來新的項目管理工具和方法。 最初，事情變得有點混亂，需要一個項目管理辦公室 (PMO)。 PMO 關注項目管理生命週期，可以在整個公司範圍內傳播或實施最佳實踐。

作為企業的項目經理，您必須與 PMO 進行交互。 每個 PMO 都不同，但您可能面臨的事情包括：

• 填寫項目啟動和關閉的各種表格。
• 提交預算以供審查。
• 提供定期進度更新。
• 獲得里程碑或各種流程步驟的批准。

對於已經在進行大量計劃和跟踪的項目經理來說，許多 PMO 要求似乎是不必要的繁文縟節，尤其是當它開始減慢項目速度時。 雖然這種官僚作風可能會讓人感到沮喪，但積極主動的項目經理可以最大限度地減少開銷，甚至從 PMO 中提取項目的價值：

• 儘早讓 PMO 了解報告要求。 然後可以將這些與項目執行期間生產的材料相匹配，以節省時間。
• 成為流程冠軍。 向 PMO 提供有關如何更改流程以使項目經理的生活更輕鬆的反饋。 PMO 的主要目標之一是幫助產品經理高效工作。
• 當您的項目遇到問題時，請利用 PMO 尋求幫助。 PMO 對所有項目具有全公司範圍的視野，並且在處理項目執行過程中出現的各種問題或風險方面具有經驗。 利用他們的知識為您帶來優勢。

企業項目經理的機會

信譽

企業的穩定性和長遠規劃對客戶和合作夥伴來說是可信的。 想要與您的公司合作的人正在尋找良好的業績記錄——您能夠兌現您的承諾並在您的專業領域擁有豐富的經驗。 這是企業相對於初創公司的最大優勢之一。 它使尋找新客戶和合作夥伴變得更加容易。

這種信任使您能夠與客戶進行更多的整合。 作為技術供應商，您正在為您的客戶提供支持，反過來，他們可能會根據您的路線圖調整自己的路線圖，以便能夠盡快提供新功能。 這種關係對於初創公司來說很難實現，因為初創公司非常不穩定且難以信任。

更容易收集需求

與初創公司相比，企業在市場上的佔有率要大得多。 隨著公司的發展，工作變得越來越具體，越來越多的專業人士被聘用。 同時，為了保持願景，越來越多經驗豐富的高層管理人員加入公司。 所有這些人都帶來了巨大的市場洞察力，這對於項目經理來說很容易在收集用戶需求時訪問和利用。

這對於 PM 的個人發展也是一個很大的優勢。 當您需要影響企業內的其他利益相關者或確保您的項目在公司高層獲得足夠的關注時，擁有大量可供您使用的聯繫人可以幫助您利用他們。

可以在銷售、客戶管理或客戶支持團隊中找到另一組可以幫助您滿足用戶需求的同事。 在那里工作的人每天都與客戶接觸，可以為您提供很多關於用戶需求和挫折的反饋。 但是，請始終牢記此反饋來自的上下文。 例如，客戶支持團隊可能與使用您的產品的人打交道，而銷售人員和客戶經理可能與做出購買決定但實際上並未使用您的軟件的高級管理人員打交道。

建造或購買

創業公司無法獲得的機會是通過併購 (M&A) 實現增長。 2018 年全球併購交易數量已創歷史新高。 這一趨勢的很大一部分是大型交易，例如最近 AT&T 以 850 億美元收購時代華納。 然而，根據《哈佛商業評論》的一項研究，部分交易的估值很小，但它們產生了更好的回報。 有很多小型初創公司提供單點解決方案，企業的項目經理應該記住，有時將它們買斷而不是試圖複製他們的解決方案是有意義的。 項目經理可能不是這種情況的決策者，但可以將這個選項帶到桌面上。

企業項目經理面臨的挑戰

審批時間更長

隨著公司的發展，報告的層次結構也隨之增長。 多個部門、流程和程序應運而生。 創建品牌指南。 必須考慮法律風險，有時在初創公司中被忽視。 與新合作夥伴聯合發布新聞稿的報價可能需要幾週時間來收集所有需要的簽字。

這意味著項目經理需要提前計劃更多並且更加勤奮。 但是，總會有一些臨時和意外情況，您需要盡快獲得所有批准。 在這種情況下與其他部門建立良好的關係將非常有價值。 作為回報，能夠幫助有需要的人的項目經理更有可能得到同事的青睞。

溝通不暢

“假設什麼”應該是項目經理的座右銘。 隨著公司內部複雜性的增加，項目經理的工作在保持項目團隊內外的有效溝通方面變得更加困難。 讓我們看一個示例場景。

您的團隊需要幾個新圖標來代表他們正在開發的新功能。 您在午餐時意外遇到了設計團隊負責人，並向她介紹了這些圖標。 她說他們現在實際上正在製作類似的圖標，並且很快就會準備好。 在第二天的站立會議中，您將信息傳遞給團隊，並告訴他們在需要圖標時與設計團隊聯繫。 有問題的功能將在 4 週內到期，因此每個人都認為圖標屆時將準備就緒。 開發人員為圖標放置了佔位符，只有在 QA 期間才會有人注意到他們忘記替換它們。 他們爭先恐後地聯繫設計團隊，由於其他緊急任務，他們實際上推遲了這些圖標的創建。 您的團隊中沒有人與他們聯繫，設計團隊負責人認為您將不再需要這些圖標。 品牌指南不允許您使用任何隨機圖標進行生產，並且您的團隊只能坐在那裡完成功能無法部署它們。

企業項目經理的工作充滿了溝通不暢的時機。 您可以在這裡採用兩種策略：

• 使用回顧與團隊一起確定新流程是否有助於避免將來出現此類錯誤。 在這種情況下，也許保留一份來自其他團隊的所有依賴項的列表並每週進行審查和跟進可能是答案。
• 過度溝通。 對於項目經理來說，溝通超出您認為的需要通常是一個很好的策略。 養成與人打卡的習慣，在等電梯或上車時在短時間內要求快速更新。 這是讓更少的東西從裂縫中溜走的好方法。

緩慢移動，不要破壞任何東西

代碼庫越舊，開發新功能就越困難。 項目經理可能會開始注意到，較小的初創公司正在通過新的創新更快地進入市場並超越它們。

在抵禦來自小型初創公司的挑戰的同時，企業還必須警惕類似規模的競爭對手。 隨著初創公司的成熟，單點解決方案成為成熟的平台，具有各種不同的功能和用例。 與其他大型競爭對手企業的功能平等成為一個問題。

作為企業的項目經理，您必須做出決定，是參與創新並為您的客戶創造新的價值主張，還是嘗試與競爭對手取得同等的功能。 但是，大多數情況下，您自己無法做出此類決定，您必須努力影響多個利益相關者為您做出這些決定。 這可能會令人沮喪，尤其是如果這些利益相關者對數字技術不太了解，並且他們不熟悉您試圖說服他們構建的功能。

結論

在本文中，我們討論了初創公司和企業的基本機制如何為項目經理創造機遇和挑戰。 雖然在初創公司中，項目經理可能會承擔產品經理的許多職能，但在企業中這兩個角色顯然是分開的。 請記住，每家公司都是獨一無二的，並非所有討論的主題都適用於每種情況，因此微妙的環境將要求項目經理利用不同的項目管理質量和技能。

回顧一下，初創公司的流程很流暢，項目經理能夠做出快速決策並對整個公司產生重大影響。 開發生命週期要短得多，這使項目經理能夠保持敏捷並能夠適應不斷變化的市場條件。

初創公司的項目經理也面臨著相當大的挑戰。 隨著初創公司的成長，未完全定義的職責可能會導致許多問題。 客戶和聯合創始人可能會推動項目經理承諾超出團隊合理交付的範圍。 之後，可以將各種捷徑放入路線圖中，這會導致將來出現遺留問題。 初創公司的聯合創始人非常積極地定義路線圖。 然而，他們的信念可能導致誤報，項目經理需要數據驅動和敏捷來緩解這些挑戰。

在企業方面，項目經理可以利用公司的信譽和業績記錄與外部各方建立良好的工作關係。 更容易從經驗豐富的高管和同事那裡收集需求，他們定期與客戶打交道。 最後，項目管理辦公室，無論多麼有限制，都可以幫助緩解項目執行過程中出現的問題和管理風險。

企業項目管理中的挑戰不可避免地與公司的規模有關。 各種批准和簽字意味著項目經理需要非常努力地計劃並與 PMO 合作，以避免減慢項目執行速度。 隨著越來越多的人和部門的參與，可能會出現溝通不暢的情況，必須通過建立正確的流程來緩解這種情況。 最後，開發生命週期變得更長，項目經理必須與市場上的初創公司和其他企業競爭。

這些是項目經理工作的這兩種環境之間的核心差異。通過了解這些挑戰，我們可以更好地預測從一種環境轉移到另一種環境可能會遇到什麼。