1. Управление долгосрочными
проектами на примере
интернет-магазина МТС
Денис Митрофанов
Генеральный директор QSOFT
+7 (495) 771-73-63

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

3. Отличия долгосрочного проекта
Несколько лет интенсивной разработки (не поддержка!)
Регулярный выпуск версий (каждые 3-4 месяца)
Причем: 2-я версия больше, чем 1-я, и так далее
Мы знаем точно только состав одной версии
Требования изменяются в результате опыта
эксплуатации и изменений на рынке
Нужно поддерживать совместимость с боевой версией

4. Почему нельзя все сделать сразу
1-й результат нужен быстро
Нельзя спланировать и спроектировать на 5 лет вперед
(3 года назад не было iPad)
Изменения требований ко 2-й версии после запуска 1-й
«Парадокс проектирования» (цена растет нелинейно от
объема + точность)

5. Если не управлять
версионностью…
По мере развития
проект превращается
в «ласкутного
монстра»
Никто не знает как он
работает и почему
Доработка нового
функционала требует
нечеловеческих
усилий
Проект «ложиться»
под нагрузками

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

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

9. Первый этап развития ИМ МТС
Релиз 1 (октябрь-декабрь 2009)
Создание в сжатые сроки первой версии интернет-магазина с минимальной
функциональностью и с высокой перспективой дальнейшего развития.
Функционал:
• Разработка дизайна;
• Каталог телефонов и тарифов;
• Организация процесса
оформления и обработки
заказов;
• Базовое наполнение
контентом;
• Реализация механизмов экспорта
и импорта данных;
• Доработка каталога (отзывы,
модерация отзывов);
• Система подбора тарифного
плана.

10. Релиз 2 (январь-апрель 2010).
Запуск региональных версий интернет-магазина.
Функционал:
• Запуск 9 региональных версий ИМ;
• Реализация мультивендорности;
• Обеспечение интеграций с региональными партнерами.
Первый этап развития ИМ МТС

11. Второй этап развития ИМ МТС
Цели второго этапа заключалась в расширении регионального представления
и функциональности интернет-магазина МТС, интеграциях с внешними
системами и создание бэк-офиса.
Релиз 1 (июль-август 2010).
Реализация, настройка и запуск 70 регионов ИМ.

12. Релиз 2 (август-сентябрь 2010)
Запуск нового функционала с целью увеличения продаж, открытие раздела
для юридических лиц.
Функционал:
Второй этап развития ИМ МТС
• Реализация механизма аукциона телефонных номеров, отчетность по лотам;
• Запуск раздела для корпоративных клиентов;
• Сбор статистики по региональным версиям ИМ;
• Доработка тарифного каталога.

13. Релиз 3 (октябрь-декабрь 2010)
Разработка бэк-офиса интернет-магазина, разработка логики
резервирования остатков, внедрение акционной механики.
Функционал:
Второй этап развития ИМ МТС
• Синхронное открытие самовывоза
в 76 регионах;
• Разработка интерфейса
розничных магазинов, включая
логику резервирования,
интеграция с 1С;
• Импорт номеров тарифов;
• Разработка внутреннего web-
интерфейса ИМ для КЦ РТК;
• Разработка акционной механики
интернет-магазина;
• Разработка предзаказа;
• Переработка каталога
аксессуаров.

14. Второй этап развития ИМ МТС
Аукцион номеров:

15. Второй этап развития ИМ МТС
Внутренний web-интерфейс ИМ для КоллЦентра:

16. Релиз 1 (май-июнь 2011)
Создание веб-приложения продажи телефонных номеров через интернет-
магазин МТС для социальных сетей Facebook, Одноклассники и ВКонтакте.
Функционал:
Третий этап развития ИМ МТС
• Версия ИМ для приложений в социальных сетях (Вконтакте,
Одноклассники и Facebook);
• Разработка механизма сравнения товаров;
• Доработка интерфейса офиса продаж.

17. Релиз 2 (июнь-август 2011)
Доработка каталога и фильтра товаров.
Функционал:
Третий этап развития ИМ МТС
• Переработка принципа хранения характеристик товаров;
• Разработка фильтра по товарам;
• Синхронизация статусов резерва с системой РТК.

18. Релиз 3 (сентябрь-ноябрь 2011)
Обновление интерфейса операторов, переработка оформления и
региональности.
Функционал:
Третий этап развития ИМ МТС
• Новая версия интерфейса для
операторов ИМ;
• Разработка страниц под
мобильные устройства;
• Переработка корпоративного
раздела;
• Переработка механизма
оформления заказа;
• Разработка новой региональной
механики;
• Интеграция с сервисами mts.ru;
• Оптимизация сайта.

19. Третий этап развития ИМ МТС
Операторский интерфейс:

20. Третий этап развития ИМ МТС
Новая региональная механика:

21. Четвертый этап развития ИМ МТС
Релиз 1 (январь-апрель 2012)
Первая версия предполагала совмещение работы со сторонними складами, а
также внедрение memcached.
Функционал:
• Учет остатков со склада партнеров ИМ;
• Внедрение адаптивного кеширования сайта;
• Доработка корпоративного раздела;
• Конвертация характеристик товаров.

