С чего начать планирование системы управления кафетериями?

Question

[kamandor]

Мы хотим создать систему управления рестораном/и, в интернете много информации на эту тему. У нас есть предложения от программистов, которые все хотят сделать. Однако, знающие люди пишут (мы и сами это понимаем), что нужно начать с планирования такой системы. Вопрос, кого нужно искать и с чего лучше начать?

Comments

[Александр Нестеров]

У нас есть предложения от программистов, которые все хотят сделать.

Однако, знающие люди пишут

Просто для понимание - в какой области они "знающие"? Я так понимаю, это не программисты?

[Петр]

А что значит упарвление рестораном?
К примеру:
- Найм сотрудников, приготовление блюд почти не реально автоматизировать.
- Учет / расходов и доходов - уже есть 1С тот же,

R-Keeper себя и то называет - автоматизации ресторанов.

[Константин Нагибович]

Вы не программистов спрашивайте, а бизнес - что они хотят делать с помощью этой системы.

[mayton2019]

Управление ... оно ведь разное бывает. Есть управление персоналом. Для этого один софт.
Потом - склад логистика. Потом управление тех-процессом. Печи. Техника. Потом клиенты - заказы.

Вот видишь сколько всяких управлений есть.

Answer 1

[Максим]

Самый лучший способ это Event Storming! Это как раз будет связующее звено для понимания и вами и программистами. Конечно, лучше найти такого специалиста - Архитектора.

По сути техника Event Storming — это воркшоп с простой структурой, на котором эксперты по предметной области и разработчики совместно исследуют эту самую предметную область. По мере исследования участники раскрывают всё больше неопределенности и скрытой сложности, сверяют предположения с реальностью и снижают влияние предположений на качество продукта.

Event Storming применяется в исследованиях клиентского опыта, проектировании новых сервисов, получении знаний о работе legacy-систем, моделировании сложных предметных областей и проектировании микросервисной или событийной архитектуры.

Техника предусматривает итеративность. Модель предметной области можно постепенно детализировать (уточнять) с каждой сессией. Участники меньше утомляются, сессии можно посвящать отдельным вопросам и приглашать нужных специалистов, брать паузы для исследований.

Из своего опыта могу сказать, что ни раз даже помогало увидеть полную картину своего бизнеса. Сразу вырисовывается организационная структура, разграничение ответсвенностей и другое. Проводится довольно быстро. Это легче чем написать ТЗ. После проработки Event Storming можно уже давать задания для программистов, дизайнеров, маркетологов и др. Очень полезная техника для автоматизации. Всегда проще сначала нарисовать бизнес, а потом его автоматизировать.

Если вы автоматизируете уникальный продукт, где есть своё ноу хау, то без этой техники не обойтись. Ведь выбирая что-то за основу и копируя её вы не доносите ценность вашего бизнеса. Для примера, ваша ценность может быть вовсе не в качественных и вкусноприготовленных блюдах, а в грандиозном сервисе подаче этих блюд. Тогда автоматизацию следует делать с большим упором на услуги. Или ваш ресторан наоборот может иметь самый быстрый сервис и подачу блюд. В этом случае упор будет другим. А может быть у вас в целом подход будет заключаться в управлении другими ресторанами (сеть). В общем брать что-то за основу и тем более слушать программистов не стоит. Программисты делают всегда то, как им удобнее и проще. Для вас же важно решить свои проблемы. Удвоить бизнес.

Answer 2

[Drno]

Если Вы хотите это сделать для своей сети - то лучше воспользоваться готовым, iiko например, это будет наиболее дешёго.

А спросить по идее надо у сисадмина, который это будет обслуживать

И не понятна формулировка - "система управления рестораном". Что конретно требуется и чем конкретно надо управлять?

Comments

[Максим]

Не очень понимаю причем тут сис админ в проектировании системы…) Можно ещё спросить тогда у дизайнера, который все это будет рисовать. Сис админ это всего лишь одно звено. И то это можно отдать на аутсорсинг.

[Drno]

Максим, угу. Отдайте и посмотрите что выйдет))
Если что имелся ваиду нормальный грамотный сисадмин с 10 летним опытом работы с рестиками

[Максим]

