19 видов диаграмм, история и будущее Ганта, выбор между скрам и канбан, основы тайм‑менеджмента, краткий курс по менеджменту, геймификация канбана, кросс‑командные проекты и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Как систематизировать работу с техническим долгом
Техдолг растёт, пока его никто не контролирует. Мы решили это так: выделили отдельную доску в Jira, разделили процесс на Backlog → To Discuss → Ready for Development → В работе, проводим регулярный груминг, оцениваем и приоритизируем задачи, сделали быстрые фильтры и дашборд для контроля времени.
Результат: прозрачность и приоритетность задач, техдолг перестал копиться «в стол», стало проще брать задачи без хаоса, улучшилось качество кода, выросла инициативность команды.
Как складывать трудозатраты по-новому. Когда хочется быть гибким, но привычные сторипойнты не решают проблему, а как будто только создают новую. Попробуем изобрести новый гибкий способ расчета трудозатрат, который, работает.
Устали от того, что 2SP+2SP ≠ 4SP? Не знаете, как объяснить, что у одной команды фича на M большемерит, а у другой команды фича на L маломерит и потому они займут примерно одинаковое время? Тогда вам сюда!
В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках. Это — с одной стороны. С другой стороны — ругают LLM, потому что код там не всегда чистый и, дескать, программирование с LLM — это не программирование вовсе, и навыки такого программиста ничего не стоят.
Мне приходит на ум то, что в принципе мы подобный слом уже видели лет 15–20 назад. Для программиста старой школы сутью программирования, собственно, было постановка задачи, её реализация с помощью алгоритма и оптимизация этого алгоритма по скорости. Сам инструмент — язык, а уж тем более чистота кода — считалась вторичной. Задачей программиста было написание в принципе работающей программы.
Что касается чистоты кода: использование отступов и понятных названий функций, переменных и классов уже считалось большой аккуратностью. Для первого поколения ПО, в общем-то, и не предполагалось, что можно эффективно и полноценно работать с чужим кодом. Появление специализированных библиотек считалось подспорьем, но предполагало, что программист и сам должен быть способен написать подобное с нуля. Программист, который пользовался только библиотеками, считался не настоящим, а ламером, «пользователем».
Требования к программистам поменялись из-за изменения бизнес-требований. Если раньше задачей программиста было придумать и реализовать программу (он одновременно был и бизнес-аналитиком, и дизайнером, и архитектором, и алгоритмистом), то сейчас появилась возможность создавать ТЗ и интерфейс не программистам. Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.
Инновационный процесс принято разделять на две принципиально разные, но взаимодополняющие фазы: нечёткую начальную (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 самых больных кейсов рабочего общения.
