Михаил Дырма, AGIMA: как собрать классную команду разработчиков и как мотивировать людей работать по ночам

Алексей: Привет, это подкаст «Будут люди – будут деньги». Мы говорим о подборе людей, формировании команды и управленческом опыте. Сегодня у нас Михаил Дырма, руководитель проектного офиса в AGIMA. Это достаточно крупный цифровой интегратор. Михаил, привет!

Михаил: Да, всем привет!

Алексей: Расскажи немножко, пожалуйста, слушателям про AGIMA и вообще что за цифровой интегратор, чем характерен, какие яркие факты биографии?

Михаил: Да, давай кратко попробую сказать. Цифровой интегратор – это громкое обозначение того, что мы делаем цифровые продукты и интегрируем их в бизнес либо бизнес переводим в цифру, то есть у вас было что-то на бумажках или же вы ходили ножками по складу и какие-то процессы обеспечивали в ручном виде, мы превращаем все это, оцифровываем в цифру, в измерения какие-то и любим это делать. Начали делать, как и все, когда-то давно сайты и мобильные приложения, а пришли вот действительно к целым экосистемам и большим продуктам, которые разрабатываем. Вот вкратце если, то так. Работаем давно, хорошо, клиенты нас любят и мы довольно большая компания, как интегратор в том числе.

Алексей: Какие-нибудь достижения можешь сказать цифровые или каких-нибудь клиентов ярких, чтобы все такие: а, да, это мощно.

Михаил: Да, давай скажу цифровые достижения, то есть если для налоговой, они и все и так прекрасно все это видят, миллиардный оборот у компании, что для нашего рынка считается крупный игрок. Соответственно, из громких имен это ребята из Финтеха, АльфаСтрахование, Ингосстрах, Ренессанс Кредит банк, X5 Retail Group, Philip Morris, GTI, Mercedes. Клиентов очень много крупных и большое количество проектов для них уже сделано. И многие из них – это не проекты какие-то, это прямо продукты, которые живут и продолжают свой жизненный цикл, жизненный путь.

Как выглядит команда крупнейшего цифрового интегратора

Алексей: Скажи, пожалуйста, как твоя команда сейчас выглядит? Кто эти люди, сколько их?

Михаил: Команда на самом деле очень большая с точки зрения, если говорить про именно команду, которая работает с этими продуктами, потому что у нас так получилось, что их много – разных команд. Где-то команда полностью внутренняя и она работает именно для клиента, делает их продукт, как будто бы делает свой именно с продуктовыми метриками. С нашей же стороны роль такая закрывается как product owner, product аналитик и так далее, хотя есть и со стороны наших заказчиков, клиентов, да, тоже ребята, которые этим занимаются. А есть там, где просто какой-то гибрид, то есть частично на нашей стороне есть, то есть это команда, то есть там человек 25, грубо говоря, от фронтов, то есть разработчиков, аналитиков, дизайнеров, тестировщиков, управленцев и так далее, частично состоит из сотрудников клиентов, частично состоит из сотрудников наших. И вот они вместе также работают над продуктом, его развивают и, соответственно, там тоже есть вопросики с их мотивацией и прочими всеми историями, то есть по размеру, да, я тебе сейчас не скажу, но вот таких команд, как я описал, их около 10-ти, около десятка таких команд и они каждая размером от, наверное, 12-ти до 20-30-ти человек.

Алексей: А ты руководишь всей вот этой историей со всеми командами, да?

Михаил: Формально – да, но если говорить про конкретно мой проектный офис, то у меня сейчас две такие хорошие большие команды прямо в прямом поле, где мы занимаемся сейчас отстройкой процессов.

В чем сложности мотивации специалистов крупной IT-компании

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

Михаил: Да.

Алексей: Это такая, знаешь, основная достаточно болезненная тем для руководителей. Можешь немножко поделиться, какие вопросики у тебя есть к мотивации, может быть, как ты эти вопросики сам решаешь?

