Если люди, реализующие 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-решения.
М.С.: Подрядчикам следует искать не «самое слабое звено», а место, где задачи накапливаются и не решаются. И нужно выяснять, почему так происходит. Нас, например, во внутренних проектах выручает канбан-доска. Быстро выясняется, что менеджеры тормозят с приемкой задач, что программисты перегружены, что руководство банально не успевает принимать решения. Во внешних проектах, как только разработчик замечает, что ему мешают, нужно немедленно информировать руководство заказчика, организовывать встречу и вместе искать решение. Если проблему запустить, она обрастет отягощающими обстоятельствами вроде сорванных сроков и бюджетов, после чего уже трудно добиться непредвзятого обсуждения.
есть еще одна причина - пользователи не пришли
почему они не пришли - им не хватило мотивации, они уперлись в "пороги" в модели поведения, им предлагается в явном виде много чего и они не могут выбрать нужную им функцию, которая затенена в интерфейсе, им никто не рассказал зачем им нужен ресурс и не убедил их на их языке
и еще одна причина
они пришли, потыкали кнопочки неделю и ушли навсегда, причины те же - модельные - владельцы ресурса не чувствуют пользователей изнутри и пользователи не выработали привычку и уже уходят
Всё очень верно подмечено, но задумываются об этом единицы. Кстати, большая часть этих проблем существует в любой отрасли, а не только в IT.
Именно так! Но это тоже понимают не все.
Тоже верно, спасибо за мнение. Вообще это тема для отдельного материала :)
Огромное количество проектов делается "на авось".
- Зачем "ТЗ" ? Авось так прокатит.
- Зачем задумываться о монетизации? Вон, у тех ребят же получилось, сделаем как они, авось тоже "попрет".
Как бы это плохо не звучало, но у нас самые любимые клиенты те, которые уже "обожглись" в прошлом. И это заставляет четче формулировать требования, детальней продумывать и планировать проект.
Тема на самом деле неисчерпаема.
Да, и это ещё вопрос бюджетов слабо затронут - так тема действительно станет неисчерпаемой :)
Первый пункт и, возможно, самый главный, потому что из него и растут дальше ноги и руки проблем.
Когда заказчик говорит, что ему там чуточку нужно сделать, составляется ТЗ, а позже выясняется, что в автоматизации хочу сделать в 10 раз больше, за тот же бюджет и те же сроки. Да ещё и начинает управлять процессом, так как он "лучше" знает, беда-беда!