Их было шестеро - барабанщик, басист, клавишник, гитарист, баянист и человек с татуировками. Как-то так начинался бы фильм о нас, о музыкальной группе Sun-Techniki.

Вы, возможно, скажете “ШТА?!  Я точно на Хабре?  Причём тут какой-то фильм о музыкальных сантехниках?”

Да, это Хабр, и это рассказ про музыкальную группу, состоящую из сотрудников одной продуктовой IT-компании.

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

Кратко о нас: мы не профессионалы в музыке, мы профессионалы в разработке софта.  Наш софт обслуживает 6% активных веб-сайтов мира (согласно Netcraft), а наша группа выступает на корпоративах в качестве хедлайнеров и за восемь выступлений мы подготовили и сыграли без малого сорок каверов.  На каждое выступление мы готовим новую программу, при этом текст часто переделывается так, чтобы отражать тему корпоратива и события в жизни компании.  В поддержку выступления идут слайды, которые крутит наш слайд-жокей.

Рассказ получился объёмным, поэтому без оглавления никуда:

1. Старт проекта / Прикидываем программу выступления

2. Управление проектом / Дисциплина бьёт талант

3. Прототип / Щупаем номера

4. MVP (точнее, MAP) / Минимально допустимое выступление

5. Тестирование, багфиксинг / Гоняем программу, находим места для улучшений

6. Релиз (раскатка) / Выступление

7. Ретроспектива

8. Заключение / Почему вам тоже стоит заниматься музыкой

9. Бонусы

Вступление закончено, начинаем!

Старт проекта / Прикидываем программу выступления 

Дедлайн / Дата выступления

“Корпоратив состоится 21 декабря” - если ждать такого письма, то ничего не успеешь.  Но зачем ждать, если известно, что корпоративы будут в конце декабря и в конце июля, а восьмое марта будет седьмого марта?  Мы ретроспективно знаем свою capacity, поэтому собираемся за три месяца до предполагаемого дедлайна.  Позже будет известна точная дата, позже будет известна точная тема, но мы уже должны начинать.

Содержание проекта / Треклист

Начинаем мы с кандидатов в треклист выступления.  У выступления есть стандартный общий план:

• выход (что-то пафосное, заряжающее, вызывающее аппетит)

• разогрев (может быть совмещён с выходом)

• заполнение (обычно что-то спокойное)

• набор напряжения (мы называем это “ebanukha”, что в переводе с суахили означает “это воняет”, то есть что-то панковское отвязное, может быть треш) 

• финал, в котором должен произойти катарсис и поставлена точка

Ресурсы / Кто участвует в выступлении

Для получения классического проектного треугольника осталось понять ресурсы.  Может показаться, что здесь всё понятно - нас шестеро, но были в истории времена, когда кто-то не мог участвовать в конкретном выступлении по разным причинам.  Поэтому эти моменты надо проговаривать каждый раз, даже если кажется, что проект типичный.

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

Брейншторм

Соответственно, на каждый этап брейнштормятся треки.  Кандидатов мы берём как просто из головы, так и из нашего слак-канала, ну и конечно же из бэклога.

Про брейншторм на Хабре писали, например, тут: 15 способов превратить мозговой штурм в результат «огонь»

Брейншторм у нас не совсем классический - после вброса кандидата мы сразу обсуждаем его.  Кандидат отбрасывается если:

• кто-то против.  Достаточно одного голоса.

• штука очевидно нам не по зубам на текущий момент.  Такой кандидат обычно идёт в бэклог - в следующий раз может быть мы будем к нему готовы.

• вещь никак не сочетается с другими кандидатами или темой (“конь-цепцией”).  Тоже в бэклог.

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

• вещь очевидно не будет принята аудиторией или другими заинтересованными лицами

“Очевидно” у нас означает мнение большинства.  Мы отлично знаем, что нет ничего очевидного.

