Добрый вечер, мои дорогие! Сегодня мы поговорим об управлении проектами, а именно — о технических заданиях. Что такое техническое задание, наверное, знают все. А вот каким оно должно быть на самом деле, об этом в нашей программе.
Давным-давно, будучи молодым, я думал, что у техзадания есть какой-то свой определенный шаблон, некий ГОСТ. Я долго его искал, но безуспешно. Перерыл все ТЗ всех компаний, что мне попадались, и нигде не было идеала. Остался даже такой осадочек на время, что ТЗ — это просто «отписка», мини-этап, который нужно сделать, чтобы скорее начать проект. У веб-студии в голове уже сформирована модель будущего сайта, зачем ее описывать — тратить время! Да и кто у нас тут специалист эпистолярного жанра, многие и запятых-то не расставят.
Но шли годы, я взрослел. Вместе со мной росли и те шишки, которые набила мне практика составления хреновых ТЗ. На сегодня я готов выделить три категории технических заданий по уровню сложности и качеству проработки. Итак, назовем их:
«Идеологическое». Техническое задание, составленное скорее как «отписка». Содержит общие фразы. Конкретика отсутствует. В быту называется «подписать и забыть».
«Логическое». Хорошо составленное ТЗ, прописаны многие моменты. Дана общая логика работы проекта и его частей. Вполне подходит для разработки сайта и объяснений с Заказчиком.
«Физическое». Максимально полное, прописана логика, структуры баз, схем обмена данными и пр. Имея под рукой такое ТЗ, сделать сайт может уже даже школьник.
Зачем вообще нужно ТЗ, спросим себя? Все просто! ТЗ является неотъемлимым приложением к договору на разработку проекта, и именно в ТЗ определен объем работ. Если завтра Заказчик на этапе создания сайта придет к вам и скажет, что нужно добавить еще пару разделов, — вы тыкаете его в ТЗ и говорите: «А вот и нет!» Без смеха. Приходят и говорят. И если в ТЗ четко не прописано, вы попадаете на дополнительный объем работ в том же старом бюджете и сроках.
Не пойду далеко за примерами. Месяц назад наша компания, поддавшись мотивационным срокам, за день составила техническое задание для проекта. Оно, естественно, получилось «идеологическим». Сегодня, разрабатывая проект, мы сталкиваемся с непонимаем между нами и Заказчиком. Вынуждены каждый раз спорить и отстаивать свою точку зрения, потому что банальная, казалось бы, «лента новостей» воспринимается Заказчиком вовсе не так, как она привычна для нас.
И другой пример. Почти месяц мы составляли техзадание для еще одного нашего клиента. Проведено несколько встреч, проработаны все моменты. В итоге ТЗ разместилось на 40 страницах. И это, мне кажется, еще не полный его вариант. Если бы позволяли сроки, можно было раскрыть его еще в полтора раза. Но сроки не позволяют. А они, кстати, таковы: ТЗ — один месяц, разработка проекта — полтора месяца. То есть этап разработки техзадания по длительности почти равен этапу разработки проекта. Way to go.
Как быть, ведь ТЗ обычно пишется после предварительной оценки проекта и сроков? Выход один — выделять составление техзадания в отдельный этап, который и оплачивается отдельно. Если Заказчика не устроит ваша оценка, то с этим ТЗ он сможет прийти в другую компанию и попробовать разработать проект у нее.
А тенденции таковы. Уже есть на рынке Новосибирска компании, занимающиеся составлением технических заданий и выдачей рекомендаций по выбору Разработчика. Да и сами компании готовы предложить такую услугу. Например, опять же, мы осуществляем такую деятельность. Не всегда же кодить и рисовать, нужно и проектированием заниматься.
Всем отличной погоды, увидимся на пляже!
Комментарии
Koz
Первый…
> Давным-давно, будучи молодым, я думал, что у техзадания есть какой-то свой определенный шаблон, некий ГОСТ. Я долго его искал, но безуспешно. Перерыл все ТЗ всех компаний, что мне попадались, и нигде не было идеала.
А ГОСТы тем не менее есть. Даже целых два: 34.602-89 и 19.201-78. Ссылки на их содержимое доступны в поисковиках. Думаю, что автор это знал, просто они ему не нравятся.
И еще ссылку на статейку подкину: Подготовка документации на программные средства (ПС) в соответствии с имеющимися ГОСТами (документация) - http://www.interface.ru/home.asp?artId=3293
ViX
“А тенденции таковы. Уже есть на рынке Новосибирска компании, занимающиеся составлением технических заданий и выдачей рекомендаций по выбору Разработчика.”
Следовательно должны появится компании занимающихся “выдачей рекомендаций по выбору” компаний-составителей ТЗ. :)
privileg
Обращаюсь к представителям разработчиков - оплачивает ли клиент разработку ТЗ? По отличному ТЗ, как замечено, сайт может сделать даже школьник, и кроме того есть фирмы состовляющие его, значит ли это что на такие тз состовляется отдельный договор?
Как в других компаниях разрабочтиках сайтов с ТЗ?
Koz
2 privileg: “оплачивает ли клиент разработку ТЗ?”
Да, бывает такое. По состоянию на сегодняшний день наверняка сказать не могу (хотя склонен считать, что мало что изменилось за 3-4 года), но в 2003 году один раз сталкивался с таким - в составе работ и по-моему даже в акте была строка “Разработка ТЗ” и клиент ее оплачивал. Правда это был наверное только один раз такой - по подавляющему большинству проектов не выделяли явно “Разработку ТЗ” с отдельной ценой, просто учитывали это в цене всего проекта и все.
eugene
2privileg
Из практики, для крупных проектов со сложным функционалом ТЗ всегда выделяется отдельным пунктом и оплачивается отдельно.
icon
Да уж, проблема знакомая и очень актуальная. Платить за ТЗ мало кто готов, а делать сайт называя стоимость “со слов” (типа “ну вы скажите примерно”, а потом от этого примерно тяжело отвертеться) существенно превышая трудозатраты не повышая стоимость не хочется.
RoleXXX
Вообще ТЗ должен составлять заказчик. И с ним идти к исполнителю, который его либо подписывает, либо вносит изменения/предложения/уточнения и отдает обратно и так до тех пор пока обе стороны не будут удовлетворены. Но если, как это часто бывает в вебе, заказчик вобще не понимает чего он хочет и перекладывает эту работу на исполнителя, то почему она должна быть бесплатной?
Koz
2 RoleXXX. “Вообще ТЗ должен составлять заказчик”
Возражу - ТЗ должен составлять исполнитель. И веб или не веб здесь не причем. Аргументирую:
1. Заказчик не является специалистом в том, разработку чего он заказывает, он не может предложить рамки, тех.характеристики, возможности системы, состав и содержание работ по ее разработке. И нельзя от него этого требовать - он специалист в своей предметной области, а не в разработке информационных (автоматизированных, …) систем.
2. Это рекомендует ГОСТ 34.602-89 - цитирую - “Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т.п.).” Хоть и давно, но ведь не из пальца его высосали.
3. Насколько мне позволяет судить собственный опыт - это все-таки общепринятая практика.
А чем Вы можете аргументировать свое мнение?
Работа по составлению ТЗ бесплатной быть, конечно же, не должна - единственное с чем могу согласиться.
RoleXXX
2 Koz
“Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований…”. Именно так. Сорьки, попутал термины. Заказчик составляет Требования.
:-)
Maxim
Нашел занимательную статью Олега Бунина под названием «Жизнь без технического задания»: http://www.computerra.ru/think/286727/
К сожалению, приходится признавать, что автор скорее прав. Грустно, но c’est la vie, это наша специфика.
Давным-давно, будучи молодым, я думал, что у техзадания есть какой-то свой определенный шаблон, некий ГОСТ. Я долго его искал, но безуспешно. Перерыл все ТЗ всех компаний, что мне попадались, и нигде не было идеала. Остался даже такой осадочек на время, что ТЗ — это просто «отписка», мини-этап, который нужно сделать, чтобы скорее начать проект. У веб-студии в голове уже сформирована модель будущего сайта, зачем ее описывать — тратить время! Да и кто у нас тут специалист эпистолярного жанра, многие и запятых-то не расставят.
Но шли годы, я взрослел. Вместе со мной росли и те шишки, которые набила мне практика составления хреновых ТЗ. На сегодня я готов выделить три категории технических заданий по уровню сложности и качеству проработки. Итак, назовем их:
«Идеологическое». Техническое задание, составленное скорее как «отписка». Содержит общие фразы. Конкретика отсутствует. В быту называется «подписать и забыть».
«Логическое». Хорошо составленное ТЗ, прописаны многие моменты. Дана общая логика работы проекта и его частей. Вполне подходит для разработки сайта и объяснений с Заказчиком.
«Физическое». Максимально полное, прописана логика, структуры баз, схем обмена данными и пр. Имея под рукой такое ТЗ, сделать сайт может уже даже школьник.
Зачем вообще нужно ТЗ, спросим себя? Все просто! ТЗ является неотъемлимым приложением к договору на разработку проекта, и именно в ТЗ определен объем работ. Если завтра Заказчик на этапе создания сайта придет к вам и скажет, что нужно добавить еще пару разделов, — вы тыкаете его в ТЗ и говорите: «А вот и нет!» Без смеха. Приходят и говорят. И если в ТЗ четко не прописано, вы попадаете на дополнительный объем работ в том же старом бюджете и сроках.
Не пойду далеко за примерами. Месяц назад наша компания, поддавшись мотивационным срокам, за день составила техническое задание для проекта. Оно, естественно, получилось «идеологическим». Сегодня, разрабатывая проект, мы сталкиваемся с непонимаем между нами и Заказчиком. Вынуждены каждый раз спорить и отстаивать свою точку зрения, потому что банальная, казалось бы, «лента новостей» воспринимается Заказчиком вовсе не так, как она привычна для нас.
И другой пример. Почти месяц мы составляли техзадание для еще одного нашего клиента. Проведено несколько встреч, проработаны все моменты. В итоге ТЗ разместилось на 40 страницах. И это, мне кажется, еще не полный его вариант. Если бы позволяли сроки, можно было раскрыть его еще в полтора раза. Но сроки не позволяют. А они, кстати, таковы: ТЗ — один месяц, разработка проекта — полтора месяца. То есть этап разработки техзадания по длительности почти равен этапу разработки проекта. Way to go.
Как быть, ведь ТЗ обычно пишется после предварительной оценки проекта и сроков? Выход один — выделять составление техзадания в отдельный этап, который и оплачивается отдельно. Если Заказчика не устроит ваша оценка, то с этим ТЗ он сможет прийти в другую компанию и попробовать разработать проект у нее.
А тенденции таковы. Уже есть на рынке Новосибирска компании, занимающиеся составлением технических заданий и выдачей рекомендаций по выбору Разработчика. Да и сами компании готовы предложить такую услугу. Например, опять же, мы осуществляем такую деятельность. Не всегда же кодить и рисовать, нужно и проектированием заниматься.
Всем отличной погоды, увидимся на пляже!
Комментарии
Koz
Первый…
> Давным-давно, будучи молодым, я думал, что у техзадания есть какой-то свой определенный шаблон, некий ГОСТ. Я долго его искал, но безуспешно. Перерыл все ТЗ всех компаний, что мне попадались, и нигде не было идеала.
А ГОСТы тем не менее есть. Даже целых два: 34.602-89 и 19.201-78. Ссылки на их содержимое доступны в поисковиках. Думаю, что автор это знал, просто они ему не нравятся.
И еще ссылку на статейку подкину: Подготовка документации на программные средства (ПС) в соответствии с имеющимися ГОСТами (документация) - http://www.interface.ru/home.asp?artId=3293
ViX
“А тенденции таковы. Уже есть на рынке Новосибирска компании, занимающиеся составлением технических заданий и выдачей рекомендаций по выбору Разработчика.”
Следовательно должны появится компании занимающихся “выдачей рекомендаций по выбору” компаний-составителей ТЗ. :)
privileg
Обращаюсь к представителям разработчиков - оплачивает ли клиент разработку ТЗ? По отличному ТЗ, как замечено, сайт может сделать даже школьник, и кроме того есть фирмы состовляющие его, значит ли это что на такие тз состовляется отдельный договор?
Как в других компаниях разрабочтиках сайтов с ТЗ?
Koz
2 privileg: “оплачивает ли клиент разработку ТЗ?”
Да, бывает такое. По состоянию на сегодняшний день наверняка сказать не могу (хотя склонен считать, что мало что изменилось за 3-4 года), но в 2003 году один раз сталкивался с таким - в составе работ и по-моему даже в акте была строка “Разработка ТЗ” и клиент ее оплачивал. Правда это был наверное только один раз такой - по подавляющему большинству проектов не выделяли явно “Разработку ТЗ” с отдельной ценой, просто учитывали это в цене всего проекта и все.
eugene
2privileg
Из практики, для крупных проектов со сложным функционалом ТЗ всегда выделяется отдельным пунктом и оплачивается отдельно.
icon
Да уж, проблема знакомая и очень актуальная. Платить за ТЗ мало кто готов, а делать сайт называя стоимость “со слов” (типа “ну вы скажите примерно”, а потом от этого примерно тяжело отвертеться) существенно превышая трудозатраты не повышая стоимость не хочется.
RoleXXX
Вообще ТЗ должен составлять заказчик. И с ним идти к исполнителю, который его либо подписывает, либо вносит изменения/предложения/уточнения и отдает обратно и так до тех пор пока обе стороны не будут удовлетворены. Но если, как это часто бывает в вебе, заказчик вобще не понимает чего он хочет и перекладывает эту работу на исполнителя, то почему она должна быть бесплатной?
Koz
2 RoleXXX. “Вообще ТЗ должен составлять заказчик”
Возражу - ТЗ должен составлять исполнитель. И веб или не веб здесь не причем. Аргументирую:
1. Заказчик не является специалистом в том, разработку чего он заказывает, он не может предложить рамки, тех.характеристики, возможности системы, состав и содержание работ по ее разработке. И нельзя от него этого требовать - он специалист в своей предметной области, а не в разработке информационных (автоматизированных, …) систем.
2. Это рекомендует ГОСТ 34.602-89 - цитирую - “Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т.п.).” Хоть и давно, но ведь не из пальца его высосали.
3. Насколько мне позволяет судить собственный опыт - это все-таки общепринятая практика.
А чем Вы можете аргументировать свое мнение?
Работа по составлению ТЗ бесплатной быть, конечно же, не должна - единственное с чем могу согласиться.
RoleXXX
2 Koz
“Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований…”. Именно так. Сорьки, попутал термины. Заказчик составляет Требования.
:-)
Maxim
Нашел занимательную статью Олега Бунина под названием «Жизнь без технического задания»: http://www.computerra.ru/think/286727/
К сожалению, приходится признавать, что автор скорее прав. Грустно, но c’est la vie, это наша специфика.
Комментариев нет:
Отправить комментарий