Реальные сроки создания веб-сайтов

Екатерина Шукалова: Здравствуйте, дорогие друзья! Сегодня я, Екатерина Шукалова, и мой гость, которого я представлю немножко позже, поговорим про интереснейший момент, связанный с разработкой сайтов, — сколько же времени нужно на то, чтобы сделать нормальный проект? Хочу представить вам Максима Трегуба, который является заместителем генерального директора веб-студии «Желтофиоль-дизайн» и директором Ассоциации интернет-разработчиков.

Максим Трегуб, заместитель генерального директора студии «Желтофиоль-дизайн».
Родился в 1978 году в г. Петропавловск-Камчатский.
В 2007 году окончил экономический факультет Казанского государственного университета по специальности «менеджер организации».
В 2008 году окончил курсы по повышению квалификации в Московском инженерно-физическом институте, курсы «Технологическое предпринимательство и управление инновациями».
С 2010 года — заместитель гендиректора студии «Желтофиоль-дизайн».
Также является гендиректором НП содействия развитию информационных технологий и цифровых коммуникаций.

Е. К.: Итак, сегодня мы говорим про сроки разработки веб-сайта и пытаемся понять, кто же виноват в том, что те проекты, которые мы начинаем вместе с нашими любимыми клиентами, заканчиваются не вовремя. Хочу напомнить, каковы основные этапы разработки сайтов. Есть несколько этапов, которые требуют определенного времени на реализацию. Соответственно, перед тем как разработчик начинает что-либо делать, он калькулирует каждый этап. Калькулирует, сколько нужно часов, вставляет эти часы в производственный процесс своей веб-студии и дальше отражает это в коммерческом предложении или в договоре, который заключается между клиентом и разработчиком. Макс, скажи, пожалуйста, когда ты пишешь коммерческое предложение и составляешь договор, эти этапы включены в коммерческое предложение?
Максим Трегуб: Этапы те же самые, но если развернуть предпроектные работы, то туда также входит техническое задание и описание структуры сайта.

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

