Айтишники vs производственники
С развитием технологий большее преимущество получают стартапы, сочетающие знания о разработке с пониманием предметной области, где будет применятся это ПО.
Не всегда разработчикам приходится создавать продукт, в котором они сами являются целевой аудиторией, например, тот же агрегатор такси или сервис по доставке еды. (выделить розовым)
При создании сложного ПО, внедряемого на промышленных объектах, нехватка знаний о производственных процессах приводит к тому, что разработчики не могут предложить Клиенту качественное решение. То, что казалось им удобным и правильным не всегда оказывается удобным и необходимым для Пользователя.
Иногда бывает, команда так увлекается выявлением проблем Пользователя, что придумывает несуществующие и доблестно пытается их решить. В результате, Клиент получает запутанный интерфейс, множество лишних функций и непрозрачную логику. Что не есть “Well done”.
Андрей Чернышов,CEO Simple Company
Мы Deeptech-стартап, разрабатываем ПО для крупных промышленных предприятий. При проектировании нашей системы Simple CMMS я заметил, как ребята из команды переходят от процесса поиска болей Клиента к процессу генерации этих болей, начинают искать решение проблемы, которой быть не может. Этот звоночек послужил поводом для проведения первого масштабного Synk(a) со всей командой. Детально прошлись, как устроен производственный процесс по аналогии с работой IT-компании, за что отвечает тот или иной специалист на производстве и какие функции он бы выполнял в команде разработчиков. В результате получился такой полушутливый словарик.
Механики на производстве — это backend-программисты, они отвечают, чтобы все работало и нигде ничего “не упало”.
Frontend-разработчики — это специалисты АСУТП, автоматизации систем управления технологическими процессами. Отвечают, где что надо нажать или повернуть, чтобы все заработало.
Энергетики предприятия, без сомнения, DevOps’ы. Задача первых — следить за электросетями, не допустить перегрузки и перерасхода энергии. Последних — автоматизировать процессы внутри программы, чтобы они не требовали много ресурсов и не перегружали главный процессор и операционку.
Метрологи — это QA-шники: их задача измерить, проверить, протестировать и найти отклонения.
Начальник смены — это Scrum master: распределяет задачи и контролирует их выполнение.
Инженер-технолог в IT-компании стал бы Product owner’ом. Они оба отвечают за выпускаемый командой продукт.
Бригадир — это Lead, тот, кто ведет за собой команду и вовремя ее мотивирует.
Проектировщик продукции — стал бы бизнес-аналитиком и следил, чтобы все было сделано «по уму»
Любой объект на производстве — location.
Продукция самого завода — код, который пишут разработчики.
Хочется в очередной раз подчеркнуть, что современным IT-компаниям мало просто уметь писать код, им важно понимать те самые насущные проблемы, с которыми живут каждый день пользователи продукта. И порой такие проведенные аналогии облегчают вход к этим знаниям. Если интересно узнать, какие задачи решаем мы, Welcome в наш телеграм-канал.
