Эпизод 24 :: Техническое задание отменяется!

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

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

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

Сейчас я с уверенностью могу сказать, что это прекрасно! Я не по наслышке знаю, что такое составлять технические задания. Во времена веб-студийной деятельности мы их составляли пачками. На это уходила уйма времени. И при всем при этом, ни один проект не был выполнен в точности по нему. Ни один! Даже не смотря на то, что это официальный документ и приложение к договору, подписываемое со стороны заказчика и веб-студии.

Происходит это по одной простой причине — разработчик не может предвидеть будущее и проблем, в том числе технических, с которыми он может столкнуться при выполнении проекта. Может оказаться, что CMS не поддерживает некоторый заявленный функционал, разработка некоторых «мелочей» съест весь бюджет и прибыль вместе с ним, появятся технические несовместимости компонентов, ну и много чего еще.

Есть, правда, еще второй фактор — изменение видения своего проекта у заказчика, но с ним легче. Можно сослаться на договор и тогда проблема решается либо доплатой либо отказом в выполнении дополнительных работ. Чаще первое.

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

Так что, техническое задание вообще не нужно? Конечно, нужно. Но должен быть разумный, действительно необходимый минимум для старта. А как определить «разумность»? Идеальный документ — один печатный лист. Не более того. Тогда у него есть шансы не попасть в стопку бумаг, просматриваемых один раз в год (обычно перед отправкой в корзину). Мы пошли именно по этому пути и ничуть не жалеем.

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

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

Можно ли было пойти по другому пути? Можно ли было потратить недели и месяцы на проработку подробного технического задания? А потом выдать его готовенький сотрудникам и быстренько сбацать идеальный проект? Только теоретически. На практике так не получается никогда и причины этому можно найти в первом абзаце моего поста.

У Вас есть другой опыт по работе с техническими заданиями? Поделитесь и в камментах — очень интересно.