Михаил: Да, давай я поделюсь. Один вопросик прямо вот больной из свежего, из наболевшего. Есть продукты цифровые, да, они живут не только как люди, они живут еще и по ночам, то есть они живут по факту 24 на 7 и 24 на 7 зарабатывают. Вот один из проектов у нас – это, грубо говоря, цифровая экосистема. Я бы не сказал, что это конкретно один сайт, потому что это не только сайт, это мобильное приложение, которое 24 на 7 продает страховые услуги. Это довольно нагруженный проект. Большая команда с нашей стороны работает над этим проектом, большая команда внутри клиента работает над обеспечением этого процесса. Там очень много интеграций. Классный мой любимый проект, уже больше 10-ти лет в разных ролях с ним поработал. И соответственно, есть проблема, да, то есть у нас иногда, поскольку очень много внутренних команд, я бы сказал так, обслуживают этот процесс, возникают какие-то сбои, аварии, то есть у нас куча мониторингов, все это логируется, есть место общей коммуникации в мессенджере и приходит оповещение, что вот такая-то проблема, например, нерабочее время в ночи. И соответственно, чтобы маршрутизировать эту проблему, то есть такая некая первая линия, если вдруг это касается нас, то есть именно нашей зоны ответственности, для этого нужен человек. И раньше, когда я этим занимался, я делал это на своем добровольном начале и понимании, что это как бы улучшает продукт и есть понимание, как потом это все потюнить, то сейчас, соответственно, команда, которая приходит, вот это next generation, скажем так, мне приходится их дополнительно стимулировать, потому что они уже не будут в ночи подскакивать от того, что у них клиент звонит, что там что-то упало и так далее, и прочее, прочее. Хотя наоборот, сейчас как раз это более критично для продукта. И вот здесь именно проблема мотивации, как ее устроить.

Алексей: То есть, зумеры не хотят ночью реагировать на проблему?

Михаил: Конечно. Ночью и по выходным они занимаются своими делами, продолжают быть более осознанными, ходить в ретриты и так далее. А вот это все оставьте этим достигаторам из 90-х. Ну, это сейчас я утрирую, конечно, но смысл в том, что да, они как бы требуют какой-то мотивации, имеется в виду с точки зрения компенсации за то, что вот они поднимаются по ночам. Вот тут первая ошибка была и предлагалось за каждый случай, когда человек поднимается в ночи, реагирует, транслирует запрос, отвечает, все там закрывает некий такой вопрос, как по трудовому кодексу, по двойной ставке оплачивать. Но поскольку это все-таки история про отказоустойчивость, то есть это сервис обслуживания, когда мы говорим о том, что сервис должен постоянно работать, то я все-таки здесь говорю, что это не совсем правильно мотивировать, потому что это будет мотивировать как раз больше подниматься по ночам, потому что тебе же больше заплатят, если ты… Чем чаще встаешь по двойной ставке по выходным и будешь уже потом… То есть, в итоге сюр, конечно, но возможно, это может привести к саботажу, когда команда такая типа…

Алексей: Наоборот, сделает так, чтобы все не работало ночью.

Михаил: Да, сделать так, чтобы… Да, я предложил как раз отталкиваться от мотивации как у китайских врачей, то есть если пациент не болеет, мотивация повышена. Если есть какие-то инциденты, то никакой мотивации. В общем, пока тяжело договориться именно с управленцами, то есть технические специалисты легко из команды на это идут и действительно понимают цель и плюс у них, казалось бы, в руках как раз все рычаги, типа давайте у нас какие риски? Мы при релизе можем что-нибудь накосячить. Давайте нормально CI/CD отстроим. Все, там тимлиды с тестировщиками, с DevOps-ами сидят там пушат эти задачи в бэклог, чтобы, короче, они шли инфраструктурно. А управленцам кажется, что никаких рычагов на это повлиять нет, с точки зрения коммуникации они есть, они будут всегда, поэтому именно управленцев мне тяжело подтащить. Вот это из моих больных таких вопросов, который пока еще не решен, но здесь я именно эмпирически иду, то есть экспериментирую с разными видами мотивации. Вот как-то вкратце попытался так рассказать.

Нужна ли разная мотивация сотрудникам разного возраста

Алексей: Слушай, а ты мотивацию ставишь на должность или ты ее подстраиваешь под конкретного человека? То есть, условно, молодым ты ставишь такую мотивацию, достигаторам из 90-х другую.

Михаил: Я понял вопрос, да. Нет, я эту мотивацию все-таки под роль, то есть эту роль может занимать как молодой, так и старый, так и не важно кто. В команде есть определенные роли и зоны ответственности, то есть коммуникации – это роль именно товарищей-управленцев, потому что они лучше всего понимают, куда маршрутизировать запрос. Это в QA, в DevOps. Можно сказать, что можно сразу просто в команду, но всю команду в нерабочее время поднимать, если это вопрос вообще, возможно, даже нас не касается и достаточно тимлида в QA дернуть и он скажет, что типа по автотестам все окей, вот лок, или не окей, вот лок ошибок, все, отправляй коллегам, соответственно, проблема у них. И поднимать при это еще тимлидов разработки, фронта, бэка, DevOps и вообще весь шухер наводить кажется, что нецелесообразно, поэтому должен быть некий такой маршрутизатор. Возможно, это как-то решится в будущем, не знаю, скриптом каким-то, то есть мы поймем, что это действительно типа инструкция, даем любому человеку, нанимаем вообще в колл-центре сотрудника в каком-то и он нам это все делает. Но пока так, пока это управленцы делают.

