Start-up

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

В ноябре прошлого года более 500 российских технологов присоединились к нашему первому GitHub Meetup на русском языке и сейчас наше коммюнити насчитывает уже больше 1000 человек. Недавно мы открыли Telegram канал. Для нас это большая честь - привлекать такое внимание, и мы всегда будем рады слушать, учить и вдохновлять русскоязычное сообщество на вашем родном языке.

Вот краткое изложение того, о чем мы рассказали на данный момент:

GitHub:

• От Юрия Неваленного, разработчика npm: новые функции в GitHub Actions и способы их эффективного использования для реализации CI/CD.

• Алексей Мигуцкий (GitHub: разработчик issues/projects): как мы разрабатываем GitHub с помощью GitHub

• Наталия Дорфман (npm Engineering manager) Обзор платформы GitHub

Открытый исходный код правит миром:

• Олег Докука, разработчик открытого программного обеспечения для @rsocket @reactorr, поделился своей историей участия в open source проектах.

• Дмитрий Сошников, ведущий эксперт в области искусственного интеллекта и машинного обучения, developer advocate в Microsoft. Он показал коллективный портрет посетителя митапа: короткую интерактивную презентацию с Python, Codespaces и когнитивными сервисами.

• Антон Колесник (Microsoft Azure SDK) поделился опытом работы в качестве разработчика OSS в крупной компании.

• Олег Пименов (Positive Technologies) рассказал об управлении проектами с открытым кодом на GitHub

• Алексей Миловидов (Яндекс): Как организовать живое сообщество вокруг продукта с открытым исходным кодом

• Алекс Пулвер (архитектор AWS Solutions) рассказал про OSS-фреймворк AWS Cloud Development Kit (AWS CDK) - современный способ построения вашей инфраструктуры AWS.

Безопасность - наша ответственность:

• Анна Федоришина, директор инженерного отдела Perkon, научила нас, как сделать исправление безопасности CVE в продукте с открытым исходным кодом, не подвергая опасности весь проект.

• Алена Глобина (Продакт Менеджер в GitHub:Code scanning CodeQL) рассказала про анализ безопасности кода с помощью CodeQL.

• Артём Савельев (разработчик в GitHub: Secret Scanning) рассказал о превентивной безопасности в цикле разработки.

Программа GitHub Stars и ваша собственная Русская Звезда

• GitHub Star Никита Соболев (DryLabs) поделился подробностями о программе GitHub Stars.

Начало работы с InnerSource

• Дмитрий Сугробов (разработчик и евангелист в Leroy Merlin, член InnerSource Commons Foundation) дал нам Введение в InnerSource.

Бонус-трек: развитие soft skills

• Алена Беркач (тренер уровня ACC ICF) поделилась своим тренерским взглядом на синдром самозванца.

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

Если вы хотите выступить в качестве приглашенного докладчика, отправьте нам предложение на http://github.co/cfp - не важно если это ваше первое или уже тысячное выступление. Мы приглашаем Вас присоединиться к нам и воспользоваться имеющимися возможностями.

Мы надеемся, что вы присоединитесь к нам 15 июня 2021 года в 19:00 по Москве для дальнейшего общения и новых сессий.

Далее: наши эксперты на июньском мероприятии:

• Грачев Михаил: Взращивание культуры Open Source в компании

• Антон Таяновский: Инфраструктурные шаблоны Pulumi на примере AWS Lambda и Sagemaker

RSVP:http://github.co/habr

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

Итоги стартапа

С точки зрения производственных показателей, какие-либо предпосылки заморозки стартапа в принципе отсутствовали:

• Продуктовые команды стабильно выпускали протестированные и работоспособные версии своих продуктов. В общей сложности суммарно за год было выпущено 70 версий;

• Продуктовые команды успешно выпустили 20 версий на продуктивную среду клиенту;

• Продуктовые команды успешно выпустили 240 новых фич клиенту;

