一、本期話題

專案經理如何解決電商在模式融合中的需求變更？更多關於專案管理的問題，推薦去“PMP專案管理助手”APP中檢視~

二、背景介紹

受診人職位：商城團隊專案經理

公司(專案)情況：

我們團隊主要負責b2c商城專案開發，近期正在進行b2b雲鏈商城的開發

問題描述：

新專案立項之初是完全獨立運營的專案，基於此，整個系統架構設計和後期擴充套件的考慮都嘗試了新的規劃，但是專案進行到三分之一，接到領導要求需要嵌入到原有的b2c商城中去，打通使用者體系，讓使用者感覺只是原有商城的升級。

在說服不了領導的前提下，還要求工期不變，目前能做到的就是加班趕進度，然後梳理需求把除必要分支之外的功能先砍掉，但是即使這樣也會為了趕進度而不得不放棄一些 利於後期擴充套件的想法，後期的維護成本也會很高。

不知能否有更優的解決方案？

三、主治醫師

01

首先，

我們應該確定問題：領導要求需要嵌入到原有的b2c商城中去，打通使用者體系，讓使用者感覺只是原有商城的升級。

其次，確定專案目前所處的位置：專案已經立項，並且已經進行了三分之一了，更重要的是說服不了領導，說明這個是典型的變更管理的請求。

解決步驟：(實現難度等級： 從1到5——簡單-困難)

步驟一：應該專案經理找產品經理和需求分析師開會，把領導的要求明確，先轉化成基本的，明確的，可測量的需求。

難度係數——2(需求分析師和產品經理給力，學會尊重，分析，聆聽，引導，協調，基本上沒有什麼問題)

步驟二：正式提出變更請求，然後把新需求提交技術組(專案團隊具體討論可行性)是否可行，如果不可行返回給產品經理和需求分析師，如果可行，給出解決方案(最好原來的設計方案不動，加上一個中間對接層，這樣保留了原來的設計方案，保證了可擴充套件性，又能兼顧新的需求)，和技術負責人新的功能需求的排序。

難度係數——4(這個相對難度比較大，需要架構師比較厲害，如果架構師沒有問題 3就可以了)

步驟三：專案經理組織產品經理和技術團隊開會，確定這期必須要做的任務，然後，把能不必要的分支之外的功能先砍掉，然後看一下原來的設計方案中，現在不能麼急迫的功能去掉，然後再把需求中分支之外的功能和原來設計的方案中去掉的功能，儲存記錄下來，可能在有需求的時候提出專案的二期工程。

難度係數——3(這個要做取捨，考慮的比較多)

步驟四：因為此變更比較大，設計基準(專案立項的專案章程的變更)，所以需要把正式的變更提交變更委員會審批通過，如果通過變更委員會審批通過，把變更 請求正式提交專案組。

難度係數——1(體力活，走流程)

步驟五：正式把變更請求實施，專案經理組織產品經理和技術團隊開會，正式把不必要的功能去掉，然後提交技術團隊實施。

難度係數——2 (這個基本在第三步就實現了，就是在過一下，然後把遺忘的，或者需要小變動的double check 一下，然後就是技術團隊的技術的基本功了)

步驟六：專案經理時刻監控專案的執行情況，如果專案團隊任務多進度慢，先採用進度壓縮，可接著以採用趕工，如果還是不滿足進度要求，可以提出申請，動用專案緊急儲備，需要確保品質。

難度係數——1(保持監控就行了，基本上沒有問題)

步驟七：變更實施完成後，記得更新專案檔案，記錄更新日誌。

難度係數——1(走個流程，體力活)

步驟八：專案變更完成。

難度係數——1(走個流程，回顧就行了，看有遺漏的東西沒有，體力活)

總之一句話，有變更走流程，這是原則問題。

專案基本保持原來的設計，保證了擴充套件線的要求和維護的成本。

裁剪下來的不急迫的需求，可以預留專案的二期工程。

需求的裁剪+進度壓縮+趕工+可能專案緊急儲備，保證了專案的進度和工期的要求。

02

我就這次案例整理了以下七點：

1、B2B與B2C其實都是以交易為主線，B2C是商家對客戶更多的是小額、小量、線上交易為主，成效率高；B2B是商家對商家更多的是商家獲取資訊，對商家和商品進行評估，欲建立長期合作關係，成效量、成交金額會比較大，可能更多選擇線下協商簽訂合同，進行交易。