Каких сотрудников подбирали в крупнейшую компанию-интегратора в 2022 году

Алексей: Слушай, у тебя достаточно такая объемная команда. Я предположу, что ты ее не один день формировал. Расскажи немножко, пожалуйста, что у тебя с рынком труда вообще, кого тебе хватает, кого не хватает, в чем там боль?

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

Алексей: Типа с тонущих кораблей вы берете, да, или что?

Михаил: По факту да. Опять же, на нашем рынке, соответственно, мелкие игроки вообще посыпались очень жестко. Они к нам просто приходят и говорят: «Купите нас. Вот у нас там команда 12 человек, просто возьмите нас куда-нибудь. Мы знаем, что у вас там проекты есть и прочая вся история». Плюс, да, то есть некоторые зарубежные ребята уходят и там это больше, знаешь, ребята а-ля EPAM, вот эти все. Они просто говорят: либо релоцируйтесь, либо оставайтесь здесь, но увольняйтесь. Соответственно, некоторые сотрудники увольняются, действительно, приходят к нам на собеседование, иногда мы даже делаем там офферы на какие-то истории, то есть это есть.

Алексей: Вроде чуть получше стало, да?

Михаил: Сейчас я бы не сказал, что кого-то не хватает. Да, сейчас попроще стало найти, то есть у нас есть с каким-то редким стеком проекты, редкий – имеется в виду слишком востребованный. Раньше там iOS, Android-специалисты, то есть мобильная разработка – это прямо можешь бесконечно искать, там завышенные ценники, очень тяжело найти вообще нормальных вменяемых ребят. Сейчас с этим стало гораздо проще, мы прямо видим, что у нас существенно увеличился штат, во-первых, и мобильной разработки, у нас потому что проектов стало больше по мобилке, и это позволило как раз ребят нанять. И их стало попроще нанимать, они быстрее стали появляться, то есть очередного тимлида… Тимлид – самая такая востребованная история, то есть это уже сформировавшийся специалист, но при это который еще готов тоже под какие-то наши процессы подстраиваться. Но сформировавшийся специалист с хорошими именно техническими скиллами в Swift-е, да, желательно, чтобы он еще разбирался в каких-нибудь соседних стеках и так далее плюс там понимал основы интеграционных всех процессов, вот таких ребят, конечно, очень тяжело найти раньше было, сейчас попроще. Плюс, как это ни странно, очень много из-за рубежа. Это Азербайджан, та же Украина, Беларусь, Казахстан.

Алексей: Типа ты берешь, наоборот, появились на рынке.

Михаил: Они, да, есть на рынке вполне себе нормально и по нормальным костам, то есть мы их действительно рассматриваем и иногда, да, делаем офферы, если действительно там все сходится и нас все устраивает.

Способы подбора сотрудников для крупного IT-разработчика

Алексей: Я понял. У тебя механика поиска традиционная, ты делаешь как обычно, никаких сверхъестественных штук, кроме как вот этой апрельской истории, которую вы запускали, я так понимаю, таргетировано на какие-то компании прямо специально, вы не делали?

Михаил: Не-не, мы прямо на компании не таргетировались, мы просто привыкли громко кричать по рынку, все каналы, которые нам известны, плюс, естественно, сейчас мы с каналами тоже экспериментируем, потому что больше нет всего, что там метовское, да, ни инстаграмов, ни фейсбуков, остались только какие-то наши каналы, которые не развиты, еще не используются, и Телеграм. Мы в основном с точки зрения PR-а, HR-а ходим по каким-то каналам, привлекаем каких-то партнеров, то есть тоже здесь экспериментируем. То есть, я не знаю, что такое имеется в виду – классический путь, это типа, видимо, HeadHunter. HeadHunter как бы тоже есть какие-то вакансии, мы их открываем, смотрим отклики, но там редко что-то находится. В основном все находится действительно по каким-то либо мероприятиям, либо каналам узкоспециализированным, либо что-то еще такое. И вот как-то раз я помню даже, у нас параллельная деятельность есть про обучение и прочее, мне коллеги, клиенты наши из ВТБ банка, это в том году было, пишут типа: «О, у нас по внутреннему каналу рекламируют ваш урок для проджект-менеджеров и что типа ты его будешь вести». Там открытый урок вел. Я говорю: «Блин, вот это дистрибьюция, вот это я понимаю». Что мы попали во внутренние каналы банка ВТБ и нас там рекламируют. Вот это кажется, что супер.

