導讀編輯導語：作為產品經理，為什么要做項目？是否你也有想過這個問題。我們又該怎樣調整心態，集合各家ISV的業務能力之長，以及明確合作模式和協作平臺呢？感興趣的朋....

編輯導語：作為產品經理，為什么要做項目？是否你也有想過這個問題。我們又該怎樣調整心態，集合各家ISV的業務能力之長，以及明確合作模式和協作平臺呢？感興趣的朋友就接著往下看吧，希望對你有所幫助。

做to B項目的回報周期和投入產出比，相較烈火烹油的to C真是相形見絀。也許這就像影視行業孵化IP一樣，孵化一部叫座的電影很難，有太多的不可堆積因素。何況我想孵化的是一個電影系列，而不僅是單單某個電影。

自8月以來，我一直派駐在外負責一個大型項目，這對于我職業生涯里也是第一次。最近臨近派駐結束，2021年也即將落幕，回想起這幾個月，竟覺得一開始那么難熬的日子硬扛到底也沒那么難過。

好吧，無論如何還是要跟這段時光做個總結，對自己有個交代，希望也對你有所啟發。

也許你在公司內也陸續負責過一些跨團隊產品合作的項目、對外服務支持的項目，也許你經常深耕到前線和銷售、售前、項目經理、交付團隊共同作戰。不知道你是否想過一個問題：為什么要做這個項目？

一、了解你為什么做項目比做什么更重要

明面上，出差嘛，沒什么道理可言。我呢，是在8月初的一個深夜接到領導的電話，隨后電腦包也被緊急送到了小區門口，一番囑咐后第二天一早就拉著行李箱飛去了異鄉。原以為待個把禮拜支持下前線團隊就行，誰知道一周復一周，一月復一月，到現在已經堪堪120天了。

事后我也多次和現場派駐的同事溝通，為什么要做這個項目，有必要讓產品經理深入前線支持嗎？

先以旁觀者的心態審視項目的來龍去脈：這項目的背景是什么，前期我們和友商是如何pk的？打動客戶的提案是什么，為什么客戶選擇了我們？之前和客戶匯報過的材料在哪里，客戶給過什么指示？

再以主導方的視角來分析接下來的局勢：為什么我們要挑在這個時候交付，有必要投入這么多人力嗎，是不是在重復造輪子？入局的廠商有哪些，接下來的重心是什么，我要作為什么角色來參與到這個項目，我能為這個項目帶來什么？

了解了項目的始末之后，新的問題擺在面前：在涉獵一個全新的項目時，我要如何避免水土不服？

二、調整心態：認清項目的可堆積和不可堆積因素

先交代下背景。我在公司內一直都是負責平臺性產品，支撐泛政行業的項目。但對于該行業里的實際業務沒有深入鉆研過，也鮮少和專門的廠商長期接洽過，此前所有的經驗都僅限于一些蜻蜓點水的方案交流。

而這個項目需要你統籌平臺并聯合多家ISV根據客戶需求共建行業應用，作為產品負責人，你哪來的底氣？

老實說，剛來項目前線時我挺焦慮。項目經理、銷售、售前、交付、運營團隊，以及公司的服務商和軟件開發商，每個人看起來都有一把刷子，我就好比一位被保護太好的大家閨秀第一次出遠門，邁著小碎步躑躅前進，焦慮得不得了。

焦慮者們一般是怎么回事呢？懼怕不可預知的改變，懼怕進入不熟悉的環境，懼怕駕馭不了新的業務，懼怕自己無法融入新的項目團隊，懼怕自己在別人眼中就是個弱雞。所以一開始常常自我否認，給自己找一萬個理由來勸退內心的激情。

怎么打破這種被焦慮捆住手腳的狀態呢？

1. 認栽

既然人都來了，責任和使命都背在身上了，后退的路已經堵死了（其他工作均已交接），那就只能硬著頭皮往前走了。往前走的過程甩下身上原先的包袱和莫須有的光環，逐步解耦自己和原先環境的關系，臉皮厚點，通過新項目去經營自己。

