我認為重構(gòu)坑太大，因此我將從十個方向告訴您重構(gòu)之前需要注意的幾點。

我認為重構(gòu)的坑太大了，所以讓我們從十個方向來談?wù)�，在重�?gòu)之前值得注意的幾點。

如果您尚未進行重建，請查看這10個坑并收集它們。 下次，您需要將它們拒之門外，然后再次仔細查看它們。 順帶一提，讓您的領(lǐng)導(dǎo)一下。 如果您踩在重建坑上，也請參閱這些坑。 那些沒有踩到的東西應(yīng)該引起注意！ 如果不幸的是您像我一樣完成了重構(gòu)，那就握手吧。

首先，我們對重新配置有一個清晰的定義：我們需要從內(nèi)部到外部重做以前的系統(tǒng)，然后我們將擁有兩個獨立且不相關(guān)的系統(tǒng)，而不是對先前系統(tǒng)進行部分重新配置，因為坑 部分重新配置的數(shù)量不夠大。 重構(gòu)是因為先前的技術(shù)框架無法支持新功能的后續(xù)迭代。

讓我們談?wù)勥@10個坑！

設(shè)計不合理，更改與否？

2年前，我加入了公司，我的任務(wù)是重建系統(tǒng)。 以前的產(chǎn)品經(jīng)理不知道他已經(jīng)更改了幾波，也沒有留下完整的文檔。 要進行重建，我們必須了解舊系統(tǒng)，例如手背。 沒有辦法。 我們只能花兩周的時間來整理舊系統(tǒng)的邏輯。 在某些業(yè)務(wù)流程中，我們發(fā)現(xiàn)了許多不合邏輯的地方。 例如，藥房退回藥品后，其狀態(tài)不是退回而是返回上一步：等待藥品交付； 治療師已經(jīng)開始治療，醫(yī)生可以刪除醫(yī)生的訂購項目，記錄突然消失； 待付款項目將在幾天后自動關(guān)閉，并且作為嚴格的產(chǎn)品經(jīng)理將無法收回這筆款項，這些不合理的事必須予以更改！ 因此，我將退藥的狀態(tài)更改為退回的藥，診所的藥劑師也爆炸了：“我發(fā)現(xiàn)，只有在我將藥寄出后，醫(yī)生才開錯了處方，所以我拿回了藥，讓醫(yī)生進行了更換 并重新發(fā)行�，F(xiàn)在您已經(jīng)退還藥物，并且已經(jīng)直接退還。醫(yī)生如何更換它？”

我怎么能認為醫(yī)生總是開錯藥？ 聽了之后，我很害怕。 不應(yīng)因為患者不想要藥物而撤藥嗎？ 為了保持我以前的完美邏輯，我添加了另一個功能：返回修改。 我認為其他診所的藥劑師在閱讀此按鈕后會有一種奇怪的感覺。 當談到這些非理性時，

確實很糾結(jié)。 以前的產(chǎn)品經(jīng)理也不是傻瓜。 他故意制造了邏輯缺陷，必須由客戶強制實施。 但是，為了抱怨系統(tǒng)中功能邏輯的一致性和合理性，這是不可避免的。

如何打破用戶習(xí)慣？ 上面也提到了

，我們重構(gòu)的主要原因是以前的技術(shù)框架太舊，無法支持新功能的迭代。

，但是，如果領(lǐng)導(dǎo)者只是在技術(shù)水平上重新構(gòu)建一套系統(tǒng)，而愿景和互動體驗卻沒有改變，他們怎么能感覺到我們團隊的價值呢？ 技術(shù)無法直接看到。 互動和視覺很容易被察覺。

我們經(jīng)�？吹降氖荂端產(chǎn)品。 一段時間后，我們將更改一組視覺樣式，該樣式必須易于使用，尤其是一些低頻必需品，例如移動銀行，但這對于領(lǐng)導(dǎo)者展示表現(xiàn)是一件好事。

因此，要重建SaaS，必須改變視覺和交互！ 但是，讓我們盡量不要改變太多：

我們真的不能高估用戶的計算機級別。 例如，如果我們更改時間控件，他們將不會使用它。

之前的時間控制是這樣的：分別選擇開始時間和結(jié)束時間：

