Простые решения, простая жизнь!Привет. Хочу внести ясность во взаимодействие заказчика и разработчика. Под заказчиком может выступать любое лицо, которое хочет что-то получить за какой-то срок. При том – получить в лучшем для себя виде. Естественно – дело касается ТЗ. Проблем на этом этапе множество. Давайте их разберем. Все пункты будут рассмотрены с позиции веб-разработки и строительства дома:
1. Отсутствие детализации.
Заказчик говорит – мне нужен готовый продукт. Заказчик представляет, что продукт должен делать, как выглядеть и даже может описать основные моменты. Но этого недостаточно. Продукт многогранен. Заказчик готов сесть рядом с разработчиком и четко указывать – что делать.
И вот, когда дело дойдет до дела – окажется что какой-то пункт у заказчика не был продуман. Страница есть, а текста для нее нет. И когда заходит речь о конечной верстке конкретной страницы – окажется, что текст на кнопочке слишком длинный и не вписывается в верстку. Нужно или все переделывать, менять текст, или его как-то умещать в заданные рамки.
Окажется, что раздел «о компании» очень сходен с разделом «наши партнеры» и их можно было бы объединить. Но они уже созданы. Рама, которую заказчик заказал больше, чем размер окна. Плита не помещается в кухню. И что в итоге?
В итоге – лишние издержки для проекта, разработчика, которые можно было бы решить при помощи детальной проработки при проектировании. Все ждут теперь заказчика. Заказчик должен, прежде всего, максимально детально составить ТЗ – то, что он хочет. Максимально детально проработать возможные взаимодействия страниц.
2. Неопределенность в приоритетах/готовности.
Заказчик говорит – нужно запускаться только когда продукт будет полностью готов. Остается только понять - что такое готов полностью.
Открою секрет – продукт никогда 100% не будет закончен. Всегда будет хоть какая-нибудь мелочь, которую нужно будет поправить. Всегда найдутся новые технологии, которые заставят все более оптимизировать уже созданные страницы. Всегда будут новые хотелки, которые будут отсрочивать запуск. Может быть, какую-то часть сделать до запуска, а что-то можно собрать и после.
Заказчик не может поселиться в доме, в котором еще не работает 2-й сан узел. Или может?
Вопрос стратегический. Запуститься сейчас с базой, остальное допилить потом, или запуститься когда все будет полностью готово. Каждый решает этот вопрос для себя сам. Палка о двух концах. Истина где-то посередине.
Определите ключевые моменты. Пусть разработчик их сделает в первую очередь. Остальное – будет видно, когда дойдет время. Гибкость – основная черта стартапов. Не теряйте гибкости, определите критерии, которые совершенно не значимы. Поставьте дедлайн с приоритетом задач. И обязательно укажите это в ТЗ
3. Неопределенность в критериях качества.
Заказчик говорит – нужна классная верстка и чтобы все работало. Остается только понять – что такое классная верстка и что значит – все работало.
Открою секрет – идеальной верстки не бывает. Идеальной работоспособности не бывает.
Верстка бывает максимально универсальная (поддерживающая все виды браузеров), бывает легкая верстка (минимум траффика). Бывает быстро разрабатываемая верстка – придающая проекту мобильности при разработке. Найдите середину в этих 3х группах – легкость, универсальность и скорость разработки. Выберите любые 2
Определитесь с браузерами ваших потенциальных посетителей. Поддержка IE 7 – в 2 раза увеличивает срок разработки. Поддержка IE6 – еще в 2 раза. Отказ от поддержки IEверсии ниже 9й – придает верстке легкость и мобильность разработки. Стоит ли ради 100 человек в год – платить верстальщику в 2 раза больше денег, увеличивая сроки разработки в 2 раза?
Если дизайнер нарисовал дизайн – и вы думаете что верстальщику уже все понятно – вы ошибаетесь. В дизайне не учтено (как правило) поведение элементов при разной ширине экрана пользователя. В дизайне не учтены эффекты и анимация при переключении элементов. В дизайне не учтены эффекты при наведении мыши на элемент. Вы хотите пользоваться сайтом через тач скрины – откажитесь от выпадающих меню, эти элементы несовместимы.
Заказчик думает – вот классный дизайн. Получает верстку и говорит – полное г***о. Так почему он сразу не сказал, что ему нужно. Опять разработчику/верстальщику брать да исправлять.
Нужно ли строить дом быстро? Нужно ли строить дом устойчивым к метеоритному дождю? Должен ли дом выдержать слона?
Вопрос снова стратегический и упирается в заказчика. И снова страдает взаимодействие и срывы сроков.
4. Неопределенность в необходимости проекта/аудитории/конкурентах
Пункт касается в основном недовольного заказчика на конечной стадии выпуска. Заказчик любит винить в неудаче разработчиков. Сайт наконец-то разработан. Уже событие, которое отметить можно.
Но не идет туда народ. А если идет - то не регистрируются. А если регистрируется - то не из того города. А если из того города - то не платят деньги за услуги.
Вопрос монетизации. Вопрос стратегии монетизации и вообще раскрутки – отдельная задача. Ее не нужно описывать в ТЗ (а в некоторых случаях - нужно), но она должна быть в голове у заказчика максимально детализирована. И эта детализация должна найти свое отражение в мелочах при разработке.
Разработчик увидел пункт «красивое выпадающее меню» - и сделал меню на Javascript. И не важно, что половина поисковиков может не увидеть эти разделы и не полностью пройти сайт. Разработчик поставил статический Title. Ведь в ТЗ указано «заголовок - О компании». Вот как теперь специалисту по продвижению этот заголовок менять для привлечения нужных посетителей. Инструменты для этого не созданы. Нужно еще раз договариваться с разработчиком.
Дом готов, въезжай и живи. Только вот дверь открывается только изнутри. Да и зачем это нужно, когда есть окна. В ТЗ же было прописано, что нужна надежная защита от вскрытия.
Разработчику, в свою очередь, нужно уметь на понятном заказчику языке объяснить последствия и уточнения того или иного решения на самых ранних этапах, переспросить, понять цели и задачи того или иного решения.
Если разработка касается нескольких узконаправленных этапов – имеет смысл обзавестись неким координатором, или самому стать таким. Ну не понимает дизайнер, что рукописные шрифты не поддерживаются некоторыми браузерами и динамическое их создание на сервере выльется в большие затраты. Не понимает верстальщик, что меню должно читаться поисковиками. А программист не понимает, зачем делать админку для указания Title и других мета тегов. Специалист по продвижению не понимает, как в таких условиях продвигать сайт.