Как грамотно составить задание для программиста

Любому, кто запускал хотя бы пару проектов, на фрилансе знакома ситуация, когда срывается срок по причине болезни бабушки у программиста, попадания в аварию и прочих стандартных уважительных причин. Генеральный директор Bright Mobile разбирается, как снизить риски провала ещё на старте.

В обратную сторону ситуация схожа. Многие компетентные исполнители (проблема актуальна же не только для программирования) жалуются на аналогичное поведение заказчиков: задержку постоплаты, требования выполнить не оговоренные ранее работы под предлогом «это же логично» или «сделай бесплатно, получишь второй проект» и так далее.

Само собой, причина этих проблем либо в желании откровенно кинуть партнёра, либо в недоговорённостях на старте. Про обман в этой статье писать не буду: это отдельный объёмный материал, связанный с юридической грамотностью и своевременностью подписания бумаг. Сегодня речь про второй вариант, когда «вроде договорились, но каждый понял по-своему» и о том, как избежать связанных с этим проблем.

Обычно процесс идёт по двум сценариям. Либо крупная подготовительная работа с написанием большого ТЗ и уточнением всех нюансов, либо, наоборот, прошлись по верхам, а детали обсудим в процессе. И у того и у другого способа есть плюсы и минусы. Уверен, большинству читателей они знакомы, но давайте всё-таки зафиксируем, чтобы было от чего отталкиваться.

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

Плюсы:

Минусы:

К слову, самое большое ТЗ, которое нам приходило на оценку — 136 страниц двенадцатым шрифтом. Я отказался его брать в работу даже на оценку, так как времени потратил бы столько же, сколько на семь-десять других клиентов, но с меньшей конверсией в продажу.

Не стоит забывать, что как заказчику важно быстро оценить проект, чтобы понимать, подходит студия по бюджету или нет, так и исполнителю важно усвоить только важные данные по проекту, чтобы грамотно дать предварительную оценку. Да, если предварительная оценка устраивает, то можно уточнять и корректировать её, но обеим сторонам важно видеть, совпадает ли порядок цен на требуемый объём работ и бюджет, который готов вложить заказчик.

Немного изменил распространённое выражение, чтобы редакция не забанила, но общая суть второго подхода иллюстрируется им лучше всего. Это происходит, когда заказчик считает работы достаточно простыми и не требующими обсуждения. Шутки в стиле «там всего лишь лендинг с функцией магазина и социальной сети» и «что там делать этот Google, там же одна строка поиска» из той же оперы.

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

Процесс практически идентичен процессу выше за исключением того, что на первом этапе проговаривается базовая идея и сразу начинается работа

Плюсы:

Минусы:

Принципиальными я вижу следующие вопросы, которые нужно регламентировать в процессе и которые влияют на положительный итог проекта:

Очевидно, ни один из подходов не решает все перечисленные задачи. Поэтому у себя в компании мы пришли к такой схеме проектирования перед реализацией проекта.

Общая оценка. При входящем обращении, в ходе диалога на 15–30 минут или первичной переписки, выясняется идея проекта и основная бизнес-логика. На основе этих данных смотрим, что мы делали или оценивали ранее, какие были бюджеты у похожих приложений.

Как правило, есть три-четыре проекта с похожими идеями и клиенту называется средняя стоимость с индивидуальным дизайном и использованием готовых блоков на Ionic. При этом заказчик решает, что либо он хочет сразу созданный под него дизайн, либо нужно простенькое с точки зрения дизайна приложение, но с экономией до 30% бюджета.

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

Если клиента устраивает оценка, следующий этап — проектирование. Проектирование сводится к пяти основным разделам:

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

Публично показать примеры проектов не могу, так как это будет некрасиво по отношению к клиентам (я против подхода «взять чужую идею и допилить под себя»), но могу показать те проекты, сильно отличающиеся от вашей идеи в индивидуальном порядке. Для этого напишите мне во «ВКонтакте» или Facebook.

Цель этого этапа — додумать за заказчика те или иные решения и согласовать ключевой функционал.

Если проект предполагает разработку дизайна, следующий этап — линкованный прототип (пример), где можно перемещаться между экранами, кликая по кнопкам, и увидеть, как будет работать приложение. Если речь о базовом дизайне, просто показываются примеры приложений с использованием шаблонов Ionic, чтобы клиент на старте понимал, как будет выглядеть приложение.

Часто бывает: в целом шаблоны устраивают, но хочется что-то сделать под себя (поменять цвет, шрифты, подвинуть кнопки). Это оценивается как несколько дополнительных часов работы программиста, и получается, что заказчик получает в дизайне те изменения, которые для него принципиальны, но по стоимости это сильно ниже, чем при создании дизайна с нуля.

Собственно, на этом всё. При удачном стечении обстоятельств и вхождении луны в правильную фазу подписывается договор и приложение переходит к реализации.

В качестве заключения давайте вернёмся к тем важным моментам, которые обозначены в начале статьи, и рассмотрим их решение при таком подходе к проектированию.

Предлагаю такой подход разработчикам сайтов и приложений. Расскажите в комментариях, какие способы используете у себя и какие самые частые проблемы случаются при этих подходах. Буду рад обратной связи по изложенному материалу в том плане, что может пойти не так, если действовать моим путём.