Обновить
328.57

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

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

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

Разработка в 2025 году — это уже не только про умение писать код. Важно уметь работать в связке с ИИ, быстро адаптироваться к новым инструментам и смотреть на задачи шире, чем строки кода. Автоматизация ускоряет процессы, языковые модели становятся полноценным помощником, а кибербезопасность требует внимания как никогда раньше.

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

Что формирует будущее разработчиков

1. ИИ и языковые модели. Инструменты вроде Cursor/Windsurf и LLM помогают быстрее и качественнее выполнять то, что вы уже умеете, или разобраться в новой теме. LLM берут на себя «черновую» работу: исправляют опечатки, улучшают оформление кода, помогают с декомпозицией задач и первичным код‑ревью. Это снижает нагрузку и освобождает время под архитектурные решения.

2. Кибербезопасность. С ростом объема данных и активным использованием ИИ‑решений увеличивается и число атак. В 2025 году безопасность уже не «дополнительная опция», а критически важный аспект разработки. В приоритете: оперативное устранение уязвимостей, поддержка зависимых библиотек в актуальном состоянии, а также проектирование безопасных систем.

Главные скиллы

— Промпт‑инжиниринг и итеративный подход. Чем лучше вы понимаете и формулируете задачу для LLM, тем лучше результат. Разбивайте сложные задачи на небольшие, пошагово уточняйте вводные, добавляйте контекст, референсы и критерии качества.
 — Умение адаптироваться к изменениям. Мир меняется быстро: нужна гибкость и готовность учиться новым инструментам и подходам.
 — Осознанное применение ИИ. ИИ ускоряет рутину, но не заменяет понимания. Код или решения без осознания внутренних механизмов сложнее поддерживать; сырые и неадаптированные ответы часто дороже, чем написать с нуля.
 — Критическое и системное мышление. Хороший разработчик видит систему целиком, задает вопросы, сравнивает варианты и думает на несколько шагов вперед: архитектура, влияние изменений, риски и стоимость владения.

Как развиваться разработчику

1. Книги, курсы и пет‑проекты. Рабочая связка: цель → план → небольшой прототип → разбор ошибок. LLM помогают собрать персональный план обучения: перечисляете, что знаете и что хотите изучить, — получаете черновой roadmap и список практик.

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

3. Полезные тг‑каналы. Удобно следить за анонсами моделей, обновлениями LLM и промпт‑подходами в профильных каналах. Выберите несколько источников и регулярно сверяйте советы с документацией и собственным кодом.

Теги:
Рейтинг0
Комментарии0

Как новенький сервис превращается в легаси помойку

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

1 шаг. Восторг и энтузиазм

Залетаем на радостях. Думаем над архитектурой. Пишем чистейший, как слеза младенца, код. Применяем все свои знания и опыт, а ещё выплескиваем все паттерны и технологии, которые накопились за годы воздержания.

2 шаг. Не хватает тяги

Наша ракета отлично стартанула. Вкушаем первые плоды переписанного сервиса. Радуемся. Но начинаются первые проблемы. Бесплатный пробный период хорошей жизни закончился - нагрузка начинает возвращаться обратно. В начале нам дали люфт. Но халява быстро кончилась — бизнесу снова понадобились фичи "на вчера". Вынуждены меньше фокусироваться на прекрасном будущем и всё больше концентрироваться на грустном настоящем. Начинаем активно поддерживать текущую версию сервиса и параллельно разрабатывать новую.

3 шаг. Кто же убийца?

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

4 шаг. Кто мы и откуда пришли

Энтузиазма поубавилось. Сервис уже переживает первые послабления в качестве в угоду скорости. Надо скорее дописывать MVP. Качество, структура и масштабируемость перестали быть приоритетом. Руководство уже и не помнит, зачем всё это затеяли. Сама идея становится всё более призрачной.

5 шаг. Мы не сеем, мы жнём

MVP готово. Переезжаем на наше новое детище. На старый сервис можно поставить печать [DEPRECATED] и убрать на задворки. Начинаем пользоваться и выполнять новые задачи уже там.

6 шаг. Мне кажется, мы здесь уже были

