Лого vc.ru

«Мы факапим, и это вина клиентов»

«Мы факапим, и это вина клиентов»

Егор Волков, сооснователь и гендиректор компании Greensight, написал для vc.ru колонку о пяти типичных ошибках, которые совершают клиенты и которые затягивают срок сдачи проекта. Среди них — туманные цели, избыточная креативность, утечка дисциплины, фокус на инструменты и пренебрежение деталями.

Поделиться

Мама и папа с детства учили меня держать слово. Вас, наверное, тоже. Сказал — сделай. Обещал — выполни. Золотые слова! И, ей-богу, я очень старался им соответствовать.

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

Сорванный дедлайн — это ведь и есть невыполненное обещание. И в нашем деле никто этих обещаний не выполняет. И это вроде как считается нормальным.

Наше агентство факапит. Конкуренты факапят. Факапят подрядчики. Факапят те, кто стоит дешево. Факапят те, кто стоит дорого. Все кругом факапят, даже те, кто очень старается не факапить!

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

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

Вот пять наиболее распространенных клиентских ошибок, которые способны затянуть сдачу любого проекта.

1. Туманные цели

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

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

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

Бывает и еще хуже: авторы идеи так и бредут в тумане до победного конца. Как правило, это происходит с теми, для кого разработка сайта не связана с выполнением конкретной бизнес-задачи. Просто хочется сделать «красиво». Понятие «красиво» — крайне туманное.

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

2. Избыточная креативность

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

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

Особенно вредно вдохновение. Например, оно может появиться в результате прочтения в интернете статьи «10 трендов в мировом дизайне» (сочиненной за полчаса студентом «Британской школы дизайна», который подрабатывает внештатным корреспондентом). Чтение стимулирует креативность, сразу хочется пустить почерпнутые идеи в дело, чтобы быть «на волне».

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

3. Утечка дисциплины

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

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

В любом случае, клиенты не слишком склонны к самокритике. Они охотнее сваливают вину на кого-то другого, хоть на нас, хоть на Папу Римского — но только не на себя.

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

4. Инструменты вместо задач

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

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

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

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

5. Пренебрежение деталями

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

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

***

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

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

Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

Факапите значит вы, а вина на клиентах. Вы не охуели?

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

Очень странно слышать от руководителя крупной студии такую дичь.

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

И клиента не ебет:
1. Сколько итерацией правок было сделано на стадии дизайна
2. Сколько раз меняли цвет
3. Сколько раз пробовали разные иконки
4. Сколько раз меняли баннер в слайдере
5. Сколько раз клиенту наебывал ПМ на мобильные и городские телефоны, чтобы тот утвердил макет, который у него на почте лежит уже 2-ую неделю
6. Сколько раз он был был в отпуске в течение этих 4-х месяцев
7. Сколько раз ответственный со стороны заказчика решился поиграть в дизайнера
8. Продолжать дальше?

Не все клиенты понимают, что это увеличение сроков! Хоть обосрись - простите.

Всем похуй на договор. На кону отношения.

Хуже того. Менеджер со стороны клиента может легко создавать такую ситуацию специально. Например, ему не нравится работать с компанией X, которая осталась во времён предыдущего ответственного, а хочет с компанией Y, что делать? Разрывать договор сложно-дорого-некрасиво, можно просто замучить подрядчика всякой чушью, изображать дурака, и в нужный момент при боссах свалить всё на него.
Можно получить результат по всем работам, а потом придраться к каким-то оплошностям в договорах и давить в них до тех пор, пока исполнитель не сделает тебе всё-всё-всё, потому что никто, кажется, в нашей отрасли не ходит в суд, кроме лебедева.

0

Нах такие отношения, если на договор похуй? То есть факапят обе стороны и это выгодное сотрудничество?

0

Вы предлагаете разрывать договор, когда идёт факап независимо от того кто виноват?

0

Почему независимо? Заказчик нарушает условия договора, вы это знаете, но идёте у него на поводу т.к. вам нужны деньги. Виноваты обе стороны.
На кону не отношения, а бабло, которое исполнитель потеряет, если начнёт качать права со своим договором)

0

Да, есть и такие ситуации и их не мало, но есть ситуации, когда 100% предоплата и мы стараемся сохранить отношения и дать то, что устроит и нас и заказчика.

0

Присоединяюсь к Алексею Костину.
Чувак 15 лет выполняет заказы клиентов (хочется подчеркнуть, "15 лет, Карл!"), и до сих пор не придумал добавить в договор с клиентом фразу типа:
- При каждом изменении ТЗ срок сдачи проекта сдвигается на ХХХ дней.
(ларчик просто открывался)