• Продуктовые команды эффективно использовали SCRUM в контексте ценностей, ролей, артефактов и ритуалов;

• Продуктовые команды вышли на свое стабильное значение velocity равное 35 стори поинтов для двухнедельного спринта;

• Текучка кадров составила 5%, и то это были два разработчика, которых перехантили обратно компании из которых они пришли;

• Обработали 600 обращений непосредственно от пользователей продуктов;

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

В разрезе добавочной стоимости запуск стартапа обеспечил следующее:

• вывод конкурентного решения на рынок умной поддержки;

• инновационность продуктового решения;

• создание производственной бизнес единицы;

• создание и развитие трех продуктовых команд с 0;

• увеличение капитализации материнской компании на стоимость созданного производства;

Предпосылки заморозки стартапа

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

Клиентская база

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

• расширение своей клиентской базы в разрезе рынков b2b, b2c;

• распределение функции управления клиентом в продуктовые команды;

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

Маркетинговые каналы

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

• участие в профильных семинар и конференциях;

• ведение продуктовых страничек на популярных IT ресурсах;

• создание и развитие бренда;

• создание вебсайта продуктов;

• SMM оптимизация;

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

Отсутствие фокуса на продуктовой цели

Первые 8 спринтов отсутствовал фокус на целях, которые должны быть достигнуты в рамках доставки продукта. В основном клиент фокусировался на UX/UI элементах и на мелочах, которые приходилось переделывать из раза в раз. Потом получилось сдвинуть фокус восприятия в сторону цели продукта, при достижении которой, бизнес клиента трансформируется, добавляя новые возможности для пользователей. Можно выделить следующие точки роста для компании с позиции формирования фокуса у клиента на продуктовых целях:

• создание культуры продуктовых целей;

• обучение и тренинг клиента;

До тех пор, пока не будет сформулирована цель продукта и осознана клиентом, инвестиции расходуются на осознание данной цели. Более того, каждый выпускаемый инкремент спринта не сможет приблизить нас к цели и заводит развитие продукта в определенный тупик

Контрактная модель

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

• переход на модель выпуска лицензий;

• переход на модель подписки (PaaS);

Все выше перечисленные предпосылки являются мнением автора и никак не отражают официальную позицию компании в части заморозки стартапа. Стоит отметить, что перечисленные выше предпосылки должны рассматриваться в качестве возможности для развития для компании в качестве IT-инкубатора.

Добавочная ценность продуктовой команды

Сама по себе, созданная и работающая на всех парах, продуктовая команда представляет большую добавочную ценность для материнской-компании:

• присутствуют все необходимые компетенции для выпуска инкремента продукта;

• есть понимание своих слабых и сильных стороны, а также их влияния на достижение цели;

• наличие микроклимата бизнес внутри бизнеса;

• ясная и понятная зона ответственности в разрезе продуктового портфолио;

• простота в планировании выпуска инкремента продукта;

• непрерывное развитие коллективного разума, который находит отображение в продукте;

Для трансформации группы людей в настоящую команду, необходимо время, которое в свою очередь выражается в затратах. Данные затраты являются частью инвестиций для запуска разработки продукта и вывода его в качестве MVP на рынок. Затрачиваемое время на выпуск MVP можно принять в первом приближении за критерий окончательного формирования команды. Соответственно, рассмотрим следующие гипотезы в части распределение затрат на запуск стартапа:

1. 70% на формирование команды, 30% на создание продукта при условии, что члены команды не знают, как работать по SCRUM и до этого не работали друг с другом; При данной гипотезе, материнская компания несет повышенные затраты на запуск стартапа, так необходимо запускать с 0 все необходимые механизмы. Данная гипотеза наиболее распространена для компаний с матричной структурой функциональных подразделений.

