В мире разработки сайтов, часто встречаются случаи, когда заказчик подписал ТЗ, начали работу, и по ходу начинают возникать требования, которые выходят за рамки технического задания (ТЗ).

Тут надо понимать ряд принципов и правил, по которым надо отрабатывать такие требования. Далеко не все они могут быть реализованы (потому что выходят за рамки ТЗ), и далеко не все из них можно отсекать (птм что это убьет качество и мб испортит отношения с заказчиком).

Важно найти баланс и понять что нужно реализовать, а что нужно отсечь или перенести.

Зачем нужно ТЗ?

Чтобы понимать суть проблемы, надо хорошо понимать зачем делается ТЗ и значение слова «качество». Проблема в том что это знают лишь 1 из 1000 человек, а остальные лишь догадываются и как правило не верно понимают суть и смысл этих вещей.

Надо начать с термина «Качество» — по стандарту ИСО 9000 — это степень превосходства ожиданий результатом.

Просто? Да, но важно понимать каждое слово в этой формулировке.

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

Самое важное в том, что ТЗ на этапе запуска фиксирует ожидания заказчика и затраты подрядчика. Ключевое слово тут — ожидания. В этом вся суть.

Не важно по ТЗ вы потом делаете работу или не по ТЗ — важно соблюдаются ли ожидания или нет.

Если ТЗ сделано, и сделано правильно и хорошо, то ключевая цель этого — определить и зафиксировать ожидания.

Если это сделано правильно, тогда все остальное будет проще. И в случае отклонений, можно будет их как-то разрулить.

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

Категории отклонений

Давайте разберем варианты таких отклонений и способы их обработки…

Изменение формулировки

Самое плохое что может быть, это изменение формулировки требования. Иногда одно слово, измененное в одном предложении текста, может перевернуть суть, смысл и затраты с ног на голову.

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

Подрядчи же вынужден балансировать между двумя краями:

  1. Если это действительно сложно реализуемое изменение, то отклонить его и обосновать совю позицию. Предложить варианты решений, в том числе вынос изменения в следующий спринт (новое ТЗ).
  2. Если это простое решение, то подрядчику должно хватить ума не быковать. Принять изменение, согласиться что так лучше и реализовать.

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

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

Явно новое требование

Заказчик может быть забыл его внести в ТЗ, или его обсуждали, но не зафиксировали. Тут как правило приходится отклонять такие требования. Предлагать перенести их в новую версию продукта.

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

Общепринятое требование

Это понятие опять же есть в ИСО 9000. Такие требования вообще могут быть не включены в ТЗ, но подрядчик обязан их учитывать и делать без усилий со стороны Заказчика.

Таких требований миллионы и все их в ТЗ не записать. Иначе ТЗ будет размером с дом.

Наприме если сайт адаптивный, то все дальнейшие изменения по нему должны быть адаптивными.

Если сайт на WordPress, то все изменения по умолчанию должны соответствовать кодексу WordPress.

Если это посадочная страница, то по умолчанию там должны быть заголовок, описание ценности и призыв к действию (принцип 3W — это минимум)

И так далее.

Если заказчик говорит что это должно быть, а специалсит этого не сделал, то будь добр исправь.

Опять же если заказчик и подрядчик адекватны, то проблем в этой области как правило не бывает. Иначе — и тут может быть конфликт.

Проекты и Agile

Отдельная тема, это обработка таких отклонений при проектной работе и при Agile. В первом случае больше подушка и подрядчик может принять больше отклонений и реализовать их. А заказчик за это платит в 2-3 раза выше от возможной цены.

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

Резюме

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