{"id":14271,"url":"\/distributions\/14271\/click?bit=1&hash=51917511656265921c5b13ff3eb9d4e048e0aaeb67fc3977400bb43652cdbd32","title":"\u0420\u0435\u0434\u0430\u043a\u0442\u043e\u0440 \u043d\u0430\u0442\u0438\u0432\u043e\u043a \u0438 \u0441\u043f\u0435\u0446\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0432 vc.ru \u2014 \u043d\u0430\u0439\u0434\u0438\u0441\u044c!","buttonText":"","imageUuid":""}

«Каждый день я работал по 14 часов, по выходным — 5–6, и так полгода». Что такое безнадежный проект и как его пережить

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

Всем привет! Сегодня хочу поговорить о том, о чем обычно говорить не любят — о трудных, невыносимых проектах и о неудачах. Но это будут не те неудачи, на которые хочется пожаловаться, а те, благодаря которым мы становимся опытнее и ценнее как профессионалы.

Меня зовут Дима Курамшин, более 12 лет я работаю в IT и более 8 лет я управляю IT-проектами в самых разных ролях. Сейчас работаю в AGIMA. Благодаря обширному опыту меня часто подключают либо к ключевым проектам в компании, либо к тем, которые находятся в кризисном состоянии. И здесь я расскажу об одном из самых интересных кейсов в своей практике.

Небольшая ремарка. В этой статье я расскажу о реальном кейсе из своего прошлого, это было задолго до AGIMA. Однако, несмотря на то, что этот проект давно закрыт, из уважения к нашей команде и бывшим партнерам, я всё же не буду указать имен и названий. Скажу лишь, что все данные абсолютно реальны, проект был завершен, а многие участники работают в других командах и даже странах.

Предисловие

А начну с конца. После завершения моего безнадежного проекта я долго анализировал свои действия и проводил работу над ошибками. В этот момент мне попалась книга Эдварда Йордона «Путь камикадзе». Именно в ней я и нашел термин «безнадежный проект» (в оригинале — death march), а еще узнал много полезного.

Итак, что такое безнадежный проект в нашем с Йордоном представлении?

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

На практике это выглядит примерно так:

  • Сроки проекта сокращены более чем вполовину от нормы.
  • Проектная команда вдвое меньше необходимой.
  • Бюджеты и связанные с ним ресурсы урезаны наполовину.
  • Требования к функционалу (объем работ, scope) вдвое превышает значения, которые они должны были бы иметь при нормальных условиях.

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

Подключение к проекту

Даже если проект начинается в разумной и спокойной обстановке, все равно велика вероятность, что по мере своего продолжения он выродится в безнадежный

Э. Йордон, «Путь камикадзе»

Для меня проект начался стандартно. Однажды утром меня вызывает руководитель и объявляет, что меня назначают на проект по разработке нативной ERP-системы для автоматизации производства и продаж в одной крупной сети. Проект активный и сложный, команда из примерно 20 человек уже больше полугода разрабатывает MVP-версию.

Моя задача — принять дела у предыдущего руководителя проекта. Но тут выясняется, что я уже 4-й по счету руководитель, все мои предшественники уволились, а последний и вовсе уходит спустя неделю работы. Тревожный звонок.

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

Итак, у меня примерно 5 дней на то, чтобы принять дела у текущего РП и взять на себя управление проектом. С чего начать?

Анализ, анализ, анализ

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

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

Изучение документации сразу показало, что у нас проблемы с документооборотом: сроки были сорваны, а новые не зафиксированы. В документах было много пробелов в содержании проекта и обещаний. Но об этом расскажу дальше.

Итак, для быстрого погружения в проект я:

  • изучил проектную и договорную документацию;
  • пообщался с действующим руководителем проекта;
  • пообщался с проектной командой;
  • встретился и переговорил с клиентом.

За отмеченные 5 дней я быстро принял необходимые дела. А вот полноценная интеграция в проект у меня заняла примерно 2 недели. К этому времени я уже точно представлял, что происходит на проекте.

Статус на момент подключения к проекту

То, что я обнаружил, не внушало надежд на светлое будущее.

  • Срок проекта изначально оценили в 9 месяцев. Когда я подключился, проект уже тянулся 11. Чтобы завершить работы, требовалось еще как минимум 4 месяца. Итого, отставание от первоначального плана составляло полгода.
  • Когда меня назначили руководителем, бюджет проекта был израсходован на 96%. Чтобы успешно его завершить, нужно было превысить бюджет на 58%.
  • Рентабельность проекта изначально закладывалась в 15,5%, но на момент моего подключения составляла 4%. К концу проекта показатель рентабельности ожидался в районе –58%.

Мягко говоря, ситуация выглядела плохо. Особенно с учетом того, что речь шла про десятки миллионов рублей. Сложно поверить, что такие проекты отнюдь не уникальный случай, и периодически они появляются в каждой компании. И тут главное — понять, что именно привело проект в такую ситуацию и как не допустить подобных ошибок в будущем.

5 «детских» ошибок, погубивших проект

Анализируя проект, я зафиксировал в специальном журнале более ста замечаний и ошибок. Чтобы не перечислять все, я объединил их в 5 более крупных ошибок, которые, в моем представлении, и завели проект в кризис.

Ошибка №1. Излишняя самоуверенность

Наша компания заключила фиксированный контракт на проект с оценочным сроком работ в 9 месяцев. Но сама ошибка была в том, что фиксированный контракт компания заключила, не имея опыта работы над подобными проектами и опыта решения подобных задач.

