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

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

Agile

Как выжать максимум изменений и не умереть

Михаил Вязанкин

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

Программный комитет ещё не принял решения по этому докладу

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

Как НЕ потерять при его масштабировании?

Сергей Дежнев

Ваш бизнес может приносить в 5 раз больше прибыли
Конверсия вашей воронки продаж более 100%? Реально!
Неизбежные дыры в маркетинговом бюджете или как в 4 раза сократить стоимость нового
клиента
Топ 10 пожирателей прибыли вашей компании и как от них избавиться
Три вопроса, которые не любят 90% коммерческих директоров, но обожают собственники
Как свести текучку в ноль и создать очередь из специалистов

Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Выбор стратегии долгосрочного развития, KPI
,
Продажи, конкуренция и аналитика
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Создание экосистемых решений в Промсвязьбанке на примере продукта "Бухгалтерия".

Константинов Никита

- Что Промсвязьбанк имеет ввиду под "экосистемными решениями"
- Почему на самом деле 1С, это хороший выбор
- Как сделать хороший продукт для МСБ в гос. банке.
- Какие ошибки допустил продуктоунер и как их правили.

Программный комитет ещё не принял решения по этому докладу

Финансовое планирование в ИТ. Что от вас хочет финансовый директор или инвестор.

Наталья Баранова

Можно ли обойтись без финансового планирования?
Какие бюджеты надо составлять и зачем. CAPEX и OPEX для IT, почему это важно.
Планирование текущих расходов - методы, убедительные для финансового директора и бизнес-заказчика.
Планирование инвестиций в ИТ - разработка ПО, железо, модернизация, автоматизация процессов и т.д. На каком горизонте времени считать.
Оценка эффективности инвестиций в ИТ - возможная или обязательная опция финансового планирования?

Программный комитет ещё не принял решения по этому докладу

Формирование ставок и тюнинг рентабельности для аутсорс-продакшена

Андрей Рыжкин

Рано или поздно у любого руководителя аутсорс-продакшена встает вопрос: сколько реально стоит час моего специалиста? И за сколько его можно продавать?
Есть разные подходы к формированию стоимости часа: сделать «среднюю по рынку», умножить ставку за час от заралаты на число ПИ, платить разработчику х% от ставки часа - «а там за сколько купят» и т.д.
Каждый из подходов имеет свои подводные камни, например:
— На сколько часов делить ЗП специалиста? 164ч? А отпуска? А болезни? А сколько эффективного времени заложить? А гарантийные и не оплачиваемые работы куда включить? А сколько рисков должно быть в ставке?
— Как учесть условно-постоянные расходы (УПР), если они постоянно разные?
— а как учесть менеджмент? А при аутстаффе?
— и еще очень много подобных вопросов!

В нашей компании более 370 специалистов трудятся в единый момент времени, у нас большой офис в центре Москвы и при этом мы умудряемся держать рентабельность производства >=20%.

Я верю, что понимание структуры расходов и доходов и правильная математика, которая лежит в основе всего этого позволяет нам получать стабильную прибыль даже при постоянном интенсивном росте (практически х2 на протяжении нескольких лет).

В своем докладе я постараюсь рассказать, как мы этого добились и раскрыть следующие тезисы:
— подходы к формированию стоимости часа: от затрат, от «среднерыночной», от ставки конечного специалиста
— как разделить УПР на специалистов; инхаус и аутсорс
— как правильно закладывать гарантийные работы, менеджмент, риски в ставку часа специалиста
— что такое «оверхед», как его считать и для чего
— что меняется при разных моделях работ (fix price, T&M, выкуп) и на что это влияет: менеджмент, кол-во часов для расчета, риски
— нюансы при разных моделях работ: контроль сметы, таймтрекинг и таймшиты, простой специалистов
— грейды по специалистам (зарплаты и ставки)
— контроль рентабельности с разной детализацией: компания, департаменты, отделы, команда, проект
— система мотивации для разных ролей: ТОП-менеджеры (руководители компании/отделов), менеджеры/тимлиды
— окупаемость и загрузка специалистов (это не одно и тоже! давайте разберемся почему)

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

Продажи, конкуренция и аналитика
,
Работа со внешним заказчиком/исполнителем
,
Управление / другое
,
Другое
Программный комитет ещё не принял решения по этому докладу

