В предпоследней журнале "Компьютерра" (№33 от 13 сентября 2006 года) Олег Бунин (организатор и идеолог конференции веб-разработчиков) написал статью под названием "Жизнь Технического Задания". Написано странное. При прочтении статьи возникает ощущение, что автор собственно разработкой _сайтов_ никогда не занимался и говорит о чем-то другом. Все рассуждения справедливы, в луч�?ем случае, если мы рассматриваем работу [...]
В предпоследней журнале "Компьютерра" (№33 от 13 сентября 2006 года) Олег Бунин (организатор и идеолог конференции веб-разработчиков) написал статью под названием "Жизнь Технического Задания". Написано странное. При прочтении статьи возникает ощущение, что автор собственно разработкой _сайтов_ никогда не занимался и говорит о чем-то другом. Все рассуждения справедливы, в луч�?ем случае, если мы рассматриваем работу для внутреннего заказчика. Все это попахивает Agile. Уважаемые разработчики сайтов, работающие под заказ, на вне�?него заказчика, будьте внимательны! Следование рекомендациям этой статьи опасно для ва�?его бизнеса. Возможно автор не знаком с методиками управления проектами и ее составляющими (управление сроками, управление бюджетом и пр.), либо экстраполирует свой личный опыт по одному из проектов на всю среду коммерческой-веб разработки. Далее цитаты и мое �?МХО:
Когда я слы�?у о техническом задании на разработку веб-сайта, я внутренне улыбаюсь – еще один продукт, устарев�?ий уже в момент выхода. Это первая проблема всех технических заданий – предположение, что вне�?няя среда не меняется.
Мысль тоже устаревает в момент ее выхода, и что? ТЗ – это документ позволяеющий задать рамки проекта и впоследствии удержать его в этих рамках. ТЗ описывает за что заказчик платит вам деньги. В процессе разработки рамки могут изменяться, а изменения фиксироваться как дополнения к ТЗ и оплачиваться заказчиком (это ведь дополнительные работы). Без такого документа, фиксирующего хотя бы начальное состояние и договоренности, а также связанные с ними параметры проекта, изменения отследить невозможно.
Вторая проблема хоро�?о известна и отражена в древней мудрости: чтобы задать правильный вопрос, надо знать половину ответа. В ситуации, когда каждый новый сайт вы разрабатываете с использованием только что появив�?ихся технологий (новые модули, новая версия собственного движка, новая версия базы данных), – фактически вы каждый раз многое делаете заново. Это значительно осложняет процесс разработки, потому что вы не знаете, как будете это разрабатывать.
ТЗ редко включает в себя подробней�?ую спецификацию будущего модуля. Почти всегда достаточно описать остановиться на уровне функциональных возможностей в клиентской части и в части бэк-офиса. Как это будет реализовываться на практике – прикладная задача. В ТЗ это писать не нужно.
Третья проблема классическая – заказчик не всегда точно знает, чего он хочет. �? когда подходит срок сдачи проекта, вы слы�?ите, что вот здесь хоро�?о бы подправить, вот здесь изменить, а вот здесь добавить. Частично эту проблему ре�?ает моделирование конечного продукта, но, повторюсь, ли�?ь частично.
Это называется "работа с требованиями заказчика", читаем и запоминаем. � абота с требованиями заказчика действительно неприятный процесс и требует морального напряжения, но такова уж на�?а тяжелая доля. Почему-то никого не удивляет, что добавление в ма�?ину электростеклоподъемника стоит денег. Почему это должно удивлять в случае с сайтом? Тут нам очень поможет ТЗ, которое как раз описывает пожелания заказчика на старте проекта и содержит его (закачика) согласие, в виде подписи и печати. Фиксируйте пожелания заказчика, оценивайте их. Согласуйте описание пожеланий и оценку с клиентом. Если стоимость доработки невысока и не выводит проект за рамки бюджета – вы можете это сделать, как "подарок" заказчику, в противном случае – нужна соответствующая компенсация ва�?их _дополнительных_ работ. (кстати, PMP не рекомендует вносить "бесплатные" доработки и называет это Gold Plating) Далее в статье перечисляются очень слабо-применимые, при коммерческой разработке сайтов, методики, типа XP, подход притянут за у�?и. Почему, я подробнее напи�?у несколько позже. Продолжим:
�? все же нам нужно чем-то заменить отсутствие формального технического задания, – ведь мы должны сделать то, что требуется заказчику.
�?менно в Техническом Задании изложено то, чего хочет Заказчик. Отсутствие технического задания позволит Заказчику _бесконечно_ требовать доработок, а проект этот никогда не завер�?иться. Хотя где-то я видел и такой подход, когда проект превращался в процесс. Напоминаю, что это мой взгляд на проблему, в контексте _коммерческой_ разработки. Описанный автором подход тоже может работать, но я хотел бы увидеть также и описание бизнес-модели компании, которая бы обеспечивала гарантированную безубыточную деятельность при таком подходе. Это может быть работа по схеме Time-and-material, но найдите мне российского клиента который согласится на такую схему…
You can follow the comments for this article with the RSS 2.0 feed.
В России риск разработки сайта без ТЗ слишком велик и для заказчика, и для разработчика.
Пока не видел тех, кто более-менее значительный клиентский проект без ТЗ делал.
Content © Проекты в сети и Вопросы существования
Proudly powered by WordPress
Theme designed by Artisan Themes
23 queries.
0.116 seconds.
Можно проще – ТЗ как одноверсионный жёсткий документ как минимум нужно для тендера, т.е. в случае внешнего выбираемого подрядчика-исполнителя.