在接到设计智慧餐厅管理端之前，和Boss聊了一下，了解了这个产品的目的是为了方便餐厅老板，能够实时远程查看餐厅的营收状况，此外还希望有相关的数据能够辅助餐厅管理者更好经营餐厅。
所以先思考内容，提取出要求的关键词就是“远程查看”“营收状况”“辅助经营”。公司定位这款是基于微信端开发（因为目前来说功能相对简单，软件体量小，交互轻盈，不适合APP这种功能复杂，频次高，重交互的软件）数据内容从智慧餐厅的服务端提取，在提取前，根据市场上的餐饮管理者对餐厅数据的调查，管理层面对数据的考量再结合产品本身所提取到的数据，推演算法，得到了一组数据，成为产品的基础内容，然后思考数据的呈现及相关的功能，将数据分成了日常数据和查询数据，如营业额是日常数据，用户青睐随时能一眼就查看到的，会员走势是查询数据，需要选定商家（因为存在分店）和时间段来进行检索的，得出的结果也以折线、饼状为主，清晰表达，最后通过思考任务的流程，设定交互，我们的产品任务流程基本都是选定数据→进行搜索→获取数据所以层级简单，考虑到分店数据的展现，所以层级最好不超过三层，要求轻量扁平，操作简单。目前产品几近上线，反响还行。
后面想到其中的一个关键性调整处理，是在一个“毛利”问题上面，毛利=菜品销售额-菜品成本刚开始这一块是这样思考的：菜品销售额是自行设定的，而菜品成本是随市场波动的，每日的食材成本都可能不同。
我的做法是将制备每道菜的食材用量图，因为一道菜的做法和分量是大致既定的，由多少量的食材组合而成，再根据这些食材的单价来计算这道菜的实际成本，可得出一个大致的范围，如：一道红烧鱼的成本=2.5kg鲤鱼*鲤鱼单价+0.2kg香蒜&香蒜单价，每个餐厅的进货量是可预估和计算的，进来的肉类，蔬菜可做多少菜品当然也有所分寸，当然需要灵活处理，········
这样做的好处就是，食材虽然每天都变化，但是只需要录入一次，菜品的成本即随成本的调整而做了动态变化，满足了数据的可改变性，也保证了管理端数据的准确性，然而最后交付功能设计方案的时候，这个功能还是被Pass了·····
再和开发沟通的时候发现在做后台的时候根本没有进行相关功能设定（意思就是写死了），产品面临上线，这样的功能耗时可能较长，无法满足，当再三反馈功能对产品的必要的时候，Boss介入，又拟定了一种简单粗暴的毛利计算方式，以当天的总销售额和总支出做减法，然后…完了……
当问及，这样的设定会导致出现每天的“毛利”有大有小，甚至可能某一时间段为负数（因为可能购入大量菜品，但是还未到营业时间，或营业额暂时没有超过当天总支出·····），破坏数据真实性，影响用户判断的时候，boss解释说已经调查过其他产品都是这么做的，我们照旧就好····
尴尬·····
