Применение принципов бережливого стартапа к Open Source проектам (перевод)
Оригинал: https://opensource.com/article/21/7/lean-startup-open-source
Автор: Ip Sam (Red Hat)
Переводчик: Gim6626
Прим. пер.: В статье автор больше пишет про запуск Open Source проекта в рамках существующего бизнеса, а не с нуля и не сообществом добровольцев. Тем не менее, статья может быть интересна и для последних случаев (и была интересна для меня, так как у меня есть несколько проектов), поскольку такие проекты зачастую стартуют и развиваются хаотично и приводят к выгоранию из-за отсутствия оказывающихся необходимыми для развития сложного проекта навыков управления. Тем более, если смотреть с более высокого и общего уровня, бизнес действует исходя из необходимости получения максимальной отдачи (для него это прибыль) при расходовании минимума ресурсов. У добровольцев ресурсы ещё более ограничены и вопрос эффективности стоит ещё более остро, хотя метрики получаемых благ у них отличаются.
Принципы «бережливого стартапа» помогут вам эффективно и успешно управлять своим проектом с открытым исходным кодом.
Запуск проекта с открытым исходным кодом даёт много преимуществ. В целом, проекты с открытым исходным кодом выигрывают от сотрудничества, принятия, прозрачности, более низкой стоимости поддержки, передовых методов разработки, большего числа участников и рецензентов и более высокого качества.
Когда вы участвуете в проектах с открытым исходным кодом, вы можете развить свои технические и лидерские навыки, получить хороший опыт для своего резюме, изучить новые инструменты разработки, понять отраслевые тенденции, поработать с ведущими инженерами по всему миру, получить возможности наставничества, встретить людей со схожими интересами, улучшите свои навыки работы с людьми и многое другое.
Когда вы разрабатываете свой собственный проект с открытым исходным кодом, вы во многом похожи на генерального директора стартап-компании, и многие стартапы используют принципы бережливого производства. В этой статье показано, как применить принципы бережливого стартапа для разработки и продвижения ваших проектов с открытым исходным кодом.
Придумайте хорошую идею
Обдумывая хорошую идею проекта с открытым исходным кодом, рассмотрите три области: отрасль, инструментарий и клиенты. Вам лучше придумать идею на пересечении этих областей. Например, я работаю над проектом с открытым исходным кодом для гибридного облака. Облачные вычисления — это моя отрасль. Инструментарий может быть набором сценариев Ansible, доступных для индустрии облачных вычислений. Заказчиками могут быть мои клиенты OpenShift, заинтересованные в использовании сценариев Ansible для настройки своей гибридной облачной инфраструктуры. Всё это подводит меня к пересечению трёх областей, и это может быть отличной идеей для проекта с открытым исходным кодом.
Как только вы определитесь с идеей с открытым исходным кодом, начните разработку проекта прототипа PoC (англ. Proof of Concept), поместите его в репозиторий Git и создайте бэклог проекта:
- Запустите простой прототип PoC.
- Отправьте PoC в общедоступный репозиторий GitHub.
- Создайте файлы README, LICENSE, CONTRIBUTING и CODE_OF_CONDUCT.
- Создавайте высокоуровневые эпики и пользовательские истории в Jira.
Затем начните работать над позиционированием вашей идеи проекта с открытым исходным кодом для долгосрочного успеха. Учитывайте предложения конкурентов, потребности клиентов и возможности компании. Например, если я знаю, что клиенты хотят автоматизировать облако в кластере OpenShift, я понимаю потребности клиентов. Возможности моей команды заключаются в использовании Ansible для автоматизации установки и обновления кластера OpenShift. И мне нужно убедиться, что конкуренты не выполняют аналогичную работу. В своем проекте с открытым исходным кодом я тоже использую Ansible для автоматизации. Другие компании могут использовать сценарии оболочки или сценарии PowerShell. Несмотря на то, что они разрабатывают технологии автоматизации, их предложения напрямую не мешают тому, что делает мой проект с открытым исходным кодом. Таким образом, я могу попасть в золотую середину со схемы ниже.
Используйте принципы бережливого стартапа
Управление рисками важно для проекта с открытым исходным кодом. В любой момент проект может потерять финансирование, людей и ресурсы. Бизнес-требования и сфера работы могут измениться. График выпуска может быть отложен или отменён. Сроки могут меняться из-за большой неопределённости. Как генеральный директор своего проекта с открытым исходным кодом вы можете использовать принципы бережливого запуска, чтобы минимизировать риски и максимизировать прибыль для своего проекта.
Принципы бережливого стартапа сосредоточены на разработке минимально жизнеспособного проекта (MVP), который как можно скорее принесёт вам пользу от производства. Это также способствует сокращению циклов выпуска и быстрой итерации. Используя обучение через обратную связи от производства, вы можете проверить свой проект с открытым исходным кодом и внести изменения по мере появления данных о продукте.
В цикле бережливого запуска вы сначала придумываете свою идею с открытым исходным кодом. Затем вы конвертируете свою идею в код, разрабатывая простой MVP. Между этими этапами вы настраиваете этап сборки (а также создаёте юнит-тесты для обеспечения качества вашего кода), CI/CD конвейеры для автоматизированных интеграций и развёртываний, инфраструктуру облачных вычислений, изолированную программную среду разработчика и используете другие лучшие практики разработки. Всё это позволит разработчикам быстрее писать код.
Вам нужно оценивать всё, от кодирования до производственных данных. Например, оцените удобство использования MVP, чтобы убедиться, что конечные пользователи могут его правильно использовать. Используйте мониторинг и предупреждения, чтобы знать, когда возникают производственные проблемы. Статический анализ кода помогает выявлять проблемы с кодом и уязвимости системы безопасности. Наконец, используйте данные обратной связи от пользователей продукта и заинтересованных сторон, это поможет вам осуществить оценку быстрее.
Все эти данные позволяют вам узнать больше о своем проекте. Вы можете учиться быстрее, проводя больше интервью с клиентами или работая с клиентами во время циклов разработки. Вы также можете быстрее учиться, создавая кросс-функциональные команды с другими бизнес-отделами. Когда вы снова пройдете циклы бережливого запуска во второй итерации, вы сможете быстрее программировать, быстрее делать оценки и учиться быстрее, чем на первой итерации.
Методологии бережливого стартапа помогут вам создать идею, сформулировать гипотезы на основе вашей идеи, создать MVP и протестировать MVP для проверки выполнения ваших гипотез. Затем вы анализируете то, что вы узнали, чтобы уточнить свои гипотезы, и начинаете вторую итерацию.
Бережливый стартап — это сочетание развития отношений с клиентами и гибкой разработки. Эта методология поддерживает более быстрые циклы итеративной разработки и инкрементную разработку продукта.
Используйте дизайнерское мышление, методы бережливого стартапа и agile-разработку
На рисунке ниже показаны три цикла дизайн-мышления, бережливого стартапа и гибкой разработки. Первая часть — это всегда дизайн-мышление (зелёный цикл), когда вы собираете требования для формулировки своей идеи. Часто они поступают от менеджеров по продукту. Затем вы переходите к циклу бережливого стартапа (синий), где вы обдумываете прототипы, проводите эксперименты и проходите период обучения. Основываясь на результатах вашего обучения, вы можете войти в последний (жёлтый) цикл agile-разработки. Он часто включает в себя типичные двухнедельные спринты, продумывание пользовательский историй в бэклогах ваших продуктов, перенос историй из невыполненных задач в планирование спринтов, выполнение спринтов, перемещение историй до завершения и отправку дополнительных продуктов в производственную среду путем развёртывания. В конце у вас есть обзор спринта, демонстрация спринта и ретроспектива спринта. После завершения гибкого цикла вы вернётесь к синему циклу, чтобы начать процесс формулировки требований, оценки и следующей итерации.
Часто у вас есть несколько MVP, прежде чем вы дойдёте до конечного продукта. Используйте отзывы клиентов и собирайте данные об использовании продукта, чтобы сформировать следующую версию MVP.
Треугольник управления проектом помогает поддерживать качество продукции. Объем, стоимость и время — это углы треугольника. Форма треугольника отражает качество продукта. Если вы уменьшите объём и затраты, форма треугольника изменится, а это означает, что ваше качество снизится.
Принципы бережливого стартапа могут помочь вам управлять объёмом, затратами и временем. Выполняя каждый выпуск с принципами бережливого стартапа, вы сможете получить инкрементные изменения, небольшие циклы выпуска, небольшие наборы функций выпуска и циклы обратной связи. Для каждой идеи необходимо оценивать, работает ли она, приносит ли она прибыль и ценность для бизнеса. Если вы ответили утвердительно, начните процесс реинвестирования, чтобы генерировать больше новых идей.
Привлечение контрибьюторов и построение команды
Проектный маркетинг — важная отправная точка для привлечения контрибьюторов и инвесторов в ваш проект с открытым исходным кодом. Изучите, как «продать» свой проект, представить его на крупных конференциях и мероприятиях, а также продемонстрировать свой PoC или MVP на местных встречах разработчиков. Если вы работаете в крупной организации, возможно, вы сможете превратить своё начинание во внутренний проект.
В ваш проект будут входить разные люди с разным опытом, стилями работы и культурой, и ваша цель — превратить их в высокопроизводительную команду. Команда будет проходить через кривые обучения, чтобы научиться работать вместе. Например, когда у вас появляются новые члены команды, текущий стиль работы вашей команды может не подходить им, и вы можете столкнуться с сопротивлением. Когда люди не хотят выходить из своей зоны комфорта, чтобы изучать новые навыки, вы также можете столкнуться с сопротивлением. Это может создать хаос, когда члены команды расходятся во мнениях по поводу того, как что-то делать. Команда может разделиться на разные лагеря с разными идеями. Это доводит эффективность команды до самой нижней точки кривой зрелости команды. Когда вы достигнете самой низкой точки, слушайте членов команды и работайте над тем, чтобы понять их идеи и причины, из-за которых люди сопротивляются, а затем преобразуйте полученные идеи в конкретные действия. Вы можете использовать системы голосования или использовать данные о продукте для подтверждения идей. По мере разрешения конфликтов члены команды начнут лучше работать вместе и интегрировать свои различные способы работы в общую культуру команды. Именно здесь ваша команда достигнет нового статус-кво и зрелости команды.
Метод бережливого управления командой может помочь вам достичь зрелости команды. Он использует четыре рычага контроля: ценности, правила, оценку и интерактивность.
- Ценности. То, во что верит ваша команда, что считает наиболее важным. Например, моя команда верит в качество как в требование к каждому продукту. Поэтому качество — основная ценность команды.
- Правила. Они связаны с установлением правил, основанных на основных ценностях. Например, моя команда верит в качество, и мы установили правила, требующие модульных и интеграционных тестов для каждого изменения кода перед его фиксацией в репозитории Git. Это становится правилами для команды. Если кто-то отправляет код в репозиторий без тестов, этот человек не следует правилу, и нужно лучше задуматься над обучением членов команды.
- Оценки. Сюда входят ключевые показатели эффективности (KPI), цели и бюджет. Например, ключевые показатели эффективности моей команды включают измерение времени цикла истории в спринте, время выпуска истории, процент дефектов, уровень тестового покрытия и проблемы с продуктом.
- Интерактивность. Интерактивный процесс — это когда вы пересматриваете продукт на основе вашего последнего цикла. Затем вы начинаете следующую итерацию для следующего набора основных ценностей.
Минимизируйте потери
Восемь видов потерь — дефекты, перепроизводство, ожидание, неиспользованные кадры, переназначение, ненужный инвентарь, лишние движения и избыточная обработка — в жизненном цикле разработки наносят ущерб продуктивности команды.
- Дефекты. Дешевле исправить дефект на раннем этапе жизненного цикла разработки, поэтому многие команды используют разработку через тестирование (TDD), чтобы уменьшить количество дефектов.
- Перепроизводство. Если вы делаете больше, чем вас просят, вы производите перепроизводство. В рассказах это связано с масштабом; объем должен быть небольшим, чтобы не было риска перепроизводства.
- Ожидание. Ожидание неэффективно и расходует ресурсы вашей команды. Во время ежедневных спринтов выявляйте истории, которые заблокированы или ожидают внешних зависимостей. Ваша задача как мастера схватки — помочь решить эти проблемы с блокировкой, чтобы сократить время ожидания.
- Неиспользованные кадры. Неиспользованные таланты всегда бесполезны, поэтому убедитесь, что у всех в команде достаточно работы.
- Переназначения. Если вы перемещаете проекты из одной команды в другую, вы вводите больше кривых обучения и времени для наращивания. Постарайтесь уменьшить количество переносимых проектов.
- Ненужный инвентарь. Слишком много инвентаря, который нельзя продать, — это пустая трата. Инвентарь занимает место в вашем офисе и впустую тратит ваше время.
- Лишние движения. Чрезмерные ненужные движения, такие как посещение встреч в разных местах или даже поездка на работу, являются пустой тратой. Многие организации проводят политику работы на дому для сокращения потерь движения.
Избыточная обработка. Если вы повторно выполняете один и тот же проверочный тест на одном и том же продукте, эта избыточная обработка может быть пустой тратой сил. Продумайте последовательность процессов в своём цикле разработки так, чтобы избежать избыточной обработки.
Как генеральный директор вашего проекта с открытым исходным кодом, ваше время очень ценно. Если это ваша работа, у вас есть только восемь часов в день. Если это ваш побочный проект, ваше время еще более ограничено. Бережливое управление временем включает очень простую матрицу, как показано ниже. Если у вас есть задача, которая важна для достижения целей и должна быть выполнена вами, продолжайте и делайте это. Если задача важна для достижения целей, но может быть выполнена членом команды, делегируйте ее. Если задача не важна для достижения целей и должна выполняться вами, минимизируйте время, которое вы тратите на нее. Наконец, если задача не является важной и может быть выполнена другими, то это пустая трата ресурсов.
Разработайте бережливую стратегию
Бережливая стратегия — это хороший способ проанализировать ваш продукт с открытым исходным кодом, чтобы выработать долгосрочную стратегию. Задайте себе следующие вопросы: если бы вашего продукта с открытым исходным кодом не существовало, понесли бы ваши клиенты какие-либо реальные убытки? Если да, то какой это будет ущерб? Вашим клиентам сложно заменить вашу продукцию в соответствии со своими потребностями? Например, если я создаю плейбуки Ansible для автоматизации кластера, могут ли мои клиенты заменить мои плейбуки Ansible с помощью набора скриптов оболочки? Как это повлияет на эксплуатационные расходы и кривую обучения?
Иерархия стратегии бережливого производства — это (снизу вверх) миссия, ценности, видение, стратегия и сбалансированная система показателей. В основе лежит ваша миссия: почему существуют ваш проект с открытым исходным кодом и ваша команда? Какова ваша миссия? Далее следуют ценности, в которые верит ваша команда. Видение — это то, как вы ожидаете, что ваш продукт будет развиваться в следующие два года. Стратегия требует соответствующего планирования. В самом верху находится сбалансированная система показателей, в которой вы реализуете и отслеживаете план для своего проекта с открытым исходным кодом.
Ваша стратегии бережливого стартапа включает вашу цель, область действия и конкурентное преимущество. Цель определяет, что ваша стратегия направлена на выполнение в определенные временные рамки. Область действия определяет требования стратегии для успеха вашего продукта с открытым исходным кодом. Ваше конкурентное преимущество — основа вашей стратегии. Как вы будете конкурировать с конкурентами, используя этот продукт и вашу стратегию для достижения своей цели?
Ценообразование и дифференциация — два важных фактора для достижения прибыли. Вы хотите предложить низкую цену и высокую дифференциацию. Спросите себя: чем ваш продукт отличается от продуктов конкурентов? Какие особенности уникальны для вашего продукта? Если вы сможете максимизировать дифференциацию и свести к минимуму ценообразование, вы выйдете на границу прибыли.
Смотрите в будущее
После того, как вы в течение некоторого времени ведёте свой проект с открытым исходным кодом и отслеживаете всё, самое время подумать, на чём вы хотите сосредоточиться в своей работе в качестве генерального директора вашего проекта с открытым исходным кодом.
Начните с оценки перспектив, возможностей и потенциальной прибыли.
- Перспектива включает в себя то, как ваш продукт удовлетворяет потребности клиентов. Например, может ли мой плейбук Ansible сократить количество ручных операций в кластере OpenShift, чтобы сэкономить 20% эксплуатационных расходов клиента?
- Возможности — это то, на что способен ваш продукт и какие новые функции он может предложить. Например, могут ли мои плейбуки Ansible работать с поддержкой кластеров OpenShift 3 и OpenShift 4? На локальных кластерах или кластерах AWS?
- Потенциальная прибыль включает в себя то, какой доход ваш продукт приносит вам за определенный период времени. Попадает ли ваш продукт в границу прибыли, показанную на изображении выше?
Открытый исходный код — это будущее. В сообществе открытого исходного кода много чего происходит, и многие компании переходят на модели с открытым исходным кодом. Открытый исходный код — отличный способ привлечь людей в ваш проект, а принципы бережливого стартапа помогут управлять проектом эффективно. Это придаст сил вам и вашему проекту в долгосрочной перспективе.