Archive for Документы

Студийные истории #8. Делим деньги коммерческого предложения.

В этой статье речь пойдет о том, как делить деньги в коммерческом предложении (КП). По сути это ответ на вопрос: если в КП указана цена конкретно за дизайн/верстку/программирование, то стоит ли столько же (пропорционально) отдать работникам?

Допустим, у нас есть коммерческое предложение на более или менее среднестатистический сайт в вакууме с ценами:

  • техническое задание – бесплатно разрабатывается для каждого проекта;
  • дизайн (~5 шаблонов страниц) – $500;
  • верстка – $170;
  • программирование – $1000;
  • базовое наполнение – бесплатно в рамках тестирования сайта.

Сумма: $1670

Почему за дизайн $500, а за программирование $1000? Несомненно, есть проекты, где это 100% обосновано сложностью кода и легкостью дизайна. Но я часто встречал случаи, когда клиенты говорили: «Ой. А в другой студии нам предлагают дизайн за $500. А работы такие же красивые как у Вас. Да и вообще нарисовать это не очень сложно», – и клиенты уходили. Некоторые таким же образом приходили к нам. Фокус в том, что большинство людей, не разбирающихся в технологиях создания сайтов, думают, что дизайн в разы легче, чем программирование. К тому же рассказать, почему программирование сложнее проще. Проще продать.
Вопрос второй: почему верстка $170? Это же практически чистая себестоимость? А как же прибыль? А как же % продажникам? А как же издержки и прочее?
Вопрос третий: руководитель проекта и контент-менеджер работают бесплатно?

Становится ясно, что сумма проекта распределяется между участниками иначе. Не так, как она отображена в КП. Но как?

Наша команда:

  • менеджер по продажам;
  • руководитель проектов;
  • дизайнер;
  • верстальщик;
  • программист;
  • контент-менеджер.

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

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

Часть разделения денег, которое я знаю и от которого не отступаю:

  • 20-40% руководителю проекта. 40% – обычно берется на маленьких проектах, т.к. время, потраченное на переговоры достаточно велико, а сумма заказа маленькая. К тому же клиент может потребовать какого-то изощренного способа коммуникации, например: менеджер, всегда должен приезжать к клиенту на встречу лично, и никаких телефонов. (Да, бывают извращенцы, и если Вы сейчас на мели, то приходиться работать с кем есть). В эти проценты входят и риски, т.к. ими распоряжается исключительно руководитель проекта.
  • 25% – строго на тестирование, отладку и базовое наполнение. Почему четверть? Да, просто потому, что все допускают ошибки – это раз. Во-вторых, когда клиент видит почти готовый продукт, ему обычно хочется что-то изменить. Можно попытаться брать за каждую мелочь деньги. Так можно прослыть крохобором или вообще поссорится с клиентом.
  • остальные деньги распределите сами исходя из издержек фирмы, уровня з/п специалистов, скорости работы специалистов, трудности какой-то конкретной задачи и т.д. Помните, что 25% тестирования – это не только работа тестировщика (или кто там выполняет его роль), а еще и работа программиста по исправлению багов и т.д. Очень хорошо получается распределять деньги, когда есть диаграмма Ганта, трудозатраты по часам и хороший архив проектов, где можно посмотреть как это уже было. MSProject вообще делает красивые отчеты по деньгам.

По некоторым предыдущим проектам разделение такое (от суммы очищенной от налогов и издержек):

  • 10% – менеджер по продажам;
  • 20% – руководитель проектов;
  • 25% – дизайнер;
  • 10% – верстальщик;
  • 20% – программист;
  • 5% – контент-менеджер;
  • 10% – риски.

* – Проекты небольшие, в основном все стандартно, есть шаблоны ТЗ, есть CMS, только дизайнер рисует всегда всё с нуля.

25% – тестирования, заложено в руководителя проекта, верстальщик, программиста, совсем чуть-чуть контент-менеджера.

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

Пару советов:

  • персонал никогда не должен видеть коммерческого предложения, точнее сметы. Это обусловлено тем, что персонал сразу думает, что все деньги по его работе будут ему. Можно объяснить, что там налоги, издержки и т.д., но мысль «за мою работу берут $1000, а я с нее получаю $300″, – совсем не греет. Иногда это служит причиной ухода на фриланс (мне жаль людей, которые ушли именно и только по этой причине). Так же персонал видя сумму, сразу может рассчитать время, которое ему должно быть выделено. Как показывает опыт, время всегда надо выделять ровно столько сколько надо, а денег брать больше – это наши «рИсковые» деньги. Сотрудник же понимая, что у него в запасе есть еще пару дней… Все знают, что бывает в таких случаях обычно.
  • клиенту лучше не знать, что в КП заложены риски. Даже если клиент закладывает риски в своих КП, то все равно большого желания платить он не испытвает. Я встречал клиентов, которые при слове «риски» пугались и уходили, и таких, что обсуждали, какие риски могут быть и как их уменьшить.

