Главное Свежее Вакансии Образование
4 591 15 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Как заказать сайт и не пустить деньги на ветер

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

Раньше наша команда и наши клиенты были очень грустными людьми. Мы срывали сроки, а клиенты были недовольны качеством. В результате никто не зарабатывал денег, и все срывались друг на друга.

1AoQ-4XO4Jg.jpg

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

Мать Тереза в своё время говорила: "Чтобы сохранить счастье, им надо делиться". Следуя заветам великого человека, мы делимся найденной формулой с сообществом.

blB6laejQYE.jpg

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

Что делать, если Исполнители, которым вы заказали сайт, «залажали» проект?

Для начала определимся — что такое успешный проект? Это проект, который в течение планового срока как минимум окупил затраты на него. Все. Включая аренду хостинга и зарплату вашего менеджера, который наполняет сайт.

AgwaTQE0RLI.jpg

Итак: Если вы не можете посчитать доход от проекта или сумму затрат, или если проект не окупается, поздравляем, вам его «залажали».

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

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

Это важно: Чтобы гарантированно получить нужный результат вы должны профессионально заказать сайт.

Что нужно сделать, чтобы профессионально заказать сайт?

wUFtv43eCEg.jpg

1. Прекратите считать что сайт делается для вас.

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

2. Хорошо, очень хорошо представьте вашего клиента.

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

3. Прекратите считать программистов умными.

Без шуток. Каждый человек умен в рамках своей компетенции. Я хорошо программирую на PHP, но когда надо побелить стены — дурак дураком. Объясняйте свой бизнес, свою задачу, схему работы, свою специфику. У вас не спрашивают? Всё равно объясняйте. Отказываются слушать? Приходите в офис компании и убивайте по одному программисту, пока менеджер вас не выслушает.

4. Запомните: программирование — всего лишь 30% от работы над проектом.

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

5. ТЗ без маркетингового анализа, прототипов ВСЕХ интерфейсов, SEO-отчета и подробного, конкретного, недвусмысленного описания каждой функции действительно просто бумажка.

Можете её выкинуть. Почему? Смотрите предыдущий пункт. Более того, вам необходимо смириться со следующими фактами:

  • Нет, вы не можете сами составить маркетинговый анализ. Даже если вы 20 лет работали маркетологом в «Эльдорадо». У веба своя специфика, вы должны иметь опыт именно в этой сфере.
  • Нет, вы не можете сами создать прототипы интерфейсов. Хотя бы потому что это групповая работа. В которой обязательно участвуют: технический специалист, дизайнер, менеджер, маркетолог, сео-специалист. Если у вас в группе нет, к примеру, технического специалиста, то вы рискуете разработать интерфейс, реализация которого будет требовать несоразмерно больших денег и усилий.
  • Нет, вы не можете составить сами SEO-отчет. Впрочем, в этом обычно большинство клиентов не сомневается.
  • И наконец: нет, вы не можете сами написать ТЗ. Потому что подробное описание для вас, для программиста и для суда (в случае критической ситуации) — это три большие разницы. Короче, прекращайте искать дурные, не работающие способы удешевления проекта и займитесь чем-нибудь полезным.

6. Внимательно вычитывайте присылаемую документацию и несите ответственность за ключевые решения.

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

Где же счастье?

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

lFJPr8fLZMQ.jpg

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

Успехов вам и вашим проектам!

С уважением, команда «Самани».

+14
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Павел Катшани
Хм... Блин, что сказать... Спасибо за инфу!)
Ответить
Евгений 12597
По мне я так и не увидел как деньги на ветер не пустить если учесть что в начале статьи идет конфликт и срывы сроков. То есть я ожидал увидеть ответ как не допустить такой ситуации. А это рассказ кому заказывать сайт и что в нем должно быть.
Ответить
S.A.M.A.N.Y.
Разработка интернет-проектов
Максим Жданов
Евгений, для того, чтобы сформулировать Вам правильный ответ, мне нужно понять кем Вы являетесь — Заказчиком или Исполнителем?
Ответить
AXIOMA 9591
ну если представить, что вы живете в мире, где ни до agile, ни до scrum еще не додумались — то ваш подход действительно имеет смысл :)
Ответить
NDB
NDB — информационный digital ресурс
Николай Авраменко
Здравствуйте.

Прошу прощения. Не очень понятен ваш комментарий.

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

В любом случае, очень интересно услышать более конкретизированное мнение или вопрос. Я лишь подмечу еще раз, что статья эта написана для роли "Заказчик" и содержит в себе информацию, как следует из ее названия, о том "Как заказать сайт и не пустить деньги на ветер".
Ответить
AXIOMA 9591
Мы, видимо, несколько дольше вас работаем на рынке и уже прошли стадию восторгов детальным ТЗ. Следующий шаг — это гибкие методологии разработки. Потому что как вы ни напишете ТЗ, каким бы детальным оно ни было, в результате клиент получит не то, что он хотел. Просто потому, что:
а) за время разработки у него родилось 15 новых блестящих идей;
б) он забыл, что было в ТЗ;
в) он не так понял половину ваших формулировок, хоть и подписался под ними;
г) он неспециалист в IT и не может по тексту и прототипам достаточно четко представить себе, как работает законченный продукт.
Поэтому работать с клиентом нужно с максимальным его вовлечением в процесс, короткими итерациями и с прозрачным и гибким механизмом внесения любых изменений на любом этапе разработки.
Это не отменяет методологию водопада, которую вы описали, но не надо ее преподносить как единственную и наиболее эффективную схему работы.
В этом был смысл моего краткого комментария.
Ответить
S.A.M.A.N.Y.
Разработка интернет-проектов
Максим Жданов
К сожалению, не знаю, как вас зовут, но никак не могу согласиться с вашим утверждением: "Потому что как вы ни напишете ТЗ, каким бы детальным оно ни было, в результате клиент получит не то, что он хотел".

