起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識用“系統思考”看破產品開發團隊與項目實施團隊的相愛相殺
編輯導語：在企業的項目合作中，產品開發團隊跟項目實施團隊很容易起沖突，產品和開發的角度有一定的差別，所以合作起來經?！跋鄲巯鄽ⅰ?；本文作者分享了這一觀點以及解決辦法，我們一起來看一下。
讓我們從一段充滿火藥味兒的假想對話開始今天的討論——
項目實施團隊指責：你們根本不懂業務需求！這點功能都支持不了！
產品開發團隊反駁：你們根本不懂產品思維！你那需求沒有產品意義！
一、話題背景
2B（To Business）產品，會因行業不同、企業規模不同、甚至是企業文化不同，對同一個核心需求點，需求的實現方式有自各獨特的訴求，也就是我們經常說的“個性化需求”。
或許有人會說，作為產品經理不應該停留在表層功能層面，而應該挖掘底層需求，運用邏輯能力深層次的抽象，找到一種普適的功能實現方式。
我不否認這種觀點，但同時也要向現實低頭；以“協同類”2B產品來說，協同中很重要的一個因素是參與協同的“人”，想要幫助這些人提高效率，“讓工具適應人”比“讓人適應工具”更容易。
說點更現實的，當你的客戶說“你這產品不好用”，而你又無法說服客戶改變時（認清一個現實，就算我們的客戶是高層管理者，有些事也不是他能改變的），你是放棄成交，還是為Ta改變？
跨越鴻溝理論告訴我們，一款產品，如果一開始就定位于主流大眾用戶，那它大概率什么用戶也滿足不了；在B端是同樣的道理，如果一開始就想讓自己的產品適應所有企業，那它大概率是蹩腳的、難用的。
所以，在2B產品中，過去常見的一種模式是，軟件建設廠商的產品團隊開發好產品后，先到甲方客戶現場去部署，然后根據客戶的個性化需求，由項目實施團隊提供一定的定制化服務；雖然SaaS正對這種模式產生沖擊，但在大客戶中這種模式仍普遍存在；而我們今天要討論的話題“產品與項目的相愛相殺”，正是在這種背景下發生的。
二、場景描述
要解決問題，我們首先要理解為什么問題會出現，我舉一些純屬虛構的場景，來幫助我們更好的理解。
1. 場景一：不劃算
某公司總部產品部門開發了個產品叫“宅男”，該產品新拿下了某地的一個大客戶叫“白富美”。
此時，項目團隊評估了一下大客戶的需求和公司的產品，發現“宅男”離“白富美”的需求偏差很大；而改造“宅男”花的成本，比完全新開發成本還高！而且，改造“宅男”時還受到些限制，不能完全滿足“白富美”的需求。
此時，你愿意花更多的錢，用一個更難用的產品嗎？
2. 場景二：不主動不負責
繼續說產品部門的“宅男”產品，“宅男”不主動去找各項目組了解客戶真實需求，不主動給各項目組培訓自己的優點，不主動告知項目組自己未來的改造計劃；而當項目組想主動了解“宅男”時，卻遭遇難以跨越的部門墻，產品部門推說要材料要找運營人員，運營人員說要去公司OA提工單，好不容易找到了這個工單，卻發現工單提交就報錯！然后繼續讓找OA的IT人員。
此時，大概項目組心里只會想，MMP，老子不陪你玩了！
3. 場景三：貴慢差
還繼續拿“宅男”說話，總部領導要求，項目組必須用公司自有產品二次開發。
此時，項目組發現產品本身非常復雜，想自行改造成本太高了，于是，想讓產品部支撐一下；但產品部門要求提工單，換句話說就是“拿錢辦事”，項目組5個人辛苦一年才5萬的獎金池，你產品部改一個功能就要拿走2萬！沒辦法，客戶急著要滿足需求，咬牙給錢吧；結果，你會發現，產品部會告訴你他們需求很多，你等著排期吧！
然后，你辛苦安撫住了客戶耐心等需求實現，產品部卻交付給了你“產品化”的功能，你還得繼續花時間改造才能滿足需求！
三、問題分析
產品開發團隊與項目實施團隊的相愛源于“項目能給產品錢，產品能給項目省時間”，而相殺也源于相似的原因“項目占用產品太多的時間，產品沒能幫項目省錢省時間”。
但這個問題，并不是這么簡單，我們來用“系統思考”工具嘗試探索問題背后的模式。
系統思考工具是什么我不細說了，我們只需要知道“+”號是正相關，“-”號是負相關即可；關于本系統思考圖也不細說，只看核心邏輯節點；先從整個系統中最關注的點“利潤”來開始看，影響利潤最核心的2個點是“ROI期望”和“項目新簽與續約”。
我們從ROI期望這條路徑出發，看看會發生什么——企業追求利潤，于是高管要求提升ROI，這本身是沒有錯的；但提升ROI勢必會壓縮產品和項目的成本投入，項目投入減少會直接造成項目團隊交付能力降低，項目交付能力降低會造成項目交付速度降低；而交付速度降低會造成客戶滿意度降低，客戶滿意度降低造成項目續簽減少，進行影響到整體收入和利潤。
看到這個有趣的邏輯鏈了嗎？高管想要增加利潤，但結果卻可能從其他方面造成利潤下降；同樣，在產品開發團隊投入減少，也會最終影響利潤，只是這個因果傳遞過程是有“時間差”的；看懂“時差”，很難。
在整個模式中，處于核心地位的除了“ROI期望”，就是產品本身能力了，即“產品通用性及開放性”；對于ROI，我們可以看出來，項目團隊上的投入見效快、卻不可持續；而在產品團隊上的投入見效慢、卻可持續。
如何平衡在項目、產品上的投入，如何確定合理的ROI，這是高管要決策的一個核心問題。對于“產品通用性及開放性”，有2個核心因素，一個是對產品開發團隊的成本投入，另一個是產品團隊對業務的洞察力；而產品團隊對業務洞察力的一個基礎是對業務的熟悉程度，這個因素相對容易，接下來我們主要從這個角度探索解決方案。
四、解決方案
我們要解決的問題是“如何讓產品開發團隊更懂業務”，在大客戶的場景中即，“如何讓產品與項目不脫節”；解決這個問題，你可以說我們要招優秀的人、積極主動的人，也可以說我們多組織一些溝通會，方法總比問題多；筆者再補充一種解決方案，這種方案的核心是“利益平衡”，在執行上來看即“組織設計”。
從產品開發團隊規模角度，可以將組織形式分為三種模式，依次為大產品團隊、中產品團隊和小產品團隊。
三種模式本身各有優缺，筆者從特征、原理、協作方式、應用現狀和存在問題5個角度對三者進行了對比，具體如下圖所示：
其中，對于第三種模式筆者還是很期待的，因為它可以適應筆者在B端產品中的另外一種思想，即“B端產品要適應客戶自身成熟度”。
最后總結一下，以上三種模式各有優缺，具體選擇哪種模式，還是要視自身以及客戶的場景而定；而且，以上三種模式并不是必選其一，也可以視具體場景同時混合采用；比如，同一個產品，對大客戶就采用中產品模式，而中小客戶則采用大產品模式甚至SaaS模式。
本文由 @李曉杰 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
- 目前還沒評論，等你發揮！
