Управление разработкой *

Привет! Меня зовут Игорь Федорчук, я руковожу разработкой в направлении «Монобренды» в GRI.

За последний год компания заметно выросла: команд стало больше, изменений и интеграций — тоже. А процессы в разработке долго оставались такими же, какими были пару лет назад. В какой-то момент это перестало «склеиваться» само собой: ответственность размылась, централизованной точки входа в команды не было, а коммуникация стала слишком неэффективной.

Это первая статья о том, как мы пересобирали процесс разработки в GRI — от получения запроса от заказчиков до выкатки в прод. В этой части я разберу роли (тимлиды, техлиды, TPM), зоны ответственности и общий флоу. Во второй части покажем, как мы приземлили это в Jira и метрики, а в третьей — как масштабировали поставку: релизы, код-ревью и инциденты.

Начали мы не с Jira и не с попытки «ускорить релизы», а с зоны ответственности. При росте она ломается первой: задачи начинают зависать на стыках ролей, статусы приходится собирать вручную и дублировать в несколько каналов коммуникаций, а «владелец результата» меняется по ходу движения.

Для кого статья: для тех, кто интересуется облаками или планирует заниматься такой разработкой.
О чём статья: ожидания и впечатления людей, присоединившиеся к нашей команде не так давно.
Об авторе: лид стрима в облачном провайдере, набирал большую часть команды в 2024-2025, пришлось скорректировать процесс проведения интервью и создать онбординг.

Продолжаю цикл статей о своей команде и об облаке, которое развиваем.

В этой статье – история нашего роста: как мы отбирали кандидатов, преодолевали «порог входа» в сложные технологии и формировали культуру разработки. Через интервью с участниками команды вы увидите, как менялись их ожидания и что стало реальностью. Это не просто рассказ о найме – это опыт создания команды, где каждый вносит вклад в общий результат. Это был достаточно долгий непростой процесс: процесс поиска, обучения, притирки, развития стандартов.

Недавно знакомый PM попросил рассказать “Что значит отвечать за качество?” в контексте продуктовых команд. Вопрос оказался не из простых, ведь каждый проект имеет свои особенности. Да и понятие качества может отличаться. Ниже — мой взгляд на тему через призму измеримых показателей. Если у вас есть дополнения, другие метрики или иной управленческий опыт — велкам в комментарии. Будет интересно обсудить и расширить картину.

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

Говорят, что так получится закрывать задачи без горящих дедлайнов. Но когда дело доходит до практики, матрица перестает работать уже через неделю. И это не потому, что люди ленивые. Приоритизация в компании — это не личная привычка каждого, а целый управленческий процесс.

Помните момент, когда вы впервые попробовали ChatGPT или GitHub Copilot? У меня это было похоже на взрыв: привычные процессы рухнули, а на их месте начала формироваться новая реальность. ИИ не просто ускоряет работу — он заставляет переосмыслить сам подход к хранению и обработке информации.

Раньше я, как и многие, хранил готовые документы: Word‑отчёты, PowerPoint‑презентации, схемы в графических редакторах. Потом пришёл момент, когда я поймал себя на мысли:

«Почему я трачу время на поддержание десятков копий одного и того же текста? Почему не хранить „исходники“, а документы генерировать по мере необходимости — как сборку кода?»

Т��к родилась концепция, о которой я хочу рассказать.

Привет, Хабр! Меня зовут Антон Осетров, я разрабатываю СнК в компании YADRO. Раньше я проектировал отказоустойчивые бортовые вычислители, а также испытывал в лаборатории микросхемы. В этой статье я расскажу, что такое DFT, зачем это нужно, а также сравню популярные архитектуры, с помощью которых DFT реализуют на FPGA.

Я долго размышлял на данную тему и наконец решил изложить.

Вся эта история с оценкой кода по количеству написанных строк или другие попытки оценить объем работы мне всегда не давали покоя.

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