Ошибка №2. Пробелы в договоре

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

Ошибка №3. Наивность и слепая вера в подрядчика

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

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

Итого, мы полностью передаем контракт на реализацию достаточно крупного и интересного проекта неизвестному подрядчику, найденному по выгодной цене.

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

Причем подрядчика «оштрафовали» на 500 тыс. рублей, чему, я думаю, он был рад. Ведь скоро штатная команда занялась переоценкой и поняла, что итоговая стоимость проекта должна была быть в 2–3 раза дороже, чем изначально планировали.

Ошибка №4. Мало внимания проектированию

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

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

В нашем проекте на проектирование выделяли 2 месяца. К сожалению, одной из фатальных ошибок стало то, что проектирование доверили субподрядчику и оставили его полностью без контроля. То есть никто не уделял должного внимания ходу работ, не проверял разрабатываемые артефакты, не запускал процесс согласования, когда это было необходимо, и т. д.

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

Ошибка №5. Плохое ведения проектной документации

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

  • план-график был неактуален и редко обновлялся;
  • почти отсутствовало управлением изменениями;
  • полностью отсутствовало управление рисками;
  • ресурсное планирование было, хотя и поскрипывало;
  • управление бюджетами отсутствовало.

Не люблю придираться, но, по моим меркам, такое документирование проекта было недопустимо. Конечно, проблемы были не со всех сторон. Местами что-то фиксировалось хорошо. Но для серьезных проектов и такого типа контракта, по моему мнению, недостаточно.

Итоги анализа

  1. Определил потенциальные затраты, которые нам потребуются для завершения проекта.
  2. Определил плановые сроки завершения проекта.
  3. Составил реестр рисков, определил ключевые, подготовил планы по ним.
  4. Актуализировал ресурсный план, чтобы понять, какие люди мне необходимы и в каком количестве.
  5. Собрал информацию и проанализировал совершенные ошибки и причины, которые превратили проект в безнадежный.
  6. Оценил общее настроение на проекте.

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

В итоге я получил достаточно информации, чтобы сделать выводы.

Проанализировали. А что дальше?

На этом этапе у менеджера проекта, как правило, есть выбор. Вы можете:

  1. Отказаться от управления безнадежным проектом.
  2. Инициировать досрочное закрытие проекта.
  3. Согласиться на эту роль.

Отказываемся от проекта

Тут вы можете возмутиться: «Как же я могу отказаться от него?» Очень просто. Как я писал выше, кризисные проекты отнимают много сил и времени. Большинство таких проектов приводят нас к вынужденным переработкам, работе под постоянным давлением и в состоянии стресса, не исключены и регулярные конфликты на любом уровне. Менеджерам таких проектов (да и другим участникам команды) часто приходится забыть про отпуска, жертвовать свободным временем, личной жизнью, физическим и психическим здоровьем в пользу проекта. И если постоянные переработки в течение 2–3 месяцев можно потерпеть, то жить в таком режиме полгода и больше будет сложно. Я знаю случаи, когда люди на безнадежных проектах подрывали здоровье и рушили свой брак. Нужно ли это вам? Готовы ли вы к такому? Решайте сами.

Забегая вперед, для меня работа на этом проекте превратилась в ежедневные смены по 11–14 часов в будние дни и по 5–6 часов в выходные. Это продолжалось 5 месяцев. Почти все участники команды работали с большими переработками.

А что, если руководство не дает возможности отказаться от проекта?Поговорите с руководителем еще раз, объясните ситуацию. Возможно, повысить шансы на успех проекта поможет менеджер с более подходящими компетенциями? Конечно, вы всегда можете покинуть компанию, но это крайняя мера.

Инициировать досрочное закрытие проекта

К сожалению, многие просто не думают о том, что любой проект можно закрыть досрочно. Да, это может быть не так легко и не так приятно, как довести его до конца. Но всё же это может стать вашим лучшим решением. Подумайте и оцените, во что вам может встать досрочное закрытие проекта и соотнесите с теми затратами, которые повлечет доведение его до финала. Иногда расторгнуть контракт и выплатить штраф выгоднее, чем тянуть такой проект. Помните, что так вы можете не просто избежать дополнительных расходов, но и сберечь репутацию, сохранить команду.

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

Зачем соглашаться на участие?

Вам может показаться, что я считаю, будто безнадежных проектов следует в принципе избегать, но это не так. На самом деле и я, и многие другие соглашаются участвовать в безнадежном проекте, и это объяснимо. Например, Йордон приводит такие причины:

  1. Риск высок, но вознаграждение тоже. Если соотношение риска и вознаграждения выглядит привлекательно, то это может стать большим соблазном участвовать в проекте. Речь не только о денежном вознаграждении. Это может быть психологическая награда: создать революционный продукт, помочь человечеству найти лекарство от болезни и так далее. Конечно, это чаще привлекает молодых сотрудников или компании.
  2. Синдром покорителей Эвереста. Тут безнадежный проект представляется как возможность испытать себя. Одна только мысль сделать то, чего никто не мог сделать до тебя, заставляет кровь кипеть. Это может быть вызов, и люди соглашаются в надежде завоевать славу и признание.
  3. Наивность и оптимизм молодости. Как правило, в IT работают молодые и прогрессивные ребята. У них высокая целеустремленность и уверенность в себе, но и наивность. Многие готовы взяться за такие проекты, просто не понимая, что они за собой скрывают.
  4. Альтернатива — безработица. А вот и другая сторона медали. Если наивность — это чаще про молодых специалистов, то мотиватором более зрелых иногда становится страх потерять работу.
  5. Возможность будущей карьеры. Безнадежные проекты учат нас многому и взращивают из нас профессионалов быстрее. Наградой тут может быть продвижение по карьерной лестнице или шанс громко заявить о себе на рынке.
  6. Альтернатива — банкротство. Сотрудники соглашаются участвовать в безнадежном проекте, если верят, что альтернативой является банкротство или иные страшные последствия.

