Сколько стартап не планируй – всё пойдет иначе

У вас есть отличная идея стартапа, концепция, планы, расписанные на несколько лет вперед и даже день Х, когда необходимо представить заказчику первый релиз. Звучит красиво, а вы полны амбиций. Но нередко еще на старте начинаются проблемы. Рассказываем, как мы запускали стартап, ругались с командой и заказчиком, теряли нервные клетки, но многому научились.

Меня зовут Анастасия Кузьмина, я эксперт-аналитик в IT_One. Наша компания занимается разработкой кастомизированных продуктов. Расскажу о том, как мы запускали один из стартапов, какие шишки набили в пути, и к каким интересным выводам пришли к финалу. Все рекомендации основаны на личном опыте, реальных взлетах и падениях, поэтому, их сразу можно применять на практике и избежать наших ошибок.

Идея стартапа – перевод офлайн операций в онлайн, заключение электронных сделок (покупка, продажа недвижимости, машин, и т.д.). Проект стартовал два года назад, в эпоху карантина и был очень актуален.

На тот момент электронные сделки не пользовались популярностью, потому что люди не доверяли такому формату. А значит, ему нужно было придать юридическую значимость. Предполагалось много интеграций с крупными банками. Они должны были покупать наш продукт, использовать в своих системах и проводить электронные сделки. Также требовалось коммуницировать с множеством федеральных сервисов, из которых самый крупный и заметный – Госуслуги.

Наша сплоченная команда из 10 человек-единомышленников успела сработаться еще на предыдущем проекте. Нам было интересно всё это реализовать, и мы буквально загорелись проектом, но столкнулись с рядом проблем и сложностей.

Заказчик сразу обозначил срок, к которому нужно выпустить первый релиз. При этом нам было совершенно непонятно, с чего начать: есть классная идея, концепция, планы, но нет понимания, что должно быть MVP.

Мы проводили множество встреч с заказчиком, его спонсором, разработчиками, и пытались активно решить этот вопрос. Все они были как день сурка: мы приходили, говорили, спорили и расходились.

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

Это основные организационные проблемы, из-за которых мы буксовали и даже ругались.

Мы перехватили инициативу. Раз заказчик не знает, как и что надо сделать, значит придумаем сами.

Во-первых, перестали писать тексты. На тот момент их и так было много – письма, сообщения и т.д. Они не давали однозначного понимания проблемы, никто не хотел их читать и сверять отличия.

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

Что в ней было прорывного для нас? За основу мы взяли основные ключевые функции, которые бы позволили составить минимальный работающий продукт. Обозначили необходимые шаги реализации, прописали особенности и ограничения. Продумали, что реально успеем реализовать за определенный промежуток времени. Это позволило согласовать с заказчиком MVP за две недели.

Такой подход дал нам больше времени. Спланированы были именно те работы, которые мы сможем поддержать. Заказчик тоже остался доволен, потому что нам удалось сдвинуться с мертвой точки.

Итак, мы спроектировали набор функциональных требований и стали его прорабатывать. В процессе появлялись дополнительные вопросы к заказчику, но благодаря тому, что мы четко знали, что нам нужно решить, встречи проходили уже более продуктивно. Но возникли другие проблемы:

Мы стали оставлять «следы» - рисовать схемы прямо во время встреч. Во-первых, это помогло зафиксировать решение в памяти. Во-вторых, включало синергию всех участников – они могли высказываться, поправлять элементы схемы, добавлять новые и т. д.

Такой процесс оказался гораздо увлекательнее, чем просто смотреть на монитор во время онлайн-встреч, потому что:

Но есть один важный нюанс. Если команда раньше не практиковала этот подход, то он может оказаться психологически сложным. Участники могут переживать, что у них что-то плохо получается, рисовать, например. Но ровные и красивые линии тут совершенно не важны. Главное – начать делать. Со временем все оценят однозначную пользу и выгоду схем.

Если мы не рисовали, то просто делали записи онлайн в формате минуток, в которых фиксировали:

Заказчик сразу видел результат встречи и у него не возникало вопросов, что за резюме ему прислали, и о чем в итоге договорились.

Такие нехитрые вещи позволили нам очень сильно продвинуться в договоренностях с заказчиком и сделать рывок.

Наконец третий вариант – если не успевали писать минутки, звали на помощь дополнительного аналитика. Пока я вела демонстрацию, он фиксировал все ключевые моменты и комментарии. Также я старалась выделять 30 минут после встречи, чтобы самостоятельно прописать все минутки.

О том, как важны функциональные требования, и как грамотно расширять команду я расскажу в следующий раз.

А пока поделитесь в комментариях, сталкивались ли вы с проблемами при запуске стартапа, и как вам удалось их решить?