Придешь утром в офис и начинаешь что-то писать. А вечером мне нравилось иногда нажать ctrl+z и смотреть в ускоренном темпе, пусть и в обратном порядке, как бегал курсор, как выделялись, появлялись и исчезали какие-то блоки кода. Сначала условие и цикл появились в одном месте, потом кусок кода из цикла перешел в процедуру, цикл вообще исчез и т.д.

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

Сейчас, в эпоху тотальной увлеченности ИИ, меня не покидает мысль, что неплохо бы весь этот когнитивный процесс легализовать.

Здесь не будет инструкций как я это сделал. Здесь будет просто рассуждение вокруг да около.

О чем эта статья

Проблемы клиентов живут на проде годами. Поддержка о них знает, аккаунтам они снятся, разработка горит на проектах, а продукт почти не меняется. Клиенты пишут снова и снова, команда выгорает.

Триггерит?

Поздравляем, у вас сломана петля обратной связи.

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

Я разобрала, что произошло за последние месяцы, почему кодинг, что называется, "по вайбу" оказался опасной иллюзией, и что теперь делать разработчикам, чтобы не остаться за бортом.

Пятница, конец спринта. Команда сдала всё в срок. Клиент доволен. Тишина в эфире. Я смотрю на экран и понимаю, работу затащили, как и всегда, но какой ценой?
Команда не выгорела, а я — да.

Выгорел, следя, чтоб не выгорела команда — иронично.

Специалисты, поработавшие много лет в IT, иногда чем-то напоминают людей преклонного возраста, которые встретившись, начинают рассказывать о наболевшем.

Так произошло и со мной, когда встретился со своим другом, работающим в IT уже с десяток лет. Мы незаметно и довольно стремительно переключились на обсуждение болячек связанных с работой. И очень быстро нашли точки соприкосновения по одной мучительной боли: рабочие чаты

Привет, Хабр! Меня зовут Егор Дудин, я технический руководитель юнита «Деловые услуги» в Авито Услуги. В этой статье я излагаю своё видение построения и работы с обратной связью и её роли в крупной IT-компании. 

Здесь будет больше про личный практический опыт, а не теорию. Это статья про развитие моего подхода к фидбэку от тяжелого и утомительного к простому и эффективному.

Под катом - кейсы из практики, примеры работы с фидбэком и 13 советов от меня.

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

Сегодня поговорим об этом парадоксе и о трех этапах, через которые проходит команда, когда давление ожиданий начинает ломать коммуникацию.

Фаза 1 – высокие стандарты как источник перфекционистской культуры

Высокие стандарты – это естественная часть профессиональной среды. Однако проблемы начинаются, когда эти стандарты превращаются в культуру, где нет места для «неидеального» процесса. Это происходит незаметно:

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

В законодательстве как Российской Федерации, так и прочих стран земного шара, возможно найти противоречия, когда одно и то же событие в разных нормативно-правовых актах трактуется взаимообратно. Последнее приводит к необходимости судебных разбирательств. Казалось бы, какое это имеет отношение к информационным системам и технологиям? Несмотря на то, что внедрение программного обеспечения сводит до минимума случаи мошенничества и воровства сотрудников за счет прослеживаемости операций, находятся и те, кто умело пользуется недоработками системы.

Детективный контроль позволяет выявлять подобные случае по мере возникновения неблагоприятных событий. Наоборот, предиктивный контроль пресекает подобные исходы на корню. Именно на последних мы и остановим внимание в данной статье. Применительно к программному обеспечению подобный вид проверок тесно связан с термином SOD (Segregation of Duties).

Цель данной работы состоит применение методологии SOD в проектах внедрения корпоративных информационных систем, что обеспечит реализацию бизнес-процессов компании в ИТ-решении образом, исключающим/минимизирующим мошеннические действия со стороны работников. Достижение заявленной цели потребует решения следующих задач:

Что будет, если больше 200 бэкенд‑разработчиков запускают по 2–3 новых проекта в неделю в более чем 400 микросервисов, написанных на пяти разных языках — C++, Go, Python, Java и PHP? Ответ хорошо знаком любому, кто сталкивался с быстрорастущей распределённой системой: хаос появляется быстрее, чем успеваешь его отлавливать. И в какой‑то момент становится очевидно, что нужна надёжная точка контроля, чтобы поддерживать архитектуру в рабочем состоянии.

