軟工1816 · 作業（十一）事後諸葛亮

阿新 • • 發佈：2018-12-02

專案Postmortem

設想和目標

我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

我們的軟體針對的是福大學子來到食堂會猶豫不決無法決定吃什麼的痛點，希望做出一款軟體可以根據大家的口味幫忙決定吃什麼。其中，使用者只需要回答簡單的問題就可以得到結果，解決了普遍存在的“選擇恐懼症”。軟體的定義還是比較清楚的，這來源於我們生活中自己也遇到的問題。在編寫需求規格說明書時，我們對典型使用者進行了清晰的定義，並且通過問卷調查明確了市場上是存在對於我們的軟體的需求的。

我們達到目標了麼（原計劃的功能做到了幾個？按照原計劃交付時間交付了麼？原計劃達到的使用者數量達到了麼?)

原計劃的目標大部分都已經完成。在實際的開發過程中，我們將一兩個功能放到了beta版本實現。

核心功能有在alpha衝刺結束時按時交付。儘管這次衝刺延期了一星期答辯，但大部分功能在一週前也已經基本完成。

我們的軟體分為學生端和商家端，目前完成了學生端的一個釋出版本，但還沒有公開向使用者釋出。

和上一個階段相比，團隊軟體工程的質量提高了麼？在什麼地方有提高，具體提高了多少，如何衡量的？

上一個階段團隊還沒有開始實際開發。如果說團隊現場程式設計作業是上一個階段的話，我們團隊的軟體工程質量的確有提高。主要體現在以下幾個方面：

任務分工更加清楚了，每個人有明確的分工，大家之間的配合也從無到有，到熟練。

有詳細的文件編寫、程式碼註釋風格要求。
團隊成員的技術水平通過學習得到了一定的提升。

有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

在專案的規劃階段對於一些具體細節的思考度不足。例如討論時覺得都討論的差不多了，但具體實踐時具有難度不得不多佔用一些時間。

改進：提高自己的程式設計能力、以及對於程式語言和框架的熟練度很有必要。

計劃

是否有充足的時間來做計劃?

之前有充分的時間來討論、構想整個軟體的框架，之前佈置的每一項作業——立項報告、需求規格說明書、UML圖繪製——都在不斷地讓整個軟體的輪廓在我們的大腦中變得清晰。

團隊在計劃階段是如何解決同事們對於計劃的不同意見的？

在計劃階段基本沒有什麼不同意見的出現。

你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

基本完成。沒做完的部分有一部分需要較大的工作量而推到了Beta衝刺。

有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

PM很早敲定了一些介面文件，然而後來都廢棄了。介面文件最後由後端實際設計前後端邏輯和設計資料庫的人來完成。可見的確PM不要涉及太具體的程式碼部分的內容。

是否每一項任務都有清楚定義和衡量的交付件?

有的。在Alpha衝刺的初期，全組成員開會最主要就是討論清楚整個業務邏輯，討論完業務邏輯，我們再細分出各個任務，例如前端由幾個頁面組成，後端要寫哪些介面，要設計幾個表等等，這些具體的東西就是具體的交付件。把每一項任務分配給各個人，形成詳細的任務分配。

是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

基本按照計劃執行。有一個意外就是前端組組長請假回家了，導致前端組有三天空檔期，沒有按照原來預想的進度進展下去。（沒辦法預估啊）

在計劃中有沒有留下緩衝區，緩衝區有作用麼?

本來是沒有緩衝區的。但是老師出差，答辯延期了一週。一下子，隊員緊繃的神經都放鬆了許多。然而，這多餘的一週並沒有什麼實際的額外效果。因為我們團隊在一週前也已經基本實現了大部分的功能。新的這一週，PM為團隊新制定了一些額外的目標，但基本上都沒有完成。這一插曲可以反映deadline是第一生產力這個經典的大道理。

將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

感覺目前整個團隊的態勢發展良好，只要維持住目前的節奏就好了。

我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

