КАК МЕНЕДЖЕРАМ НАУЧИТЬСЯ СТАВИТЬ ЗАДАЧИ...
TRANSCRIPT
КАК МЕНЕДЖЕРАМ
НАУЧИТЬСЯ СТАВИТЬ
ЗАДАЧИ РАЗРАБОТЧИКАМ
Николай Хлебинский, 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/
Николай Хлебинский[email protected]