Полноценное техническое задание проекта - это готовая часть работ где ясно какая платформа используется, бизнес-модель проекта, проведены тесты, подобраны модули, прописаны сценарии действий пользователей и инструментов, спланирована база данных. Разработчику остается спокойно пройти по расписанным этапам работ, без дополнительных согласований, тестов, и переделок. Данный вариант кажется дороже, но на самом деле в процессе создания расширенного ТЗ Разработчик проводит анализ, тестирование, частично собирает проект, прописывает подробно дизайн, техническую часть и т.д.
Статью навеяла ситуация из моей практики.
Годом ранее я получила заявку на создание сайта. Заказчик заявил - работы немного, сайт простой, результат хочется через месяц. Все как обычно, техзадание отсутствует, как и понимание процесса как это организовать. Ситуация осложнялась отсутствием подробного описания бизнес-модели, возможно из опасения Заказчика, что идея уйдет на сторону, либо Заказчик не смог прояснить задачу по той причине, что еще сам не понимал как это должно работать и находился в поисках решений.
Диалог перерос в регулярный созвон и просьбой о консультации по нюансам проекта где часть информации приходилось вытаскивать на поверхность догадками и Заказчик после этого уходил на какое-то время думать, каждый раз отказываясь от подробного техзадания.
Через полгода идея созрела и выросла в видение готового проекта по типу портала для фрилансеров. У Заказчика сформировался процесс, а у меня краткое ТЗ по ключевым шагам и общее видение конечного результата.
Обычно я не берусь за проекты такого типа без какого либо ТЗ, тут два варианта, либо краткое техзадание и работа по шагам в исследовательском режиме, либо подробное техзадание с описанием сценариев и ролей. Первый вариант, как правило, получается дороже - связано это с тем, что работы происходят в исследовательском режиме с отсутствием проекта баз данных и заранее прописанных сценариев, которые возвращают разработчика к началу работ для переделки предыдущих этапов. Возникает это чаще всего, когда появляется новый сценарий пользовательский действий, кнопок и др. инструментов от которых зависят предыдущие сценарии, либо когда происходят изменения в базе данных при добавлении или удалении полей, форм и представлений. Разработчику приходится обосновывать свои действия и вести согласования с Заказчиком на каждом шаге работ, консультировать Заказчика, создавать дополнительные соглашения к договору что неизбежно приводит к перерасчету стоимости услуг и потере времени обоих сторон.
Полноценное техническое задание проекта - это готовая часть работ где ясно какая платформа используется, бизнес-модель проекта, проведены тесты, подобраны модули, прописаны сценарии действий пользователей и инструментов, спланирована база данных. Разработчику остается спокойно пройти по расписанным этапам работ, без дополнительных согласований, тестов, и переделок. Данный вариант кажется дороже, но на самом деле в процессе создания расширенного ТЗ Разработчик проводит анализ, тестирование, частично собирает проект, прописывает подробно дизайн, техническую часть и т.д. В таком случае Заказчик может использовать данное ТЗ по своему усмотрению, поменять Разработчика на любом этапе и получить желаемый результат в гораздо более короткий срок и с небольшой вероятностью удорожания услуг в процессе работ.
В моем случае - обсудив основные моменты и согласовав стоимость услуг Заказчик принимает решение запускать проект в работу, просит договор, в котором описаны шаги в виде краткого ТЗ и на этом этапе пропадает.
И вот тут - внимание! Как не надо делать!
Заказчик уходит к другому исполнителю с этим кратким ТЗ, которое содержит только список ключевых шагов в спецификации к договору.
Возможно ему там предложили сделать работу дешевле, возможно он просто решил сэкономить на мне оплату работы за составление техзадания - но через полгода мне вновь начали поступать от него звонки с просьбой провести аудит уже готового сайта, который ему сделали по моему сокращенному техзаданию, чему я была не сказать как удивлена.
Из разговора я понимаю, что сторонний Разработчик по имеющемуся списку работ в виде ключевых шагов, прописанных в моей спецификации, без описания сценариев сделал, что-то, что он понял по своему и в процессе работы повысил стоимость услуг в виду того, что он проделал больше работы, возможно так оно и есть, а вот какой работы Заказчику осталось не понятно, как и то - соответствует ли эта работа теперь тому что мы обсуждали и Заказчик хочет убедиться в том, что результат того что видела я, совпал с результатом того что есть в итоге и теперь ему требуется полный аудит сайта. Напомню - минимальная стоимость аудита подобного сайта в 2020 году составляет 35 000.00 рублей и выше.
Что произошло?
Такие проекты создаются успешно тогда, когда видение результата заказчиком и разработчиком совпадают.
Прописывая шаги я обсудила заранее, что буду делать, проконсультировала заказчика по каждому этапу работ, провела тесты, прописала для себя сценарии и действие ролей пользователей.
Сторонний Разработчик же взял готовый старт для работы, в виде моего краткого ТЗ, благодаря которому он быстро сориентировался в объеме работ, но пошел своим путем. В итоге у Заказчика появились сомнения и результат не совпал с ожидаемым и это, вполне ожидаемо приведет к дополнительным вложениям в проект, которых можно было избежать путем создания подробного ТЗ проекта.
Читайте здесь - о более подробном тех-задании.
- Войдите, чтобы оставлять комментарии