Суть вопроса.
Бытует мнение, что в сольных коммерческих/пет-проектах проще не усложнять. Код пишется одним человеком, ревью нет, масштабируемость, зачастую, не нужна.
В случае, если оплата за работу почасовая, встает вопрос, должен ли заказчик платить за составление документации к проекту.
Но и тут есть свои подводные камни и неочевидные выгоды, как для тебя, так и для заказчика. Давай подробнее рассмотрим вопрос.
ТЗ.
Бизнес-коучи, мотиваторы, инфо-цыганe — все они продвигают понятную и простую идею: у тебя должен быть четкий план. Так оно и есть, вспомни, как с утра приходишь на работу и не знаешь, за что бы взяться, с какой стороны подойти.
Так вот ТЗ — это и есть план. Четкое руководство что, куда и зачем должно нажиматься, всплывать, звучать.
ТЗ — это метрика, по которой можно оценивать проделанную работу. Чем конкретнее будут требования в тех. задании, тем проще тебе будет организовать работу.
Как составить ТЗ и получить за это оплату?
В компаниях есть менеджеры, аналитики, выделенные процессы, направленные на сбор хотелок у бизнеса и конвертацию их в бизнес, пользовательские и функциональные требования.
Для нас такой подход — непозволительная роскошь, потому что заказчик хочет получить все вчера, а платить за то, чтобы «калякать» бумажки — не хочет. Как тогда быть?
Во-первых, нужно объяснить заказчику, зачем составлять ТЗ. Самая очевидная выгода — экономия времени. А время — деньги. Можешь прямо так и сказать — ТЗ экономит деньги.
Помните, что каждая минута, потраченная на планирование, экономит десять минут вашего труда.
Брайан Трейси.
Во-вторых, начинай собирать ТЗ, как только заказчик начал рассказывать про проект. Уверен, все мы прекрасно можем обойтись без бизнес и функциональных требований, формируя ТЗ только из юзкейсов.Что за юзкейсы?
Не бойся задавать вопросы заказчику из серии «что будет, если нажать сюда, а если сюда?». Тебе это поможет в составлении ТЗ, а ему даст лишнюю возможность поговорить о своем продукте (не забывай хвалить идеи заказчика, чтобы он рассказал тебе как можно больше).
Обязательно структурируй полученные ответы. ТЗ должно отвечать на вопросы:
- что делает система?
- из каких частей состоит система?
- кто клиенты системы?
- какие группы клиентов есть в системе?
- как группы клиентов используют части системы?
Соответсвенно, чем больше система, тем больше будет ТЗ.
Архитектура.
Многие начинающие разработчики не отличают архитектуру от структуры проекта. Архитектура отвечает на вопрос «как части системы взаимодействуют между собой», а структура — «как части системы разбиты на файлы».
Структура имеет прямую зависимость от архитектуры. Архитектура зависит от бизнес-процессов.
Минимальный элемент архитектуры — компонент. Минимальный элемент структуры — файл. компонент может быть представлен как одним, так и группой файлов.
Из вышесказанного можно сделать вывод: от выбранной архитектуры будет зависеть количество файлов проекта и их сложность. С подходящей архитектурой каждый отдельно взятый файл будет иметь конкретную роль в проекте (я не беру в расчет системные файлы, инструментальные файлы и файлы конфигураций).
Как продать архитектуру?
Выбор архитектуры тоже занимает время, а работать бесплатно не хочется.
Все мы знаем, что заказчику плевать, насколько красивая система внутри, главное, чтобы работало.
Как и в случае с ТЗ, первым делом необходимо понять, какую выгоду получит заказчик от правильно подобранной архитектуры. Масштабируемость и гибкость навряд ли его впечатлят, а вот устойчивость — это сильный козырь.
Да, хорошая архитектура многократно повышает устойчивость системы. Благодаря этому заказчик получит меньше сбоев, в следствие — меньше простоев, больше денег.
Вывод.
Решение «не усложнять» почти всегда приводит к срыву сроков и дополнительным расходам. Но надо помнить, что бюджет и сроки у нас строго ограничены.
Когда я обсуждаю с заказчиком этапы, я предлагаю два варианта действий:
- Начинаю с проектирования, потом пишу код.
- Сразу пишу код.
После этого поясняю, что в первом случае первый осязаемый результат будет немного позже, чем во втором, но суммарный срок будет меньше, потому что будут проработаны возможные ошибки и связанные с ними задержки.