趙暢：進度管理十分重要，是我們學到的一課。Alpha衝刺進行到一半，這個時候突然有一個額外的作業——團隊現場程式設計完成一個抽獎系統。這之前大家不緊不慢地學習框架學習語言，好像衝刺結束還有好多天，悠哉遊哉。作業下來了，這時候猛然發現大家實際產出程式碼的能力是不足的，於是大家開始爆肝程式設計來解決這個問題。這項風險沒有估計到，只能說too young too simple. Alpha衝刺結束後再翻《人月神話》，第二章寫著“系統程式設計的進度安排背後第一個錯誤的假設是：一切都將運作良好，每一項任務僅花費它‘應該’花費的時間”。想起來是一套，做起來是另一套。好似程式語言、各種工具都易於駕馭，信手拈來，然而實際的開發中是會遇到重重困難的，一定要儘早開始，重視專案的進度（需要PM和組長多把控）。如果重來一遍，一定會要求隊員儘快上手寫程式碼，團隊儘快進入能夠有實際產出的創造階段。

資源

我們有足夠的資源來完成各項任務麼?

有的。前端、後端各有一位小組長。這兩位同學起到了領導作用。學習資源的話，網上的資源十分豐富夠用。伺服器方面，騰訊雲10塊錢一個月的產品也是完全足夠應付目前我們的玩具產品（感謝騰訊雲）。

各項任務所需的時間和其他資源是如何估計的，精度如何?

其實一開始我們敲定了各個任務，但沒有衡量這些任務的完成所需時間，說實話在一開始大家都是零經驗，很難有個確定的數字。

趙暢：不過這個情況在你真正去做了一定的開發後就有所改善，例如在有一天我完成使用者介面後，獲知寫一個敲定好邏輯的介面後臺程式碼需要的時間資料：寫程式碼3個小時，debug+本地測試大概需要兩小時。這部分時間這麼長還是因為對於php和Web框架不熟悉的原因。如果把後臺程式碼部署到伺服器上讓前端對接，在前端不熟練的情況下要額外多出一天的時間預算。這樣子的精度還是足夠的，方便PM和小組長把控進度。也方便其他成員參考，留出多少時間段來進行開發。

測試的時間，人力和軟體/硬體資源是否足夠?

測試的時間和人力不足夠，感覺軟體還有很多缺陷，程式碼也不夠完善。大家學習開發知識的同時還要應付考試，為了完成基本功能就已經費神費心，基本任務完成就感覺已經可以交付了，對於測試和程式碼的健壯性不是太上心。

對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?

PM：是。將頭腦裡的設想付諸實際，其實是一件很難的事，在專案中的體現就是雖然閱讀了《material design》的設計教程，但要真正做出符合設計規範的UI介面比想象中困難很多。

你有沒有感到你做的事情可以讓別人來做（更有效率）?

恆達：前端介面要個確定的Ui和審美規格，重寫3次才用框架的我眼淚掉下來。

嶽昕：有的，我覺得我寫的介面後端組裡的大佬們大概幾分鐘就寫完了，而我花了兩三小時，所以有時候會覺得其實我好像可以更適合web組，畢竟更多的開發經歷是html。大概這就是“群佬我菜”的感覺吧。

有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

恆達：任務deadline的提前量如果能更精確就好了，這樣子有利於專案進度的把控。

變更管理

每個相關的員工都及時知道了變更的訊息?

Alpha衝刺時每兩日一次的站立會議交流算是一個很好的方法。此外，線上交流很方便。如果有線上聊天解決不了的技術細節問題，組內（前端組、後端組）或者整個專案組就會進行團隊現場程式設計來面對面解決。

我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

必須實行的功能就是專案的核心功能和Alpha衝刺實際開發過程中遇到困難較小的功能。

推遲，一般是因為這個功能可能需要較大的工作量而Alpha衝刺的時間所剩無幾，這時大家就做出推遲到Beta衝刺時完成的決定。

專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