В Яндекс Еде этой точкой стало архитектурное ревью — процесс, который постепенно вырос из локальной инициативы в полноценный инструмент управления сложной системой. В этой статье я расскажу, как эволюционировало архревью, какие инсайты появились по пути и как этот процесс выглядит сегодня.

AI‑инструменты часто делают одно и то же: они выбирают слишком тяжёлое решение там, где достаточно простого. Ценность человека — в инженерном суждении: распознать плохую архитектуру, остановить усложнение, выбрать более простой путь, держать систему в здравом состоянии.

Когда таск-трекер внезапно уходит с рынка, процессы не нажимают на паузу. Команда по-прежнему должна держать в порядке задачи, сроки и коммуникацию — особенно если работа идет в высоком темпе. В этот момент перед бизнесом встает болезненный вопрос: чем заменить систему, которая была встроена в ежедневные процессы?

Есть проекты, которые с первого дня пахнут успехом. А есть те, от которых веет таким могильным холодом, что хочется завернуться в плед, удалить мессенджеры и переехать в деревню без интернета. Проблема в том, что часто мы слишком поздно замечаем запах горелого кода и безнадёжных дедлайнов.

Живой пример

Однажды мне в руки «по наследству» от предыдущего руководителя достался проект по автоматизации взаимодействия с подрядчиками. Задача важная: подрядчиков более 50, привлекаемых сотрудников — несколько тысяч, за всеми нужен учёт и контроль, который на тот момент осуществлялся полностью вручную, и занимался этим не один-два человека, а аж целый отдел. Неудивительно, что внутренний аудит это не устраивало, и нам было велено «срочно все автоматизировать». Генеральный директор поставил свою визу и отметил в календаре дату, когда ему нужен результат — через год.

Мы привыкли думать, что архитектура программ рождается из требований бизнеса, бюджетов и технологий. Но в самом начале любого проекта лежит архитектура мышления — разработчика, заказчика, пользователя. Эта статья и ряд других в серии «каскад» — попытка рассмотреть проектирование как отражение когнитивных механизмов человека. Не UX, не поведение пользователей, а именно то, как фазы нашего мышления формируют будущую систему. И главное — как, поняв это, создавать более устойчивые и человечные архитектуры.

Мода на то «вкат» в IT появилась задолго до пандемии и массового распространения удаленного формата работы. Я помню пасты на двачах и мемы про «300кк/наносек синьора-помидора» в 2016-2017 годах - уже тогда многие стремились попасть в эту сферу из-за высоких зарплат и относительно низкого порога входа. После распространения удалёнки, хайп вокруг вката вырос многократно: появилось ещё больше желающих работать, лёжа на шезлонге где-нибудь на Бали с ноутбуком на коленках и с коктейлем в руках.

На фоне стремления огромного числа людей вытянуть свой счастливый билет в сказочный мир больших зарплат, удалённой работы, гибкого рабочего графика и достаточно низкой ответственности за результаты работы по сравнению с другими профессиями, начал набирать популярность феномен накрутки опыта, который подавался как эффективный способ вкатиться сразу на высокую зарплату на должность миддла и выше, минуя низкооплачиваемые (а иногда вообще не оплачиваемые) стажировки и джуновские позиции.

Логика простая: в IT-сфере профильный диплом не нужен, опыт из резюме почти никогда не просят подтвердить официальными документами. Зачем в таком случае тратить годы на учёбу в профильном ВУЗе и самообучение, начиная свой карьерный путь с позиции стажёра, если можно продумать легенду (или попросить кого-нибудь с реальным опытом выдумать её для вас), поставить в резюме 3+ года опыта, потратить на подготовку максимум год (а с ментором – раза в два меньше), походить по собесам, получить оффер и сразу начать «рубить бабло»? Так делали многие, и у многих получалось.