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

Инновационный процесс принято разделять на две принципиально разные, но взаимодополняющие фазы: нечёткую начальную (Fuzzy Front End, FFE) и структурированную завершающую (Structured Back End, SBE).

OKR — штука в целом полезная, если знаете, зачем и как её внедрять.

Сегодня я не собираюсь вам продавать OKR как «идею» или «мечту» как способ достичь того, что не получается с помощью обычных средств. Моя цель сейчас — скорее, рассказать вам, как сделать в инструменте удобный механизм ведения Целей и Результатов (а именно так переводятся Objectives and Key Results) их дальнейшего отслеживания. В качестве инструмента будет выступать Jira, в качестве дополнительного удобства — плагин Structure с его удобными фишками. Рассказ будет поделен на 2 части — о создании механизма и о создании мониторинга.

В конце вас ждёт инструмент, который поможет вам сэкономить на покупке платного плагина для Jira. И который вы сделаете сами с помощью этого гайда.

Часть 1. Создаём механизм

На этапе, когда в компании началось массовое внедрение и команды начали знакомиться с этим подходом, предлагалось ведение всех целей в таблицах и файлах-документах. Для одной команды — вполне себе неплохой вариант, но когда команд за 30 и часть Целей зависит от других Целей, то понять общую картину в куче Excel-таблиц, где каждая команда, хоть и соблюдая общие принципы, но всё же ведет все по-своему — становится крайне тяжело.  И мне это очень не понравилось.

Я решил попробовать найти или сделать механизм для этого.

В бигтехе — всё ради системы. В Soft Media Group — всё ради людей. Здесь ценят чужое время, дают ответственность и не делают культ из митингов. Именно поэтому те, кто однажды ушёл, часто возвращаются.

В статье рассказываем, кто такие Soft Media Group и как работа в небольшой команде помогает развивать ключевые скиллы.

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

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

2010г: по семейным обстоятельствам я оказался в глубоком финансовом кризисе. У меня не было денег даже на бензин. Один знакомый мне предложил поработать у них в отделе 1с-ником. Оплата была небольшая (по сравнению с рынком). Я согласился поработать у них несколько месяцев, пока не найду нормальное место, такой и был изначальный уговор. В отделе 1С было 3 человека, я стал четвертым.

Все, что написано ниже, это, конечно же, произошло не в первый день и не в течение одного месяца. Просто постепенно я погружался в атмосферу коллектива и организации.

Был у них там финансовый отдел, который считался о-о-о-чень важным. Не с точки зрения его пользы, а с точки зрения позиционирования. Они там раздували щеки, что без нас вы вообще никуда. Мы тут самые специалисты. Да без проблем, они в другом конце здания, я с ними не пересекался. Но слышал обсуждения коллег.

В том отделе 4 человека. Одна из их задач была подбирать копейки для счетов-фактур. Чтобы строки с итоговой суммой сходились. Ну вы знаете про округление. Для этого у них был целый инструмент - документ в 1С аж с десятитысячными долями в ценах! Они там сидели вручную подбирали десятые доли копеек. Этот процесс был легендарным. Считалось, что его нельзя автоматизировать - кто ни пробовал, ни у кого не получалось, так мне сказал начальник.

Да как так? Не может такого быть! Я-не-ве-рю! Покажите!

Привет! Я Андрей Леонтьев, тимлид разработки в вертикали Авито Товары. В этой статье рассказываю, зачем тимлиду осознанно прокачивать visibility — управляемую «видимость» инженеров — и как это напрямую влияет на калибровки, промо и скорость получения ресурсов. Покажу, куда «светить фонариком», как выровнять систему ценностей и подбирать инструменты под мотиваторы. Материал пригодится тимлидам, техническим лидерам, PM/PO и инженерам.

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

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

Привет, Хабр! На связи Маргарита Сорочинская, технический писатель отдела архитектуры в Рунити. Хочу рассказать, как мы в компании подошли к описанию API в Swagger — и почему решили перенести туда всё, что раньше жило в Confluence. А еще поделюсь с вами стартерпаком для описания API в Swagger, пошаговой инструкцией и всеми ссылками, чтобы для вас этот путь был уже более простым.

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

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

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

Представьте, как себя чувствуют отечественные производители ПО, когда приходят к корпоративным клиентам, а им говорят: «Ну вот у SAP всё давно работает, у Oracle – поддержка по всему миру, а у вас опять продукт упал после очередного обновления».

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

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

Решение — включить продуктовое мышление: задавать неудобные вопросы и не бояться менять ТЗ. В этой статье пример Mindbox, где разработчики проявляют продуктовое мышление, — посмотрим, как и зачем это делать. 

Менеджмент без коучинга и теории — показываю рабочие фреймворки, которые закрывают 70% задач руководителя.

