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