Project-менеджер | IT

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

Как мы вышли на международный рынок и зашли обратно #почитать Сколько мы разрабатываем фичи, каждый раз убеждаемся, что их возможная вариативность очень чётко определяется запросами наших пользователей. Сделать можно любую фантазию, но дело в том, что люди пользуются только тем, что им нужно. И это приводит к тому, что разные компании с разных уголков мира, делающие продукт в этой нише, делают примерно одно и то же. Разумеется, бывают оригинальные фичи, нестандартная реализация, но глобально, всё сводится к нескольким основным механикам и качеству их реализации. В одном из эссе Пол Грэм пишет, что рынки отличаются возможностью к консолидации. И, как правило, силы, защищающие вас от конкурентов, начинают работать против вас, когда вы хотите консолидировать рынок. Как пример — рынки ресторанов, шиномонтажа, производства одежды (о чём обычно пишет С. Рюмин на Хабр) больше рынков операционных систем или поиска, но делятся на миллионы игроков. Работать на таком рынке просто, но масштабироваться сложно. Вы знаете сеть из 100 шиномонтажек/стоматологий? Я — нет. Видимо, факторы локаций, навыков исполнителя и подобные, хорошо защищают мелких игроков от консолидации. В то время как если вы разрабатываете операционную систему, вы получите либо всё, либо ничего. И рынки IT-продуктов чаше всего очень консолидированы, на них находится место максимум нескольким игрокам в нише. ⏱Читать статью

Инструменты клиентской поддержки: опыт e-commerce брендов #почитать Высококонкурентный рынок в e-commerce не прощает ͏ошибок. 89% клиентов готовы поменять сервис после одного негативного опыта в сервисе. При этом, привлечение нового͏ стоит бизнесу до 25 раз дороже, чем удержание текущего. Поэто͏му важность ка͏чества ͏сервиса становится н͏е вспомогательной, а важнейшей функцией, ͏которая вл͏ияет на ͏удержан͏ие, прибыль и͏ репутацию бренда. ⏱Читать статью

Как превратить звонки техподдержки в самообновляемую базу знаний на Python и LLM #почитать База знаний в поддержке почти всегда отстаёт от реальности: знания появляются в звонках, остаются в умах операторов, а в документацию попадают выборочно и с задержкой. При этом сами звонки уже записываются и транскрибируются. В этой статье разберём инженерный способ автоматически извлекать из этого потока проблемы и решения и вести актуальную базу знаний с помощью Python, МТС Exolve и LLM. ⏱Читать статью

Приглашаем на Пиэмную — бесплатный митап ЮMoney для руководителей IT-проектов ✅ Спикеры из ЮMoney и основатель «Школы развития Доверия» расскажут, как управляют проектами и командами, а после докладов ответят на вопросы зрителей. О чём поговорим на митапе: 🟣 Ловушки коммуникации: как выходить победителем из игры без правил. 🟣 Управление доверием в команде: лидерская компетенция, которой не учат в MBA. 🟣 ИИ для менеджера проектов: с чего начать. 🟣 3 х 30: история адаптации в роли менеджера проектов ЮMoney. 📍21 мая, четверг, 19:00 (мск) приходите на митап в Санкт-Петербурге или подключайтесь онлайн. Чтобы попасть на митап, нужна регистрация. Все подробности — на сайте Пиэмной 🔥

Почему стандарт должен быть выше проекта #почитать На любом заводе рано или поздно наступает один и тот же момент. Линия работает, проекты давно сданы, подрядчики ушли, а вместе с ними — люди, которые «знали, как тут всё устроено». На смену приходят новые инженеры, и внезапно выясняется простая вещь: чтобы начать уверенно поддерживать АСУ ТП, им нужны не недели и не месяцы, а годы. Если на предприятии есть нормальный стандарт и живая, привязанная к нему документация — новый инженер выходит на самостоятельную работу через пару месяцев. Если стандарта нет — может пройти год и больше, прежде чем человек сможет в одиночку обслуживать завод без постоянного риска что-то сломать. Разница между этими сценариями не в уровне специалистов, а в том, есть ли на предприятии система или только набор проектов. ⏱Читать статью

