Колонки

Где и как «подстелить соломку», чтобы запустить стартап и не провалиться

Колонки
Анастасия Кузьмина
Анастасия Кузьмина

Эксперт-аналитик IT_One

Анастасия Удальцова

Анастасия Кузьмина — эксперт-аналитик компании IT_One. Два года назад ее команду привлекли к работе над заказным стартапом — требовалось перевести офлайн-операции в онлайн, подключить возможность проводить электронные сделки. В материале Анастасия поделилась советами, как избежать трудностей в организации, общении с заказчиком и командой и успешно запустить проект с нуля.

Где и как «подстелить соломку», чтобы запустить стартап и не провалиться

 

Решите оргвопросы

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

  1. Спланируйте повестку и список участников встреч;
  2. Назначьте модератора, который будет вовремя возвращать всех к ключевым вопросам.

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

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


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


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

В стартапе должен быть «тоталитаризм мнений».

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

 

Отрегулируйте коммуникации

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

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

Читайте по теме: «Ну вы же специалисты»: что такое партнерские отношения между заказчиком и исполнителем


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

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

В этом случае я рекомендую оставлять «следы» — рисовать схемы прямо во время встреч.

  1. Это поможет зафиксировать решение в памяти.
  2. Включает синергию всех участников — они могут высказываться, поправлять элементы схемы, добавлять новые. Такой процесс гораздо увлекательнее, чем просто смотреть на монитор во время онлайн-встреч:
  • схемы более универсальные, чем тексты; 
  • визуалам их легче воспринимать; 
  • каждый может рисовать их в любой удобной программе (Visio, Miro); 
  • картинку легче вспомнить; 
  • у всех в голове единое понимание и точка отстройки для принятия дальнейших решений.

Безусловно, такой подход может оказаться психологически сложным для тех участников, кто ранее его не практиковал. Люди могут переживать, что плохо рисуют, но ровные и красивые линии тут совершенно не важны. Главное — начать.

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

Научиться эффективному управлению или прокачать свои навыки можно выбрав курс в каталоге курсов управления.

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

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

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

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

Если этого не делать и сразу писать требования для разработки, можно столкнуться с рядом проблем:

  • Будут возникать ситуации в духе «отработал, а результата нет»

Не зафиксировано на бумаге — значит не было.

  • Сложнее будет готовить обязательные отчеты

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

Подготовка минуток процесс отчетности сильно упрощает. Вы пересылаете их менеджеру, он выводит информацию в статус, пишет, что сделано и какие договоренности зафиксированы, а также кто и что должен сделать на следующем этапе.

Это удобно — не нужно устно и не по одному разу все пересказывать, стараясь не упустить важные детали

  • Когда участников много, сложно до всех донести нужную информацию

Минутки можно просто переслать каждому, и если возникнут вопросы — обсудить их на встрече отдельно. Это проще, чем проводить устные беседы с каждым.

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

Из-за этого начинают сдвигаться сроки проекта и возникают претензии.

Письма с минутками — ваша страховка в переговорах с представителями заказчика. Опираясь на факты, вы всегда сможете прокомментировать причины задержки и все нестыковки.

Так, в нашем проекте это привело к смене заказчика и более эффективной работе.

  • Сложно вспомнить, что нужно сделать на следующей встрече

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

 

Сформулируйте нефункциональные требования

Нефункциональные требования (НФТ) — это то, без чего не обходится ни один стартап. Что к ним относится:

  1. операционная система; 
  2. СУБД; 
  3. нормативная документация; 
  4. значения производительности; 
  5. требования смежных систем;
  6. цветовая гамма и стиль интерфейса;
  7. tone of voice для общения с пользователями.

В существующем проекте НФТ собрать всегда несложно, потому что есть прод, и на него можно собрать текущую статистику, прикинуть динамику. В новом проекте это может оказаться гаданием на кофейной гуще и настоящей головной болью.

НФТ дают большую неопределенность, и на них надо закладывать много времени. Даже если задача кажется простой, понятной и очевидной — заложите минимум х2, чтобы успеть все в срок. 


Читайте также: Найти решение бизнес-проблем в сжатые сроки: опыт дизайн-студий


Если заказчик не может предоставить необходимые данные, придумайте все самостоятельно: 

  1. найдите открытую статистику;
  2. составьте несколько сценариев; 
  3. нарисуйте графики по разным показателям; 
  4. итоги представьте заказчику, чтобы он выбрал наиболее подходящий и близкий к реальности вариант. 