2、對於兩種模式，我們進行專案融合必定是求同存異，滿足兩種交易模式。

不難找到在B2C與B2B專案中，都有商家、商品、掛牌、訂單等功能，不同的有交易方式、溝通方式、議價方式等。在建專案前期未考慮與B2C進行融合，突然的融合必定影響已完成B2C專案和在建B2B專案的設計，以及完成了的模組，時間緊、任務重這是必然;

3、 對B2C專案我們採用的戰略是抽象現在功能，形成服務，不同服務之間我們定義統一通訊格式和通訊方式，完成服務之間的資訊互動。

這樣我們首先就完成了對B2C專案的改造，以較少的代價為B2C和B2B融合打下基礎，確定技術路線。

餘下工作則是對現在建專案進行按服務思路進行改造。

4、由於在建專案我們對專案的設計比對B2C專案更熟悉，可依據B2C專案抽象出來的服務改造現有專案，裁剪現有專案的功能，儘可能多的複用現在有服務功能，這些服務是相對穩定的，即可減少功能的開發，也可減少單元測試的時間；裁剪是困難的，只要走出第一步，改變選擇開發的模型，以構建化的思想，以組裝服務為主，只開發剩餘不可複用功能，同樣以服務形式對接上現在各服務模組即可。

5、對於B2B與B2C中的交易形式不同，我們可進行需求引導，讓商家與商家之間的交易模式向商家與客戶之間的交易模式靠攏或一樣，把商家與商家每一次的交易當成一次商家與客戶之間的交易，以型別進行區分，在商家與商家之間的交易模式上進行附加功能的動態繫結，交易模式的複用是是B2B和B2C專案真正的融合。

多元化的交易模式，我們可進行獨立開發，配置客戶、商家選擇不同交易模式。

6、商家對商品進行掛牌、商家和客戶進行選購，以及交易大廳選擇商品這些功能都是極盡相似或者說是相同的，B2B與B2C最大的不同在交易，多元化的交易進行動態配置，不僅僅完成了兩種模式的融合，同樣解決了後期維護難的問題，以服務的形式也便於了擴充套件。

7、個人專案經驗，B2B與B2C的融合，隨著網際網路技術的發展這將是必然的趨勢；這不僅僅是兩種模式的融合，更多的是對我們專案管理思想的融合，對專案開發模式選擇的變革。面向物件結構化的開發方法，不在滿足不定時專案需求的擴充套件和業務的延伸。

03

在專案出現返工，工期不變的情況下，專案成員需要加班加點的完成，從士氣和工作強度上來說，都是不利的事情。

返工會降低成就感，加班會因為邊際效益遞減規律，導致工作效率下降，工期則又可能會被拉長。面臨這樣的問題，不一定有完美的解決方法，只能是考慮從各個環節著手，優化或減少因這兩種負面因素而影響的專案結果。

問題分析：

通常在開發專案中，面臨需求變更問題應該算是比較常見的。此時，一般處於主導地位的是產品負責人【不排除某些團隊中，因為能力問題，會由其他人擔任】。

因此，在遇到需求變更時，專案經理必須第一時間與產品負責人以及相關技術管理人員進行會議溝通，之後專案經理協調團隊管理人員與領導再進行一次的溝通，反饋團隊會議中達成的認知和對應的解決方案，目標是獲得領導的認可和支援，並讓團隊達成一致的結果，以便進入下一步執行的開展。【也可能會需要幾次往復的溝通】

那麼團隊內部會議溝通的方向是什麼呢?

1、清楚領導是出於什麼原因而做出變動決定?

站在領導的角度去思考他提出的變動需求的最根本原因，對於產品負責人和團隊管理來說非常有必要。領導可能會因為競品壓力、上線壓力、戰略調整、資金等問題而做出變更專案的決定，甚至有時候，有些領導只是出於片面理解而下判斷，對於背後企業需要付出的成本和代價一無所知。

2、對於不同的深層原因，團隊可以採用不同的方式給出解決方案。

2.1如時間或成本的限制而調整，一定是基於以最小的工作量去調整功能，並且不要大面積的偏離原本的產品整體規劃，有時候，以快速上線為目的的產品，只是為了提前佔領市場的話，可能在一定程度上需要捨棄功能和體驗的優勢，但在後期迭代和維護中要儘快彌補回來。