在需求規格說明書中的“Alpha驗收標準”有清晰的定義。

對於可能的變更是否能制定應急計劃?

因為需求和專案的具體邏輯是組內製定的，好像也沒有那種變化程度太過急劇或者有提出什麼十分刁鑽的需求以至於要到“應急”的程度吧。

員工是否能夠有效地處理意料之外的工作請求？

專案初期對於任務的劃分基本上涵蓋了整個Alpha衝刺過程。幾乎沒有意料之外的工作變更。一般來說組長佈置給組員的額外的一些小任務（例如多加個按鈕，某個邏輯有點什麼小變更，多寫個介面之類的）團隊成員也可以及時地完成。

我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

感覺這部分我們團隊做的還是不錯的。

設計/實現

設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

在Alpha衝刺的初期，全組成員開會討論清楚整個業務邏輯。但這個不算真正的設計，因為很多內容和細節再實際開發的設計過程中都由重新敲定。

UI原型設計主要由PM來負責。

到了實際編碼前的設計，例如設計邏輯、設計介面和表，主要由趙暢、王源和王彬來完成。（後端組組長和組員以及PM）

設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？

因為都到設計階段了，有什麼模稜兩可的情況出現都會討論清楚並敲定一個最終的方案。

團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？

沒有運用單元測試，但有測試驅動的開發，每個介面都有寫測試用例，雖然可能不是很完善。

有設計UML。UML是很有效的，有的時候對於概念不清淅可以開啟類圖看看，在討論邏輯時開啟用例圖和泳道圖幫助理清思路。

開始的UML和現在的文件肯定是有差別的。例如資料庫的欄位名字、屬性型別，類圖中對於每一個模型的定義或多或少有刪有減等。這些區別的產生是很自然而然的，這裡引用《人月神話》中的一句話：“對於創造者，只有在實現的過程中，才能發現我們構思的不完整性和不一致性。”

我們倒是沒有更新最初的UML文件，這些最初的UML圖都始終作為參考，時不時地被開啟。真正開發時用的介面文件都是重新寫的。

什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

前端Android頁面出現的Bug最多，包括例如動畫效果在某些品牌的手機下會導致應用閃退，某些情況下地圖資料在地圖上繪製不出地標等。原因，就是在大多數情況下（執行的好好的）我們並不清楚是為何導致了這些BUG。可能是由於安卓生態環境的碎片化，各家廠商並沒有遵循原生安卓的系統設計規範。還有就是有些Bug的產生觸及到團隊成員的知識盲區了。

程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

後端程式碼由趙暢負責程式碼複審，審閱程式碼、註釋以及介面文件。後端這方面工作做的還是不錯的。

志煒（前端組組長）：前端組並沒有很嚴格地進行Code Review，大致merge到master大部分都是自己在進行的，部分存在沒有完全遵守程式碼規範的情況。~~我的部分我覺得是沒問題的~~ 個人認為還是時間成本的問題吧，但還是應該規範起來，提高程式碼的整體質量。

測試/釋出

團隊是否有一個測試計劃？為什麼沒有？

本來分佈了一位同學專門負責測試，但最後這個計劃擱淺。

展瑞：因為我本來的任務是負責測試的，但是同時也在後端組做事。期間有一段時間學習了一下測試的相應知識，發現了自己在語言上和一些知識儲備都有相應的不足。開會的時候，基於我們的程式碼比較優秀的前提下，我們覺得測試任務可能不需要採用自動化測試，而且人工來測試。所以測試計劃被拖後，直至死亡。

是否進行了正式的驗收測試？

在後端，每個人都寫好介面文件，都經歷本地的測試，以及伺服器測試，才交付前端進一步開發。在整合系完所有功能後，手動考慮多種情況進行測試驗收。

團隊是否有測試工具來幫助測試？

後端使用postman對每個情況都進行了測試。

團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？

頁面整合完後，在不同的機型上使用，出現了頁面切換出現一些bug，以及部分機型有閃退的情況。

