Почему заказчики сайтов считают, что их обманывают, а разработчики недовольны заказчиками. Часть 2

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

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

Копать отсюда и до обеда

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

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

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

В отсутствие такого техзадания «вилка» оценки сроков и сумм может достигать 70%-80%. И только в редких случаях можно точно оценить проект на начальном этапе, без его детального описания.

В итоге из-за отсутствия техзадания возникают 2 варианта проблемы:

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

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

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

Если нет соответствующего опыта, то не стоит тратить время на написание «макулатуры». Лучше сразу обратиться за описанием проекта к профессионалам.

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

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

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

Волшебные бобы

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

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

1. «Сайт нужен вчера, у вас есть максимум 2 месяца на запуск». А дальше идет аргументация: выставка, начало сезона, ребрендинг или простое «а что тут делать так долго?». Так и хочется спросить: если сроки так важны, где вы были раньше?

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

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

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

Тем более, если вы недостаточно хорошо разбираетесь в разработке сайтов.

2. «Мне нужен собственный Amazon!». Очередной пример незрелости рынка: заказчик не разбирается и не желает разбираться в особенностях инструмента, который хочет получить. Ведь тот же Amazon - это не просто удобный каталог, умный поиск и виртуальная корзина. Это работа целой компании, полностью скрытая от глаз стороннего наблюдателя.

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

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

Вообще при реализации проекта интернет-магазина (если это не выход на рынок крупного игрока) лучшим решением станет поэтапный запуск.Спустя какое-то время бизнес отладит все внутренние процессы по сопровождению сайта и продаж через него (то есть будет готов к расширению). У него появится реальная статистика и аналитика проблемных мест в интерфейсе, накопится база покупателей для реализации программ лояльности. Сайт начнет приносить доход, и тогда его уже можно будет расширять: добавлять новую функциональность и наращивать команду, которая будет поддерживать эффективную работу интернет-магазина. Со временем таким образом можно прийти к своему, пусть и маленькому, но «Амазону», который приносит прибыль владельцу. Однако на это же нужно время, а все хотят завтра.

3. «У меня есть идея, как подвинуть Фейсбук, бюджет 500 долларов». Не хочу вдаваться в подробности, почему нельзя сделать Фэйсбук за такую сумму - думаю, это очевидно.

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

Без «покупки покупателей» ваш интернет-магазин или каталог продукции увидят считанные единицы.

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

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

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

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

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

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

Можно ли научиться управлению, если ему нигде не учат?

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

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

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

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

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

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

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

А внутренний рынок веб-разработки снова остается на прежнем месте, порой срывая сроки из-за человеческого фактора. Хотя именно ИТ-сфера у нас считается самой бурно развивающейся и перспективной.

Влияние «каст» программистов

Итак, сроки проектов обычно срываются не из-за программистов. Но из-за особенностей рынка труда эти люди, конечно, могут влиять на результат. В частности, сам язык PHP (один из наиболее популярных и востребованных языков веб-разработки) в среде программистов почти не котируется. А самих PHP-разработчиков называют чуть ли не новичками в своей среде.

И это недалеко от истины. Многие начинающие программисты в силу относительной простоты этого языка часто выбирают веб-разработку как стартовую площадку для начала карьеры в ИT. Это одна из причин достаточно высокой текучести кадров: проработав пару лет, толковый амбициозный программист «идет дальше», изучает модные фреймворки или языки системного программирования.

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

Другой фактор, определяющий специфику рынка труда в нашей сфере - агрессивная кадровая политика крупных ИТ-экспортеров. Они готовы «выгребать» перспективных кандидатов чуть ли не с первых курсов технических ВУЗов. Небольшим веб-студиям, работающим на местный рынок, сложно конкурировать с этими «гигантами» условиями труда или уровнем проектов. И это делает программистов, пожалуй, самым ценным и незаменимым ресурсом. Даже несмотря на достаточно низкую масштабируемость бизнеса веб-разработки, между студиями зачастую идет гораздо более жесткая конкуренция за кадры, чем за заказы.

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

Так, по данным dev.by, медиана зарплат PHP-программистов в Минске сегодня составляет $1400 в эквиваленте.

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

Итак, себестоимость работы программиста в размере $2 755 - это в эквиваленте $17,2/час (в пересчете на 160 рабочих часов в месяце).

Следовательно, в ставку часа $25 заложено чуть более 30% прибыли.

Зная эту простую математику, можно минимизировать риск попасть в руки недобросовестных разработчиков:

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

2. Если вам озвучивают принципиально меньшую стоимость, значит разработчик:

• либо не видит глубины и сложности проекта (а значит на определенном этапе, когда будет «проеден» бюджет, начнутся проблемы, ведь работать в минус никто не будет)
• либо использует в работе дешевых фрилансеров (которые вряд ли покажут приемлемое качество работы, а то и вовсе пропадут в самый ответственный момент)
• либо пытается выдать использование готовых шаблонов сайта за уникальный дизайн (к сожалению, этот вариант все чаще встречается в практике).

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

Например, любые задачи, которые не оплачиваются заказчиком, и в первую очередь - простои в работе. Получается, чтобы «отбить» 1 час простоя специалиста, необходимо отработать более 2 часов - если в отчетном периоде компания недозагружена более чем на 30%. Такой бизнес становится убыточным, и это делает процент «утилизации» специалистов - одним из ключевых показателей в оценке эффективности.

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

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

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

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

Так что же делать?

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

1. Владелец бизнеса вместе с рабочей группой формулирует бизнес-требования к сайту, утверждает бюджет (на разработку, сопровождение, в т.ч. собственные кадры, инфраструктуру и продвижение) и бизнес-план проекта (с утверждением ключевых KPI).

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

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

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

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

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

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