Как пример пункта 5 - я всегда хотел на восьмое марта (а лучше на 14 февраля) выпустить кавер на трек Pussy от Rammstein.  Моё извращённое чувство юмора считает, что это постирония и очень смешно.  Но как Product Manager я понимаю, что core segment аудитории этот пассаж не оценит.

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

Управление проектом / Дисциплина бьёт талант

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

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

План (Work Breakdown Structure a.k.a. Иерархическая структура работ)

Ключевые вещи в проектном управлении - это WBS (Work Breakdown Structure), майлстоуны (то есть промежуточные дедлайны), зависимости, ресурсы и управление рисками.

Про проектное управление: PMBoK за 2.5 часа: интервью с Иваном Селиховкиным  

Про конкретно WBS: 4 инструмента по полочкам. Управление проектами с WBS, Диаграммой Ганта, CPM и Time-Cost или Преимущества Иерархической Структуры Работ (WBS) для менеджеров ИТ проектов 

Про оценку задач: Оценка. Рассчитать и уложиться

Про управление рисками расскажу сам ниже.

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

Капитанские, но, оказывается, не всем очевидные принципы построения WBS:

• строй WBS справа налево (вот так: <--), то есть:

  • справа напиши результат - “концерт готов”

  • задай вопрос “что мешает считать, что результат достигнут?” - “номера не готовы”, “сцена не готова”

  • и так рекурсируй до элементарных задач

• после составления WBS пройди уже слева направо (-->) и на каждую задачу задай вопрос “а почему я не могу эту задачу выкинуть?”

• майлстоуны аналогично - справа налево (опять <--).  Потому что дедлайн у нас задан заранее

В традиционных трудах по WBS эту структуру рисуют сверху вниз (вверху цель, внизу этапы), но сейчас чаще это всё укладывают в диаграмму Ганта (ужас какой), поэтому я и пишу про справа налево.

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

Вопрос “а как мне понять расчётную стоимость задачи” оставлю для другой статьи, тема эта считается сложной и здесь я её не раскрою.  Мы ретроспективно знаем, что в среднем нужно три-четыре репетиции для MVP одного номера, и ещё пяток репетиций могут уйти на шлифовку.  И ещё мы заранее знаем, что мы захотим дополнительные репетиции вне обычного графика, то есть раш (кранч, овертайм - как вам угодно) обязательно будет, так что можно его и запланировать ;) 

Инструментарий

Мы не используем ничего тяжёлого - нас не так много, проект структурно не такой сложный.  Нам хватает каталога в Google Drive на концерт, в этом каталоге несколько документов:

• тексты и прочие заметки по номерам

• документ по планам и рискам (в нём несколько секций, в том числе и оперативные - worklog, brainstorm, шорт-лист треков и подобное)

• чеклист на сам концерт, он же райдер

• после концерта в каталог добавится документ по ретроспективе

Отдельно, в корне, лежит документ с общим бэклогом.  

Управление рисками

Отдельно коснусь моей любимой темы - управление рисками.  Почему тема любима - потому что она незаслуженно игнорируется очень многими.  А ведь это просто и полезно!

Как и обещал, про риски рассказываю прямо здесь, без ссылок.

Алгоритм:

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

2. У риска оценивается вероятность срабатывания и тяжесть последствий

3. Риски сортируются по вероятности и тяжести, и в работу берётся N топов в каждой категории.  N зависит от бюджета на работу над рисками

4. Риску прописываются два плана:

   1. План А - что надо сделать для уменьшения вероятности срабатывания риска

   2. План Б - что надо будет сделать для уменьшения тяжести последствий в случае срабатывания риска

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

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

Для первого риска (участник заболел) предлагаю вам придумать План А и План Б и написать его в комментариях, а про второй (номер не получается) расскажу сам - План Б там вовремя понять, что “не прёт” и заменить трек на резервный. 