Да уж, и не говорите!

0

Лев, а что Аркадий Морейнис рекомендует в таких случаях?))

Гапченко не в теме видимо

0

Шутка, повторенная два-три раза, становится несмешной.
Шутка "Лев, а что Морейнис рекомендует в таких случаях?))" повторялась тут чуть менее чем дохрена раз. Щенин в своих комментариях про Морейниса уже и не вспоминает, но нет - кто-нибудь всё равно заявится и повторит этот образчик фантастически искрометного юмора.
Потому и минус.

Благодарю Вас, Артём Гапченко!
Спасли меня от коварных троллей...
( с меня - пиво от "Пивной сетевой компании")

0

как же здорово вбросить и все начинают базарить не по теме статьи, да так прямо аргументированно и энергично)) прямо настоящий хабр

Не было опыта внедрения agile? Может это решит часть проблем? Если был опыт, интересно послушать. Если нет, то интересно почему не пробуете?

К agile сами клиенты обычно не готовы.
Но та система, по которой работаем является миксом разных подходов.

0

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

У таких клиентов не один проект, а портфели взаимосвязанных проектов. У них нет пространства для маневра.

0

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

0

Сделайте дедлайны прозрачно-подвижными. День просрочки на стороне клиента +2 дня к дедлайну. Если клиент может тупить он будет тупить, но ответственность на вас

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

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

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

сроки - вечны. бюджет - резиновый. простор для проб и ошибок - бесконечность.

Уже лет 10 хоронят-хоронят, все никак не закопают.

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

Полностью согласен, вы все правильно написали.
Придраться можно разве только к фразе "бюджет - резиновый".

0

А как же договор, этапы, права и ответственность сторон, пени, расторжение договора, дополнительные соглашения?
Или там все на устных договоренностях делается?

Договорные отношения никто не отменял конечно же. Это далеко не всегда дисциплинирует клиентов.

0

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

0

Все примерно так и прописывается. Реальность расставляет всё на свои места.

0

Константин, проекты (любые сложные) это системы с количеством зависимостей стремящимся к бесконечности, а раз так, то целый проект точно эстимировать малореально.
Вот посмотрите строительную отрасль. На что уж стандартизированная область, все равно факапят сроки даже на типовых проектах. Уж про индивидуальные я вообще молчу, увеличение сроков в 3 раза по ходу строительства - стандартная ситуация.

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

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

Соглашусь, просто в разработке софта (и веб-разработке, в частности) все идут своим путем, набивают свои шишки ибо слабая стандартизация процессов.

0

ГОСТ 34 - все четко, по-военному :)
Если будет не достаточно стандартизации процессов, еще ГОСТ 19.

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

0

да, какая разница!!! аванс бог контракта!желательно 70% сразу и 30% через 15мин. Ну если че, то клиент, ссука во всем виноват!

Мопед не мой, но что если заложить переговоры в сроки? Типа мы потратим N на переговоры и декомпозицию, но больше потому, что не рентабельно.

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

Ебаный насос, сколько хайпа вокруг такой постыдной дичи

Коллеги,

1 - любой сдвиг дедлайна должен увеличивать бюджет. В договорах это у всех прописано.
2 - дедлайн сдвигается выставляется счёт, который клиент оплачивает только в 2% случаев.
3 - за отсутствие оплаты клиент приглашается в суд.
4 - бывает даже суд выигрывается (клиент не всегда прав), но денег никто не получает. Посмотрите у топовых агентств сколько бумажно-выигранных судов и сколько денег по ним.
5 - Логично предложить - закладывайте риски в бюджет. Я смотрю прям вся отрасль по 50 000 000 руб за 6 месячный проект выкатывает)

Итого: добро пожаловать в отрасль!

0

Вспоминается старый анекдот про гестапо и партизан:
- А потом пришёл лесник и выгнал всех из леса...
Я предсказываю ситуацию 2016 года:
компании InSales и StoreLand захватили 90% рынка веб-разработок России, потому что заказчики отказываются платить более 100 долларов США за разработку своего сайта и ждать более 6 часов, чтобы получить готовый результат.

0

Вспоминается старый анекдот про гестапо и партизан:
- А потом пришёл лесник и выгнал всех из леса...
Я предсказываю ситуацию 2016 года:
компании InSales и StoreLand захватили 90% рынка веб-разработок России, потому что заказчики отказываются платить более 100 долларов США за разработку своего сайта и ждать более 6 часов, чтобы получить готовый результат.

0