2. 40% на формирование команды, 60% на создание продукта при условии, что члены команды знают, как работать по SCRUM, но до этого не работали друг с другом; Здесь достигается определенный паритет затрат между формирование команды и разработки непосредственно продуктов. Данная гипотеза может более апробирована в компаниях, где развита производственная культура гибкой разработки ПО;

3. 20% на формирование команды, 80% на создание продукта при условии, что члены команды знают, как работать по SCRUM, и большая часть участников работали друг с другом в команде. Данная модель свойственна компаниям с ярко выраженным продуктовым подходом, где ротация происходим целыми командами.

Соответственно, возвращаясь к теме статьи о специфике процесса заморозки стартапа, заморозка должна происходить безболезненно как для сотрудника, так и для бизнеса. Фрустрация сотрудника должны быть сведена к минимуму, и компания должна помогать адаптироваться к новой реальности за рамками стартапа. Бизнес в свою очередь, потенциально может сократить затраты на запуск нового стартапа на 50 60% от стоимости MVP за счет сформированной продуктовой команды.

Инспекция и адаптация

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

После заморозки стартапа (более подробно можно ознакомиться в статье) компания заинтересовалась возможностью трансформации существующего производства включающего 400 сотрудников, работающих в 6 продуктовых направлениях. Данной публикацией, я запускаю цикл статей, в которых попытаюсь предложить формализованный подход для оценки степени зрелости аспектов разработки для внедрения SCRUM.

Для решения данной сложной задачи, была предложена программа, которая включает в себя 4 этапа:

1. Оценка готовности производственных подразделений к трансформации

2. Разработка этапов трансформации

3. Разработка механизмов трансформации

4. Разработка ценностной модели обоснования трансформации

Для реализации первого этапа, я разработал программу оценки готовности, которая состоит из следующих частей:

1. Понимание и применение фреймворка SCRUM

2. Разработка и поставка продукта

3. Гибкое управление продуктовыми направлениями

4. Развитие продуктовых команд

В данной статье будет идти речь об атрибутах и их характеристиках в разрезе понимания и применения фреймворка SCRUM. Остальные части будут раскрыты в следующих публикациях.

Философия эмпиризма

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

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

Культурные ценности

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

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

Команда как функциональная единица

Рабочим механизмом доставки ценностей инкремента продукта является команда, организованная по предметному признаку (продукт). С позиции управления, наличие самодостаточной организационной единицы, которая в состоянии выполнить весь спектр работ для поставки инкремента в продуктивную среду клиента, предоставляет гибкость в планировании и решении стратегических задач для руководства. В целях упрощения управления командой на уровне организации, ролей состав сводится к минимальному составу: скрам мастер - управление организацией, владелец продукта - управление контентом, разработчик - исполнитель.

[ 0 - 13] - низкий результат, характеризующий отсутствие команды в качестве производственной единицы признанной на уровне организации. Необходимо разработать комплексную программу мероприятий для выделения и формирования команды в контексте организационных уровней компании. Не допускается проводить мероприятия для отдельно взятых характеристик за рамками комплексной программы.

[14 - 20] - средний результат, характеризующий наличие команды как класса, но существуют определенные ограничения для полного раскрытия потенциала. Необходимо определить проблемные характеристики для улучшения и разработать мероприятия. Допускается применение мероприятий без общей программы.

[17 - 20] - высокий результат, характеризующий наличие самодостаточной организационной единицы производства инкремента продукта, признанной на уровне организации. При данном результате, рекомендуется сделать акцент на мероприятиях направленные на управление продуктом, непрерывное обеспечение качества и CI/CD, как вектор роста команды

События

События представляют из себя правила коммуникаций в разрезе следующих вопросов:

• кто должен коммуницировать?

• когда должен коммуницировать?

• с какой целью должен коммуницировать?

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

[ 0 - 17] - низкий результат, характеризующий события в качестве реактивных явлений, триггером появления которых служит возникшая проблема или задача. Данному результату свойственно большое время простоя производства в связи с отсутствием эффективных механизмов коммуникаций. При данном результате необходимо разработать комплексную программу внедрения и развития событий в командах.

