Советы для тех, кто планирует новый проект

Итак, у вас появилась идея для нового проекта, неважно что это: разработка нового сервиса, дополнительный раздел текущего проекта или, например, автоматизация процесса. Вот пара советов, что важно сделать до старта разработки, чтобы повысить шансы на выполнение задуманного с минимальными потерями нервов и денег.

В нашей практике мы часто встречались с кейсами перегруженных на старте проектов. Когда хочется с нуля сделать сразу космический корабль, реализовать кучу дополнительных функций, сделать сервис решающий все проблемы на свете еще до их возникновения. Мы всегда стараемся убедить клиентов по возможности упрощать первые этапы и сокращать объемы работ, и на это есть масса причин.

Чем сложнее система, тем очевидно труднее и дольше ее разрабатывать. В случае когда на старте нет еще никаких работающих функций, даже оценка такого проекта займет слишком много времени, и при том будет скорее «пальцем в небо». Можно детально разобрать 2-3 базовые функции, но каждое дополнение это как мыслить еще на десятки шагов вперед — с каждой новой деталью точность уменьшается, а результат отдаляется. Чтобы покрыть риски исполнители вынуждены завышать оценки в несколько раз, но и этого бывает мало, так как количество деталей и нюансов часто недооценивается в разы. Да и описать подробно сложную составную систему намного сложнее и возрастает шанс, что в итоге небольшие ошибки на каждом этапе перемножатся, а не сложатся. Разработка в этих случаях затягивается, стоит дороже либо становится убыточной как для клиента так и для исполнителя, что вызывает потерю качества, негатив, затягивание сроков.

При том основная функция системы часто занимает менее 20% затраченных ресурсов и уже могла бы наносить пользу заказчику и пользователям.

Сложность системы — неминуемая проблема с возрастом проекта: нарастающий технический долг, увеличивающая стоимость поддержки, непредсказуемые проблемы и неинтуитивное поведение системы в некоторых кейсах — боли продуктов со стажем. Но сложность нарастает постепенно, функции разрабатываются отвечая на реальные потребности пользователей на основе обратной связи, и все это успевает принести прибыль, окупая возрастающие стоимости. Если можете начать с простого — намного выгоднее так и сделать.

Да к тому же не факт что ворох функций, который вы так тщательно продумывали и тратили на них время и деньги будет нужен реальным пользователям. Поэтому если делаете что-то новое — по возможности начните только с необходимого, чтобы как можно быстрее получить обратную связь и понимать: где и что нужно докрутить, а что не важно.

Вторая распространенная проблема способная подкосить проект — это сложности с донесением задачи и одинаковым ее пониманием всеми участниками процесса. Да да, речь о ТЗ, его наличии и других проблемах с ним. О технических заданиях и их составлении можно говорить много, в следующих статьях к ним вернемся, сейчас же осветим некоторые простые, но важные моменты.

Если отбросить формальности то ТЗ в первую очередь необходимо для того, чтобы все стороны понимали задачу одинаково и говорили об одном и том же. Изначально когда появляется идея проекта, понимание того, что должно быть реализовано — только у вас в голове. И к сожалению передать это понимание — сложная задача. По закону подлости если есть хоть малейшая вероятность того, что вас могут понять неправильно, то вас поймут неправильно. Часть моментов вы не озвучите, думая что они очевидно подразумеваются, часть обязательно неверно поймет исполнитель, про что-то забудут все. Самыми частыми проблемными кейсами бывают:

1) Отсутствие конкретики и слишком общее описание, без упоминаний о деталях критичных клиенту. Представим ситуацию, клиент просит «обычный интернет-магазин сами знаете, что объяснять: список товаров, корзина, простейшие фильтры». Исполнитель кивает, делает и в итоге сдает это:

Клиент же оказывается в голове представлял и ожидал вот это:

Как видим, даже на одной странице типового каталога разница между первоначальной оценкой работ исполнителем и тем, что ожидал заказчик может быть громадна. Возникает конфликт где каждый прав, клиент не получил, что хотел, хотя ожидал, что это подразумевается и входит в бюджет, а исполнитель сделал только то, что просили и уперся в ресурсы. А проект редко ограничивается одной страницей. Конечно это не так страшно, если для заказчика не проблема доделать за доп бюджет выясненные теперь доработки, но что если изначальный бюджет был уже в упор или финансирование стороннее и зафиксированное. В этом случае выйти из ситуации без потерь будет проблематично.

2) Вторая проблема — наоборот слишком формальное расписывание текстом каждой функции отдельно, без проработки связей между ними и представления «а как это в итоге будет работать». Часто такое ТЗ составляется самим исполнителем, по итогам расспросов клиента и на основании его пожеланий. Но в итоге получается громадный многостраничный документ, по которому и сам заказчик не может четко сказать, а то ли это, что он представлял или нет. Часто клиент соглашается с этим тз, не изучив его полностью, потому что в целом речь о чем то похожем, а вникать в 50+ страниц А4 не тянет. Тем более, что представления о продукте по такому описанию часто не возникает, и, как и в первом случае, кажется, что описано все что нужно и как нужно. По крайней мере сразу не всплывает мысль, что что-то не так. Хоть такой случай и намного менее страшен, чем первый, но с учетом того, что в проработку такого ТЗ уже вложено немало сил, и кажется, что ну теперь то «всем все понятно», то что в итоге получается не то, что ожидалось в голове — еще обиднее.

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

По сути речь идет о прототипировании, с этим могут помочь дизайнеры, но первичную визуализацию полезно проделать самим, как минимум, чтоб пощупать собственную идею. Для этого не обязательны специальные инструменты, хватит схемы вручную на бумаге или схематичных блоков (прямоугольники, линии, текст) с помощью figma. com, дерзайте. Ну а в случаях где картинка неуместна, например во внутренних расчетах условий для автоматизации процесса — вместо картинки сядьте и придумайте пошагово 2-3 примера, как должна работать система если бы нужно было выполнять процесс вручную. Какие исходные данные и откуда она должна взять, что проверить и что сделать в случае ваших конкретных примеров.

И с минимизированной задачей и понятным прототипом мы без проблем реализуем ваш проект:) Впрочем и другие разработчики будут рады проекту с такими вводными, так что рекомендуем в любом случае. Что же полезно и важно делать уже во время разработки, чтобы еще больше минимизировать проблемы и быть уверенным, что все движется как надо — расскажем в следующих статьях