Но это тоже определенный риск, так как можно буквально «попасть пальцем в небо» и остановиться на тех НФТ, которые в сотни раз превышают реальные. Из-за этого архитектура решения сильно усложнится, а разработка и тестирование потребуют гораздо больше усилий.

Поэтому первые релизы стоит планировать, как пойдет.

Не упирайтесь в архитектуру, делайте, как получается. Но обязательно потом запланируйте время на модернизацию решения 

 

Расширяйте команду

Вы спроектировали систему, поняли, как ее делать, и пришли к выводу, что она будет огромная. Значит, необходимо расширять команду. Иерархия при этом может быть выстроена по продуктовым дивизионам. Под каждым находится лид по разным направлениям. Под ним уже senior и regular. 

  • Учитывайте нагрузку лидов

Если помимо текущих задач им придется проводить технические интервью, встречаться с заказчиком и командой, встраивать в процессы новых сотрудников и еще тянуть regular в случае отсутствия senior, то они быстро выгорят.

И тогда даже простейшие задачки будут вызывать отторжение и раздражение, а значит — снизится скорость разработки системы.

  • Подготовьте шаблоны — как именно необходимо формулировать требования

Иначе участники проекта будут писать их совершенно по-разному в силу своего видения.

  • Если организуете большой найм персонала, проводите его волнами

Набрали несколько senior, ввели их в команду, через месяц — следующая волна.

Обязательно нужны перерывы на встраивание новичков в команду. Бесконечный наем в режиме «бешеной белки» очень опасен — вместо увеличения производительности вы получите ее снижение.


К примеру, у нас была задача на 100 человеко-часов. До расширения мы делали ее за один спринт силами трех команд. После того, как команд стало шесть, ничего не изменилось — задача по-прежнему занимала один спринт.

Мы очень много времени тратили на коммуникации и производительность снижалась. А из-за того, что наем шел неравномерно, получили во времени разные бутылочные горлышки. То не хватало фронта, то архитекторов, то еще кого-то.

Рост команды должен быть сбалансированным. 

 

Организуйте пространство для работы с заказчиком 

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

Что с этим делать?

  1. Разработайте правила работы и внедрите единое рабочее пространство. Это может быть, например, бизнес Jira, где вы сможете мониторить статусы задач, ход их выполнения и на чьей стороне они находятся — вашей или заказчика. 
  2. Всю переписку можно вести в бизнес Confluence — так она не теряется среди писем или сообщений в чатах. Требования и комментарии видны обеим сторонам, оперативно отрабатываются и всегда можно поднять историю.

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

 

Резюмируем

  1. Стартап сильно отличается от запущенного проекта. Поэтому все нужно продумать заранее.
  2. Сколько людей — столько и мнений. Учитесь договариваться и слышать друг друга. 
  3. Фиксируйте абсолютно все. Лучше всего — схемой. Вместо тысячи слов проще нарисовать одну, понятную всем схему.
  4. Обязательно записывайте минутки, не надейтесь на заказчика. У него свой интерес, у вас — свой. Всегда должны быть факты для подстраховки на случай споров. 
  5. Используйте такие инструменты, как бизнес Jira и бизнес Confluence. Этим вы избавите себя от множества проблем.
  6. Будьте готовы к тому, что все сделанное на старте можно выкинуть. Это тяжело, но факт.
  7. Много времени уйдет на построение команды, потому что стартап запускается всегда небольшим количеством единомышленников и хорошо понимающих друг друга людей. Но как только он разрастается, растет и команда, и смежные проблемы. 
  8. Как стартап ни планируй и ни продумывай все детали, он пойдет иначе. Поэтому, оценки и сроки надо перезакладывать. 

 


Фото на обложке сгенерировано нейросетью Midjourney

Подписывайтесь на наш Telegram-канал, чтобы быть в курсе последних новостей и событий!

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Наём сотрудника равен 2,5 его зарплаты
  2. 2 Реорганизация юридического лица
  3. 3 Как сообщить об увольнении правильно: не допускайте эти 6 ошибок
  4. 4 9 типов коллег, с которыми трудно работать
  5. 5 Топ-5 советов по моделированию схем для вашего бизнеса
RB в Telegram
Больше полезного контента в Telegram
Подписывайтесь!