Your SlideShare is downloading. ×
Денис Петрухин: Взаимодействие с разработчиками
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

5,317
views

Published on

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

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


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

No Downloads
Views
Total Views
5,317
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
4
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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