Humanized IT часто пытаются построить через процессы и практики.
Но оно ломается на первом же "как дела?",
которое на самом деле означает "сейчас будет срочная задача".
Люди быстро считывают не слова, а намерение.
И если в коммуникации нет честности, никакие фреймворки это не компенсируют.
RCA (Root Cause Analysis) у нас есть.
Документ есть.
Митинг был.
Причину нашли.
Инцидент повторился.
В какой момент RCA перестаёт быть инструментом
и превращается в управленческое самоуспокоение?
Читаем: RCA (Root Cause Analysis) как показатель зрелости менеджмента
Год надо заканчивать правильно...
Индексация - не рост!
Сидеть на одном месте без развития - не карьера!
Если вы не растете, то вы падаете!
Более подходящего момента чем сейчас у вас не будет!
Почему хорошие технические решения иногда ломают бизнес?
За годы работы заметил частую закономерность: решение может быть абсолютно правильным с точки зрения архитектуры и при этом плохо работать в реальности компании/бизнеса.
Причина почти всегда одна: его принимали без учёта операционных ограничений (людей, сроков, процессов).
С тех пор, стараюсь смотреть на технические решения не только глазами инженера или CTO, но и через призму того, как с ними будет жить бизнес каждый день (COO).
Это наблюдение и стало решающим для меня при определении направления развития карьеры в сторону управления процессами. Зачастую, правильно (как требуется) поставленные процессы добиваются большего бизнес-эффекта, чем самое технически совершенное решение.
А как вы находите баланс между операционкой и техническим совершенством продукта?
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?
😎 Как специалист по защите информации, по образованию, капитаню хочу отметить:
Любую систему можно взломать!
😁 И вот на просторах интернета попался еще один красивый пример обхода ограничений "хайпового" GPT:
А если серьёзно - я собрал всё, что нужно знать о работе с ChatGPT и другими языковыми моделями:
фреймворки для запросов (GRWC, ERA, APEX и др.)
лучшие практики и техники
сравнение моделей (GPT-4, Claude, Gemini и др.)
форматы вывода и входные данные
полезные инструменты (Taplio, Cursor, Decktopus...)
где использовать ИИ в бизнесе
📌 Это не просто список, а универсальный навигатор по генеративному ИИ.
Для тех, кто хочет не просто «поговорить» с ИИ, а заставить его работать на результат.
Причины выгорания. Опрос.
Не так давно, я опубликовал статью-мнение с обзором причин выгорания и мер которые превентивно не дадут команде проволиться туда.
Статья была встречена довольно холодно, что заставило меня доработать её.
Таким образом, уважаемые хабровчане, прошу поделиться своим опытом и мнением в поисках коллективной истины.
Что по вашему мнению является причиной выгорания?
Атмосфера в коллективе
Не компетентный менеджмент
Work-Life balance
Методология и/или процессы
Легаси решение и/или инструменты
Отсутствие возможности профессионального роста
Оклад
Другое
Допускается выбор нескольких вариантов. Расскажите о них в порядке важности для вас.
Большое спасибо!