Scope creep is a natural outcome of doing anything!
AsmongoldTV

It’s about progress, not perfection. Keep going!
Duolingo

Продолжаю серию статей про малоизвестную (надеюсь что пока!) методологию разработки, которая запала мне в душу. Запала настолько, что я хочу донести знания о ней до как можно большего количества людей.

Первая вводно-обзорная статья

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

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

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

В рамках методологии Shape up стадия “прожарки” сырых идей до состояния оформленного артефакта, на который стейкхолдеры готовы сделать ставку (выделить время разработчиков), называется Shaping (шейпинг). Время, которым стейкхолдеры готовы рискнуть для воплощения идеи, кстати, в терминологии Shape up называется аппетитом (Appetite), так что в итоге в разработку идут самые “аппетитно” приготовленные идеи.

Процесс постановки задач и best practices описания хотелок

Так или иначе, сырые идеи (хотелки) надо превратить в набор артефактов, ориентируясь по которым можно вести разработку. Хотелки обычно описываются либо словами (условно обозначим такой способ как ТЗ), либо макетами (макеты в своём “каркасном” варианте тоже сюда относятся), либо и тем и тем сразу.

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

Мои претензии к ТЗ и макетам из личного опыта:

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

Потенциальная золотая середина - Shaping

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

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

По итогам шейпинга формируется артефакт — питч (pitch), который должен соответствовать трём критериям:

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

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

Оживляю теорию практикой

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

Немножко предыстории. У нас в CosySoft HR’ы в этом году придумали проводить пульс-опросы, чтобы периодически выяснять умонастроение народа в целом и отдельных представителей перед ассессментом (у нас так performance review называется). Реализовано это всё на данный момент с помощью гугл-формы с опросом, из которой сформирована гугл-таблица с результатами. К таблице я по просьбе HR’ов прикрутил гугл-скрипт, обрабатывающий результаты. Под кодовым названием “светофорная обработка результатов пульс-опроса”.

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

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

Этап 1 - Определение границ

Краеугольный принцип всего Shape Up - Варьируемый объем работ за фиксированное время. Поэтому логично начать с выяснения аппетита. Я выбрал цифру в 80 часов работы, потому что делать этот проект буду в свободное время, за которое конкурирует огромная куча идей. С аппетитом определились, также я исходил из посылки, что делать всё одному, и чем меньше потребуется работы на бэкэнде, тем лучше

Этап 2 - Выявление элементов

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

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

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

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

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

В итоге я выявил такие элементы своего будущего решения:

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

Этап 3 - Выявление рисков

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

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

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

Распределение вероятностей сроков окончания работ над фичей в ситуации, когда отсутствуют неучтённые риски

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

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

Какие риски я выявил в своей идее

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

Поэтому я сразу для себя решил делать максимально простой бекенд из всех возможных. Что потребовало небольшого исследования АПИ гугл скриптов, но в итоге я решил, что буду собирать большой JSON-объект он будет просто передаваться на фронт, и там я уже буду с ним разбираться как мне надо. Для первой версии приемлемо, “progress over perfection”! Это пример одного из trade-off’ов для достижения цели (поставка ценных для пользователей фич в установленные сроки), которые Shape up всячески поощряет. Здесь я обменял своё представление как должен выглядеть бекенд “по хорошему”, на минимизацию объёма работ в области, где я не обладаю достаточной экспертизой.

Ещё один вопрос, который возник в ходе анализа рисков - “что делать с историей ответов пользователя на пульс-опрос?”. В существующей гугл-таблице эта функциональность отсутствует, но вместе с тем в модуле ассессментов история прошлых ассессментов вполне себе предусмотрена. Прикинув на глаз, я решил, что сейчас это не must-have функционал, и делать я его в этот раз не буду. Это будет так называемый “No-go”, что надо будет отметить отдельным пунктом в питче.

Этап 4 - Написание питча

Оформленный питч

Обычный питч включает в себя 5 компонентов:

Описание проблемы.
Описание решения.
Предполагаемый аппетит.
Кроличьи норы - потенциальные риски из-за которых можно выйти за рамки аппетита, если пытаться решить на ходу. Отвечает на вопрос: “Что делать если в ходе реализации возникнет проблема Х?” Чтобы максимально обезопасить себя от факапа дедлайна, решение как обойти эти кроличьи норы принимается на этапе шейпинга и прописывается в питче явно.
То чего в рамках данного проекта делать не надо (No-go’s) - тоже принимаемые заранее решения для более четкого определения границ проекта.

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

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

Мои впечатления по итогам эксперимента

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

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

Мотивационная цитатка про шейпинг вместо заключительного слова

“Когда проекты лучше зашейплены, у них более чётко определены границы, что позволяет командам разрабатывать более автономно. Когда команды более автономны, люди наверху могут тратить меньше времени на управление командами.

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

Поиски баланса в составлении функциональных требований. Особенности Shaping’а в Shape up