Алексей: Это специально было или ты так и не понял?

Михаил: То есть, потом я выяснил откуда, да, это действительно специально, с помощью наших партнеров мы попали с рекламой в этот канал, причем канал специально для продактов, то есть для целевой аудитории внутренний канал, да.

Алексей: Неплохо.

Михаил: То есть, это достижение ребят, которые у нас занимаются именно HR PR-ом, то есть они залезли даже в какие-то такие истории. То есть, хорошая дистрибьюция – это залог успеха, я считаю, причем в любом бизнесе, в том числе и в поиске кандидатов.

Алексей: Слушай, а ты как-то считаешь какой-то ROI, ROMI вот этих каналов дистрибьюции или вы просто во все подряд массировано загружаете?

Михаил: Все так. Это оцифрованный процесс внутри компании, потому что для нас сотрудники – это наш актив. Мы – заказная разработка, у нас нет каких-то там продуктов. Они по факту есть, но это не основное, да. Основное – это сотрудники и вложения в каждого из них с учетом (00:14:30) и прочая, прочая вся история. У нас это все, естественно, оцифровывается и мы стараемся оптимизировать эти процессы в том числе. То есть, здесь обычная такая работа, как мы работаем над продуктами наших клиентов с точки зрения продуктовой аналитики по каким-то циклам, воронкам и так далее. Вот здесь абсолютно все то же самое. Пробуются новые каналы, понимается их конверсия, понимается стоимость привлечения, в общем, стандартная история, я не знаю.

Алексей: Как обычно.

Михаил: Да, тут как обычно.

Особенности подбора сотрудников в IT-компанию при помощи телеграм-каналов

Алексей: Слушай, есть ли какие-то, знаешь, категоричные выводы, которые ты сделал, что вот этот канал – полная просто хламина, вот оно вообще не работает? Что-нибудь такое есть у тебя?

Михаил: Да, есть такие. В основном это какие-то рекрутерские такие уже стабильно забитые каналы чаще всего набегают. В принципе, да, канал начинает работать, туда прибегает очень много рекрутеров из разных компаний, из рекрутерских агентств и все – вот эти каналы уже пока, до свидания. Вот поэтому есть некая такая их ротация, это вот если говорить про Телеграм-каналы. Я сейчас конкретные каналы, наверное, не скажу, уже давно не смотрел эту аналитику, статистику, но вот как-то примерно так, если в ту область смотреть.

Как происходит увольнение в крупной компании-интеграторе

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

Михаил: Да, к сожалению, увольнение людей у нас в стране и по Трудовому кодексу, законодательству – оно такое довольно непростое. То есть, буквально недавно был инцидент с сотрудником, то есть приходилось объяснять, что увольнение – это… То есть, есть несколько видов. Сокращение, понятное дело, это когда мы вынуждены сотрудника уволить, потому что не можем дать ему работу, или еще какие-то такие моменты. Тогда да, это делается с компенсацией и вот этим всем. Есть увольнения, когда сотрудник желает покинуть компанию сам, это по собственному желанию. И есть третий вид самый негативный, который для обеих сторон ничего хорошего не несет, потому что для работодателей это очень трудозатратно, для сотрудника это, в принципе, как бы такая черная метка, это увольнение по какой-либо статье, типа несоответствие трудовым каким-то обязанностям, которые прописаны в трудовом договоре или зафиксированы где-то в виде регламентов, которые человек так или иначе подписал. У нас это в должностной инструкции зафиксировано, например, в компании. Соответственно, это такой геморройный процесс, и поэтому мы всегда стараемся все-таки расставаться даже с нашими даже теми сотрудниками, которые нам в чем-то не подошли, (00:16:58) что-то похожее на (00:16:59 OKR) историю, вот именно (00:17:00 те KPI) которые мы проставляем всем сотрудникам и мы видим, что сотрудник не справляется, мы с ним расстаемся и расстаемся, как правило, не увольняя по статье, а именно человек сам пишет, то есть такая договоренность. Но в принципе, все, наверное, так работают, но иногда люди бывают…

Алексей: Плюс-минус. Так у тебя, получается, был какой-то негативный опыт? 

