Как взаимодействовать с разработчиками

Как взаимодействовать с разработчиками

Денис Петрухин, генеральный директор Future Colors
3 апреля 2014
#poSEEDelki

Какой сценарий разработки лучше выбрать и когда;
Как поставить задачу программистам;
Как определить уровень команды-аутсорсера;
Как, собственно, вести весь проект.

http://greenfield-project.ru/poseedelki/events/poseedelki_3_04_2014/

258ea49e94e15499de794dc016cfe27c?s=128

Future Colors

April 03, 2014
Tweet

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