[18 - 20] - средний результат, характеризующий наличие событий с ограничением их эффективного использования. Ограничения выражены безосновательной продолжительностью, а также хаотичностью возникновения. При данном результате необходимо разработать мероприятия для проблемных характеристик с точки зрения сокращения времени и внедрения ритмичности. Допускается проведение мероприятий отдельно от общей программы в случае, если существующие события семантически соответствуют описанным выше. В том случае, если существуют дополнительные события, необходимо проанализировать эти события на предмет ценности и целесообразности.

[21 - 25] - высокий результат, характеризующий наличие эффективно выстроенных коммуникаций и ритмичные процессы производства продукта. При данном результате, рекомендуется сделать акцент на характеристике критерии завершенности в качестве точки роста компетенций команды и качества выпускаемого инкремента.

Артефакты

В традиционном водопадном подходе существует большое количество артефактов, целью которых является синхронизация функциональных групп. В гибкой разработке выделяют только три артефакта, которые являются единственными для организации работы команд:

1. Бэклог продукта - упорядоченный и постоянно обновляемый список всего, что планируется сделать для создания и улучшения продукта. Этот артефакт является единственным источником работы для команды.

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

3. Инкремент - протестированная и работоспособная версия с добавочной ценностью для клиента, которая соответствует критериям завершенности.

[ 0 - 9 ] - низкий результат, характеризующий сложность существующих подходов в части управления и планирования содержанием работ. Данная сложность может быть причиной увеличения времени ожидания ответа на запрос внутри команды, а также причиной низкой концентрацией на актуальных задачах.

[10 - 12] - средний результат, характеризующий наличие артефактов, однако существуют ограничения для их эффективного использования. Ограничения могут быть обусловлены разбросанностью элементов бэклога , а также наличие дополнительных артефактов. Рекомендуется разработать мероприятия, направленные на выделение артефактов как отдельной практики, задуманной по определению.

[13 - 15] - высокий результат, характеризующий наличие и использования минимального набора артефактов для организации работ продуктовой команды. При данном результате рекомендуется сделать акцент на улучшение подходов по управлению содержанием продукта.

Критерии завершенности

Список критериев завершенности (далее DoD, от английского definition of done) является формальным чек-листом для принятия решения о выпуске инкремента. Критерии определяются стандартами организации или в случае если они отсутствуют, то команда сама должна определить список DoD. По мере развития команды, список критериев завершенности будет развиваться параллельно улучшению качества выпускаемого инкремента.

[ 0 - 31] - низкий результат, характеризующий отсутствие системы критериев завершенности, как механизма принятия решения о выпуске инкремента продукта. Для данного кейса свойственен иррациональный критерий - наступление даты релиза. Рекомендуется разработать комплексную программу внедрения критериев завершенности в минимальном составе. По мере того, как критерии будут приобретать рутинный характер, можно рассмотреть внедрение новых для улучшения качества выпускаемого инкремента.

[32 - 37] - средний результат, характеризующий ограниченное использование системы критериев завершенности. Ограничение может быть обусловлено отсутствием полноты критериев, а так же их игнорированием при принятии решении о выпуске инкремента. Рекомендуется предусмотреть отдельные мероприятия для улучшения критериев с низкой оценкой.

[38 - 45] - высокий результат, характеризующий устоявшуюся и применяемую систему критериев завершенности , которая гарантирует выпуск работоспособного инкремента за спринт. При данном результате, команда по умолчанию выполняет действия, направленные на удовлетворение критериям завершенности и это становится рутинной операцией. Рекомендуется зафиксировать подход как эталонный и разработать стандарт на уровне организации.

Масштабирование

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

• Кадровое обеспечение - данный механизм определяет два способа наращивания штата новых сотрудников. Первый способ - запрос функциональных подразделений, второй способ - запрос продуктовой команды.

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