Тестирование и приёмка

Как мы тестируем фичу от ТЗ до пост-продакшна и сохраняем дружеские отношения внутри команды

Даша Кормушина

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

Я поделюсь процессом ведения фич, который помогает не только сэкономить время, но и прокачать личные скилы. Расскажу, как нам удалось удержать в едином контексте продактов, дизайнеров и разработку. Теперь мы верим, что ревью первой тестовой сборки всеми заинтересованными действительно облегчает людям жизнь. А коммуникация — ключевой момент в ведении фичи.

Автоматизация разработки и тестирования
,
Большие проекты/команды
,
Тестирование мобильного ПО
Программный комитет ещё не принял решения по этому докладу

Анализ

Анализ данных при принятии решений

Андрей Макаров

Принятие решений в условиях неопределенности – “едим слона” по частям правильно.

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

1. Теория. Как выбрать правильную “линейку” и принять решение.
1.1 Требования – продуктовый подход.
1.2 Как смотреть - процесс или объекты.
1.3 Оценка узлов с точки зрения ценности для бизнеса.
1.4 Принцип "дерева принятия решений".

2. Практика и кейсы.
2.1 Видение vs Требования. Заказчик “видит” продукт, но не знает требований. Их создаем мы.
2.2 Roadmap проекта без детального плана в условиях предыдущей ситуации.
2.3 Тестирование и результат. Анализ готовности функционала до проведения полного регресса.

3. Оценка эффективности такого подхода.
3.1 На регрессе мы не тратим время на поиск ошибок, если не проверен "самый ценный" кейс.
3.2 Проверяя постановку задачи объективными данными, мы снижаем риск изменения требований по ходу постановки.

4. Что важно и что дальше?
4.1 Мы прививаем командам продуктовый подход и разностороннее понимание процесса/продукта.
4.2 Мы разрабатываем прикладные утилиты для предварительного тестирования данных или ключевого процесса.

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

Когортный анализ в Google Analytics дешево и сердито

Ирина Назарова

Пошаговая инструкция, как начать тестировать гипотезы в разработке продукта, используя те инструменты, которые у вас уже есть: Google Analytics, Google Sheets и ни единой строчки кода. Мы взламываем GA, чтобы получить те функции, которые недоступны из интерфейса — возможность строить когорты и получать данные, которые позволяют отслеживать воронки внутри каждого инструмента и фичи, гибко подсчитывая интересующие нас действия.

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

Программный комитет ещё не принял решения по этому докладу

Разработка

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

Любовь Тарасова

План тестирования – инструмент обеспечения качества на всем протяжении процесса разработки.

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

Наши вводные: высоконагруженный проект в проде, 10 разработчиков. Релизы раз в две недели, постоянная корректировка планов со стороны бизнеса заказчика. Тестировщик – всё в одном: и тест-менеджер, и автоматизатор, и черт в ступе.

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

У нас план тестирования используется:
• при составлении сценариев тестирования,
• при тестировании на разных окружениях,
• при принятии решений о приоритете багов.
• при проведении приёмочного тестирования версии,
• при планировании загрузки, когда нет работ над версией,
• при передаче знаний,
• для планирования развития QA-инженера и улучшения процессов проекта.

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

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Выбор стратегии долгосрочного развития, KPI
,
Управление / другое
,
Приёмочные и функциональные тесты
,
Процессы и инструменты в enterprise
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

Создание школы по веб-разработке внутри компании

Андрей Морозов

- Создание программы обучения для веб-разработчиков;
- набор специалистов для обучения (где искать и как собеседовать);
- процесс обучения и менторство;
- аттестация специалистов;

PHP
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Чему мы научились в Pivotal, или Как сделать внутри банка от идеи до прода за 1 дн

Ян Ашенкампф

Мы съездили в Pivotal Platform Acceleration Lab, посмотрели, как там все устроено, и стали прививать это в маленьком анклаве внутри одного крупного (топ-10) российского банка. Расскажу, что из этого получилось, а также какие находки встретили по дороге.