現(xiàn)在使用元素的組件，用戶如何不能選擇時間段？ 他認為他想雙擊以進行選擇，然后在某個日期（即選擇日）上單擊了兩次。

也有非常重要的一點。 在用戶切換系統(tǒng)之前，請要求他們使用更多新系統(tǒng)，直到他們習(xí)慣為止。 最好熟練地使用它們。 否則，一旦工作繁忙，系統(tǒng)將無法正常工作，并且會有更多的投訴。

重構(gòu)的內(nèi)容越來越多，一般來說

saas并不是一個單一的系統(tǒng)。 它將具有一個操作平臺，以及外部對接，例如公司內(nèi)其他業(yè)務(wù)的對接以及第三方應(yīng)用程序的對接。

我們只是想重建用戶端的系統(tǒng)，而沒有其他動作。 但是，當我們這樣做時，我們發(fā)現(xiàn)必須重做操作平臺，并且必須重做所有外部對接，例如聚合支付對接，出站對接檢查。 工作量比預(yù)期增加了一倍以上。

因此，在評估重構(gòu)的內(nèi)容時，最好仔細閱讀所有與重構(gòu)有關(guān)的內(nèi)容。 盡管這個主意非常好，但是如果您不對其進行盡可能多的更改，請不要動，但要做好重新計劃的準備。 <

的功能必須> 舊的系統(tǒng)可以將

重構(gòu)的系統(tǒng)和系統(tǒng)從0升級為1。最大的不同是：不同的商業(yè)時間，不同的升級方案。 我們都知道MVP的真相，但這在重建系統(tǒng)時不起作用。 我們的用戶遷移到新系統(tǒng)上使用。 舊系統(tǒng)具有某些功能，而新系統(tǒng)則必須具有。 否則，他們的工作將無法進行。

，但是在我們發(fā)展它時，我們不可能招募數(shù)十人。 所有功能都是同步開發(fā)的，因此我們必須分批進行。 例如，我們首先執(zhí)行門診相關(guān)功能，然后執(zhí)行物料庫存管理功能。 如果是0到1的乘積，我們可以在門診服務(wù)后開始小規(guī)模促銷，讓一些庫存管理要求較低的小型診所首先使用它，并在隨后的新功能開發(fā)中一起優(yōu)化舊功能。

當然，為了防止我們在更改舊功能和添加新功能時出現(xiàn)偏差，每個版本上線后我們都會發(fā)現(xiàn)一些用戶體驗，但畢竟與實際使用有所不同。 這個重構(gòu)過程有點像一個半黑匣子，對產(chǎn)品經(jīng)理有更高的要求。 如上所述，對于新功能，建議遵循MVP原則，而不要立即全部完成。 以

為例，我們最初計劃做健康管理功能，設(shè)計是完美的，包括用戶自己的家庭測量數(shù)據(jù)上傳以及家庭醫(yī)生的多對一服務(wù)。 但是后來，我將其刪除了，但只提供了一個運行狀況索引數(shù)據(jù)庫。 盡管這是一個發(fā)展方向，并且許多診所都提到了這一點，但現(xiàn)在只有少數(shù)人真正能夠做到這一點，事實證明我們是對的。 延長

在線時間，然后延長

。 我們最初計劃在4個月內(nèi)對其進行重建，因此需求文檔必須在1個月內(nèi)完成。 當我們的產(chǎn)品經(jīng)理每天超過10點加班時，我們就會按時交付PRD。

從3月開始，預(yù)計將在6月重建。 后來，據(jù)說重建于十月，然后更改為第二年年初，然后更改為三月。 猜猜，最近幾個月？ 明年十月！ 花了一年半的時間。 我們不想看到

項目延遲，但原因并非全都是人為造成的。 我總結(jié)了以下幾點：

在這段時間內(nèi)對銷售和客戶服務(wù)造成很大壓力。 之前已經(jīng)積累了數(shù)百種需求，并且已經(jīng)向客戶承諾這樣做。 盡管我們確實設(shè)計了新系統(tǒng)，但是客戶無法使用它。 起初，當我認為它將在6月完成時，當客戶敦促需求時，我告訴他們新系統(tǒng)已經(jīng)構(gòu)建并且可以使用。 但是后來，銷售部門不敢讓用戶知道我們有兩個系統(tǒng)，因為擔(dān)心他們總是會問新系統(tǒng)什么時候上線。