Через пару недель разработки появляется стойкое ощущение дежавю. Сервис вроде новый, построен аккуратнее. Но почему-то замечаются те же ошибки. Местами - те же подходы. Уже есть зоны кода, в которые никто не решается лезть. "Чёрные дыры" проекта. Да и багов меньше не стало. Мы же не сделали вторую версию такой же кривой, как первая? Мы же могли потратить время и ресурсы впустую? Ведь так?

7 шаг. Убийцей был дворецкий!

Давайте анализировать, как так вышло. Собирается команда на митинге и начинает ретроспективу. Кто виноват?

Первое, что приходит в голову - ограниченный фокус внимания на новом сервисе. Мы параллельно поддерживали старую систему, и ресурсы постоянно утекают туда.

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

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

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

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

Заметки в никуда

Теги:
Всего голосов 4: ↑3 и ↓1+3
Комментарии3

...и вот у меня спрашивают «А какие у тебя мотивация работать и стимул для развития?», а я говорю «Деньги». Ты бы видел как на меня посмотрели! Как будто ждали какой-то другой ответ. Что мне надо было ответить? Не понимаю. Работать за идею?

Недавно общался со своим другом с прошлой работы и разговор зашел за повышения и performance review. И этот момент ТОТАЛЬНОГО непонимания руководителями желания сотрудника зарабатывать больше мне как-то скребется, я слышал о похожих ситуациях уже немало.

Хотелось бы здесь написать остро "НИКТО!", но буду мягче. Если мы будем честны: мало кто в найме готов работать только за идею. Я уверен, если предложить этому ревьюверу: «Ой, а давай мы твою зарплату попилим на весь отдел? Тебе же хватит идеи?», – он быстро сольется.

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

И вот у друга спрашивают: «А что тебя мотивирует, кроме денег?». И в этот момент я думаю: а что мотивирует стоматолога? Чтобы у меня зуб не болел. Но если ему сказать: «Давай-ка, дружочек пирожочек, ты полечишь меня бесплатно? Твоя ж идея – это здоровье людей»? Он меня пошлет и будет прав. И хирург, и пилот самолета, и строитель – все пошлют. Но почему-то в айтишечке считается, что я должен радоваться "идее".

Работа ради идеи возможна, если эта идея твоя. Если же это чужая идея, за чужие деньги, да ещё и без нормальной компенсации – это.. бесплатный кружок по интересам? Фан-клуб с членскими взносами? Секта? Выбирайте что больше нравится.

Отличная компенсация + интересные задачи + адекватный менеджмент = получаем мотивированную команду. Идея и миссия компании – это важно и круто, но это вишенка на торте, а не замена базовым потребностям.

Теги:
Всего голосов 5: ↑4 и ↓1+5
Комментарии8

Ценность разработчика. Мысли о том самом…

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

Баланс между качеством и скоростью

Качество и скорость - это две противоположные крайности одного спектра.

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

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

Хороший разработчик должен быть посередине этого спектра. Каждое решение им принятое должно:

  • закладывать минимальную архитектуру, которую без проблем смогут понять и поддерживать другие

  • иметь возможность базового масштабирования, без фанатизма, но с заделом на возможные изменения завтра

  • учитывать временные рамки, воспринимая время как ограниченный ресурс

  • работать с ограничениями, которые всегда есть, иначе легко сойти с намеченного плана

Продуктовое мышление

Хороший разработчик не ограничивается своим куском кода и клочком текста в ТЗ. Перед тем как приступить к задаче, важно выстроить полную картину. Зачем эта задача бизнесу? Кому это нужно? Какую боль пользователя решает? Чего это нам будет стоить? Иногда ответы на эти вопросы проясняют картину лучше, чем ТЗ от менеджера.

Спор "как правильно"

На разработку всегда можно смотреть с разных углов - из этого и рождается куча "как правильно". Хороший разработчик должен уметь экологично отстаивать свое "как правильно", но при этом давать право на жизнь решениям других членов команды. Очень часто споры происходят между равнозначными вариантами. Здесь важно не воевать, а выбирать то, что выгоднее прямо сейчас. Доверять, уступать, договариваться - вот что отличает нормального разработчика от занозчивого полудурка.

Предсказуемость

