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

Среди топ‑менеджеров, а также линейных руководителей в IT‑компаниях периодически возникает вопрос: является ли та или иная команда разработки производительной?

Пытаясь ответить на этот вопрос, многие приходят в тупик, так как осязать цифровое производство крайне непросто, а уж измерить его — тем более!

В данной статье мы с вами попробуем разобраться, каким образом все‑таки можно попробовать измерить производительность команды разработки.

Также стоит подчеркнуть, что все описанное в статье уже применяется в IT компании Flang, в которой я на данный момент времени являюсь CTO.

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

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

Сегодня мы расскажем о внедрении кросс-командной приоритизации во всей компании Спортмастер Лаб, и о том, как мы:

- сократили время планирования разработки в 9 раз (с 18 до 2 недель).

- увеличили количество значимых для бизнеса функций в 5 раз без роста команды разработчиков.

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

В прошлый раз мы обсуждали PDCA — про оценку того, как рук-ль работает с командой. Теперь — о командах, на уровнях которых работает CTO (будем для общности называть его руководителем технического домена). CTO работает не только с разработкой. Его зона ответственности охватывает множество бизнес-доменов — от аналитики до маркетинга. Разберём, как это устроено на разных уровнях компании, определив, с кем он взаимодействует и из чего складывается оценка его деятельности.

Выбрать AI для кода непросто. Сравнили Bolt, v0, Lovable, Replit, Cursor, Windsurf в 5 задачах: от прототипов (текст/Figma) до игр и full-stack приложений.

Тесты показали: один строит прототип за 15 секунд, другой собирает игру в один промпт. Узнайте, какой инструмент эффективен для вашей цели.

Меня зовут Рустам Галимов, я начальник отдела эксплуатации средств защиты информации (СЗИ). Моя команда занимается поддержанием, развитием и эксплуатацией СЗИ, и участвует в разнообразных проектах по внедрению этих самых СЗИ внутри компании. Кроме того, у нас проходят сессии планирования целей на следующий год, и иногда возникает внезапная необходимость включиться в какое-либо очень важное мероприятие.

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

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

Краткое примечание о значении "вайб-кодинга" (vibe coding): В этом посте я исхожу из того, что вайб-кодинг повзрослеет, и люди будут использовать его для настоящей инженерии, а версия "отключи мозг" останется только для прототипирования и забавных проектов. Для меня вайб-кодинг просто означает позволить ИИ делать работу. Насколько внимательно вы решите следить за работой ИИ, зависит исключительно от решаемой задачи. Для продакшена вы внимательны; для прототипов вы расслабляетесь. В любом случае, это вайб-кодинг, если вы не написали это вручную.

Еще одно примечание: Месть происходит в самом конце, как в кино.

ОК! Разобравшись с этими административными вопросами, поехали!

Полтора года назад мы в RuStore собрали новую команду, чтобы с нуля разработать собственное платёжное решение. Тогда всё началось с одной фичи. Казалось бы, «просто запилить», чего тут сложного. Но на деле это обернулось целым кварталом разработки, бесконечными доделками и болью на финальном этапе интеграции. Тогда мы столкнулись с типичным набором проблем — от отсутствия документации и слабой декомпозиции до невозможности предсказать сроки. Да, в конечном итоге всё как-то заработало, но по ощущениям исключительно на энтузиазме.

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

«Нужный человек не в том месте может перевернуть мир».

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

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

Данные OpenRouter показывают тенденцию: разработчики охотно платят за Claude, несмотря на наличие бесплатных альтернатив от Google. При создании продакшн-приложений для них важнее стабильность и предсказуемость ответов ИИ, чем цена - даже если токены бесплатны.

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

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

В этой статье я расскажу о своём подходе, как я справляюсь с такими ситуациями.

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

Вы думали, что путь от Senior Developer до Tech Lead — это всего лишь прибавка к зарплате и новый пункт в резюме? Увы. Техлид - это не только про разработку, но и про управление командой в штормовые времена, сохранение продукта в моменты кризиса, а еще про самодисциплину и менеджмент.

От вас будет зависеть не только качество кода, но и весь проект.

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

Привет, Хабр! Меня зовут Лера, я технический писатель в Авито. Делюсь с вами разбором полезной книги — «Радикальная прямота» Ким Скотт.

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

В статье разбираемся, в чём суть философии радикальной прямоты, какие ошибки совершают руководители и как построить культуру искренней обратной связи в команде.

Специализированные AI-агенты для кодирования автоматизируют 79% задач разработки, радикально меняя процесс разработки ПО. Исследование показывает, что веб-разработка и создание пользовательских интерфейсов стали первыми мишенями трансформации, а стартапы используют передовые инструменты AI для кодинга примерно в 2,5 раза активнее крупных предприятий.

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

Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста Podlodka и автор Роадмапа Тимлида. Веду телеграм-канал Teamlead Good Reads, где каждый день делюсь идеями о работе с командами. 

Сегодня — перевод и разбор классной статьи инженера, технического директора и основателя стартап-инкубатора Limbe Labs и лаборатории Red Hat Джереми Брауна. Он рассказывает о том, как эффект IKEA (тот самый эффект, когда мы особенно ценим то, что сделали сами) может работать, и как иногда он больно бьёт по управлению изменениями.

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

Что будет в этой статье:

(перевод с комментариями "The Death of Product Development as We Know it" - Julie Zhuo, 25 марта 2025)

Прощай, трёхногий стул, команды на две пиццы и "менеджеры"

О возможностях ИИ в разработке, дизайне и документации написано уже много. Но мне кажется, не менее интересные изменения происходят в том, как команды строят продукты в эпоху ИИ.

Этот пост создан при участии Хенри Модиссета, руководителя дизайна в Perplexity. Я восхищаюсь Perplexity по многим причинам, и одна из них - это то, как они как компания применяют ИИ на практике и находятся на передовой нового подхода к работе.

Доброго времени, Хабр! Меня зовут Эдвард. В сфере обеспечения качества я с 2012 года. Последние 7 лет работаю в Т-Банке, начинал со старшего специалиста по тестированию бэкэнда и работал в Т-Инвестициях. А сейчас занимаю позицию QA Head управления разработки социальных платформ.

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