• Новые клиенты - механизм при котором происходит внедрение существующих продуктов для нового клиента. Первый способ - для каждого клиента отдельная ветка и свой вектор развития продукта; второй способ - выделяется общее ядро и собственная ветка разработки для каждого клиента в рамках слоя кастомизации; третий способ - единственная ветка разработки с общими архитектурными механизмами.

• Архитектура - механизм, который регулирует способ управления и развития архитектуры. Первый способ - монолитная архитектура, второй способ - микросервисный монолит, третий способ - микросервисная архитектура, четвертый способ - оркестратор бизнес процессов.

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

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

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

Остальные части программы оценки готовности к трансформации:
SCRUM: Понимание и применение фреймворка
SCRUM: Разработка и поставка продукта
SCRUM: Гибкое управление продуктовыми направлениями

Фасилитация встреч и мероприятий

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

[ 0 - 19] - низкий результат, характеризующий слабо развитую культуру фасилитации событий в компании. При данном результате выделяется директивный способ организации, целью которого является трансляция задач от сотрудников с руководящими функциями без процессинга и обсуждения с исполнителями. Рекомендуется разработать программу в разрезе культивации философии фасилитации на уровне среднего менеджмента компании.

[20 - 25] - высокий результат, характеризующий устоявшуюся культуру фасилитации событий внутри компании, целью которой является создание удобных механизмов для владельцев содержания. Данный способ организации событий предоставляет модель встреча-развлечение, на которой у участников формируются доверительные отношения, целеполагание и вовлеченность в ожидаемый результат. При данном результате рекомендуется сделать акцент на развитие личностных характеристик сотрудника с функциями фасилитатора.

Методы развития продуктовых команд

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

1. Коучинг - метод тренировки, в процессе которой, устанавливаются цели для достижения. В свою очередь, коуч-тренер помогает команде достигнуть данные цели, используя знания предметной области, навыки межличностного общения и фасилитации.

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

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

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

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

[ 0 - 10] - низкий результат, характеризующий отсутствие у компании осмысленного подхода к развитию и адаптации кадров. В случае динамической среды стартапа, может наблюдаться эмоциональное выгорание сотрудников на горизонте испытательного срока; в случае умеренной корпоративной среды, наблюдается проявление низкой культуры развития сотрудников, как осознанный выбор компании для снижения затрат рынка низкотехнологичной продукции. При данном результате, целесообразность разработки программы обусловлена видением инвесторов в части долгосрочности нахождения компании на рынке, а также высокотехнологичностью продукции.

[11 - 20] - средний результат, характеризующий ограниченный набор методов развития продуктовых команд или не системность их использования. В случае динамической среды стартапа, может наблюдаться эмоциональное выгорание сотрудников на горизонте одного года; в случае умеренной корпоративной среды, может проявляться фрустрация и стагнация в развитии профессиональных навыков и знаний у сотрудников. В первую очередь, рекомендуется сделать акцент на развитие менторства и системы тренингов для сотрудников.

[21 - 25] - высокий результат, характеризующий зрелую систему развития и поддержки продуктовых команд. В арсенале компании имеются все доступные методы для формирования у сотрудников необходимого проактивного паттерна отношения к труду, новых навыков и знаний. При данном результате, компания осознаёт необходимость инвестицией в человеческий ресурс, так как он является потенциалом роста продуктовых направлений. Рекомендуется рассмотреть создание образовательного комплекса (аналоги GeekBrains, SkillFactory и т.д.) в периметре компании в целях становления и развития кадрового резерва.

Стили управления

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

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

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

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

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

В рамках бесплатного спринта по созданию презентаций для стартапов я перевела полезные советы от Y Combinator.

Y Combinator лучший в мире акселератор для стартапов по количеству единорогов (25), по объему привлеченных инвестиций ($27 млрд) и по капитализации выпускников ($300+ млрд). 125 компаний с оценкой $150M+

