Заявки на доклады

Конференция Whalerider проходит в рамках профессионального фестиваля "Российские интернет-технологии". Вам, как участнику конференции, доступны все доклады этой конференции.

Кроме этого, Вы cможете посетить все общие доклады фестиваля, интересные широкой публике, и специализированные доклады конференций блока управления и предпринимательства: конференция "Aletheia Business 2018".

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

Поиск по тегам:

Бизнес и финансы

Бизнес-метрики для оценки эффективности SaaS-компании

Анастасия Новикова

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

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

Доклад принят в программу конференции

Кризис

Внутренние препятствия цифровой трансформации компании из ЖКХ 2.0

Сергей Путин

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

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

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

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

Доклад принят в программу конференции

Проектный офис

Подчинение хаоса или битва с ветряными мельницами

Алексей Васильев

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

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

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Выбор стратегии долгосрочного развития, KPI
,
Продуктовая разработка
,
Управление / другое
Доклад принят в программу конференции

Как мы учились мыслить ценностью, а не скоупом, и что из этого вышло

Петр Марков

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

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

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

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

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

Доклад принят в программу конференции

Стратегия

Куда вести агентство: цели, планы и мечты

Александр Богданов

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

Доклад принят в программу конференции

Почему вас все должны хотеть

Сергей Рыжиков

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

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

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

Выбор стратегии долгосрочного развития, KPI
Доклад принят в программу конференции

Продукт

Как микротексты становятся стандартом коммуникации в цифровом мире

Евгений Романовский

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

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

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

Доклад принят в программу конференции

Клиенты и продажи

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

Алексей Колоколов

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

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

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

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


Доклад принят в программу конференции

Процессы

Как мы выбираем команду и технологический процесс для новой фичи

Владимир Лихтанский

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

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

Code Review
,
Автоматизация разработки и тестирования
,
Работа со внешним заказчиком/исполнителем
,
Продуктовая разработка
,
Автоматизация тестирования
,
Приёмочные и функциональные тесты
Доклад принят в программу конференции

Гемба на 5 миллионов. Как работа "в поле" может улучшить ваши процессы.

Сергей Грязев

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

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

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

Как большая IT-команда может меняться сразу по всем фронтам и при этом не умереть

Александр Андронов

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

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

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

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

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

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Модели руководства
,
Антикризисный менеджмент
Доклад принят в программу конференции

Продажи

Как открыть стартап: секреты продвижения на примере онлайн-сервиса уборок Qlean

Роман Кумар Виас

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

Доклад принят в программу конференции

Глобальные тренды продажи и развития IT-продукта

Павел Рысков

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

Выбор стратегии долгосрочного развития, KPI
,
Продажи, конкуренция и аналитика
Доклад принят в программу конференции

Юриспруденция

Софтверные патенты: что, зачем и как можно запатентовать и каким образом это поможет вашей карьере или бизнесу

Дарья Яцкина

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

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

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

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

Выбор стратегии долгосрочного развития, KPI
,
Работа со внешним заказчиком/исполнителем
,
Интеллектуальная собственность на программное обеспечение;
Доклад принят в программу конференции

Как Европа обяжет с 25 мая 2018 года все компании в мире защищать данные европейцев. Как жить российскому ИТ-бизнесу с этим

Максим Лагутин

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

Работа с зарубежным заказчиком/рынком
,
Юридические вопросы
,
Взаимодействие с государством
Доклад принят в программу конференции

Разработка

Как начать DevOps-трансформацию

Андрей Александров

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

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

Менеджмент в эксплуатации
,
Devops / другое
Доклад принят в программу конференции

Метрики IT-производства

Виталий Каторгин

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

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

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

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

Доклад принят в программу конференции

Чек-лист для веб-студии

Михаил Смирнов

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

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

Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Продажи, конкуренция и аналитика
,
Продуктовая разработка
,
Бизнес на стыке онлайн и офлайн
,
Обслуживание клиентов, техническая поддержка, обратная связь
,
Управление / другое
Доклад принят в программу конференции

Мы делили апельсин. Реальная история реформы ИТ

Андрей Ревяшко

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

Доклад принят в программу конференции