7 причин, по которым веб-проекты не доводятся до конца, и как с этим бороться

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

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



Итак, какие проекты считаются успешными? Принято выделять следующие параметры:

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

Что же на деле, как часто сданные проекты отвечают всем этим пунктам?

С небольшой разницей в оценках исследования от the Standish Group, Project Management Institute, Gartner, Wellingtone и других респектабельных организаций говорят нам, что треть проектов в IT оказываются провальными, а половина испытывает трудности. Просто задумайтесь, это ошеломляющая статистика.

Сложно сказать, какого уровня проекты участвовали в выборках, но давайте предположим, что это крупные истории вроде провальной модернизации ИТ-инфраструктуры сети магазинов KMart за $ 1,2 млрд, которая стала одним из ключевых факторов банкротства компании.

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

«Заказывали разработку и дизайн сайта в 2015 году. Дизайн сделали быстро, но не сказать, что качественно. Разработку внедряли по 2017-й год да так и не внедрили»

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

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

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

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

Риск 1. Недостаточная квалификация подрядчиков

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

Решив оцифровать часть бизнеса, компания обращается в веб-студию (aka диджитал агентство / веб-интегратор). Обслуживание проходит в формате одного окна. Клиента просят заполнить бриф, на основе которого потом составляют ТЗ. Если проект сложный и требует опытных программистов, то разработку отдают аутсорс-продакшну.

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

Это проблема рынка — подрядчик неадекватно оценивает собственные силы, но при этом берет проекты в продакшн, принимает неправильные решения и в итоге ничем не помогает. Клиент страдает.

Метод избежания

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

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


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


Генеральный подрядчик просит рассчитать стоимость разработки на примере похожих по формату, но абсолютно по-разному реализованных сервисов. «Сделайте как там, по ходу дела разберемся»

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

Риск 2. Исчерпание бюджета до выпуска продукта

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

Объем работ окажется больше, генеральный подрядчик начнет защищать свои интересы и продавливать конечных исполнителей, чтобы те уложились в бюджет. У обеих сторон срабатывает извращенная логика, каждый придумывает себе оправдание поступить чуть хуже, чем оппонент: «Предоставили плохое ТЗ, и теперь увеличивают объем? Тогда не учтем часть замечаний!» / «Мы уже пообещали клиенту, куда они денутся, доделают или не получат деньги!».

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

Метод избежания

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

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

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

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

Риск 3. Изменения посредине проекта

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

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

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

Метод избежания

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

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

Риск 4. Потеря интереса со стороны владельца

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

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

Метод избежания

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

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

Риск 5. Заказчик не выделяет время на участие в проекте

Сотрудники на стороне клиента не дают нужную информацию, руководитель медленно отвечает и всё тормозит. При этом мы точно знаем, что проект нужен клиенту, интерес не утрачен, сроки по-прежнему целесообразные.

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

Метод избежания

Лично договариваемся с клиентом об определении ответственных лиц. Обсуждаем их статус и степень ответственности. Фиксируем их функции и обязанности в графике работ.

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

Риск 6. Затянувшиеся корректировки / доработки

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

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

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

Метод избежания

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

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

Риск 7. Неготовность инфраструктуры для запуска

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

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

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

Метод избежания

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

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

Заключение

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

Но как показывает опыт, есть три универсальных способа для профилактики и минимизации последствий рисков:

• Фиксация потенциальных рисков;
• План действий по их избежанию;
• Готовность к смене курса и поиск альтернативных решений.

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

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

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

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

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