有一個老客戶超過3年。 在會議期間，他一直堅持說：“我是您的第一批用戶。我提出了這兩個要求，并告訴我我會這樣做。讓我等待。結(jié)果，我等不及了。 2年。我真的等不起�！�

數(shù)據(jù)遷移是一個大漏洞

我們重建的系統(tǒng)是一個全新的系統(tǒng)，與舊系統(tǒng)無關(guān)。 如果用戶要使用新系統(tǒng)，則必須將舊系統(tǒng)的數(shù)據(jù)遷移到新系統(tǒng)，否則客戶信息和歷史病歷將丟失，這肯定不好。

數(shù)據(jù)遷移并不像您想的那么簡單：開發(fā)和編寫腳本，只是分批運行。 在進行數(shù)據(jù)遷移之前，產(chǎn)品經(jīng)理應(yīng)清楚地寫出遷移字段的交叉引用關(guān)系。 我們已經(jīng)撰寫了20多頁文檔，超過1000個字段。 在

中有很多要注意的地方。 簡而言之，讓我們感受一下復(fù)雜性：將文檔交給開發(fā)人員后，每個模塊都負責(zé)數(shù)據(jù)遷移代碼的開發(fā)，并且工作量不小。 到那時，六個或七個開發(fā)項目已經(jīng)寫了一個多月。 最后，客戶可以申請遷移。 我們無法盡快完成遷移。 在正式遷移之前，開發(fā)人員將嘗試多次遷移，并且只有在通過多次測試驗證數(shù)據(jù)正常之后，才會通知客戶正式遷移。 數(shù)據(jù)量少的客戶可能需要2-3個小時才能遷移，而數(shù)據(jù)量大的客戶則需要6-7個小時。

，但我們必須了解兩個系統(tǒng)是不同的，并且不可能進行無縫連接而不會出現(xiàn)任何錯誤。 盡管我們會提前告知客戶遷移的預(yù)防措施，并讓他們通過電子郵件確認已知的風(fēng)險，但我們無法避免遷移后出現(xiàn)的問題，甚至要求他們退回。

完成了數(shù)據(jù)遷移，這表明系統(tǒng)的重建已基本完成。 但是不要太早高興。 測試后有測試。 盡管據(jù)說新系統(tǒng)的功能是成批完成的，并且是成批在線的，但新的上層系統(tǒng)仍然不穩(wěn)定。 沒有真正的用戶，很多問題都不會爆發(fā)。 當我們完成重新配置并與外界正式開展業(yè)務(wù)時，立即啟動如此大的系統(tǒng)的風(fēng)險仍然很大。

快到了新年，診所很忙。 結(jié)果，頁面加載速度非常慢，服務(wù)器異常，并且系統(tǒng)無法每隔一天登錄一次。 客戶的意見很大，在我們的年終研究中給我們的分數(shù)很低。

在新系統(tǒng)中出現(xiàn)錯誤是正常的。 畢竟，測試用例的覆蓋范圍是有限的，并且有許多客戶無法預(yù)料的操作方式。 但是，功能越多，發(fā)生錯誤的可能性就越大； 另一方面，不同的功能分散在不同的開發(fā)中，因此，修復(fù)錯誤后，由于同步不到位，將解決更大的問題。

的那段時間非�？植�。 恐怕在早上到達公司之前，客戶群激增了。 在運行了一個多月之后，新系統(tǒng)終于穩(wěn)定下來，至少不會有大的錯誤。 這時候，我有點放心了。

：客戶總是談?wù)撆f系統(tǒng)。 如果

沒有比較，就不會有傷害。 如果新客戶直接使用新系統(tǒng)，則問題將更少。 遷移的舊客戶有很多問題，因為他們可以談?wù)撆f系統(tǒng)。 例如

，他自己診所的藥劑師要求我在退還藥品后更改要交付的藥品狀態(tài)，因為舊系統(tǒng)是這樣的； 醫(yī)生說我要用病人的醫(yī)療卡