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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 認栽

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

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

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

2. 連接

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

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

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

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

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

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

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

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

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

3. 堆積

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

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

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

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

在我負責的這個項目裡，涉及到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 協議