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

В докладе я расскажу про основные метрики оценки эффективности бизнеса, которые мы использовали на разных этапах развития нашей компании. Объясню, почему наша отчетность в 1 год жизни компании умещалась на 10 строчках, а теперь занимает 10 листов Excel. Расскажу, какие особенности подсчета метрик мы учитываем, так как продаем SaaS-решение. На что мы обращаем внимание при оценке основных показателей для разных моделей продаж - прямых и через партнеров.

1. Компания находится в точке невозврата. Разрыв между лидерами рынка и точкой Х – «одна промышленная революция». Продолжая дальше бизнес в устоявшихся традициях, мы идем под уклон.
Пока медленно. Но скорость возрастает с удешевлением и распространением цифровых практик в РФ.
Как преодолеть разрыв без революций и тотальных вложений? Какие препятствия возникают на пути форсированной эволюции?

2. Внутренняя причина №1
Правильный состав своих кадров и наличие у них навыков, необходимых для будущего процветания в цифровой компании. Сейчас команды из прошлого. С обозами.
Ключевые решения: партнерство с HR в стандартизации процессов, массированное развитие внутреннего тренерства, партнерство с PR в массированной продаже идей, бизнес развитие ИТ-команды и "внешние пророки", сегментирование по XYZ-признаку разные ценности.

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

4. Внутренняя причина №3
Отсутствие продуманных экономических моделей для вложения средств в технологии, определяющие Четвёртую промышленную революцию. Дефицит внутреннего согласования, недостаток эффективного взаимодействия с внешними партнёрами и ориентированность на краткосрочную перспективу.
Ключевые решения: последовательность акционера и лидера компании, точечная свежая управленческая кровь, "безопасно делим пирог власти", вовлечение новых финансовых партнеров.

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

Например, мы решили повысить конверсию сайта, с помощью которого мы привлекаем клиентов.

Для этого мы выбрали решение: новый сайт с новой структурой навигации для более эффективной конверсии. После инициации проекта у команды в голове цель подменилась с “нам нужно увеличить конверсию сайта” на “нам нужно сделать сайт согласно ТЗ с заданным качеством в заданные сроки”. Чем длиннее проект, тем больше шансов на такое развитие ситуации, если не задумываться об этом специально.

Чем это плохо? По идее, ну сделаем сайт качественно и достигнем исходной цели. Да, все так. С одним НО. В процессе реализации проекта возникает множество мелких вопросов и, если на эти вопросы отвечать в контексте другой цели, можно довольно сильно отклониться от оптимальной траектории. Например, в контексте достижения цели “нам нужно увеличить конверсию” можно прийти к выводу, что call to action на какой-то конкретной странице может быть разным (нужны эксперименты), и нужно заложить возможность относительно дешевых экспериментов, в контексте же достижения цели “нам нужно сделать сайт согласно ТЗ” такой вопрос даже не будет задан.

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

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

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

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

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

Чаще всего проблема в компасе. Куда вы идете? Какая у вас стратегия? Почему вас должны хотеть инвесторы и большие компании?

Поговорим о стратегии для компании и вашем месте в пищевой цепи.

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

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

Расскажем, как проектировать контент для продукта, почему нужно думать и писать микротекстами, чем это похоже на традиционные форматы и в чем принципиальные отличия.

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

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

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

1. Анализ данных и формулировка гипотез.
2. Визуализация дашборда.
3. Проверка гипотез.
4. Упаковка продукта.

Не зря есть выражение “стрелять из пушки по воробьям”. В IT это применимо как нельзя кстати: мы любим писать новые фреймворки на ровном месте, автоматизировать всё подряд и использовать супермощное железо. А что насчёт людей? Как мы выбираем, кто будет делать новую задачу, и делаем ли это правильно? Особенно это важно, когда задач, как обычно, больше, чем людей.

Я поделюсь нашим опытом и расскажу, как мы в Plesk:
- поменяли подход к разработке, чтобы релизиться чаще;
- выделили несколько команд с разным релиз-циклом;
- попробовали привлечь outsource и выпустили на 20% больше фич;
- оптимизировали использование практик в разработке и тестировании;
- в итоге свели всё это в систему, которая позволяет нам выбрать правильную команду и технологический процесс под каждую задачу.

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

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

