среда, 9 ноября 2016 г.

6 причин провала IT-проектов


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

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

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


2. Недоверие

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


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

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

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

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

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

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

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

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

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


4. Гордыня

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

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

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


5. Саботаж

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

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


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

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

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


Что делать?

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

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

Комментариев нет:

Отправить комментарий

Есть комментарий? - Пиши.

Популярное за неделю

ПИШИТЕ: avatarabo@gmail.com  ЗВОНИТЕ: ☎ WhatsApp +7 902 064 4380 (02:00 - 15:00 по Москве)   ОБРАЩАЙТЕСЬ: Skype papa-tron