一知半解的話就去翻資料、找資源、找專家求助，承認“我就是不懂，我就是需要幫助，我就是要向你學習”，這并不丟臉。不斷拓展自己的視野，加深對各業務領域的認知，讓焦慮無從插手。

事實上，后續上手了解整個項目的利益關系，摸清客戶決策層的小算盤后，也確實無暇顧及這種若有似無的情緒，即便偶然閃現也會通過一次次的實踐驗證讓自己擺脫出來。

2. 連接

斯科特·佩奇在《多樣性紅利》一書里提過，所謂創造性，其實就是“不同想法的連接”。把兩個視角加起來，你就獲得了一對想法的連接，它能幫助你解決新的問題。

在一個大項目里，你能接觸的角色、遇到的事情比你在家潛心做一款產品的時候更多，可以連接的想法也會更多。

舉個例子，有一次我們在討論政府內“信息簡報”的業務場景時，作為一個內容性產品，無非從收、發兩個維度切入，分為：編制簡報——接收簡報——簡報批示——接收批示意見。與此同時，各模塊下的角色也就浮出水面：編制人、接收人。

乍一想流程簡單明了，沒什么疑慮。但深究下去發現，政府內的公職人員實際的信息傳遞場景，似乎并不是這么簡單。

信息簡報的定位是什么，它是公職人員向各級單位領導以簡要形式傳遞工作或業務要情的信息載體和傳遞工具，尤其在跨單位跨層級的匯報場景里會有較高頻的運用。經過和專門負責政府傳統oa業務的廠商溝通后，抓住簡報和其他信息內容的差異點：專題性強、有一定周期性、相對更高頻：

• 對簡報創建方而言：在簡報之上引入“欄目”的概念，每個單位均能創建多個欄目，基于欄目去編制、審核和分發簡報。由業務管理員注冊欄目并按欄目維度確定編制人、審核人，以及有權接收該欄目下的簡報接收人；
• 對簡報接收方而言：本單位內以領導為主，查看和批示簡報；跨單位時以接收單位的簡報管理員作為唯一接口人來進行簡報分發。

在和ISV共同商議后，最終擬定的簡報主流程為：注冊欄目——編制簡報——審核簡報——接收簡報——批示簡報——接收批示意見。然后再根據不同環節再開展分支流程的梳理，以及每個流程里覆蓋的角色和權限。

整個過程我最大的感受是，要充分利用我們的產品能力和ISV的業務能力，二者進行有效地組合，才能讓最終的交付物更貼合客戶需要。

對個人而言，學習用“工”字形的結構來積累自己的能力：先劃一橫，廣泛涉獵多個領域，積累經驗；再劃一豎，從某一個業務領域專精下去。然后再劃一橫，把積累的領導力遷移到各個領域，最終實現多個維度的成功。

3. 堆積

在一個項目里，總會存在一系列可堆積因素，它是可被計劃的、可控的、可被堆積出來的。

比如人力物力財力，只要你有足夠的意愿和執行力，你可以通過反復給它加碼、給它堆出來。只要你投入的成本足夠高，組織有道管理有方，有明確的流程、分工、責任、權力、利益分配，這事兒就有較大的概率能搞定。

但同時，一個項目里難免也會存在一些不可堆積因素，你無法計劃也無法指揮，可能需要一個機遇，一個突如其來的決策，一個靈光乍現的想法。你只能等這個因素已經露出苗頭之后，再集中精力去跟進。

因此，一個項目的成功與失敗都不會取決于你一個人。你可以堆積很多的資源和努力，但你堆積不出來那個讓所有人眼前一亮的X因素。所以犯不著給自己太大壓力，把握可堆積的因素，充分發揚不同團隊的優勢，共同把整個項目撬動起來。