Остановимся на темах:
- Stateful vs Steteless: хранение данных, в том числе чувствительных. Где же все-таки этот стейт лежит, и как это все сочетается с обновлением на лету?
- Тесты как краеугольный камень DevOps - модульное, функциональное, приемочное (спеки), нагрузочное, стресс-марафон, тестирование безопасности, ретроспективное. Коснемся BDD.
- Как организовать команду и процесс? В чем отличие от традиционных команд? Бывает ли в реальной жизни парное программирование (спойлер: да), как сделать обмен знаниями?
- Каких людей искать, как принимать. Как организовать "пробный день" и что это такое.
- Отличается ли инфраструктура для 1d-TTM (time-to-market)? Мы закончили частным облаком. Поговорим, почему и как именно.
- В чем отличие архитектуры приложений, которые целятся к 1d-TTM? Понятно, что сервисная архитектура, но как именно? К чему мы пришли? Как разделить, упаковать, как искать друг друга, обмениваться командами и данными, как мониторить все это дело.
- А поддерживать кому и как? Выделенные администраторы? Инструкции? Дежурная смена? 1, 2 линии?
- Интеграции со смежными системами как последняя по списку, но не по важности вещь. Аутентификация, протоколы обмена, сосуществование систем с разными циклами обновления. Сосуществование с более традиционными внешними партнерами?

Так как доклад затрагивает все эти темы, то на каждую из них остается только на самую суть. Поэтому и интересно.

Микросервисы, SOA
,
Отказоустойчивость
,
Методы и техника разработки ПО
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
,
Функциональное тестирование
,
Нагрузочное тестирование
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Юнит-тестирование
,
QA / другое
Программный комитет ещё не принял решения по этому докладу

Истории успеха

Как преодолеть технический долг и сделать рывок

Антон Штин

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

Я расскажу о технических и управленческих практиках, которые сработали и позволили реализовать видеоплатформу MOVIX в ЭР-Телеком.

Программный комитет ещё не принял решения по этому докладу

Рост продаж в 3 раза после смены дизайна и функционала магазина: это реально (история успеха)

Денис Фитеров

Вкратце о докладе:
1) У клиента был старый дизайн магазина. Мы создали новый интернет-магазин c красивым дизайном и нужным функционалом для покупателей, сохранив при этом все URL сайта. И после его внедрения без привлечения дополнительного поискового трафика увеличили продажи в 3 раза для интернет-магазина продуктов из Японии.
2) В течение 3 лет за счет продвижения и развития ЭТОГО же сайта увеличили общую видимость по запросам на 750% (с 1,01 млн. чел. до 7,55 млн. чел.) и посещаемость на 550% (с 79 798 чел. до 437 313 чел.) фото скринов прикрепляю.

Программный комитет ещё не принял решения по этому докладу

Инструменты

Аналитика в ритейле от Excel до OLAP-кубов

Елизавета Гринберг

Основные тезисы по докладу:
* как построена аналитика в интернет-ритейле?
* что такое OLAP-кубы и зачем они нужны?
* кейсы с использованием сквозной аналитики и OLAP-кубов.

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

MSSQL
,
Базы данных / другое
,
Архитектура данных, потоки данных, версионирование
,
Продажи, конкуренция и аналитика
,
Бизнес на стыке онлайн и офлайн
,
Проектирование информационных систем
,
Теории и техники анализа
,
Интеграция web и enterprise-решений
,
MySQL (MariaDB, Percona Server)
,
ETL
Программный комитет ещё не принял решения по этому докладу

Проектирование

Ролевые игры. Практика управления требованиями профессиональных продуктов

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

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

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

Программный комитет ещё не принял решения по этому докладу

Продажи

Как структурировать работу отдела продаж с помощью трех простых правил

Матвей Кардаш

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

2. По результатам исследований 80% российских компаний теряют клиентов, потому что менеджеры сами выбирают кому продавать, а кому нет.

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

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

Продажи, конкуренция и аналитика
,
Бизнес на стыке онлайн и офлайн
,
Реклама и ее эффективность
,
Обслуживание клиентов, техническая поддержка, обратная связь
,
Управление / другое
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

Что делать, если ты стереотипный айтишник, которому нужно продавать.

Кирилл Кириллов

1. «Кирилл, ты по-прежнему не умеешь продавать, но делаешь это уже лучше». Или как айтишник учился продавать, вызубрил всю теорию, а на практике все было по-другому.
2. Продавать или впаривать общение сделать сайт/приложение и т.д.
3. Презентация продакшена занимает 5 минут из 20, потому что пока нет портфолио. Как понравиться клиенту? И какой тип клиентов нужно безжалостно отсекать.
4. Как планомерно увеличивать ценник с первых месяцев работы агентства?
5. Как получить контракт с крупным брендом, если агентству меньше года.

