В условиях постоянных изменений все больше компаний переходят на гибкую практику. Они часто сосредотачиваются на постоянном совершенствовании процессов и деятельности, забывая о реальных целях — повышении ценности продукта и результатов бизнеса.
What is Time to Market? Meaning.
Время выхода на рынок (TTM) — это время, необходимое для вывода продукта на рынок: от рождения идеи до запуска. Он охватывает весь цикл проектирования, разработки и запуска нового продукта.
Концепция времени выхода на рынок появилась еще в 1995 году и является важной переменной в процессе управления качеством. Когда стало ясно, что потребительские предпочтения быстро меняются, а жизненные циклы продуктов становятся короче, компаниям пришлось рассматривать сроки как ключевой элемент подхода к разработке продуктов.
Advantages of a Quick TIme To Market.
Основными преимуществами более быстрого TTM являются:
- Премиальная цена, как результат выхода на рынок первым. Когда компания запускает продукт, которого еще нет в ассортименте конкурентов, рынок оправдывает более высокую цену. тем, что компания первой запускает продукт.
- Более длительный жизненный цикл продукции.
- Более ранняя безубыточность, более высокая окупаемость инвестиций и рентабельность.
Limitations of the Time To Market Concept. Disadvantages
Сокращение времени выхода на рынок не всегда является лучшим решением. Поскольку большинство проектов по разработке новых продуктов следуют стандартизированным моделям, таким как Stage-Gate или Six Sigma, сокращение TTM может означать пропуск или спешку на одном или нескольких этапах модели. Многие эксперты считают, что такое сокращение может повлиять на качество всего продукта или определенных его характеристик.
По этой причине можно рассмотреть возможность обмена или синтеза между коротким TTM и TQM (в зависимости от конкретных потребностей отрасли).
Время выхода на рынок — значительное явление в наши дни. Время выхода на рынок может помочь производителям провести правильный анализ продукции, пользующейся спросом. Этот период также может придать продукции нужное измерение, чтобы и производители, и потребители имели о ней хорошее представление.
Почему сразу сказки?
Они так не считают — и правильно. Всем известно, что ИТ — это сложный, запутанный и очень взаимосвязанный сектор. Изменения происходят в потоке. Бизнес-требования, идеи и инициативы не имеют конца. Клиенты не знают, чего они хотят, и начинают считать время с момента, когда мы рассказали вам о нашей новой идее» — в таких условиях время выхода на рынок может быть бесконечным.
А рабочий процесс обычно организован так, чтобы вы знали, как это делается. Как метко выразился Энди Хант, один из соавторов Agile Manifesto, «современная разработка программного обеспечения означает, что мы делаем половину Scrum и имеем Jira». Давайте ускорим этот процесс, хорошо? Поехали. Удачи!
«Agile сейчас означает, что мы делаем половину Scrum плохо и имеем Jira».
Энди Хант
Однако важно отметить, что под многократным ускорением мы подразумеваем именно многократное ускорение, как бы странно это ни звучало. Другими словами, не для того, чтобы стать на 10-20% эффективнее, а для того, чтобы сократить время, необходимое для развертывания новых больших функций, в два раза. По крайней мере, дважды, а лучше трижды. Еще лучше: от пяти до десяти раз. Это, конечно, сказка.
Можно ли в сказку попасть?
Оказывается, можно. Для достижения этой цели необходимо (но не достаточно) работать по четырем направлениям:
- Принцип организации ресурсов — извините за цинизм, я говорю об ИТ-персонале. Как вы знаете, существует условный спектр от иерархии до (почти) самодостаточных команд в плане распределения ресурсов на задачи. Выбранный принцип организации ресурсов предоставляет определенные возможности и накладывает понятные ограничения. Разветвленные иерархии в принципе не могут быть быстрыми, но являются достаточно экономичными. Таким образом, для того чтобы умножить скорость иерархии, мы должны в определенной степени обойтись без нее.
- Архитектура и технология. Есть ИТ-системы, над которыми мы работаем годами, поколения программистов связывают воедино все, что только можно, внутренне превращаясь в безумный монолит, где аббревиатура «CI/CD» вызывает удивление, отвращение или нервный смех — такие системы невозможно ускорить в несколько раз. Это не означает, что вы зашли в тупик; это означает, что вам придется принимать очень сложные (и дорогие) технические и архитектурные решения, чтобы ускориться.
- Работа с входными данными. Даже самая хорошая производственная система может быть полна мусора. Время выхода на рынок — это здорово, но время выхода на рынок чего? Чего хотел клиент (в конце концов, каждая идея гениальна и принесет миллиарды долларов)? Или наш технологический долг? Или задачи по эксплуатации и обслуживанию того, что мы уже создали? Если для решения наиболее интересных бизнес-задач доступна лишь небольшая мощность производственной системы, если эта мощность непредсказуема по объему, если мы не замкнули пресловутый контур обратной связи и не оцениваем результаты того, что делается, с точки зрения бизнеса — тогда мы не испытаем мультипликативного ускорения.
- Организация производства. Вспомните разговор о потоке ценности, о потерях и их методичном устранении, о методе Канбан и пределах WIP, о порядке и ограничениях для поддержания порядка. По пути мы вдруг понимаем, что новая организация производства не так уж высоконаучна, почти все очень логично и довольно просто. Кроме того, в такой производственной системе удобно находиться (что, несомненно, является приятным преимуществом).
Вышеперечисленные пункты не являются приоритетными. Понятие «приоритет» не применимо к этим пунктам — они нужны вам все.
— Мне нужно 500 000, и желательно все сразу, а не частями.
— Почему бы не выплачивать его в рассрочку?
— Я бы взял его частями, но мне нужно все сразу.
И. Ильф, Е. Петров, «Золотой теленок».
Но есть приятный нюанс: ни один из пунктов не требует смены персонала. Ни разработчики, ни аналитики, ни руководители групп, ни даже менеджеры.
А можно пример?
Вы. Самым ярким примером, который несколько изменил мое отношение к этим мультипликаторам ускорения в 2017 году, стал мой опыт участия в симуляции Project Phoenix. Из приведенного списка второй пункт вообще отсутствует в игре (в конце концов, игра — это всего лишь рабочий день, а не компьютер), но остальные можно испытать на собственном опыте.
Сначала участников «делят» на группы. В течение дня, в четырех итерациях, группе придется иметь дело как с исходными данными (над чем работать), так и с процессом (как работать).
Стоит отметить, что почти все команды организуют себя в начале дня так же, как это делает их компания. Игра — это такое зеркало. Бывает, что у них входит в привычку не задавать вопросов о поставленных компанией задачах; «договариваться» о рабочем процессе устно; передавать почти все полномочия по принятию решений начальнику; охранять свою территорию и не пускать туда посторонних; активно помогать всем вокруг, что вызывает еще больший хаос — много чего бывает. Измеренное время выхода на рынок после первого раунда обычно составляет 25 минут на каждую выполненную задачу, а процент выполненных задач, которые приводят к появлению продукта, составляет 25-50%, при этом выполняется от 1 до 3 задач.
В конце дня часто наблюдаются разные результаты: Время выхода на рынок составляет от 40 секунд до 1,5 минут на задачу, процент принятых и выполненных задач — 85-100%, а выполненных задач — более 10. За то же астрономическое время.
Вот что я заметил. Те же участники, что и утром, «разогнались» с 25 минут до 1. Не потому, что они наконец-то поняли правила и механику игры — правила очень просты. Не потому, что игра была «взломана» — ее, конечно, можно взломать, но не взламывать. Потому что в тестовом примере из четырех вышеперечисленных пунктов сработали только три. И если утром вы скажете им, что ожидаете 25-кратного ускорения, реакция будет предсказуемой — сказка. Это не так.
Правильно, нет. Но правильнее будет сказать, что это так, но не для всех. Не каждая команда имеет такой эффект.
Тип работы. Важно разделить метрики по видам деятельности и отслеживать их отдельно. В конце концов, время цикла работы над ошибкой нельзя сравнивать с временем цикла работы над новой функцией.
Скорость сжигания бэклога
Если вы не хотите или не можете иметь дело с Jira и расчетом метрик, есть альтернатива. Давайте рассчитаем коэффициент сгорания незавершенного производства на заказ продукции. Метод пугающе прост, но он работает. Как говорится, «Keep it simple, stupid» (принцип проектирования, принятый в ВМС США).
Предложите командам любую систему подсчета баллов за выполнение заданий. В точках памяти, в часах, в кусках — как вам угодно.
В конце каждого весеннего/повторного периода/месяца фиксируйте два показателя: сколько единиц было запланировано для работы и сколько единиц было фактически выполнено. Создайте простую таблицу или приборную панель на основе этих данных.
Мы можем четко увидеть слабые места системы и получить много конкретной информации для работы над улучшениями.
В нашем примере мы собираем статистику по завершенным сюжетным точкам в спринте каждой команды. Сюжетные точки «сгорают», как только работа достигает статуса «Готов к выпуску», т.е. она была протестирована и готова, осталось только запустить ее в производство.
Важно отметить, что любую систему довольно легко обмануть. И история с оценкой метрик не является исключением. Рано или поздно ваши команды найдут способ жульничать с оценками, это неизбежно. Но обычно первыми способами обойти систему являются позитивные оправдания — «а мы разбиваем реструктуризацию на более мелкие», «а мы делаем меньше спринтов», «а мы оставляем запас времени для непредвиденных задач и подач». Это приводит к положительному результату процесса развития. Это также требует лучшего анализа задач, отказа от того, что «не подходит», и предоставления времени для исправления ошибок.
Вывод
В первой части мы рассмотрели вопрос «Как быстро мы бегаем?». И это только верхушка айсберга. Вы можете бежать очень быстро, но бежать в неправильном направлении или упираться в стену.
Во второй части я расскажу о том, как оценить качество продуктов, созданных продуктовыми командами (и ответить на вопрос «Где мы находимся?»), и как мотивировать их должным образом для достижения коммерчески успешных результатов по продуктам.