Е. Ш.: Хорошо, то есть до получения предоплаты от клиента ты уже точно знаешь, сколько времени тебе нужно на то, чтобы реализовать проект?
М. Т.: Безусловно. Мы довольно скрупулезно прописываем структуру с заказчиком, согласовываем систему управления, модули и т. д., и т. п. Понимаем, как это все будет строиться, и исходя из делаем предпроектную смету.
Е. Ш.: И знаете эти сроки?
М. Т.: Это будет уже окончательная стоимость проекта в договоре.
Е. Ш.: Хорошо, тогда у меня такой вопрос: когда мы что-либо делаем по разработке наших проектов, мы предполагаем, что, прежде чем что-то сделать, нужно сначала подумать. Но когда я говорю клиенту, что я буду думать в течение, допустим, 10 часов или 12 дней, это вызывает некое отторжение. В твоей практике были ли случаи, когда ты пытался донести до клиента, что в той смете, в той калькуляции, которую ты даешь в рамках коммерческого предложения или договора, есть время «на подумать»?
М. Т.: Да, были такие случаи. Но мы, как правило, об этом не говорим нашим клиентам, заказчикам. Есть подозрение со стороны заказчиков, что мы таким образом можем что-то накрутить. Соответственно, он не знает, скажем ли мы ему реальное время. Поэтому мы стараемся его в такие детали не посвящать, но мы учитываем, безусловно, учитываем…
Е. Ш.: …что вы будете думать.
М. Т.: Конечно. Без этого, в принципе, не будет адекватной стоимости проекта.
Е. Ш.: У меня недавно была ситуация, когда необходимо было на достаточно старый сайт с самописной системой администрирования вставить рекламный баннер. Для того чтобы разобраться с системой, нам потребовалось достаточное количество времени. Что мне говорить клиенту? «Дорогой клиент! Я разбиралась с системой в течение десяти часов. Мне нужно было понять, куда вставить баннер». Затем в течение десяти минут я его вставила и выставляю ему счет на десять часов. Как ты думаешь, что в таком случае делать?
М. Т.: Здесь все просто. Является ли этот клиент постоянным?
Е. Ш.: Да.
М. Т.: Это имеет большое значение. Или он пришел со стороны?
Е. Ш.: Ага, то есть для постоянных клиентов — десять минут, а для новых клиентов — десять часов?
М. Т.: Нет, зачем? С постоянным клиентом гораздо легче договариваться. Безусловно, сначала нужно клиенту говорить, что система управления незнакомая, допустим. И для того чтобы поставить тот же самый баннер, нам потребуется какое-то время. Человеку нужно говорить правду. И сказать, сколько на это уйдет часов. Сначала предварительно согласовать, выставить смету. Если заказчик согласится на это, то, конечно, нужно работать. Если какие-то сомнения у него будут возникать, то тут, в принципе, можно договариваться. С учетом того, что это наш постоянный клиент, можно ему сделать какую-то скидку.
Е. Ш.: Если клиент работает постоянно с одним и тем же разработчиком, ему это выгодно. Правильно? Он получает правдивые сроки по разработке сайта, по поддержке. И мы, соответственно, все знаем про этого клиента, так?
М. Т.: Конечно. Гораздо удобнее и легче выстраивать отношения. Более того, выстраиваются доверительные отношения, что, безусловно, сказывается на стоимости.
Е. Ш.: Хорошо. Давай мы тогда вернемся немножечко попозже к этому вопросу. А сейчас скажи, пожалуйста, были ли в твоей практике такие истории, когда в силу различных причин, о которых мы тоже поговорим чуть позже, сроки разработки достигали бесконечности? На том примере, с которого мы начали наш разговор про интернет-магазины. Сколько, кстати, у тебя в студии занимает сделать интернет-магазин стандартного характера?
М. Т.: Стандартного — до двух месяцев.
Е. Ш.: А если ты понимаешь, что стандартный интернет-магазин, который ты в среднем делаешь за два месяца, начинает растягиваться на три, на четыре, на больше месяцев? Что ты при этом чувствуешь, к чему это может привести и т. д.?
М. Т.: Безусловно, ничего хорошего в этом нет, потому что элементарно есть планы, планы по приходу денег, соответственно, и тем же самым расходам. Если проект затягивается, то он становится невыгодным. Он невыгоден нам как разработчикам. И, безусловно, клиент тоже теряет от этого, потому что он не запускает проект вовремя, соответственно, не монетизирует проект. Причин здесь может быть много. По какой причине задержка произошла? По вине разработчика, или из-за неправильного составления документации, или, грубо говоря, из-за каких-то дополнительных пожеланий со стороны клиентов. Здесь нужно индивидуально разбираться. В принципе…
Е. Ш.: …это плохо.
М. Т.: Конечно, ничего хорошего.
Е. Ш.: Например, тот же самый интернет-магазин, который Максим делает за два месяца, не сделан за пять месяцев, это значит, что проект будет закрыт. Если вы, дорогие клиенты, не успеваете разработать какой-то сайт, запустить его в эксплуатацию в течение, скажем, втрое большего времени, чем указано разработчиком, то, по моему опыту, проект умирает. Ты согласен с этим?
М. Т.: Конечно, полностью согласен.
Е. Ш.: Если вы не успели, то можете забыть про свой проект и те деньги, которые, собственно говоря, были отданы разработчику. Теперь давай конкретно поговорим. На определенный этап разработки необходимо в калькуляции указать определенные часы. В каждой студии, соответственно, часы будут разные. Это зависит от квалификации, от стандартов, от бизнес-процессов, от системы администрирования, с которой мы можем работать. Согласен ли ты, что каждый из этих этапов может растягиваться до бесконечности?
М. Т.: Теоретически да, но есть этапы, на которых нужно сделать акцент. В первую очередь я хотел бы обратить внимание на регламент. Если в студии отсутствует регламент, а так, к сожалению, работает большинство, то будут проблемы. Проблемы с этапами, по срокам. Например, если мы говорим о предпроектной работе, то туда у нас входит техническая документация. Я бы рекомендовал сделать на этом акцент. Чем лучше, чем понятнее, чем подробнее будет расписана техническая документация по проекту, тем, соответственно, меньше будет проблем на дальнейших этапах. Объясню почему. Как правило, возникают вопросы из-за чего? Из-за того, что, допустим, что-то забыли, что-то не поняли. К примеру, на словах проговорили, а в документ не внесли. А потом, после утверждения дизайна, выясняется, что у нас этого модуля нет. Где мы его теперь будем ставить? Давайте переделывать дизайн или вносить в дизайн изменения, да? Пожалуйста, элементарно. Техническая документация позволяет исключить все эти погрешности в будущем, потому что эти погрешности накапливаются в дизайне, потом, соответственно, в верстке и в программировании. Поэтому здесь первое — это документация. И очень важный момент: если в процессе заказчик начинает вносить какие-то изменения, то нужно согласовывать дополнительное соглашение и увеличивать сроки.
Е. Ш.: Мы еще поговорим об этом вопросе. Ты говоришь, что если мы будем работать по некоему регламенту, то все будет здорово. Что это за регламент, где его взять?
М. Т.: Я бы хотел сослаться на наш опыт в некоммерческом партнерстве с Ассоциацией интернет-разработчиков, где у нас присутствуют студии, сертифицированные студии. Эти студии работают по регламентам, у них налажены бизнес-процессы.
Е. Ш.: Регламент — это бизнес-процессы, налаженные в компании?
М. Т.: Конечно, безусловно. Это позволяет более четко, более правильно, более адекватно сделать оценку того или иного проекта. Это имеет большое значение. И конечно, квалификация сотрудников имеет большое значение.
Е. Ш.: Как клиенту это проверить? Я сейчас приду в «Желтофиоль-дизайн» и скажу: «Ну-ка, ребята, показывайте ваши бизнес-процессы! Скажите, как вы тут работаете, дайте доказательство вашей квалификации и т. д.» Как узнать клиенту, реально приходящему в студию, что эта студия работает по регламенту и может грамотно сделать разблюдовку по всем срокам разработки?

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