三、他山之石：集各家ISV的業務能力之長

在我負責的這個項目里，涉及到10多個行業內的業務應用，這都不是一朝一夕就能了解透徹的。

對個人而言，一個項目中涉及到多少業務，分別需要你快速熟悉并給出判斷。做深10多個業務意味著要深挖10多口井，并從中找到水源。

對于ISV而言，他們在這個細分行業里沉浸多年，擁有豐富的know-how，要在短期內交付這個項目，我們應該支持合作伙伴去做，或是聯合合作伙伴的業務能力共建，而不是自己下場去做。

但這并不意味著交給合作伙伴之后就可以高枕無憂，直接拿現成的方案給到客戶。你還需要深入客戶側調研客戶的需求場景和痛點，再來看已有的方案是否能夠滿足。

事實證明，在這個項目里，這些業務在實際調研之后的確有很多地方需要推倒重來：有些產品需要重新定義業務邏輯，有些產品需要充分結合其他產品的組件能力，有些產品需要提升魯棒性，有些產品需要按最新定義的規范開展設計，實現產品的本地化建設。

舉個例子，我們在設計一款日程應用時，目標是匯聚和管理個人的工作計劃和安排。照理說，這是一個相對通用的辦公工具。而對于通用的工具，在政府內的業務場景下，是否有一些個性化的差異點？

首先拆解下目標，“個人的工作計劃和安排”，這里要劃分角色：所有人看待日程的視角一樣嗎？普通員工和領導的日程會有什么差異？怎么去定義普通員工和領導？

其次對實體的權限進行管理：誰有權限建日程，日程的公開范圍有哪些，由誰來定義？由誰來變更？

經過和ISV的多輪探討，最終將日程分成三類：個人日程、領導日程和關注日程，即：除了規劃和查看個人日程外，我還能查看到領導公開的日程，還能關注本單位內其他人員的公開日程。不同類型的日程公開范圍不同，日程之間的關聯性也不同。

比如領導日程，在政府內一般由秘書或辦公室副主任代理設置，因此在領導日程里增設代理人模塊。由日程管理員設置哪些領導由哪些代理人來設置日程，并定義好日程的公開范圍。那么對于公職人員來說，就可以查看到本單位內所有公開的領導日程。

整個產品就是在一點點的討論和細化中，豐滿起來的。

亞當·格蘭特在《離經叛道》一書里提到，人們獲得越多的專業知識和經驗，他們觀察世界所用的某種方式就變得越發根深蒂固。 不同專業領域的合作伙伴，都會恪守原有的業務邏輯和產品走向。

研究顯示，當橋牌規則被改成由擁有最小牌的玩家先出牌，而不是擁有最大牌的玩家先出牌，專業的橋牌選手表現得比新手更難適應；在使用取消了舊規定的新稅法時，專業會計師比新手做得更糟糕。隨著我們對某一領域的知識增多，我們也成了自己頭腦中原型的囚徒。

在與isv聯合研發的過程中，的確會遇到雙方各執一詞無法決斷的情況，這時候劃清雙方的分工邊界、開展柔性化的協作則非常重要。

1. 明確定位

比如我司，主要以平臺型產品為主，作為一家從互聯網公司切入To B戰場的企業，我們很難在短時間內構建復雜行業應用的能力。當我在推動整體協同應用在各行業賽道上的建設時，雖然我大概了解這些應用在實際客戶辦公場合里有什么場景，但我并不真正了解客戶為什么要這么用，單憑一己之力構建不了完整的行業解決方案。

因此，在項目初期，多方聚在一起就要先把丑話說在前頭，互揭老底，開誠布公地來定義整個方案能實現到什么程度，有哪些是可以保底的，哪些是可以爭取的，哪些是需要引入外援的。

2. 發揚優勢

如果你無法深入業務，那么你的優勢是什么？一開始我就清楚，我們的優勢是產品和技術能力，在和多方合作伙伴的聯合共建的過程中，我們應該做一些能最大限度發揮自身技術能力優勢的方案，做能標準化、可復制、輕交付的產品。