Разработчик обязан держать команду в курсе любых затыков и проблем. Он не должен быть черным ящиком. Менеджер должен четко понимать, где риски и потенциальные угрозы. Только так можно грамотно распределять ресурсы, управлять временем и ожиданиями.

Работа с неопределенностью

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

Долгосрочность решений

Хороший разработчик думает "как этот кусок кода будут поддерживать через год", а не как бы закрыть задачу и быстрее взять новую. Долгосрочные решения выгоднее бизнесу: платим в начале больше, но потом пользуемся бесплатно. С краткосрочными наоборот - получаем результат быстро и дешево, но расплачиваемся постоянно.

Заметки в никуда. Подписаться

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии0

Пан или MVP пропал! Дебаты на ProductCamp

Уже в эту субботу, 20 сентября, МойОфис организует жаркий баттл продуктологов в формате парламентских дебатов на ProductCamp. Никакой воды и эмоций — только факты и сильные аргументы.

Тема встречи: «Fail Fast наносит больше вреда качеству продукта и духу команды, чем приносит пользы?»

Мы обсудим, может ли быстрая «обкатка» сырой версии подорвать продукт и команду, и бывают ли ситуации, когда Fail Fast действительно оправдан.

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

Дебаты стартуют в субботу, 20 сентября, в 17:00 в большом шатре. Будет жёсткая профессиональная дискуссия без купюр и сантиментов!

Теги:
Всего голосов 14: ↑14 и ↓0+14
Комментарии0

Вопрос: оцени сколько времени займет выполнение задачи?

Оценка - это, по определению, предположение.

Так что какое число ни назови столько и будешь работать до следующего такого вопроса 😁

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии8

Как не сливать бюджет на разработчиков без задач?

Представим ситуацию. Большой аутсорс, 5 распределённых команд, у каждой обычно в работе по 1–3 проекта. Наступает момент, когда текущий проект сдан, а новый проект ещё не утверждён: документы в стадии подписания, а ТЗ ещё не сформировано. Команда разработчиков ждёт отмашки, возникает свободное время между проектами. Что делать? Бюджет утекает на разработчиков, которые ничем не заняты. Какой выход из ситуации, когда кончились задачи?

Я очень часто сталкиваюсь с этим кейсом, и по моему опыту есть решение. Если дать разработчику волю, он скорее свалит в кофейню, чем будет просиживать штаны, пока нет проекта или задач. Пустая трата ресурсов для вас обоих. Но из свободного времени можно извлечь выгоду как для команды, так и для самого разработчика - последний выиграет даже больше. Речь идёт об обучении. И я говорю не о курсах или конференциях. Лучшее обучение - это практика. В одной из команд мы сделали следующее. Каждому разработчику дали задание: описать свой пет-проект, который он хочет реализовать, и список технологий, которые он при этом прокачает.

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

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

Что мы в итоге имеем и в чём выгода?

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

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

Заметки в никуда

Теги:
Всего голосов 6: ↑5 и ↓1+5
Комментарии4

Про вайб и прочих ИИ агентов в ретроспективе "лихих 90-х"

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

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

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

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

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

Теги:
Рейтинг0
Комментарии0

10 лет в AvitoTech — а минусы будут?

В этот раз в гости пришёл Александр Лукьянченко, технический руководитель кластера Architecture. Саша работает в Авито почти 10 лет: компания менялась на его глазах, а сам он прошел путь от разработчика до менеджера высшего звена. В интервью вместе с Сашей и ведущим Виктором Раевым, руководителем разработки юнита Services Base, поговорим вот о чём:

  • как выглядит путь от разработчика до менеджера высшего звена длиной в 10 лет;

  • какие изменения произошли в Авито с 2016 года;

  • как зарождалась PaaS — платформа, которая теперь облегчает жизнь инженерам;

  • что такое AvitoPlato и какие планы по развитию продукта на будущее.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Теги:
Всего голосов 30: ↑28 и ↓2+26
Комментарии0

Как связаны игра «Что? Где? Когда?» и работа в IT?

