Эффективные менеджеры. Часть 1. У меня нет времени, мне надо ДЕДЛАЙНЫ

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

Есть сквозные проблемы, которые неизменно встречаются во всех организациях в разном масштабе, и в целом универсальны. Разберем эту тему в нескольких статьях, начав с темы баланса сроков и планирования.

Эффективные менеджеры. Часть 1. У меня нет времени, мне надо ДЕДЛАЙНЫ

Поработав уже у трех разных работодателей в ролях от младшего специалиста до нач. отдела и Product Owner, и поперемещавшись между еще большим количеством отделов (закупки, опер эффективность, продуктовая разработка и др.), я выявил несколько универсальных проблем менеджмента, которые стабильно укладываются в один из следующих блоков, а иногда одновременно сразу в несколько из них:

  1. Квалификация управленцев — недостаток опытных лидеров, отсутствие развития и передачи экспертизы.
  2. Дефицит делегирования — руководитель делает всё сам, нет доверия команде.
  3. Плохая коммуникация — барьеры между отделами и уровнями, искажение информации; непроработанная система целей и поощрений, текучка кадров.
  4. Стратегическая близорукость — ориентация только на дедлайны, отказ от долгосрочного планирования.

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

Кратко проблему можно сформулировать так: «У меня нет времени, мне надо ДЕДЛАЙНЫ». Сталкивались? Чаще всего этим “болеют” руководители проектов ввиду специфики роли, но проблема не обходит стороной и линейный менеджмент.

Приведу несколько примеров из личной практики и наблюдений.

Пример 1. Крупный корпоративный заказчик и ИТ-команда, которая очень хочет заработать.

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

Что происходит дальше? Дальше начинается работа. Идем анализировать ТЗ. Раз — пробел. Пошли уточнять требования. Два — пробел. Пошли уточнять требования. Три — пробел... Погодите. Проект начал расти, объем работы явно не такой, как представлялось. А сроки и суммы уже подписаны. И пошли один за другим дедлайны (вехи проекта). Первый дедлайн — извините, не успели, сейчас догоним. Второй — ой, снова не уложились, но мы оптимизируемся, обещаем. Руководитель проекта уже бушует — требует результаты, “нужно было вчера”. Третий дедлайн... а можно перенести срок по этапу? Спасибо. Меняются руководители, вслед за этим меняются некоторые подходы к работе, но в целом все продолжается по той же схеме. Где мы оказались в итоге? Сдали MVP-функционал на два года позже указанного в первоначальном контракте. Смету проекта не видел, но судя по сокращениям команд, думаю, ушли в убыток. Не получилось как сыр в масле. Но зато мерча красивого наделали и на конференциях выступили, рассказывая про строящийся прекрасный продукт.

Пример 2. Давайте что-нибудь улучшим.

Другая ИТ-команда. Внутренний заказчик. Очень много идей, как сделать жизнь лучше, и не очень много ресурсов. Нет времени планировать, потому что “чем быстрее, тем лучше”. Есть идея? Погнали! Один сервис сделали, потребность закрыли, отчитались — молодцы! Второй сервис сделали, потребность закрыли, отчитались — молодцы! Три, четыре, пять, десять… Про первые два сервиса уже забыли. Новый проект, новая архитектура, новые результаты — уже 5-6 разных классов систем сделали, ух! И вроде заказчики довольны, но кто это там постанывает тихо в углу? А, это наш Legacy! Когда-нибудь отрефакторим. Спустя N лет — уже сложно разобраться кто чем пользуется и периодически прилетают внеплановые запросы по багам в сервисах, которыми команда уже не занимается. В нагрузку - отсутствие общей архитектуры, и непонятно, что развивать дальше. Может, пойти в AI? Есть идеи?

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

Что можно было сделать по-другому для Команды 1, которая делала продукт для крупного корпоративного заказчика, но сильно вышла за сроки и бюджет проекта?

Шаг 1. Осознать, что планирование — это важно и это отдельный этап работ.

Шаг 2. Убедить в этом заказчика и указать на то, что без уточнения ТЗ и четкого планирования ресурсов хороший продукт не получится: получат самокат вместо мерседеса. Заложить этап проектирования, после которого будут зафиксированы сроки, объем и стоимость. Далее — формировать дорожную карту.

Шаг 3. Так как мир постоянно меняется, в том числе, меняется представление заказчика о том, что такое хороший продукт, заложить в контракт регулярную процедуру пересмотра и внесения изменений в план (с окном входа в цикл корректировок — ежеквартально, или для длинных проектов со сложным бюджетированием хотя бы ежегодно).

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

Что можно было бы сделать для Команды 2, чтобы не накопился Legacy, команда четко понимала текущую ценность и востребованность продуктов и тратила время только на действительно важные задачи?

Шаг 1. Определить пул стейкхолдеров и объяснить им важность этапа планирования.

Шаг 2. Собрать их боли и потребности. Совместно со стейкхолдерами провести приоритезацию.

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

Шаг 4. Вместе со стейкхолдерами определить ключевой фокус на год и еще хотя бы на два года вперед и заложить это в стратегию: цели, метрики, in scope, out of scope, ключевая функциональность, дорожная карта (тему “как подготовить хорошую стратегию” можно разобрать отдельно).

Шаг 5. Спроектировать автоматизируемые бизнес-процессы и архитектуру с учетом стратегии и двигаться в светлое будущее — без Legacy и с четким пониманием направления движения.

Какой итог?

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

Я лично уже набил достаточно шишек и больше не хочу. Официально объявляю себя амбассадором и евангелистом стратегического и тактического планирования и буду яростно бороться с “У меня нет времени, мне надо ДЕДЛАЙНЫ” во всех его проявлениях. Призываю к тому же и всех вас!

В комментариях поделитесь: были ли у вас похожие проблемы, связанные с планированием, и как команда выходила или планирует выходить из ситуации? Интересен ваш опыт.

18
2
3 комментария