ТЗ или Бэклог?
Тенденции web-разработки: сложность проектов
Технологии развиваются. Задачи для заказной web-разработки становятся все сложнее. Косвенно это связано с развитием no-code технологий, в том числе — конструкторов сайтов, например, той же Tilda. Простые проекты можно легко создавать с их помощью, часто для этого даже не требуется привлекать сторонних специалистов. Клиенты все чаще приходят в web-агентство только когда их проект действительно сложный.
С одной стороны, тенденция позитивная — разработчики не тратят время на выполнение рутинных типовых задач. С другой — сложные проекты требуют сложного технического задания, в несколько десятков, а иногда и сотен страниц. Детально вникнуть в такое ТЗ и запомнить все детали и нюансы всем участникам проекта, включая заказчика, практически невозможно. В статье разберем современные тенденции web-разработки и выясним, так ли нужно сейчас техзадание и чем можно его заменить.
С одной стороны, тенденция позитивная — разработчики не тратят время на выполнение рутинных типовых задач. С другой — сложные проекты требуют сложного технического задания, в несколько десятков, а иногда и сотен страниц. Детально вникнуть в такое ТЗ и запомнить все детали и нюансы всем участникам проекта, включая заказчика, практически невозможно. В статье разберем современные тенденции web-разработки и выясним, так ли нужно сейчас техзадание и чем можно его заменить.
Итак, тенденции web-разработки в 2022 году
1
Проекты усложняются. Как мы уже отметили, бизнес-логика проектов становится все сложнее. В процессе разработки приходится решать много разноплановых задач. Некоторые проблемы «всплывают» только в процессе работы.
2
Клиенты стали более требовательными. Все чаще на стороне заказчика в процессе принимают участие люди, непосредственно связанные с разработкой и компетентные в it-сфере. Это позитивная тенденция, которая позволяет команде разработки говорить с заказчиком на одном языке.
3
При этом уровень аналитики падает. Это общая проблема для рынка web-разработки. Толковые аналитики через какое-то время или уходят в руководители проектов, или смотрят в сторону Data Science. А без должного уровня аналитики невозможно добиться полной детализации проекта и составить ТЗ так, чтобы в процессе разработки не возникало вопросов.
4
В ТЗ появляется очень много «белых пятен». Если аналитик на проекте недостаточно компетентен, срабатывает когнитивное искажение, когда именно сложные вопросы в ТЗ обрисовываются буквально несколькими штрихами, без конкретики. При этом простым механикам уделяется излишне много времени, дается масса избыточной информации. В итоге сложные задачи приходится решать уже в процессе разработки.
5
Требования в большинстве случаев меняются по ходу проекта. Находятся проблемы, которые не были учтены изначально, меняется логика, клиенты хотят добавить новые «хотелки» в проект. Это может быть связано и с внешними обстоятельствами, которые клиент не мог предвидеть на этапе составления технического задания.
Если подытожить, то в тенденциях web-разработки есть и позитивные, и негативные моменты. Проекты становятся более сложными и интересными, но это влечет за собой и усложнение тех. заданий, а предусмотреть все нюансы, с которыми столкнется разработка, заранее практически невозможно.
Для чего нужно ТЗ?
Цель у заказчика и разработчика одна — сделать хороший проект. И четкое техническое задание кажется необходимой основой для достижения этой цели. Оно закрывает сразу несколько задач: зафиксировать все требования заказчика, определить точную стоимость проекта и, при необходимости, дать возможность передать часть работ по проекту стороннему разработчику. С одной стороны, логично. С другой, если рассмотреть каждую цель детальнее, она оказывается несостоятельной. Давайте разберемся:
Можно ли с помощью ТЗ зафиксировать все требования заказчика?
Если дело касается объемного проекта со сложной логикой, то это практически невозможно. Документ с техзаданием получится огромным — 100 и более страниц — при таком объеме крайне сложно учесть все нюансы и выстроить детализированную логику связей между частями проекта.
Если дело касается объемного проекта со сложной логикой, то это практически невозможно. Документ с техзаданием получится огромным — 100 и более страниц — при таком объеме крайне сложно учесть все нюансы и выстроить детализированную логику связей между частями проекта.
А зафиксировать стоимость?
Плюс-минус да. Но сюда тоже могут «вклиниться» различные обстоятельства. Например, заказчик захочет добавить важную, по его мнению, деталь. Или выяснится, что какие-то моменты не были учтены в ТЗ из-за его сложности и объема. А учитывая, как меняются обстоятельства в современном мире, нужно быть готовым ко всему. Например, что у заказчика прекратятся поставки от зарубежных контрагентов или изменится порядок оказания услуг — все это нужно будет отразить в проекте.
Плюс-минус да. Но сюда тоже могут «вклиниться» различные обстоятельства. Например, заказчик захочет добавить важную, по его мнению, деталь. Или выяснится, что какие-то моменты не были учтены в ТЗ из-за его сложности и объема. А учитывая, как меняются обстоятельства в современном мире, нужно быть готовым ко всему. Например, что у заказчика прекратятся поставки от зарубежных контрагентов или изменится порядок оказания услуг — все это нужно будет отразить в проекте.
А что насчет передачи части проекта другим разработчикам?
В этом ТЗ вам тоже не поможет. Чтобы грамотно работать с проектом, учитывая все нюансы, важно прорабатывать его вместе с заказчиком. Разработчик, не знающий всех вводных, на основе которых строилось тех.задание клиента, вряд ли сделает свою работу хорошо. Нужно будет полностью погрузиться в проект, внимательно прочитать техническое задание и полностью понять всю логику проекта. По трудоемкости получается примерно как написать это самое ТЗ с нуля.
В этом ТЗ вам тоже не поможет. Чтобы грамотно работать с проектом, учитывая все нюансы, важно прорабатывать его вместе с заказчиком. Разработчик, не знающий всех вводных, на основе которых строилось тех.задание клиента, вряд ли сделает свою работу хорошо. Нужно будет полностью погрузиться в проект, внимательно прочитать техническое задание и полностью понять всю логику проекта. По трудоемкости получается примерно как написать это самое ТЗ с нуля.
Таким образом, сейчас составление ТЗ часто выглядит как анахронизм. Практически невозможно сделать так, чтобы на протяжении всего процесса разработки ТЗ осталось неизменным. Во время работы вам придется или постоянно переписывать ТЗ, или создавать многочисленные дополнения к нему, или смириться с его неактуальностью.
Как просчитать риски без ТЗ?
Мотивация написания подробного технического задания чаще всего завязана на страхах — не предусмотреть чего-то, вылезти за рамки бюджета, получить не то, что хотелось первоначально. Чтобы справиться с этими страхами, достаточно просчитать основные риски проекта:
- Есть ли рынок для вашего продукта? Существует ли сегмент потенциальных пользователей, которые ощущают сильную потребность в продукте?
- Реализуема ли ваша идея? Хватит ли у вас бюджета, времени, технических навыков, чтобы ее реализовать? Сможете ли вы отобрать компетентных исполнителей?
- Купит ли пользователь ваше решение? Не найдет ли он аналог дешевле?
- Заработаете ли вы на этом? Если у большинства ваших потенциальных конкурентов не получилось продвинуть свой товар или услугу, то очень возможно, и у вас не получится.
- Сможете ли вы масштабировать свой проект? Насколько это для вас важно?
Ответив на эти вопросы, можно начинать разработку MVP (минимально жизнеспособного продукта). Мы рекомендуем начать работу именно с MVP, чтобы быстрее протестировать гипотезу, отметить слабые места и приступить следующим этапам разработки.
Как работать над продуктами в современных условиях?
Оптимальный способ — это использование бэклогов и работа по SCRUM.
Разберемся с терминологией:
Разберемся с терминологией:
SCRUM — это фреймворк для разработки и поддержки сложных продуктов. При работе по Скраму разработка ведется спринтами. Спринт — это отрезок времени от одной до четырех недель, за который команда разработки создает очередную версию продукта (выполняет определенное количество задач проекта).
Roadmap — документ, в котором содержатся все желаемые функции продукта. Это скорее стратегический инструмент, который отражает долгосрочное видение продукта. Дорожную карту составляет менеджер проекта после плотного обсуждения проекта с клиентом.
Roadmap — документ, в котором содержатся все желаемые функции продукта. Это скорее стратегический инструмент, который отражает долгосрочное видение продукта. Дорожную карту составляет менеджер проекта после плотного обсуждения проекта с клиентом.
Бэклог — список задач для команды разработчиков, который составляется на основе roadmap (дорожной карты) проекта. Задачи в бэклоге стоят в порядке важности, но четких указаний по их выполнению нет — разработчики сами решают, как именно будут воплощать ту или иную функцию. Если специалисты достаточно компетентны, такой путь эффективнее, чем создание жестких инструкций для разработки.
Обычно составляется бэклог продукта (общие требования к разработке всего продукта) и бэклог спринта (список задач из бэклога продукта, которые будут выполняться в ближайшем спринте разработки).
Команда разработки может менять бэклог текущего спринта — добавлять возникшие по ходу задачи, обновлять оценки, убирать задачи ставшие неактуальными. Заказчик может влиять на бэклог продукта — список задач и приоритеты могут меняться, в зависимости от потребностей, новых идей или изменяющихся условий.
Имеет смысл сразу готовить бэклоги на два-три следующие спринта, чтобы проработка деталей по каждому шла на 1−2 спринта быстрее разработки. Это позволит достичь оптимальной скорости — после завершения спринта можно будет сразу переходить к следующему.
Использование бэклогов в большинстве случаев позволяет полностью отказаться от ТЗ, получив более гибкую разработку, а бонусом — сэкономить несколько недель на в начале проекта.
Обычно составляется бэклог продукта (общие требования к разработке всего продукта) и бэклог спринта (список задач из бэклога продукта, которые будут выполняться в ближайшем спринте разработки).
Команда разработки может менять бэклог текущего спринта — добавлять возникшие по ходу задачи, обновлять оценки, убирать задачи ставшие неактуальными. Заказчик может влиять на бэклог продукта — список задач и приоритеты могут меняться, в зависимости от потребностей, новых идей или изменяющихся условий.
Имеет смысл сразу готовить бэклоги на два-три следующие спринта, чтобы проработка деталей по каждому шла на 1−2 спринта быстрее разработки. Это позволит достичь оптимальной скорости — после завершения спринта можно будет сразу переходить к следующему.
Использование бэклогов в большинстве случаев позволяет полностью отказаться от ТЗ, получив более гибкую разработку, а бонусом — сэкономить несколько недель на в начале проекта.
Краткие выводы
- Начинайте с MVP. Не раздувайте его — включите в него только самые важные функции, на основе которых вы сможете протестировать свою гипотезу. О том, как приоритизировать задачи, мы рассказываем здесь.
- Проверяйте самые рискованные гипотезы. Старайтесь в начале сделать самое сложное.
- Обязательно проводите живое тестирование проекта. Никакая аналитика его не заменит.
- Проектируйте методом набегающей волны — не стремитесь сделать всеохватывающее ТЗ, прорабатывайте спринты максимум на месяц-полтора вперед. Возникающие по ходу проекта дополнительные задачи добавляйте в следующие спринты.
- И основной совет: не бойтесь изменений в начальной концепции, если это улучшит ваш проект. Современные реалии требуют гибкости и быстрого приспособления к новым условиям. И SCRUM идеально подходит для разработки в таких реалиях.