在與客戶打交道時,請記住利害關係人的目標與關鍵使用者的需求之間存在差異。大多數決策者的優先考慮的是時間和預算,而關鍵用戶大多會要求特定的功能。由於這些目標相互矛盾,您必須做出決定:
你想取悅誰?
您需要始終做您認為對專案最有利的事情;這意味著挑戰關鍵用戶的要求,甚至如果您認為這對專案不值得,就拒絕這樣做。使用以下策略來處理自訂開發請求:
如果您得出的結論是開發特定功能不值得,則需要更努力地說服客戶您的觀點。為此,您可以採用不同的策略:解釋「為什麼」,在「上線」日期之後的一個階段進行計劃,或者將主題升級給經理(雖然不理想,但有時是必要的)。
假設您有以下自訂開發請求:
客戶有一個使用 Magento eCommerce 開發的網站,並且不想更改他們的網站,因為他們已經投入了大量資金。但他們希望 Odoo 與他們的 Magento 網站完全整合(包括產品、優惠券、廢棄購物車的後續活動等)。
評估是否有必要的最佳方法是檢查客戶的舊軟體中是否已經具有此功能。如果客戶在舊軟體中手動記錄所有訂單,他們可以使用 Odoo 進行相同的操作。然後,我們建議先投入生產,而不開發與 Magento 的集成,使用 Odoo 幾個月,然後決定是否值得。
請記住,客戶的優先事項在投入生產時會發生變化。
在變更管理方面,逐步推出業務流程變更比一次性推出所有變更更容易。借助 Odoo 的模組化功能,分幾個階段進行部署是有意義的:首先是客戶運營業務絕對需要的或對他們的成功影響最大的內容,只有在此之後才進入第二階段,在該階段中,您將重點關注其他需要改進的功能效率。
您需要評估收益:由於此功能,客戶每月可以節省多少個工作天?通常,客戶只考慮多少時間他們目前在此類任務上花費了多少,以及他們認為將來會節省多少。實際上,他們仍然需要記錄計算所需的所有數據、手動處理異常等。
例如:
即使客戶開發了 Magento 連接器,他們仍然必須解決所有衝突,在兩個軟體解決方案中記錄價格折扣,處理由於同步不實時而導致的庫存衝突等。
然後,您需要評估持續成本。通常,客戶只看到「一次性開發成本」。實際上,您可以將此成本乘以 2 或 3,用於未來 5 年內的維護和升級。
請注意,使用社群模組可以節省初始開發的時間,但您仍然需要花費在測試、維護、專案延遲和升級的時間來計算總成本。社群模組也會造成技術債。
假設您有以下自訂開發請求:
當我們確認建築項目的銷售訂單時,我們希望根據一組取決於產品、客戶和位置的規則建立一系列任務。
當您有定制需求時,您需要先詢問數量:“您每月贏得多少個建築項目?”假設客戶每月贏得 10 個此類項目。透過複製和更新專案範本來建立和更新任務可能需要 10 分鐘。
是否值得啟動一項複雜的開發來每月節省不到 2 小時的工作時間?當然不是,這個功能的開發成本大約是 10 天,每年還要再加上 25%。
不同的方法?
假設您有以下客戶請求:
我想將 Outlook 行事曆與 Odoo CRM 同步。
Odoo 有一個標準的與 Google 日曆的連接器,但沒有與 Outlook 的連接器。
但開發和維護連接器可能會花費很多錢。不過,有許多服務可以將 Google 日曆與 Outlook 同步(例如 IFTTT)。因此,解決方案是為每位員工訂閱並設定這樣的服務。
它並不完美,因為每次招募新員工時都必須修改設置,但解決方案在 2 小時內就準備好了,每個新員工只需要 10 分鐘。但成本仍然比新的低很多,如果公司員工人數少於 100 人,則需要開發。