Я не могу однозначно ответить, почему согласился на этот проект, ведь я знал, на что иду. К тому моменту у меня за плечами уже был не один сложный проект, многие были кризисными. Но всё-таки я сказал да. Скорее всего, я хотел принять вызов, набрать очков в пользу будущей карьеры.Но вместе с тем я еще и проявил наивность. Этот проект казался просто еще одним кейсом в моей копилке, не больше. Казалось, что справиться с ним будет легко. Так или иначе, после отказа от досрочного закрытия проекта я согласился взять на себя ответственность за его реализацию.

Как спасти безнадежный проект

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

И конечно же, одним из самых важных шагов станут переговоры.

Переговоры — ваше всё

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

Э. Йордон, «Путь камикадзе»

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

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

Конечно, все зависит от конкретной ситуации, но я бы рекомендовал пойти таким путем:

  1. Сначала проводим переговоры внутри своей компании и команды.
  2. Потом проводим переговоры с заказчиком.

Внутренние переговоры

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

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

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

Если ваше руководство слишком увлекается политическими играми, старайтесь держать его подальше от проекта. Кроме того, рекомендую помнить, что безнадежный проект требует от менеджера умения говорить «нет». Принимать любые условия руководства тут не получится. Под условиями тут можно понимать, например, такое: «сделать это до пятницы любыми силами» или «мы не дадим более опытного программиста, обходитесь тем, кто есть».

Но тут справедливо и обратное. Обещая что-то руководству или настаивая на собственных требованиях, менеджер должен быть уверен в успехе. Если менеджер не умеет правильно оценивать проект, работать с ключевыми метриками, работать с рисками, то безнадежный проект — это последнее место, чтобы такому учиться.

Переговоры с заказчиком

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

Мои переговоры с заказчиком об увеличении бюджета продолжались примерно 2 месяца. Мы провели не менее 8 раундов. К сожалению, никакого дополнительного финансирования мы так и не получили. Заказчик был умен и прекрасно понимал, в какой ситуации оказалась наша компания из-за ошибок. И откровенно говоря, планировал максимально долго этим пользоваться, о чем заявлял почти открыто. После пары раундов переговоров я перестал верить, что получится добиться увеличения бюджета. Но я всё-таки продолжал проводить переговоры, и каждый раз добивался каких-то небольших выгод и соглашений. Например, мы сократили количество встреч и времени на коммуникации, сократили затраты на проведение демонстраций, вместо экспериментальных решений по интеграционным взаимодействиям воспользовались уже проверенными, оптимизировали график работы проектной команды, значительно сократили и где-то отказались от формального документирования не теряя при этом качества и многое другое.

Команда и мотивация

Первая отличительная особенность безнадежного проекта — явно выраженный акцент на правильном формировании проектной команды.

Э. Йордон, «Путь камикадзе»

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

Йордон выделил 4 стратегии формирования команды безнадежного проекта:

  • Стратегия №1. Команда суперзвезд

Нанимаем суперпрограммистов и предоставляем им полную свободу действий.

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

  • Стратегия № 2. Команда «Миссия невыполнима»

Привлекаем команду, готовую к невыполнимой миссии и имеющую опыт совместной работы.

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

  • Стратегия № 3. Команда простых смертных

Формируем команду из самых обычных специалистов, но предупреждаем, куда и на что они идут.

Наиболее распространенный вариант, когда мы сталкиваемся с безнадежными проектами. В команде может не быть суперпрограммистов или тех, кто вместе прошли тернистый путь ранее. Следовательно, это новая команда, собранная на проект, и ваша задача — постараться превратить ее в команду «Миссия невыполнима».

  • Стратегия № 4. Команда «счастливчиков»

Берем просто всех, кому «посчастливилось» быть назначенными на этот проект, и пытаемся сделать из них команду «Миссия невыполнима».

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

Внимание к комплектации команды

А теперь немного мистики. Чтобы команда была эффективной, ее участники должны иметь высокую квалификацию, но еще более важный фактор — психологическая совместимость.

Разумеется, формирование сплоченной команды занимает время. Йордон пишет, что в процессе эволюции команда проходит 4 основные стадии:

  1. Формирование: участники команды определяют цели, роли и направления работы.
  2. Утряска: команда устанавливает правила и процедуры, пересматривает роли и ответственность.
  3. Нормирование: вырабатываются процедуры, стандарты и критерии.
  4. Выполнение: команда начинает функционировать как единое целое.

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

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

Психологический аспект и мотивация

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

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

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

Во-вторых, основные факторы, влияющие на мотивацию, сосредоточены вокруг тех процессов, которые происходят в команде.

В-третьих, и это самое главное, будьте внимательны к участникам команды. Ограждайте их от лишних задач и сторонних вопросов, защищайте от вмешательства руководства и других менеджеров. Выгоняйте их с работы в пятницу, запрещайте им работать по выходным, давайте им возможность отдохнуть и выспаться. Как бы ни шла работа, всегда заботьтесь о своих людях. Если вы можете как-то повлиять на их зарплату, сделайте и это. Всё это поможет сохранить команду в целости.

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