Студийные истории #7. Коммерческое предложение на разработку сайта.

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

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

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

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

Лирическое отступление.
Всегда удивлял, удивляет и будет уделять, тот факт, что когда спрашиваешь у клиента ориентировочный бюджет, то 99% морозятся. Да, это именно то слово, ибо по другому невнятный ответ о том, что еще неизвестна сумма, назвать нельзя. А вот когда даешь в руки коммерческое предложение, то сразу же взгляд на сумму, а на лице вопрос: «Хватит ли денег?».
Почему удивляет? Потому что если я хочу купить ноутбук за $1000, то я выберу ноутбук максимальной конфигурации именно на эту сумму, а не буду радоваться, что на рынке есть унылое гавно что-то проще за $500. Так почему же не заказать сайт максимально классный в рамках бюджета?

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

Меня очень удивило то, что наша таблица с работами в коммерческом предложении состояла из 3 частей:

  • работы по дизайну: дизайн страниц, дизайнерская обработка материалов, баннера, флеш-элементы, etc;
  • работы по программированию интерфейсной части для пользователя;
  • работы по программированию админ-части.

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

Я видел два больших недостатка:

  1. Разделение интерфейсной части и админ-части. Сегодня одно без другого уже не бывает (или нет?).
  2. В коммерческом предложении не было раздела «верстка». Работа есть, деньги за нее берут, но она размазана по разделу программирования. Это плохо, т.к. если верстает фрилансер, то проект надо разбивать на зарплату каждому и долю студии.

Таким образом я внес два важных изменения и маловажное:

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

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

Одна студия описала в коммерческом все работы и дополнительно, что и как будет происходить на этих работах. Идея мне очень понравилась, т.к. это делает для клиента Вашу работу прозрачнее, а значит доверия больше. Но вот само описание было более «разработчику от разработчика», чем «клиенту от исполнителя».

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

На мой взгляд, основные цели коммерческого предложения такие (в порядке важности):

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

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

Студийные истории #6. Хорошим верстальщикам ТЗ не обязательно.

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

Почему так? Рассмотрим небольшой сайт визитка на 3 макета: главная страница (она же текстовая/информационная), каталог страниц (что бы отобразить вложенность разделов), и какая-то страница с формой обратной связи и картой от Яндекс.Карты. Дизайнер отдал Вам (менеджеру) все три макета в PSD… все как положено.

Вопрос: что объяснять верстальщику?
Увидеть где и какие элементы будут ссылками совершенно не есть проблема – логика у всех работает (должна по крайней мере!!!). Должен ли сайт «тянутся»? Тут тоже все понятно: нормальные дизайнеры, если сайт фиксированной ширины, рисуют фоновые поля. Рассказывать верстальщику как должны меняться ссылки при наведении? А вот и нет! Это задача дизайнера показать все выделения и все варианты отображения. Можно попробовать рассказать о том, что нужно оставлять комментарии в коде, но это и так должно быть понятно: отсутствие комментариев не комильфо. Так же хороший верстальщик сам знает, что названия страниц надо делать h1, и как правильно дальше использовать h2,h3 и т.д. Хороший верстальщик знает, что поисковик читает страницу сверху вниз, ровно так как это написано в html-коде, а не так как это видит пользователь, потому более важные элементы выносятся выше по коду и т.д. О W3C я вообще молчу.

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

Техническое задание

Техническое задание - в поисках истины

Было недавно очень много споров вокруг технического задания. Все судили о ТЗ со своей стороны. Я попытался собрать это все в одну лирическую статью.

Что такое техническое задание?

Cогласно Wiki:

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

Cогласно Яндекс.Словари определение более широкое (первая часть с Wiki повторяется один в один):

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

Есть определения ТЗ, которыми все пользуются. Оспаривать определения глупо и бессмысленно: «Об определениях не спорят, о них договариваются»(с).

В этой статье я хочу отойти от определений и приблизиться к реальности разработки сайтов.

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

«Кому надо техническое задание?» – вопрос достаточно сложный. На абзац Выше я написал, что это документ, а значит, он нужен как заказчику, так и исполнителю. Давайте детальнее.

Зачем техническое задание менеджеру? В нем менеджер проекта излагает все касательно разрабатываемого продукта. Это делается из следующих соображений:

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

Обязательно ТЗ надо разработчикам, т.е. дизайнеру, верстальщику, программисту и т.д. Надо оно им только из одного соображения: перед тем как делать, надо четко понимать, что ты делаешь и, что должно быть в результате. Согласно методологии постановки целей S.M.A.R.T, цель должна быть измерима. А это в основном цифры. Вот в техническом задании эти цифры и прописываются. Т.е. если клиент сказал, что «сайт должен загружаться быстро», то в ТЗ это описывается примерно так: «Размер страницы без графики, загруженной пользователем, должен составлять не более 50Kb».

