7 факторов гарантированного провала

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

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

Ниже приведены 7 типичных факторов, которые почти гарантируют отказ.

Фактор 1: не учитывать человеческий фактор

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

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

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

Фактор 2: Думай слишком масштабно или делай слишком мало

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

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

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

Фактор 3: полагаться на оценки и планирование на 100%

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

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

Фактор 4: Магический треугольник PM постоянно игнорируется

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

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

Фактор 5: Документирование всего

Бесплатно в честь Франца Беккенбауэра: «Мы называем это классикой!» Хотя все больше и больше компаний полагаются на agile-процедуры (в основном scrum), все еще находятся организации и проекты, которые придают обширной документации большее значение, чем создаваемому программному обеспечению. Это высокий риск, особенно в крупных проектах. Нередко месяцами или даже годами работает охота консультантов и специалистов отдела на тысячи страниц, которые потом будут переведены другой командой в SW.

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

Фактор 6: Просто не сбалансированная организация проекта

Команда из 20 разработчиков и 1 технический специалист? Нет необходимости в экспертных знаниях, чтобы признать, что эта конструкция рано или поздно выйдет из строя. В начале проекта, будь то каскадный или agile, он все еще может работать, потому что разработчики заняты фреймворками или настройкой сред. Но очень скоро сотрудники будут задавать вопросы — нужна интенсивная профессиональная поддержка.

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

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

Фактор 7: Медленно нагревайте лягушку

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

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

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

Так что это может быть возможно

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

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