🟢Подборка полезностей для прожектов и продактов 💻 16 мая 🔥Нашумевшее ▫️Вообще, кажется, сейчас начинается золотое время в IT ▫️Я понял, что Ozon не победить — и сделал 17 млн на том, что он не привезёт ▫️Морковка «пассивного дохода» отравила целое поколение предпринимателей ▫️РКН объявил войну зарубежным разработчикам игр. Почему это бьёт по всей IT-отрасли ▫️Как знакомый знакомого сделал 1,5 млн рублей на фейковых клиентах банка ▫️Промпт-инжиниринг для не-промпт-инженеров ▫️Как сайты собирают цифровой отпечаток пользователя — почему VPN больше не спасает (о Fingerprinting) ▫️Иерархия платежей по кредитам и займам в России 💎Продукты ▪️Продакт-билдер — это не будущее. Это деградация роли ▪️Эван Шпигель, СEO Snapchat: дистрибуция важнее продукта ▪️Как не тратить ресурсы впустую: четыре шага перед разработкой любой фичи ▪️Мета-работа, память агентов и Product Graph: почему AI не спасёт продукт без структуры знаний ▪️Почему вредно сразу начинать рисовать макеты ▪️Eat your own dog food: почему продукт, которым не пользуются создатели, обречён 🗓 Проекты ▫️Те, кто не любит отлаживать — против тех, кто не любит писать ▫️Высоконагруженные люди: как управлять давлением и не сломать команду ▫️Как мы построили интегрированное планирование для фармхолдинга, растущего в 6 раз быстрее рынка ▫️Я грузил уран в бочки, а потом 20 лет строил ИТ в атомной отрасли ⚖️Аналитика ▪️ИИ съест экономику изнутри. А потом запустит ядерный апокалипсис ▪️Слои и модели данных: какие бывают, как и кто с ними работает ▪️Аналитика новых и текущих сайтов: как не положить прод одной доработкой ▪️Снимаем с ИИ марковское одеяло ▪️В мире уменьшающихся кубиков: когда заводу нужны математики ▪️Почему пользователи врут на интервью и что мы увидели, когда начали за ними наблюдать ▪️Отказоустойчивый запуск WSGI приложения. Обзор архитектуры Gunicorn ▪️Тайна общей тарелки или System Design дачного шашлыка на 20 гостей ✍️ Документация ▫️Персональная система планирования и база знаний в Obsidian для технического директора ▫️MoneyDev: как заработать на макулатуре ▫️Почему без архитектора контента невозможно масштабировать документацию компании ▫️Пользователь, they и Шекспир: история одного скандала ▫️Как мы сделали автогенерацию документации для CI/CD из комментариев в коде ▫️Разбор реализации docs-as-code на базе Sphinx ▫️Тайны чёрных мониторов и бегущих строк. От ASCII-графики к современным языкам разметки 🔑Рассказы ▪️Мне всю жизнь говорили, что я умный. А потом в 34 попробовал своё дело ▪️Сделал MVP за 3 дня, а потом неделю прикручивал оплату. Оно того стоило? ▪️Кейс Сitadel: как не задохнуться от бюрократии, когда у тебя тысячи сотрудников ▪️Итерация 4 закрыта: 20 часов на методику, которую агент не написал бы ▪️Как мы автоматизировали маркетинг, продажи и контроль стеком ИИ-агентов ▪️Как Ashton-Tate сумела превратить dBASE в инфраструктурный стандарт, но напугала разрабов и клиентов ▪️Базовый минимум или роскошный максимум: версия Smart TV ▪️Дерево решений vs граф работ: я объединила Data Science и JTBD в проекте 💡 Карьера ▫️Как не сойти с ума в 2026 году ▫️Войти в IT после 35: как декрет, волонтёрство и честный разговор с собой полностью изменили мою жизнь ▫️Манипуляции в жизни ИТ менеджера ▫️People management. Изменения, которые будут стоить 0 рублей ▫️14 уроков за 14 лет опыта работы в Google ⚔️ Спорное ▪️Пора начинать использовать интернет как в конце 90-х ▪️Почему умные люди прокрастинируют ▪️Дедлайн оплаты в 21:00 — это не dark pattern ▪️Кому нужно «кресло» за 250 тысяч рублей: история и результаты одного эксперимента 📺Посмотреть 🌐ProductCamp 2026: как поехать и найти работу ⏱️1 час 20 минут 🌐Стать фаундером или карьера? ⏱️1 час  🌐CPO Купера: от продакта до CPO ⏱️1 час 🌐Workshop Getting the Most out of AI with Minimum Effort ⏱️1 час 30 минут 🥂 Отдохнуть ▫️Как совместить работу и путешествие на 1000+ км (заметки собаки) ▫️Что там с Ту-214 ▫️В НАСА опубликовали в открытом доступе 12217 фотографий, которые сделали члены экипажа миссии 🚀 Вакансии Пи-Эмов и аналитиков  Не тащи поезд

