Как я сравнил нашу команду айтишников с производственниками
С развитием технологий большее преимущество получают стартапы, сочетающие знания о разработке с пониманием предметной области, где будет применятся это ПО.
Не всегда разработчикам приходится создавать продукт, в котором они сами являются целевой аудиторией, например, тот же агрегатор такси или сервис по доставке еды
При создании сложного ПО, внедряемого на промышленных объектах, нехватка знаний о производственных процессах приводит к тому, что разработчики не могут предложить Клиенту качественное решение. То, что казалось им удобным и правильным, не всегда оказывается удобным и необходимым для Пользователя.
Иногда бывает, команда так увлекается выявлением проблем Пользователя, что придумывает несуществующие и доблестно пытается их решить. В результате, Клиент получает запутанный интерфейс, множество лишних функций и непрозрачную логику. Что не есть “Well done”.
Мы Deeptech-стартап, разрабатываем ПО для крупных промышленных предприятий. При проектировании нашей системы Simple CMMS я заметил, как ребята из команды переходят от процесса поиска болей Клиента к процессу генерации этих болей, начинают искать решение проблемы, которой быть не может.
Этот звоночек послужил поводом для проведения первого масштабного Synk(a) со всей командой. Детально прошлись, как устроен производственный процесс по аналогии с работой IT-компании, за что отвечает тот или иной специалист на производстве и какие функции он бы выполнял в команде разработчиков. В результате получился такой полушутливый словарик.
Механики на производстве — это backend-программисты, они отвечают, чтобы все работало и нигде ничего “не упало”.
Frontend-разработчики — это специалисты АСУТП, автоматизации систем управления технологическими процессами. Отвечают, где что надо нажать или повернуть, чтобы все заработало.
Энергетики предприятия, без сомнения, DevOps’ы. Задача первых — следить за электросетями, не допустить перегрузки и перерасхода энергии. Последних — автоматизировать процессы внутри программы, чтобы они не требовали много ресурсов и не перегружали главный процессор и операционку.
Метрологи — это QA-шники: их задача измерить, проверить, протестировать и найти отклонения.
Начальник смены — это Scrum master: распределяет задачи и контролирует их выполнение.
Инженер-технолог в IT-компании стал бы Product owner’ом. Они оба отвечают за выпускаемый командой продукт.
Бригадир — это Lead, тот, кто ведет за собой команду и вовремя ее мотивирует.
Проектировщик продукции — стал бы бизнес-аналитиком и следил, чтобы все было сделано «по уму».
Любой объект на производстве — location.
Продукция самого завода — код, который пишут разработчики.
Это то, что пришло мне на ум, но может вы сможете его дополнить?
Для чего я вообще это рассказываю? Хочется в очередной раз подчеркнуть, что современным IT-компаниям мало просто уметь писать код, им важно понимать те самые насущные проблемы, с которыми живут каждый день пользователи продукта. И порой такие проведенные аналогии облегчают вход к этим знаниям. Если интересно узнать, какие задачи решаем мы, Welcome на наш сайт или в телеграм-канал.
Главное фото сделано в Нижнем Новгороде, если не ошибаюсь)
Не ошибаетесь ) Оно сделано во время конференции ЦИПР в июне
"вход к этим знаниям" обеспечивает бизнес аналитик из области, а остальное это экономия на качестве. Бедным разрабам и так есть куда погружаться в своей специальности, им еще не хватало изучать технологии заказчиков.
Наших разрабов точно нельзя назвать бедными) Просто пилить софты, не разбираясь в предметной области — это не наш подход. Мы не штампуем программные продукты сегодня для одной, а завтра для другой доменной области, сфокусированы на внедрении передовых решений исключительно для наших коллег из промышленного сектора, откуда 70% нашей команды начинало свой профессиональный путь.
P.S. Данная встреча, как вы правильно отметили, была по большей части для бизнес-аналитиков. Коллектив у нас пока небольшой, до 30 человек, но начиная от сотрудников финансового (менеджеров по грантам и субсидиям) до маркетингового отдела и R&D, сотрудники приходят в Simple не только за зарплатой — их в том числе мотивирует миссия компании. Они хотят вникать в то, что мы делаем и расширять кругозор. Пожалуй, можно уже с уверенностью сказать, что мы этим гордимся.
У нас отличная команда разработчиков с минимальным опытом от 13 лет, компетентных реализовывать сложные масштабные проекты для промышленных предприятий. Всегда рады новым специалистам, потому что расширяемся стремительно. В том числе со следующего месяца начнем сотрудничать и со стажерами. Направить резюме нам можно на почту hr@simplecompany.io