Небольшой доклад о проблемах и решениях при разработке продуктов, управлении командой.

1. Start Up and Get Done
How to build success product in time.
Максим Климишин
CTO в ZAKAZ.UA
@maxmaxmaxmax

2. Немного личного
10 лет в IT
программист, совладелец, лид, менеджер
блоггер, организатор конференций
активист OpenSource

3. О чем это я

5. Что есть на старте ?

6. НАДО СОЗДАТЬ ПРОДУКТ

7. Ограничения
Дата релиза
Платформа/технологии
Ожидаемая нагрузка

8. Команда
На вид По факту
поехали

9. По факту
За одну итерацию не сработаешься
Понять интересы и «темперамент»
разработки занимает время
Притирку и заниженную продуктивность
не учли при планировании скоупа

10. Чего хотим добиться ?

11. Идиллии

12. Цели лида
Доставить вовремя
Сплотить(ся)
Впечатлить UX-м
Краааасивый Рабочий код
Легко масштабироваться

13. Чего мы не хотим ?

14. ПРОБЛЕМ с
product owner-оm
product owner-оm

15. Типичные проблемы
Задержки в коммуникациях - особенно с
американскими заказчиками
Один PO на 10-ть проектов - с трудом
удерживает контекст одного конкретного
проекта
Большая команда “менеджмента”: PO, CTO,VP,
архитектор, маркетолог - избыточные митинги

16. Решения
Самому понять цели и стратегию разработки
продукта
Углубиться в приоритеты и детали реализации
Встречи по узким темам минимальным
составом (разделить технические и
маркетинговые)
Выбрать правильного ПО (вместо всего
выше)

17. Наархитектить

18. Что обычно тупит
Синхронная архитектура - когда “тяжелые”
задачи работают внутри слоя отображения
Dog-pile effect, “тяжелые” задачи кешируют
одновременно
Неразумное использование хранилищ -
например PgSQL как Key/Value или MySQL для
EAV
Запросы к базе данных в циклах,
автоматически генерируемые запросы, third-
party API

19. Очень простой рецепт
Оставьте синхронным только front-end -
отображение для пользователя
Как можно больше задач обрабатывайте
асинхронно
PubSub, MQ - это все создано для простых и
рабочих систем

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

21. Безопасность

22. О чем это?
Не надо хранить пароли в открытом виде, в
виде md5 без salt-a
Крайне внимательно относиться к ACL
Правильный транспорт - SSL и тп
Некорректная архитектура защищенной сети

23. Зачем?
Непредвиденные задачи по “латанию” дыр в
безопасности (не выпустить вовремя)
Доверие пользователей

24. В двух словах:
не обосраться
не обосраться

25. Как достичь цели ?

26. Планировать
два сценария
два сценария
1: Все OK
Все фичи в
полном
объеме и вовремя
2: Все по другому
• Меньше фич
• В меньшем объеме
• Включаем команду

27. Мотивировать команду
В зависимости от типа разработчика:
Задачи - интересные
Проблемы - посильные
Сроки - реалистичные
Нагрузка - поддерживаемая

28. IT’S flowtime
Тогда команда творит

29. product owner, что ты творишь, ахаха
прекрати

30. Релиз ,
теперь можно расслабить

31. Спасибо. Вопросы?
@maxmaxmaxmax