А вы знали, что методы легендарной интеллектуальной игры могут стать ключом к эффективной работе вашей команды? Рассказываем в нашей новой статье!

 «За зеркальным столом я капитан команды, а на работе — бизнес-аналитик. Но в последнее время эти роли размываются, потому что параллели между поведением команды за столом и во время обсуждения рабочих задач…как-то уж очень близки. И однажды мне захотелось исследовать, как методы из игры работают в реальной жизни. Как оказалось, большинство моментов применимо» — пишет автор статьи Евдокия Аверина. 

Если хочется идти дальше стандартных подходов и строить по-настоящему слаженную команду — статья «Что? Где? Когда?» и эмоциональный интеллект в бизнес-команде для вас!

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Инженер по безопасности компании Fortinet представил экспериментальный инструмент KittyLoader. Это небольшой загрузчик, написанный на C и Ассемблере, который автор сам называет крайне ненадёжным и не предназначенным для практического применения.

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

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

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии2

Гигачад на сцене, быдлокодер в опенспейсе

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

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

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

Мне кажется, давно пора признаться самим себе, что разработка делится на два типа: "сказки об идеальных решениях" и "настоящая работа", где первые треплют языком, а вторые решают проблемы бизнеса - хоть это в 95% случаев и превращается в жопоболь через какое-то время.

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

Заметки в никуда

Теги:
Всего голосов 8: ↑7 и ↓1+6
Комментарии2

Поиск скомпрометированных зависимостей через Dependency Track

На днях стало известно о компрометации почти 2-х десятков npm-пакетов (подробнее в этой статье). Зловредный код может похищать криптовалюту. Это не первый раз, когда в зависимости попадает зловред (например, в 2022 году зловред удалял данные).

Один из вариантов поиска наличия скомпрометированных пакетов среди сотен проектов - использование Dependency Track. При этом поиск возможен и в транзитивных зависимостях тоже. На картинке ниже показан процесс. Заходим в раздел "Components", вводим название в формате "pkg:npm/$name$". Далее остаётся отсортировать по версии и найти среди них скомпрометированную (сейчас это легко - нужно смотреть самую старшую версию). Можно поиск производить сразу по конкретной версии. Пример:

pkg:npm/simple-swizzle@0.2.3
Ищем пакет по названию, сортируем по версии
Ищем пакет по названию, сортируем по версии

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

Если знаете альтернативные варианты поиска скомпрометированных пакетов другими средствами - напишите в комментариях.

Теги:
Рейтинг0
Комментарии0

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

Дейлики: благо или зло?

В новом выпуске подкаста «Свободный слот» Саша Прокшина и Паша Федотов разбирают принципы грамотного планирования. Обсуждаем:

  • какими должны быть идеальные итоги встречи?

  • как выглядят секреты эффективной фасилитации и perfect follow-up?

  • и конечно, как выстроить день так, чтобы успеть всё?

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

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Теги:
Всего голосов 27: ↑25 и ↓2+23
Комментарии0
Привет, я Юра, Project-менеджер с 10-летним стажем. Рассказываю о личном опыте в IT. тг: @projectmindset_pm
Привет, я Юра, Project-менеджер с 10-летним стажем. Рассказываю о личном опыте в IT. тг@projectmindset_pm

«О чем на самом деле думает проджект-менеджер во время митинга: перевод с корпоративного на русский»

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

Про оценку сроков

Каждому проджекту знакомо. Митинг с заказчиком и командой, вдруг, не согласовав оценку с менеджером, разработчик говорит: «Ну, это задача дня на четыре... Если ничего не помешает».
Тут же слышится от заказчика: «Фиксируем, через 4 рабочих дня будет готово».
Вспышка, шторм, помешательство. У проджекта в голове: «Ага, “Если ничего не помешает”, так вам ничего и не помешает, конечно. Сейчас начнется: мало ресурсов на сервере, срочный баг от другого клиента, а тестирование? В этой оценке указана только время разработки! Минимум неделя нужна. А обещать буду за 7 рабочих дней».
Проджект тут же говорит вслух на корпоративном: «Предлагаю заложить на задачу 7 рабочих дней с учетом возможных рисков и интеграции в основной процесс. Нужно обстоятельно убедиться, что функционал готов к релизу».
Заказчик недоверчиво фиксирует 7 рабочих дней на задачу — фух, пронесло 😓

