Собрал обзор 10 планировщиков задач — для командной работы и для личной продуктивности. Кратко объясняю, как устроено планирование в каждом сервисе, какие фичи действительно полезны и кому что подойдёт.
Привет! Меня зовут Мария Аркуша, я продакт-менеджер в Точка Банк. Сегодня хочу рассказать, как нам удалось ускорить и упростить процесс разработки и выкатывания новых фич в продукте.
Есть такое мнение, что ретроспективы — пустая трата времени и бесполезное передвигание карточек. Сегодня я попробую доказать вам, что это мнение в корне неверно и из ретроспектив можно (и нужно!) извлекать огромную пользу. Припас для вас несколько не попавших под NDA кейсов и приемов, которые мы сами применяем в командах разработки. Поехали!
Привет, Хабр. Я старший android-разработчик и скрам-мастер. За годы работы я видел десятки команд, которые относились к ретро как к обязаловке, и столько же тех, которые превратили их в мощный инструмент развития. Разница между ними была не в размере команды или сложности проектов, а в понимании одного простого принципа.
Известно, что каждая компания проходит определенные этапы в своей деятельности с момента ее возникновения до момента ее ликвидации. И, конечно, каждый владелец не желает, чтобы детище его рук и приложенных усилий, зачастую очень больших, прекратило свое существование и старается отодвинуть этот момент как можно дальше (см. Рис. 1).
Привет! Меня зовут Гильметдинов Ильнур, ведущий эксперт Дирекции роботизации банка Уралсиб.
Сегодня хочу рассказать о вызове, с которым мы столкнулись в самом начале пути масштабирования RPA (Robotic Process Automation) внутри банка: как научить коллег, не имеющих опыта в программировании, не просто пользоваться роботами — а создавать их самостоятельно?
Это звучит амбициозно — и даже немного наивно. Но именно с этого начался наш путь к созданию внутреннего курса по RPA на платформе PIX.
Проектный офис ответственен за множество инициатив, но команды сталкиваются с неясными требованиями, путаницей и постоянными изменениями. Знакомо? Для многих организаций это настоящая головная боль, которая мешает эффективно работать.
Ручная обработка заявок на обслуживание — это вечные звонки, потерянные письма и бесконечные уточнения. Особенно в крупных компаниях, где сотрудникам ежедневно нужна помощь ИТ-поддержки и хозяйственной службы. Поэтому сегодня в блоге ЛАНИТ на Хабр поделимся, как мы разрабатывали систему, которая облегчила работу канцелярии, с какими вызовами столкнулись и каких результатов удалось достичь.
Новый технологический тренд — всегда вызов для бизнеса. Но что с ним делать — немедленно вкладываться и внедрять или подождать и присмотреться?
В России об ИИ-агентах уже много говорят, но мало кто заявляет о включении в стратегические планы развития, продукты и процессы. Решили разобраться, что происходит с агентным ИИ в мире и как он может помочь увеличить прибыль и лидировать на рынке.
На связи команда Research & Insights Центра стратегии цифровых продуктов МТС. Мы подготовили исследование мирового и российского рынка ИИ-агентов и в этом материале публикуем основные его тезисы и инсайты.
Всем привет! Меня зовут Алексей Цыбульник, я помогаю внедрять Kanban в командах ПСБ. В банке я работаю с 2019 года, а вообще в IT больше 15 лет. Почти все это время всеми силами я продвигаю Kanban — учу методологии, веду подкаст, делаю конференцию о нем. Если вы интересуетесь этим миром, то можете меня знать :-)
В этой статье расскажу про системный подход, с которым будет проще самостоятельно внедрять Kanban в команде. Имя ему STATIK — System Thinking Approach To Introducing Kanban. Разберемся, чем он полезен и как ложится на принципы канбана.
Идея получить степень Магистра в Испании сопровождала меня много лет. Это было та самая цель, которую переносишь из года в год. Хотя и понимаешь, что это критически важно для профессионального развития, расширения компетенций и построения международной карьеры.
Почему-то всегда получалось, что это было не срочно, не обязательно и кроме того трудоемко. Плюс слабый уровень испанского языка лишь усиливал прокрастинацию.
Тем не менее в 2025 году я решился пройти весь путь поступления в магистратуру в Испании в испанском университете. От выбора специальности, анализа требований и подачи документов до получения финального решения о зачислении.
В этой статье на личном опыте разбираю процесс максимально подробно: как выбрать специальность, какие существуют форматы обучения, чем отличаются испанские университеты, что требуется для подачи, какие документы придётся собрать, как оценивают иностранные дипломы, и какие нюансы могут замедлить или, наоборот, ускорить поступление.
План задач вроде расписали, поручения распределили по приоритетам — а через неделю дедлайны уже плывут, команда выгорела, а половина задач ушла на следующую неделю. Кажется, что все под контролем, но то задачи недооценили, то коммуникации встали, то внезапно сменились приоритеты.
Почему так происходит, что такое спринты и как они помогают команде двигаться быстрее, а не сгорать по пути? Разбираемся вместе с редакцией Kaiten.
В любой команде есть момент, когда количество сотрудников переваливает за 20 — и внезапно оказывается, что никто толком не понимает, где хранится информация и к кому идти за ответом. А клочки информации поделены между разными сотрудниками.
Приходящие новички теряются, старожилы устают повторять одно и то же, а у HR растёт очередь из запросов: «а где у нас инструкция по...».
Все это следствие отсутствия информационной культуры — когда знания не фиксируются, а существуют в головах. И именно эту проблему закрывают Wiki-системы.
Работа над онбордингом помогла нашей команде вырастить активацию в 2,5 раза.
Процесс работы занял больше полугода, а некоторые действия были совершенно бессмысленными. Делюсь своими выводами по итогам работы, чтобы сэкономить время другим командам, занимающимся этой областью продукта.
Рассказываю, когда онбординг делать не нужно, как подойти к этому процессу, какие инструменты использоавть.
Какие практики бывают в разработке и эксплуатации, и как их внедрять? И как масштабировать практики и оценивать их с помощью метрик? Какие сложности можно встретить на пути?
Привет, Хабр! Меня зовут Евгений Харченко. Моя роль в Райффайзен Банке — руководитель отдела по развитию практик в разработке и эксплуатации. А еще уже пять лет я — Senior Community Lead DevOps, хотя начинал с роли инженера тех. поддержки ServiceDesk. Еще я — член программного комитета DevOpsConf.
В этой статье по мотивам моего доклада для конференции Highload++ будет много примеров, историй и ретроспективы того, как мы в компании развивали технические практики и инженерную культуру.
2026 год на пороге. Искусственный интеллект уже не модное словосочетание, а коллега. Copilot подсказывает код в IDE, а ChatGPT помогает с архитектурой. Но наши подходы к найму техспециалистов всё ещё застряли между допросами и бесконечными этапами, которые отнимают время, но не показывают реальных навыков.
Меня зовут Григорий, я разработчик. За последние несколько лет я прошел десятки собеседований с обеих сторон: и как кандидат, и как интервьюер.
Эта статья — не истина в последней инстанции. Это скорее диалог. Предлагаю порассуждать, каким должно быть техническое собеседование в 2025 году с учётом соврeменных реалий.
Сегодня хочу поднять вопрос о двух весьма важных и в то же время сложных аспектах менеджмента - принятие собственных ошибок и увольнение членов команд. Казалось бы, большинство из нас уже прошли через эти испытания, получили свою порцию ошибок, навыки и опыт, но тема продолжает оставаться актуальной.
Заметил одну странность: несмотря на глубокое распространение ретроспектив, как инструментов анализа, и анализа ошибок в профессиональной деятельности, признание ошибок в принятии решения об увольнении сотрудника практически отсутствует. А между тем средняя стоимость замены сотрудника в РФ составляет примерно 6-9 месячных зарплат. Достаточно значимая сумма, чтобы задуматься о принятом решении.
Давайте посмотрим на причины и поразмышляем о том, почему менеджеры редко признают свои ошибки при расставании с сотрудниками, и почему стоит переосмыслить этот подход для улучшения работы команды и компании в целом.
Привет! Как и обещал, вторая часть доклада про то, как проводить быстрый аудит разработки без изучения кода (первая тут). Так как весь аудит по своей сути — это качественно поговорить и позадавать нужные вопросы, чтобы потом сделать выводы, то поговорить стоит и про более низкоуровневые вещи, такие как трекер задач, количество багов, метрики, используемые командой, и процесс разработки. В привычном по предыдущей статье формату «Хорошо / Плохо».
Метрики
Количество клиентских багов
Помните фильмы, где главный герой лежит в больнице, подключенный к кардиомонитору, и там на экранчике бежит график сердцебиений? Когда график вытягивается в прямую линию, значит, всё грустно и главный герой умер.
Так вот, с клиентскими багами такая же история. Это пульс продукта. Если в метриках их ноль — то это самое страшное. Это значит, что продукт или вообще не используется, или что клиенты никогда не запускали его.
Нет, конечно, есть исключения, когда какой-то продукт присутствует в компании чисто для галочки. Такое может попадаться в сфере информационной безопасности — например, клиент с точки зрения закона обязан купить какое-то ПО, но никто не будет проверять, используется этот софт на самом деле или нет. Скажем, купила компания антивирус, чтобы соответствовать требованиям регулятора, и просто положила его на полку — aka «бумажная безопасность». При таком подходе вообще без разницы, что там делает разработка — можно ее хоть уволить всю. Захочется ли вам работать в такой компании — это уже отдельный вопрос.
Итак, отсутствие багов — это плохо. Хорошо — это когда они есть, причем динамика изменений может быть любой, главное, чтобы это имело под собой какое-то логическое объяснение.
ЮMoney и ЮKassa регулярно проводят исследования. В ноябре мы выясняли, как компании справляются с технической нагрузкой, особенно во время распродаж. Делимся данными:
Методы Монте-Карло и швейцарского сыра, статистика в оценке сроков, замена Jira, вредные советы планирования, управление техдолгом, типология руководителей, борьба с микроменджментом, правильный онбординг и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Oracle снова в центре внимания. Компания, долгое время считавшаяся инфраструктурным элементом корпоративных ИТ-систем, внезапно оказалась в центре внимания ИИ.
Это история Oracle Ларри Эллисона, её многолетней трансформации и создания облака, идеально подходящего для эпохи искусственного интеллекта.