Как создать лучший Pitch Deck

Ниже приведена адаптация презентации, которую я даю стартапам YC, прежде чем мы попросим их создать свои презентации для Демо-дня.

Вот как сделать надежную презентацию для Демо-дня. Следует помнить, что у вас уже есть все необходимое для создания отличной презентации.

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

Как вы уже поняли после Prototype Day, вам повезет, если они смогут вспомнить хотя бы 1 или 2 из этих пунктов в контексте 100 других компаний, презентующихся вместе с вами.

Если вы просто четко изложите свои идеи, то добьетесь большего успеха, чем 99% стартапов. Потому что прежде чем кто-то сможет вспомнит, он должен это понять. Вот как я делаю вещи легкими для понимания:

• Я делаю это разборчивым.

• Я делаю это простым.

• Я делаю это понятным (очевидным).

Вот как заставить людей не понимать:

• Сделать это неразборчивым

• Сделать это сложным для понимания

• Сделать это неочевидным

Я собираюсь вдалбливать это снова и снова: ваши слайды НЕ должны быть неразборчивыми, сложными или неочевидными. Слайды должны быть разборчивыми, простыми и понятными.

Я хочу вас предупредить, прежде чем двигаться дальше в своей презентации. В этой презентации слишком много чертовых слайдов. Если бы это была настоящая презентация для Демо-дня, я бы сделал гораздо меньше слайдов. Это визуальное эссе, это очень разные вещи. Пожалуйста, не делайте визуальное эссе.

Разборчивость

Хорошо, давайте поговорим о разборчивых слайдах. Если люди не смогут его прочесть ваш слайд, они не смогут его понять. На Демо-дей в зале будет более 500 людей. Они не смогут все сидеть в первом ряду. Многие из них люди в возрасте, так что зрение у них, возможно, не самое лучшее.

Разборчивые слайды могут читать даже старики, сидящие в заднем ряду с плохим зрением. Вот как вы можете это сделать:

• Настройте большой размер шрифта.

• Используйте жирный текст.

• Выберите простой шрифт.

• Сделайте хороший контраст текста и фона.

Кроме того, текст наверху легче читать из задней части комнаты. Давайте рассмотрим несколько примеров.

Это не совсем ужасно. Проблема заключается в контрасте и позиционировании текста. Давайте попробуем еще раз.

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

Следующий слайд взят из Shred Video. Это из их презентации в Prototype Day (спасибо, ребята, что дали мне разрешение использовать это), и это то, что должно объяснить, что делает их стартап.

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

Простота

Давайте поговорим о простых слайдах. Простые идеи легко понять.

Но что именно это означает? Что ж, простое и сложное имеют одно и то же происхождение.

Слово "plex" означает плетение, скручивание или складывание.

Простые идеи это те, которые не переплетаются с другими идеями. Они одна нить. Они одна идея. Таким образом, простой слайд выражает одну идею. Не загромождайте слайды множеством идей. Вот как вы все усложняете. Некоторые идеи могут занять более одного слайда, чтобы вы смогли выразить свою точку зрения. Но вы должны очень постараться сделать это за один слайд.

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

Давайте рассмотрим еще один пример из нашего стартапа. Вот очень ранняя версия слайда из Afrostream, объясняющая, что они делают.

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

Сравните это со слайдом, который они в конечном итоге используют в Демо-день, чтобы объяснить свой стартап:

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

Очевидность

Давайте поговорим об очевидных слайдах. Очевидные слайды это те, которые можно понять с первого взгляда. Вот простой тест, который вы можете использовать, чтобы проверить, является ли слайд очевидным: покажите его незнакомцу и попросите его рассказать вам, что это значит. Если он сразу не скажет вашу идею, вы не смогли сделать идею очевидной.

Это происходит потому, что идеи, которые очевидны, очень быстро воспринимаются. Почему мы заботимся о скорости понимания? Что ж, для презентации Демо-дня следующие две вещи делают ее очень сложной для вас.

