Как описать идею проекта для технической команды?

Обрывки мыслей, откусанные Docx, макеты в Excel — всё, что в итоге превращается в проекты. Рассказываем, как сделать хороший бриф проекта для команды разработчиков и получить адекватную оценку.

Привет! 👋 Меня зовут Александр, я руковожу компанией FENWIK. Мы — команда разработчиков, которая работает в аутсорсе много лет.

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

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

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

Расскажу как сделать короткий практичный документ, не потратив на него уйму времени, и что нам нужно от него, как разработчикам.

Не пишите техническое задание

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

Объем не важен

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

Не описывайте форму авторизации

Мы все в курсе, как она работает.

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

Макеты — часто провальная идея

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

Отличная практичная замена — референсы из других приложений и сайтов. Наскриншотьте как у других.

Тут вебхук, короче, надо сделать..

Особая склонность людей, которые «в индустрии» (знают немного про SQL, когда-то давно писали сайт на PHP, и вообще не первый раз летали) — начать говорить языком технических решений. Часто приходится делать двойную работу: пробираться через сформулированное техническое решение к изначальной цели чтобы заново его перепридумать.

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

Программа минимум

Документ из трех абзацев:
1. Ландшафт проекта (кто вы, кому вы делаете, какая потребность)
2. Идея проекта (в чем реализация, как решается боль)
3. Ограничения проекта (маркетинговый план, сроки, бюджеты, особенности)

Пример

Ландшафт

Мы — организаторы профессиональной конференции врачей, которая пройдет в апреле.

Идея проекта

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

Ограничения проекта

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

Дополнительно

• Роли (пользователи системы по категориям)
• Функционал
  

Как быстро описать желаемый функционал системы?

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

В каком формате писать?

Я бы предложил вам об этом не думать и писать как пишется. Здесь общая структура важнее подробностей и качества.

Пример

Часто первое описание проекта делается для оценки. Иногда оценка делается подробной, чтобы стороны могли заключить договор, а иногда бывает грубой чтобы просто понять о какой сумме идет речь.

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

Из этого получился сайт https://estimate.agency. На нем можно выбрать категорию сервиса, ответить на десяток вопросов и получить тут же грубый диапазон бюджета и примерные сроки. Причем, сразу же и без участия людей.

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

Если захотите получить более подробную смету, проконсультироваться по вопросам реализации, то мы будем рады знакомству, контакты на сайте или профиле.

Не забудьте только три абзаца! Ландшафт, идея, ограничения.