Drno, я не спорю, что специалисты должны быть хорошие. Но причем тут сис админ? Если на этапе проектирования спроектируют такой проект, который не масштабируется, то тут хоть какой будет сис админ он не сделает из этого микросервисы. При плохой архитектуре всё это будет работать очень печально с хорошими нагрузками. Никакой сис админ тут не поможет.

Системный администратор, или админ — это специалист, который поддерживает бесперебойную работу и безопасность сайта, приложения, локальной сети компьютеров и всего ПО внутри компании.

Основные задачи системного администратора: Установка, настройка и обновление операционных систем Windows и Linux (в IT-командах востребована вторая), а также другого ПО и инфраструктуры, необходимых для работы компании.

Системный админ, например, не ответит на чем писать каждый сервис. На go, php, Java… Какой выбрать фреймворк и библиотеки. Сис админ работает с установкой всего этого, а не с выбором всего этого в зависимости от задачи. Он так же как и программист сделает как ему удобно. Ему плевать на то, что код станет не поддерживаемый, потому что в нем заложен CRUD подход в разработке, а не DDD. У сис админа нет задачи снизить расходы на разработку и поддержание этого ПО. На все эти вопросы отвечает Архитектор ПО (Software Architect). Возможно вы имели его? Тогда соглашусь с вами.

[kamandor]

Максим, спасибо, действительно сисадмин вообще никакого отношения не имеет. Он лишь настраивает серверную часть. Но и правда в том, что он должен быть грамотным.

[Максим]

kamandor, грамотность касается всех членов команды продукта, а не только именно его) Иначе смысл этой работы. Если будет не грамотный дизайнер, то он сделает плохой UI/UX, которым будет неудобно пользоваться. Если у вас будет плохой программист, то он может где-то ошибиться и деньги будут идти не туда, куда надо.

Автор ответа предлагает спросить с чего начать планирование подобной системы у сис админа. Это точно не то, с чего нужно начинать. Здесь суть заключается в том, что любого специалиста, в том числе и сис админа, можно будет заменить, если он не справляется или делает не качественно. А вот если изначально была заложена неправильная архитектура тут уже придётся менять многое. Архитектор - это проектировщик домов, разработчик - это строитель этого дома, а сис админ всего лишь обслуживающая компания.

[Drno]

kamandor, в Вашем вопросе есть неясность - Вы это собственно "ресторан", которому нужна система управления (тогда мой ответ верен, т.к. Вашему же сисадмину это обслуживать и поддерживать, и отталкиваться надо от его рекомендаций), или дядя с баблом который хочет выпустить продукт на рынок(тогда мой ответ менее верен, но сисдамин всё равно же понадобится)

[Drno]

Максим, я исходил из того, что люди хотят сделать систему управления для своего ресторана или сети ресторанов.
В таком случае это всё должнен планировать сисадмин. В моем понимаю нормальный сисадмин, после общения с "заказчиком" и прогерами спокойно определит на чем лучше писать, какую архитектуру делать, будут это микросервисы или нет, итд итп...
просто потому, что эту всю лабуду, которую там напрограмят, обслуживать в итоге ему, и звиздюлей в случае косяков получать тоже)

Да, я считаю что нормальный сисдамин является в том числе архитектором и как минимум понимает код на питоне и распространенных языках(только примерно понимает, не обязательно пишет)

Восможно в современном мире это уже называется как то по другому)

[Максим]

Drno, Вы как раз говорите всё то, что делает Архитектор ПО) Пишите вы более менее правильно, но путаете специалистов. Возможно в Вашей команде был человек которого все называли сис админом, но он выполнял несколько функций. Я ещё раз говорю, что проект может быть в облаке и какую систему он тогда там будет настраивать) В Amazon Yandex всё делается через UI интерфейс, например. Чтобы развернуть базу надо просто указать размер хранилища и другие настройки, которые делаются через UI и у вас уже готовая база данных. При этом Ваша база будет очень надёжная, быстрая, отказоустойчивая, может легко масштабироваться и так далее. Сис админу же нужно будет всё это делать в ручную.

[Drno]

Максим, да, можно действительно пользоваться сервисами амазон или яндекса.
но это должен кто то настроить, и кто то обслуживать потом, само оно всё равно не работает, как по волшебству)
видимо я мало денег беру, раз я оказывается еще и архитектор)))