Е. Ш.: Да.
М. Т.: То, что он занимает ту или иную должность, что у него есть знания, которые он получил, или прошел какие-то курсы, или повышение квалификации прошел и т. д., и т. п. Или какое-то дополнительное образование.
Е. Ш.: Ну, хорошо. Мне кажется немножко фантастичным, что клиент приходит в студию и требует определенные документы. Можно предположить, что не все студии готовы эти документы показывать, потому что в какой-то степени это является коммерческой тайной: мои бизнес-процессы, мои построения и т. д. Мне кажется, это решается на уровне встречи с сотрудниками, посещения офиса и работы с лицами, принимающими решения со стороны разработчика. Так ли это?
М. Т.: Немножко сложнее. Дело в том, что, к большому сожалению, большое количество заказчиков не разбирается в теме.
Е. Ш.: Вообще?
М. Т.: Большинство. Им очень сложно разобраться и понять нашу работу, работу именно в студии, компании или агентстве, которое занимается разработкой. Поэтому оценить адекватно они не смогут.
Е. Ш.: А что же делать тогда, если я клиент?
М. Т.: Здесь есть определенные риски. Есть ряд компаний, которые могут сопровождать те же самые предпроектные работы. Можно обращаться к специалистам. В частности, Ассоциация интернет-разработчиков такую услугу предоставляет, она может подобрать подрядчика на разработку того или иного проекта.
Е. Ш.: Хорошо.
М. Т.: Это минимизация рисков и оптимизация времени для того же самого заказчика. Это раз. Второе, на что я хотел бы обратит внимание: клиент не приедет к разработчику, для того чтобы смотреть сертификаты.
Е. Ш.: В том-то все и дело.
М. Т.: Ну конечно, здесь есть определенный риск. Конечно, хотелось бы, чтобы заказчик удосужился и приехал к разработчику в компанию. Чтобы он понимал, что это не виртуальная студия, что это реальная студия или агентство. По телефону сказать можно что угодно. Коммерческое предложение можно написать откуда угодно и прислать его откуда угодно. А в реальности за этими «специалистами» никого и ничего нет.
Е. Ш.: Хорошо. Мы приезжаем в офис, стараемся познакомиться с сотрудниками, просим документы, подтверждающие бизнес-процессы и квалификацию сотрудников. Это является некоей гарантией того, что те сроки, о которых мы с тобой сегодня говорим, будут более или менее реальными.
М. Т.: Там, конечно, еще и портфолио.
Е. Ш.: Еще портфолио. Но мы немножко попозже об этом поговорим. Итак, когда мы калькулируем как разработчики тот или иной этап работы с сайтом, мы указываем часы, которые нам необходимы. Но у нас есть производственные процессы. Соответственно, мы не можем сразу, подписав договор, броситься работать с каким-то одним клиентом. Так или нет, Макс? Ты, подписав договор, сразу берешь 10, 18, 50 часов и занимаешься предпроектной работой, допустим, или дизайном сразу после получения аванса. Или ты встраиваешь клиента в некий производственный цикл и знаешь, что оплаченный сегодня договор пойдет в работу, допустим, на следующей неделе? Как построены эти процессы?
М. Т.: На самом деле, конечно, это не так. Безусловно, после согласования договора и оплаты со стороны заказчика нужно выстроить саму работу. У компании, в частности у нас, есть корпоративная система, где мы заводим проект, прописываем там все этапы, прописываем сроки. Дальше мы переходим к работе над документами, то есть проработке технического задания, на которую уйдет какое-то время. Неделя или полторы — это уже в зависимости от сложности проекта. И составляем план работ для заказчика.
Е. Ш.: Заказчик об этом знает?
М. Т.: Безусловно.
Е. Ш.: Корпоративная система отсылает некие уведомления, что сделано это, сделано то?
М. Т.: Да, расписывается план работ по этапам, например, то же самое техническое задание, дизайн, верстка, программирование, какие сроки, время на согласование. Все это предоставляется заказчику.
Е. Ш.: То есть стараетесь придерживаться этих дат, утвержденных у клиента. Хорошо, после того как мы поняли, что у нас тот же самый интернет-магазин займет полтора месяца, мы опять к нему возвращаемся. Давай посмотрим, кто виноват в том, что сроки срываются? На мой взгляд, есть три силы, которые срывают сроки разработки сайта. Первая сила — это объективная реальность. Это некие форс-мажорные обстоятельства, которые приводят к тому, что проект никак не заканчивается. Начиная с каких-то природных катаклизмов, заканчивая макроэкономическими процессами. Есть какие-то моменты, которые вносят неразбериху в сроки разработки сайта. И есть еще две большие силы — это сторона клиента и сторона разработчика. Как сделать так, чтобы та классно составленная смета со сроками по регламенту сертифицированной студии с бизнес-процессами действительно выполнялась? Были ли у тебя случаи, когда проекты не заканчивались по причине каких-то не зависящих ни от нас, ни от клиента обстоятельств?
М. Т.: Да, было такое, — даже не знаю, как это отнести к объективной реальности, — просто компания закрылась.
Е. Ш.: Наверное, да, по каким-то макроэкономическим показателям и т. д. А часто ли бывает такое, что клиент затягивает те утвержденные сроки, которые прописаны во всех документах?
М. Т.: Практически на каждом проекте так происходит.
Е. Ш.: Все клиенты всегда затягивают сроки и это они виноваты в том, что проекты заканчиваются не в срок?
М. Т.: Нет, зачем? Здесь нельзя говорить, что виноват только сам клиент. Палка о двух концах, как говорится.
Е. Ш.: Давай про клиента.
М. Т.: Если мы говорим про поводу клиентов, то обычно все процессы происходят виртуально. И в этом случае клиент не чувствует времени. Он потерян во времени: у него день, два, три могут пройти, он даже их не заметит, он посчитает, что это нормально. Но это, конечно, повлияет на сроки, потому что у разработчика есть определенный регламент, у него есть план работы, и он должен ему следовать. В этом случае нужно напоминать клиенту как минимум о том, чтобы он посмотрел, утвердил. Предварительно ему сбросили, грубо говоря, какой-то результат работы, он должен посмотреть в течение какого-то времени. И я порекомендовал бы: если первый раз клиент не ответил вовремя, можно на это не обращать внимания. Но, допустим, во второй, третий и последующие случаи, конечно, нужно с заказчика брать какую-то объяснительную. Даже не объяснительную, а элементарное подтверждение по электронке, что он принимает предыдущие результаты и постарается в течение такого-то времени следующий этап согласовать.
Е. Ш.: Документированная переписка с помощью специальных систем страхует.
М. Т.: Всегда можно будет поднять эту переписку и, соответственно, передать это клиенту, сказать: «Вы же сами говорили про эти сроки, вы их сами не соблюли».
Е. Ш.: Хорошо, Макс, а что делает твоя студия, если клиент вообще пропадает на какой-то достаточно длительный срок? Невозможно его найти ни по почте, ни по телефону. Это частенько бывает в нашей практике. И он, возвращаясь через два, три или четыре месяца или полгода, говорит: «Здравствуйте, вот он я, давайте продолжим работу над моим проектом. И вообще меня тут не было, а сроки указаны. Мы уже десять раз должны были это закончить». Как ты решаешь этот вопрос? Для нас это достаточно серьезная проблема: команда забыла, о чем был этот проект, она уже ушла в другие проекты, у меня есть какие-то другие технические вопросы. И чтобы вновь вспомнить про клиента, который пропал и очень сильно затянул сроки, требуется определенное время. А иногда ценообразование меняется. Как в этом случае решается вопрос у тебя?
М. Т.: У нас был один случай, когда заказчик пропал и появился через довольно-таки длительное время. И, соответственно, он попросил оперативно завершить проект. На что мы ему сказали, что мы продолжим работу по вашему проекту только после завершения предыдущих проектов. Дали ему понять, что регламент нарушен, соответственно, он не выполнил свои обязательства, а теперь у нас есть другие приоритеты. После выполнения тех или иных работ мы продолжим работу над его проектом.
Е. Ш.: Понятно. Разговоры, переговоры и т. д. Дорогие клиенты, посмотрите, пожалуйста, на список узких мест в коммуникациях со стороны клиента. Это оформление различных документов, прием работ, согласование дизайна, наполнение сайта. Что бы мы ни делали, какие бы мы хорошие или не очень были, если вы со своей стороны затягиваете сроки, проект рискует не закончиться. Если клиент, например, затянул утверждение дизайна, предоставление определенной информации на энное количество дней, я как разработчик имею право увеличить срок разработки на это самое количество дней. Ты такое практикуешь?
М. Т.: Безусловно, у нас в договоре это прописано.
Е. Ш.: И это написано в договоре. Как к этому относятся клиенты?
М. Т.: В основном с пониманием.
Е. Ш.: Тебе повезло.
М. Т.: Только в том случае, если, конечно, проекты не сильно срываются по срокам. Опять же, здесь, как я говорил, палка о двух концах. Есть причина, по которой заказчик затянул, или тот же самый разработчик…
Е. Ш.: Нет, сейчас именно о клиенте. Мне очень хочется, чтобы клиенты тоже понимали, что это совместная работа, что если я пропал, уехал в отпуск, у меня что-то случилось, то нужно сообщить об этом разработчику. И тогда можно искать какие-то компромиссные решения по срокам. Друзья, не затягивайте с ответами на письма разработчиков.
М. Т.: Как минимум нужно все-таки выстраивать диалог и предупреждать разработчика о том, что вы уезжаете или, к примеру, у вас возникли какие-то обстоятельства, которые могут повлиять на сроки.
Е. Ш.: Изменение контактных лиц и т. д. Теперь давай поговорим о том, почему мы, разработчики, затягиваем сроки. Студии, как правило, являются небольшими компаниями. Кто-то ушел в отпуск, кто-то заболел, кто-то плохо отработал. Мы с тобой как руководители должны понимать, что не всегда виноват клиент и часто виноват разработчик. Как клиенту застраховаться от затягивания сроков разработчиком? У меня есть одно такое предположение, но я хочу сначала тебя услышать.
М. Т.: Вернусь к предпроектным работам. Я хотел бы, чтобы каждый заказчик понимал, что составление правильной технической документации по проекту — это очень ответственный этап.
Е. Ш.: Это не гарантирует. Ты можешь составить классную документацию.
М. Т.: Я поясню. Дело не в этом. Дело в том, что проблема, как правило, из-за чего возникает у разработчика? Когда клиент начинает что-то просить в процессе.
Е. Ш.: Так.
М. Т.: По дизайну или уже даже в программировании. Но при этом он не задумывается о том, что проект из-за этого может дольше выполняться. А если это переписывание какого-то модуля, которое может неделю занять? А заказчик хочет получить проект в срок. В этом случае, если техническая документация соответствует дизайну, а дизайн соответствует программированию, и заказчик, к примеру, решил внести какие-то изменения, нужно составлять дополнительное соглашение с новыми сроками.
Е. Ш.: И относиться к этому нормально, да?
М. Т.: Конечно.
Е. Ш.: Не впихивать эти новые изменения в существующие сроки?
М. Т.: Конечно, это уже нереально. Как правило, это уже срыв в любом случае. Если, конечно, разработчик не заложил определенный запас по времени, что позволит ему уложиться в старые сроки.
Е. Ш.: Понятно, хорошо. Тем не менее я предлагаю клиентам прежде всего не стесняться звонить, спрашивать, как обстоят дела с проектом. Потому что есть чисто субъективный эмоциональный человеческий фактор. К тому клиенту, который больше себя проявляет, больше внимания. У вас так?
М. Т.: В принципе, так.
Е. Ш.: К тому человеку, который проявляет к вам больше внимания, вы тоже проявляете больше внимания. Со стороны разработчика та же самая история. Но если разработчик совершенно плохо себя ведет, то вплоть до расторжения договора может дойти. В этом случае, мне кажется, страховкой для клиента является поэтапная оплата и поэтапная приемка работ. В этом случае на любом этапе клиент может перейти от одного разработчика к другому, и, собственно говоря, другой разработчик может подхватить работу коллеги. И теперь вопрос, Макс: как проверить, что та или иная компания в состоянии сделать сайт в указанный срок?
М. Т.: Нужно обращать внимание на историю студии или агентства. Какое у нее портфолио, какого уровня проекты они выполняли, какие отзывы? Отзывы тоже имеют какое-то значение. Последнее время в нашу студию часто через отзывы приходят. Если есть положительные отзывы, то, соответственно, есть какое-то доверие. Безусловно, если есть какие-то подтверждающие сертификаты, которые говорят о том, что компания или студия работает по каким-то стандартам или регламентам, то это тоже имеет значение. Квалификация сотрудников.
Е. Ш.: Да, мы уже говорили. А что-то еще можешь добавить к квалификации, к регламенту, к бизнес-процессам?
М. Т.: Чтобы люди были на своих местах.
Е. Ш.: Чтобы они вообще существовали?
М. Т.: Чтобы они были. Потому что часто такое бывает, что разработчик передает проект на фриланс.
Е. Ш.: О’кей, и это нехорошо.
М. Т.: И это нехорошо. Чтобы минимизировать риски, клиент должен хотя бы поинтересоваться, — если он понимает, конечно, как вообще эта работа строится, — будут ли выполнять эти проекты именно здесь, «вживую».
Е. Ш.: Итак, подведем итоги. Сколько же нужно времени на то, чтобы разработать сайт? Каждый разработчик, который достаточно времени проработал на рынке, знает, сколько ему потребуется времени на разработку того или иного сайта на известной ему системе администрирования. Если это требуется какой-то сверхъестественный функционал, помогает хорошее предпроектное проектирование и учет всех нюансов, которые могут быть в разработке. Для того чтобы клиент мог подстраховаться на предмет того, сколько нужно времени на разработку, нужно присматриваться к разработчику. Стоит разослать предложение по нескольким студиям и выяснить, кто сколько времени просит на ту или иную разработку. Но на каждый стандартный проект уходит определенное стандартное время. Как и во всех других историях, связанных с разработкой, все дело в профессионализме людей. Можно ли что-нибудь тут добавить и дать последний совет нашим зрителям?
М. Т.: Я хотел бы добавить, что можно воспользоваться такими услугами страхования проектов, которые недавно появились на рынке. Подобного рода услугу предоставляет Ассоциация интернет-разработчиков.
Е. Ш.: Особенно для сложных проектов.
М. Т.: Безусловно.
Е. Ш.: Хорошо. Итак, смотрите на разработчика, используйте документацию и доверяйте тем людям, с которыми вы работаете. Это залог успеха разработки сайта в те сроки, которые указаны в договоре. Спасибо большое! Спасибо большое моему гостю Максиму Трегубу! И до следующих встреч!
М. Т.: До свидания!