在接到設(shè)計智慧餐廳管理端之前晾腔，和Boss聊了一下遗座，了解了這個產(chǎn)品的目的是為了方便餐廳老板豆瘫，能夠?qū)崟r遠(yuǎn)程查看餐廳的營收狀況吞鸭，此外還希望有相關(guān)的數(shù)據(jù)能夠輔助餐廳管理者更好經(jīng)營餐廳寺董。
所以先思考內(nèi)容，提取出要求的關(guān)鍵詞就是“遠(yuǎn)程查看”“營收狀況”“輔助經(jīng)營”刻剥。公司定位這款是基于微信端開發(fā)（因為目前來說功能相對簡單遮咖，軟件體量小，交互輕盈透敌，不適合APP這種功能復(fù)雜盯滚，頻次高，重交互的軟件）數(shù)據(jù)內(nèi)容從智慧餐廳的服務(wù)端提取酗电，在提取前，根據(jù)市場上的餐飲管理者對餐廳數(shù)據(jù)的調(diào)查内列，管理層面對數(shù)據(jù)的考量再結(jié)合產(chǎn)品本身所提取到的數(shù)據(jù)撵术，推演算法，得到了一組數(shù)據(jù)话瞧，成為產(chǎn)品的基礎(chǔ)內(nèi)容嫩与，然后思考數(shù)據(jù)的呈現(xiàn)及相關(guān)的功能寝姿，將數(shù)據(jù)分成了日常數(shù)據(jù)和查詢數(shù)據(jù)，如營業(yè)額是日常數(shù)據(jù)划滋，用戶青睞隨時能一眼就查看到的饵筑，會員走勢是查詢數(shù)據(jù)，需要選定商家（因為存在分店）和時間段來進行檢索的处坪，得出的結(jié)果也以折線根资、餅狀為主，清晰表達(dá)同窘，最后通過思考任務(wù)的流程玄帕，設(shè)定交互，我們的產(chǎn)品任務(wù)流程基本都是選定數(shù)據(jù)→進行搜索→獲取數(shù)據(jù)所以層級簡單想邦，考慮到分店數(shù)據(jù)的展現(xiàn)裤纹，所以層級最好不超過三層，要求輕量扁平丧没，操作簡單鹰椒。目前產(chǎn)品幾近上線，反響還行呕童。
后面想到其中的一個關(guān)鍵性調(diào)整處理漆际，是在一個“毛利”問題上面，毛利=菜品銷售額-菜品成本剛開始這一塊是這樣思考的：菜品銷售額是自行設(shè)定的拉庵，而菜品成本是隨市場波動的灿椅，每日的食材成本都可能不同。
我的做法是將制備每道菜的食材用量圖钞支，因為一道菜的做法和分量是大致既定的茫蛹，由多少量的食材組合而成，再根據(jù)這些食材的單價來計算這道菜的實際成本烁挟，可得出一個大致的范圍婴洼，如：一道紅燒魚的成本=2.5kg鯉魚*鯉魚單價+0.2kg香蒜&香蒜單價，每個餐廳的進貨量是可預(yù)估和計算的撼嗓，進來的肉類柬采，蔬菜可做多少菜品當(dāng)然也有所分寸，當(dāng)然需要靈活處理且警，········
這樣做的好處就是粉捻，食材雖然每天都變化，但是只需要錄入一次斑芜，菜品的成本即隨成本的調(diào)整而做了動態(tài)變化肩刃，滿足了數(shù)據(jù)的可改變性，也保證了管理端數(shù)據(jù)的準(zhǔn)確性，然而最后交付功能設(shè)計方案的時候盈包，這個功能還是被Pass了·····
再和開發(fā)溝通的時候發(fā)現(xiàn)在做后臺的時候根本沒有進行相關(guān)功能設(shè)定（意思就是寫死了）沸呐，產(chǎn)品面臨上線，這樣的功能耗時可能較長呢燥，無法滿足崭添，當(dāng)再三反饋功能對產(chǎn)品的必要的時候，Boss介入叛氨，又?jǐn)M定了一種簡單粗暴的毛利計算方式呼渣，以當(dāng)天的總銷售額和總支出做減法，然后…完了……
當(dāng)問及力试，這樣的設(shè)定會導(dǎo)致出現(xiàn)每天的“毛利”有大有小徙邻，甚至可能某一時間段為負(fù)數(shù)（因為可能購入大量菜品，但是還未到營業(yè)時間畸裳，或營業(yè)額暫時沒有超過當(dāng)天總支出·····）缰犁，破壞數(shù)據(jù)真實性，影響用戶判斷的時候怖糊，boss解釋說已經(jīng)調(diào)查過其他產(chǎn)品都是這么做的帅容，我們照舊就好····
尷尬·····
