PRODUCT MANAGER VAS+SITE
Уманский Андрей
PRODUCT
ENGINEER
Роль разработчика в продуктовой
компании
ПЛАН
1. Intro
2. Про нужду продуктового бизнеса
3. Time to Market
4. Стартап Культура
5. Процесссы
6. Технологии
7. Советы
Немного
философии
НОРМЫ НЕ
СУЩЕСТВУЕТ
СПИСОК ПРЯМЫХ БИЗНЕС-
ПОТРЕБНОСТЕЙ
Time to market.
Время от момента
появления проблемы или
идеи до получения
результата конечными
пользователями должно
быть достаточно
коротким, чтобы мы
могли эффективно
реагировать на изменение
рынка и бизнеса
Productivity
Производительность
разработки в виде
количества
произведенной ценности
в единицу времени
должна быть достаточной,
чтобы IT не являлось
узким местом и не
тормозило развитие
бизнеса компании.
Customer
Experience
Продукт должен быть
достаточно высокого
качества с точки зрения
конечного использования
для удовлетворения
потребностей всех
заинтересованных лиц
Мысль №1
Первые две цели кажутся близкими, но на
самом деле они разные по смыслу.
Productivity за год может оказаться
неплохой — вы деливерите сразу целую
кучу ценности, просто очень редко. При
этом Time-to-Market может оказаться
очень плохим.
Мысль №2
Во вполне благополучной Agile-команде с очень хорошим
Time-to-Market производительность может оказаться
недостаточной.
Если потребности бизнеса выше возможностей команды,
какие-то проекты будут просто ждать в баклоге.
И хотя time-to-market для задач может быть очень
хорошим, среднее время ожидания в баклоге до старта
работ будет высоким и команда будет казаться бизнесу
медленной.
Мысль №3
Цели “Productivity" - “Time to market" — “Customer
Experience" являются основными. Понятно, что их
достижение часто невозможно без наличия определенного
уровня зрелости процессов внутри организации.
СПИСОК КОСВЕННЫХ
БИЗНЕС-ПОТРЕБНОСТЕЙ
Transparency
Процесс должен
быть прозрачен и
понятен
участникам. Лишь
при этом условии
можно его улучшать
Predictability
Разработка должна
быть предсказуемой.
По каждому
происходящему
изменению мы
должны понимать,
как оно влияет на
достижение
поставленных целей
и данных
обязательств
Quality
Разумеется, работа не
может считаться
эффективной, если не
соблюден должный
уровень качества кода
и продукта
Motivation
Низкая мотивация
сотрудников — часто
следствие предыдущих
проблем, но вполне
может рассматриваться
как самостоятельная
цель
Современная стратегия
Не только завершить проект в срок и в рамках
бюджета, но и обеспечить успех на рынке
Интеграция и координация работ на всех
этапах жизненного цикла разработки нового
продукта
TO MARKET
TO FEEDBACK
TO PROFIT
TIME
● Решить проблему
пользователя
● Дедлайн обусловлен
бизнесом
● Критерии сделанной работы
● Право на изменение скоупа
● Ad hoc - не костыль
STARTUP culture
● Правильный рекрутинг
● Автономия на принятие
решений
● Персональная ответственность
● Универсальные бойцы
Иметь только узкую
специализацию уже не
достаточно.
мастера на все руки и
профессионалы узкого
профиля в одном.
Сбалансированный набор
из умения работать на
стыке дисциплин,
высокого уровня эмпатии
и желания расширять
кругозор
● Опыт
● Знания
● Исследования
Любопытство
● Выполнение
FULL-STACK
development
● Back-endFront-end + верстка
● DEV - заказчик у других отделов
● Demo от разработчика
● QA граничные кейсы и
интеграция
PRODUCT mindset
● Инженер, а не программист
● Subject-matter expert
● ЦельПроблема - вариант
решения
● DEV имеет доступ к данным
● Proof of Concept - MVP
CI / CD*2
● Feature Flags
● МикроСервисы
● Unit тестирование
● Инструменты логирования
● Code review не защита, а
возможность
SDLC
Процессы
● Меньши касаний
● Product Manager = Продюсер
● Тестирование требований
● MVP
● Early Adopters
● Релиз команда
Tips and Tricks
★ Scrum of Scrums
★ Sales не другой мир
★ Смотреть на календарь
★ Нет мультизадачности
★ Правильный рекрутинг
★ Переменная нагрузка
★ Happy Managment?
★ Не все проектызадачи
★ Социология
★ Простые решения
ВСЕ ТЛЕН
ВСЕ БУДЕТ
СЕКТОР ПРИЗ
5 минут на вопросы
Контакты
ask@umansky.me
fb.com/andrew.umanskiy
ua.linkedin.com/in/andrey
umansky