Резервный трек отбирается так, чтобы его можно было легко и быстро подготовить.  Как вариант резервного трека можно взять старый трек, который мы уже когда-то готовили.  Если даже План Б провалился, то есть План Б2 - выкинуть трек вообще и выходить сокращённой программой.  Ну либо затащить слабый номер харизмой.

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

Из рисков, которые мы не учитывали, но которые сыграли - это выход из строя оборудования.  Один раз у нас сломался баян за пять дней до выступления.  Сломался жёстко, я не смог его починить.  План Б мы выдумали и осуществили очень оперативно - попросили баян взаймы у знакомых.  А План А я потом выполнял самостоятельно - купил новый баян.

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

Прототип / Щупаем номера

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

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

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

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

Это всё и выясняется на прототипировании, или, как мы это называем, на “прощупывании”.  

MVP (точнее, MAP) / Минимально допустимое выступление

Из продуктового опыта мы знаем, что лучше всего сделать MVP (Minimum Viable Product), и потом его дободрить.  Почему?  Тема для отдельной статьи.

В нашем случае более правильно говорить не MVP, а MAP - Minimum Awesome Product.  Ни нам, ни нашей публике не нужно тухлое выступление, нужно awesome выступление!

Про MVP: MVP: что это такое и как работает? (а тут разбор знаменитой картинки с самокатом: Как определить функционал MVP и влюбить клиента в пилотную версию продукта) и сорри за Medium, но на Хабре не нашёл подходящей статьи: The MVP is dead, long life to the MAP. 

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

Вовлечение / Эмоциональная кривая

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

Отличаемся от других / Фишки номеров

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

Кто услышит тут отсылочку к совершенно другому произведению - пишите в комментах! И отдельное спасибо программе "Соль" за proof of concept участия баяна в этой песне.

UI, UX / Тексты

Мы всегда хотим, чтобы тексты у нас были готовы уже на этапе MVP, но как правило по самым разным причинам у нас это не получается.  Практически никогда тексты не были готовы заранее.  Не делайте так. Тексты - это сложно, это важно, они могут поменять аранжировку (когда выбранная аранжировка плохо поддерживает текст).  Делайте тексты как можно раньше.

С IT-продуктами аналогично - нужны фишечки, нужны эмоции и нужны тексты, ибо тексты - это UX.  И нужно это как можно раньше, ибо чем раньше найдена проблема, тем дешевле её исправление. 

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

Тестирование, багфиксинг / Гоняем программу, находим места для улучшений

До этапа MVP ты думаешь, что всё будет классно, вы опять зажжёте, будете прекрасно восприниматься, всё хорошо и всё такое.  Но когда MVP по сути готов, происходит скачок требований, и ты начинаешь докапываться до себя.  Здесь не то, и тут не так.  Это ужасно, с этим нельзя выходить на сцену, это позор!  Тут главное не опускать руки, спокойно остановиться, осмотреться и понять, что конкретно нужно доработать.

Product Walkthrough / Прогоны, сценические образы

На этом этапе мы уже начинаем прогонять программу целиком, включая слова между номерами, думая над движениями и расстановкой на сцене, прикидывая образы.  Очень помогает запись прогона и прослушивание - где провисы, где скучно, где неуверенно, где непонятно, где переход излишне резок или излишне плавен.  Включается режим максимального докапывания (я бы даже написал слово пожёстче, но РКН не дремлет).  

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

Как не вспомнить анекдот: 

Ветеринар на на приёме у Терапевта: 

Терапевт: На что жалуетесь? 

Ветеринар: Не, ну так-то каждый может!

Бета / Последние штрихи, препродакшн

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

Про HADI-цикл: Кейс: как ускорить развитие проекта 

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

Релиз (раскатка) / Выступление

Приближается день выступления.  И здесь та же самая петрушка, что и в самом начале - если спохватиться поздно, то велики шансы запороть всё то, что ты делал три месяца.

Работа с аутсорсерами / Саундчек