Михаил: Да, до того, что, блин, человеку объяснял, что я прошу его подписать по собственному, это уже некий с моей стороны шаг навстречу и попытка не разводить эту историю до того, что действительно буду тратить время с какой-то комиссией, подтверждать, что действительно не выполнял свои обязанности, хотя на самом деле человек как бы уже признал сам, что да, вот все, это последние инциденты, которые были – это, наверное, точка кипения, точка кипения именно меня как руководителя и нас как компании. Там полное несоответствие тому, что как бы требуется от сотрудника.

Как предотвратить увольнение сотрудника по статье

Алексей: Ты что-то поменял, после того как у тебя такие ребята начали появляться, в подходе? Не знаю, ты начал заранее какие-то вещи проговаривать, может, что-то по-другому оформляешь?

Михаил: Да в принципе, особо ничего менять не надо. Единственное, что я впервые в жизни, наверное, за сколько, больше, чем 10 лет работы в этой роли задумался над тем, что действительно, если есть какое-то понимание внутри и стратегически ты понимаешь, что дальше сотрудник, скорее всего, идет ко дну и идет вопрос к расставанию, если есть риск не договориться на выходе, то, возможно, стоит заранее вот эту процедуру прорабатывать. Как бы сейчас просто в постфактум проблематично сделать вот эти три выговора, по-моему, насколько я помню, да, зафиксировать, что действительно было поручение, было не выполнено, не получено объяснение, еще какие-то истории, то есть возможно, стоит заранее какие-то такие вещи делать. Но опять же, это такой скользкий этический момент здесь еще возникает, потому что по факту начинаешь заранее рыть некую такую могилку, которая потом…

Алексей: Слушай, есть, Нассим Талеб, по-моему, говорил, что антихрупкость одного достигается за счет хрупкости другого.

Михаил: Хрупкости другого, все верно, да.

Алексей: Поэтому тут как бы выборов не особо много. У меня есть мои друзья, приятели-предприниматели, они мне много разных способов рассказали. Есть, наверное, самый такой агрессивный, когда подписывается трудовой договор, но на руки трудовой договор человеку не выдается, например.

Михаил: Это незаконная история все-таки.

Алексей: В целом да, но как бы…

Михаил: Любой договор – он двухсторонний, должен быть. Просто поскольку резиденты Сколково, мы не можем не быть абсолютно белыми и пушистыми, да, и соответственно, все эти истории – они как бы очень важны. И вообще в целом почему еще тоже не хочется в негативные эти истории лезть такие, потому что очень сильно много работаем над так называемым HR-брендом, то есть рассказываем, что у нас там действительно хороший коллектив, мы внутри очень много, то есть у меня там HR и внутренний PR, то есть внутренние коммуникации вкладывают огромное количество сил в какие-то внутренние движухи: опросы 360, опросы про сотрудника и о нем самом, какие-то разговоры. Мы там тоже экспериментируем с форматами разными. Просто поговорить по душам, то есть иногда некие такие тет-а-теты между сотрудником и руководителем – это, в принципе, как некая обязательная история практически у всех во всех наших подразделениях. А где-то именно просим со стороны, типа чтобы HR просто зашел и поговорил с сотрудником, типа все ли его устраивает, все ли окей и так далее, то есть такие истории тоже проходят. Потом эта, естественно, вся информация анализируется в таком сжатом виде без каких-то откровений и так далее. Мы действительно очень много в это вкладываем, а такие истории, что мы кого-то уволили по статье, естественно, человек будет в негативе, может об этом (00:20:43) в том числе, но на обоих откладывает на самом деле это черную метку, поэтому смысла в этом я особо не вижу. Плюс это еще и затрата усилий с обеих сторон, поэтому всегда стараемся договориться так или иначе.

Почему гибкий и вариативный подход к клиентам компании-разработчика эффективнее, чем Scrum

Алексей: Подскажи, пожалуйста, немножко про такие управленческие принципы, хочу тебя немножко поспрашивать. То есть, у тебя есть product owner и прочие ребята, по семантике названий которых можно понять, что вы где-то глубоко сидите в Scrum-е или в ScrumBut-е каком-нибудь аналогичном.

