▍ Разработка ПО — это исследование
Требуют ли фармацевтические компании от исследователей сообщить им сроки создания лекарства от рака? Исследователи могут сообщить сроки выполнения конкретного исследования (и достаточно точные сроки, потому что планы исследований обычно имеют графики), но результаты наподобие «получения лекарства от рака» зависят от того, что выяснится в процессе экспериментов. Для прогнозирования подобных результатов нам заранее нужно знать результаты экспериментов, но если бы мы их знали, то эксперименты были бы не нужны. На самом деле мы не можем смотреть дальше, чем результаты следующего эксперимента, потому что этот эксперимент определяет дальнейший шаг.
В разработке ПО мы не тратим время на задачи, решения которых знаем. Если решения уже существуют, мы добавляем в качестве зависимости пакет или библиотеку с этим решением, или копируем старый код, или делаем что-то ещё, на что требуются секунды, а затем можем переходить к следующей задаче. Почти всё время разработки тратится на новые задачи, ответов на которые мы не знаем. Часто они новы ужасно скучным образом, например, «как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?» Но именно из-за них эта ситуация отличается от всех остальных (или, по крайней мере, от тех, которые мы смогли найти) и именно это занимает всё наше время.
Разработка ПО почти полностью состоит из быстрого цикла экспериментов. У нас есть мысль о том, как мы можем решить задачу, нам требуется несколько секунд, чтобы написать решение, а затем мы его выполняем. Если это срабатывает, мы переходим к следующей задаче, если не срабатывает, то пробуем другую мысль. Когда у нас заканчиваются идеи, то мы переходим на Stack Overflow и пытаемся найти что-нибудь там. Клинические испытания могут длиться месяцами, а большинство экспериментов в разработке ПО занимают меньше минуты — это может быть быстрое изменение строки кода, проверка прохождения юнит-тестов или результатов при повторном запуске программ или перезапуске браузера. Наши циклы гораздо короче, но мы всё равно не можем предвидеть дальше, чем результат следующего эксперимента. Если он срабатывает, то мы решили задачу; если нет, то мы пробуем что-то ещё. Каждый разработчик ПО сталкивался с задачами, на решение которых требовались часы, но даже если вы зарылись в задачу с головой, в любой момент времени есть вероятность, что следующий прогон окажется рабочим. И вы никак не сможете узнать, сколько времени осталось до решения задачи, тридцать секунд или три часа, пока она не будет решена. Единственное, что мы честно можем сказать, так это что мы делаем прямо сейчас.
Чем больше у вас опыта в строительстве, тем точнее вы сможете оценивать сроки постройки стены, но это возможно, потому что все переменные известны. Это нелёгкая работа, но с точки зрения сложности задача остаётся простой. В процессе работы практически не возникает новых факторов. Каждый кирпич обычно очень похож на любой другой, по крайней мере, в том, что важно при строительстве стены. Количество времени, необходимого для укладки всех кирпичей, в общем случае довольно близко ко времени укладки одного кирпича, умноженному на количество кирпичей.
Но в разработке ПО всё совершенно не так. Разработчики ПО могут обманывать себя, считая, что с опытом они начинают лучше оценивать сроки (особенно если их мотивируют это делать), но поскольку мы тратим всё своё время именно на задачи, которые раньше никто не решал, то любой прошлый опыт, по определению, не имеет никакого веса. Если у нас есть подходящий прошлый опыт, то мы выполним задачу за минуты или даже за секунды. Почти всё наше время мы тратим на задачи, которые не решали раньше, на цикл крошечных экспериментов.
Разумеется, конус неопределённости существует. При нахождении решения новых задач остаётся меньше нерешённых, потому что неопределённость при решении десяти задач ниже, чем при решении десяти плюс ещё девяноста. С другой стороны, в задачах разработки ПО может быть сложно объяснить разницу между простым и практически невозможным, и это не всегда интуитивно понятно даже для опытных разработчиков. Иногда истинная сложность задачи вскрывается после её глубокого изучения. Да, есть вероятность, что когда осталось всего десять задач, неопределённость снижается, но любая из этих десяти задач может оказаться монстром, занимающим в два раза больше времени, чем предыдущие девяносто девять вместе. Конус неопределённости говорит нам, что это маловероятно, но мозг человека имеет ужасную привычку путать маловероятное с невозможным. Когда от этой привычки зависят планы проектов, то компании оказываются раздавленными разницей между этими понятиями.
▍ Смертельная цена обмана
Для большинства разработчиков ПО оценки сроков — это ложь, которую они рассказывают руководству (обычно потому, что руководство на ней настаивает). Хорошие разработчики противятся этому. Они пытаются объяснить, почему оценки бесполезны и не должны использоваться ни для чего. Но их руководство настаивает, что ему нужны оценки, поэтому разработчики говорят какие-то сроки, обычно с большим запасом для своей защиты и со множеством оговорок. В организациях с нездоровой культурой руководитель настаивает, заставляя разработчиков предоставить более сжатые сроки. Вы можете услышать раздражённое «Не понимаю, почему нужно так много времени» от того, кто точно не заинтересован неделями слушать лекции, необходимые для объяснения сроков. Даже в организациях, которые доверяют своим разработчикам, эти оценки становятся диаграммами Ганта и графиками проектов. Они быстро превращаются из прикидки в железное обязательство, на кону которого стоит работа людей.
В опросе Института управления проектами Pulse of the Profession за 2018 год говорится, что примерно 48% проектов не укладываются в дедлайны. Вероятно, большинство из нас это не удивит, но мы всё равно упорно верим в том, что это единственно возможный способ ведения бизнеса, несмотря на то, что успех или провал практически определяются броском монеты. Я уверен, что большинству из вас приходилось перерабатывать и трудиться по ночам, чтобы уложиться в дедлайн, даже если эти переработки приводили к снижению производительности и даже замедляли проект из-за внесения новых багов, требовавших больше времени на устранение, чем потрачено на «кранч». Есть кучи книг, доказывающих, что такая стратегия не только неэффективна, но и контрпродуктивна и требует от нас ещё больше времени, которого и так не хватает. Это было бы плохо само по себе, если бы это было плохой бизнес-практикой — к сожалению, компании принимают ужасные решения каждый день — но это ведь ещё и убивает каждый год 750 тысяч человек.
Но какого ещё результата нам следует ждать? Все оценки сроков — ложь, поэтому принятые на основании них планы и дедлайны проектов — это фантазии. Почему мы ожидаем, что их связь с реальностью будет точнее, чем бросок монеты? И чего мы ожидаем от людей, когда их жизнь зависит от этих фантазий?
Выше я говорил о том, что наши прикидки превращаются в железные обязательства; напомнить вам о третьей ценности из манифеста Agile-разработки ПО?
Сотрудничество с заказчиком важнее согласования условий контракта
Мы видим, что современный подход к согласованию условий контракта не соответствует ничьим потребностям: ни разработчиков, ни бизнеса, ни заказчика. Вспомним изложенный выше сценарий: руководитель спрашивает у разработчика оценки сроков, разработчик даёт отпор, а руководитель настаивает, что бизнесу для планирования нужны сроки. Давайте сделаем шаг назад и разберёмся, зачем бизнесу вообще нужны оценки сроков. На то есть несколько действительно весомых причин:
- Бизнес должен иметь возможность планировать ресурсы, обеспечивать эффективность назначаемых сотрудникам задач.
- Бизнесу нужно обеспечить координацию всего для выпуска большого продукта.
- Бизнес должен информировать высшее руководство и стейкхолдеров о текущем состоянии дел.
Однако в каждом из этих случаев ложность наших оценок создаёт запутанную паутину новых проблем, в конечном итоге приводя к провалу изначальной цели. Всё это очень важные цели, и их провал — серьёзная проблема. Единственный способ достичь этих целей — быть честным и открытым, а чтобы начать это делать, нужно перейти от согласования условий к сотрудничеству с заказчиком.
▍ Планирование проектов и Agile-компания
Одна из самых важных причин необходимости точных оценок сроков заключается в планировании ресурсов. Если для создания дизайна команде проектировщиков UX потребуется два месяца, нам нужно гарантировать, что команда разработчиков будет готова через два месяца принять результат и приступить к работе. Если для реализации этого дизайна команде разработчиков потребуется полгода, то нам нужно гарантировать, что команда QA будет готова к его тестированию через восемь месяцев. Если команда проектировщиков UX не уложится в дедлайн, то это вызовет проблемы на всех последующих этапах и повлияет на все зависящие от них отделы.
Это принцип Big Design Up-Front (BDUF). Мы делаем крупную ставку — в этом примере девять месяцев работы, которые для многих компаний могут означать разницу между успехом и банкротством — заявляя, что полностью поняли задачу, придумали правильное решение, и что в течение девяти месяцев этой работы не произойдёт никаких важных изменений. Каждое из этих допущений само по себе является ставкой, которую примут немногие профессиональные игроки, а всё вместе это (да ещё и с учётом размера ставок) превращается в чрезвычайно маловероятное событие.
Делать одну огромную рискованную ставку — не лучшая идея; мы должны делать одну за другой мелкие ставки. Не вкладывайте усилия в девять месяцев труда; вложитесь в две недели, а потом посмотрите, к чему вы пришли. Чтобы сделать это, вам с большой вероятностью придётся реорганизовать работу; команда проектировщиков UX не должна выполнять всю работу по исследованиям и проектированию, а затем перебрасывать её разработчикам, а разработчики не должны выполнять первичную разработку, а затем перекидывать её команде QA. Проектировщиков UX, разработчиков ПО и специалистов по QA нужно объединить в одну кросс-функциональную команду, а затем разделить работу на вертикальные срезы — части полной функциональности, которую команда сможет выполнить за выделенный объём времени, а затем посмотреть, что вы получите к его завершению.
Для выполнения своих задач кросс-функциональной команде не нужен долговременный план. В каждом новом цикле она готова взяться за любую наиболее важную работу, которую нужно выполнить следующей. Ей не нужны оценки сроков, им требуется только знать, что организация ждёт от них на следующем этапе. Участники команды должны коммуницировать с остальной частью организации и обеспечивать прозрачность выполняемых ими задач, чтобы было чётко понятно, на какой стадии всё находится. Организация должна использовать эту прозрачность, чтобы решать, какую следующую самую важную задачу необходимо выполнить; команда при этом будет знать, над чем начинать работать после начала следующего цикла работы. При изменениях на рынке вы можете пересмотреть в свете этих изменений следующую наиболее важную задачу. Каждый готовый вертикальный срез приносит с собой новые открытия и новое понимание, которое может изменить образ осознания задачи. Когда это произойдёт, вы снова можете пересмотреть в свете этих открытий следующую наиболее важную задачу. Именно благодаря возможности реагирования эта методика называется Agile («гибкая»).
Вы можете сказать, что всё это замечательно для маленьких команд, но не подойдёт для крупных организаций. Если у нас есть 50 дизайнеров, 100 разработчиков и 30 специалистов по QA, то их ведь не объединишь в одну кросс-функциональную команду из 180 людей? Это ни за что не сработает; поэтому их и разбивают на 30 команд, в каждой из которых 1 специалист по QA, 1-2 дизайнера и 1-4 разработчика. Если соединить стратегию вертикальных срезов с архитектурой вертикальных срезов и/или с микросервисами (если вам действительно нужны микросервисы), то каждая из этих 30 команд может взять свой срез одного и того же продукта и вам не придётся волноваться о коллизиях (которые лучше известны разработчикам по одному конкретному типу коллизий — конфликту слияний).
▍ Готов к выпуску
Даже несмотря на возможность более эффективной работы в мелких кросс-функциональных командах, регулярно выпускающих работающие вертикальные срезы окончательного продукта, это не избавляет нас от необходимости точных оценок сроков выпуска продукта. Выпуск продуктов — сложный процесс, зависящий от правильной координации. Маркетинг может быть масштабным многоступенчатым процессом, и обеспечение всего необходимого для рекламы выпуска продукта — серьёзная работа. Мы не можем просто придумать что-нибудь в последнюю минуту. Нам нужно назначить дату, чтобы планировать на её основе маркетинговые мероприятия.
Всё это правда; по крайней мере, для того, что называется жёстким запуском. Он отличается от мягкого запуска, который в последний десяток лет становится всё популярнее. При мягком запуске вы выпускаете что-то с гораздо меньшими фанфарами. Такая стратегия хорошо подходит для стартапов и minimum viable product (MVP), а MVP хорошо подходят для кросс-функциональных команд, регулярно выпускающих работающие вертикальные срезы. Так как в каждом цикле приоритет отдаётся следующему наиболее ценному срезу, мы просто определяем, какого количества срезов достаточно, чтобы продукт представлял ценность для реальных пользователей, и выпускаем его. На работу команды это практически никак не влияет; теперь она повышает ценность уже работающего продукта, но это исключительно бизнес-решение.
При мягком запуске можно рискнуть и выпустить продукт, который некоторым пользователям покажется недоделанным; именно поэтому в него не вкладываются большие маркетинговые ресурсы. Вы получаете отзывы от первых пользователей и используете их для выбора следующих наиболее ценных срезов. При использовании такой стратегии слишком долгое ожидание релиза более рискованно, чем слишком ранний релиз, потому что вы рискуете потратить время на срезы, которые пользователям неинтересны. Чем раньше вы что-то выпустите, тем раньше у вас появятся пользователи, которые скажут вам, чего они хотят. Мэтт Малленвег сформулировал это так:
Практическое использование — это кислород для идей. Вы никогда не можете предсказать, как аудитория отреагирует на то, что вы делаете, пока не выпустите это. Это означает, что каждая секунда работы над чем-то без публикации — смерть от недостатка кислорода реального мира.
При таком подходе вам не нужно пытаться предсказывать будущее. В процессе использования реального продукта реальными людьми он становится совершеннее, и вы постепенно вкладываете в него больше маркетинговых ресурсов. Нет никакого «большого запуска» и скоординированной маркетинговой атаки. Вы начинаете разработку и проводите кампании только после выпуска продукта и его готовности для рекламы широкой аудитории.
Тем не менее, нельзя отрицать то, что некоторые продукты действительно должны иметь жёсткий запуск; но как часто компании объявляют о дате выпуска долгожданного продукта, а потом снова и снова его откладывают? Мы не можем избавиться от того факта, что все оценки сроков — это ложь, что означает практически полную гарантию сдвига всех запланированных дат релизов вне зависимости от тяжести «кранчей», которые приходится терпеть сотрудникам (потому что, как и говорилось выше, эта стратегия просто ещё дальше отодвигает дату завершения).
Если вы хотите быть честными с самими собой и создавать планы, которые действительно работают, то стоит изучить удобство планирования и исполнения мягких запусков по сравнению с жёсткими. Если мы разрабатываем ПО итеративно, то при достижении точки, в которой стратегия мягкого запуска запустила бы MVP, мы можем запустить закрытую бету для избранной группы участников. Только достигнув в развитии продукта достаточно хороших отзывов бета-тестеров, вы можете начать планировать маркетинговую кампанию. На этом этапе у вас будет уже гораздо более глубокое понимание того, что необходимо для создания качественного конечного продукта, и того, сколько работы ещё для этого потребуется. Скорее всего, эти детали будут меняться между временем начала планирования и приближающейся датой выпуска, но поскольку вы уже разработали качественный базовый продукт, то у вас уже будет то, что можно выпустить. Можно начинать делать маркетинговые заявления, вызывающие восторг и предвкушение, параллельно участвуя в ярмарках, подкастах или телепередачах, покупая рекламные площади и проводя другие мероприятия для скоординированной кампании перед датой выпуска. Вместо того, чтобы решать броском монеты, будет ли у вас готовый продукт на момент релиза, вы точно будете знать, что у вас уже есть отличный продукт. Останется только вопрос, насколько лучше он станет на дату выпуска.
▍ Будьте честны с руководством
Наверно, вы уже догадались, что я думаю по поводу использования оценки сроков в отчётах высшему руководству и стейкхолдерам. Людям, принимающим решения, важно знать о текущей ситуации и её развитии, чтобы они могли принимать важные стратегические решения, но оценки сроков не дадут им этого, ведь все ваши оценки — это ложь. Они находятся в неведении о происходящем в реальности. Сложные диаграммы Ганта, проектные показатели, планы и оценки позволяют проекту, который уже несколько месяцев движется к катастрофе, выглядеть красиво; так происходит до самого последнего момента, когда приходит и проходит дедлайн. В этом и обнаруживается истинная ценность оценок: она заключается не в предоставляемой, а в скрываемой ими информации.
Agile-команды способны обеспечивать гораздо более высокую степень прозрачности того, чем они занимаются, что выполнили и что осталось выполнить. Это даёт ответственным за принятие решений людям максимум возможного понимания ситуации и позволяет им принимать решения, которые команда может начать реализовывать сразу в начале следующего рабочего цикла. Недостаток такого подхода в том, что принимающие решения люди будут точно знать, чем занимаются команды, что они выполнили и что ещё нужно выполнить… а это может вызывать ужас. Разработка ПО — рискованный процесс. И от этого никак не избавиться. Может выясниться, что цифровой продукт невозможно реализовать технически или он нежизнеспособен с коммерческой точки зрения. Хорошие менеджеры по продукту прогнозируют самые большие риски заранее (именно от этого зависит расстановка приоритетов для наиболее ценных следующих срезов — выявление наибольших рисков чрезвычайно полезно), и когда это происходит так, мы узнаём о них рано, а не поздно. Но даже если мы делаем всё правильно, в конечном итоге разработка ПО — это исследование. Даже в самом конце есть вероятность того, что мы найдём нечто, превращающее все наши усилия в пустую трату огромного количества времени и денег.
Из-за прозрачности мы никак не сможем спрятаться от этой ужасающей правды. Все мы люди, поэтому понимаем, почему ответственные за принятия решений склонны к использованию систем, скрывающих все эти тревоги за высокой непроницаемой стеной планирования проектов. В этом случае риск по-прежнему присутствует, но нам необязательно его видеть. Если всё удастся, но вам никогда не придётся с ним сталкиваться. У нас проходит большой успешный запуск и мы все получаем премии за отличную работу. Но если это не срабатывает, а такое, согласно приведённому выше опросу, случается в 48% случаев, то происходит взрыв рисков. Акции рушатся. Сотрудников увольняют. Мы требуем сообщить нам, кто виновен во всём этом, но если быть действительно честными с собой, то ответ будет очевиден: ошибки сотрудников не идут ни в какое сравнение с неизбежным результатом сокрытия всех этих рисков.
Agile позволяет нам перестать врать начальнику и обеспечивает ему прозрачность, показывающую, что происходит на самом деле, но в таком случае им приходится становиться не боссами, а лидерами. Борьба с неопределённостью пугает, ведь необходимо признать, что в этом бизнесе присутствует риск. Можно спрятать его в шкаф, или замести под ковёр, или даже воспользоваться довольно эффективными способами его минимизации (если осмелитесь признать его), но устранить риск полностью невозможно. Это неотделимая часть работы. Если вы сможете принять это и верите в своих людей, то они смогут быть честными с вами и вместе вы сможете найти способы одолевать, минимизировать и регулировать эти риски. Если вы не можете, то вам придётся попросить своих сотрудников продолжать врать вам, а потом удивляться, почему так много проектов неизбежно заканчиваются провалом, несмотря на то, насколько прилежно вы обновляете свои диаграммы Ганта.
▍ Главный критерий измерения прогресса
Если вы выберете в качестве критерия «достаточного качества» чего-то косвенный показатель, то это всеми возможными способами даст вам понять, что косвенный показатель — не то, что вас интересует на самом деле. Давным-давно платформы соцсетей решили, что хорошим косвенным показателем удовлетворённости пользователей является длительность нахождения на сайте, и начали оптимизировать эту метрику. В результате они создали цифровой аналог опиатов и игровых автоматов. Кроме того, я уверен, что многие из вас смогут вспомнить истории разных организаций, которые выполняли огромные суммы сторипоинтов, или Scrum-команд, которые стабильно увеличивали velocity с каждым спринтом, но создавали едва работающее ПО.
Седьмой принцип Agile-манифеста гласит:
Работающий продукт — основной показатель прогресса.
Не сторипоинты, не velocity, не оценки сроков: только работающее ПО. Если вы сделаете их показателем своего прогресса, то закон Гудхарта скажет вам, чего ждать дальше: вы будете создавать кучу сторипоинтов и высокую velocity, но, скорее всего, не очень работоспособное ПО. Если мы хотим других результатов, то нам нужно сосредоточиться на том, что мы действительно хотим.
Распространение тега #NoEstimates в Twitter началось с того, что своими историями делились люди, недавно завершившие крупные сложные проекты без каких-либо оценок сроков. Прямо сейчас люди поступают так даже в больших, сложных проектах наподобие вашего. Вместо того, чтобы писать научно-фантастические рассказы о том, каким может быть будущее, мы можем сформировать кросс-функциональные команды, реализующие вертикальные срезы работающего ПО, чтобы мы могли измерять свой прогресс не в сторипоинтах, velocity или какой-то другой лжи, а в настоящем работающем ПО, которое существует и запускается.
Если после всего вышесказанного вы всё равно уверены, что в некоторых ситуациях оценки сроков нужны, то я предложу следующее: сторипоинты и velocity активно используются в Scrum-командах. Не менее одного раза в спринт команда собирается, чтобы «причесать» бэклог, и в это время она рассматривает пользовательские истории из своего бэклога и присваивает каждой какое-то количество сторипоинтов. Чаще всего используются числа из последовательности Фибоначчи. Это позволяет scrum-мастеру или владельцу продукта вычислить velocity (среднее количество сторипоинтов, которые команда завершила за последние несколько спринтов). Используя это среднее значение, они могут спрогнозировать, что при сохранении командой той же скорости она сможет завершить за следующий спринт такое-то количество пользовательских историй, что можно превратить в прогноз того, сколько времени понадобится на разбор бэклога.
В своей книге #NoEstimates Васко Дуарте говорит, что если бы мы отказались от чисел Фибоначчи (то есть заменили 1, 2, 3, 5 и 8 на 1, 2, 3, 4 и 5), то получили почти такие же прогнозы. Более того, если мы полностью откажемся от этих оценок (по сути, если каждая пользовательская история будет стоить 1 сторипоинт), то мы всё равно получим почти аналогичные прогнозы. Это значит, что мы или можем один час в неделю регулярно заниматься разбором бэклога, анализировать каждую пользовательскую историю и использовать покер планирования для подбора их подходящего размера, или можем просто подсчитать количество историй в бэклоге. Прогнозы в любом из случаев будут одинаково полезны (хотя один из них требует гораздо меньше времени и усилий).
В руководстве по Scrum приводятся конкретные ценности, для реализации которых нужен этот процесс. Одна из них — это «смелость»; эта ценность была позаимствована у его предшественника, экстремального программирования. Возникает вопрос: зачем Scrum требует «смелости»? По моему опыту, Scrum-команды чаще всего терпят неудачи из-за отсутствия смелости, чем по какой-то иной причине. Обычно именно нехватка смелости заставляет организации создавать карго-культы вместо «гибкости» и именно нехватка смелости заставляет нас прятаться за оценками сроков, вместо того, чтобы взглянуть в глаза неоспоримому факту: разработка ПО — это риск. Когда мы слишком боимся принять это, такие риски накапливаются и растут в тех местах, где мы их прячем. Они разрушают наши проекты, наши компании, наши карьеры и даже наши жизни. Если мы признаем их, то сможем минимизировать. Мы сможем выявлять их до того, как поставим всё на карту в ожидании результата. Мы сможем их устранять, обходить, справляться с ними и управлять ими. Но только если сначала наберёмся смелости взглянуть им в глаза и честно говорить о них друг с другом и с собой.
Помоги спутнику бороться с космическим мусором в нашей новой игре! 🛸
