Чем занимаешься в компании?
Я являюсь заместителем управления разработки программного обеспечения. Непосредственно координирую отделы между собой, выстраиваю процессы внутри них, отвечаю за разработку по проектам и в рамках развития продукта. Кроме этого, я являюсь одним из ведущих разработчиков нашего отдела и принимаю непосредственное участие в развитии архитектуры и возможностей нашего продукта.
Какие отделы входят в управление разработки и за что отвечают?
Сейчас в составе управления разработки более 40 человек. В него входят команды разработчиков, инженеров тестирования, DevOps, системных аналитиков и технических писателей. Таким образом, мы закрываем процесс реализации разработки с этапа написания ЧТЗ до проведения ПСИ. Конечно, разработка занимает в этом ключевую позицию.
Наши разработчики являются fullstack-разработчиками: они занимаются как фронтендом, так и бэкендом. Основной стек: PHP, JS (jQuery), MariaDB/Postgres.
Расскажи подробнее о командах разработчиков.
Жестко выделенных команд у нас нет, но есть специализации, которые мы условно называем командами:
Проектные команды. Под реализацию отдельных проектов выделяется несколько разработчиков с руководителем разработки проекта во главе. Перед ними стоят задачи как доработки разных частей функционала, так и организация сопутствующих мероприятий (нагрузочных тестирований, подготовки релизов, миграций и пр.). Помимо разработчиков в проектах принимают участие и другие отделы нашего управления.
Команда разработки интеграций. Ребята из этой команды занимаются реализацией интеграций в рамках проектов, поддерживают и развивают интеграцию с государственными системами, а также развивают наш модуль интеграционной шины, позволяющий быстро встраиваться в экосистемы наших клиентов.
Команды разработки отдельных модулей. Некоторые модули продукта имеют высокую сложность и требуют более узкой специализации для их развития, поэтому для их разработки выделяются постоянные команды из нескольких человек. Такими модулями стали модули Смет, КСП, ТИМ и некоторые другие.
Команда разработки и развития продукта. Сам продукт насчитывает более нескольких десятков модулей: базовых или реализующих частный бизнес-функционал. Разработчики из этой команды являются «универсальными бойцами». Они найдут решение задачи, касающейся почти любого модуля, а могут и создать новый. В этой команде чаще всего начинают свой путь новички.
Команда развития фреймворка и общей архитектуры. В нее так или иначе входят все наши ведущие разработчики. Ребята принимают участие в обсуждении подходов с системным архитектором и берут на себя реализацию нередко очень сложных задач. Именно их работа помогает расширять возможности нашего продукта, оптимизировать его, повышать безопасность и многое другое.
Обычно круг задач, с которыми предстоит работать разработчику, определяется во время прохождения испытательного срока. В нашей команде важны разработчики любого уровня, задачи есть для всех.
Ты упомянула, что помимо разработчиков в управление входят другие специалисты. Чем они занимаются?
В нашей команде еще есть:
- Команда DevOps-инженеров: ребята отвечают за инфраструктуру, а также процесс поставки кода.
- Команда инженеров тестирования: наши тестеры занимаются как ручным, так и автоматизированным тестированием, активно участвуют в процессах подготовки релизов.
- Команда системных аналитиков: самый молодой наш отдел занимается вопросами подготовки ЧТЗ для разработки нового функционала, вопросами НФТ и требований ИБ по проектам.
- Команда технических писателей: именно те специалисты, которые собирают информацию для документации по проектам и оформляют ее. Кроме того, именно они занимаются развитием внутренней базы знаний по фреймворку и техническим аспектам продукта.
Какие модели методологии разработки продукта вы используете?
Скажу сразу: мы не придерживаемся какой-то одной методологии разработки в ее книжной версии. Мы адаптировали принципы разных методологий под свои процессы. Можно сказать, что работаем по Agile с элементами итеративной разработки. Если сравнить итеративную разработку с написанием картины: у художника в голове есть законченный образ картины, к которому он стремится через постепенную прорисовку наброска.
Сначала мы накидываем базу, а потом ее уточняем и дорабатываем шаг за шагом. У нас версии MVP отличаются от типичных: при «сыром» пользовательском функционале закладывается обобщенная основа для расширения. По мере итераций мы получаем удобный продукт с гибкими возможностями. Поэтому подход у нас масштабируемый и расширяемый.
С точки зрения организации процесса, мы работаем по Scrum. У нас приняты двухнедельные спринты, а каждую неделю мы проводим общую встречу, где синхронизируемся по решаемым задачам. Примерно раз в месяц происходит подготовка релизов. Организацией процессов, проведением общих встреч или встреч по отдельным вопросам занимается наш Scrum-мастер.
На каких принципах строится разработка продукта?
Основные принципы я проговорила — гибкость и масштабируемость. Мы разрабатываем систему высокой конфигурируемости и обеспечиваем тем самым вариативность пользовательского функционала на единой кодовой базе.
А еще нам важен абстрактный подход, который помогает обобщить запросы от разных компаний и придумать оптимальное для всех решение. Чем более высокий уровень абстракции, тем большее количество частных задач мы сможем закрыть. Это дает нам конкурентное преимущество.
Как вы решаете, что будет разработано в первую очередь?
Такие вопросы решаем коллегиально на разного уровня обсуждениях. Например, с представителями внедрения рассматриваем запросы бизнеса. По договорным обязательствам ставим приоритет по тем срокам, которые заказчик ожидает.
Помимо этого есть общее развитие системы — R&D (Research and Development). На встречах с техническим комитетом обсуждаем реализацию и выстраиваем приоритеты по конкретным задачам развития системы.
Какие модули получили свое развитие в 2024/5 годах?
В 2024 году мы развивали архитектуру ПО и разработали гибкий конструктор бизнес-процессов, который позволяет их автоматизировать. Сейчас работаем над тем, чтобы он стал доступен для всех пользователей. Также улучшили дашборд с виджетами на главной странице ЦУС: он подгружает большое количество данных менее чем за одну секунду.
Качественный скачок в развитии получил модуль «ГПР»: теперь у него усовершенствованный графический интерфейс и более быстрая скорость работы. Он адаптирован под реальные строительные графики производства работ, состоит из множества пунктов и растянут на длительный срок. Все это достаточно сложно реализовать в веб-интерфейсе, поэтому продолжим над ним работать.
Серьезное развитие получил модуль «Сметы»: в нем расширили функции для специфичных видов сметных расчетов — сметы контракта и сметы на ПИР. Добавили возможность загрузки новых форматов и упростили форму в веб-интерфейсе.
Это всего несколько примеров задач, с которыми мы работаем. В каждом квартале беремся за новые разноплановые задачи: от глобального развития системы и добавления в нее новых серьезных возможностей до таких рутинных, как конфигурирование и формирование нового функционала.
У нас так построена система, что для одних фреймворков эти задачи будут трудоемкими, но у нас они являются рутинными. Для нас добавление новых функций в пределах модуля — сборка конструкторов. А глобальной задачей может быть разработка новых возможностей: например, микросервисов.
Для такого развития нужны большие человеческие ресурсы. Как быстро растет команда разработки?
В последнее время это примерно два-три человека за квартал. Мы поддерживаем сейчас большой продукт и экосистему к нему, поэтому постоянно расширяемся и ищем разработчиков на сложные задачи.
В каких новых специалистах вы сейчас нуждаетесь?
Мы набираем разработчиков любого уровня и для каждого находим задачи. У джуна недостаточно опыта и знаний, но есть правильный подход к мышлению, желание развиваться и интерес к этой теме. Мидлов и сеньоров тоже подбираем: у них есть опыт и умение проектировать свои решения.
Есть два типа разработчиков: те, кто хочет пользоваться фреймворками, и те, кто хочет их создавать. Меня интересуют вторые.
У разработчиков есть внутреннее обучение?
Для джунов или мидлов назначаем наставника, который подсказывает решения, проводит ревью кода и его одобряет. Код можно писать по-разному, и наставник смотрит, чтобы решения нового разработчика попадали под принципы, о которых я говорила. То есть поддержка для новых сотрудников у нас есть.
Я всегда говорю: если не можете найти решение дольше чем полдня, обратитесь к другим разработчикам. Методом ошибок и совместного обсуждения можно учиться на практике. Обмен знаниями помогает ребятам расти.
Классическое обучение у нас тоже есть. Периодически отправляем ребят на курсы, чтобы они повышали квалификацию. Вот сейчас на Яндекс. Практикуме учатся несколько разработчиков, расширяют свой кругозор. Участие в обучении добровольное.
Какими навыками и умениями нужно обладать, чтобы работать в вашем отделе?
Навыки работы в команде, умение слышать и смелость высказывать свое мнение аргументированно. Таким людям в нашем коллективе всегда легче.
Нужен интерес к развитию продуктов нестандартным подходом. Это должен быть человек, который обладает структурным мышлением и способен к обобщению и абстракции. Наш стек технологий включает PHP 7.4+, JavaScript, jQuery, MariaDB/PostgreSQL и Linux.
Умение пользоваться фреймворками вторично, потому что знание большого количества инструментов не очень поможет. А вот знание того, как устроены эти инструменты и почему они такие — вот это будет очень круто, потому что такой человек сможет создать аналоги.
Если человек хочет уровень middle+, то ему стоит обладать определенными знаниями о строительстве. На этом уровне стоят сложные вопросы интеграции и проектирования новых модулей. Здесь может помочь экспертиза строителей, но придется извлекать из рассказов алгоритмы строительных процессов и глубоко в них разбираться.
Почему разработчику может понравиться работать в «Осмокод»?
Мы разрабатываем сложную систему. Поскольку подход разработки нестандартный и гибкий, он позволяет на своем ядре построить системы самой разной направленности. Сильным разработчикам может быть очень интересно создавать такой продукт.
Мы не загружены бюрократией и всячески этому препятствуем. Стремимся создавать комфортные условия для разработчиков: предоставляем свободу в решении задач и не ограничиваем жесткими рамками. Над ребятами нет трекинга. Мы поддерживаем взаимопомощь, подстраховываем неудачи и отмечаем успехи. Базовый соцпакет у нас тоже есть.