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

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

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

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

Стандартные процессы разработки

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

Большое и долгое ТЗ

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

Плюсы:

  1. Исполнитель и заказчик достаточно плотно разобрались в проекте и согласовали хотя бы глобальные вопросы, что снижает риск недопонимания.
  2. ТЗ прикладывается к договору и в случае проблем можно будет вспомнить и разобраться, нужно ли реализовать те или иные функции.

Минусы:

  1. В ходе реализации проекта у заказчика может поменяться виденье того или иного блока, что приведёт к переписыванию ТЗ, заключению дополнительного договора и тратам.
  2. Если работает команда, то не стоит надеяться, что за огромной кучей страниц ТЗ каждый из участников проекта увидит именно ту идею, которая лежала изначально. Расфокусировка будет обязательно.
  3. Без гарантий заключения сделки мало кто из исполнителей будет помогать с грамотным составлением ТЗ.
  4. Если покупать написание ТЗ, то опять же есть шанс, что будет написан огромный, технически верный проект, не отражающий, однако, ключевых требований.

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

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

Хоп-хоп и в продакшн

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

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

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

Плюсы:

  1. Все участники проекта понимают цель и причины реализации проекта.
  2. При изменении какого-либо блока он обсуждается в процессе и реализуется под требования клиента, если не сильно меняет объём работ.
  3. На этапе продажи легко оценить проект и перейти к договору, если цена устраивает.

Минусы:

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

Выводы из обоих подходов

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

  • Вся команда должна чётко понимать основную идею и ключевые функции.
  • Основные, влияющие на стоимость работы должны быть прописаны в ТЗ.
  • Должна быть возможность мягкого и понятного ценообразования изменений.
  • На старте, без серьёзных временных затрат, нужно иметь возможность дать предварительную оценку, которая не сильно (не более, чем на 20%) изменится после уточнения деталей.

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

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

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

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

Разработка проекта

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

  • Вводная задача от клиента: та самая идея, которой должно быть пронизано всё приложение.
  • User-case: описание последовательной логики работы всеми ролями пользователей.
  • Структура: список экранов приложения с указанием на цель того или иного экрана и принципы его работы, а также дополнительные функции (интеграции с 1С и эквайрингом, авторизации через соцсети и прочее на что не требуется доп экраны).
  • Смета: рассчитывается стоимость работ на основе количества экранов и сложности дополнительных функций. Для проектов с базовым дизайном и индивидуальным, само собой, стоимость экранов разная, поскольку отличается объём работ, а дополнительные функции считаются по временным трудозатратам.
  • Рекомендации: на основе опыта работы с подобными проектами даём рекомендации по развитию сервиса после запуска.

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

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

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

Прототипирование

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

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

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

Заключение

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

  • Понимание идеи всей командой. Благодаря расписанному юзер-кейсу и чёткой структуре, а также небольшому объёму информации, любой участник проекта понимает, что он делает и какая цель того или иного блока.
  • Принципиальная функциональность. Все важные функции и экраны описаны в структуре. Заказчик тоже через ценообразование понимает, что, например, добавить новое поле в экран заявки дополнительных денег стоить не будет, но если нужно сделать новый экран или подключить эквайринг, который изначально не был заложен, то это дополнительные деньги.
  • Понятное ценообразование. Ещё на этапе проекта в разделе сметы показывается, что каждый экран стоит, например, 11 тысяч рублей, значит, и при добавлении ещё одного стоимость экрана будет такая же. Если интеграция трёх соцсетей стоит 4800 рублей за каждую, четвёртая будет стоить те же 4800 рублей.
  • Предварительная оценка. На этапе пресейла не пишутся и не изучаются никакие длинные документы, а вопрос «сколько примерно стоит» решается за 15-30 минут.

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

0
21 комментарий
Написать комментарий...
Максим Федоров
в ходе диалога на 15-30 мин или первичной переписки, выясняется идея проекта и основная бизнес-логика.
Ответить
Развернуть ветку
Альбина Никитченко

Первым этапом идет обсуждение цены от и примерный диапазон до.
А после подписание договора и написание ТЗ.
Иначе можно впустую тратить деньги на клиентов, которые просто интересуются. Исполнитель потратит свое время, а клиент сделает "там где дешевле".