Про «немного поменять ТЗ»

Это из фонда золотых цитат заказчиков: «Мы тут подумали и хотим немного улучшить концепцию. Фактически, всё остается по-старому, просто логика немного меняется».
С этого начинается внутренний диалог проджекта: «„Улучшить концепцию“... Это значит пришить к штанам капюшон и выкинуть 3 недели работы. „Логика немного меняется“ — это сделаем из грузовика экскаватор, новый движок, новая база данных и отказ от всего, что уже сделано».
Проджект говорит вслух: «Понимаю ваше стремление к улучшению! Давайте проведем отдельную встречу вместе с аналитиком, где вы подробно расскажете о новой концепции. Мы проведем анализ, посчитаем новые сроки и бюджет и обсудим решение».
(редко кто меняет изначальную логику, увидев новые сроки и бюджет 😉)

Работа PM — это искусство баланса между желаемым, возможным и реализуемым. Главное — сохранять спокойствие и дальновидность.

Подписывайтесь здесь или в тг: @projectmindset_pm

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Что будет с человеком, если его перегрузить задачами до предела? Ну конечно - он выгорит.

Выгоревший сотрудник это реальная проблема, а не «загрустил, пройдет». Она имеет такие вполне конкретные последствия:

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

  2. Падение качества. Это влияет на количество инцидентов и тогда риски возрастают кратно. Восстановление, репутация, штрафы. Например, утечка персональных данных будет стоить до 15 млн только штрафа. А ошибки в мед- или авиаоборудовании могут стоить кому-то жизни.

  3. Текучка. Если сотрудник выгорел, то время до его заявления на вашем столе уже пошло. И его не отговорить, он уже нашел интересную замену. А найм и адаптация нового сотрудника дорого. И есть угроза цепной реакции в коллективе.

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

На ИТ-рынке, в целом, заметен тренд на заботу о состоянии сотрудников. Хотя чаще он довольно поверхностный. Стандартный набор — ДМС, оплата спорта, тим-билдинг, корпоратив, индивидуальная работа с сотрудниками, материальная мотивация. Является ли это достаточным? На мой взгляд — мало, но допустимо. Например, психологов я в малом и среднем бизнесе не встречал, только изредка в корпоративном слое. Работу над положительной нематериальной мотивацией встречал где-то в 20-30% организаций.

Нулевого выгорания не достигли нигде (это невозможно из-за особенностей человеческой природы), но значительно снизить удавалось. Помню случай с ТехноНиколь времен пандемии — им за счет работы с выгоранием сотрудников удалось повысить производительность на 50%! По их оценкам они при этом снизили уровень выгорания с 80% до 20%.

Со стороны сотрудника:

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

Со стороны бизнеса:

Работа с выгоранием — это похоже на регулярную страховку: объем бюджета, который менеджмент готов потратить на проблему, и уровень риска, на который согласен. Где брать на это деньги? В фонде оплаты труда. Если выгорание присутствует — потери производительности — 5-50%. Это размер ФОТ, который потрачен впустую. Можно взять из будущего ФОТ 5% и получить прирост производительности в 10%. А это уже рост EBITDA и чистой прибыли.

Берегите себя, и своих сотрудников, коллеги!

И расскажите как у вас с этим?

Теги:
Рейтинг0
Комментарии2

«СберТех», Cloud.ru и Хабр заколлабились и запустили грантовую программу «Код без границ». Это отличная мотивация для разработчиков и ресурсы для проектов. Можно доработать свой проект с поддержкой сообщества, найти единомышленников и показать свои возможности.

Участвовать просто:

  • разместить свой проект на GitVerse (СберТех) или импортировать его с другой площадки.

  • делится кодом и вдохновляться чужими разработками.

Номинации следующие: ИИ‑инновации, «Наука и образование», «Проекты для всех», «Разработка для разработчиков».

Заявки на грантовую программу «Код без границ» принимаются с 3 сентября по 31 октября. Отбор проведут в ноябре, а результаты огласят в декабре.

Теги:
Рейтинг0
Комментарии2

Delivery Manager: где его место среди Project, Product и Program Manager?