На кризисном проекте люди — это ваша самая главная ценность, и нет ничего важнее участников вашей проектной команды.

Работая над этим текстом, я вспоминал, насколько тяжелым был тот проект, но я уверен, что сделал для своей команды всё возможное. Несмотря на то, что работать было сложно, у нас был крепкий коллектив, хороший боевой дух, доверие друг к другу. Именно такая команда способна творить чудеса, а это именно то, что требуется на безнадежных проектах.

Помните, что при работе на безнадежных проектах команда находит удовлетворение и радость только в совместной работе с конкретными людьми. Задумайтесь об этом.

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

Условия работы

Есть много исследований, доказывающих, что хорошие условия работы увеличивают продуктивность сотрудников проектных команд. Если члены команды работают в шумном офисе и постоянно отвлекаются на посторонние дела, байки коллег, приглашения сходить на перекур/кофе или приставания других сотрудников с какими-то вопросами, то вероятность ошибок в работе увеличивается в разы, а скорость работы снижается более чем в 2 раза.

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

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

Процессы

Если вы запомните хотя бы одно слово из всей книги, то этим словом должно быть «приоритетность» (triage).

Э. Йордон, «Путь камикадзе»

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

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

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

Подведем итоги

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

  1. Первым делом проанализируйте, почему проект оказался безнадежным, где были допущены ошибки и можно ли исправить их в текущей ситуации.
  2. Объективно оцените свои силы и возможности компании: если проект оказался кризисным, возможно, тратить на него время и ресурсы уже бессмысленно.
  3. Договаривайтесь: чтобы вытащить проект из кризиса, вам понадобятся ресурсы — и это нормально. Сделать что-то из ничего невозможно. Поэтому откровенно говорите заказчику и руководителю, как можно выйти из положения и какая помощь вам нужна.
  4. Работайте с командой: подберите тех людей, которые помогут вывести проект из кризиса, мотивируйте их, поддерживайте, добивайтесь для них лучших условий — вместе вы решаете непростую задачу.
  5. Позаботьтесь об условиях труда: справиться с трудностями можно, только если вам и команде ничего не мешает. Поэтому не стесняйтесь просить особых условий, если это поможет достичь цели.
  6. Проявляйте гибкость: процессы должны помогать, а не мешать работе. Поэтому подбирайте такие практики и методы, которые будут всем удобны. И не тревожьтесь, если иногда заведенные обычаи не будут соблюдаться.

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

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

Если у вас остались вопросы — задавайте в комментариях. Буду рад ответить. А еще подписывайтесь на телеграм-канал об управлении проектами от AGIMA, который веду я. Там больше интересных кейсов и методик.

0
132 комментария
Написать комментарий...
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Om a

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

Ответить
Развернуть ветку
6 комментариев
Alexey Mokrushin

Вы все забываете про коммуникации на проектах подобному этому очень велик их объем. Они проходят как с РГ заказчика так и внутри. Задач обычно ТЬМА. Это же ЕРП-система, нам не рассказали скоуп, но вы предположили что это просто.

Ответить
Развернуть ветку
1 комментарий
Dmitriy Kuramshin
Автор

Скорее рабочих 16 ч/день это прям редкость - не знаю кто такое бы вывез :)) Может пару таких дней за весь период я и насчитаю (отчетные периоды какие-нибудь). Все же стандартное время для меня - 11-14 ч/день. Меньше 11 уже тоже редкость.

График менеджера всегда немного рваный и не такой предсказуемый как у прикладного специалиста: сегодня - одно, завтра - другое.

Если попробовать выделить какие-то категории затрат времени и "от-до", то наверное я бы сделал так:
1. Около 4-7 ч - коммуникации и они занимали обычно самую большую часть работы, где:
- внутренние коммуникации (с проектной командой) - 1-3 ч
- внутренние коммуникации (прочие: руководство, антикризисный комитет, юристы, ресурсные менеджеры и т.д.) - 1-2 ч
- внешние коммуникации (заказчик, функциональные заказчики)
2. Решение регулярных управленческих задач - 2-4 ч (план-графики, реестры рисков/изменений/артефактов и т.д., планирование спринтов, планирование релизов и другие регулярные задачи)
3. Решение нерегулярных задач - 1-3 ч (планирование ресурсов, планирование бюджетов, подготовка различной документации, участие в найме и подборе, подготовка различных отчетов/презентаций, решение отдельных антикризисных задач)

Справедливо отметить, что у меня был параллельно с этим еще один проект, который мог съедать 1-3 ч/день, но не каждый день.

На протяжении всего проекта я много внимания уделял возможному сокращению времени как по себе, так и по команде. Но все же коммуникаций все равно было очень много и достаточно серьезной проблемой (лично по моему мнению) - это процессы антикризисного управления в этой команде. В случае попадания проекта в кризис, у менеджеров автоматически увеличивалась нагрузка и мне до сих пор кажется, что не все в этом процессе было в порядке...

Ответить
Развернуть ветку
Alexander

Всё-таки РП - самая тяжёлая и неблагодарная позиция в IT. И далеко не самая высокооплачиваемая. Но опыт гребешь быстрее всех в разы. РПшник в общем может любую карьеру выстроить или свой биз. поднять. Самые крепкие и закалённые люди.

Ответить
Развернуть ветку
Om a

На рп очень легко списывать все проблемы проекта)

Ответить
Развернуть ветку
5 комментариев
Скрытый Потанцевал

