0 просмотренных постов скрыто
Как бороться с хотелками заказчиков
Этот пост посвящён извечной проблеме взаимоотношений с заказчиками и приемки результатов работ для случаев, когда сторонам не хватило времени, желания, и т.д. по списку на согласование требований и договора. Но, даже если хватило, «хотелки» часто возникают, и назревающие проблемы приемки исполнителю нужно как-то уметь решать.
Этот способ мне посоветовал матёрый руководитель, и уже 5 лет он показывает свою эффективность, так что смело можете пользоваться.
Обычно процесс всем представляется так: Техническое задание, работы, проверка результата (приемка).
Заказчик утверждает, что результат не соответствует ТЗ. Это хорошо, тогда смотрим в ТЗ, находим несоответствие, исправляем и сдаём.
Но конфликты возникают тогда, когда заказчик считает, что результат не соответствует его ожиданиям, или, что исполнитель не внёс в ТЗ то, что оказывается для заказчика важным. Почему так случается, и главное, что делать, чтобы таких ситуаций избегать?
Первый важный момент, это разница между ТЗ и ТТ. Технические требования (ТТ) или просто «требования» характеризуют продукт, как результат физического или интеллектуального труда. ТЗ же является заданием в прямом смысле, т.е. характеризует, как исполнитель должен выполнить работу, этапы, сроки, правила сдачи, состав документации и т.д.
ТТ и ТЗ вместе дают исчерпывающий перечень требований как к результату, так и процессу его достижения.
Заказчик говорит, «Вы сорвали срок» или «Вы не показали промежуточный результат». Это относится к ТЗ. Часто требования ТЗ дублирует договор, или ссылается на ТЗ, отражая основные моменты.
Если заказчик говорит, «Я хотел совсем другое» или «Оно не работает». Это относится к ТТ. И тут важно отметить, что хорошие требования сформулировать на старте бывает сложно, как же быть?
Нужно просто держать в уме, что заказчик планирует использовать результат работ в соответствии со своими намерениями для решения задачи (задач). У результата работ есть назначение.
Для упрощения примем, что намерения определяются какой-то проблематикой заказчика. Для разрешения проблемы он и привлекает исполнителя (договор) для создания результата, который будет использоваться для решения задачи. Тоже самое, но другими словами, использование результата работ решает задачу заказчика. Решенная задача разрешает его проблему. Это и есть его намерение.
В итоге картина становится намного понятнее: Проблема - задача - требования - тех задание - договор.
Когда заказчик говорит, что в требованиях чего-то не было или что результат не соответствует ожиданиям, мы возвращаем заказчика на шаг назад на уровень его задачи, «мы точно решаем эту задачу?», и, если надо, в самое начало, «мы точно решаем эту проблему?».
Отматывайте заказчика на шаг назад, согласовывайте, фиксируйте договорённости и двигайтесь дальше, и тогда будет вам счастье.
У всех, кто дочитал до конца, извиняюсь за занудство) Желаю адекватных заказчиков и успешных проектов.
Показать полностью
ТЗ - Техническое Задание
Почему ТЗ очень важно (вообще, и особенно для работы с одеждой)?
Давайте обсудим это на примере моей работы над данным костюмом.
Начнем с базы. Что должно быть в ТЗ?
Всё… Вот все что вы МОЖЕТЕ выдать, как заказчик. Соберите все это в одном файле: необходимое/планируемое количество, основные параметры и размеры, желаемые цвета, все фишечки (которые уже есть в вашей задумке или, что хотели бы увидеть), ваш логотип, ссылки, фото/картинки, возможные примеры и т.д.
Клиент захотел запустить свой бренд и, в принципе составил неплохое ТЗ, и даже выслал примеры костюмов, от которых нужно оттолкнуться.
И вот, с одним костюмом все прошло гладко, сразу все понравилось, утвердили и уже шьем образец.
А вот со вторым, все не идет.
Задача 1 была сшить «что-нибудь подобное», сделали и не зашло.
Задача 2 была «давайте сами с какой-нибудь изюминкой», это как раз эти 2 варианта на фото и тоже не зашло, потому что мы теперь сильно ушли в сторону.
Теперь Задача 3, сделать полную копию образца и добавить пару минимальных отличий… Что же,, посмотрим. Работу так то, оплатили и как говорится: «Любой каприз за ваши юани».
Клиент оплатил депозит и даже с небольшим запасом. Так что может позволить себе капризничать. Но, проблема в том, что у них есть сроки и сторонние проекты.
Так что, на связь выходят раз в несколько месяцев, и сразу все нужно решать, в кратчайшие сроки. Хотя, это классика в нашем бизнесе.
Итог такой. Мы как профи можем и креативить и рано или поздно попасть в яблочко, как с первым костюмом, например. Но будет гораздо быстрее, практичнее и дешевле, если клиент изначально подольше посидит над ТЗ и, это позволить достичь результата в кратчайшие сроки. Так что, не пренебрегайте проработкой ТЗ, относитесь к нему ответственно и всем добра!
Показать полностью
10
По-настоящему годная петиция
Прекратить дискриминацию "заданий", клеймя их всех "техническими"!
Мемас о своём, дизайнерском
Показать полностью
1
Когда большое ТЗ лишь вредит
У нас созвон с добрым и давним клиентом - они сделали ТЗ (тех.задание) на новый проект (сайт), которое занимает 80 (!) страниц текста :) Вложено очень много сил (и денег + год работы), ТЗ подробнейшее, но сразу появилась огромная ловушка :)
Ловушка в том, что без подобного анализа ТЗ невозможно сделать оценку проекта. А сделать детальный анализ 80 страниц мелкого текста - уйдет месяц. Я предлагаю - работаем по часам или нам нужно выделить разработчика, вы оплачиваете его время и мы делаем глубинный анализ, и потом даем оценку проекта. Отказываются, сидим обсуждаем...
В итоге находим соломоново решение - про ТЗ забываем вообще, берем дизайн всех экранов и заново обсуждаем что делать надо :) И такое, кстати, не в первый раз в моей практике - чем толще ТЗ на начальном этапе, тем больше оно занимает места в корзине :)
Почему так? Не спрашивайте, у меня нет ответа, но такой парадокс в кастомной разработке ПО существует. Почему парадокс? Ну казалось бы, чем подробнее ТЗ, тем легче работается.... но видимо не всегда :)
Это изнанка. Обещал дать ответ в понедельник вечером с новой оценкой.
Русский ИТ бизнес (https://t.me/bezsmuzi)