25 мая 2017 года. Очередное падение системы, 4 часа она лежала, поднималась минут на 10 и снова падала. И это на "Последний звонок". Потеряли кучу клиентов. Проблемы со стабильностью, команда инфраструктуры была загружена на 200%, QA толком не было, разработка велась по компонентам, часто не соответствуя приоритетам бизнеса.

Как может IT-команда меняться сразу по всем фронтам и при этом не умереть? Мы меняли свои процессы везде практически одновременно.

При этом:
* Надо отдавать техдолг, накопившийся за годы и угрожающий стабильности. По расчетам в августе-сентябре падения стали бы просто ежедневными.
* Повысить качество, ибо не получалось выпустить и 3-х релизов подряд без серьезных сбоев.
* Продолжать разработку и выпускать новые большие фичи, мобильное приложение, запуск кастомизации в США и научиться грамотно управлять приоритетами.
* Растить команду количественно и качественно, иначе не видать нам международных рынков.

В начале 2018-го мы стабильны, у нас фичакоманды, проблемы при релизах стали нонсенсом, мы деплоим в любое время без остановки, идем в .NET Core в линукс-среду, IT-команда выросла в 2 раза.

Это рассказ о том, как мы умудрялись меняться одновременно по всем фронтам.

1. Как понять объем и привлекательность рынка?
2. Как определить, кто ваши конкуренты?
3. Из каких источников надо собирать информацию и как ее читать?
4. Кто ваша аудитория и чего она хочет?
5. Как сегментировать покупателей и бить точно в цель.
6. На десерт: 4 инструмента продвижения, которые может применить каждый, и они точно работают!

1. Как изменились системы продаж крупнейших вендоров: переход в клауд.
2. Эволюция IT-продукта из технологии в сервис.
3. B2B is dead. Основной принцип формирования ядер клиентских сегментов: business value и не только.
4. Упаковка IT-продукта: работающее ценностное предложение UVP.
5. Что на самом деле такое «успешная сделка» и какой KPI ставить продажам.
6. Customer Success — мировой тренд управления продажами в IT.

1. GDPR - новый общеевропейский регламент о защите персональных данных: что за зверь, и как он влияет на весь бизнес в мире - от уведомлений об утечках данных до штрафов в 20 млн евро или 4% оборота компании.
2. Какие российские компании попадают под действия GDPR?
3. Что нужно и что можно сделать ИТ-бизнесу, чтобы закон не помешал реализовывать проекты и продажи в Европе?

По данным патентных брокеров США, средняя цена сделки по покупке одного софтверного патента на 2016 год составила $235,000. Количество софтверных патентов в России измеряется тысячами и каждый год растет, а все потому, что патенты становятся инструментом конкуренции за инвестиции, маркетинга и неотъемлемым условием для выживания на развитых рынках.

В докладе будет дан краткий ликбез по патентам, ориентированный на IT-отрасль, в частности: что такое софтверный патент с примерами, что он дает, как выглядит патентная заявка и как ее правильно читать, критерии патентоспособности и распространённые заблуждения, связанные с ними. Данная часть аккумулирует всю боль вопросов от senior-менеджмента компаний, которые «разбираются в теме».

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

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

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

Только практика работы. Опыт роста среднего чека на разработку сайтов в региональных студиях в 3-4 раза за шесть месяцев и выход на положительную маржу. Плюс пример использования чек-листов для старта работы колл-центра при продаже seo-услуг.

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

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

У нас было:
- куча отделов;
- хаос в задачах;
- непонятные сроки;
- во всем виноваты заказчики / разработчики / pu-teen.

Но мы знали, что рано или поздно это надо изменить.

Чтобы изменить, надо понять. Чтобы понять, надо померить... и мы померили!

Оказалось. Чтобы производство работало как надо, достаточно просто...

1. Борьба за ресурсы монолитного ИТ-отдела компании есть бутылочное горлышко в реализации задач.
2. Когда в каждом департаменте есть свой ИТ-отдел, появляются возможности быстрого подтверждения прибыльности того или иного проекта.
3. Львиная доля времени по созданию того или иного сервиса уходит на подготовку ТЗ. Своевременное взвешивание ответственности от последствий со стороны бизнес-заказчика в ряде случаев сводит надобность ТЗ к нулю.