Привет! Меня зовут Инесса. Я — аналитик в компании fuse8. Предлагаю сегодня поговорить о том, как встроиться в уже сработавшуюся команду. По моему опыту, это всегда испытание. Почти как игра в русскую рулетку: не знаешь, как команда примет новичка и как быстро он подстроится под общий ритм. Новому человеку нужно время на адаптацию, обучение и погружение в процессы. И только потом можно по-настоящему оценить его вклад.

Внедренный программный продукт подлежит дальнейшему развитию, причин для которого достаточно: изменение законодательства, технологические тренды и новинки, цифровизация не автоматизированных областей и др. Часто подобные активности над ИТ‑системами связывают с запросами на изменение (ЗНИ), относящимися к процессу управления изменениями. Это действительно так, однако работа с ЗНИ требует выстраивания регулярных бизнес‑процессов, вовлекающих как бизнес‑пользователей, так и технических специалистов, обеспечивающих надзор над корпоративной архитектурой предприятия и соблюдение целостности существующих ИТ‑сервисов. Для чего согласно EABoK [4] организуются следующие организационные сущности:

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

Сотни сообщений без смысла, игнор просьб, срочные задачи в полночь — вот настоящая «корпоративная культура». Я собрал 7 самых больных кейсов рабочего общения.

Говорят, стажёрам нельзя доверять прод — сломают, наделают ошибок, а потом мучайся. В «Авито» решили доказать обратное: дать ответственность сразу и посмотреть, что будет.

В статье — о том, как выглядят испытания для стажёров и у кого точно нет шансов попасть в команду.

Привет, Хабр.✌️ Это Люба и Кристина, менеджеры разработки в Контуре. Кроме менеджерских дел мы ведём в Контуре настолки про Kanban.

В Контуре уже несколько лет существует практика игры в GetKanban. Все началось с появления нескольких игровых комплектов в офисе, а сейчас это стало регулярной активностью со своей командой организаторов, онлайн-версией и удобными инструментами. Игра стала популярной благодаря своей механике: она в доступной форме объясняет базу Kanban-метода и помогает выявить узкие места в реальных процессах команды. В статье расскажем о том, какую пользу приносит игра, кто больше всего интересуется ею в Контуре, как организован процесс и кто такие ангелы.

Многие считают ITIL (Information Technology Infrastructure Library) устаревшим набором практик, которые не работают на современных процессах. Опыт «Петрович-ТЕХа» доказывает обратное.

Привет, Хабр! Меня зовут Антон Скутин и я business relationship & service level manager в «Петрович-ТЕХ». Вырос из специалиста техподдержки в лида направления качества и сервиса, в компании уже шесть лет, веду телеграм-канал BRM о своей работе. Расскажу про опыт, как мы в «Петрович-ТЕХ» внедрили ITIL и получили реальный профит. В процессе роста компании мы выделили три временных этапа внедрения ITIL-практик.

Статья написана по мотивам моего доклада для конференции DevOps Conf.

Меня зовут Илья Куликов, я руковожу разработкой веб-терминалов в компании «Столото». Сегодня хочу рассказать, как мы превратили ручные релизы и вечные конфликты в почти автономный CI/CD. За почти 10 лет в компании я прошёл путь от бэкенд-разработчика до руководителя направления, в «Столото» же за это время родился и вырос целый продукт — веб-терминал для агентов розничной сети. Изначально у нас был парк дорогих аппаратных терминалов, установленных у агентов. Но как расширить сеть и снизить входной порог? Возникла идея: а что, если сделать аналогичное приложение в браузере? Тогда любой желающий мог бы стать агентом — достаточно старого ноутбука и договора с нами. Так появился полноценный веб-аналог аппаратного терминала со всеми необходимыми функциями для продажи лотерей.

Но вместе с ростом продукта росла и боль: релизы занимали часы, всё постоянно ломалось на проде, а после каждого деплоя команда судорожно грепала логи в поисках причины падения. Мы поняли: без серьёзной перестройки процессов дальше — только хуже. И тогда решили кардинально пересмотреть наш подход к CI/CD. Отказались от классического GitFlow в пользу trunk-based development, полностью перестроили пайплайны в GitLab и внедрили автоматизацию на всех этапах — от сборки и тестирования до деплоя и мониторинга.

В этой статье я делюсь реальным опытом:

- как мы ушли от ручных релизов к автоматическому деплою в прод;

- какие практики и инструменты позволили нам перестать бояться каждого коммита;

- как повысить качество кода и ускорить вывод фич на рынок без ущерба для стабильности.

Этот материал будет особенно полезен техлидам, инженерам DevOps, разработчикам и командам, которые всё ещё живут в мире ручных деплоев, боятся нажимать «мердж» в пятницу вечером. Если вы задумываетесь, как перейти от хаоса к предсказуемости в релизах — вы по адресу.

А как мы этого добились — читайте под катом!