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

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

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

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