Немного про управление объемом проекта #почитать Определение объема проекта часто воспринимается как сложная и абстрактная задача. На практике это процесс установления четких границ проекта. Он определяет, какие работы входят в проект, а какие находятся за его пределами, что должно быть выполнено, а что делать не планируется. В контексте управления проектами понимание этих границ позволяет согласовать ожидания, избежать недоразумений и обеспечить единое представление о проекте у всех его участников. Объем проекта является основой всей проектной структуры. Именно он задает рамки для планирования сроков, бюджета, ресурсов и общего направления работ. Без четко определенного объема сложно управлять проектом последовательно и предсказуемо. Более того, отсутствие ясного понимания объема считается одной из самых распространенных причин неудач в проектах. ⏱Читать статью

Пять постулатов Исполнителя #почитать Старый постулат, испытанный миллионами боёв и веками истории. Человек со своим опытом, проблемами, настроением и обстоятельствами по крупицам строит результат проекта. А проект — это всегда стресс, неопределённость и путь в неведомое. Ожидания сбудутся в зависимости от того, как решатся его проблемы, и от комфорта работы будет зависеть продуктивность людей. Второе ключевое слово в заголовке — «своих». Кто такие «свои»? Конечно же, команда. Сплочённая, когда один за всех и все за одного. Состоящая из мастеров своего дела. Так? ⏱Читать статью

Системная диагностика команды: найдите точки роста до старта курса Хотите точно понимать, что мешает команде работать на максимум? Разберём системную диагностику — оценим людей, процессы и окружение, выявим проблемы и наметим точки роста. Открытый урок «Системная диагностика команды и группы команд» пройдёт 20 мая в 20:00 — в преддверии старта курса «Менеджер поставки ИТ‑решений / Delivery Manager». На вебинаре разберём модели оценки команды: • личностную (психотипы и мотивация); • групповую (Такман, Ленсиони); • ролевую (Белбин и др.); • корпоративную. Для деливери‑менеджеров, руководителей тимлидов и практикующих тимлидов. Запишитесь сейчас — получите скидку на курс и напоминание в день вебинара. 👉: Ссылка Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Как управлять бэклогом через JIRA Structure #почитать

Периодически слышу, как мне говорят: «В Jira неудобно управлять бэклогом, стандартный список задач мне не нравится». Дело доходит даже до выписывания задач в Excel. Тогда зачем нам таск‑трекер?) Сегодня попробую рассказать о решении, которым сам пользуюсь, а именно применение Structure.

⏱Читать статью

Фокус-фактор: почему у разработчика никогда нет 40 часов на задачи #почитать

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

⏱Читать статью

Нелояльная лояльность #почитать

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

⏱Читать статью

🌟 Команда загружена на 100%, а сроки всё равно срываются? В проектах с дефицитом ресурсов это типичная ситуация: задачи накапливаются, появляются срочные запросы, а реальная причина задержек остаётся незаметной. В итоге команда перегружена, а результат не растёт. На открытом уроке разберём: ✔ как управлять ресурсами в условиях ограничений: ✔ как находить узкие места в процессе, ✔ почему полная загрузка снижает эффективность ✔ как реагировать на срочные задачи без разрушения плана. 🗓 Урок проходит в преддверии старта курса «Руководитель ИТ-проектов». Если вы хотите управлять сроками и нагрузкой осознанно, а не в режиме постоянных переработок — подключайтесь 12 мая в 19:00 МСК. ➡ Регистрация открыта: ссылка Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Как я поставил цели на год и не сошел с ума #почитать

За неделю я разделил свою жизнь на сферы, выстроил систему и процессы, чтобы еще один год не прошел впустую. Думаю, что получилось очень неплохо, опытом результатом делюсь в этом материале. Привет! Меня зовут Рафаэль, на момент написания статьи мне 20 лет. Сейчас я очно учусь на 3-ем курсе филфака и совмещаю это дело с фулл-тайм работой UI/UX дизайнером в крупном агентстве. Именно поэтому в начале 2026-го года для меня остро встал вопрос построения целей на год. Дел много, времени мало, а преуспеть в каждой сфере очень хочется, амбиции же прут. Поэтому было решено внести в хаотичный поток жизни немного структуры, да и навык построения правильных целей еще прослужит мне долгое время, думал я. В этой статье подробно расскажу о методиках и подходах, которые я выделил для себя, а также поделюсь классными инструментами, которые помогли мне в планировании и постановки целей. Да, в интернете уже куча статей о том, как правильно ставить цели, достигать их и жить в шоколаде. И все они по своему прекрасны. Но в основном эти статьи прикладные, и из каждой мне пришлось черпать понемногу, чтобы в итоге это собралось в единое целое.