Недавно я публиковал статью о различиях Project Manager, Product Manager и Program Manager. В комментариях закономерно возник вопрос: "А где же Delivery Manager?"

Давайте разберёмся!

В базовой статье я сознательно ограничился тремя ролями - PM, PdM, PgM.
Это клубок который действительно может ввести в ступор даже бывалых, который часто встречается в IT и лучше всего показывает разницу между управлением проектами, продуктами и программами.

Delivery Manager - роль более "нишевое" явление, сильно зависящее от конкретной компании и её процессов. В разных организациях она трактуется по-разному: от старшего PM-а до операционного менеджера в Agile-команде. Поэтому в коротком сравнении Delivery Manager легко внести больше путаницы, чем пользы.

Чем отличается: Delivery Manager = фокус на выполнении обязательств команды и стабильности поставки.

  • Project Manager отвечает за проект: сроки, бюджет, риски.

  • Product Manager отвечает за ценность и развитие продукта.

  • Program Manager отвечает за синхронизацию множества проектов и продуктов.

  • Delivery Manager отвечает за то, чтобы команда реально и предсказуемо доставляла результат, а процессы разработки и поставки не ломались.

Задачи Delivery Manager-а

  • Следить за здоровьем процессов в команде (Agile церемонии, velocity, SLA).

  • Снимать операционные блокеры, чтобы команда могла работать.

  • Координировать взаимодействие с другими командами (DevOps, QA, Support).

  • Мониторить метрики поставки.

Когда Product Manager уходит в стратегию и общение с рынком, а Project Manager в бюджет и отчётность, команде часто нужен человек, который держит фокус на ежедневной предсказуемости поставки. В крупных организациях Delivery Manager становится опорой для нескольких команд разработки, снимая с PdM и PM часть операционных забот.

Метрики эффективности Delivery Manager:

  • Velocity & Throughput - стабильность скорости команды.

  • Lead Time & Cycle Time - скорость прохождения задач.

  • Defect Rate - качество поставки.

  • Team Satisfaction - насколько комфортно команде работать в текущем процессе.

Delivery Manager - это не конкурент Project/Product/Program Manager, а их дополнение.

  • PM, PdM и PgM отвечают за "что и зачем" (стратегия, ценность, цели).

  • Delivery Manager отвечает за "как именно" на уровне повседневной работы команды.

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

А у вас в компаниях, есть ли отдельные Delivery Manager-ы или их функции выполняют PM/PdM?

Теги:
Всего голосов 4: ↑3 и ↓1+5
Комментарии0

Ну что вы скажете? С 12 минут до 3 секунд(!) сократил время поиска инструкций полнотекстовый поиск в KMS Gran.

Один из наших клиентов - IT-компания - хранила документацию в Google Docs и Telegram, что вызывало путаницу. В 2024 году внедрили базу знаний KMS Gran, создав разделы "Проекты", "API-документация" и "Ошибки и уроки".

Результат спустя год:

  • время поиска инструкций сократилось до 3 секунд

  • скрипты автоматизировали уведомления о новых версиях API, уменьшив время согласования релизов на 30%.

  • за 6 месяцев количество багов в коде снизилось на 25%, так как разработчики быстро находили решения по прошлым ошибкам.

Статистика показала, что раздел "Ошибки и уроки" просматривали 80% команды, что привело к добавлению видео-разборов типичных ошибок.

А какие процессы хотелось бы улучшить в вашей команде?

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Интеграция PVS-Studio c SGRC SECURITM

Компания PVS-Studio и платформа Securitm заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

Облачный сервис и программное обеспечение SGRC Securitm позволяют построить управление информационной безопасностью на базе риск-ориентированного подхода и единой информационной модели компании.

Отчёт анализатора PVS-Studio стало возможным загрузить в Securitm для дальнейшего использования с помощью пользовательского интерфейса системы.

Подробнее о том, как загрузить отчёт анализатора PVS-Studio в систему Securitm можно прочитать в посвящённом этому разделе нашей документации.

Также мы с коллегами из Securitm провели совместный вебинар, на котором обсудили, как обеспечить соблюдение требований ГОСТ в области РБПО, а также показали реальные примеры использования PVS-Studio и Securitm.

Теги:
Рейтинг0
Комментарии0

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