[Максим]

Drno, обслуживание полностью Яндекса, если о внутреннисиях говорим. А о настройке да, но сделать это на много проще. Любой программист сможет. И возможно даже сам клиент. Не просто так за это берут больше денег, чем настраивали бы сами) В этом и суть облака.

Если вы исполняете роль архитектора, то да. Схороните архитекторы берут много. Я знаю таких лично. Но и ответственность на них совершенно другая, а не сравнимая сис админом. В общем то за это им и платят больше. Можно делать всё что делает Архитектор, при этом не отвечать за всё наделанное. Тогда и получает как обычный программист. На маленьких проектах зачастую вообще один программист сочетает в себе все функции и front dev и back dev и design dev …

[Drno]

Максим, ну у меня так и получается, 1 за всех... к счастью без написания кода))
по крайней мере планировать как будет взаимодествовать софт между собой и конечными точками, планирование развертки на серверах, что куда, зачем... я вот хз входит ли это в архитектуру.
К примеру планирование всей технической части сети ресторанов, всего софта и его взаимодействия.

Либо "сборка" впн сервиса под "ключ", из опенсорсного, ну и портал \ авторизашки \ бота ТГ понятно что програмеры пишут, как и API.

насчет облака и "сами смогут" - возможно у нас разные програмисты и заказчики, я пока таких не встречал))

[Максим]

Drno, результат работы архитектора это схемы в Miro или Lucid, различная техническая документация, расчёты, разработка задач, планирование с точностью до часов их реализации, выбор стека для разработки и так далее. В целом можно почитать. Не думаю, что Вы полностью взяли на себя роль Архитектора ПО. Скорее всего вы просто имеете небольшой проект, где приходится делать многие, то есть совмещать, в том числе и работу Архитектора. При этом вы вряд ли даже делаете расчёт доступность сервисов, различные диаграммы, техническую документацию и т.д. На небольших проектах на это всё забивают.

1. Либо "сборка" впн сервиса под «ключ"
Тут не понятно что имеется ввиду. Он может иметь продажи этих ВПН, а может и не иметь. В общем тут нюансов много. Но в целом похоже как раз на работу сис админа.

2. Портал авторизации Бота не особо требует Архитекторских знаний. В целом тоже больше под программиста смахивает.

насчет облака и "сами смогут" - возможно у нас разные програмисты и заказчики, я пока таких не встречал))

Если мы говорим о Backend Developer уровня Middle и Senior, то он вполне себе не то что бы сможет, а должен. Хотя бы подготовить себе среду для разработки. А вот на счёт заказчиков всё не однозначно. У меня был заказчик, который строил себе сервера крупные и у него была система развернута на ПО, за которое он платил 280 тысяч в год. При этом полностью сам всё делал и вносил мелкие правки в код. В основном по тексту UI. Другой заказчик сам развертывал базу в Digital Ocean и вообще не давал доступ к ней, так как боялся за безопасность. Он же самостоятельно настраивал CDN для своего сайта через Selectel. Проекты до сих пор живут. Так что такие заказчики есть. Другое дело у Вас их нет. Но я регулярно сталкиваюсь. В целом я и сам во всём разбираюсь. Постоянно совершенствуюсь. Это интересно.

Answer 3

[Everything_is_bad]

У нас есть предложения от программистов, которые все хотят сделать.

В этом предложении должно быть ТЗ, либо информация, каким путем оно будет получено.

Answer 4

[Dmtm]

У нас есть предложения от программистов, которые все хотят сделать.

пускай делают, все равно потом переделывать
по опыту - лучшая стратегия - быстро сделать первую версию, отладить на ней бизнес процессы, доформулировать ТЗ и через год полностью переписать... а потом, года через 3 - переписать еще раз

Comments

[kamandor]

Спасибо. Думаю вы правы на все сто, так наверное и бывает всегда:)

[Adamos]

Стратегия чревата ситуацией "так истерически слежалось": сначала сделали через жопу, потом никто не решился переделать, а в итоге все привыкли работать через жопу, и переделать процесс уже сложнее, чем в принципе начать новый бизнес с нуля...