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

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

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

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

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

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

Оргвопросы – не шутка

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

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

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

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

Что предприняли

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

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

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

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

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

Выводы

  • Проработайте процесс выработки решения. Иначе погрязнете в обсуждениях, спорах и встречах.

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

Коммуницировать тоже надо уметь

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

  • Даже если мы говорили об одном и том же, то зачастую оперировали разными понятиями и не понимали друг друга на уровне терминологии.

  • У всех был очень разный бэкграунд и свое представление о процессах и результатах. Это выливалось в большое количество дискуссий, споров, и опять же встреч.
  • Заказчика я не знала. У меня всегда получалось выстраивать партнерские и доверительные отношения с заказчиками, договариваться об оптимальных решениях. В этом проекте такого не было и это оказалось проблемой, которая всплыла позже.

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

Что предприняли

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

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

  • схемы более универсальные, чем тексты;

  • визуалам их легче воспринимать;
  • каждый может рисовать их в любой удобной программе (Visio, Miro и др.);
  • картинку легче вспомнить;

  • у всех в голове единое понимание и точка отстройки для принятия дальнейших решений.

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

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

  • дату встречи;

  • тематику;
  • что именно обсуждали и почему;
  • какое решение приняли;

  • что необходимо сделать в следующий раз, кто ответственный и какой срок исполнения. Об этом, кстати, нередко забывают.

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

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

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

Выводы

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

  • Обсудите и утвердите единую терминологию. Иначе, столкнетесь с непониманием, спорами и снова увязните во встречах.
  • Оставляйте «следы», рисуйте схемы, делайте записи онлайн в формате минуток, зовите помощника, либо выделяйте 30 минут после встречи, чтобы самостоятельно все зафиксировать. Поможет избежать ситуаций в духе «отработал, а результата нет», и упростить планирование последующих задач для команды.

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

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

55
11 комментариев

Для меня стало удивлением, что IT-компания может принимать участие в запуске стартапа. Получилось ли у вас в итоге запустить проект?

Ответить

Всегда даже самый четко выстроенный план отличается от реальности. Вопрос в том, как это разруливать «в пути» и какие выводы сделать.

Ответить

Где взять ресурсы, когда запускаешь стартап, на документирование и структурирование процессов? Мне кажется, что горишь идеей и хочется поскорее закончить продукт

Ответить

Вопрос бесполезных совещаний - болезненный не только для стартапов. Хорошая идея про оставлять следы - спасибо)

Ответить

Да, тоже удивилась, что It-компания запускает стартапы. Но интересный опыт, спасибо, что поделились кейсом.

Ответить

Классика: чем больше и красочнее планируешь, тем меньше получается) Причем актуально вообще во всем. Я думаю, проектировать все равно необходимо, но при этом двигаться более гибко - т.е. иметь четкую концепцию, но при этом быть готовым править в моменте. Т.е этакий риск-менеджемент, где у нас есть ресурсы и идеи не только на план А, но и на планы Б и С.

Ответить

Но если не планировать, то как двигаться вперед? Не только в бизнесе, но и в жизни в целом?

Ответить