2.2如果是因為領導認知有限的話，可以通過不同解決方案對比分析【側面給領導做知識普及】，從產品、運營、市場競爭、後期業務擴充套件和維護成本等多個方面進行比較，並將可能造成的技術層面的影響展示給領導，以便給他一個更直觀的對比評估，綜合產品拓展、運營推廣、技術實現、提升該專案效益，且能夠在市場上具備一定競爭力的角度，以便引導領導做出更適合且對企業發展更有利的決策。

3、如果最終胳膊擰不過大腿，那麼最差的解決方案是什麼?(如何避免再一次被調整，如何在執行前與團隊做好溝通。)

如果領導依然還是堅持執行他的決定，那麼團隊需要做出一個完整的可執行的調整規劃，儘量以最優的方式來提出解決方案——如沿用原來的商城框架減少返工時間；或在現有進度基礎上，部分移植到原來的商城上以減少開發量；在一期上線產品功能裡，犧牲部分可能影響未來擴充套件和增加維護成本的功能，並增加幾個開發工期短且不影響擴充套件和維護成本、有一些亮點特色的產品功能，用類似田忌賽馬的方式——“砍上取中，舍中補下”的方式提升一期產品的競爭力，同時，也能為技術團隊搭建底層基礎，提升產品延展性爭取更多的開發工期。

其次，在領導明確並批准專案調整方案之後，要思考如何跟專案團隊傳達，這一點需要管理團隊的人員達成一致。一方面，不要降低團隊的成就感，感覺是專案不行而被迫調整，而是需要讓大家認為，我們的專案非常重要，因此需要我們去挑戰一個更高的難度。

同時，為了避免技術人員長時間加班影響工作效率，要和技術負責人對整個專案和涉及的人員的工作排期進行拆分，儘量避免單個或部分員工長時間的加班狀態，保障員工休息時間張弛有度。

最後，為了避免專案執行中再一次被領導調整，一定要舉行一次新的產品評審會，並且領導需要一起參與。這樣既可以讓領導知曉你們具體的解決方案，同時也能讓領導和團隊成員直接面對面溝通，表達自己的想法，了解團隊的困難點，知曉專案的緊迫程度，以降低再一次被調整的風險。

總結：

無論是說服領導延續原來的專案框架，還是無法說服只能別破接受專案的調整，都需要與領導明確闡述專案調整後對產品、運營、技術、運維等各部門未來所產生的影響，站在企業利益的角度，評估專案調整所帶來的正/負面的經濟效益和產品價值，為你認為最優的專案解決方案而盡最大可能的努力，但也要擁抱領導所堅持的變化，並盡己所能達成領導所期望的目標。

04

/ 我有話說 /

牧雲-成都-產品：

“這問題我們以前恰好遇到過，相當於使用者系統獨立，挺簡單的。原有系統的使用者系統改為token，由老商城的使用者系統分配，只需要對接使用者--token體系，新專案由token鑑權就行咯。打個比方吧，以前登入社保需要社保卡號和密碼，現在強制要求用第三方微信，那麼把微信和社保卡進行一個連結就好。”

肖樂源-上海-AR：

”本問題不是技術類問題，單純的打通賬號體系可能是簡單些，問題是不單是隻對接一個使用者體系，還有商城的功能也就係統相通，這個希望做下細化，拆分任務，詳細到每一天人員的開發內容，再好領導溝通，說明當前碰到的這問題和耗費時間，把一些可以砍掉的功能和必須要有的功能寫清楚，最好再給一些變通的方案“

Ignatius-佛山-公益慈善：

”大家目前的角度總結而言就是從技術實現方面降低難度，保證工期。既然是專案管理的群，我們應該從專案管理的各個角度來考慮，還有其他的可能性，例如既然把B專案改為嵌入A專案，原有A專案的團隊是否可以調配一些資源過來。”

EQ無-新疆-IT+教育：

”PMP®的角度就是提出一個方案，之後讓兩方坐下來聊，最好說服用這個方式進行後續開發，如果說服不了就先擱置爭議，求同存異，商量出一個可以接受的辦法先讓專案上線。”

亮哥-杭州-旅遊：

”個人認為最大痛點是：系統做了全新規劃，自然資料庫結構等都和原來可能不一樣，並且相差可能大。領導要求嵌入原來的東西，應該就死在這裡了，程式碼和資料庫不匹配，想要達到領導效果，哪一個都不能適應……改哪裡都來不及……”