Итак, у вас появилась идея для нового проекта, неважно, что это: разработка нового сервиса, дополнительный раздел текущего проекта или, например, автоматизация процесса. Вот несколько советов о том, что важно сделать перед началом разработки, чтобы увеличить шансы реализовать свою идею с минимальной потерей нервов и денег.
Сократите первоначальный объем работ до необходимого минимума
В нашей практике мы часто сталкиваемся с перегруженными проектами в начале. Когда вы хотите построить космический корабль с нуля, внедрить множество дополнительных функций, создать сервис, который решит все проблемы в мире до их возникновения. Мы всегда стараемся убедить клиентов упростить первые этапы и сократить объем работы, и тому есть множество причин.
Чем сложнее система, тем сложнее и дольше ее разрабатывать. В случае, когда на старте нет работающих функций, даже оценка такого проекта займет слишком много времени, и в то же время будет больше похожа на дикую догадку. Можно детально разобрать 2–3 базовые функции, но каждое добавление — это как продумывать на десятки шагов вперед — с каждой новой деталью точность снижается, а результат далек. Чтобы покрыть риски, программистам приходится увеличивать оценки в несколько раз, но даже этого недостаточно, потому что количество деталей и нюансов часто занижается. А детально описать сложную компонентную систему гораздо сложнее и вероятность того, что мелкие ошибки на каждом этапе со временем будут накапливаться, возрастает. Разработка в этих случаях затягивается, обходится дороже или становится невыгодной как для заказчика, так и для исполнителя, что влечет за собой потерю качества, негатив, срыв сроков.
При этом основная функция системы зачастую занимает менее 20% затрачиваемых ресурсов и уже могла бы принести пользу заказчику и пользователям.
Сложность системы — неизбежная проблема по мере старения проекта: увеличение технического долга, увеличение затрат на поддержку, непредсказуемые проблемы и в некоторых случаях неинтуитивное поведение системы — проблемы продуктов с историей. Но сложность растет постепенно, функции разрабатываются в ответ на реальные потребности пользователей на основе обратной связи, и все это удается приносить прибыль, окупая растущие затраты. Если вы можете начать с простого, лучше так и сделать.
К тому же не факт, что тот набор функций, который вы так тщательно продумали и на который потратили время и деньги, будет нужен реальным пользователям. Так что если делаете что-то новое — по возможности начинайте только с того, что вам нужно, чтобы как можно быстрее получить обратную связь и понять, где и что нужно подправить, а что не важно.
Сформулируйте ожидания
Вторая распространенная проблема, которая может испортить проект, — это сложность с одинаковым пониманием задачи всеми участниками процесса. Да, речь идет о Product Requirement Specification, его существовании и прочих проблемах с ним. Можно много говорить о Технических требованиях к продукту и их составлении, в следующих статьях мы к ним вернемся, сейчас же выделим несколько простых, но важных моментов.
Если отбросить формальности, то Техническое задание на продукт в первую очередь необходимо для того, чтобы все стороны одинаково понимали задачу и говорили об одном и том же. Изначально, когда есть идея проекта, понимание того, что должно быть реализовано, только в голове. И, к сожалению, передать это понимание — сложная задача. По закону Мерфи, если есть малейшая вероятность того, что вас неправильно поймут, вас неправильно поймут. Какие-то вещи не скажешь, думая, что они подразумеваются, что-то обязательно будет неправильно понято исполнителем, что-то забудется всеми. Наиболее распространенные проблемные случаи:
1.Отсутствие конкретики и слишком расплывчатое описание, без упоминания критичных для клиента деталей. Представим ситуацию, клиент запрашивает «обычный интернет-магазин: список товаров, корзина, простейшие фильтры». Подрядчик кивает и делает это, и в конце концов сдает:
Получается, что клиент представлял и ожидал в голове это:
Как видите, даже на одной странице стандартного каталога разница между первоначальной сметой подрядчика и тем, что ожидал заказчик, может быть огромной. Возникает конфликт, когда все правы, клиент не получил того, что хотел, хотя ожидал, что это подразумевается и заложено в бюджете, а исполнитель сделал только то, что просили. И проект редко ограничивается одной страницей. Конечно, это не так страшно, если у заказчика нет проблем с добавлением фиксов за дополнительный бюджет, но что делать, если первоначальный бюджет уже израсходован. В этом случае выйти из ситуации без убытка будет проблематично.
2. Вторая проблема обратная — слишком формальное описание в тексте каждой функции в отдельности, без проработки связей между ними и представления о том, как это будет работать в итоге. Часто такое Техническое задание на продукт пишется клиентом, исходя из результатов запросов клиента и его пожеланий. Но в итоге вы получаете многостраничный документ, а сам клиент даже не может внятно сказать, это то, что он себе представлял, или нет. Часто клиент соглашается с ТЗ, не изучая его, потому что все понятно, но копаться в 50+ страницах А4 желания нет. Клиент не получает полного представления о продукте, и, как и в первом случае, кажется, что все так, как должно быть. По крайней мере мысль о том, что что-то не так, сразу не возникает. В итоге получается не совсем то, что ожидал клиент. Хотя такой случай гораздо менее страшен, чем первый, он все же болезненный.
Чтобы решить обе эти проблемы и улучшить первоначальное понимание исполнителя задачи, вот наш совет. Прежде всего, спецификация требований к продукту нужна, чтобы выкинуть идею проблемы из головы в способом, понятным для всех сторон. И нет ничего более однозначного, чем картинка. Картинка всегда проще и лучше объясняет главное. Картинка сразу подскажет, если чего-то не хватает. Гораздо проще понять, как связаны компоненты системы. Даже процесс визуализации своих мыслей в осязаемый результат уже заставит вас продумать все моменты и выявить неочевидные проблемы. Это сэкономит деньги и время. Конечно, будут нужны описания картинок, пояснения сложных моментов и так далее. Но это будут объяснения поверх общего понимания. Будет намного проще получить картинку в голове, чем продираться через тонны текста формальных спецификаций требований к продукту.
Мы говорим о прототипировании. С этим могут помочь дизайнеры, но первоначальную визуализацию лучше сделать самому, хотя бы прочувствовать свою идею. Он не требует специальных инструментов. Достаточно схемы вручную на бумаге или схематических блоков (прямоугольники, линии, текст) с помощью figma.com. В случаях, когда картинка не подходит, как при внутренних расчетах условий автоматизации процесса, придумайте 2–3 примера того, как должна работать система, если бы вам пришлось выполнять процесс вручную.
Свяжитесь с нами, чтобы обсудить ваш проект
А с минимизированным заданием и прототипом мы без проблем реализуем ваш проект. Тем не менее, другие разработчики будут довольны проектом с таким вкладом, поэтому мы все равно рекомендуем его. Что важно сделать при разработке, чтобы еще больше минимизировать проблемы и быть уверенным, что все идет как надо — расскажем в следующих статьях.
