Как грамотно составить задание для программиста
Любому, кто запускал хотя бы пару проектов, на фрилансе знакома ситуация, когда срывается срок по причине болезни бабушки у программиста, попадания в аварию и прочих стандартных уважительных причин. Генеральный директор Bright Mobile разбирается, как снизить риски провала ещё на старте.
В обратную сторону ситуация схожа. Многие компетентные исполнители (проблема актуальна же не только для программирования) жалуются на аналогичное поведение заказчиков: задержку постоплаты, требования выполнить не оговоренные ранее работы под предлогом «это же логично» или «сделай бесплатно, получишь второй проект» и так далее.
Само собой, причина этих проблем либо в желании откровенно кинуть партнёра, либо в недоговорённостях на старте. Про обман в этой статье писать не буду: это отдельный объёмный материал, связанный с юридической грамотностью и своевременностью подписания бумаг. Сегодня речь про второй вариант, когда «вроде договорились, но каждый понял по-своему» и о том, как избежать связанных с этим проблем.
Стандартные процессы разработки
Обычно процесс идёт по двум сценариям. Либо крупная подготовительная работа с написанием большого ТЗ и уточнением всех нюансов, либо, наоборот, прошлись по верхам, а детали обсудим в процессе. И у того и у другого способа есть плюсы и минусы. Уверен, большинству читателей они знакомы, но давайте всё-таки зафиксируем, чтобы было от чего отталкиваться.
Большое и долгое ТЗ
На картинке я показал, что ТЗ прорабатывается до КП, но некоторые студии меняют эти этапы местами. Для текущего вопроса это не принципиально, поэтому я объединил в один формат.
Плюсы:
- Исполнитель и заказчик достаточно плотно разобрались в проекте и согласовали хотя бы глобальные вопросы, что снижает риск недопонимания.
- ТЗ прикладывается к договору и в случае проблем можно будет вспомнить и разобраться, нужно ли реализовать те или иные функции.
Минусы:
- В ходе реализации проекта у заказчика может поменяться виденье того или иного блока, что приведёт к переписыванию ТЗ, заключению дополнительного договора и тратам.
- Если работает команда, то не стоит надеяться, что за огромной кучей страниц ТЗ каждый из участников проекта увидит именно ту идею, которая лежала изначально. Расфокусировка будет обязательно.
- Без гарантий заключения сделки мало кто из исполнителей будет помогать с грамотным составлением ТЗ.
- Если покупать написание ТЗ, то опять же есть шанс, что будет написан огромный, технически верный проект, не отражающий, однако, ключевых требований.
К слову, самое большое ТЗ, которое нам приходило на оценку — 136 страниц двенадцатым шрифтом. Я отказался его брать в работу даже на оценку, так как времени потратил бы столько же, сколько на семь-десять других клиентов, но с меньшей конверсией в продажу.
Не стоит забывать, что как заказчику важно быстро оценить проект, чтобы понимать, подходит студия по бюджету или нет, так и исполнителю важно усвоить только важные данные по проекту, чтобы грамотно дать предварительную оценку. Да, если предварительная оценка устраивает, то можно уточнять и корректировать её, но обеим сторонам важно видеть, совпадает ли порядок цен на требуемый объём работ и бюджет, который готов вложить заказчик.
Хоп-хоп и в продакшн
Немного изменил распространённое выражение, чтобы редакция не забанила, но общая суть второго подхода иллюстрируется им лучше всего. Это происходит, когда заказчик считает работы достаточно простыми и не требующими обсуждения. Шутки в стиле «там всего лишь лендинг с функцией магазина и социальной сети» и «что там делать этот Google, там же одна строка поиска» из той же оперы.
Привожу эти примеры не для издёвки, а как иллюстрацию задачи с точки зрения пользовательского интерфейса, его сложности, многогранности реализации. При такой подаче процесс исполнения выглядит так:
Процесс практически идентичен процессу выше за исключением того, что на первом этапе проговаривается базовая идея и сразу начинается работа
Плюсы:
- Все участники проекта понимают цель и причины реализации проекта.
- При изменении какого-либо блока он обсуждается в процессе и реализуется под требования клиента, если не сильно меняет объём работ.
- На этапе продажи легко оценить проект и перейти к договору, если цена устраивает.
Минусы:
- Большой шанс, что может появиться уточнение, которое сильно влияет на бюджет, но клиент предполагал, что она уже входит в стоимость.
- При конфликтных ситуациях вопрос решается только путём переговоров без документальных свидетельств, что и как точно нужно сделать.
Выводы из обоих подходов
Принципиальными я вижу следующие вопросы, которые нужно регламентировать в процессе и которые влияют на положительный итог проекта:
- Вся команда должна чётко понимать основную идею и ключевые функции.
- Основные, влияющие на стоимость работы должны быть прописаны в ТЗ.
- Должна быть возможность мягкого и понятного ценообразования изменений.
- На старте, без серьёзных временных затрат, нужно иметь возможность дать предварительную оценку, которая не сильно (не более, чем на 20%) изменится после уточнения деталей.
Очевидно, ни один из подходов не решает все перечисленные задачи. Поэтому у себя в компании мы пришли к такой схеме проектирования перед реализацией проекта.
Общая оценка. При входящем обращении, в ходе диалога на 15–30 минут или первичной переписки, выясняется идея проекта и основная бизнес-логика. На основе этих данных смотрим, что мы делали или оценивали ранее, какие были бюджеты у похожих приложений.
Как правило, есть три-четыре проекта с похожими идеями и клиенту называется средняя стоимость с индивидуальным дизайном и использованием готовых блоков на Ionic. При этом заказчик решает, что либо он хочет сразу созданный под него дизайн, либо нужно простенькое с точки зрения дизайна приложение, но с экономией до 30% бюджета.
Для примера — скриншоты формы заявки на перевозку в двух логистических приложениях. При похожей функциональности, первое на 20 экранов в базовом дизайне стоило порядка 250 тысяч рублей, второе, с индивидуальным дизайном — более 500 тысяч рублей.
Разработка проекта
Если клиента устраивает оценка, следующий этап — проектирование. Проектирование сводится к пяти основным разделам:
- Вводная задача от клиента: та самая идея, которой должно быть пронизано всё приложение.
- User-case: описание последовательной логики работы всеми ролями пользователей.
- Структура: список экранов приложения с указанием на цель того или иного экрана и принципы его работы, а также дополнительные функции (интеграции с 1С и эквайрингом, авторизации через соцсети и прочее на что не требуется доп экраны).
- Смета: рассчитывается стоимость работ на основе количества экранов и сложности дополнительных функций. Для проектов с базовым дизайном и индивидуальным, само собой, стоимость экранов разная, поскольку отличается объём работ, а дополнительные функции считаются по временным трудозатратам.
- Рекомендации: на основе опыта работы с подобными проектами даём рекомендации по развитию сервиса после запуска.
Важно, чтобы объём проекта занимал менее восьми страниц, а в приложении было меньше 30 экранов. Если получается больше, есть шанс сильно запутаться в деталях. В таком случае нужно часть менее приоритетного функционала обязательно выносить на вторую версию. Если важно всё, то можно первую версию не публиковать, а использовать такой подход для упрощения внутренней работы и взаимодействия.
Цель этого этапа — додумать за заказчика те или иные решения и согласовать ключевой функционал.
Прототипирование
Если проект предполагает разработку дизайна, следующий этап — линкованный прототип (пример), где можно перемещаться между экранами, кликая по кнопкам, и увидеть, как будет работать приложение. Если речь о базовом дизайне, просто показываются примеры приложений с использованием шаблонов Ionic, чтобы клиент на старте понимал, как будет выглядеть приложение.
Часто бывает: в целом шаблоны устраивают, но хочется что-то сделать под себя (поменять цвет, шрифты, подвинуть кнопки). Это оценивается как несколько дополнительных часов работы программиста, и получается, что заказчик получает в дизайне те изменения, которые для него принципиальны, но по стоимости это сильно ниже, чем при создании дизайна с нуля.
Собственно, на этом всё. При удачном стечении обстоятельств и вхождении луны в правильную фазу подписывается договор и приложение переходит к реализации.
Заключение
В качестве заключения давайте вернёмся к тем важным моментам, которые обозначены в начале статьи, и рассмотрим их решение при таком подходе к проектированию.
- Понимание идеи всей командой. Благодаря расписанному юзер-кейсу и чёткой структуре, а также небольшому объёму информации, любой участник проекта понимает, что он делает и какая цель того или иного блока.
- Принципиальная функциональность. Все важные функции и экраны описаны в структуре. Заказчик тоже через ценообразование понимает, что, например, добавить новое поле в экран заявки дополнительных денег стоить не будет, но если нужно сделать новый экран или подключить эквайринг, который изначально не был заложен, то это дополнительные деньги.
- Понятное ценообразование. Ещё на этапе проекта в разделе сметы показывается, что каждый экран стоит, например, 11 тысяч рублей, значит, и при добавлении ещё одного стоимость экрана будет такая же. Если интеграция трёх соцсетей стоит 4800 рублей за каждую, четвёртая будет стоить те же 4800 рублей.
- Предварительная оценка. На этапе пресейла не пишутся и не изучаются никакие длинные документы, а вопрос «сколько примерно стоит» решается за 15-30 минут.
Предлагаю такой подход разработчикам сайтов и приложений. Расскажите в комментариях, какие способы используете у себя и какие самые частые проблемы случаются при этих подходах. Буду рад обратной связи по изложенному материалу в том плане, что может пойти не так, если действовать моим путём.
в ходе диалога на 15-30 мин или первичной переписки, выясняется идея проекта и основная бизнес-логика.
Первым этапом идет обсуждение цены от и примерный диапазон до.
А после подписание договора и написание ТЗ.
Иначе можно впустую тратить деньги на клиентов, которые просто интересуются. Исполнитель потратит свое время, а клиент сделает "там где дешевле".
"К слову, самое большое ТЗ, которое нам приходило на оценку - это 136 страниц 12-м шрифтом. Я отказался его брать в работу даже на оценку"
ТЗ на простые модули для сайтов начинаются от 40-50 страниц A4.
Аналитики, которые работали с принципиальными разработчиками, понимают важность подробного и четко сформированного ТЗ.
Читая ТЗ разработчик должен уже с первых слов понимать, о чем проект, для чего и как его примерно реализовать.
В что с бабушкой? Тема статьи не раскрыта...
Просто громкий заголовок и потом шум, сорян чо не ту статью читаем.
знакома ситуация, когда срывается срок по причине болезни бабушки у программиста, попадания в аварию ну и прочих стандартных "уважительных причин"Встречается исключительно у новичков (то есть БУДУЮЩИХ или ЖЕЛАЮЩИХ БЫТЬ) специалистов.
Довольно даже средний уровень программиста достигается сложной и долгой работой, там уже хорошие зарплаты и потому в нем работают в большей части довольно матерые ребята.
Не просто так зп мидла даже на таком "дешевом" языке как PHP по Москве идет в интервале 100-140К
Вы так говорите, как-будто крупные компании не факапят сроки
Название статьи не совсем соответствует содержанию.
Вы же просто пишете, как работаете с клиентами и делаете проекты, не более. Причем здесь "болезнь бабушки"?