КАК МЕНЕДЖЕРАМ

НАУЧИТЬСЯ СТАВИТЬ

ЗАДАЧИ РАЗРАБОТЧИКАМ

Николай Хлебинский, Retail Rocket

Система real-time персональных рекомендаций для Ecommerce

Платформа для data-driven email-маркетинга

Платформа персонализации интернет-магазина

120+ миллионов уникальных пользователей в месяц

Аналитический кластер из 100+ серверов

450+ тысяч внешних запросов в секунду

9GB сырых данных для анализа… В час!

В цифрах:

ЧТО ТАКОЕ RETAIL ROCKET?

RETAIL ROCKET AT A GLANCE

1000+ клиентов и 100+ сотрудников в России, Англии, Нидерландах, Испании, Германии и Чили

Кто здесьменеджер?

ПРИМЕР ИЗ ЖИЗНИ

ПРИМЕР ИЗ ЖИЗНИ

Мы хотим ограничить размер отзыва о товаре 140 символами,

потому что мы, возможно, будем отправлять их по SMS в будущем!

Выглядит как два байта об асфальт, да?

НЕТ!ПРИМЕР ИЗ ЖИЗНИ

– Когда вы работаете над хорошим ПО,

не бывает маленьких изменений.

Что будет, когда отзыв длиннее 140 символов?

Обрезаем строку? Показываем сообщение об ошибке?

Где? С каким текстом? Кто его придумает?

Как он должен выглядеть? А CSS класс такой у нас уже есть?

Обрабатывать ошибку будем на клиенте или на сервере?

Кто пишет JavaScript? Как поддержим совместимость JS и server-side валидации, если JS

на клиенте отключен?

Как объясним пользователям 140 символов? Сделаем подсказку с количеством оставшихся?

Что еще?

ПРИМЕР ИЗ ЖИЗНИ

Кто будет писать счетчик? Может в инете есть готовый?

Кто будет тестировать его работу в 37 браузерах?

А должен стиль меняться, когда доступное количество символов подходит к концу?

А что будет, когда их станет 140? Нужно отдельное уведомление?

А что делаем с ранее оставленными отзывами? Обрезаем? Оставляем?

Кто обновит документацию? Как на счет API? А приложения для iPhone?

А что если кто-то использует странную кодировку или emoji? Вырезаем?

Надо-бы отдельную проверку на сервере для клиентов с отключенным JavaScript…

ПРИМЕР ИЗ ЖИЗНИ

- СОГЛАШАТЬСЯ НА РАСШИРЕНИЕ

ФУНКЦИОНАЛЬНОСТИ ОЧЕНЬ ПРОСТО

- КОДИТЬ НОВЫЕ ФИЧИ СЛОЖНО, А ПОДДЕРЖИВАТЬ ОЧЕНЬ ДОРОГО

Кто здесьразработчик?

Все разработчики имеют встроенную систему «свой – чужой»

Все «чужие» получают либо «это сделать невозможно», либо неадекватно высокую оценку по срокам выполнения задачи

Стать «своим» очень просто: пройдите несколько курсов на Codeacademy.com

Постройте бизнес-процесс по управлению продуктом

СЕКРЕТ ОБЩЕНИЯ С IT

0. ПРИОРИТЕТЫ

Высший приоритет: баги

Второй приоритет: доработки по ранее выпущенным фичам

Третий приоритет: технический, долго

Четвертый приоритет: новые фичи

Подробнее: https://habrahabr.ru/company/retailrocket/blog/329346/

КАК У НАС УСТРОЕН ПРОЦЕСС НАРАЩИВАНИЯ ФУНКЦИОНАЛЬНОСТИ

1. ГИПОТЕЗА

Исследования рынков, конференций, интервью клиентов, инструменты аналитики

Фича должна иметь оценку ожидаемой прибыли

Фича должна получить подтверждение интереса от нескольких клиентов

Результат: бизнес-требования (до задачи в разработку еще далеко)

КАК У НАС УСТРОЕН ПРОЦЕСС НАРАЩИВАНИЯ ФУНКЦИОНАЛЬНОСТИ

2. БЭКЛОГ

Подготовка функциональных требований, user story map, мокапов

Приоретизация бэклога по стоимости и ожидаемой прибыли от фичи

Фича должна иметь измеримые KPI для оценки ее ценности

Результат: Google Doc, который передается разработчикам

КАК У НАС УСТРОЕН ПРОЦЕСС НАРАЩИВАНИЯ ФУНКЦИОНАЛЬНОСТИ

ПостановказадачиПодробнее: https://habrahabr.ru/company/retailrocket/blog/334256/

3. MVP

Выпуск первой минимальной версии

Тестирование на нескольких клиентах в полуручном режиме, отлов багов

Измерение результата и принятие решения о выпуске полноценной версии

КАК У НАС УСТРОЕН ПРОЦЕСС НАРАЩИВАНИЯ ФУНКЦИОНАЛЬНОСТИ

4. РЕЛИЗ

Презентация отделу продаж

Маркетинговые активности

Сбор обратной связи и формирование требований к следующей версии

КАК У НАС УСТРОЕН ПРОЦЕСС НАРАЩИВАНИЯ ФУНКЦИОНАЛЬНОСТИ

Визуализация

Блокировка процесса производства

Задачи без оценки профита не нужны

КАК У НАС УСТРОЕН ПРОЦЕСС НАРАЩИВАНИЯ ФУНКЦИОНАЛЬНОСТИ

СОВЕТУЮ ХОРОШИЕ КНИГИ

БОЛЬШЕ ИНТЕРЕСНОГО В ИНЖЕНЕРНОМ

БЛОГЕ КОМАНДЫ RETAIL ROCKET

https://habrahabr.ru/company/retailrocket/blog/

Николай Хлебинскийnh@retailrocket.io