1. У вас есть только 2 минуты и 30 секунд.

2. Люди легко отвлекаются.

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

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

Вот как я делаю вещи очевидными: я начинаю с того, что делаю их разборчивыми и простыми. (См. два пункта выше.) Затем я стараюсь сделать свою идею ясной. Вот вам пример:

Уточнение: этот слайд не является явным. Вы, вероятно, можете догадаться и понять, что он представляет собой какой-то график роста, но это не сразу ясно.

Это лучше, но идея, которую я хочу выразить, может быть более очевидна:

Бум. Это как если бы я положил Клиффсноты прямо на слайд. Не нужно гадать, как дела у моего стартапа,я показал это наглядно. Вот еще один вариант одного из наших стартапов.

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

Еще один способ, которым я делаю свои слайды очевидными, - это избегать отвлекающих факторов в своих слайдах. Теперь, когда я говорю отвлечения, я имею в виду информационные отвлечения. Вот один из способов показать, как работает Dropbox:

Неплохо, но не очевидно. Проблема в том, что люди не могут понять этот слайд сразу. Почему? Ну, на этом слайде много информации. Видите?

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

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

Вот некоторые отвлекающие факторы, которых вы должны избегать в своих слайдах.

• Слишком много текста.

• Излишние объяснения и предостережения.

• Чрезмерное брендирование на слайде.

• Фотографии без заголовков и подписей.

• Анимация.

• Переходы.

• Мемы.

• Тонкий юмор.

• Случайный юмор.

В принципе, не пытайтесь сделать слайды тем, что они запомнят.

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

Есть, однако, одно исключение из этого правила: когда ваша цель показать сложность или ошеломить аудиторию. Обычно это происходит, когда стартап хочет поговорить о том, насколько трудна проблема, которую он решает. Я приведу вам пример из презентации Magic.

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

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

Гребаные Скриншоты

Давайте поговорим о скриншотах. Обычно я ненавижу скриншоты в демонстрационных презентациях. Скриншоты почти всегда неразборчивы, сложны и неочевидны. Они нарушают все 3 правила! Текст в большинстве интерфейсов слишком мал (не разборчив). Большинство интерфейсов делают несколько вещей (не простых). Большинство скриншотов занимают больше времени, чем один взгляд, чтобы понять (не очевидно). Они самые худшие.

Вот поиск изображений Google для "скриншотов":

Можете ли вы сразу понять любую из этих картинок? Нет.

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

Этот слайд гораздо лучше объясняет простоту использования продукта SparkGift, чем любой рабочий процесс, который они могли бы показать из своего реального интерфейса.

Иногда компании может повезти, и они смогут объяснить, что они делают, в двух пунктах. Вот как это сделал Meadow:

Употребление наркотических веществ на основе марихуаны в РФ является административным правонарушением, караемым штрафом.

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

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

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

Сделайте ее разборчивой. Сделайте ее простой. Сделайте ее очевидной.

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

Две недели подряд мы проводим мероприятие под названием Prototype Day, чтобы все стартапы впервые представили друг другу свои идеи. Что они быстро понимают, так это то, насколько плохо они описывают свои стартапы, что их даже запоминают коллеги в батче.

Если вы хотите помочь с переводами полезных материалов библиотеки YC - пишите в личку, телегу @jethacker или почту alexey.stacenko@gmail.com

Следите за новостями YC Startup Library на русском в телеграм-канале или в фейсбуке.

Полезные материалы

• Minimum Viable Pitch-deck - канал, где много полезностей по созданию презентаций для стартапов

• Подборка 143 переводов эссе Пола Грэма (из 184)

• 75 лекций на русском от Y Combinator (из 172)

• Y Combinator: русскоговорящие основатели

• Какие стартапы ищет Y Combinator в 2020 году

• Чат Y Combinator in Russian

• Паблик в фейсбуке YCombinator in Russian