Андрій Уманський: Роль розробника в продуктовій компанії. Product engineer – швидше, краще, дешевше

  • 1.
  • 3.
    PRODUCT ENGINEER Роль разработчика впродуктовой компании
  • 4.
    ПЛАН 1. Intro 2. Пронужду продуктового бизнеса 3. Time to Market 4. Стартап Культура 5. Процесссы 6. Технологии 7. Советы
  • 5.
  • 6.
    СПИСОК ПРЯМЫХ БИЗНЕС- ПОТРЕБНОСТЕЙ Timeto market. Время от момента появления проблемы или идеи до получения результата конечными пользователями должно быть достаточно коротким, чтобы мы могли эффективно реагировать на изменение рынка и бизнеса Productivity Производительность разработки в виде количества произведенной ценности в единицу времени должна быть достаточной, чтобы IT не являлось узким местом и не тормозило развитие бизнеса компании. Customer Experience Продукт должен быть достаточно высокого качества с точки зрения конечного использования для удовлетворения потребностей всех заинтересованных лиц
  • 7.
    Мысль №1 Первые двецели кажутся близкими, но на самом деле они разные по смыслу. Productivity за год может оказаться неплохой — вы деливерите сразу целую кучу ценности, просто очень редко. При этом Time-to-Market может оказаться очень плохим.
  • 8.
    Мысль №2 Во вполнеблагополучной Agile-команде с очень хорошим Time-to-Market производительность может оказаться недостаточной. Если потребности бизнеса выше возможностей команды, какие-то проекты будут просто ждать в баклоге. И хотя time-to-market для задач может быть очень хорошим, среднее время ожидания в баклоге до старта работ будет высоким и команда будет казаться бизнесу медленной.
  • 9.
    Мысль №3 Цели “Productivity"- “Time to market" — “Customer Experience" являются основными. Понятно, что их достижение часто невозможно без наличия определенного уровня зрелости процессов внутри организации.
  • 10.
    СПИСОК КОСВЕННЫХ БИЗНЕС-ПОТРЕБНОСТЕЙ Transparency Процесс должен бытьпрозрачен и понятен участникам. Лишь при этом условии можно его улучшать Predictability Разработка должна быть предсказуемой. По каждому происходящему изменению мы должны понимать, как оно влияет на достижение поставленных целей и данных обязательств Quality Разумеется, работа не может считаться эффективной, если не соблюден должный уровень качества кода и продукта Motivation Низкая мотивация сотрудников — часто следствие предыдущих проблем, но вполне может рассматриваться как самостоятельная цель
  • 11.
    Современная стратегия Не толькозавершить проект в срок и в рамках бюджета, но и обеспечить успех на рынке Интеграция и координация работ на всех этапах жизненного цикла разработки нового продукта
  • 12.
  • 13.
    ● Решить проблему пользователя ●Дедлайн обусловлен бизнесом ● Критерии сделанной работы ● Право на изменение скоупа ● Ad hoc - не костыль
  • 14.
  • 15.
    ● Правильный рекрутинг ●Автономия на принятие решений ● Персональная ответственность ● Универсальные бойцы
  • 16.
    Иметь только узкую специализациюуже не достаточно. мастера на все руки и профессионалы узкого профиля в одном. Сбалансированный набор из умения работать на стыке дисциплин, высокого уровня эмпатии и желания расширять кругозор
  • 18.
    ● Опыт ● Знания ●Исследования Любопытство ● Выполнение
  • 19.
  • 20.
    ● Back-endFront-end +верстка ● DEV - заказчик у других отделов ● Demo от разработчика ● QA граничные кейсы и интеграция
  • 21.
  • 22.
    ● Инженер, ане программист ● Subject-matter expert ● ЦельПроблема - вариант решения ● DEV имеет доступ к данным ● Proof of Concept - MVP
  • 23.
  • 24.
    ● Feature Flags ●МикроСервисы ● Unit тестирование ● Инструменты логирования ● Code review не защита, а возможность
  • 25.
  • 26.
    Процессы ● Меньши касаний ●Product Manager = Продюсер ● Тестирование требований ● MVP ● Early Adopters ● Релиз команда
  • 27.
  • 28.
    ★ Scrum ofScrums ★ Sales не другой мир ★ Смотреть на календарь ★ Нет мультизадачности ★ Правильный рекрутинг ★ Переменная нагрузка ★ Happy Managment? ★ Не все проектызадачи ★ Социология ★ Простые решения
  • 29.
  • 30.
  • 31.
    5 минут навопросы
  • 32.