Михаил: Да-да, мы называем его (00:21:14)???? или до этого называли его еще Scrum (00:21:17)??? Тут понятно, нет, смотри, у нас, как я всем своим руководителям проектов, не важно, какая роль у них будет потом в команде, будет он product-ом или же будет он Scrum-мастером исключительно и так далее, всегда говорю, что у нас индивидуальный подход и с одним и тем же клиентом мы можем проект делать как по какому-то гибкому фреймворку, так и по чистой классике – по Водопаду. Почему? Потому что мы за оптимальные решения стоящих задач перед нами. Еще часто клиент сам задачи не понимает, но это классика жанра про заказную разработку, то есть все ребята, которые работают в заказной разработке, сейчас меня прекрасно понимают, что приходит клиент: «Я хочу мобильное приложение». На самом деле ему нужно сделать лендинг для рекламной кампании и совершенно другая задача стояла изначально. Поэтому да, управленец должен четко понимать разницу в фреймворках и вообще в подходах, потому что где-то там утилизируются ресурсы лучше, где-то результаты выше и так далее, поэтому здесь чего-то жесткого нет, то есть мы с одним и тем же клиентом проект можем сделать под Scrum-ом, здесь пошли по Водопаду, по классике жанра. И даже модель взаимодействия от этого тоже меняется. Здесь фикспрайс, мы подписываемся под ТЗ и под конечные какие-то результаты, сроки, там мы подписываемся, что вот команда будет работать, вот столько-то спринтов, вот то-то мы хотим сделать, вот так-то мы вместе отслеживаем эффективность и прочее. Поэтому здесь вот какого-то такого не скажу. Есть универсальный у нас подход с точки зрения формирования, мы называем ее схема взаимодействия команды, то есть это именно одна… Вот есть проект, есть подготовительная предварительная часть, у нас просто такая схемка есть, потом могу прислать, если интересно. Заканчивая всю предварительную историю, когда мы прорабатываем архитектуру, какие-то такие общие-общие вещи для проекта, формируем бэклог, соответственно, если там нужны концептуальные визуальные части проработать, их тоже все прорабатываем. Дальше у нас идет вот такой пластичный подход, начиная с описания (00:23:13) и заканчивая его реализацией и тестированием по информационной безопасности и релизом в прод. И вот эта схемка позволяет, то есть такой путь делать любой цифровой продукт. Есть вот там, соответственно, оно все в Jira разложено по доскам, канбан-доскам имеется в виду, с которых мы потом замеряем эффективность, да, каждого из сервисов. Тут есть сервис постановки задачи, то есть это все, что касается формирования требований, то есть отрисовка, прототипирование, можно сказать, ТЗ, тест-кейс и вот эта вся история, а есть сервис разработки, когда именно это все реализуется. Еще есть сервис менеджмента, который обслуживает эти оба сервиса и там тоже ставятся задачки и так далее. Вот это все позволяет нам как-то контролировать качество всех трех этих сервисов, и какие-то проблемки если находятся, то тюнить. Но они легко вписываются в абсолютно любой формат как в Водопад, так и в какой-то, может быть, гибкий фреймворк типа Scrum-а. Но по сути своей это канбан-метод, то есть это канбан-доски, мы смотрим, соответственно, все эти истории и так далее, то есть можно сказать так.

Какие преимущества у формата “Водопад” в разработке мобильных приложений и сайтов

Алексей: Я редко у кого встречал, что открыто говорят, что пользуются Водопадом. Обычно, знаешь, даже немножко, что ли, стесняются об этом говорить, знаешь, как-то неудобно: ой, у нас тут Водопад.

Михаил: У меня есть для этого классический пример, который на собеседованиях у ребят спрашиваю.

Алексей: Если можешь, приведи.

