На первой практической конференции «Анализ & Управление в ИТ-проектах» мы взяли интервью у Артема Пластинина – руководителя практики и тимлида компании «АйТи Капитал». Артем модерировал секцию «Программная инженерия».
Порассуждали о том, что такое программная инженерия, и кто такой программный инженер. Поговорили о работе с заказчиками, менторстве и кадровом голоде. А еще узнали, как в своей команде Артем выстраивает рабочие процессы и обучение сотрудников – делимся этим и с вами.
Интервью получилось крутым – оно честное, открытое и очень полезное. Поэтому смотреть, читать или слушать обязательно.
Расскажи немного о себе: где работаешь и как оказался в ИТ?
Сейчас я тимлид банковского направления – роль, совмещенная с должностью. Я сам люблю так говорить, потому что не хочу отвязывать от себя разработку. Я очень люблю разработку, программирование – соответственно, так и пришел в ИТ.
Я руковожу командой разработки по банковскому направлению. Вообще, в современной программной инженерии под определение разработки попадает огромное количество ролей, людей и профессий. Сейчас нельзя сказать, что разработка – это вопрос, который касается тех людей, которые занимаются непосредственно написанием кода. Под разработчиками можно понимать и аналитика, и консультанта, и тестировщика. Они тоже занимаются разработкой, они тоже генерируют разного рода артефакты, они также должны доставлять эти артефакты до бизнес-заказчика. Поэтому в мою команду разработки входят не только кодеры, но и аналитики, консультанты, тестировщики. Но все мы вместе занимаемся разработкой.
Сколько человек в команде?
У нас по-разному, но максимальное количество – 15 человек. И с таким количеством было довольно непросто. Сейчас мы стремимся к тому, чтобы людей было до 8 человек.
Почему?
Так проще обеспечивать взаимодействие. Текущий опыт, текущая практика показывают, что чем меньше у тебя коммуникаций, тем проще тебе работать на проекте.
А какие роли у вас? Разработчик? Аналитик?
У нас есть разработчик, аналитик, у нас есть функциональная архитектура – функциональный, технический архитекторы. Сейчас еще появляется тестировщик.
С чем работаете? С каким софтом? 1С?
Да, у нас 1С. Вообще, надо сказать, что мы довольно специфичные ребята. Потому что все наши клиенты – это компании, которые находятся под крылом ЦБ РФ: банки, страховые, ломбарды. Это накладывает отраслевую специфику. В частности, если говорить про банки, страховые – там нет классического хозрасчетного плана счетов.
Еще накладывает некую специфику на работу то, что наши клиенты зрелые с точки зрения ИТ – это большой зоопарк систем. Зоопарк систем, где все животные прикормленные и живут довольно неплохо. И вот когда ты приходишь в этот зоопарк, ты не можешь прийти и сказать, что ваш зоопарк теперь будет работать по тем правилам, которые мы придумали. Скорее наоборот тебе скажут, что у нас такие правила, такие регламенты, и вы должны в них войти, чтобы здесь вам комфортно жилось.
И как вы справляйтесь с такой задачей?
Вопросы секции, которую я модерировал, позволяют нам справляться с этой задачей, а именно вопросы программной инженерии и современных практик. Обеспечение качества – для нас самый большой приоритет.
Что такое программная инженерия?
Программная инженерия… Все, что сейчас не назови, с точки зрения ИТ можно так или иначе привязать к определению «программная инженерия». Но в целом это некая область знаний, которая отвечает на вопрос: как оптимально построить систему при наименьших трудозатратах, сделать какое-то решение, которое максимально удовлетворяет заказчика, при наименьших инвестициях.
Под это определение попадает много всего. Мы сюда можем отнести и вопросы связанные с разработкой, с аналитикой... Но все направлено на то, чтобы оптимально построить сложные системы.
Есть ли такой отдельный специалист как программный инженер? Ты на стыке всегда, или ты сам себя так называешь, если ты можешь выстраивать сложные системы?
Конкретно такой роли, как программный инженер, пока нет, но это как частичка каждого специалиста. Аналитик – он тоже программный инженер, разработчик и тестировщик – все программные инженеры.
Кстати, когда мы говорим про разработчиков, иногда даже так и уточняем: давайте, не будем называть их разработчиками, потому что разработчик чаще всего ассоциируется с человеком, который пишет код, а мы их называем «инженерами». Для нас - это инженеры, которые работают над артефактами, доставляют их до бизнеса в виде какой-то ценности.
Можно сказать, что это эволюция разработчика? Потому что требования к профессии растут – нужно больше знать, больше уметь.
Можно сказать, что для любого специалиста эволюция – это когда он начинает заботиться о том, чтобы совершенствовать свой инженерный склад ума или какое-то базовое понимание программной инженерии. Это история, над которой должен задумываться каждый специалист, если он хочет расти.
Есть какой-то джентльменский набор инструментов, которым должен владеть специалист?
Безусловно, есть разного рода джентльменские наборы. При этом спроси специалистов, тимлидов и архитекторов – каждый приведет свой. И каждый будет прав. Почему? Потому что, есть разные направления деятельности: кто-то занимается продуктовой разработкой, кто-то проектной, кто-то внутренней автоматизацией, внутренней проектной автоматизацией. И везде набор этих программных средств будет отличаться.
Но с другой стороны, если посмотреть какие-то современные тренды, то мы увидим некую закономерность – все ребята считают стандартом использовать сценарные тесты, механизмы автоматической доставки и инспекции кода.
Многие ребята, которые ищут работу, в частности, разработчики, всегда обращают внимание на описание вакансии, и если указано, что компания использует инструменты CI/CD, Devops и что-то подобное, то разработчик, скорее всего, скажет «да» такому работодателю.
Какие инструменты вы обсуждали на секции?
Сама конференция больше ориентирована на аналитику, а не разработку. И поэтому мы здесь очень аккуратно преподносим наши инструменты программной инженерии. С одной стороны, мы понимаем, что есть некоторая грань в программной инженерии, когда разработчик и аналитик будут единым целым. Хотя в какой-то степени основной идеей всей нашей секции является то, что аналитик тоже немного разработчик, и ему тоже придется осваивать все эти инженерные практики.
После докладов наверняка подходят коллеги, задают вопросы, проблемы свои рассказывают. Есть какой-то топ вопросов, проблем, о которых спрашивают чаще всего?
Есть, причем всегда. Это не зависит от конференции, не зависит от того, аналитическая это конференция или ориентированная больше на разработчиков.
Чаще всего задаются вопросы об организации процесса разработки: как сделать правильно? как построить оптимально процесс? Или озвучивают какую-то проблему, но она всегда сводится к тому, что где-то не организован процесс разработки. Или, как говорит Сережа Наумов «проектная методология».
А у вас как реализовано?
Тоже всегда по-разному. Тут нет никакой «серебряной пули», здесь нужно исходить из множества факторов и каждый раз смотреть, насколько та или иная методология, процесс разработки здесь и сейчас подходят. Потому что где-то может быть использование гибких методик и методологий, где-то будет нужен разветвленный метод разработки конфигураций, где-то жесткий Waterfall и никак иначе. То есть это всегда зависит от того, каков окружающий мир, в котором нужно выполнять всю эту реализацию.
Самое главное, на что стоит сделать упор, это некий элемент осознанности и понимания того, что нужно регулярно возвращаться и рефлексировать на тему того, что мы делаем, и все ли у нас получается. Если есть этот элемент осознанности и рефлексии, вы легко можете сделать вывод: подходит та или иная проектная методология или тот или иной процесс разработки конкретно сейчас.
И здесь из таких лайфхаков, или как модно сейчас говорить джобхаков, ко всем этим элементам рефлексии подключать наших заказчиков. Заказчик дает нам огромное количество фидбэка, пусть не всегда положительного, но именно он подсвечивает нам болевые точки.
На практике это как выглядит – подключение заказчика? Он участвует в ретроспективах?
Наши ретроспективы не обходятся без заказчика. Иногда мы сначала проводим ретроспективу внутри команды разработки, с заключением по результатам ретроспективы приходит тимлид команды к заказчику и отчитывается за всю команду. И получает фидбэк от коллег. Это всегда очень полезно. Для нас в определенный момент на некоторых проектах это стало мощнейшим бустом. Мы наконец-то услышали заказчика, стали ему давать инструменты, адаптироваться под их процессы.
Я всегда на всех конференциях говорю одну и ту же вещь, что ретроспектива – это, наверно, самый лучший элемент рефлексии. А если вам еще и удается привлекать к нему заказчика, то суперинструмент.
Что тебе как руководителю помогает добиваться эффективной командной работы? Может быть дело не в разработке, а в работе специалистов внутри команды?
Если у тебя образуется команда, то тебе не нужно думать впоследствии об эффективности отдельных ее членов. Потому что команда будет сама заботиться о своей эффективности. Деление ответственности между членами всей команды: все приглядывают друг за другом, все понимают, что если мы где-то промахиваемся, то промахивается вся команда, и здесь нужно помочь.
Я бы сказал, что помогает доверие. В какой-то момент мне пришлось отпустить все мысли о том, что только я могу делать что-то хорошо и быстрее всех, лучше всех, и отдал эту функцию команде. Пусть ребята сами за собой следят, а я в тех случаях, когда мне нужно понести за них ответственность, я это сделаю.
Как ты измеряешь эффективность сотрудников?
Мне не нужно измерять эффективность сотрудников в команде. Есть две плоскости: с одной стороны, обязательно нужно понимать эффективность команды, как команда поработала. И если мы применяем проектную методологию типа Agile или Scrum, она нам расскажет, что если команда переваривает спринты, берет определенный объем задачи и справляется, то она растет. А если у вас производительность от спринта к спринту растет, то это тоже объективный показатель того, что в команде отлаживаются процессы. Но это если обсуждать командно.
С другой стороны, если оценивать эффективность каждого сотрудника, то это другая плоскость – она от команды отодвигается. Здесь ты собираешь фидбэк от других коллег, благодаря ежедневному daily понимаешь, справляется ли человек. У нас нет запрета обсуждать и говорить, что где-то человек плохо справился со своей работой. Такое тоже бывает. Человек может сказать, что мы где-то здесь промахнулись, у нас по этой функции просадка. И когда ты говоришь про функцию, ты можешь это как-то сопоставить с человеком, который ее реализует.
Как у вас устроено внутреннее обучение сотрудников?
Здесь есть несколько направлений. Мы себя любим за то, что у нас развито и продолжает развиваться DeveRel направление – developer relationship. И тут под девелопером мы понимаем и разработчиков, и аналитиков, и консультантов. В общем, все те самые инженеры.
Обучение у нас есть внешнее и внутреннее. Если говорить про внутреннее, это еженедельные митапы по типу обмена опытом – вот что за неделю произошло хорошего или плохого, просто расскажите в рамках небольшого митапа своим коллегам, но исключительно про конкретные текущие задачи.
Есть еще другое направление – техкружок, конскружок и «кругозор». Эти практики ради «опыления» – берем какую-то технологию, которую даже в перспективе не планируем использовать, но она по какой-то причине кажется нам интересной. К примеру, какой-нибудь Chat GPT. Почему не посмотреть Chat GPT и не рассказать коллегам о том, как это можно применять? Для разработчиков это уйдет в техкружок, для консультантов – в конскружок. А «кругозор» – это когда мы изучаем какой-то космический инструмент. Так у нас происходит обучение внутри.
Дальше мы иногда внутренний деврел тиражируем еще во внешний деврел. Когда тот же конскружок можно выложить куда-нибудь на YouTube, и коллеги наши с других компаний или наше сообщество канала, оно нам тоже помогает и синхронизирует, что вот туда ребята не идите, идите сюда – корректируют или, наоборот, скажут спасибо.
Но это пассивный подход, когда нет директивного указания «иди и учись».
С другой стороны, наши проекты и наши заказчики приходят к нам с такими требованиями, что вынуждают нас всегда расти. Условно, придет какой-нибудь заказчик с нефункциональным требованием «давайте стопроцентное покрытие кода тестами». А такие случаи бывают. И только одно такое нефункциональное требование от тебя будет требовать реализации большого количества инженерных практик. И эти инженерные практики ты должен тиражировать и обучать им всю команду.
Поэтому есть пассивный режим, и есть активный режим. Драйвером активного режима у нас выступают наши заказчики и задачи, которые мы решаем в рамках проекта.
По поводу космических инструментов – это какие?
Chat GPT – это на самом деле довольно космический пока для нас инструмент.
Как раз хотела спросить, используйте ли в своей работе ИИ?
Я использую в своей работе регулярно. Могу даже рассказать в каких сценариях.
Но вернусь про космические инструменты. И среди таких космических инструментов мы недавно рассматривали Obsidian – это инструмент, который позволяет организовать базу знаний особенным образом.
Если возвращаться к вопросу Chat GPT, есть определенный набор сценариев, в которых Chat GPT может пусть делать не лучше, чем человек, но, по крайней мере, иногда подсказать. Например, ответить на какое-нибудь письмо. Или, например, к тебе прилетает гневное письмо, и отсутствие эмоционального интеллекта тебе здесь и сейчас не позволяет ответить на него в корректной форме. Ты можешь написать свою формулировку и попросить Chat GPT переформулировать. Он задаст идеи или тренд, как нужно писать. Можно накидать идеи для какого-нибудь доклада. Понятно, что не пройдет цензуру модераторов по качеству, но какие-то идеи, за которые можно зацепиться, даст.
У нас выступал Юрий Куприянов, и он рассказывал о том, как Chat GPT можно использовать для аналитиков. И там прикольные кейсы: когда Chat GPT используют для генерации диаграмм; когда можно заниматься актуальной сейчас задачей реверс-инжиниринга – нужно понять, как это работает, и перевести на другой язык.
Если даже взять такую задачу – какой-нибудь SAP нам нужно импортозаместить, например, но мы не понимаем, как работает какой-то блок кода, и сейчас мы не можем найти специалиста, который нам даст какие-то комментарии. Тогда давайте, отдадим этот кусок кода Chat GPT, и он разложит его нам в тц конструкцию, которую мы хотим. Можем написать: «Расскажи трехлетнему ребенку о чем эта конструкция кода», и он тебе преобразует.
Если возвращаться к вопросу, как я использую, это: почта; генерация диаграмм для технического задания; для вдохновения. В любом случае, если нужно придумать идею, обогатить эту идею какими-либо кейсами – тут Chat GPT незаменимый помощник. Вообще, сейчас Chat GPT позиционируют как хорошего джуна. По крайней мере, в части аналитики.
А кадровый голод вы вообще испытывайте?
Мы, как и все в этом направлении, испытываем.
Это касается всех специалистов или специалистов с определенными навыками?
У нас достаточно жесткая специализация.
Во-первых, у нас есть несколько направлений деятельности – проектная разработка, продуктовая разработка, внутренняя автоматизация. Это усугубляется тем, что у нас есть отраслевая направленность – банки, страховые и т.д. Есть еще функциональное направление – к примеру, управленческий учет, регламентированный учет и т.д.
И представь, что нам нужен такой вот специалист по автоматизации управленческого учета в банках на проектную деятельность. Вот как это звучит?
Специалисты уровня мидл и сеньоры – они, мне кажется, всегда будут в дефиците. Сейчас за счет того, что современный рынок дарит нам большое количество джунов, может быть, в части джунов не будет вопросов, и рынок будет как-то обеспечен потребностями. Но мы, честно говоря, пока боимся этого.
Наша точка роста, как компании или команды, в том, чтобы запустить наставническую деятельность, уметь выращивать из джунов мидлов. Потому что мы до сих пор ориентировались на мидл и сеньор сегменты, а сейчас понимаем, что хватит это терпеть, надо как-то научиться работать с джунами.
То есть если вы ищете специалистов, то начинающих не рассматриваете?
До какого-то момента не искали. У нас пришли талантливые ребята в компанию, которые не побоялись, сказали, что будут воспитывать джунов. И это имеет некоторый выхлоп даже. Поэтому мы учимся.
Это очень здравый подход. У нас еще очень популярен вопрос по саморазвитию. Раз уж мы заговорили про молодых, начинающих специалистов. Что нужно делать для саморазвития? Курсы, наставничество – хорошо, но ведь учиться нужно все время. А как и чему? Тебе что помогает?
Не уверен, что то, что помогает мне, будет помогать остальным ребятам. Но если у человека есть вопрос: «а куда дальше расти или что еще поизучать», и он сейчас на каком-то перепутье стоит, то в современном ИТ этот вопрос решается через менторство. Это направление деятельности сейчас широко распространяется. Есть уже и направление свободного менторства, и направление платного менторства.
Ты совершенно свободно можешь прийти к человеку, который тебе нравится, которого ты считаешь специалистом, или который для тебя является примером, куда бы ты хотел уйти, кем бы ты хотел стать. И этот человек размещает свою анкету на определенных порталах, и в коннекте с ним устраивайте некую менторскую сессию. Этот ментор тебе на безвозмездной основе рассказывает, что ты можешь двигаться в такую-то сторону для того, чтобы тебе чего-то достичь.
Я как ментор тоже выступаю. Сейчас я немного приостановил эту деятельность, потому что поток желающих очень большой для меня. Это тоже определенного рода ответственность, потому что ребята приходят с проблемами. У них есть реальные запросы. Для того чтобы разобраться в этом запросе требуется время, а делать это абы как или тешить свое самолюбие на менторских сессиях – так не хочется делать. А так на каждого, к сожалению, времени нет.
С другой стороны, потребность человека в том, чтобы много рассказывать и делиться своими знаниями, даже в рамках нашей конференции, – удивительная вообще история, насколько люди стали открыто делиться своими знаниями безвозмездно.
И я всем ребятам – начинающим, продолжающим, тем, кто столкнулся с таким вопросом «а куда дальше», рекомендую пойти на GetMentor. Это свободный ресурс. Найти там человека, который вдохновляет, и запросить у него менторскую сессию и поговорить.
У меня там тоже несколько менторов есть. То есть не только я ментор, но и я обращаюсь к разным ребятам за помощью.
Мне нравится, например, HR-политика в Яндексе – как выстроена. И там представлены люди от Яндекса. Причем это не HR, а, например, какой-нибудь техлид. Ты поговорил с техлидом, он тебе рассказал, как у них это устроено.
Или пришел и сказал, что я из такой-то компании, мы занимаемся 1С, у нас с программной инженерией не очень. Как вы делаете в большом ИТ? Он может на совершенно безвозмездной основе с тобой поделиться такой информацией.
Ты, как ментор, тоже сам прокачиваешься? Бывают ситуации, когда действительно надо покопаться в кейсе подопечного, и есть шанс узнать что-то новое и для себя тоже?
Это хороший вопрос. А для чего это мне надо? Во-первых, я сильно синхронизируюсь с отраслью. То есть я понимаю, чем сейчас дышит отрасль. Так как мы в некую специализацию уходим, мы тоже переживаем, что или убежим сильно вперед – нам это невыгодно, потому что однажды мы придем к какому-нибудь заказчику с пакетом наработок, и нас просто никто не поймет, или наше предложение будет неконкурентное, потому что типа “рокет сайнс” для заказчика. Или кто-то из наших конкурентов не поймет проблему. Поэтому нам даже наших конкурентов выгодно подтягивать по уровню своих знаний.
Вот здесь как раз происходит вот эта синхронизация: какие проблемы сейчас вообще в отрасли? там у ребят какие проблемы? кто какие вопросы решает? И, с другой стороны, ты реализуешь как-то свой потенциал в том, чтобы отдавать знания, и прокачиваешь себя.
Это вот к вопросу о пользе сообщества разработчиков, и необходимости вращаться среди единомышленников.
Ты спрашивала, какие вопросы задают по теме доклада. Вот сегодня, как раз после моего доклада, общался с прекрасным человеком. И он сказал такую фразу, что на самом деле доклады не дают столько информации, сколько дает потом вот это общение, эти контакты.
У человека, может быть, были немного другие ожидания, он не словил инсайтов, потому что сам по себе уже очень крутой. Специалист пришел на конференцию как раз за инсайтами, за артефактами и получил их не в полной мере, но получил контакты и возможность пообщаться. Он смог поделиться каким-то своим новым видением, новым продуктом.
Конференция для аналитиков и управленцев у нас ведь еще и практическая. То есть упор на практику. Польза теоретического формата и польза практического – есть перевес в какую-то сторону?
Безусловно, есть. Теория дарит некоторые элементы этого «опыления», про которое я рассказывал. То есть она тебе в краткосрочной перспективе как будто бы ничего не давала, но в долгосрочной там может что-то прорасти. А практика тебе результат дает здесь и сейчас – в краткосрочной перспективе. Это безусловный плюс, и люди гораздо больше рады и довольны происходящим.
Кстати, есть две вещи, которые меня удивили на конференции. Первая: когда Александр Чавалах спросил, кто первый раз на конференции Инфостарта, и где-то 90% людей подняли руку. Мы поняли: это же абсолютно новая аудитория. И мы даже не понимаем, как с ней сейчас работать, какие доклады вообще читать. С ними, наверное, надо как-то по-новому.
Вторая: по части некоторых докладов у меня был определенный скепсис – люди не будут вовлечены. Но в некоторых случаях не пришлось даже как-то фасилитировать, и уровень вовлеченности был поразительный: все чем-то занимаются, все вовлечены, все хихикают.
Я думаю, что это лучшая реклама нашей конференции.
Но это не столько реклама, а сколько реальный эффект от происходящего.
Я своих собеседников прошу что-нибудь пожелать коллегам, начинающим специалистам. Есть у тебя какая-то мудрость?
Мудрость такая – не бояться. Сила в правде. Нужно не бояться, всегда говорить правду и делать так, как говорит тебе сердце.
На Инфостарт вы можете посмотреть мастер-класс Артема с конференции «Анализ и Управление в ИТ-проектах 2023». В нем участники рассмотрели реалистичную бизнес-задачу и разложили ее на основные виды UML-диаграмм (Use case, Class, Statechart, Activity, Sequence), а также познакомились с инструментом PlantUML.