Продажи, конкуренция и аналитика
Программный комитет ещё не принял решения по этому докладу

Как я перестала продавать сама и сэкономила 1,5 миллиона рублей

Екатерина Ким

— Немного о боли: «Продают топы»?
— Учебник по продукту: как сократить время обучения нового менеджера в 6 раз.
— Занимайтесь стратегией и развитием компании, пока отдел продаж выполняет план.

Поиск и развитие команды
,
Продажи, конкуренция и аналитика
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Стратегия

Вы точно знаете ваших конкурентов?

Евгений Рыжков

Уверен, что каждый из присутствующих легко ответит на вопрос: «Кто является основными конкурентами вашей компании?». Мы настолько привыкли отвечать на этот вопрос, что отвечаем не задумываясь. А я вот недавно задумался и был удивлен своими мыслями. Поделился ими с коллегой – он тоже сказал: «Ничего себе, действительно…». Так вот, хотя моя компания делает программный продукт для программистов, но мои конкуренты занимаются совсем другими вещами.

Понятно, что по кадрам мы конкурируем с другими программистскими компаниями, которые делают совсем другие вещи. Это понятно. Но мы также конкурируем по аренде офиса со строительной компанией с миллиардными оборотами (они занимают второй этаж, а мы третий). Мы конкурируем со Сбербанком, Яндексом и Леруа Мерлен. Так как и мы, и они хотим иметь стенды на конференциях.

Наконец мы конкурируем с другими докладчиками на конференциях за внимание аудитории. Эти мысли заставили меня продумать ответы на вопрос «А чем ваша компания лучше?». А также сформулировать и для себя, и для внешнего мира, почему работать с нами – хорошо.

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

Программный комитет ещё не принял решения по этому докладу

Каким должно быть конкурентоспособное SaaS-решение

Арсений Косенко

LIFE PAY - разработчик кассового ПО. Три года назад мы вышли на новый, но уже вполне конкурентный рынок и стали разрабатывать свой продукт. Год мы пытались создать решение, которое будет делать “все”. Пока не поняли, что все делаем плохо. Но мы не сдались, мы просто поменяли стратегию.
Теперь наше SaaS-решение делает “все” и “все остальное” тоже.
Я расскажу о том, в чем сила API и как превратить ПО в SaaS-конструктор.

1. Немного о нас и рынке, на котором мы работаем
2. Ключевая ошибка нашей прежней стратегии - на высококонкурентном рынке нельзя быстро и хорошо сделать продукт, который решал бы максимум задач пользователя.
3. Правильное решение – продукт должен закрывать базовые задачи и иметь удобный API для интеграции с другими сервисами.
4. Как развиваться дальше: изучение потребностей рынка, интеграции с ключевыми игроками рынка и востребованными сервисами.

Продуктовая разработка
,
Будущее рынка разработки ПО
Программный комитет ещё не принял решения по этому докладу

Человеческий капитал

Are You Sure You Are Not a Micromanager?

Егор Бугаенко

Do you know what micromanagement is? It's when your manager is telling you exactly what you have to do right now in order to achieve the results he or she wants. The micromanager doesn't trust you and that's why wants and needs to control every step you make. It's annoying and unproductive, but it's inevitable unless you have small tasks and a transparent and unambiguous system of rewards and punishment. The question is how you can define an obvious and transparent motivational system. A number of options will be suggested.

Модели руководства
Программный комитет ещё не принял решения по этому докладу

Как нанять идеального разработчика

Даниил Пилипенко

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

Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

Интервьюируем разработчика: как кого-то нанять и никого не убить

Даниил Подольский

Техническое интервью выглядит простым делом:

1. мы знаем нашу предметную область
2. мы знаем наши текущие задачи и краткосрочный прогноз по ним
3. мы знаем, что из этого мы хотим поручить новому человеку сейчас, и какую область мы хотим с его помощью закрыть в перспективе
4. мы четко представляем себе, какие для этого требуются знания и навыки
5. мы знаем, как проверить, обладает ли кандидат нужными знаниями и навыками
6. мы обладаем ресурсами и квалификацией для организации процесса проверки
7. мы владеем методикой обобщения результатов проверки и порождения практически полезных выводов
8. PROFIT