Михаил: Да, давай кратко. Я пытаюсь обрисовывать, погружать в контекст, что приходит заказчик, потом вы в мультивселенной в двух разных измерениях, ты там делаешь с одной командой тот же самый проект, только по Scrum-у, здесь по Водопаду. И соответственно, этот пример разбираем. Он реально очень наглядно и показательно с точки зрения того, понимает человек вообще, в чем разница между вот именно Agile-манифестом и гибкой разработкой, гибким подходом к разработке продуктов и Водопадом. А на самом деле есть тоже большое преимущество, например, у того же Водопада – это утилизация ресурсов. Эффективность утилизации ресурсов в Водопаде все-таки повыше, чем в Scrum-е, хотя бы из-за самого подхода. То есть, если на длинном продукте вы там итерациями будете сильно много утилизировать в тестировании в Scrum и, соответственно, в релизную деятельность в целом если не наладите нормально CI/CD процессы… То есть, я реально как-то раз видел команду, которая работает уже третий год двухнедельными спринтами и у них уже огромнейший продукт на самом деле из ритейла, и у них не было никаких автотестов, то есть, я говорю: «Вы регресс руками делаете?» Они такие: «Ну, да». Я говорю: «И сколько у вас из времени спринта занимает релиз?» «Да мы вот команду увеличиваем, уже неделя больше, чем в релиз идет». Так это же очевидно, что у вас функционала уже очень много, вы вот руками туда-сюда гоняете, это неэффективно. Включайте автотесты, настраивайте CI/CD процессы нормально тогда. Поставка будет не так много времени занимать. Но кажется, вещь очевидная, но при этом как бы гонка от продактов, что у нас бэклог пухнет, приоритеты растут, стейкхолдеры требуют, показатели падают, она всегда заставляет забивать на такие инфраструктурные процессы. А в Водопаде у тебя нет именно вот этой интерактивности итераций, ты разом все это релизишь, то есть только там тест, ретест после откладки и как минимум меньше времени. И плюс, действительно, заказчик, конечный потребитель, стейкхолдер, да, он платит в Водопаде за конкретный функционал в конкретные сроки и конкретный фикс денег. Для него это прозрачнее, для него это эффективнее, потому что риски в данный момент на тебя как на исполнителя кладутся, какими способами ты это сделаешь и так далее. Но надо предупреждать, что, соответственно, мы что с Вами в ТЗ пропишем, которое Вы, скорее всего, не прочитаете, то мы и сделаем. Любой шаг влево, шаг вправо расстрел, в смысле расстрел – это допкост, сдвижение сроков и так далее. То есть, здесь надо все прозрачно доносить. И для маленьких проектов, где волатильность требований невысокая, действительно эффективнее их сделать по Водопаду, не уходя в какие-то гибкие фреймворки. А там, где у нас живой продукт, конкурентная среда и действительно…

Алексей: И неопределенность, наверное, большая.

Михаил: Да, и высокий уровень неопределенности, это как бы да, это надо командой и гибкую погнали. Но мы сейчас чаще всего именно в канбан-метод, потому что так проще отследить потом эффективность, действительно, работы команды, то есть все инструменты там уже настроены.

Тренды и тенденции рынка digital-интеграции и разработки

Алексей: Слушай, а расскажи немножко про тренды и тенденции, которые у тебя на рынке есть. Я вот для себя выделил такую забавную особенность, что у тебя есть, я не знаю насчет тренд или не тренд, но есть внутреннее разделение, такая возможность работать с заказчиком гибкая и, условно, по Agile или по Водопаду, как угодно. Какие тренды еще у тебя есть, что ты замечаешь, что с рынком происходит у тебя?

Михаил: Рынок трясет. В принципе, весь мир трясет, всю мировую экономику, и соответственно, рынки на это так же реагируют, пытаются как-то, по крайней мере, наши ближайшие партнеры и даже конкуренты все остальные, в принципе, сейчас активно смотрят в сторону госзаказчиков, потому что импортозамещение, да, сейчас сильно кратно увеличился этот тренд, когда все поуходили, какие-то огромные ПО-шки. Но это действительно большой куш можно сорвать, если у тебя уже есть какие-то готовые решения по замене какого-нибудь SAP-а и прочей всей истории. Это да, это интересная такая вещь. Мы как люди, которые против коробочных решений, про внедрение именно каких-то кастомных проектов, хотя и коробки мы тоже спокойно используем, тот же Битрикс, где-то он идеально встраивается в бизнес и нормально живет, опять же, индивидуальный подход везде, но мы всегда за какую-то кастомную разработку. Кстати, у нас был очень крутой кейс, не знаю, можно ли это говорить, но я так скажу, что это очень крупное управление автопарком, то есть с ERP-системой, и соответственно, пару лет назад в 20-м году на заре… Вот везет ребятам. На заре, собственно, коронавируса они разыгрывают тендер и думали: SAP выбирать или в кастом пойти? И мы говорим: «Пацаны, давайте на кастоме мы под вас сделаем?» И там по смете получалось где-то, наверное, на один порядочек поменьше, чем внедрение и кастомизация SAP-а под них. Они такие: «Ладно, фиг с ним, рискнем, пойдем с вами». Мы, соответственно, где-то за месяцев 6-7 запустили (00:29:36 NVP и RP-шки) по управлению огромным-огромным автопарком, одной зеленой компанией в нашей стране. Они: «Блин, классно, давайте развивать». И соответственно, дальше мы командой развивали это все это именно по Scrum-му, то есть релизами, разрастили очень сильно функционал, то есть за два года. И тут 22-й год, SAP говорит России «пока» и пацаны такие типа: «Вот это вообще просто…»

Алексей: Пронесло.