⏱Читать статью

Что будет если тимбилдинги будут организовывать разработчики #почитать Перед началом статьи стоит дать пару вводных. Разговор будем вести о компании под названием «Рога и копыта», в которой я работаю 3 года, и это моя первая работа по специальности. В нашей компании работает ни много ни мало 80 человек и у нас нет HR-ов, думающих как же улучшить наши показатели Активностями и различными мероприятиями здесь не занимаются (за исключением праздников и корпоративов) В компании отсутствуют строгие правила и атмосфера в ней из-за этого очень комфортная В благоприятной и достаточно дружелюбной атмосфере не хочется сидеть замкнутым, хочется общаться с коллегами. Однако все зависит от команды, у нас не исключение встретить одинокого воина, солирующего на каком нибудь проекте, поэтому можно сказать он упускает некую возможность социализации. На личном примере заметил, что приходя на первую работу по специальности в жизни испытываешь нереальный стресс, особенно когда это IT с огромной конкуренцией еще и знать нужно все и еще немного (по крайней мере так казалось). ⏱Читать статью

Как мы вывезли ИТ-трансформацию, за которую никто не хотел браться, и спасли бизнес от многомиллионных потерь #почитать Несколько лет назад к нам обратился клиент (крупнейшая логистическая компания в России) с проблемой – европейский головной офис отзывает все лицензии действующих ПО, и у клиента есть только год, чтобы импортозаместить 8 ключевых ИТ-систем и несколько дополнительных. При этом проектного офиса в компании нет – ранее все ИТ-проекты делались силами головного офиса. А на то, чтобы создать проектный офис с нуля, времени уже нет. При этом, если не успеть до момента, когда все лицензии прекратят действовать… это приведет к остановке работы в 14 распределительных центрах России компании и ущербу в десятки миллионов рублей. Большинство подрядчиков, к которым клиент обратился до нас, отказались ввязываться в эту историю – потому что даже для внедрения одной ERP-системы требовалось месяцев 16. А тут, кроме ERP, еще 7, и времени всего год. Так как у нас большой опыт в вытаскивании масштабных программ из кризиса, мы согласились. И сразу приступили к работе – в качестве проектного офиса на аутсорсе. Что конкретно мы сделали и как нам удалось помочь компании предотвратить многомиллионные потери, рассказываю в этом кейсе. ⏱Читать статью

Как развивать платформенные продукты. Саппорт vs критическая инфраструктура #почитать Развивать платформенные продукты не просто. С бизнес-продуктами всё более менее понятно: развивать надо то, что приносит деньги. Тут главный вопрос, как узнать, что именно приносит деньги. Это тоже очень не просто, и на эту тему написано десятки статей и даже учебников. В этой же статье хочу поговорить о том, какие сложности стоят именно перед платформенными продуктами. Если хотите узнать подробности — эта статья для вас. Я развиваю платформенный продукт Ролевая модель в Альфа-банке последние 2 года и горжусь им. Мы действительно задаём тренды, находимся в топах практически любого рейтинга, нас копируют. И это здорово. Но сегодня не о рейтингах, а о развитии внутри прекрасного Enterprise. ⏱Читать статью

Роскошный архитектурный минимум для аналитика: понимать систему в целом и не бояться «богов»-архитекторов #почитать Недавно мне раскрыли тайну: архитектор — это не тот, кто знает всё, а тот, кому доверяют построить систему для решения бизнес-задачи. И я поняла, что в начале пути меня привлекали их спокойствие и уверенность. А всё остальное — опыт, знание технологий — это hard skills, которые можно наработать для решения этой задачи. В статье хочу осветить границу между анализом и архитектурой и показать, каким минимальным набором знаний в этой области должен обладать аналитик, чтобы не просто передавать требования, а активно влиять на качество конечного продукта. ⏱Читать статью

Проектная страшилка: почему проекты умирают #почитать Часто вижу холивары на тему того, как не сорвать проект, сделать все в срок, в бюджет и именно то, что хотел заказчик. Волшебной таблетки тут не существует, все зависит от среды, ситуации и навыков руководителя проекта. Но, по моему опыту, есть не совсем очевидные, но сильно влияющие на достижение успеха вещи, которыми могут пренебрегать. И их несоблюдение ведет к «смерти» проекта и к печальным последствиям как для руководителя проекта, так и для результата в целом. И тут совершенно неважно, какую методологию управления проектом вы используете. ⏱Читать статью