ТЗ и архитектура в сольном проекте. Ахилесова пята или сизифов труд?
В прошлой статье мы разобрали основные правила совмещения сторонних проектов с full-time работой. Теперь я постараюсь более атомарно показать процессы и этапы таких проектов.
Начнем с начала — составление ТЗ и проектирование системы.
Краткое содержание.
Составление ТЗ и проектирование системы — важные этапы даже для сольных проектов. Любые работы лучше начинать именно с этих этапов, несмотря на размер команды и проекта в целом.
Учитывая специфику заказной разработки и «бесполезность» технической документации для заказчика, утвердить эти этапы, как оплачиваемую работу, бывает сложно. Тут, как в любых переговорах, стоит занять сильную позицию — в нашем случае, это указание заказчику на очевидные временные и денежные расходы, которые повлечет за собой разработка «вслепую».
ТЗ необходимо максимально ужать, но не терять ключевые элементы. Проектирование, определенно, должно проходить в кратчайшие сроки.
Хороший выход, как я считаю, предложить заказчику два плана работ, включающий и исключающий проектирование. При этом план с этапом проектирования должен выглядеть более выигрышным.
Суть вопроса.
Бытует мнение, что в сольных коммерческих/пет-проектах проще не усложнять. Код пишется одним человеком, ревью нет, масштабируемость, зачастую, не нужна.
В случае, если оплата за работу почасовая, встает вопрос, должен ли заказчик платить за составление документации к проекту.
Но и тут есть свои подводные камни и неочевидные выгоды, как для тебя, так и для заказчика. Давай подробнее рассмотрим вопрос.
ТЗ.
Бизнес-коучи, мотиваторы, инфо-цыганe — все они продвигают понятную и простую идею: у тебя должен быть четкий план. Так оно и есть, вспомни, как с утра приходишь на работу и не знаешь, за что бы взяться, с какой стороны подойти.
Так вот ТЗ — это и есть план. Четкое руководство что, куда и зачем должно нажиматься, всплывать, звучать.
ТЗ — это метрика, по которой можно оценивать проделанную работу. Чем конкретнее будут требования в тех. задании, тем проще тебе будет организовать работу.
Как составить ТЗ и получить за это оплату?
В компаниях есть менеджеры, аналитики, выделенные процессы, направленные на сбор хотелок у бизнеса и конвертацию их в бизнес, пользовательские и функциональные требования.
Для нас такой подход — непозволительная роскошь, потому что заказчик хочет получить все вчера, а платить за то, чтобы «калякать» бумажки — не хочет. Как тогда быть?
Во-первых, нужно объяснить заказчику, зачем составлять ТЗ. Самая очевидная выгода — экономия времени. А время — деньги. Можешь прямо так и сказать — ТЗ экономит деньги.
Помните, что каждая минута, потраченная на планирование, экономит десять минут вашего труда.
Брайан Трейси.
Во-вторых, начинай собирать ТЗ, как только заказчик начал рассказывать про проект. Уверен, все мы прекрасно можем обойтись без бизнес и функциональных требований, формируя ТЗ только из юзкейсов.
Что за юзкейсы?
Use case — вариант использования. Простым языком — что получит пользователь, сделав определенное действие с системой.
Пример: пользователь нажимает на кнопку со знаком вопроса и попадает на страницу с FAQ.
Не бойся задавать вопросы заказчику из серии «что будет, если нажать сюда, а если сюда?». Тебе это поможет в составлении ТЗ, а ему даст лишнюю возможность поговорить о своем продукте (не забывай хвалить идеи заказчика, чтобы он рассказал тебе как можно больше).
Обязательно структурируй полученные ответы. ТЗ должно отвечать на вопросы:
что делает система?
из каких частей состоит система?
кто клиенты системы?
какие группы клиентов есть в системе?
как группы клиентов используют части системы?
Соответсвенно, чем больше система, тем больше будет ТЗ.
Пример ТЗ из юзкейсов
Сайт с новостями про сельское хозяйство.
Сайт состоит из главной страницы, страницы профиля, страницы настроек.
На сайте сидят фермеры, менеджеры магазинов и агрохолдингов.
На сайте есть читатели, редакторы новостей, админы.
Читатель может:
зарегистрироваться/авторизоваться через email
перейти в ленту новостей
прочитать новость
оценить новость
комментировать новость
пожаловаться на новость
перейти в настройки
сменить тему
включить / отключить уведомления на почту
…
и так далее.
Архитектура.
Многие начинающие разработчики не отличают архитектуру от структуры проекта. Архитектура отвечает на вопрос «как части системы взаимодействуют между собой», а структура — «как части системы разбиты на файлы».
Структура имеет прямую зависимость от архитектуры. Архитектура зависит от бизнес-процессов.
Минимальный элемент архитектуры — компонент. Минимальный элемент структуры — файл. компонент может быть представлен как одним, так и группой файлов.
Для тех, кого пугает слово компонент.
Не путай компонент и библиотеку. Вот пример копмонента для расчета стоимости подписки:
class SubscriptionCostCalculator {
int calculate(int baseCost, int? discount) {
return baseCost - discount ?? 0;
}
}5 строк кода, но это тоже компонент. Вот еще примеры компонентов:
форма регистрации,
обработчик нажатия,
сервис показа уведомлений.
Компонент — минимальная единица системы, выполняющая какую-то полезную работу. Компонент может состоять из других компонентов.
Из вышесказанного можно сделать вывод: от выбранной архитектуры будет зависеть количество файлов проекта и их сложность. С подходящей архитектурой каждый отдельно взятый файл будет иметь конкретную роль в проекте (я не беру в расчет системные файлы, инструментальные файлы и файлы конфигураций).
Как продать архитектуру?
Выбор архитектуры тоже занимает время, а работать бесплатно не хочется.
Все мы знаем, что заказчику плевать, насколько красивая система внутри, главное, чтобы работало.
Как и в случае с ТЗ, первым делом необходимо понять, какую выгоду получит заказчик от правильно подобранной архитектуры. Масштабируемость и гибкость навряд ли его впечатлят, а вот устойчивость — это сильный козырь.
Да, хорошая архитектура многократно повышает устойчивость системы. Благодаря этому заказчик получит меньше сбоев, в следствие — меньше простоев, больше денег.
Вывод.
Решение «не усложнять» почти всегда приводит к срыву сроков и дополнительным расходам. Но надо помнить, что бюджет и сроки у нас строго ограничены.
Когда я обсуждаю с заказчиком этапы, я предлагаю два варианта действий:
Начинаю с проектирования, потом пишу код.
Сразу пишу код.
После этого поясняю, что в первом случае первый осязаемый результат будет немного позже, чем во втором, но суммарный срок будет меньше, потому что будут проработаны возможные ошибки и связанные с ними задержки.
Мягких клавиш, друзья.