比如在做辦公門戶的時候，ISV已有較為成熟的標品，但是產品本身在角色權限管理、應用管理、數據源配置上都沒有做好標準化，在多單位場景下也很難做到應用數據的切換。

這些都是基于我對底座平臺和產品標準化的理解，即便我沒做過門戶，不清楚門戶內各元件的設計邏輯，也不妨礙我們和合作伙伴之間共同推進該產品的優化，形成更完整的解決方案。

3. 錨定目標

取他人之長，集各家ISV的業務能力之長，目的不是為了賣行業解決方案本身，而是為了增強自有產品的行業適配性，形成可復制的標準能力。

而對于isv而言，他們也會有自己的心思，如何充分發揮自己的行業實力和業務強項，如何讓產品在更大的平臺和項目上得到印證，樹標桿、贏口碑、名利雙收，后續可以有更多的商業合作機會。

四、構建隊形：明確合作模式和協作平臺

業務規模要匹配上相應的組織能力，組織能力是To B企業的最大瓶頸。如果組織能力跟不上，項目就算拿的多，也消化不了。管理不善時，項目甚至會虧損。

坦白說，我們都太習慣組織內的協作了，跨組織間的合作一搬上臺面，似乎就要頂著鍋蓋、拋出盾牌、緊盯戰況，如有風吹草動隨時準備防御、后撤。

在當下這個互聯的技術系統下，所有組織本質上都是生存在一個無限鏈接的空間中。我們常常看到的是，組織內部之間是開放的、互通的；組織之外表現為以顧客為核心的相互鏈接的價值共同體。

我們也承認，分工使得勞動效率最大化，但我們要解決是合作團隊的整體效率，既有你方團隊成員，又有我方成員，跨組織的合作更需要依靠協同，依靠信息交換和共享。

那么落實到實際行動上，怎樣才算是協同合作呢？

一個一個說。

1. 定機制

項目在一開始搭建團隊的時候就要明確多方協作的機制，并形成文字上的規范進行宣導，包括日常研發合作模式和臨時突發情況的應對機制，從始至終要和合作伙伴保持信息透明和同步，確保雙方背靠背，共進退。

跨公司聯合研發的過程中，有太多需要磨合的地方了，尤其是當一個項目聚集了多家公司，每個公司內還涉及到多個團隊，各團隊的利益不完全一致的情況下，如何讓整個項目團隊群策群力，是一件特別有挑戰的事兒。

每個公司的研發流程各不相同，當大家匯聚到同一個項目里，就需要有人牽頭明確整體協作機制。你需要基于項目實際情況，比如項目的成本和交付周期、各團隊的人力資源、需求的復雜程度、標品的匹配程度、總體項目的質量要求等綜合去定義產品的迭代節奏和研發流程。

以產品研發流程為例，你需要明確定義各家廠商分別要配備哪些人力資源，每個角色的職責邊界和分工，以及各角色之間在研發各環節中如何協作。其中每個環節誰為主誰為輔，大家必須要達成共識。

由于整個項目是我們牽頭由多家廠商合作，涉及到產品聯調的環節，需要由我們來從中協調，主動給出決策判斷。

以產品方案設計為例，從前期的客戶需求調研、業務流程梳理、產品原型設計、需求方案設計到面向客戶匯報方案，全程有哪些輸入，哪些輸出，哪些注意事項。在這個過程中，ISV產品給出初步的業務流程設計，再由我方的產品同事進行把關審核，雙方達成一致意見后約客戶面談對齊方案，得到印證后再開展詳細的需求原型設計。

2. 定平臺

一個大項目的協作僅停留在流程機制層面肯定是不夠的，在這過程中還需要引入平臺性工具，比如需求研發管理工具、知識管理工具、代碼分支管理平臺、設計管理工具等，讓所有廠商的產研相關人員均養成同樣的習慣，在同一個平臺上交換信息，提升組織協同的效率。

