5 способов превращения проекта в провальную госзакупку

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

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

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

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

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

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

Каждый проект решает конкретные задачи:

— если это интернет-магазин, то у заказчика стояла задача продавать товары онлайн;

— если это новостной сайт (электронное СМИ), то вероятно исходная задача доносить информацию определенной тематики до аудитории;

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

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

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

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

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

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

По собственному опыту и опыту наших клиентов эффективной является следующая практика. Формируется команда из 1-3 человек (подробнее в следующем пункте) внутри компании, которые имеют полномочия “от и до” вести проект и принимать результат. Эти люди должны быть непосредственно связаны с интернет-маркетингом или продажами, иметь интерес к проекту, а в идеале быть его инициатором.

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

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

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

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

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