Как писать правильное ТЗ. Ошибки при взаимодействии с разработчиками

Привет. Хочу внести ясность во взаимодействие заказчика и разработчика. Под заказчиком может выступать любое лицо, которое хочет что-то получить за какой-то срок. При том – получить в лучшем для себя виде. Естественно – дело касается ТЗ. Проблем на этом этапе множество. Давайте их разберем. Все пункты будут рассмотрены с позиции веб-разработки и строительства дома:

1.  Отсутствие детализации.

Заказчик говорит – мне нужен готовый продукт. Заказчик представляет, что продукт должен делать, как выглядеть и даже может описать основные моменты. Но этого недостаточно. Продукт многогранен. Заказчик готов сесть рядом с разработчиком и четко указывать – что делать.

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

Окажется, что раздел «о компании» очень сходен с разделом «наши партнеры» и их можно было бы объединить. Но они уже созданы. Рама, которую заказчик заказал больше, чем размер окна. Плита не помещается в кухню.  И что в итоге?

В итоге – лишние издержки для проекта, разработчика, которые можно было бы решить при помощи детальной проработки при проектировании. Все ждут теперь заказчика. Заказчик должен, прежде всего, максимально детально составить ТЗ – то, что он хочет. Максимально детально проработать возможные взаимодействия страниц.

2.  Неопределенность в приоритетах/готовности.

Заказчик говорит – нужно запускаться только когда продукт будет полностью готов. Остается только понять - что такое готов полностью.

Открою секрет – продукт никогда 100% не будет закончен. Всегда будет хоть какая-нибудь мелочь, которую нужно будет поправить. Всегда найдутся новые технологии, которые заставят все более оптимизировать уже созданные страницы. Всегда будут новые хотелки, которые будут отсрочивать запуск. Может быть, какую-то часть сделать до запуска, а что-то можно собрать и после.

Заказчик не может поселиться в доме, в котором еще не работает 2-й сан узел. Или может?

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

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

3.  Неопределенность в критериях качества.

Заказчик говорит – нужна классная верстка и чтобы все работало. Остается только понять – что такое классная верстка и что значит – все работало.

Открою секрет – идеальной верстки не бывает. Идеальной работоспособности не бывает.

Верстка бывает максимально универсальная (поддерживающая все виды браузеров), бывает легкая верстка (минимум траффика). Бывает быстро разрабатываемая верстка – придающая проекту мобильности при разработке. Найдите середину в этих 3х группах – легкость, универсальность и скорость разработки. Выберите любые 2

Определитесь с браузерами ваших потенциальных посетителей. Поддержка IE 7 – в 2 раза увеличивает срок разработки. Поддержка IE6 – еще в 2 раза. Отказ от поддержки IEверсии ниже 9й – придает верстке легкость и мобильность разработки. Стоит ли ради 100 человек в год – платить верстальщику в 2 раза больше денег, увеличивая сроки разработки в 2 раза?

Если дизайнер нарисовал дизайн – и вы думаете что верстальщику уже все понятно – вы ошибаетесь. В дизайне не учтено (как правило) поведение элементов при разной ширине экрана пользователя. В дизайне не учтены эффекты и анимация при переключении элементов. В дизайне не учтены эффекты при наведении мыши на элемент. Вы хотите пользоваться сайтом через тач скрины – откажитесь от выпадающих меню, эти элементы несовместимы.

Заказчик думает – вот классный дизайн. Получает верстку и говорит – полное г***о. Так почему он сразу не сказал, что ему нужно. Опять разработчику/верстальщику брать да исправлять.

Нужно ли строить дом быстро? Нужно ли строить дом устойчивым к метеоритному дождю? Должен ли дом выдержать слона?

Вопрос снова стратегический и упирается в заказчика. И снова страдает взаимодействие и срывы сроков.

4.  Неопределенность в необходимости проекта/аудитории/конкурентах

Пункт касается в основном недовольного заказчика на конечной стадии выпуска. Заказчик любит винить в неудаче разработчиков. Сайт наконец-то разработан. Уже событие, которое отметить можно.

Но не идет туда народ. А если идет - то не регистрируются. А если регистрируется - то не из того города. А если из того города - то не платят деньги за услуги.

Вопрос монетизации. Вопрос стратегии монетизации и вообще раскрутки – отдельная задача. Ее не нужно описывать в ТЗ (а в некоторых случаях - нужно), но она должна быть в голове у заказчика максимально детализирована. И эта детализация должна найти свое отражение в мелочах при разработке.

Разработчик увидел пункт «красивое выпадающее меню» - и сделал меню на Javascript. И не важно, что половина поисковиков может не увидеть эти разделы и не полностью пройти сайт. Разработчик поставил статический Title. Ведь в ТЗ указано «заголовок - О компании». Вот как теперь специалисту по продвижению этот заголовок менять для привлечения нужных посетителей. Инструменты для этого не созданы. Нужно еще раз договариваться с разработчиком.

Дом готов, въезжай и живи. Только вот дверь открывается только изнутри. Да и зачем это нужно, когда есть окна. В ТЗ же было прописано, что нужна надежная защита от вскрытия.

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

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

Больше материалов выкладываю на своем Дзен канале

  • Автор: kosmom
  • Рейтинг: 0
  • Просмотров: 1200
  • Комментариев: 0
  • Создан: 03.11.2012 08:34

Комментарии (0)

Ваши предложения и пожелания пишите на pro@kosmom.ru

Теги

ajax axios backup bootstrap core framework eloquent excel home project html ios javascript keep-alive kpi laravel legacy mvp orm php rip scroll solid timestamp undefined vue vuetify watch безопасность биометрический паспорт ваша любаша для путешествий загран на 10 лет загран паспорт загранпаспорт нового образца зимние книги как заполнить анкеты кеширование книги на новый год логирование мцф недвижимость новогодние книги образец заполнения антеты паспорт для путешествий паспорт нового поколения печать продукт проектирование прокси разработка ремонт ремонт в апартаментах ремонт нежилого помещения самокат сдача сколько стоил ремонт апартаментов спорт стандарты таблица финансы хостинг цена ремонта что почитать зимой юзабилити

Случайный пост

12.12.2014 19:47
Фильмы за неделю 17 - 23 ноября 2014 года