Поймал флешбек работы в интеграторе в начале двухтысячных, пришел такой, почти сразу после ЦАХАЛа, ветеран боевых, а мне говорят – смотри, есть такой классный проект, там как раз руководитель ушел, а у тебя уже есть опыт командования, чего тебе идти просто аккаунт-менеджером, глядишь и карьера начнет расти. и понеслась жара, клиент полугосударственный телеком-оператор, система не ключевая, но важная, команда просрала эстимейты и сфокусировалась на low hanging fruits, даже показать нечего, приходилось и по 18 часов в сутки работать. Проект в итоге вытянули, из-за чего мой карьерный рост в той конторе и не случился, такая была сложная политика, но зато опыт прирос приличный.

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Очень сильная история получилась, снимаю шляпу )) А вот что вас мотивировало работать на таком?

Ответить
Развернуть ветку
2 комментария
Владлена

Закажу пожалуй книгу про безнадёжный проект 😂 выжить с таким графиком и не опустить руки это сильно!

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Очень советую книгу, о которой упоминал в статье! Немного жалею, что я ее прочел уже после того, как многих подобных проектах. Очень полезное чтиво для опытных менеджеров (новичкам бы не рекомендовал), хоть и немного старое

В книге действительно нашел классные советы и рекомендации. До некоторых я уже дошел опытным путем, а о каких-то не задумывался ранее. Короче, рекомендосьен :)

Ответить
Развернуть ветку
1 комментарий
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
1 комментарий
Константин Добров

Так, а как ваша зарплата изменилась в этом периоде?

Складывается ощущение что про Agile и Scrum раньше в той компании ни кто не слышал...

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Моя зарплата тут никак не изменилась, если не считать премиальной части, которая от этого проекта ну никак не зависела :)
На самом деле, мы этот проект вели в Agile, хотя это больше было похоже на мешанину разных практик, вида Scrumbut, Kanbut... Я сначала задумывался о том, чтобы раскатать там Scrum (как раз облюбовал его), но почти сразу понял, что там ни команда, ни заказчик не готовы к нему - а это уже почти гарант провала. Прям уйти в какую-то конкретную практику там тоже не получалось. Если интересно, скорее там было нечто среднее между Kanban + XP. Очень серьезной помехой тут еще были определенные бюрократизм от заказчика, с которым я бился очень долго, но так и не победил. Но честно могу сказать, если бы мы вели этот проект по каскаду, то я бы даже ни на минуту не поверил бы в его успех :))

Ответить
Развернуть ветку
Evgeny

Гибкие методы управления проектами сильно переоценены и скорее дань модному тренду, который прямо сейчас заканчивается. Надёжнее водопада ничего нет и не будет. Любой серьезный проект, причём необязательно в ИТ, реализуется именно так. Ну а смузи стартаперы пусть играются в эджайл, пока молодые.

Ответить
Развернуть ветку
15 комментариев
Alexander

У вас несколько раз встречается слово "игра". Мне тоже помогало относиться к сложному проекту как к игре. Без эмоционального погружения. Просто квест где нужно перебрать подходящие варианты и выиграть. Даже азарт появляется

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

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

Ответить
Развернуть ветку
Ковригин Григорий

Человек просто написал о том, как ему удалось выжить) Молодец, всё же

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо! Надеюсь, статья понравилась :) Я все же больше придерживался цели именно поделиться опытом и дать какие-то советы и рекомендации другим менеджерам. Для меня это был далеко не первый подобный проект... к счастью или сожалению :)

Ответить
Развернуть ветку
Эльвира Асарова

Как можно выжить с таким графиком работы

Ответить
Развернуть ветку
Sardor

Ну в консалтинге и инвест банках люди работают примерно также

Ответить
Развернуть ветку
3 комментария
Dmitriy Kuramshin
Автор

Это действительно тяжело, но вполне реально. Главное найти для себя какие-то точки опоры. Лично для меня важна какая-то мотивация... работать на таком проекте просто потому что тебя туда поставили - не приведет ни к чему хорошему))

Ответить
Развернуть ветку
2 комментария
Сергей Куприянов

При работе по 14 часов в день как находить силы вставать на следующий день? И вообще продолжать работать? Есть какой-то секрет?

Особенно если учесть, что проект сложный, демотивирует, наверное

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Это был действительно очень тяжелый период в жизни. Искренне благодарен своей жене за поддержку, понимание и что она сама выдержала это :) Все же для родных и близких это тоже испытание.

Ну поначалу меня точно мотивировало то, что это выглядело как вызов. Проджекты до меня не справились, бизнес не знал что делать и тут есть я, с уже солидным опытом в т.ч. и в ведении данных проектов. Меня привлекал также стэк, т.к. было мало опыта управления подобными проектами, а это кейс в мою копилку. Но вот спустя время это все перестало радовать и я ставил себе целью удержать команду в первую очередь. Тут можно считать, что я больше работал не ради своего руководства, возможных премий и подобного, а я работал именно ради участников нашей команды. И, кажется, мне удалось сколотить очень мощный и крепкий коллектив, где многие работали и поддерживали друг друга. Я просто не хотел подводить свою команду и бросать ее на произвол судьбы... наверное с этими мыслями я доводил уже проект до финала))

Ответить
Развернуть ветку
1 комментарий
Форопонова Ася

Работаю по 14 часов в сутки, кроме пятницы(там 7 часов) и выходных. Полёт нормальный)) правда хочется после работы и отдохнуть приличненько

Ответить
Развернуть ветку
1 комментарий
Zaraza

