Управление проектами *

Основная часть работы современных разработчиков ПО¹ связана с API: публичными интерфейсами для общения с программой, например, API Twilio. Я потратил кучу времени на работу с API как их разработчик и пользователь. Я писал публичные API для сторонних разработчиков, приватные API для внутреннего использования (или для потребления одной страницей фронтенда), API REST и GraphQL и даже несетевые интерфейсы, например, для инструментов командной строки.

Думаю, большинство рекомендаций по проектированию API слишком уж уходит в тонкости. Разработчики отвлекаются на обсуждения того, что же такое «реальный» REST, правильно ли использовать HATEOAS и так далее. В этом посте я попытаюсь рассказать всё, что знаю о проектировании хороших API.

Тратите бюджет на контент, но лидов нет? Я через это проходил. Делюсь опытом, как я меряю результаты размещения статей на UGC, чтобы достигать поставленных целей.

Казалось бы, чего может быть сложного: спроектировали, разработали, протестировали программную информационную систему и все, осталось только ее запустить в продуктивный режим эксплуатации, что обычно неоднократно репетируется. Но так ли это просто? Ответ положительный, если внедряется ERP-система на подразделении с небольшим числом конечных пользователей, уровень владения компьютером у сотрудников плюс-минус нормальный, все участники проекта сосредоточены в одной локации и, наконец, число специфичных требований к системе небольшое. Сейчас мы рассмотрели типовой проект внедрения корпоративной системы (далее – КИС).

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

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

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

Жизнь была прекрасна: спокойствие, умиротворенность, гармония, созерцание того, как растут деревья. А потом я узнала про многозадачность. Оказывается, можно делать больше одного дела в день. 

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

Сейчас я веду все дела в календаре. Это крайне эффективный инструмент. Но прежде чем использовать календарь на 146% до него требуется дозреть. В моём случае — пройти путь отбрасывания стандартных инструментов. Вы их знаете. Первый из них — это запись задач в ежедневник.

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

В статье разберемся, что такое таск-трекер, зачем он нужен, как выбрать лучший сервис для планирования задач, а также сделаем обзор 10–15 популярных таск-менеджеров 2025 года с их особенностями, плюсами, минусами и ценами.

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

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

В предыдущей статье я рассказал, как вместе с командой превратил небольшую группу инженеров в структурированное подразделение Professional Services (PS). В этой хочу рассказать, как мы создали PS 2.0 — объединили внедрение и техподдержку в цельную команду, добавили автоматизации и цифровых помощников, а также организовали процессы так, чтобы команда работала круглосуточно, но без ночных смен.

Многие Project Manager’ы однажды ловят себя на мысли: «А что дальше?» Управлять сроками и таск-листами становится привычно, но хочется больше влияния на сам продукт, а не только на процесс. В этот момент в поле зрения появляется роль продакт-менеджера — с её стратегией, рынком, пользователями и ответственностью за результат. Но путь туда не прямой: часть привычных навыков окажется полезной, а часть придётся прокачивать с нуля. Эта статья — о том, какие вопросы стоит задать себе перед переходом, где совпадают зоны компетенций, а где придётся кардинально менять фокус.

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

Разбираем метрику через обслуживание в пабе в пятничный вечер в сравнении с АйТи-командой (с паттернами и примерами). Тема довольно актуальная, так как сейчас в США и Европе расцвет прогнозирования на основе именно метрик потока и появляется много плагинов с Монте-Карло (но не все из них доступны в РФ).

Он заговорил, и стрелок застыл, поражённый: к нему обращались Высоким Слогом Гилеада! — Сделай милость, стрелок‑сэй. Не пожалей золотой. Один золотой — это ж такая безделица. Высокий Слог. В первый миг разум стрелка отказался его воспринять. Прошло столько лет — Боже правый! — прошли века, тысячелетия; никакого Высокого Слога давно уже нет. Он — последний. Последний стрелок.

Стивен Кинг

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

Осторожно! В статье намеренно используются фрагменты сгенерированного текста!

Когда пристёгиваешь пациента к электронной пушке, способной выстреливать пучком частиц с энергией 25 МэВ, следование процедурам — вопрос жизни и смерти. Оператор, эксплуатировавшая аппарат лучевой терапии в Онкологическом центре Восточного Техаса (East Texas Cancer Center, ETCC), работала с ним достаточно долго для того, чтобы запомнить все процесс.

21 марта 1986 года оператор пригласила пациента в процедурную. Она проверила его назначение и уложила его на стол Therac-25. Над пациентом находилась диафрагма излучателя — поворотный диск, позволявший выбрать тип излучаемого устройством пучка. Сначала оператор переключила поворотный диск в простой режим оптического лазера, чтобы луч ударил в небольшой участок грудины пациента.

Полгода назад я испытал культурный шок. Всю карьеру — я QA Automation Engineer — пилил фичи в аутсорсе: стабильно, предсказуемо, местами даже комфортно. Но на январских каникулах впервые за долгое время задумался: мне скоро 30, я уверенный сеньор — а будто бы стою на месте.

Я просто включил «open to work» на LinkedIn — и неожиданно получил оффер в продукт. Пошёл на собеседование «чисто посмотреть» и остался.

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

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

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

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

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

И почему её путь отличается от судьбы обычного ресторана — не только масштабом, но и последствиями.

Описание системы управления через усложнение задачи и способ выживания в ней. Чаще всего достается от подобных систем проектному офису и всем мотивированным сотрудникам. В статье привожу несколько рабочих практик и свой опыт.

25 августа в Торгово-промышленной палате РФ прошёл круглый стол на тему «Персонализированное здоровье будущего», в рамках которого был подписан Меморандум о сотрудничестве между ОП ЕАЭС и Российским новым университетом. Мероприятие организовано в рамках национального проекта «Продолжительная и активная жизнь», модераторами выступили председатель комитета Общественной палаты стран Евразийского экономического союза по Здравоохранению Карина Георгиевна Назарова и руководитель компании «Титул Тех» Ольга Юрьевна Симашкина.

В ИТ есть три роли, которые часто путают: Project Manager (PM), Product Manager (PdM) и Program Manager (PgM). Звучат они похоже, но задачи и фокус у каждой разные. Встречаясь с каждой из них в своей карьере, каждый раз возникало ощущение "дежавю". Оказалось "Вы не понимаете, это другое!" - разница есть. Понимание этой разницы помогает компаниям эффективнее выстраивать процессы, а специалистам правильно строить карьеру и лучше ориентироваться в сообществе.

В современном IT-мире часто возникает путаница между различными ролями. Одним из примеров является роль Delivery Manager, которая имеет некоторые сходства с Project Manager. Хотя обе позиции связаны с управлением проектами, их обязанности и зоны ответственности существенно различаются. В этой статье мы рассмотрим на примерах, что должен делать каждый из этих специалистов в конкретных ситуациях.

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