Первый выпуск «Не 12 часов»: конвейер, проектирование и префлайт-чек-лист
«Работать нужно не 12 часов, а головой» — так сказал Стив Джобс, и мы, ведущие сотрудники Surf, с этим согласны. Мы запустили подкаст «Не 12 часов» и решили рассказать о нём и вам. В нём показываем наше видение процессов, инженерной культуры аутсорс-компании и способы повышения её эффективности.
Ведущие подкаста — Евгений Сатуров, Head of Flutter Surf, и Марк Абраменко, Tech Lead of Flutter Surf.
Тема первого выпуска — старт проекта. За 13 лет мы запустили больше 200 и точно знаем, что делать на старте. А чтобы не быть голословными, мы собрали небольшую выжимку самых важных вещей, идей и мыслей, о которых говорили ребята на протяжении всего подкаста.
Если вкратце, то расскажем, как выстроили процесс запуска проектов, нашли для этого роль архитектора, составили план действий в случае отклонений. И, конечно, поделимся советами, чтобы вы смогли настроить процессы так, чтобы навсегда забыть о страданиях в виде сорванных дедлайнов, мучительных бессонных ночей и разочаровании в продуктах.
Таймкоды
00:00 — Вступление
02:59 — Закладываем фундамент проекта: высокая цена ошибки, обманчивая гибкость
06:24 — Архитектор: его портрет и задачи
11:01 — Проектирование и его типы: функциональное и техническое
22:23 — Префлайт-чеклист: бизнес-аспекты
29:06 — Процессы: пресейл, предпроектная стадия, кик-офф, проектирование и приёмка
42:16 — Префлайт-чеклист: процессные и проектные аспекты
Конвейер — норм или стрём?
В какой-то момент компании приходят к шаблонизации продуктов, стремятся сделать что-то, что можно автоматизировать и адаптировать. Выдать похожий продукт, как с конвейера. И в этом часто есть негативный подтекст — однотипные решения, которые быстро создаются, не решают проблем заказчика.
Поэтому важно кастомизировать решения, потому что каждый клиент уникален, у него есть собственный запрос, и компания должна решить проблему его бизнеса при помощи технологий.
Разберём на нашем примере. К нам часто обращается еком и фудтех. И мы не можем позволить себе шаблонизацию. При этом конвейер может быть и у нас. Только он связан не с результатом, а с экспертизой, людьми и процессами.
Разработка проекта — это не единый монолит. Это ряд этапов — от закладывания фундамента до релиза MVP. И даже это не конец, проект поддерживается и развивается дальше. И первые этапы — проектирование в их числе — как раз и нуждаются в этой «конвейерности». А дальнейшее развитие может идти по принципиально разным сценарием.
Так, в процессе одного и того же конвейера можно получить совершенно разные результаты. А это точно норм :)
Явление архитектора в проекте
Для начала определим, кого мы называем архитектором и какими качествами хорошо бы ему обладать.
1. Это не просто разработчик и всегда сеньор.
Речь не просто о стаже. То есть, если человек 10 лет сидел на одном проекте в, предположим, продуктовой компании, скорее всего, он может стать архитектором этого конкретного продукта. В нашем случае, когда мы запускаем сотни разных проектов — фудтех, еком, медтех и прочие — нужно иметь достаточную гибкость и кругозор для того, чтобы понять, с чем ты сейчас имеешь дело, для того, чтобы предложить правильное техническое решение.
Это говорит о том, что нельзя зацикливаться на чём-то одном. Да, мы любим Flutter, активно его продвигаем, развиваем Flutter-команду, но при этом для меня показатель хорошего архитектора в нашей команде — это то, что человек может встать и сказать, здесь Flutter, пожалуйста, не используйте. Для этой задачи он не подходит.
2. У него есть опыт тимлида.
Несмотря на то, что здесь у архитектора нет команды, тимлидский опыт даёт много навыков, которые разработчик, как правило, в себе не воспитывает. Не потому, что он такой нехороший, а потому, что ему некуда приложить их в повседневной работе. Это и прогнозирование рисков, и реакция на нестандартные ситуации, и управление оценкой.
Мы убеждены, архитектор должен быть на проекте с самого начала — даже на этапе пресейла. Зачем так рано? На этом этапе важно снизить неопределённость, которая связана с требованиями клиента, и сформировать реалистичную оценку сроков и ресурсов. А кто, как не архитектор, сможет выявить потенциальные технические проблемы на ранних этапах и предложить решения, которые минимизируют риски
В ином случае может произойти такое, что архитектор, который подключился только на этапе проектирования, не всегда сразу понимает, что делать. И когда аналитики, дизайнеры, продакт-менеджеры — вся эта толпа людей, которые отвечают за функциональную составляющую продукта — начинают работу, для разработчика это выглядит совершенно оторванной от реальности историей.
«Какой-то бизнес, что-то решает, рассуждает, какого цвета кнопки, где будут расположены. Зачем я тут нужен?»
На деле же архитектор обеспечивает связь между бизнес-требованиями и технической реализацией, что помогает создать продукт, который действительно решит задачи клиента. На первичном этапе он может выдвигать технические (и не только) гипотезы, чтобы впоследствии не оказаться в ситуации, когда всё решили без него и за него.
После пресейла идёт проектирование. И иногда этот процесс проходит гладко — тогда архитектор подключается к нему только в конце — на последних 2–3 неделях до запуска — когда понятно, что нужно сделать. Здесь он заходит с технической стороны, финально подводит технологии под задачу.
Бывает и по-другому, когда архитектор нужен на протяжении всех месяцев проектирования. И это мы молчим про предпроектное исследование, которое запускается, если на пресейле вообще ничего не понятно. В общем, многое зависит от проекта.
Пресейл и проектирование
«Этот этап очень часто заканчивается только потому, что наступил тот день, в который мы по какой-то странной причине начали разработку»
Построение проектирования — один из самых интересных этапов для нашей команды.
Буквально полгода назад у нас не было устоявшегося процесса проектирования. И хотя мы успешно запускали проекты, это происходило достаточно хаотично. Однажды мы оказались в ситуации, когда в проектирование попало сразу несколько проектов. Нужно было быстро описать процесс и донести его до тимлидов. Собственно, тогда-то нам и пришлось более чётко выстроить этот процесс. Зато теперь мы пользуемся им и на других проектах.
Понятно, что мы не будем заниматься проектированием 3 месяца, если через 4 месяца нужно отдать продукт. Так что определить дедлайн достаточно просто.
Дедлайн зависит от многих бизнес-факторов. Сезонности, к примеру.
У каждого проекта есть сезонность. К примеру, у аптечных историй — это январь-март — сезон простуд. У образовательных — 1 сентября.
Если смотреть на процесс с момента пресейла, то понимаешь, что главная задача не в том, чтобы понять запрос клиента и найти способ его удовлетворить, а помочь ему понять его самому.
Вообще, пресейл — это такой этап, на котором редко всё ясно до конца. Есть только приблизительное представление о том, что должно получится в итоге. И вот это приблизительное представление нужно оценить. И оценка при этом должна быть достаточно точной, потому что она становится ориентиром для ожиданий клиента.
И если в итоге выяснится, что нужно не 100 часов, а 1 500, получится не очень здорово, и проект может даже не начаться. По-хорошему, оценкой должен заниматься тот, кто будет потом делать этот проект. Именно поэтому архитектор и должен подключаться на проект на этапе пресейла. И именно он поможет собрать так называемый «префлайт-чек-лист»
Префлайт-чек-лист — чтобы ни один продукт не упал
Префлайт-чек-лист (от англ. preflight checklist — да, мы вот такие, сыплем терминами) — это список обязательных проверок или задач, которые выполняются перед запуском процесса, проекта или системы. В контексте нашей статьи (и создании цифровых проектов в целом) префлайт-чек-лист используется для минимизации ошибок, обеспечения качества и подготовки к успешному запуску.
Разберём на примере готовки. Сидит человек, очень хочет есть, но готовить не умеет. Холодильник полупустой, продуктов — минимум, но голод не тётка, и он начинает экспериментировать. То макароны с лимоном, то яичница с орехами. Сначала получается странно, иногда даже страшно, но со временем он начинает находить в этом смысл. Странные сочетания вдруг складываются во что-то цельное, а потом и вовсе — в нечто уникальное.
Проходит два года, и он вдруг понимает, что случайно создал блюдо, от которого все в восторге. Гости уплетают за обе щёки, даже не подозревая, что это результат долгих экспериментов, провалов и импровизаций. А он сидит и думает: «О, да я, оказывается, изобрёл новый рецепт (=процесс), который реально работает!»
Так же и с префлайт-чек-листом: иногда мы просто собираем всё, что есть под рукой, экспериментируем, ошибаемся, но в итоге находим то, что работает идеально. И это того стоит.
Вот так мы пришли к пониманию, что даже самый хаотичный процесс можно структурировать. И, перекладывая это на кулинарный лад, если бы у человека из примера с самого начала был чёткий план, список ингредиентов и понимание, как их сочетать, он бы, возможно, избежал пары несъедобных экспериментов.
А чтобы упростить процесс составления префлайт-чек-листа, мы делим его на три части: бизнес, процессы и технологии.
Бизнес
Разработчики часто живут в своего рода изолированном мире, сосредоточенном на технических задачах, и не очень часто задумываются о бизнес-составляющей проекта. Но префлайт-чек-лист помогает преодолеть этот разрыв, заставляя команду задавать вопросы о целях проекта, бизнес-модели клиента и его потребностях.
Напомним, успех проекта зависит от полного взаимопонимания между всеми участниками: разработчиками, дизайнерами, аналитиками, бизнесом и клиентами. И префлайт-чек-лист становится инструментом, который не только структурирует процесс, но и помогает команде глубже погрузиться в предметную область клиента. Это особенно важно, когда разработчики сталкиваются с задачами, далёкими от их повседневного опыта. Это может быть новый технологический стек или незнакомая сфера деятельности клиента, где незнание нюансов может привести к ошибкам.
История, которая хорошо иллюстрирует, почему так важно погружаться в предметную область клиента. Однажды мы работали над проектом для авиакомпании, и это было на заре моей карьеры. Я тогда никогда не летал на самолёте, и мои знания о перелётах ограничивались школьными уроками географии. В процессе работы я столкнулся с задачей, где нужно было отображать время пересадки: время отправления — 20:00, время прибытия — 21:00, а общее время перелёта — 2 часа. Я сразу подумал: «Как так? 21 минус 20 — это один час, а не два!» И, конечно, побежал заводить баг. Коллеги посмеялись, объяснив, что дело в тайм-зонах, а не в моих математических способностях.
Этот случай стал для меня уроком: чтобы делать качественный продукт, нужно понимать, как работает бизнес клиента. Особенно если это что-то сложное, вроде авиаперелётов с их стыковками, пересадками и тайм-зонами. Кстати, это хорошая практика — отправлять разработчиков, тимлидов или архитекторов прямо «в поле», чтобы они своими глазами увидели, как всё устроено.
Марк Абраменко, Tech Lead of Flutter Surf
Так что живое взаимодействие с клиентом очень важно. Когда команда видит, для кого и зачем она работает, это вдохновляет и мотивирует.
Бизнес-часть позволяет понять бизнес-контекст и создать продукт, который действительно решает проблемы клиента.
Процессы
Проектирование — это не попытка подготовить абсолютно все на 100% для старта проекта, потому что в реальности это бывает крайне редко.
Часто проекты стартуют с неполными данными: бэкенд может быть в процессе разработки, макеты — доделываться, а техническое задание — дополняться по ходу работы. Это стандартная ситуация в технологических компаниях, где параллельная работа над разными частями проекта — обычная практика.
Префлайт-чек-лист помогает выявить потенциальные проблемы, которые могут заблокировать разработку в будущем. Например, если бэкенд не готов или не соответствует спецификации, это может потребовать создания моков или актуализации документации.
Аналогично, важно проверять макеты дизайна на полноту и логичность, а ТЗ — на ясность и достаточность информации для разработки.
Ключевой момент — это не доверять на слово, даже если в команде высокий уровень доверия. Проверка и уточнение деталей на этапе префлайта помогают избежать сюрпризов в процессе разработки.
Таким образом, префлайт-чек-лист становится инструментом, который позволяет команде заранее выявить риски, подготовиться к возможным изменениям и убедиться, что все участники проекта понимают, что и как будет разрабатываться. Это особенно важно в условиях, когда проекты начинаются с неопределённостью и параллельной работой над разными компонентами.
Технологии
Архитектор должен обладать широким кругозором и насмотренностью, чтобы принимать взвешенные решения. И тут очень важен опыт работы в разных проектах с различными архитектурами и технологиями. Иначе архитектор, который всю жизнь карьеру провёл в одном проекте, рискует перенести привычные решения в новый контекст, даже если они не подходят.
Техническая часть префлайт-чек-листа включает вопросы, связанные с выбором архитектуры. Архитектор должен оценить, подходят ли стандартные решения компании для конкретного проекта или требуется нечто более специфичное.
К примеру, для сложного банковского проекта стандартная архитектура может оказаться недостаточной, а для небольшого проекта — избыточной, что приведёт к оверинжинирингу и лишним временным затратам.
Также нельзя забывать о балансе между инновациями и потребностями клиента. Архитекторы часто стремятся внедрить новые технологии для развития компании, но это может быть рискованно, особенно если технология не обкатана. Такие решения должны обсуждаться с техлидом или руководством отдела, чтобы избежать ситуаций, когда инновации вредят проекту или усложняют работу команды.
Важный этап — финальная проверка (она же приёмка), когда результаты работы за несколько недель или месяцев оцениваются независимым экспертом, например, техлидом или руководителем отдела. Это позволяет выявить потенциальные проблемы до того, как они станут критичными, и убедиться, что проект соответствует ожиданиям и стандартам.
Так, техническая часть префлайт-чек-листа помогает архитектору и команде принимать обоснованные решения, избегать оверинжиниринга, балансировать между инновациями и стабильностью, а также обеспечивать качество проекта на этапе приемки.
В общем, проектирование, подключение архитектора на этапе пресейла, префлайт-чек-лист — это не просто формальности или списки задач для галочки. Это инструменты, которые помогают команде, и особенно архитектору, принимать осознанные решения, избегать ошибок и создавать продукты, которые действительно решают задачи клиента.
Да, это не гарантия, что всё пройдёт идеально, но это уверенность в том, что команда готова к вызовам и знает, как с ними справляться. В конечном счёте, всё это не про то, чтобы «не облажаться». А про то, чтобы создать продукт, которым будут гордиться все: и компания, и клиенты.
Подробности — в подкасте «Не 12 часов», а кейсы, лучшие практики, новости и вакансии в команду Flutter Surf уже в нашем телеграм-канале. Присоединяйтесь!