Такова теория. Практика, как обычно, существенно отличается.

В мире нет никого более беспомощного, безответственного и безнравственного, чем человек, проходящий собеседование на позицию senior software developer. Разве что человек, проводящий это собеседование.

И сейчас мы в это окунемся.

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

Проблемы нарастают через пункты
2 (прогноз на 4 недели - долгосрочный, правда?)
3 (пусик, готов ли бекложек?)
4 (а сами-то мы умеем хоть половину?)
5 (если вдруг оказался друг...)
6 (сегодня на тебе 3 срочных бага и два собеседования, %username%)
и достигают апогея в пункте 7 (промолчим).
Пункт 8, слава Богу, не наша забота. Oh, wai...

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

И готов поделиться, с упором на пункты 4, 5, 6 и 7. Ну и 8, хоть он и не наша забота.

Программный комитет ещё не принял решения по этому докладу

Как управлять персоналом

Дмитрий Мишунин

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

* Осознаете и скорректируете свой стиль лидерства.
* Переведете управленческие знания в управленческие навыки. Узнаете типичные управленческие ошибки.
* Научитесь делегировать и ставить конкретные задачи перед подчинёнными.
* Рассмотрите технологии внедрения и работы с обратной связью.
* Рассмотрите передовые методы мотивации сотрудников.
* Поймете сильные и слабые стороны вашей стратегии управления.

Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Процессы

Как спланировать полгода разработки 40 команд за 3 дня

Анжела Дружинина

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

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

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

Программный комитет ещё не принял решения по этому докладу

Управление производством на основе анализа данных в агентстве заказной разработки

Сергей Кожемякин

- HR. Подбор и работа с персоналом на основании анализа конверсии воронок и анализа данных опросов.
- Оценка эффективности сотрудников. Рентабельность производства во главе угла, иерархическая вложенность целей сотрудников от топов до исполнителей, замеры рентабельности на всех уровнях. Принятие кадровых решение на основании эффективности.
- Client service. Обзвоны клиентов, сбор CJM, маппинг с внутренними регламентами, внедрение улучшений.
- Продуктовые метрики. Учёт продуктовых метрик в качественных KPI сотрудников. Нацеленность на качество продукта и учёт данных Client service в KPI
- Работа с клиентами по схеме revenue share.

Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

Как подружить бизнес и IT - процесс и майндсет ориентированный на бизнес-результат

Михаил Меньшинский

- основные pain points в работе бизнеса с IT командой
- основные point points в работе IT команды с бизнесом
- как сделать так чтобы бизнес-стейкхолдеры услышали IT команду
- как сориентировать IT команду на достижение бизнес результатов
- обязательные ключевые элементы в процессе при наличии аутсорс/аутстаф команды
- как это все ложится на существующие методологии управления проектами

Инструментальная поддержка, декомпозиция задач
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Работа со внешним заказчиком/исполнителем
,
Продуктовая разработка
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Как настроить цикл работы с обратной связью и измерять эффективность продукта цифрами

Юрий Кривочуров

Как разрабатывать проект как продукт на основе обратной связи.

Как собрать, проанализировать обратную связь, не потерять главное и превратить это в требования и функциональность.

Для это рассмотрим 4 области:
1. Продукт – продажа авиабилетов и услуг авиакомпании через агентскую сеть.
2. Процесс – опишем процесс от выбора гипотез, проведем через все шаги разработки и закончим оценкой результатов внедрения гипотез.
3. Инструменты – сбор, агрегация и визуализация метрик с использованием Spring, Spring Boot, InfluxDB, ELK, RabbitMQ, OLAP-кубы, Grafana и Zabbix.
4. Мотивация – мотивация команды на основе теории постановки целей и теории ожидания.

Почему так делать правильно: субъективность vs объективность. Взгляд со стороны заказчика и со стороны меня как менеджера.

Логирование и мониторинг
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Продуктовая разработка
,
Обслуживание клиентов, техническая поддержка, обратная связь
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

Как мы пытались заменить менеджера простым скриптом на питоне, и что из этого получилось

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