在釋出的過程中發現了哪些意外問題？

釋出了alpha衝刺後的第一個版本，發現了沒有寫logout的按鈕。因為我們有token機制來使得一名登陸的使用者保持兩小時的活躍狀態，超過兩小時未有操作就需要重新登陸。然而我們忘了寫退出登入的按鈕，如果token過期，就永遠無法再登陸，需要重灌APP才可以解決這個問題。是個嚴重BUG。

我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

恆達：假如能重來，會在前端組內更加積極的交流，在前端組內也寫上技術文件，提高前端介面質量。

團隊的角色，管理，合作

團隊的每個角色是如何確定的，是不是人盡其才？

其實只有志煒算是一個熟練工，他作為安卓前端組的小組長是當之無愧的。其他人都是完全的新手，在分配角色時是自願或被指定的，就很隨緣。

當然最後的結果是大家都發揮了自己的作用，大部分人都能做自己擅長的東西。

團隊成員之間有互相幫助麼？

PM：有的。我們的管理方式為三位一體：PM、前端組、後端組。前端組由志煒帶隊，志煒有實際的專案經驗，其他成員有問題都可以請求幫助。

趙暢（後端組組長）：後端組內有形成一份組內自己的技術文件，有任何問題都可以詢問組內成員或者直接查詢這份文件，裡面很多問題都有組內成員積累的可行解決方案，省去了很多百度、google的精力。

志煒（前端組組長）：有的，自己Android也寫的比較多，遇到的坑，爬出來的坑，相對而言多一些吧，同組的遇到問題時，能給予一些幫助。使用過的工具也較多一些，也能給出一些推薦。

當出現專案管理、合作方面的問題時，團隊成員如何解決問題？

討論之後由PM、前後端組長作出決定。

每個成員明確公開地表示對成員幫助的感謝（並且寫在各自的部落格裡）：
我感謝 _______王源______對我的幫助，因為某個具體的事情: ______親自指導git團隊協作如何執行，完美避免了分支出現問題的情況_______。
我感謝 _____所有團隊成員______對我的幫助，因為某個具體的事情: ______能夠相互配合幫忙完成Alpha版本的開發_______。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

文垚（前端組）：我學會了Java和Android開發，特別是對Json資料的使用和理解，並且在隊友的教導下學會的git的使用。如果歷史重來一遍，和我會將回答問題介面的UI設計得再優美一點。

煌偉（Web端）：學到了一個團隊是如何合作執行，每個人如何為團隊更好地貢獻自己的一份力量。如果歷史重來一遍，我會在衝刺之前更加充分學習所需要的技能，而不是在衝刺階段邊學邊做

志煒（前端組組長）：如果是對於我個人而言，可能需要做的就是再肝一些吧，但這學期開頭肝了一個多月，快兩個月吧，所以有點想進入點養生狀態，所以這階段即使有熬夜也沒有特別晚~~就只到一點多兩點左右~~，每天差不多可以說是事情都排得挺滿的，也勉強完成。

總結:

你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?

我們查閱了這個連結來了解CMM/CMMI是什麼。討論後認為，後端組的工作以及達到了已定義級(Defined)，因為後端組有實現技術工作和管理工作的標準化、文件化。後端組組長趙暢放出狂言“隨便來個人我都能培訓到他能寫程式碼”。前端組水平介於初始級別(initial)和可重複級(Repeatable)之間。

你覺得團隊目前處於萌芽/磨合/規範/創造階段的哪一個階段?

後端組：整個團隊目前處於創造階段。

前端組有不同意見：規範階段吧，還有一些東西能再規範一些。

你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?

對比Alpha開啟前，我們專案組最重要的改進是真正的能產出程式碼，以及對於任務需要的時間有一個度量的標準。還有就是大家對於軟體工程裡的一些概念有了切實的體會，例如文件、專案進度管理、前後端的合作等。這些是隻聽理論課體會不來的。

你覺得目前最需要改進的一個方面是什麼?