22. Релиз 2 (сентябрь-декабрь 2012)
Главной целью релиза являлось обновление и расширение основной
функциональности интернет-магазина, интеграция с основным сайтом
Функционал:
Четвертый этап развития ИМ МТС
• Переработка логики учета
остатков;
• Переработка логики резервов;
• Разработка новой версии
корзины;
• Переработка логики акционной
механики;
• Доработки каталога и поиска;
• Реализация виджета ИМ на сайте
mts.ru;
• Разработка функционала
рекомендации аксессуаров для
mts.ru;
• Оплата со счета мобильного
телефона.

23. Четвертый этап развития ИМ МТС
Корзина интернет-магазина:

24. Интеграции с системами РТК
• Синхронизация создания заказа
через систему 1С;
• Синхронизация событий РТК и
ИМ;
• Экспорт отмененного заказа;
Получение актуальной информации по каталогу:
• Импорт остатков товарной базы,
добавление и учет остатков на
точке;
• Импорт цен товаров;
• Импорт точек доставки;
• Импорт статуса резерва заказа;
• Импорт номенклатуры;
• Импорт остатков внешних
поставщиков;
Взаимодействие по заказам:
• Экспорт данных о клиенте
корпоративного раздела;
• Экспорт заявки на резерв;
• Экспорт заказов с тарифами.

25. Интеграции с системами МТС
• Передача данных о корзине покупателя;
• Вывод рекомендуемых аксессуаров для клиентов mts.ru (личный
кабинет).
Получение актуальной информации по каталогу:
• Импорт данных о тарифах;
• Импорт данных модельного ряда телефонов БД МТС;
• Получение каталога приложений для мобильных телефонов.
Реализация виджетов для сайта mts.ru:

26. Интеграции с внешними системами
Интеграции с партнерскими сетями:
• Экспорт каталога товаров для Яндекс.Маркет, Admitad, Criteo, Soloway,
Wikimart, GoogleShop и других систем;
• Интеграция с Яндекс.Быстрый заказ и Яндекс.Карты.
Интеграции с социальными сетями:
• Покупка номеров через приложение Red Gadget под социальные
сети (ВКонтакте, Facebook, Одноклассники);
• Виджеты социальных сетей.
Интеграции с платежными системами:
• Интеграция с кредитной системой CreditLine;
• Интеграция с платежной системой PayOnline (оплата банковской
картой);
• Интеграция с системой CyberPlat (оплата заказа со счета мобильного
телефона);
• Интеграция с системой QIWI.

27. Еще немного
теории, как
сделать всем
красиво

28. Мажорные итерации (3-6 мес.)
Рефакторинг
Нагрузочное тестирование
Доработка архитектуры, документирование
Проблема «продажи» рефакторинга: нет видимого
результата (важно чтобы у заказчика был технический
специалист) + видимые метрики

29. Разделение производства и Поддержки.
Культура отгрузок
Разделение Производства и поддержки. Минорных и
мажорных итераций
Разные цели (KPI) и психология Производства и
Поддержки
Отгрузки через отдел Поддержки
Обеспечение высокого uptime

30. Стабилизация команды. Сохранение
культуры
Люди устают, один проект надоедает, деньги не
мотивируют
Своевременная передача знаний и культуры, а не
удержание любой ценой 5-ти человек 5 лет
Команда 5-10 человек, 2 архитектора
Стабильный поток объемов

31. Основные причины падений в порядке
возрастания (по экспоненте)
Сбой на уровне «железа»
Сбой на уровне ПО (ОС, БД, web-сервер)
Сбой на уровне канала (хостинга)
Сбой на уровне Продукта
Сбой от высокой неплановой нагрузки
Сбой в результате обновления Продукта

32. Стабильность проекта 24х7
Независимый аудит кода перед отгрузкой
Сфокусированная ответственность за отгрузку
Регулярный выборочный контроль кода со стороны
эксперта (тех директора)
Автотесты
План-тесты и таблицы связанного функционала (работа
отдела качества)

34. Тренируйтесь на кошках
Частичная отгрузка на боевой – в идеале если
пользуетесь сами или часть лояльных пользователей
Отгрузка для части боевых пользователей (на
выделенный сервер)
Полная идентичность финального тестового стенда и
боевого (включая окружение)
Тестирование на реальных данных
Отгрузка одной кнопкой

35. DNS
Балансировщик
Node
1
Node
2
Node
N
Типовая схема

36. DNS
Балансировщик
Node
1
Node
2
Node
NStageStage
Отключаем одну
ноду и обновляем со
Stage

37. DNS
Балансировщик
Node
1
Node
2
Node
N
Тестовый
трафик
Включаем ноду в
тестовом режиме

38. DNS
Балансировщик
Node
1
Node
2
Node
N
Раздаем изменения
с обновленной ноды

39. Проблемы и риски
Нормирование нагрузки на команду – не равномерный
объем работы
Вялотекущие периоды сильно демотивируют команду
Большие обновления перед Новым годом – в пик
продаж
Остатки – обновление кэша по факту изменения
Синхронизация кэша на резервном сервере

40. Вопросы?
Митрофанов Денис
Спасибо за внимание!