Обновить
405.78

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

Планирование, отслеживание и контроль

Сначала показывать
Порог рейтинга
Уровень сложности

Баг не в коде, а в словах:  как требование превращается в уязвимость

Уровень сложностиПростой
Время на прочтение7 мин
Просмотры2.5K

Всем привет! Меня зовут Саша Симоненко, и я операционный директор кибербез компании Xilant. Эта статья родилась из моего сентябрьского выступления на конференции KazHackStan 2025 в Алматы, где рассказывал, как качественные бизнес-требования помогают избежать проблем с безопасностью.

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

Читать далее

ИИ в управлении проектами: как я применяю нейросети в реальных проектах и что получается

Уровень сложностиПростой
Время на прочтение5 мин
Просмотры16K

На конференции PMSOFT этого года услышал утверждение, которое потом подтвердили преподаватели МГТУ им. Баумана на курсе «ИИ в управлении проектами»: «ИИ не будет управлять проектами. ИИ будет избавлять менеджеров от рутины, чтобы те сосредоточились на стратегии». Это не маркетинг. Это то, что я наблюдаю на практике последние 8 месяцев.

Читать далее

Обзор возможностей для разработчиков при работе с VK Mini Apps

Уровень сложностиСредний
Время на прочтение12 мин
Просмотры1K

В 2025 году аудитория ВКонтакте достигла 92,5 млн пользователей в месяц. Пользователи ВКонтакте активно используют все внутренние сервисы, в том числе мини-приложения и игры, которые любой внешний разработчик может представить многомиллионной аудитории с помощью VK Mini Apps.

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

Читать далее

Обзор 10 лучших таск-трекеров для управления задачами. Что изменилось за 2025 год

Уровень сложностиПростой
Время на прочтение13 мин
Просмотры13K

Подготовил обзор 10 популярных таск-трекеров и основных обновлений, которые выкатили в 2025 году.

Рассказываю про новые возможности для автоматизации, AI-помощники и AI-агенты, переосмысление UI-дизайна, новые интеграции и гибкие настройки под разные команды.

Читать далее

Управление проектами: дайджест публикаций #44

Уровень сложностиПростой
Время на прочтение13 мин
Просмотры3.1K

19 видов диаграмм, история и будущее Ганта, выбор между скрам и канбан, основы тайм‑менеджмента, краткий курс по менеджменту, геймификация канбана, кросс‑командные проекты и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Читать далее

Пример процесса работы с техническим долгом

Уровень сложностиСредний
Время на прочтение4 мин
Просмотры3.7K

Как систематизировать работу с техническим долгом

Техдолг растёт, пока его никто не контролирует. Мы решили это так: выделили отдельную доску в Jira, разделили процесс на Backlog → To Discuss → Ready for Development → В работе, проводим регулярный груминг, оцениваем и приоритизируем задачи, сделали быстрые фильтры и дашборд для контроля времени.

Результат: прозрачность и приоритетность задач, техдолг перестал копиться «в стол», стало проще брать задачи без хаоса, улучшилось качество кода, выросла инициативность команды.

Читать далее

Новая арифметика трудозатрат

Уровень сложностиСредний
Время на прочтение7 мин
Просмотры2.8K

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

Устали от того, что 2SP+2SP 4SP? Не знаете, как объяснить, что у одной команды фича на M большемерит, а у другой команды фича на L маломерит и потому они займут примерно одинаковое время? Тогда вам сюда!

Читать далее

Будет ли важна чистота кода в ближайшем будущем

Время на прочтение3 мин
Просмотры8.2K

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

Мне приходит на ум то, что в принципе мы подобный слом уже видели лет 15–20 назад. Для программиста старой школы сутью программирования, собственно, было постановка задачи, её реализация с помощью алгоритма и оптимизация этого алгоритма по скорости. Сам инструмент — язык, а уж тем более чистота кода — считалась вторичной. Задачей программиста было написание в принципе работающей программы.

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

Требования к программистам поменялись из-за изменения бизнес-требований. Если раньше задачей программиста было придумать и реализовать программу (он одновременно был и бизнес-аналитиком, и дизайнером, и архитектором, и алгоритмистом), то сейчас появилась возможность создавать ТЗ и интерфейс не программистам. Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.

Читать далее

Front & Back End инновационного процесса

Время на прочтение8 мин
Просмотры1.3K

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

Читать далее

Реализуем отображение OKR в JIRA

Уровень сложностиСредний
Время на прочтение15 мин
Просмотры3.4K

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

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

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

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

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

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

Читать далее

«У нас даже собеседования прокачивают грейд»: как IT-компания Soft Media Group растит лидов

Уровень сложностиПростой
Время на прочтение5 мин
Просмотры2.7K

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

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

Читать далее

Как я оптимизировал отдел и получил врагов вместо премии

Время на прочтение4 мин
Просмотры46K

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

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

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

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

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

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

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

Читать далее

Как тимлиду работать c «видимостью» инженеров в команде и зачем это нужно

Уровень сложностиСредний
Время на прочтение16 мин
Просмотры10K

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

Читать далее

Ближайшие события

Семь кругов финтеха глазами разработчика: что ломается в платёжных интеграциях

Время на прочтение13 мин
Просмотры2.7K

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

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

Читать далее

Один Swagger вместо сотни страниц Confluence: как в Рунити навели порядок в API-документации

Уровень сложностиПростой
Время на прочтение9 мин
Просмотры4.5K

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

Читать далее

Чувство вины, размытые ТЗ и страх говорить: о чём молчит ваша команда

Уровень сложностиПростой
Время на прочтение3 мин
Просмотры670

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

Читать далее

Зачем компаниям платформенный подход и как он возникает даже без отдельной команды

Время на прочтение13 мин
Просмотры1.1K

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

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

Читать далее

Требуют как со взрослых: почему пора перестать стыдиться российского софта

Уровень сложностиПростой
Время на прочтение7 мин
Просмотры19K

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

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

Читать далее

Как разработчику вырасти с помощью продуктового мышления

Уровень сложностиПростой
Время на прочтение7 мин
Просмотры1.5K

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

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

Читать далее

Краткий курс по менеджменту за 10 минут: база, которая вытянет любой проект

Уровень сложностиПростой
Время на прочтение10 мин
Просмотры34K

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

Читать далее

Вклад авторов