趙暢（後端組組長）：Alpha衝刺初期花在學習基礎知識和熟悉框架、程式語言上的時間，應該提前去完成，需要提高積極性。

王彬（PM）：應該增強空餘時間的緊迫感，這樣才能避免出現突發事件時的措手不及。

文垚（前端組）：隊員之間的溝通交流還需要進一步的加強，特別是在遇到某些難題時，更應該積極溝通，一起討論出解決方案。

對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

參照《構建之法》P114頁的敏捷開發原則，回顧我們的Alpha衝刺過程，我們做得比較好的有：

第四條：“業務人員和開發人員在專案開發過程中應該每天共同工作”。團隊現場程式設計是常有的事。
第五條：“以有進取心的人為專案核心，充分支援信任他們”。前端組和後端組各有一名組長，分組管理，在他們的帶領下每一個組都把各自的工作完成的不錯。
第六條：“面對面的交流始終是最有效的溝通方式”。例如Alpha站立會議、團隊程式設計、開會討論等等。
第九條：“不斷關注技術和設計，才能越來越敏捷”。後端組有自己內部的技術文件和所有介面設計文件，積累了經驗。

團隊貢獻比例

組員	貢獻比例
趙暢	19
王源	16
王彬	15
志煒	15
文垚	10
恆達	7
煌偉	6
展瑞	6
嶽昕	6

答辯總結

小組現場答辯評分

去掉一個最高分，去掉一個最低分，小組最終得分為79.86分

組號	組名	打分
1	爸爸餓了隊	80
2	拖鞋旅遊隊	79
3	彳艮彳亍隊	84
4	火箭少男100	75
5	起床一起肝活隊	81
6	404 Note Found隊	74
7	第三視角	81
8	小白吃	84
9	我頭髮呢隊	79

第二組的提問

問題1:提給使用者的問題是否多樣化？
答:我們的問題庫中目前有40道問題,每次使用者需要推薦時我們會從問題庫中隨機選出三道題供使用者選擇自己的口味,在beta我們會酌情考慮擴充問題庫的規模.
問題2:商家端的功能會有哪些？
答:商家端將基於web提供服務,目前已經做好頁面的功能有菜品新增頁面,商鋪端註冊登入頁面,之後在beta階段我們會繼續實現使用者口味分析報告頁面
問題3:地圖上的紅點太密集了，也沒有店鋪資訊，能否出線一項展示推薦產品具體位置的食堂的平面圖？
答:地圖上的紅點代表每一個店家的位置,紅點大小的問題我們已經找到了解決方法,在後續會使得定位點的大小隨地圖縮放等級改變.至於用平面圖展示產品具體位置的功能我們已經在alpha版本中有所考慮目前需要手繪食堂平面圖並收集各個店鋪的相對位置來支撐我們的功能.

第三組的提問

問題1:使用者口味是長期形成的，如果使用者的選擇型別一致，會不會出現一直重複推薦某一道菜品的情況？如果會，那麼你們是如何處理矯正的？
答:我們也考慮到這個問題,所以我們在alpha版本的推薦演算法中只針對使用者明確拒絕的菜品更新使用者的口味,並且我們的推薦演算法並不只推薦一道菜餚而是了概率排名前幾位的菜品隨機推薦給使用者,一定程度上預防重複推薦一道菜的情況.
問題2:菜譜更新麻煩，個人感覺如果要進行更新需要一個個去調查，過於麻煩，能否做到與商家合作，通過商家更新資訊來做到實時更新
答:菜品更新只能靠人工這個問題我們也很無奈,不過我們是起步中的開發小組在食堂看來沒有什麼話語權,如果未來我們得到其他方面的資源支援會考慮與商家合作更新我們的菜品資訊.
問題3:請問你們提供給使用者測試的題目有多少呢？真的能夠準確的測試到嗎？
答:我們的問題庫中目前有40道問題,每次使用者需要推薦時我們會從問題庫中隨機選出三道題供使用者選擇自己的口味.使用者的口味是一個主觀的問題,我們只能力求通過我們的問題獲取使用者當時的一個口味偏好.