Меня в таком случае двигало только понимание, что проект временный, на постоянке так шарашить могут люди только с откровенными девиациями)

Ответить
Развернуть ветку
2 комментария
Zaraza

Статья достаточно интересная и написана неплохо, тем более многие в подобной ситуации себя определенно ощущали либо с высокой вероятностью ощутят!

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

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо большое! Рад, что оценили мою статью.

На самом деле, вопрос очень интересный... Причины ввязываться в такой проект могут быть разными, даже у опытных ребят. Менеджеры все равно продолжают влезать в подобные проекты снова и снова, даже если уже там побывали. Я лично знаю таких, у кого есть большой страх потерять работу и он готов ввязаться в самый страшный проект, лишь бы этого не произошло. Для кого-то мотиватором становятся дети, кредиты, ипотека и другие прелести взрослой жизни. Но не только страх на это мотивирует :)

Насчет себя могу сказать, что в один похожий проект я включался, т.к. ожидаемая награда была достаточно приятна - я успешно завершил этот проект и это дало скачок в моей карьере. Еще один подобный проект я взял потому, что он был очень амбициозен и я знаю, что результат моего проекта сейчас внедрен во многих банках и финансовых компаниях в стране. Приятно осознавать, что создал что-то значимое - хотя я не считаю, что этот проект мы завершили прям успешно. А вот в проект, о котором говорю здесь, я сам уже точно не знаю почему включился... наверное все же верил в возможность развития своей карьеры + надеялся помочь в "спасении" нашего бизнеса от провала, т.к. мне казалось, что я самый подходящий кандидат на эту роль, чтобы попробовать вытащить проект.

Думаю, что меня и снова можно заманить в такой проект, если я почувствую тут достижение каких-то своих личных интересов... хотя звучит уже как исповедь мазохиста :))

Ответить
Развернуть ветку
4 комментария
Red Fox

Несколько мыслей о прочитанном.
Уровень бардака в описанной компании поражает!
1. Сначала подписывается многомиллионный договор с низким уровнем маржинальности, "не имея опыта работы над подобными проектами и опыта решения подобных задач"
2. Договор, судя по комментарию автора с пробелами и кучей пробелов. Кто готовил и согласовывал текст договора?
3. Проект почему то отдаётся на субподряд неизвестному субподрядчику, которого начинают контролировать только на 3-й месяц работ и затем отказываются от подряда. Руководство хотело срубить бабла по легкому?
4. Автор подключается к проекту на 11-й месяц. Вопрос! А что делали в период с 3-го месяца по 11-й ? В компании кто то вообще контролирует ситуацию с проектами?
5. Проблемы с проектированием и ведением документации! Вопрос! А в компании есть какие то утвержденные стандарты и правила по поводу проектирования и ведения документации? Или каждый руководитель проекта это делает на свое усмотрение? Предыдущие 3 руководителя проекта видимо так и делали. Почему их никто не контролировал? Они были реально PM или это были друзья или родственники кого то из ТОПов компании?
Короче, вопросов масса, а ответ один - БАРДАК. И проблемы этого бардака в руководстве и менеджменте компании.
Есть такая мудрость: "Умный знает как выйти из трудной ситуации, а мудрый в нее не попадает".
Слава Богу, что в таких компаниях есть парни, которые с мозгами и готовы вытаскивать на своих плечах весь этот бардак. Руководство должно на них молиться, но судя по комментарию автора эти козлы даже премию не дали за то, что безнадежный проект вытянули и закрыли.
Бонус, в данном случае только один - это опыт.
Автору желаю удачи в будущих проектах и держаться подальше от компаний с бестолковым руководством!

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо большое! :)
Я сам достаточно глубоко копал в причины совершенных ошибок и искренне удивлялся почему уже зрелая и опытная компания их допустила. Но, как показал мой личный опыт, даже в серьезных и сильных компаниях бывает такая фигня.

На самом деле, бардака в компании не так чтобы много, есть очень классные и регламентированные процессы в части проектного управления. Есть что-то вроде аудиторских проверок проектов и соблюдения методологий, но все же этот проект стал исключением для всей компании )))

Еще раз благодарю за поддержку) Надеюсь, что таких проектов в будущем будет у всех меньше)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
1 комментарий
Obi Van Goga

то, что вы выжили при таком графике уже достижение

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо :) такие проекты очень многому учат!

Ответить
Развернуть ветку
Kate Kras

шикарная статья.
каждая рекомендация - как ПДД: написаны пролитой кровью рп-шника.
обнять!

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо большое! Очень рад, что статья понравилась и особенно рад, если нашли в ней пользу - в этом и была моя цель :)

Ответить
Развернуть ветку
2 комментария
Сергей Леопольдович

Можно я использую статью в качестве кандидатской диссертации? ))))

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Берите))

Ответить
Развернуть ветку
Дмитрий Ластовкин

Прочел на одном дыхании. Шикарно!

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо :) рад, что понравилось!

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо, Александр :) Каждому свое. Я намеренно не стал уходить в конкретику, т.к. черновой вариант статьи у меня вышел в несколько раз больше. Уж не стал разбивать ее на несколько частей. Я еще подумаю, может потом сделаю еще одну статью-продолжение... а может и не стану))

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

