Talk:SharpResto

Analüüsi retsensioon projektile SharpResto

Projekti idee on väga hea: eesmärgiks on restorani teenindusprotsessi kiirendamine, ilma et teenindaja ametikoht ära kaoks või oma tähtsust kaotaks. Projekti autorid on välja toonud, et teenindaja saaks tänu sellele rakendusele keskenduda rohkem klientidega suhtlemisele ning lisamüügile. Suhtlus teenindajaga on restoranikülastuse üks oluline osa ning on tervitatav, et seda osa ei taheta täielikult ära kaotada, vaid seda soovitakse parandada ning seeläbi potentsiaalselt ka ettevõtte kasumit suurendada.

Jäi silma, et lehte kliendi veel kinnitamata tellimusega nimetatakse ostukorviks. Kuna termin „ostukorv“ seostub esmalt e-poega, siis ehk tasuks siin loomingulisemalt läheneda ja nimetada vastav osa ümber kuidagi „restoranilikumaks“.

Kliendil on võimalus maksta sularahas või makseterminali kaudu, kuid ideaalis võiks rakendus sisaldada ka võimalust maksta kas läbi rakenduse pangalingiga või ühendada rakendusega oma krediitkaart – loomulikult on arusaadav, et antud aine raames pole sellise lahenduse valmistegemine oluline ega ka vajalik, kuid reaalse rakenduse korral oleks selline võimalus mugav.

Võimalike probleemide all oleks võinud täpsemalt kirjeldada, millise rakenduse osa arendamise juures tehnilistest oskustest puudu võib tulla.

Analüüsis on põhjalikult kirjeldatud rakenduse erinevaid vaateid ja need joonistega illustreerinud. See näitab, et töö autorid on projekti struktuuri põhjalikult läbi mõelnud. Samuti on analüüsitud andmebaasi võimalikku struktuuri ja lisatud joonis, mis samuti kinnitab analüüsi põhjalikkust.

Rakenduse kasutajal on võimalik valida kasutajatüüp. See on vajalik funktsionaalsus, kuid reaalses restoranis võiks siinkohale mõelda sellele, et restorani külastajale võiks kättesaadav olla ainult kliendi vaade isegi hoolimata sellest, et erinevad vaated on kasutajanime ja parooliga piiratud. Jällegi on arusaadav, et vaadete piiramine antud aine raames tehtavas projektis ei ole vajalik.

Mida teeksime teistmoodi?

• Menüüs objektil (tabel menu_items) võiks olla lisatud ka informatsioon selle kohta, kas tellimus läheb kööki ja teenindajale või ainult teenindajale (näiteks jookide tellimisel ei ole vaja tellimust tavaliselt kööki saata).
• Arve jagamise võimalus võiks olla lihtsam. Kui arve jagada kõige alguses ehk rakendus küsib, mitu arvet tuleb koostada, ja klientide nimesid (kes maksab, mille eest maksab) ning kui keegi midagi tellib, siis rakenduses võiks saada kohe valida, kelle nimele see toit läheb ja teenindajal on mugavam ka klientide poole pöörduda. Tihti juhtub nii, et kui enne tellimust ei ütle, et maksate eraldi, siis arvet ei saa (või ei taheta) oma süsteemis enam jagada.

Kas ma ise kasutaks lahendust?

Rakendus peab olema väga mugav ja kiire ning UI peab olema lihtne ja arusaadav (eriti vanematele inimestele), et seda kasutada (veidi sarnane iseteeninduskassade kasutamisele, aga restoranis teenindajaga suhtlemine käib sageli asja juurde ja on elamus omaette). Hea oleks lisada veel lisafunktsioone, et rakenduse kaudu pakkuda ka muud kui ainult tellimine.

Mida võiks veel rakendusele lisada:

• Teenindaja/koka hindamine
• Roogade/jookide hindamine
• Top 3/5 populaarsemad road/joogid igas kategoorias
• Võimalus vaadata, kes on kokk täna ja mis on tema parimad/lemmikroad

Mõned probleemid, mida me nägime.

Kuna tegemist on restoraniäriga tuleb mainida, et igas kohas on oma menüü ning sellest järeldub, et iga restorani jaoks tuleb luua oma andmebaas toodetega. Võiks kirjeldada, kuidas autorid kavatsevad sellega hakkama saama: kas nad pakuvad ainult tarkvara (platvorm) või lõpp-produkti koos valmismenüüdega iga restorani jaoks.

Kokkuvõte

Kokkuvõttes on tegemist tugeva ning põhjalikult läbimõeldud analüüsiga. Kahtlemata saaks sellise rakenduse abil restoranide tööprotsessi optimeerida. Üldiselt tundub projekt huvitav ja teostatav. Skoop paras. Üldine arusaadavus hea, korralikult läbimõeldud funktsionaalsus ja andmebaas.

Retsenseeris meeskond TeravMDB[[1]] 12.11.2017