"К слову, самое большое ТЗ, которое нам приходило на оценку - это 136 страниц 12-м шрифтом. Я отказался его брать в работу даже на оценку"
ТЗ на простые модули для сайтов начинаются от 40-50 страниц A4.

Аналитики, которые работали с принципиальными разработчиками, понимают важность подробного и четко сформированного ТЗ.
Читая ТЗ разработчик должен уже с первых слов понимать, о чем проект, для чего и как его примерно реализовать.

Ответить
Развернуть ветку
Sergei Timofeyev

И, главное, не абстрактный результат: ещё один сайт, а описанием функциональных возможностей. Про деньги перед ТЗ - правильно. Это тоже работа и этап.

Ответить
Развернуть ветку
Dmitry Trubnikov

В что с бабушкой? Тема статьи не раскрыта...

Ответить
Развернуть ветку
Роман Романов

Просто громкий заголовок и потом шум, сорян чо не ту статью читаем.

Ответить
Развернуть ветку
Максим Федоров
знакома ситуация, когда срывается срок по причине болезни бабушки у программиста, попадания в аварию ну и прочих стандартных "уважительных причин"

Встречается исключительно у новичков (то есть БУДУЮЩИХ или ЖЕЛАЮЩИХ БЫТЬ) специалистов.
Довольно даже средний уровень программиста достигается сложной и долгой работой, там уже хорошие зарплаты и потому в нем работают в большей части довольно матерые ребята.

Не просто так зп мидла даже на таком "дешевом" языке как PHP по Москве идет в интервале 100-140К

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Вы так говорите, как-будто крупные компании не факапят сроки

Ответить
Развернуть ветку
Артём Лисовский

Проблема сроков в компаниях - очень редко проблема рук исполнителей(хотя бывает и такое). Чаще всего это проблема менеджмента. Неправильно поставленный срок в начале - самая популярная проблема. Всем хочется ворваться в бой с криком "мы сделаем это за месяц", а потом дособираются требования и проект затягивается еще на 3.
Бывает, что заказчик сам затягивает в виду нехватвки данных(не прислал фотографии, доступы), а потом спрашивает "почему так долго". Спасает прозрачность, регулярная отчетность, опыт и осторожность. Оценка не всегда зависит от опыта. Часто люди храбро идут делать то, что никогда не делали, но представляют как делать. В этом случае любой поставленный срок будет очень примерным, если декомпозиция и риск-менеджмент не применены.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

В статье я как раз предложил золотую середину, чтобы не было расфокусировки и ключевые данные были зафиксированы.

Ответить
Развернуть ветку
Артём Лисовский

Факапят. Еще как факапят.

Ответить
Развернуть ветку
Просто Сергей

Название статьи не совсем соответствует содержанию.
Вы же просто пишете, как работаете с клиентами и делаете проекты, не более. Причем здесь "болезнь бабушки"?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Такой подход позволяет договориться на берегу о том, что входит в стоимость, а что нет и о том, какой примерно будет стоимость доработок, если они появятся в процессе не потратив кучу времени на написание ТЗ. Прозрачность и для заказчика, и для исполнителя позволяет снизить риск недопонимания и неадекватного поведения.

Ответить
Развернуть ветку
Просто Сергей

Парировать мне теперь нечем, кажется название статьи изменилось, спасибо :)

Ответить
Развернуть ветку
Sergei Timofeyev
На этапе пресейла не пишутся и не изучаются никакие длинные документы, а вопрос "сколько примерно стоит" решается за 15-30 минут.

:))) Простой ленд... на пару часов... вышел уже вместе с админкой приёма заказов, асинхронными запросами и прочим, и почти в неделю работы )) Крайне сложно работать от идеи, не переводя её в ТЗ. Самому потом будет трудно понять на этапе тестирования правильно ли это или нет

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Это описывается в проектировании. Например, в структуре:
1. Ленд с описанием работы
2. Авторизация админа
3. Список заказов
4. Детали заказа

Если асинхрон реально нужен - выносим в блок доп. Функций

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Руслан Кузанов

4800 руб запилить ссылки на соцсети?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Нативная авторизация

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Да, теперь не так эпично, но больше к теме

Ответить
Развернуть ветку
18 комментариев
Раскрывать всегда