По примерам... немного искажаете. Я не увольнял сотрудников и кардинально не менял команду, особенно не нанимая новых. Да, вы абсолютно правы, что онбординг требует времени и обычно затраты выше профита... только к моему кейсу данный пример не очень-то применим, т.к. на протяжении моей работы процесс онбординга прошел лишь у пары сотрудников из ~20 человек. Все остальные уже давно работали в команде и решения принимались вот совсем не на этой основе. В целом, вектор понял, кажется намек на то, что хотелось бы больше примеров данных и количественных/качественных метрик, а также указания определенных триггеров (что заметили, почему это проблема, как решили).

Короче, спасибо за мысли) Рождается идея еще одной прикольной статьи)

Ответить
Развернуть ветку
Сергей Жидков

Отличная статься, большое спасибо автору!
Отметил - " ...к проекту начинают применяться правила и процессы из комплекса антикризисных мер". А можно подробней?

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо большое! Надеюсь было познавательно и полезно :)

В статье я немного обобщил. В разных компаниях где я работал сам, или просто консультировал по проектной деятельности и процессам, антикризисные меры имели разное представление.

Конкретно у нас был т.н. "антикризисный комитет", который занимался тем, что помогал в решении каких-то сложных вопросов и вытаскиванию проектов из кризисного состояния. это выглядело примерно так:
- Проект попадает в реестр кризисных, за ним закрепляется кто-то из антикризисного комитета;
- Менеджеру проекта назначаются регулярные собрания с комитетом, где он как правило предоставляет определенную отчетность о ходе проекта и динамике изменений. На этих же собраниях менеджер может получать рекомендации и задачи по улучшению ситуации, а также менеджер отчитывается о выполнении подобных антикризисных задач.
- Кроме собраний с комитетом, вместе с закрепленным представителем могут определяться какие-то отдельные задачи для решения кризисной ситуации (провести переговоры, инициировать подписание доп. соглашения, подготовить какое-то предложение) и отдельные встречи с этим человеком;
- Менеджер начинает вести дополнительную специальную документацию на проекте, что-то вроде реестра изменений и подобного. Документация позволяет контролировать ход по антикризисным задачам и отслеживать изменения.
- Плюс есть уже разные процессы и задачи у самого кризисного комитета. Контроль в целом за кризисными проектами внутри компании, распределение ресурсов и каких-то определенных бюджетов на решение проблем. Участие в переговорых процессах с заказчиком (если необходимо) и многое другое.

Ответить
Развернуть ветку
Vitaliy Ivanov

Про антикризисное управление слышали? Это прям профессия такая даже есть антикризисный управляющий. А комплекс о котором говорится, это конкретно наработанные практики в направлении тушения пожаров на проектах в критическом состоянии.

Ответить
Развернуть ветку
4 комментария
Julia Ivashchenko

Очень вовремя статья попалась на глаза) спасибо.

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Пожалуйста! Искренне надеюсь, что статья будет полезна, но вы все же не столкнетесь с подобными проектами :) Если же уже столкнулись и у вас есть какие-то трудности, всегда готов подставить плечо коллеге по цеху и помочь, если в моих силах

Ответить
Развернуть ветку
Victor Deev (Гид в Мексике)

А разве бывают безнадежные проекты? У каждого товара есть свой покупатель. Вот только искать этого покупателя иногда быстро, иногда и пол года мало.

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Безнадежный проект - это термин, предложенный в книге на которую ссылаюсь в статье. И безнадежные проекты действительно встречают и не так редко как хотелось бы. Чтобы не создавать путаницы, авто предложил классный идентификатор - отклонение параметров от нормы не менее чем на 50%.

Проще говоря, если тот же бюджет или срок проекта сокращены вполовину от расчетной нормы, то проект попадает в категорию "безнадежных". А такие ситуации с IT-проектами очень частые. Взять те же гос. или полугос. контракты и там, думаю, можно найти много подобных проектов.

Ответить
Развернуть ветку
1 комментарий
Zaraza

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

Изменение какой то переменной ( менеджер, бюджет, сроки проекта, желаемый результат и т.д.) это по сути уже другой проект

Ответить
Развернуть ветку
3 комментария
Alexey Mokrushin

Читаю и вижу аналогии ) Похоже все проекты по внедрению "чего-то из ERP" с такими вводными идут примерно по одному сценарию. На рынке похоже нет ни одного проекта чтобы какая-то компания-внедренец могла бы им погордиться (если копнуть поглубже)

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Не задумывался об этом. А вообще интересно поднять какую-то статистику об успешности проектов около ERP-шных. Причем интересно посмотреть на успехи внедрения и разработки в отдельности. Может озадачусь этим на днях :) Спасибо за наводку!

Ответить
Развернуть ветку
boomzilla

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

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Заинтересовали. А что побуждало команду продолжать работать на проекте или лично вас? Почему мирились с постоянными переработками?

Лично для себя я отметил очень большую важность именно в работе с мотивацией. Участники команды часто тоже находятся под давление, устают, выгорают. Как я писал, может быть и такое, что единственной радостью в работе остается только удовольствие от работы в конкретной команде, с конкретными людьми...

А как было у вас? Можете рассказать подробнее?

Ответить
Развернуть ветку
1 комментарий
Евгения Меметова

Интересно, что вас навело на мысли вспомнить о плохом? Статья интересная, спасибо.

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо большое! Очень рад, что статья понравилась!

На самом деле ничего не навеяло, вот совсем :) Я эту статью задумывал уже очень давно и писал ее долго, периодически откладывая.

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

Ответить
Развернуть ветку
Red Fox

Очень интересная и познавательная статья! Автору 5+

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо :) Очень рад, что статья оказалась интересна и полезна!

Ответить
Развернуть ветку
Sam