Для концертов нужно концертное оборудование, об аренде которого нужно договориться заранее.  Заранее нужно договориться о приезде звуковика, чтобы он настроил всё это.  Хороший звуковик стоит дорого, поэтому может быть так, что он нанимается на саунд-чек, а на самом выступлении работает другой звуковик, подешевле.  С обоими звуковиками крайне желательно встретиться заранее, чтобы подготовить список оборудования.

О да, это всё должно быть в WBS, о котором я говорил в начале статьи.

Очень важно, нет, не так ОЧЕНЬ ВАЖНО провести нормальный саундчек.  Нормальный - это значит прогнать программу несколько раз.  В нашем случае программа обычно полчаса, значит, на саундчек нужно три часа.  Это не считая монтажа оборудования, который может занимать часа два (иногда и больше).

Это типичная работа с аутсорсерами, со всеми плюсами и минусами.  Кто из продуктовых команд и имел такой опыт, вероятно, сейчас смахнули скупую слезу.  Да, это может быть сложным и, что самое неприятное, это может быть провальным.

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

Чеклисты

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

Спасают чеклисты и проверка по ролям, например, после погрузки оборудования очень полезно подробное проговаривание вслух того, что будет происходить, и указывание пальцем на тот предмет, про который мы говорим.  “Мы приезжаем, заходим в зал, ставим вот это пианино на вот эту стойку - опппа, а где стойка?!  не погружена в машину!!1”

Про ТЗ: Стандарты и шаблоны для ТЗ на разработку ПО 

Ретроспектива 

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

Обычная такая ретроспектива - что было хорошо и что мы будем продолжать делать; что можно улучшить и каким образом.

Обратная связь (ищем Market Product Fit)

Нередко на аудиторию запускается анонимный опросник.  Мы пробовали разные форматы - NPS, market product fit, и так далее, я полагаю, тут всё очень индивидуально.  Также мы слушаем, что говорят люди, какие фотки и видео они выкладывают в инстаграм, какие видео на нашем канале набирают больше просмотров, ну в общем после релиза происходит этап валидации успеха и анализ произошедшего.  Результаты этого анализа используются при подготовке следующего концерта.

Про market product fit: Market Fit или как найти точку G у стартапа

Growth hacking / Щупаем аудиторию быстро

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

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

А на самом деле мы ведь больше для себя это делаем, а не для аудитории.  Просто так уж сложилось, что нам с нашей аудиторией по пути.  Всем бы продуктам так, да?

Заключение / Почему вам тоже стоит заниматься музыкой

Может показаться, что всё это очень скучно и очень сложно.  Сложно - да, скучно - нет.  Я ведь не рассказал про творческую часть, там очень много фана.  Само выступление - это чистый фан, чистый адреналин/дофамин/окситоцин/whatever.  Иногда ты думаешь - ну ёлки, ну зачем я опять в это ввязался, но эти шестьсот часов подготовки стоят тридцати минут выступления.  И тысяча часов тоже были бы адекватной ценой.

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

Так вот, я таки понял, чтобы что.

Средство против выгорания

IT - это индустрия высокого стресса.  “Выгорание” - это одно из очень модных слов в последнее время.  Также индустрия стареет, то есть и кризис среднего возраста уже тут как тут.  От всего этого помогают хобби.

На Хабре про выгорание пишут много, но я бы выделил вот эту статью: Профессиональное выгорание айтишников: 15 ответов психиатра Максима Малявина   

Как не выгорать?  Это просто (картинка с Тони Роббинсом):

1. заниматься интересным ненаскучивающим делом

2. регулярно в этом деле побеждать (получать подкрепление)

3. работать с удовольствием

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

Музыка - это хороший вариант такого занятия.  То есть музыка - это средство против выгорания. А у айтишников в музыке есть преимущество - мы умеем в процессы, у нас есть дисциплина.

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

Бонусы

• Как все начиналось? История становления музыкальной группы Sun-Techniki 

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