Потому что:

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

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

в) Ребят, но так для этого существует раздел "Определение" в ТЗ и язык у вашего менеджера.

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

Также замечу, что в статье не говорилось о единственно правильном методе. Это Spark — и здесь каждый рассказывает о своем опыте.
Ответить
AXIOMA 9591
Зовут меня Константин, я CEO студии AXIOMA ( http://www.axiomadev.ru/kompaniya/ )

Ваши ответы — это отличное, эффективное жопоприкрывание, и клиент не сможет вас обвинить в невыполнении ваших обязательств. Но результатом он будет недоволен. Потому что за его кучу денег он не получил того удовольствия и продукта, который хочет на данный момент (прямо сейчас и в том виде, как он его представляет в голове, а не полгода назад в черно-белых макетах и на простыне описания). Поработайте года три по такой модели, и после сквозь кровавые слезы всмотритесь в модели гибкой разработки. :) Они тоже не панацея, но если удается убедить клиента работать по такой модели — это значительно лучший и клиентский сервис, и результат, приближенный к желаемому клиентом.
Ответить
S.A.M.A.N.Y.
Разработка интернет-проектов
Максим Жданов
Вовсе нет. Вы как-то однобоко рассматриваете коммуникацию с клиентом, я бы сказал, субъективно.
Такое впечатление у нас создалось, потому что мы как раз ни слова в статье не говорим ни о скраме, ни о водопаде. Этап утверждения чего либо присутствуют в любой методологии. Вы же спишите обвинить нас в "недоразвитости".

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

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

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

Если вы желаете продолжить бессмысленный диалог о тех или других методиках работы — прошу выбрать другое место. Так как статья не об этом, а о том как клиенту правильно отнестись к проекту и совершить заказ. А какой метод работы избрала для себя компания — дело другое.
Ответить
Андрей Гуртовой
работаю фронтендером в стартапе где начальник занимается всем(в частности составляет тз, рисует макеты, оценивает работу программистов…)
Ну что сказать…. Был у нас В самом начале дизайнер. Очень талантливый и грамотный. Отрисовал все интерфейсы и его уволили.
По приказу начальника мы начали верстать макеты. Потом начальнику макеты разонравились, и он начал вносить в них правки, и просить "немного доработать". Потом ещё немного, и цвета кнопок сделать не белыми а чёрными с желтоватым отливом….

В итоге переделывали сайт с нуля около 3х раз…. Сейчас верстаем четвёртый раз, но уже в роли аутсорсеров, ибо "кончилось финансирование".

Макеты не очень сложные, но с респонсивом от 1440 до 320 пикселей. И когда у фронтендеров работа уже выполнена начальнику снова разонравливается, то что он в фотошопе делал, и вновь просит внести правки…. Тяжко и на ветер выброшенные деньги. Если ещё учесть что экранов в проекте 26.

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

Вот так и выбрасываются деньги на ветер по не-опыту.

во многих местах поработал. Но такой бардак встречаю второй раз в жизни.

обычно делается так:
мокап от дизайнера согласовывается с заказчиком.
делается кликабельный макет.
По мокапу рисуется дизайн-макет. После того как дизайн + кликабельный макет устраивает заказчика начинают работать верстальщики… И ЛУЧШЕ ИМ НА ЭТОМ ЭТАПЕ НЕ МЕШАТЬ! -- велик шанс получить какаху, даже если верстают хорошие специалисты
Ответить
S.A.M.A.N.Y.
Разработка интернет-проектов
Максим Жданов
Интересная компания… Надеюсь, что Ваше положение в ближайшее время изменится.
Безусловно Вашему директору пригодится прочитать помимо этой статьи еще одну, которую мы готовим специально для небольших веб-студий, подписывайтесь, мы скоро выложим ее на Спарк.

Обычно делается так — здесь у меня есть небольшие правки:
1. Разрабатывается и утверждается ТЗ.
2. Разрабатывается технический проект, утверждается с заказчиком.
3. Разрабатывается дизайн-макет, утверждается с Заказчиком.
4. Производится верстка дизайн-макета, демонстрируется Заказчику.
5. Осуществляется интеграция.
6. Проводится индивидуальное тестирование менеджером проекта.
7. Проводится массовое тестирование.
8. Проект дорабатывается и утверждается с Заказчиком.

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

По поводу не мешать верстальщикам, с Вами полностью согласен!
Очень важно помогать друг другу.
Ответить
S.A.M.A.N.Y.
Разработка интернет-проектов
Максим Жданов
Андрей, советую Вам и Вашему начальству данную статью http://spark.ru/startup/samany/blog/6117
Ответить
InnMind
Деловая сеть для стартапов и инвесторов
Екатерина Воронова
Спасибо! Интересный материал! То есть, перед тем, как бежать к разработчикам со своей идеей, нужно "пообщаться" с еще кучей специалистов,я верно все поняла?
Ответить
S.A.M.A.N.Y.
Разработка интернет-проектов
Максим Жданов
День добрый, Екатерина. Ответ: да.
Ответить
Айрат Кадырмаев
Опять же как-то все в общих чертах написано) Да конечно надо все тестировать, брать специалистов! но как быть если нет такого большого бюджета на все это)

есть например тысяч 100 на все - разработка, дизайн) но есть например идея по сайту или сервису. И тысяч 100 на продвижение.
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.