Денис Петрухин: Взаимодействие с разработчиками

10,180 views

Published on

Презентация Дениса Петрухина на #poSEEDelki 3 апреля

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
10,180
On SlideShare
0
From Embeds
0
Number of Embeds
3,419
Actions
Shares
0
Downloads
5
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Денис Петрухин: Взаимодействие с разработчиками

  1. 1. Взаимодействие с командой разработки Outsource или in-house Петрухин Денис студия Future Colors
  2. 2. Общие принципы — Наличие своего технического эксперта (желательно) — Язык и платформа — те, на которых есть потенциальные разработчики — Делать самостоятельно столько, сколько возможно — потом формировать команду
  3. 3. Общие принципы — Для типовых продуктов — лучше CMS — Постоянно отслеживать новые сервисы в интернете и по возможности использовать их, не писать свои “с нуля”
  4. 4. Архитектура и техдолг — Архитектуру надо закладывать с самого начала — Должна быть настолько простой, чтобы не мешала разработке ближайших фич — Кто-то должен за нее отвечать — Отслеживать уровень технического долга
  5. 5. Постановка задач разработчику — Agile — вариант для стартапов. Нужна команда, способная его поддерживать — Оптимальны итерации в 1-2 недели — Внутри каждой итерации всё чётко зафиксировано. В самом крайнем случае - свёртывание всей итерации и открытие новой
  6. 6. Как описывать задачу — Зачем мы это делаем (какую именно пользовательскую задачу решаем) — Как мы это делаем (предлагаемый способ) — Приёмочный тест. По каким признакам мы определяем, что задача выполнена (одновременно является ТЗ для тестировщиков)
  7. 7. — Больше понимания — больше пользы — Синхронность понимания — Лучшие решения открываются в процессе — Хорошая команда думает над продуктом, плохая - делает по бумажке Вовлечение разработчика
  8. 8. Этапы разработки — Бэклог — Оценка — Выделение итераций — Разработка — Тестирование — Выкатка
  9. 9. Признаки хорошей команды — Выполненные проекты — Тим-лид — Opensource-проекты, инфраструктура и автотесты — Осознанность в работе
  10. 10. Инхаус или аутсорс? — Что качать: технологии или маркетинг — Слишком маленькая команда неустойчива (менее 5 человек) — Фриланс — только для формализованных задач на первых этапах
  11. 11. Инхаус или аутсорс: кадры — Сложно найти специалистов — Крутые спецы не любят рутину — Всегда учиться — в рамках одного небольшого проекта это сложно
  12. 12. Инхаус или аутсорс: менеджмент — Менеджмент — это важно — Менеджмент — это затратно (особенно на этапе становления) — Менеджмент — это вообще куча всего (персонал, тестировщики, инфраструктура, системное администрирование)
  13. 13. Инхаус или аутсорс: финансы Схемы оплаты внешней команды: — фиксированная (на ком риск оценки) — за время (как считать часы) — ФФФ (Фикс тайм, Фикс прайс, Флекс скоуп)
  14. 14. Инхаус или аутсорс: как выбирать — Направление деятельности компании — Технологическая сложность проекта — Объём проекта — Сроки — Объём поддержки проекта после запуска
  15. 15. Сопровождение проекта. Фидбэк — Постоянная аналитика — Сплит-тестирование — Работа с отзывами
  16. 16. Спасибо за внимание Вопросы? +7 (495) 649-32-49 denis@futurecolors.ru Future Colors http://futurecolors.ru

×