Шесть причин, по которым ваш IT-проект будет провален

Если люди, реализующие IT-проект, не слышат друг друга – пиши, пропало. Взаимопонимание критично важно на всех этапах и уровнях: и между заказчиками / разработчиками, и внутри взаимодействующих команд. Каких проблем, связанных с человеческим фактором, важно избежать, автоматизируя бизнес? Чек-лист от экспертов: Алексея Абрамова (на фото слева), в разные годы работавшего руководителем IT-проектов в компаниях «Элемент», SODIS Lab, «Ростелеком», и Михаила Серякова (справа), владельца компании «Вебтолк» из Абакана. Большой опыт проектной работы позволяет им выделить главные ошибки, которые допускают заказчики IT-решений и их подрядчики.

1. Некомпетентность

Алексей Абрамов: Я не раз встречал заказчиков, которые видят в решении для автоматизации работы универсальную «волшебную кнопку» и пытаются с его помощью устранить множество проблем, которые к IT никакого отношения не имеют. Простой пример: не сформирован план развития компании, не описаны бизнес-процессы, нет регламентов, не очерчены KPI, нет понимания мотивации. В общем, не готов фундамент, есть системные ошибки. И с такого старта компания намерена внедрить CRM, электронный документооборот или что-то другое.

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

2. Недоверие

М.С.: Важнейший вопрос: умеет ли заказчик делегировать? Если нет, такой владелец проекта не упрощает и не ускоряет работу, а буквально стопорит ее. Замыкая все вопросы на себя, он не дает возможности ничего сделать ни своим сотрудникам, ни тем более – внешним подрядчикам. Это серьезная проблема, иногда фатальная.

3. Неорганизованность

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

Героизм в режиме 24/7 встречается в IT-проектах нередко. Но вызван он обычно не высоким уровнем ответственности, а серьезными проблемами в планировании. Важно избегать чрезмерно оптимистичных сроков выполнения работ и больше времени посвящать тому, чтобы договориться «на берегу». Следует описать функциональные требования, разработать техзадание, прописать роли и ответственность сторон. В дальнейшем — использовать современные средства коммуникации и контроля исполнения, протоколировать итоги рабочих совещаний, осуществлять объективную корректировку задач и сроков. Это не просто формализм, а рабочие инструменты. Все о них знают, но не все ими пользуются.

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

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

Беда, если руководители проектов прячут проблемы, и они вскрываются уже в конце проекта. Хотя лучше собрать все «грабли» как можно раньше, пока есть время исправить ошибки.

А типичный грех программистов – выполнение поставленной задачи «по-своему». Получается, что формально ТЗ выполнено, но с отличиями. Иногда это неважно, иногда критично.

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

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

4. Гордыня

А.А.: Разработчики часто грешат тем, что пытаются отстаивать свою позицию до потери пульса. Звучит это так: «Мы лучшие на рынке, у нас лучшие практики, лучшие продукты, все лучшее». Апеллируя к своему большому IT-опыту, они нередко игнорируют или поверхностно трактуют опыт заказчиков в предметной области. Прямое следствие: разработчики пытаются навязать сервис и подход, который выгоднее IT-компании, чем заказчику. Не менее опасна ситуация, когда разработчики готовы согласиться со всем, что диктует заказчик: лишь бы заплатил.

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

М.С.: Несколько раз замечал, что разработчики пытаются использовать в проекте какую-нибудь новую технологию не потому, что она нужна заказчику, а просто потому, что хочется попробовать ее в действии. Кроме того, за усложнение проекта легче получить дополнительные деньги, чем за упрощение. Мы регулярно боремся с этим, разъясняя своим клиентам тезис: «Сложно сделать просто, просто сделать сложно».

5. Саботаж

М.С.: Проект может намеренно тормозить один из сотрудников компании-заказчика. Это может быть один из управленцев, который планировал отдать его другому подрядчику, но не сумел. Если проект провалится, он всегда сможет сказать: «Зря меня не послушали». Это может быть ответственный менеджер, которому выгодно «слить» проект, который ему лично невыгоден, так как добавляет ему обязанностей и работы.

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

6. Незаинтересованность

А.А.: Демотивированные сотрудники — это вообще не «айтишная» проблема. Но особенность IT-проектов в том, что на их успех должны быть мотивированы и люди из компании-подрядчика, и люди со стороны заказчика. Если этого нет, то виноваты не рядовые сотрудники, а их руководители. Я сам руководитель, и прекрасно это понимаю. Чем выше должность руководителя – тем больше он виноват: не смог организовать, донести до исполнителей нужную информацию, учесть все риски, мотивировать, повлиять и надавить, проконтролировать.

М.С.: Если проект идет из-под палки, без личной включенности – это даже не человеческий фактор, а «нечеловеческий». В таком случае сотрудники заказчика видят в разработчиках не партнеров по общему делу, а вредителей, которые пришли их отвлечь от важных дел, чтобы все ухудшить. Бывает, что сотрудники заказчика вообще не знают о планах по внедрению IT-продукта. В таком случае перспективы проекта, конечно, плачевные.

Что делать?

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

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

Executive.ru открыл канал в мессенджере Telegram. Хотите быть в курсе самых главных событий российского менеджмента? Присоединяйтесь!
Комментарии
Директор по рекламе, Москва

есть еще одна причина - пользователи не пришли

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

и еще одна причина

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

Дизайнер, Москва

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

Директор по развитию, Москва
Александр Васильев пишет:
Кстати, большая часть этих проблем существует в любой отрасли, а не только в IT.

Именно так! Но это тоже понимают не все.

Директор по развитию, Москва
Дмитрий Федоров пишет:
есть еще одна причина - пользователи не пришли
почему они не пришли - им не хватило мотивации, они уперлись в "пороги" в модели поведения, им предлагается в явном виде много чего и они не могут выбрать нужную им функцию, которая затенена в интерфейсе, им никто не рассказал зачем им нужен ресурс и не убедил их на их языке
и еще одна причина
они пришли, потыкали кнопочки неделю и ушли навсегда, причины те же - модельные - владельцы ресурса не чувствуют пользователей изнутри и пользователи не выработали привычку и уже уходят

Тоже верно, спасибо за мнение. Вообще это тема для отдельного материала :)

IT-менеджер, Абакан

Огромное количество проектов делается "на авось".
- Зачем "ТЗ" ? Авось так прокатит.
- Зачем задумываться о монетизации? Вон, у тех ребят же получилось, сделаем как они, авось тоже "попрет".

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

Тема на самом деле неисчерпаема.

Директор по развитию, Москва
Михаил Серяков пишет:
Тема на самом деле неисчерпаема.

Да, и это ещё вопрос бюджетов слабо затронут - так тема действительно станет неисчерпаемой :)

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Новости
В ЦНТИ Прогресс прошел семинар по сложным вопросам документации

Валентина Андреева провела семинар по новеллам трудового законодательства для слушателей ЦНТИ Прогресс.

МРЦ запустил набор на курсы для поступающих на Президентскую программу

Программы «Бизнес-проектирование» и «Деловой английский язык» разработаны с учетом критериев оценки кандидатов при прохождении конкурсных испытаний.


Компания Columbus автоматизировала передачу данных в сети магазинов «Гроздь»
Cеть начала работу со специализированным ПО для передачи данных в Единую государственную автоматизированную информационную систему (ЕГАИС).
Вышел новый релиз программы «АЛТИУС – Управление строительством»

Релиз под номером 10.11 содержит 30 новых полезных дополнений.