Рынок конструкторов и рынок веб-разработки - это разные рынки. Конструкторы существуют уже лет 10 и пока даже на фрилансеров особо не повлияли.

Автор прав. В IT факапят все. Те кто это отрицает - либо не айтишники, либо оторванные от реальности философы, либо просто неискренни.

Забейте. Это отсутствие компетенций + ментальность.
Отсутствие компетенций у исполнителей.
Ментальность у заказчиков.
Ядерная смесь при которой никогда вовремя ничего сделано не будет.

0

Я в договоре всю разработку делю на этапы (получается примерно 15) и прописываю сроки каждого этапа, в т.ч. тех, за которые отвечает заказчик (согласование макетов, предоставление материалов).
Не было ни одного острого конфликта по срокам, все все понятно и прозрачно.

За примерно 3-4 года, был всего один клиент, который со своей стороны все делал согласно договору - в прошлом он военный.

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

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

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

0

Копим блоки доп работ, заключаем доп.соглашение.
А как коней на переправе менять по другому?

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

0

И еще, вы наверное не поняли - мы на этапе коммерческого предложения и ТЗ продумываем очень многое, с клиентом ведется объемная работа, и речь здесь не про бриф с 50 вопросами =)

0

Я-то как раз понял. Очень хорошо, когда клиент давний и у вас с ним полное доверие и взаимопонимание. Но любой клиент когда-то бывает новым, про которого вам ничего неизвестно.
По вашей схеме на него ещё до заключения договора и каких-либо гарантий нужно потратить десятки часов, десятки тысяч рублей на аналитику, предварительное проектирование и прочие работы, чтобы сделать документацию (ТЗ), которая станет частью договора. А там в последний момент какой-нибудь директор передумает, и снова по кругу.

0

Сначала идет плотное общение. Да, оно может заниматься десятки часов, но на практике, максимум одна-две встречи и переписка.

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

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

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

С первого раза КП никогда не утверждается.
Всегда что-то добавляется\убывает.

И уже после согласования КП делает техническое задание, которое ложится в договор.

Возможно самое главное, что никак не ложится в вашу картину мира:
Договор и ТЗ делается уже в тот момент, когда клиенту нужен счет на предоплату.
Получается, вариант сделать ТЗ и не получить оплату - минимальный, такое было может пару раз, не могу вспомнить даже...

0

Послушайте, ну если клиенту уже нужен счёт на предоплату, значит он уже узнал цену. Это здорово, если вы обсудили вилку, только вот мой опыт показывает, что клиент всегда слышит её нижнюю границу.
Так вот, если речь уже идёт о предоплате, значит клиент знает цену. И эту цену и трудозатраты вы обсудили на основе встречи и КП.
Вопрос: если все что нужно для утверждения границ проекта (бюджет, сроки, ключевые условия) упаковано в КП, то какой смысл в прикладывании к договору ТЗ? Чтобы усложнить любые движения, которые остаются в рамках границ? Вы ведь даже не утверждаете у клиента это ТЗ, получается, просто подкладываете его к договору. Клиент просто надеется на вашу добросовестность, и хорошо если вам везёт с такими. Как правило люди все читают внимательно, либо не читают и потом отмахиваются, дескать, подумаешь бумаги какие-то, давайте делайте.

0

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
Mikhail Kritsky

Три года подряд летал на 5 месяцев в Тай, на Пхукет. 3-4 месяца ок, последний уже поднадоедает. Обратно на 7 месяцев в Питер.

Потом на год уехали уже в Сочи. Там хорошо, когда не сезон. Мало людей, множество мест питания, дороги свободные. Не так холодно зимой. Что понравилось — отсутствие пробок, светофоров. Да и машину за 16 тыс из Питера можно на поезде отправить.

Одиночество и отсутствие связи с местом: предприниматели о проблемах постоянной удалённой работы
0
Andrey Harchenko

Неоднозначно, смотря какого цвета hat у этого человека

iPhone 7: первое знакомство
0
Сергей Достовалов

Боты примерно такие

Издатель Sports.ru запустил ботов в Facebook для отслеживания новостей футбола
0
Getov Oleg
БомJoviLike

Тема крутая конечно,но ... Все это фигня.

1. Имея 15 летний опыт в такси и то порой стопор от знаков,разметок и ситуаций на дорогах
2. До порта,днем автопилот будет добираться за три часа. Соблюдая все правила ПДД. Вам это будет интересно?

Gett откроет центр разработки в Москве для работы над беспилотными авто
0
Roman Maximov
Magician

Мне даже страшно подумать откуда у него могут быть данные :)

«Яндекс» будет продавать исследования эффективности рекламных щитов
0
Показать еще