Остается только один вопрос: надо ли техзадание клиенту? Я считаю, что в большинстве случаев – не надо! Техническое задание отдавать клиенту разумно в том случае, если клиент может разобраться в нем. А если контактным лицом со стороны клиента является «девочка-маркетолог», то некоторые разделы она вообще не сможет понять как таковые. В результате Вы, конечно, подпишите с клиентом такое ТЗ, но это будет субъективный документ. С другой стороны клиенты разные и если не зажимать их в рамки технического задания, то они будут пить кровь очень долго и мучительно. Тут выбор за Вами.

Что должно быть в техническом задании?

В последнее время часто слышу вопросы: «Техническое задание одно на всех, или по одному на каждого?». На практике я писал и одно на всех и по одному на каждого. Это было что-то вроде эксперимента. Изначально у меня был вопрос: «А как разные люди могут создать что-то одно, опираясь на разные цели/задачи?». Оказалось, что могут.

«Одно ТЗ на всех». Я остался сторонником именно этого подхода. В одном документе описывается, как Сайт должен работать, выглядеть и т.д. Каждый разработчик должен полностью ознакомиться с документом, что бы понимать полную картину. Часто бывает, что ошибки командные, а не чьи-то конкретные, потому и необходимо, что бы команда знала всю картину и не допускала подобные ошибки. Как пример: «Размер страницы без графики, загруженной пользователем, должен составлять не более 50Kb» – этот критерий можно отнести как к дизайнеру, так и к верстальщику. Если в результате страница весит 70К, то дизайнер с верстальщиком могут очень долго играть Вами в футбол.

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

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

Идеальное техническое задание – миф или реальность?

Нельзя линейкой измерить идеальность. Должны быть критерии. Пока критериев нет – это провокационный вопрос.

Техническое задание и другие документы.

Наряду с техническим заданием обычно подписываются и другие документы. Однозначно подписывается договор. Возможно, подписывается календарный план, который согласно ГОСТ 19.201-78 уже, в каком-то виде, есть в ТЗ и описывается в разделах: стадии и этапы разработки, порядок контроля и приемки. Осталось добавить даты и все.

Часто в техзадании описывается концепция проекта и многие другие – НЕНУЖНЫЕ – вещи. Концепция проекта имеет совершенно другое назначение и потому не стоит включать концепцию в техническое задание. О том, что такое концепция и чем она отличается от ТЗ можно узнать из замечательного топика на Хабре.

Техническое задание на создание дизайна интернет-магазина

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

Сейчас магазин находится на стадии «перед дизайн». А значит необходимо писать техническое задание на дизайн.

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

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

Собственно, что такое техническое задание?

Согласно Wiki, техническое задание – это исходный документ для разработки информационных систем.

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

На сегодняшний день часто можно услышать вопрос: «какое оно идеальное ТЗ? и где можно взглянуть на образец?».
Я склонен считать, что идеального технического задание не существует. Это крайне индивидуально для каждого проекта. А так же это крайне индивидуально от студии к студии, от менеджера к менеджеру.

Основная проблема в том, как правильно делать техническое задание?

Есть некие стандарты на технические задания.
Более подробно можно посмотреть тут:
http://www.nist.ru/hr/doc/gost/19201-78.htm
http://www.nist.ru/hr/doc/gost/34-602-89.htm

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

Три методоа работы:

Я знаю о трех методах работы. В некотором виде это эволюционная цепочка.

1. Техническое задание не пишется вообще. Клиент рассказывает на словах чего надо. Менеджер передает на словах/e-mail/ICQ непосредственному исполнителю. Клиент получает результат.

Позитив:

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

Негатив:

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

2. Техническое задание не составляется в явном виде документа (либо носит форму брифа и не содержит всех деталей). Клиент заполняет бриф, менеджер проводит «допрос» и делает заметки. Этот материал и устные дополнения уходят непосредственному исполнителю. Клиент получает результат.

Позитив:

  • наличие команды становится менее важно;
  • вероятность получить то, что хотели, возрастает.

Негатив:

  • возрастает цена, т.к. менеджер тратит на Вас больше времени, делая записи;
  • в ходе исполнения, менеджер всегда может отказаться от изменения чего-то, что в брифе написано Вашей рукой;
  • в мелочах Вы можете проиграть, т.к. доказать говорили Вы это или нет – невозможно, есть только бриф. Максимум будет набросок на бумаге. Клиенту: храните у себя копии всех бумажных документов/записок/приписок/набросков и т.д.

3. Техническое задание составляется в полном объеме и является документом, на котором ставится печать.

Позитив:

  • Вы четко представляете все: что будет в конце, сроки, качество, документация и т.д.;
  • Вы получите ровно то, что хотели!

Негатив:

  • это дорого стоит;
  • это занимает больше времени;
  • это скучно и под конец начинает надоедать.

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

Выкладываю техническое задание на создание дизайна Интернет магазина. Думаю, многим будет интересно. Критику и замечания пишите в комментарии. Дизайны шлите в почту. :)

Скачать «Техническое задание на создание дизайна интернет магазина»

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