Teamplify (https://teamplify.com/)
Доклад об автоматизации процессов в команде.

1. Собирает всю активность разработчиков в одном месте (Slack, Github, Gitlab, Jira, отчеты о выполненной работе за период, отпуски, праздники, больничные). Приносит больше спокойствия как менеджерам, так и разработчикам, так как в любой момент времени доступна полная информация о текущей деятельности как команды, так и разработчика.
2. Позволяет выявить характерные проблемы в работе команд.
3. Экономит время разработчика и менеджера и, как следствие, экономит деньги компании.
4. Избавляет менеджеров от заметной части рутины (умные нотификации): знает про государственные праздники в 180 странах мира, и автоматически напомнит про те, которые актуальны для вашей команды; предупреждает, если человек идет в отпуск; напоминает о приближении дедлайнов; напомнит о необходимости сделать апдейт в задаче; напомнит о необходимости написать отчет.

Программный комитет ещё не принял решения по этому докладу

Рост компании

Возможно ли доверить новичкам разработку в Digital и зачем это нужно?

Сергей Попов

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

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

Большие проекты/команды
,
Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

Команда

Инженерная культура. Что в нее нужно включить и как ее внедрять.

Дмитрий Круглов

Корпоративная культура — устоявшийся и понятный всем термин. Зачастую, из-за внедрения для «галочки», отношение к ней у сотрудников варьируется от безразличия до ненависти.
Инженерная культура — это про другое. Это про такие вопросы, как:
- что такое хороший код?
- какими должны быть комментарии к pull request-ам?
- почему антипаттерны это зло?

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

Корпоративная культура и мотивация
,
Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

Как работать с джуниорами?

Сергей Попов

* Что такое начинающий разработчик и что он скрывает?
* Какие тайны он приносит с собой после того, как заканчивает обучение?
* Что он придумывает на собеседовании и почему он так их боится?
* К чему нужно быть готовым при работе с джуниорами, какие задачи нужно ему давать и как погружать в работу?

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

Code Review
,
Большие проекты/команды
,
Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

В одну реку дважды… RUN!

Артем Каличкин

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

Была у меня большая команда, и там я уже много сделал:
1. обеспечил операционную доступность,
2. наладил устранение инцидентов и сбоев,
3. запустил работающий DevOps,
4. сформировал слаженную команду разработки.

И тут говорят "Псс… Парень, хочешь много легаси, олдскульные процессы и уставшую команду? Нет? А надо!".

И вот у меня совершенно другая команда и продукт, а я начинаю преодолевать полосу препятствий:
1. Нельзя сделать «как у меня там было». Старые приемы и паттерны управления не работают, текущие проблемы на других уровнях и в других плоскостях;
2. Нет драйва от новизны технологий и подходов – я уже знаю, что они работают! Нужны другие драйвы;
3. Сопротивление команды на каждую инновацию: «Мы это уже пробовали…». Да, но не со мной!
4. Да где же мои проверенные бойцы, в конце концов!?

И что делать? Увидеть новые возможности, открыться новому опыту!
1. Перестать цепляться за старое, прям вот ЗАБЫТЬ: Мир другой, ты другой, технологии другие. Старые привычки будут только мешать;
2. Перестать самому действовать, как прежде, решать, как решал раньше, делать то, что делал раньше – необходимо! Чтобы получить новый результат, нужно начать совершать новые действия;
3. Есть возможность узнать много нового со своей новой командой, чего не знала даже твоя прежняя команда;
4. Увидеть возможность личной трансформации.

Доклад для ветеранов всех войн и тех, кто на подходе.

Программный комитет ещё не принял решения по этому докладу

Как уместить все этапы интервью в один час без технического задания

Андрей Минкин

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

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

Программный комитет ещё не принял решения по этому докладу

Сокращения: как пережить самому и не растерять команду

Ксения Коновалова

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

Я расскажу, как:
- пережить сокращение самому
- сохранить команду
- позаботиться о сокращенных
- не потерять доверие сотрудников

Программный комитет ещё не принял решения по этому докладу

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

Учимся продавать сложные ИТ-продукты

Евгений Савицкий

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

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

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

В докладе я хочу рассказать о том, из каких элементов может состоять технология продаж сложного ИТ-продукта, как это сделано у нас, на что особенно стоит обратить внимание, а также послушать ваш опыт - приходите, должно быть очень интересно!

Программный комитет ещё не принял решения по этому докладу