在這個過程中，最大的挑戰是反復、刻意地培養所有人養成使用平臺的習慣。

以研發管理平臺為例，在項目伊始宣導過規范，但各家isv在實際執行時仍然會延續自己公司內的做法。比如用表格管理需求、記錄缺陷，等需求缺陷實現后再補錄到研發平臺上。對于整個項目而言，通覽數據的準確性和完整性就無法保障，研發流程也無法及時流轉到下一位處理人，整體研發進度不夠清晰透明。

這種情況下，一方面要持續宣導平臺的使用規則，各產品線分頭指定對應的負責人跟蹤到底；一方面通過日會匯報的機制，以平臺數據為準，每天由各廠商的項目經理對數據進行盤點，對風險點進行晾曬，倒逼每個團隊將習慣扭過來。

3. 有儀式

上述無論是在明確合作機制和協作平臺的過程中，都需要保持一種儀式感。

大型的數字化項目或軟件開發項目，尤其是涉及到甲乙丙丁等多方的合作，都需要一個“儀式感”的會議，代表項目正式的kickoff。

這不單單是將項目計劃告訴所有參與項目的領導和執行人員，最重要的是讓所有人都對項目的目標、計劃、分工有統一的認識，也對項目過程中各方的協作模式加深理解，讓所有的參與人員統一思想。

我在這個項目負責了三個產品版本的迭代，每個版本推進前都會開展一次版本啟動會，明確該版本的階段性里程碑和迭代計劃，并和各廠商的項目負責人提前對齊，了解他們對產研的期許和意見。在版本啟動會時，也會主動讓項目負責人在所有項目組成員面前去發表自己的想法和看法，樹立威信。

此外，不僅是啟動前要有儀式感，一個版本即將告一段落的時候，也要有一個儀式：成果 復盤。

1. 匯報成果前，最好能拉上各團隊相關負責人約客戶當面演示和驗收產品，向整個團隊傳達客戶的表揚或提議，增強項目組成員的獲得感；
2. 復盤，給各方團隊一個自省和吐槽的機會，是為了更好地總結之前的問題，更好地應對接下來的挑戰。

據我觀察，這類型的會也更容易拉近各團隊間的關系，就像是在日常公事公辦的場合里打開了一扇小窗，大家都可以吐露心里的想法，整個氣氛是比較寬松自在的。

五、小結：飯要一口一口吃

以上是我這幾個月以來作為產品經理深入到項目的大體總結，不舍晝夜緊鑼密鼓的團隊奮戰中，當中的細節遠不止這些。針對每個關鍵階段的心得分享，比如方案設計、需求管理、團隊管理、項目管理等過程中的實操經驗和感悟，我會在接下來的時間里持續輸出（先把flag立下了）。

回顧這幾個月，和不少前線的高人交流過，有一點大家都心有戚戚：做to B項目的回報周期、短期投入產出比，相較烈火烹油的to C真是相形見絀。

在傳統互聯網下，我們賺快錢習慣了，現在要慢下來。做to b項目的過程中，我發覺新的挑戰點發生了范式轉移，不僅是產研的合作模式，也包括業務盈利模式、運營模式和從業者的心態等。這些都需要所有角色齊心攻克。

我常和項目組的伙伴們說，不管項目如何，對個人而言都已經是一個很大的成長了。

也許這就像影視行業孵化IP一樣，孵化一部叫座的電影很難，有太多的不可堆積因素。即便成了，我們的野心也不止于此，我想孵化的是一個電影系列，而不僅是單單某個電影。

參考文獻：

#專欄作家#

健壯的大姐姐，健壯的大姐姐（ID: is_strong），人人都是產品經理專欄作家。騰訊高級產品經理，專注于To B服務項目管理和行業分析，歡迎各路好漢一起探討。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議