Если реализация идеи не приносит быстрого успеха, анализируем: «А есть ли проблема, которую решаем, или мы ее придумали»
Создавая IT-продукты, мы придерживаемся принципов гибкой разработки — Agile. На первый план выходят люди и взаимодействия, сотрудничество с заказчиком, работающий продукт и готовность к изменениям даже на поздней стадии разработки. Формализм в виде следования процессам и согласования условий договора отходит на второй план.
В работе используем методологию Scrum — вид Agile разработки. Чтобы понять, как устроен процесс, познакомьтесь с действующими лицами.
Участники scrum-разработки
1. Владелец продукта. Увлечен идеей, четко знает, какие проблемы будет решать продукт и для кого. Общается с клиентами, получает от них пожелания и замечания по разработке. Роль владельца продукта выполняю я, так как сам в течение 16 лет работал проектировщиком и был на месте наших потенциальных пользователей.
2. Разработчики. Разбиваются на группы не более, чем по 5 человек. Если людей больше, наладить эффективное взаимодействие между ними невозможно. Каждая группа выполняет свою часть работы, которая не пересекается с задачами остальных групп.
3. Заинтересованные пользователи или ранние последователи. Их призвание — любить, использовать IT-продукт и высказывать пожелания по его улучшению владельцу разработки.
«А за что любить продукт, который еще не допилен и не вышел на большой рынок», — спросите вы?
Во-первых, за то, что в результате взаимодействия пользователей с разработчиком происходит бесплатная кастомизация продукта.
Во-вторых, за то, что желаемые функции быстро появляются в продукте, ведь scrum — не только гибкая, но еще и быстрая разработка.
В-третьих, за то, что проблемы в работе продукта разработчик решает оперативно, ведь заинтересованные пользователи — ключевой элемент в системе Scrum, и к ним относятся с максимальной заботой и вниманием.
4. Scrum-мастер — связующее звено между владельцем продукта и командой разработчиков:
- получает от владельца продукта пожелания по функционалу и контролирует, чтобы они попали в product backlog — банк идей;
- устраивает совещания с разработчиками и переводит пожелания в «фичи» — характеристики продукта;
- планирует, сколько фичей будет выполнено за ближайший спринт;
- следит, чтобы в команде не было разногласий и ничего не отвлекало от работы.
Как устроен процесс
1. Пожелания заинтересованных пользователей в порядке приоритета владелец продукта фиксирует в банке идей — product backlog.
2. Процесс разработки поделен на короткие отрезки времени — «спринты» или, если переводить дословно, забеги.
3. Во время каждого спринта длиной в 1-2 недели разработчики добавляют продукту новые фичи.
4. Новый сотрудник быстро адаптируется в команде и встраивается в проект за 1,5 недели.
5. Один из элементов Scrum — доска со стикерами, на которой видно, как задачи проходят этапы: «ожидание», «в работе», «завершено». Большую часть времени разработчики работают удаленно, поэтому роль канбан-доски выполняет система управления проектами Easy Task.
6. Scrum-мастер собирает разработчиков, чтобы перед спринтом обсудить последовательность действий в предстоящем забеге или после окончания спринта проанализировать, что было сделано хорошо, а чего надо избежать в следующем спринте.
7. По реализованным функциям владелец продукта получает обратную связь от заинтересованных пользователей, а с ней и новые пожелания.
8. Количество фичей на входе должно быть равно количеству фичей на выходе. В первое время пожеланий от заинтересованных пользователей будет много, поэтому владельцу продукта стоит научиться расставлять приоритеты. Если, фичей зайдет больше, чем возможно реализовать за спринт, образуется затор задач и пострадает качество исполнения.
Мы с самого начала тестируем идеи на реальных клиентах — это помогает понять, нужен ли продукт или отдельные функции пользователям. Если реализация идеи не приносит быстрого успеха, возвращаемся в начало, чтобы понять, существует ли проблема, которую решаем, или мы ее придумали.
Поскольку тестирование идей занимает максимум месяц, предприниматель не вложит много средств, прежде чем поймет, что идеи нежизнеспособны. Так стартап становится экономичным, а продукт развивается только в нужных направлениях.
Алексей, у меня как-то не увязывается когда вы говорите про 1-2 недели на спринт и что тестирование занимает как минимум месяц. Что вы подразумеваете под тестированием? Пока у меня сложилось мнение, что вы сначала используете "водопадную модель".
Сергей, доброе утро! Написал, что тестирование идей занимает "МАКСИМУМ месяц". Возможно, меньше. Фичи реализуем, выпускаем, клиенты тестируют и в течение месяца получаем обратную связь. Это имел в виду)