第四組的提問(暫無)

問題1:
答:
問題2:
答:
問題3:
答:

第五組的提問(暫無)

問題1:
答:
問題2:
答:
問題3:
答:

第六組的提問

問題1:您好，你們的PPT很是精美規範，具體介紹了你們的演算法和程式碼規範，這方面值得借鑑。但UI介面設計就略顯遜色，有想過在這方面進行改進嗎。
答:分兩方面回答:1.PM個人喜歡簡潔大方的UI設計這在一定程度上反映到了產品的UI設計上,但美醜仁者見仁智者見智. 2.產品目前處在alpha開發階段我們會在後期針對UI進行相應改進以期符合主流審美.
問題2:您好，你們的PPT顯示的實現功能看起來有點少，你們以前設下的功能還有多少未實現，可以簡要說明一下嗎，如果已經全部實現，可以說下後續是否會增加附加功能嗎?
答:在alpha開發階段我們將開發精力放在了產品核心功能--菜品推薦上,在之後我們的安卓端預計還會新增美食地圖的內容,店鋪風雲榜功能,以及提供使用者瀏覽推薦歷史記錄的功能,這部分功能的介面已經在alpha階段的後端設計中做了鋪墊,會在beta繼續完場上述功能.
問題3:你們軟體的商家功能還未實現，可見你們的進度稍慢，後續你們要調整自己隊的隊員分工和完成時間，來提高進度?
答: 在alpha階段我們的前端將主要精力放在了開發安卓端應用上,但商鋪端的頁面我們也已經基本設計完成但未在alpha答辯中展示出來:請看我們的商鋪端頁面

第七組的提問

問題1:是否考慮過提供菜品的相關介紹？
答:鑑於並沒有現成的福大各個食堂的菜品介紹資料來源,而憑我們目前的力量對每道菜新增菜品介紹也並不現實,所以我們暫時不會考慮新增菜品介紹的功能.
問題2:地圖有很多地標，可是並不知道這些具體指示的是哪一家店？
答:鑑於目前資料庫中並沒有足夠的使用者資訊,我們會在beta階段將地標設定成顯示商品資訊的按鈕,一旦按下地標就會顯示出該商家的店鋪資訊與熱門菜餚.
問題3:如果提供多個備選的菜品我還是不知道選哪一個怎麼辦?
答:我們的app只能做到提供就餐建議,最後使用者吃什麼的最終決定權屬於使用者

第八組的提問

問題1:推薦演算法是否需要使用者的用餐資料？
答:我們的推薦演算法會參考使用者的過往選擇記錄,並根據每個使用者的偏好生成使用者的口味畫像,在推薦時會依據使用者口味進行推薦決策
問題2:問答的問題與使用者的使用喜好相關嗎？
答:我們的問題庫中目前有40道問題,每次使用者需要推薦時我們會從問題庫中隨機選出三道題供使用者選擇自己的口味
問題3:有沒有開發附加功能以增加使用者黏度的計劃？
答:我們的產品理念是將app做成一款方便的工具,當用戶有不知吃什麼的選擇困難時就會想起我們的app,而在其他時間我們也並不想搶佔使用者寶貴的時間

第九組的提問

問題1:PPT已經很完整的展示了功能，但是感覺UI介面設計比較簡陋，在今後打算怎麼改善？
答:分兩方面回答:1.PM個人喜歡簡潔大方的UI設計這在一定程度上反映到了產品的UI設計上,但美醜仁者見仁智者見智. 2.產品目前處在alpha開發階段我們會在後期針對UI進行相應改進以期符合主流審美.
問題2:PPT已經很完整的展示了功能，但是感覺UI介面設計比較簡陋，在今後打算怎麼改善？
答:同上
問題3:在推薦菜品這方面打算怎麼處理？
答:我們將繼續跟進商家的菜品更新