Тезисы:

• Для чего нужны метрики? Выбираем, исходя из "того, где болит", технических целей и идей для бизнеса.
  
  
• Как собираем метрики: от Excel до автоматизации.
  
  
• Флоу проекта с помощью отслеживания метрик на Дашбордах. На что обращать внимание при управлении проектом.
  
  
• Что дальше? Или как поддерживаем метрики в командах
  
  

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


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


Fight!"

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

У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.

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

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

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

У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.

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

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

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

У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.

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

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