Михаил: Да. Вот это они прямо… Сейчас бы они сильно попарились, естественно, да. Хоть это, конечно, и автопарк в том плане, что тяжело там сейчас что-то с ним, отдельная история – это с запчастями, с поставками новых вообще, в принципе, автомобилей, но я думаю, это тоже все решится, потому что здесь перефокусироваться проще, чем внедрить новую огромную ERP-систему в весь этот процесс, который еще завязан на партнеров, на кучу дополнительных всяких дочек и прочая вся история. Поэтому такие вот примеры есть и это тренд.

Как выживают компании на ERP-системах, покинувших российский рынок

Алексей: Слушай, а ребята, который на условном SAP-е сидели, они у вас пороги не обивают, что нам пора, нужно срочно, прямо сейчас?

Михаил: Они все-таки как-то договариваются с SAP-ом и пытаются его просто разгружать потихоньку, то есть там процесс такой, что они с него функции снимают. Как правило, SAP является не единственной системой, которая в бизнесе, а какой-то системой, которая пришла еще какую-нибудь дополнить. Вот они просто этот функционал разгружают. Но хотя, конечно, те, кто полностью живет на SAP-е, его продукт, конечно, тем сейчас прямо тяжеловато. Но я думаю, они просто договариваются, в какой-то момент либо переводят, проводят оплаты как-то через какие-нибудь костыли, либо как-то договариваются, чтобы все-таки пока не найдут замену (00:31:14) Так, чтобы прямо пороги обивали, такого прямо, наверное, я не видел еще.

Алексей: Чтоб все одним днем закрыли, а они прямо не знают, как жить завтра.

Михаил: Нет, одним днем вообще невозможно вывести, это прямо большое количество бизнес-процессов.

Рекомендации руководителя проектного офиса крупнейшего digital-интегратора

Алексей: Окей, я тебе хочу несколько личных вопросов задать с твоего позволения.

Михаил: Давай.

Алексей: Хотел тебя немножко порасспрашивать про какой-нибудь список литературы, который у тебя есть, который ты читал за последнее время, можешь порекомендовать или, наоборот, смело не порекомендовать.

Михаил: Да, так получилось, что у меня, не знаю, видимо, из-за того, что я был глупым, несмышленым и в свое время купил квартиру в ипотеку, я не особо занимался инвестициями. Так что-то там откладывал, где-то там экспериментировал. Сейчас очень много читаю про именно… И даже записываюсь на некоторые разные курсы по инвестированию и про криптовалюты, то есть, в принципе, с технологией блокчейн я очень хорошо знаком, потому что мы сами такие проекты… Использовали в некоторых проектах для бизнес-процессов. Но с точки зрения инвестиций как это работает, я до недавнего времени не знал. Но тут, можно сказать, есть книжка такая – «Blockchain Basics». Надо будет вспомнить потом, я могу дослать потом, кто автор, чтобы не обманывать. По-моему, Даниэль Дрешер или как-то так.

Алексей: Да я думаю, мы можем указать в подкасте потом.

Михаил: Да-да, можно потом ссылочку дать. Вот вполне для понимания, что да как, да почему и вообще про блокчейн-технологии, про блокчейн-платформы это очень хорошая история. Так или иначе, нам сейчас нужно будет всем понимать, как инвестировать помимо просто покупки доллара, пока он дешевый. И кстати, тоже сейчас не очень хорошая история, это тоже отдельная история. Из литературы художественной сейчас читаю книжку, которая мне не нравится, я просто, не знаю, пересмотрел чуть-чуть «Ведьмака» оба сезона на Нетфликсе, когда он еще был, и такой: блин, что-то захотелось почитать. И МИФ, видимо, ребята очень хорошо работают, не знаю как, подсунули в подборке… МИФ – это издательство «Манн, Иванов и Фербер». Мифы разных стран. И соответственно, там была книжечка, которая затесалась, что-то там вообще в принципе про мифологию, что-то общее а-ля от драконов до чего-то еще. Книжка пока вообще абсолютно не нравится, потому что это сборник древнегреческих и древнеримских рассказов про то, как вызывали духов, пытались оживить людей, то есть довольно скучно написана либо переведена.

Алексей: Не все книжки МИФа стоит читать.

Михаил: Да, есть такое вот. Люблю ребят, очень много покупаю у них всегда книг, читаю их, но иногда бывают такие просаки.

Алексей: Бывает. Хорошо, Михаил. Закончи, пожалуйста, наше с тобой интервью тремя словами.

Михаил: Спасибо, было интересно.

Алексей: Все, отлично, спасибо. Это был подкаст «Будут люди – будут деньги» и Михаил Дырма. Спасибо тебе.

Михаил: Все, всем пока! 

Подписывайтесь на наш подкаст, чтобы быть в курсе всех новостей