Time to decision что это
Time to market: почему показатель важен в кризис и при чем тут облако
Что такое Time to market?
TTM — это время от начала разработки идеи до конечного запуска решения и его выхода на рынок. Например, для мобильного или корпоративного приложения Time to market начинается с момента, когда компания только решила его создать. И заканчивается, когда приложение публикуется в сторе или внедряется в компании.
Time to market — один из ключевых показателей для стартапов. Но он также важен для любых компаний, которые выпускают или внедряют новые решения.
Чем меньше значение TTM, тем лучше. Ведь если создание и запуск продукта затягиваются, компания может отстать от конкурентов и упустить выгоду. А инновационное решение — потерять свою инновационность. По данным Gartner, примерно 20% продуктов, выпущенных с задержкой, не достигают своих целей.
Почему этот показатель так важен в кризис?
Иногда эксперты называют срок выхода продукта на рынок термином Time to revenue, то есть временем до получения первой выручки. Это очень хорошо отражает ситуацию. Пока не пройдены все необходимые этапы подготовки и запуска, компания не начнет зарабатывать на новом решении.
В кризисные периоды у бизнеса, как правило, нет лишних ресурсов, чтобы вкладываться в проекты без быстрой отдачи. Тем более, что проект может «не полететь».
Но главное, сокращение Time to market позволяет компаниям серьезно экономить. Например, если речь идет о создании ИТ-продукта, зарплата ИТ-специалистов составляет сотни тысяч рублей в месяц. Уменьшив время выхода на рынок с нескольких месяцев до нескольких недель, эти ресурсы можно направить на другие цели.
Бизнес, прошедший через периоды экономической нестабильности, хорошо это понимает. После мирового кризиса 2008 года компания Amdocs отмечала рост внимания к TTM. Если в 2008-м его называли одним из важнейших бизнес-показателей только 58% поставщиков услуг и сервисов, то три года спустя цифра выросла до 70%. А сегодня сокращение TTM — одна из самых обсуждаемых тем в компаниях, которые выводят новые продукты на рынки.
Какие этапы включает в себя Time to market?
ТТМ включает несколько основных стадий, которые проходит команда при создании нового продукта или функции:
Чаще всего самый длительный этап — это разработка. К примеру, на создание приложения средней сложности может уйти от полугода.
Какие еще факторы влияют на Time to market?
Срок выхода на рынок прямо пропорционален сложности продукта и требованиям к его качеству. Многое также зависит от возможностей ИТ-подразделения компании, которая занимается разработкой. Однако даже в крупных корпорациях с собственным ИТ-департаментом релизы иногда готовятся намного дольше запланированного и содержат критические ошибки.
На TTM сильно влияет и выбранный подход к разработке: сроки создания решений полностью с нуля и из готовых компонентов отличаются в разы.
По подсчетам Gartner, только 55% продуктов запускается вовремя, а оставшиеся 45% релизов откладываются как минимум на месяц. «Продукт может не запускаться в запланированные сроки из-за нескольких факторов, включая отсутствие формализованных процессов запуска, задержки в разработке продукта (баги, ошибки, нестабильность функций), невыполнение требований клиентов, качество продукта или даже проблемы с поставками», — отмечают аналитики.
Как можно сократить Time to market?
Чтобы быстрее вывести продукт на рынок, компании часто готовят MVP (Minimum Viable Product — минимально жизнеспособный продукт, позволяющий получить обратную связь) с ограниченным функционалом и тестируют его на потребителях. Это позволяет выявить ошибки в продукте и оценить его востребованность.
Например, Uber начинался с упрощенного мобильного интерфейса, который использовали только основатели и их знакомые. Тарифные функции, платежи по кредиткам и отслеживание машин в реальном времени появились намного позже.
Однако после запуска MVP решение все равно приходится докручивать. Если делать это «по старинке», потребуется время.
Среди самых эффективных способов уменьшить TTM — использование облачных ИТ-ресурсов вместо физических серверов, отказ от архаичных подходов к разработке в пользу готовых решений на облачных платформах.
Каким образом облака помогают ускорить выход на рынок?
Облачные сервисы ускоряют процессы по двум основным направлениям.
Их предоставляют поставщики облачных услуг (облачные провайдеры) в рамках услуг PaaS — Platform as a Service. Эти сервисы специально спроектированы, чтобы ускорить и упростить процесс создания решений. Разработчики продукта получают готовую программную среду для написания, тестирования и размещения приложений вместе с набором дополнительных инструментов.
Так, на облачной платформе SberCloud.Advanced компании SberCloud интегрированы и инфраструктурные облачные услуги (IaaS), и платформенные PaaS-решения. Например, услуга развертывания приложений в облаке, бессерверные вычисления, облачные базы данных реального времени и другие продукты.
При этом облачные сервисы можно использовать как конструктор, собирая решение из готовых блоков. Это позволяет сначала без задержек создать MVP продукта, затем быстро протестировать его, внести изменения и выпустить на рынок готовую коммерческую версию.
Таким образом TTM решения сокращается в несколько раз. А сам процесс создания и запуска становится более прогнозируемым и надежным за счет автоматизированных систем работы с сервисами.
Как заявил президент, председатель правления Сбербанка Герман Греф, на встрече с инвесторами и акционерами (Investor Day 2020) переход на новую облачную цифровую платформу сократил Time-to-market новых продуктов «Сбера» в семь раз.
Каким компаниям и в каких проектах стоит использовать облако для сокращения TTM?
Облачные сервисы помогают выполнять почти любые задачи, связанные с созданием собственного ПО и кастомизированных корпоративных решений. Это может быть запуск чат-бота, дополнительный функционал для интернет-магазина, новый онлайн-сервис или приложение. То есть, речь не только о проектах ИТ-компаний и крупных «цифровых» корпораций. В облаке решения можно строить из уже готовых элементов, и для этого необязательно иметь глубокую экспертизу в ИТ.
В SberCloud отмечают, что их платформа позволяет создавать облачные продукты и сервисы в любых областях экономики, науки и образования — от мобильных приложений в ретейле до платформ дистанционного обучения для вузов и финтех-продуктов.
Наращивать использование облаков собирается большинство компаний, показало исследование Flexera: 59% предприятий ожидают, что облачные сервисы будут применяться шире, чем планировалось в доковидный период.
При этом эксперты отмечают рост интереса к PaaS и, в частности, контейнерным технологиям. Контейнеры — это автономные единицы ПО, в которых есть все необходимое для работы приложений — код, среда запуска, библиотеки и настройки. Компании используют их, чтобы быстрее разворачивать приложения и масштабировать процессы, указывают во Flexera.
Как это работает с ИТ-стартапом?
Возьмем один из самых распространенных примеров — технологический стартап, который активно работает с различными данными. Допустим, в стартапе активно используется ИИ. В этом случае ему понадобится облачная инфраструктура, желательно автомасштабируемая под клиентский трафик, управляемая база данных, сервис развертывания и управления контейнерами приложениями на основе Kubernetes, сервис аналитики данных, сервис мониторинга и управления приложениями и инфраструктурой и ряд других облачных услуг.
Почему облачных? Совершенно понятно, что cамостоятельная покупка оборудования, инсталляция и настройка взаимодействия всех этих приложений никак не вписывается в бизнес-модель стартапа с его ограниченным количеством финансовых, трудовых и временных ресурсов.
Единственный вариант успешно запустить такой стартап, это использовать готовые инфраструктурные (IaaS) и платформенные облачные сервисы (PaaS). Идеально, если они будут еще интегрированы между собой.
Поставщики облачных услуг уже предлагают такие варианты. Например, на платформе SberCloud.Advanced можно получить сразу и IaaS сервисы, такие как Elastic Cloud Server — легко конфигурируемый и масштабируемый виртуальный сервер с возможностью автомасшатбирования, а также все необходимые для быстрой реализации идеи платформенные сервисы (PaaS).
Что важно в такой бизнес-модели. Размер оплаты облачных сервисов зависит исключительно от количества клиентов стартапа. Клиентов мало — потребление небольшое, затраты на облако минимальны. Количество клиентов и размер выручки растут — соответственно есть возможность спокойно масштабировать бизнес и увеличивать потребление облачных услуг.
Мы уже используем облачные сервисы. Как еще можно сократить TTM?
Основной совет — работать над MVP, избавляться от всего лишнего и концентрироваться на ценности для клиента и компании. Также стоит обратить внимание на концепцию Lean startup. Обобщайте и проверяйте гипотезы и, главное, постарайтесь как можно раньше получить обратную связь от потребителей продукта. Как показывает опыт, даже самое длительное и детальное тестирование не заменит мнения живого пользователя.
Time to market: не теряйте время, это слишком дорого
В современном бизнесе есть понятие time to market — это время, которое компания тратит на реализацию и выпуск бизнес-идеи своим клиентам. Чем ниже time to market, то есть чем быстрее фича отправляется в продакшн, тем быстрее зарабатываются деньги для бизнеса. Подробнее — в статье руководителя отдела производства продукта для магазинов Леонида Савченкова.
В Яндекс.Маркете мы внедрили несколько изменений, которые помогли нам сократить время разработки новой фичи с 64 до 46 дней. Их можно применить в любой команде, которая разрабатывает софт.
После того, как разработчик написал код и убедился, что всё работает как ожидается, обычно требуется ещё несколько шагов до выкладки в прод. Сначала нужно провести код-ревью и тестирование. Затем код нужно упаковать, обновить конфиг, подготовить изменения в базе данных. В общем случае это выглядит так:
Теперь давайте посмотрим, как можно ускорить каждый из этапов.
Если код-ревью для вас — обязательный этап, максимально оптимизируйте его. Отдайте линтеру все стилистические требования, чтобы живой человек на них не отвлекался. Договоритесь в команде о правиле, что на код-ревью отводится 24 часа. Внедрите инструмент, который автоматически раздаёт задачи на код-ревью — с учётом справедливости, опыта членов команды и календаря отсутствия.
Вот так у нас получилось ускорить этот этап (на графике изображён 80-й персентиль времени, за которое коммит проходит код-ревью):
Ручная проверка готового релиза QA-инженерами может занимать много времени. Как правило, она проходит в два этапа: тестирование новой функциональности, ради которой и затевался релиз, и регрессионное тестирование, чтобы убедиться, что мы ничего не сломали. Ускорить процесс поможет уменьшение размера релизов и автоматизация тестирования.
Если релизы будут небольшими и простыми в развёртывании (см. следующий пункт про CI и CD), их легко будет тестировать. Стоит целиться в один релиз в день.
Далее избавляйтесь от ручного регрессионного тестирования — пишите интеграционные тесты на весь регрессионный пак. Для бэкенда это достаточно легко. Тесты должны писаться против контрактов API и покрывать все возможные ситуации. Интеграционные тесты при этом прогоняются против настоящего тестового окружения или с использованием моков наиболее сложных сервисов, состояние которых непросто воспроизвести. Тесты пусть пишут сами разработчики. Для фронтенда тесты пишутся против интерфейса и, как правило, ближе к концу реализации фичи. Фронтенд-тесты часто играют роль интеграционных.
После такого подхода к автоматизации профессия тестировщика бэкенда в Яндекс.Маркете исчезла как класс. Существующие QA-инженеры остались для фронтенда.
Вручную они теперь проверяют только новый функционал, а для регрессионного тестирования пишут автотесты.
Вот так мы избавились от ручного регресса для личного кабинета партнёров Маркета в 2019 году:
Agile тренд: управление компаний в 2018 году
Agile [эджайл] тренды в управлении компании Гибкое управление Agile становится очень популярным среди руководителей компаний. Формирование Agile команд повышает конкурентоспособность бизнеса и дает возможность получать прибыль в условиях изменений или кризиса.
Используя гибкое управление вы получаете возможность быстро реагировать на изменения, добиваясь необходимых показателей эффективности, а в некоторых случаях даже превосходя их.
Agile в управлении компанией
Большинство бизнесов сейчас зависит от умение быстро адаптироваться к требованиям рынка, а для того чтобы это уметь сделать необходимо использовать методы гибкого управления.
Как внедрить Agile правильно?
Основная ошибка заключается в применении методологии гибкого управления Agile из ИТ в других бизнес-процессах компании без соответствующей адаптации, что в дальнейшем приводит к провалу Agile проектов и не дает возможность получить результат от гибкого управления.
Адаптация технологии и Обучение персонала — вот два направления, про которые вы должны помнить, если заинтересованы в успешном внедрении Agile в вашей компании. Не надо строить иллюзии, что ваш ит специалист или сторонний Agile тренер с опытом внедрения Agile в при разработке программных продуктов сможет решить ваши задачи, скорее всего наоборот вы получите множество конфликтных ситуаций, которые вас потом придётся решать самостоятельно.
[bctt tweet=»Адаптация технологии и Обучение персонала — вот два направления, про которые вы должны помнить» username=»SavkinKS»]
Agile трансформация
Трансформация означает переход компании с одного типа управления, на другой — в данном случае на гибкое управление.
Мое любимое высказывание:
[bctt tweet=»Гибкое управление в ежовых рукавицах.» username=»SavkinKS»]
[su_note note_color=»#ADFF2F» text_color=»#333333″ radius=»3″ четко олицетворяет правильный акцент при внедрении Agile в бизнес, так как многие руководители считают что Agile это путь к свободе и анархии внутри компании, а это далеко не так.[/su_note]
Я считаю будет очень опрометчиво начинать эджайл трансформацию со всей компании, необходимо выбрать пилотный проект и на нем отточить внедрение технологии, потенциальные конфликты среди персонала.
[su_note note_color=»#FFFF66″ text_color=»#333333″ radius=»3″ что одно дело общий интерес руководителей и сотрудников всех отделов к методологии гибкого управления и совершенно другое внедрять данные подходы на практике в реальном бизнесе и с высоким уровнем ответственности.[/su_note]
Преимущество Agile
Agile использует два ключевых показателя, которые интересуют любого руководителя:
Применение гибких методологий дают вам возможность сократить данные показатели и на мой взгляд, очень важно сокращение времени принятия решения, но помните хорошую поговорку:
Семь раз отмерь — один отрежь
Это всё про Agile (эджайл) кстати, а вот некоторые бизнес тренеры по гибкому управлению забывают про это и слепо следуют лозунгам: внедрим и быстро, очень халатно проводя корпоративное обучение персонала.
Цели компании при внедрении методов гибкого управления
[su_note note_color=»#ADFF2F» text_color=»#333333″ radius=»3″ перед руководителями компаний сейчас стоят очень серьезные задачи, но не стоит строить иллюзий и думать, что гибкое управление моментально решит все ваши проблемы, а сотрудники после пары бизнес тренингов станут умными и гениальными.[/su_note]
И кстати, текущий подход в управлении проектами меняется не потому что меняется рынок, а потому что меняются сотрудники, которыми становится все тяжелее управлять, находить новых и удерживать старых.
А отношение людей к работе зависит от многих факторов, а не только от Agile.
Как выбрать эксперта по Agile?
Следует понимать, что на рынке присутствуют компании, которые внедряют Agile и множество экспертов, которые работают самостоятельно.
Обращаю ваше внимание, что стоимость взаимодействия с компанией существенно выше, более того держать в штате профессионала по Agile довольно дорого, поэтому многие компании ограничиваются или посредственными экспертами по Agile или берут профессионала и делают наценку на его работу.
Возникает простой вопрос: зачем платить дважды?
Поэтому я рекомендую пообщаться с несколькими Agile тренерами, возможно запустить пилотный проект.
Сообщество Agile
Следует понимать, что Agile это не свод теорем или законов к обязательному исполнению:
[su_note note_color=»#FFFF66″ text_color=»#333333″ radius=»3″ это методика, которую обязательно необходимо адаптировать на ваши бизнес-процессы, учитывая особенности персонала.[/su_note]
И я рекомендую принимать во внимание тот факт, что Agile был хорошо известен в ИТ кругах лет 10 назад, но не каждый программист или руководитель проекта по внедрению информационных технологий сможет внедрить гибкое управление в вашей компании, скорее всего вы получите обратный эффект.
Следует помнить, что эджайл, как методика масштабируется на все бизнес-процессы компании, позволяя использовать преимущества гибкого управления, давая новые подходы руководителям отделов продаж, маркетинга, управления персоналом.
Я рекомендую обратить внимание на мою учебную программу по изучению Agile, которая может быть адаптирована на корпоративный тренинг или специализированный семинар для определенной отрасли.
[bctt tweet=»Не каждый программист сможет внедрить гибкое управление в вашей компании» username=»SavkinKS»]
Опыт внедрения Agile
Следует понимать, что практически каждая западная компания использует гибкое управление в своих бизнес-процессах, добиваясь превосходных результатов и это не только ит компании такие как Google или Amazon, это и Zappos, Zara, но опять же для успешного внедрения необходимо адаптировать зарубежный опыт под наш менталитет и корпоративную культуру внутри компании.
Перспективы Agile в России
Следует отметить, что очень большие перспективы у методов гибкого управления в государственном секторе, смотрите заметку 868967.
Конечно, с одной стороны для этого необходимы изменения в законодательстве, но с другой стороны обучение государственных служащих и небольшие пилотные проекты можно запускать уже сейчас.
[bctt tweet=»Agile масштабируется на все бизнес-процессы компании» username=»SavkinKS»]
На самом деле методы гибкого управления начинают использовать практически во всех отраслях где существует управление проектами в департаментах маркетинга и рекламы, продаж, сервисного обслуживания.
[su_note note_color=»#ADFF2F» text_color=»#333333″ radius=»3″ дает хорошие возможности и было бы очень глупо использовать их только при разработке программного обеспечения.[/su_note]
Как можно использовать Agile (эджайл) в компании
Предпосылки для внедрения Agile
Как определить что компании действительно нужен Agile? — необходимость к изменениям и быстрой реакцией на рынок является основой для внедрения методов гибкого управления, в Agile это называется трансформация.
Стоит ли пробовать внедрять Agile просто так, следую бизнес моде? — я отвечу, что да стоит, но начинать с небольших проектов для того чтобы прочувствовать необходимость масштабных изменений и хотя бы частично понять проблематику внедрения.
[su_note note_color=»#ADFF2F» text_color=»#333333″ radius=»3″ очень важно понимать, что методология гибкого управления распространяется на весь проект, начиная с различных этапов и конечно же не стоит доводить дело до абсурда и внедрять Agile там где он не нужен, например в стандартизированные производственные процессы.[/su_note]
Помните, что применение гибкого управления означает не слепое исключение других методов управления, а наоборот их дополнение.
Как использовать Agile для создания эффективных команд
[su_note note_color=»#FFFF66″ text_color=»#333333″ radius=»3″ Agile команд повышает конкурентоспособность бизнеса и дает возможность получать прибыль в условиях изменений или кризиса.[/su_note]
Одна из ключевых задач Agile, методов гибкого управления:
Создавать высокоэффективные команды, способные достигать новые цели. Как это сделать, используя текущий персонал в вашей компании, об этом мы поговорим в данной заметке. Мы с вами знаем, что в Agile (эджайл) основной акцент делается на управление отношениями и деловыми коммуникациями между сотрудниками, клиентами и партнерами, иными словами на отношения между людьми. И уже через отношения мы выходим на построение работы по достижению результата.
Как известно, для достижения успеха нужно заниматься тем, что нравится и Agile с этой точки зрения позволяет сконцентрироваться сотрудникам на том, что им нравится и интегрировать себя в общий процесс. Согласитесь это довольно интересно, особенно если суметь совместить это с целями и задачами компании.
Именно по этой причине Agile повышает профессионализм сотрудников, он просто способствует в движении в правильном направлении.
Agile и стратегия непрерывного совершенствования
Про стратегию непрерывного совершенствования сказано довольно много, а одной из особенностью управления по Agile есть постоянный анализ целей и способов их достижения, мы фактически создае и задаем необходимый темп.
Обратная связь позволяет оценить:
Вы можете использовать различные проекции или ретроспективы, например:
[su_note note_color=»#FFFF66″ text_color=»#333333″ radius=»3″ методы гибкого управления среди самих сотрудников, вы направляете обучение и развитие персонала в максимально выгодную сторону.[/su_note]
Более того, Agile задействует ваш прошлый опыт, позволяя создать уникальные для вашей команды принципы и методы работы.
Командообразование в кризис
Мы с вами понимаем, что:
Одни бизнес-модели могут принести вам прибыль, но точно также эти же бизнес-модели могут вам принести значительные убытки, если вы не успеете измениться под задачи рынка.
Сейчас бизнес должен уметь быстро адаптироваться, изменяя не только бизнес-процессы, но и мышление. 
Какие отличия Agile от других систем управления
К сожалению, классическое планирование не даёт нужного эффекта в состоянии бизнес хаоса и неопределенности, а для того чтобы развернуть ситуацию в плюс и извлечь выгоду вам необходимо рассмотреть возможности методов гибкого управления, что дает вам следующие преимущества:
1. Адаптивность
Вы можете очень быстро приспосабливаться и использовать изменения.
2. Быстро принимать решения
Наделите людей полномочиями и ответственностью в принятии решений, а не ошраничивайте их действия лишней бюрократией.
3. Определите временной темп
Бизнес это марафон, а не спринт, а при любом марафоне важно соблюдать выбранный темп. У вас есть свой темп? Вы его придерживаетесь?
4. Лучше просто, чем сложно
Стремитесь максимально упрощать сложные задачи, что позволит вам увидеть истину и выработать оптимальное решение.
5. Формат мозговых штурмов
Определите правильный формат мозговых штурмов и обсуждения вопросов, стремитесь не критиковать, а обсуждать.
И помните, что методы гибкого управления Agile меняют мышление, а мышление бысто поменять тяжело, на это требуется время, но при этом вы должны быть уверены, что внедрение методов гибкого управления позволит произвести прорыв в вашем бизнесе.
Если у вас возникли вопросы по применению методов гибкого управления в своих компаниях напишите мне напрямую. Спасибо!
[bctt tweet=»Применение гибкого управления Agile означает не слепое исключение других методов управления, а наоборот их дополнение.» username=»SavkinKS»]
Time-to-Market как козырь для внедрения DevOps
Представьте себе фантастическую ситуацию — директор компании решает внедрить DevOps. Сам, без давления со стороны технарей. Без убедительного примера конкурентов. Руководство само признало, что повысить качество продукта, предсказуемость, прозрачность и повторимость бизнес-процессов при разработке и внедрении ПО невозможно без средств DevOps.
Представили? Получилось? Вы успешно прошли тест на самое богатое воображение!
На самом деле, конечно же, всё не так. Чаще всего руководству не до наших ИТ-шных штучек. Поэтому приходится убеждать. Но как?
Когда в качестве аргумента приводится повышение культуры общения между программистами и системными администраторами, то легко можно нарваться на контраргумент: а сейчас вы некультурные, что ли? Или даже могут напомнить о затратах, которые уже понесла компания год-два назад, когда вы дружно переходили на Agile. Неужели в ИТ каждый год появляется фича, способная продвинуть процессы революционным способом?
Насчёт повышения качества продукта тоже можно заикнуться. Но осторожно. Поскольку задачу программировать без ошибок ещё никто не отменял. Да, без багов никак, но именно поэтому в компании есть «целый отдел тестировщиков», не так ли?
Предсказуемость процессов — это вообще такой субъективный фактор, обосновать который и избежать шуток про Вангу и Нострадамуса довольно сложно.
При этом, если мы говорим о типичном энтерпрайзе, то в такой компании, скорее всего, есть уже сложившаяся ИТ-команда. И эта команда в старом (если не считать Agile) привычном ритме трудится вместе немало лет и вряд ли горит желанием (опять) что-то менять. Всех всё устраивает, кроме, естественно, руководства. Которое видит, что в их ПО постоянно сыплются какие-то ошибки, смещаются сроки выпуска новых версий.
Конечно, можно предположить ещё один вариант, когда в компанию приходит человек с опытом в DevOps, ясно представляющий, в чём проблема и как её нужно решать. И который способен донести своё мнение до руководства. Однако давайте не будем надеяться на чудо-дядю.
И на этом многие ломаются. Начинают говорить, что никто их не поддерживает, что в этом болотце ничего внедрить невозможно и затем просто уходят в другую компанию, где цикл повторяется.
Получается замкнутый круг? Нет, просто постепенно мы приходим к выводу, что с бизнесом нужно говорить только на понятном ему языке — на языке денег. Для этого мы достаём из широких штанин рукава главный козырь — сокращение Time-to-Market. Нужно показать, что благодаря DevOps новые версии продукта будут выпускаться, как горячие пирожки. А все остальные вышеперечисленные выгоды от внедрения DevOps давайте оставим для итоговой презентации, которую мы создадим для директора, когда все получится. Многие скажут, что это слишком очевидно. Нет!
Нам нужно что-то, что займет у нас минимум времени и ресурсов (ведь никто не разрешит списывать человеко-месяцы на внедрение некоего DevOps и не закупят для нас срочно новых серверов), но при этом даст очень ощутимый результат (реально сократит Time-to-Market).
Для начала нужно найти бутылочное горлышко, а оно всегда одно (первый шаг в теории ограничений Голдратта). После успешного внедрения Agile (а все это имеет смысл только после внедрения Agile), в плане разработки софта всё равно им остается ручное тестирование. Даже при наличии пула свободных рук, регрессионное тестирование может занять две-три недели. А уж от том, как тестировщики «любят» проводить регрессионное тестирование, знаю все.
Итак, мы определили, что бутылочным горлышком является тестирование. Тогда начать нужно с его автоматизации. Многие заметят: легче сказать, чем сделать. Уже написаны миллионы строк кода, и хорошо, если программисты хоть что-то покрыли модульными тестами. На самом деле все не так страшно, как кажется. Как показывает опыт, 80 % успешного результата в виде серьезного снижения Time-to-Market достигается за счёт 20 % усилий. Именно во столько примерно обходится автоматизация тестирования в нашем случае.
Совсем по закону Парето, ага.
И самое главное, запустить автоматизацию тестирования можно ещё до того, как руководство согласится выделить ресурсы на внедрение остальных частей DevOps. Небольшой такой пилотный проект, который можно сделать собственными силами за одну-две недели.
Но при этом такая ситуация нам даёт шанс одержать эффектную и, самое главное, быструю победу. После которой, имея позитивный настрой и благословение руководства, уже можно просить и деньги, и ресурсы.
Начнём с того, что, наверняка, ваши программисты уже используют какое-либо серверное ПО для ежедневной сборки. Это может быть TeamCity, либо Bamboo, либо Jenkins, — не принципиально. Главное, часть автоматизации уже есть и это нужно использовать, а если нет, то за день его легко развернуть.
Сначала надо автоматизировать «дымовые» тесты. А как понять, что автоматизировать? Да просто посмотрите, что у вас регулярно ломалось при выкладке изменений за последние полгода.
Дальше нужно создать несколько тестов проверки работы основных бизнес-процессов. Как их определить? Задать вопрос вашим аналитикам/директорам/представителям бизнеса, при какой поломке в кабинет к программистам вбегает разъяренный директор и ставит задачи повышенным голосом.
Неделя, ну максимум две на создание таких тестов. В результате — очень быстрый фидбек на предмет глобальных ошибок.
И пока проект в режиме proof of concept, не надо заниматься подготовкой того же автоматического развертывания сервера для тестирования и прочими бантиками, а всё сделать вручную. Эту красоту потом можно с удовольствием сделать вместе с админами.
К чему это приведёт, догадаться не сложно. Разработчики сразу будут видеть (и исправлять) свои ошибки. Тестировщики будут избавлены от рутины в виде проведения долгих и нудных тестов на регресс. Им останется пара-тройка дней для того, чтобы протестировать только те места кода, которые были подвержены правке. Да-да, именно так. А если нет, то вернитесь в начало и еще раз поговорите с аналитиками/директорами/представителями бизнеса на тему критичных для бизнеса процессов.
Бутылочное горлышко, из-за которого возникали основные тормоза, ликвидировано. Теперь остаётся только выпустить несколько новых релизов в продуктивную среду, снять статистику «было/стало» и идти с этими цифрами к руководству. Профит!
После такой убедительной победы уже можно разговаривать про автоматизацию развертывания стендов (как минимум для тестирования). Далее выпрашивать средства на мониторинг и прочие прелести DevOps. При этом нужно помнить, что остальные компоненты системы уже не будут иметь вау-эффекта для бизнеса.
Пример в студию
В завершение поста, думаю, уместно будет привести пример успешно завершенного проекта по внедрению DevOps, который реализовала наша компания.
У одного крупного ритейлера около 20 % бизнеса приходится на интернет-магазин. При этом реагировать на рыночную ситуацию и вносить необходимые изменения в ПО нужно очень быстро. И часто. И качественно. Любой косяк на сайте может повлиять на конверсию, риски выражаются в реальных деньгах.
Для сокращения времени обновления и повышения качества была создана специализированная платформа автотестов, на которой были автоматизированы рутинные задачи по тестированию изменений и регресса сайта. Кроме того, был выстроен процесс взаимодействия группы автоматизированного тестирования с командами разработки. Это позволило разработчикам сразу выявлять и исправлять дефекты в обновляемой системе, не дожидаясь финального приемочного тестирования.
Представители ритейлера сочли опыт успешным и решили применить его к остальным софтверным продуктам.
И ещё небольшой пример, но уже из практики одной крупной страховой компании. До внедрения автоматизации тестирования релизы выходили раз в полгода. Не потому, что так требовал бизнес, — просто чаще не получалось. А заказчик как раз хотел. Так вот, через два месяца после начала внедрения средств автотестирования, ИТ-команда перешла на двухнедельные итерации выпуска релизов.
Достаточно показательно, чтобы начать этим заниматься, не так ли?
Сергей Страмнов, пресейл-архитектор Центра программных решений «Инфосистемы Джет»