Проектный бизнес — это как поход в джунгли с картой, нарисованной ребёнком: вроде бы что-то видно, но где именно ты окажешься, предсказать невозможно. Все знают, что посчитать реальную себестоимость и сроки нужно до начала работы, но почему-то чаще всего это делают после того, как уже полпроекта провалилось в болото правок и «вот тут давайте чуть-чуть изменим». Это как если бы вы решили построить дом и сначала начали ставить стены, а потом вспомнили, что забыл купить фундамент.
Ну или как в анекдоте: «Спрашивают у программиста: „Сколько времени займёт?“ — „Да пару дней!“ — „А сколько денег?“ — „Пару тысяч!“ — „А если срочно?“ — „Тогда мы сделаем за неделю и за миллион.“»
Когда появляется соблазн не писать техническое задание (ТЗ), потому что «ну тут же всё просто и понятно», знайте: это иллюзия! Работать без ТЗ — всё равно что ехать на машине с закрытыми глазами и надеяться, что обойдёшь все ямы.
Есть разные методологии — Канбан там или Скрам — но у каждой задачи должно быть чёткое описание. Если сложить все эти описания вместе, получим толстенный документ под названием ТЗ, который иногда занимает больше времени на чтение, чем сама работа над проектом. Но вот парадокс: один день на написание ТЗ экономит месяц нервотрёпки при сдаче проекта.
Это сродни тому, как бабушка всегда говорила: «Лучше потратить час на уборку сейчас, чем целый день искать потерянные носки».
Я лично сторонник писать ТЗ после дизайна — так проще учесть все визуальные эффекты и детали. Если у вас есть проекты без ТЗ — садитесь и пиши́те его прямо сейчас!
Потом будете благодарить себя из прошлого. Правда, если пытаться пропустить этот этап ради экономии времени или денег, то рискуете получить бесконечные правки и недовольных клиентов.
Оценка задач тоже весёлая история. Бывает два подхода: первый — программист сам оценивает задачу и если не укладывается в время, то «лишнее» никто не оплачивает; второй — техлид оценивает задачу и если программист задерживается, разбираются причины ошибки с целью улучшить процесс.
Второй вариант похож на семейный совет у Шрека: сначала ругаемся друг с другом, а потом вместе решаем проблему.
А теперь про вечную боль любого проекта — бесконечные правки дизайна под девизом «правим до победного». Как-то раз мой заказчик получил 52 версии макета главной страницы!
Представляете? Это уже не проектирование сайта, а марафон по редактированию с элементами самоистязания.
В итоге я решил вернуть деньги заказчику: дешевле отказаться от работы, чем продолжать терять нервы и средства. Правило простое: 3-4 раунда правок — и макет считается принятым.
Если клиент молчит дольше установленного срока (обычно 3-7 дней), работа автоматически считается принятой. Это прописано даже в Гражданском Кодексе!
Попытка договориться иначе обычно приводит к тому же результату: либо бесконечные задержки со сдачей проекта, либо споры в суде о том, кто же виноват.
Вот вам две реальные истории из жизни проектов. Менеджер приносит заказчику макеты:
— Всё нравится!
— Подпишите акты!
— Пожалуйста!
— Теперь подпишите сами макеты!
— А… Если их надо подписывать… тогда я их посмотрю.
Или другая ситуация:
Менеджер клиента согласовывает дизайн… а клиент вдруг вспоминает про внезапный отпуск или просто исчезает на неделю без объяснений.
В общем проектный бизнес напоминает игру в шахматы с котом: кажется всё под контролем до тех пор пока кот не решит перевернуть доску лапой и спрятать ферзя под диван.
Разработка проекта подобна странному путешествию в неизведанные джунгли: сначала все кажется ясным, но затем оказываешься в непредсказуемой ситуации. Отложить определение реальной стоимости и сроков на потом — как строить дом без фундамента. Техническое задание — ключевой документ, который помогает избежать хаоса в процессе разработки, и его разработка заслуживает вложения времени и усилий, чтобы избежать неприятных сюрпризов в будущем.
Правильное составление технического задания (ТЗ) в проектном бизнесе — ключевой момент, определяющий успех или провал работы. Нередко компании сталкиваются с проблемой отсутствия четкого ТЗ, что приводит к затяжным корректировкам и недовольству заказчиков. Составление ТЗ после дизайна проекта может быть эффективным подходом, позволяющим учесть все визуальные аспекты и избежать лишних правок в будущем. Вложение времени и усилий в разработку документации заранее может значительно сэкономить ресурсы и гарантировать успешное завершение проекта, что делает этот этап обязательным для любой компании, стремящейся к эффективной и продуктивной работе.