Когда мне предложили данную тему для написания своих мыслей в виде статьи, я долго думал, о чем же написать, потому что, по сути, вся данная статья укладывается в одно предложение, которое является прямым ответом на данный вопрос — Все документы должны быть прописаны и никаких моментов не должно быть в уме. Почему именно так? Рассмотрим по пунктам:
1. Обычно то, что вы держите в уме, никогда не совпадает с тем, что держит в уме заказчик. В таких случаях возникает момент, когда Заказчик говорит, что он предполагал работа/вид/дизайн не такой, что вы сделали и, к сожалению, не поспоришь с этим, так как нет никакой документации, которая подтвердит Ваши слова. И начинается бесконечный этап переделок, пока клиент не наиграется, либо не получит продукт, который по его мнению идеален. При этом вы выходите за рамки бюджета, и проект в целом становится не то что не прибыльным, а убыточным.
2. Проект – «вещь» живая и, само собой, во время его выполнения, возникнут новые веяния и цели/задачи, которые клиент захочет сразу же реализовать. Опять же, если не прописаны все данные вещи в задании, то вы будете много работать, а самые главное – бесплатно. Ведь если вы откажете, то клиент откажется платить даже за ту работу, которая уже сделана и в такой момент все делается, чтобы получить «хоть что-нибудь». При этом имея грамотное задание, вы можете не только отказать, но и мотивировать клиента на дополнительные оплачиваемые работы.
Рассмотрим, на примере компании РБК СОФТ, что и в каком формате нужно описывать в техническом задании.
Наша компания разрабатывает проекты на собственной CMS, и практически весь типовой функционал уже реализован в стандартных модулях. Все данные модули имеют техническое описание функционала модуля. И для разработки типовых проектов, нет смысла писать все с нуля. Поэтому, вместе с клиентом при обсуждении проекта, сразу определяется весь функционал будущего проекта, выбираются нужные модули и их описание сводится в техническое задание. При нестандартном функционале, тщательно описывается новый функционал в формате данного документы. Далее, готовы документ согласовывается с клиентом, подписывается и является неотъемлемой частью договора.
Далее вводится новый документ – Художественное задание описывающий всю структуру и художественную составляющую проекта. После 2-3 часового брифинга клиента, аналитик и арт-директор разрабатывают данный документ, где описывают структуру, визуальные блоки, фирменные цвета, цепочки следования пользователя, портреты целевой аудитории, цели и бизнес задачи проекта. Опять же, данный документ согласовывается с клиентом и подписывается. На основе художественного задания разрабатывается дизайн будущего проекта и клиент в 99% случаев принимает работу, так как при презентации у него не возникает вопрос, почему именно так, а не по-другому. Все согласовано и описано в художественном задании и при желании что-либо изменить, задайте вопрос: «Зачем? Что изменит данная правка в предложенном решении бизнес задачи, которая была сформулирована в задании?». Не имея похожего документа, можно впасть в этап «двигания» картинок и «увеличения» логотипа, который может продлиться до бесконечности и в итоге родится мертворожденный проект, не решающий ни одной задачи с точки зрения бизнеса, а, как известно, любой коммерческий проект призван решать бизнес-задачи.
И так, еще раз подведем итог, в документации, описывающей задание (это должно быть не только техническое задание), должно содержаться максимально полное описание всех граней проекта, от функционала до внешнего вида и бизнес задач, иначе вы рискуете получить мертворожденный
Напоследок, правило работы с клиентом: Больше бумаги – чище попа!
Игитян Тачат,
Директор направления интерактивных коммуникаций,
РБК СОФТ
1. Обычно то, что вы держите в уме, никогда не совпадает с тем, что держит в уме заказчик. В таких случаях возникает момент, когда Заказчик говорит, что он предполагал работа/вид/дизайн не такой, что вы сделали и, к сожалению, не поспоришь с этим, так как нет никакой документации, которая подтвердит Ваши слова. И начинается бесконечный этап переделок, пока клиент не наиграется, либо не получит продукт, который по его мнению идеален. При этом вы выходите за рамки бюджета, и проект в целом становится не то что не прибыльным, а убыточным.
2. Проект – «вещь» живая и, само собой, во время его выполнения, возникнут новые веяния и цели/задачи, которые клиент захочет сразу же реализовать. Опять же, если не прописаны все данные вещи в задании, то вы будете много работать, а самые главное – бесплатно. Ведь если вы откажете, то клиент откажется платить даже за ту работу, которая уже сделана и в такой момент все делается, чтобы получить «хоть что-нибудь». При этом имея грамотное задание, вы можете не только отказать, но и мотивировать клиента на дополнительные оплачиваемые работы.
Рассмотрим, на примере компании РБК СОФТ, что и в каком формате нужно описывать в техническом задании.
Наша компания разрабатывает проекты на собственной CMS, и практически весь типовой функционал уже реализован в стандартных модулях. Все данные модули имеют техническое описание функционала модуля. И для разработки типовых проектов, нет смысла писать все с нуля. Поэтому, вместе с клиентом при обсуждении проекта, сразу определяется весь функционал будущего проекта, выбираются нужные модули и их описание сводится в техническое задание. При нестандартном функционале, тщательно описывается новый функционал в формате данного документы. Далее, готовы документ согласовывается с клиентом, подписывается и является неотъемлемой частью договора.
Далее вводится новый документ – Художественное задание описывающий всю структуру и художественную составляющую проекта. После 2-3 часового брифинга клиента, аналитик и арт-директор разрабатывают данный документ, где описывают структуру, визуальные блоки, фирменные цвета, цепочки следования пользователя, портреты целевой аудитории, цели и бизнес задачи проекта. Опять же, данный документ согласовывается с клиентом и подписывается. На основе художественного задания разрабатывается дизайн будущего проекта и клиент в 99% случаев принимает работу, так как при презентации у него не возникает вопрос, почему именно так, а не по-другому. Все согласовано и описано в художественном задании и при желании что-либо изменить, задайте вопрос: «Зачем? Что изменит данная правка в предложенном решении бизнес задачи, которая была сформулирована в задании?». Не имея похожего документа, можно впасть в этап «двигания» картинок и «увеличения» логотипа, который может продлиться до бесконечности и в итоге родится мертворожденный проект, не решающий ни одной задачи с точки зрения бизнеса, а, как известно, любой коммерческий проект призван решать бизнес-задачи.
И так, еще раз подведем итог, в документации, описывающей задание (это должно быть не только техническое задание), должно содержаться максимально полное описание всех граней проекта, от функционала до внешнего вида и бизнес задач, иначе вы рискуете получить мертворожденный
Напоследок, правило работы с клиентом: Больше бумаги – чище попа!
Игитян Тачат,
Директор направления интерактивных коммуникаций,
РБК СОФТ