жизнь одна

Ответить
Развернуть ветку
Anton Zavarzin

И должна быть потрачена на работу!!!! Отдохнем в пансионате для престарелых

Ответить
Развернуть ветку
5 комментариев
Roman Sokolov

Под копирку мой проект и опыт пережитый на нём. И даже его финал )

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Увы, такие проекты встречаются часто. Мне кажется в каждой компании точно найдется по 1 такому :)
Надеюсь, вам удалось его завершить успешно? Интересно, удалось ли сохранить команду? Часто бывало, что команда разваливается.

Ответить
Развернуть ветку
1 комментарий
Мария Серова

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

А в вашей текущей компании Agima как устроены процессы? Есть ли безнадежные проекты?

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

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

На самом деле, компания далеко не маленькая и давно на рынке. Там сильная и хорошая команда. Возможно, какие-то процессы нуждались в серьезной корректировке, но где не без этого? ) Тут все же была именно проблемная ситуация с самим проектом и очень большим количеством ошибок, которые сам не знаю как пропустили во "взрослой" компании. А подобные проекты встречают повсюду, от какого-нибудь начинающего ИП Смирнов, до Яндекса.

А что именно интересно узнать о процессах? )
Честно и абсолютно ничего не скрывая, могу сказать, что о безнадежных проектах в нашей команде мне неизвестно. Но тут важно сказать, что безнадежные и кризисные проекты - это далеко не уникальный случай. Они есть и встречаются в каждой компании и если мне хоть одна ИТ-компания с достаточно активной проектной деятельностью скажет, что у них такого нет и не было, я не поверю. По официально статистике. которую мне удалось найти (правда это США), усредненно, каждый год в каждой ИТ-компании встречается минимум 1 проект, который может быть трактован как "безнадежный" (т.е. его параметры отклоняются на 50% от нормы). А вот что считать кризисным проектом - тут как правило компании сами внутри для себя это определяют. Мне кажется, что кризисные проекты сейчас есть, но насчет "безнадежных" я не уверен... триггеров я не вижу, поэтому могу считать что таких нет. По крайней мере сейчас.

Ответить
Развернуть ветку
Трям

Добрый день!
Честно говоря, бестолковая статья, извините уж) Затравка сюжета хорошая, проблемы описаны ясно, но потом идет какой-то непонятный набор общих формальностей из серии "чтобы получилось хорошо, надо работать хорошо".

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

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

Вообщем, требуется, больше конкретики. "Имя, сестра, имя!!!"))

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Владъ Русиновичъ

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

1. Жёсткая вертикаль власти. Я до сих пор не понимаю, зачем в IT компаниях создавать диктатуру. Автор статьи объяснил топ-менеджерам, что проект лучше закрыть, но пришел босс всех боссов и сказал: "Я сказал, что проект надо закончить!!! Ведь я самый главный и сам знаю лучше вас всех". Такой подход может подойти только в маленькой студии, где такие дяди играют роль и жнеца и на дуде-игреца. Хорошо, что автор статьи смог довести проект до ума, но скольких человеческих ресурсов это стоило, просто из-за прихоти не уполномоченного лица...

2. Компания не имела опыта работы над подобными проектами и поэтому отдала эту задачу новичкам. Ну пиздец честно... Я конечно иногда и сам готов бросить себе вызов видя интересные и сложные задачи, но я работаю на себя и с такими большими рисками не сталкиваюсь. Тут же большой контракт на несколько десятков миллионов и такая халатность. Я считаю, что на изначально сложные проекты следует брать ребят, которые имели опыт с кризисными проектами и прекрасно понимают, какие факапы на начальном этапе могут привести к кризисной ситуации.

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

4. Абстракция в документах. Сам иногда грешу этим, из-за лени. Впоследствии же откатываюсь в прогрессе и трачу время возвращаясь к планированию... А ведь можно было с самого начала делать как надо.

5. Работать с крупным заказчиком из-за денег. Типичная ловушка в которую все попадают. Особенно крупные IT-шки. Многие мечтают работать с крупными брендами. Да я и сам хотел, пока не столкнулся в работе с крупной компанией и могу сказать, что работать с ними сплошной гемор в котором тобой постоянно пытаются манипулировать давя на свой авторитет. Мне свобода дороже, поэтому работаю только с теми с кем схожусь в видении на проект. Спокойная работа лучше большого чека. ИМХО

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

Ответить
Развернуть ветку
DashaUl

Я бы после такого проекта ушла из сферы мне кажется :) Нужно все же уметь вовремя говорить "нет"

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

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

Ответить
Развернуть ветку
Tony Darko

Круто, спасибо за статью! Желаю не встречать таких проектов

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо :)

Ответить
Развернуть ветку
Dmitriy Kuramshin
Автор

Спасибо большое! Рад, что статья понравилась :)

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

Кстати, очень классно подсветили основные аспекты :)

Ответить
Развернуть ветку
Projecto

Интересная история)

На качество планирования сильно влияет опыт и квалификация руководителя. Если есть пробелы, то могут быть проблемы.
Про 4 встречи по антикризисным мерам это, конечно, печально) Причем эта проблема встречается в большинстве команд. Руководство тратит слишком много времени на обсуждение операционных задач и на стратегические вопросы времени не остается. Это можно решить с помощью таск-трекера.

Например, Projecto. В два клика запросили отчет по проекту/задачи, проверил его, обсудили и сформировали новый пулл задач)

Ответить
Развернуть ветку
129 комментариев
Раскрывать всегда