Как внутрикорпоративный мини-проект превратился в стартап

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

В прошлом году я работал по найму в одном стартапе, в роли Fullstack-разработчика в связке с Backend-разработчиком (удалёнка).

Сперва велась работа над мобильным приложением (аналог youdo/профи ру). Но в апреле, в разгар пандемии, ребята решили заморозить этот проект и переключиться на маркетплейс по доставке продуктов (как и сделали многие).

Поскольку конкуренты появлялись, как грибы после дождя, а так же был риск потери основного финансирования, формат ведения этого проекта был немного экстремальным.

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

Через месяц, когда я сделал основные экраны с логикой, начались "правки". Я люблю приводить пример с домами. Когда построили дом и начинаем двигать комнаты (у которых разный размер), после чего приходится двигать стены и потолки, переставлять раковину (или вообще её выкинуть на улицу). Особенно страдают коммуникации и проводка (т.е. логика). Правки прилетали одна за одной. Сперва мелкие, которые доносились в ходе обсуждений или в мессенджерах. Затем правки накапливались и присылались в google docs с комментариями, где я задавал вопросы, получал ответы, иногда переходя в мессенджеры.

Следующим шагом был PowerPoint: верхняя часть слайда - скрин с нумерацией правок на компонентах, местами выделение области, а нижняя часть - нумерация с описанием. Я сразу вспомнил упражнение из книги "Скорочтение", где в хаотичном порядке расставлены цифры, ты смотришь в центр и должен найти все цифры по порядку от 1 до n.

Прошло 2.5 месяца, функционал рос, добавлялись интеграции (чат-боты, платёжная система, google maps для расчёта маршрутов и стоимости) и было принято решение усилить бэк. В команду пришёл крутой питонист, Тимлид, с большим опытом запусков ИТ проектов. Он по-своему структурировал работу. Где-то стало лучше, убралась спешка и давление на программистов по срокам. Чётко были расписаны требования, задачи, спринты, мы перестали пилить продукт "на коленке".

Но коммуникация с дизайнером-проджектом (он же один из основателей) стала ещё интереснее. Теперь эти слайды из PowerPoint были вложены в задачу в JIRA в таком виде: картинка - слайд с нумерацией, а в описании задачи эта нумерация с кейсами. Для того, чтобы задать уточняющие вопросы, я писал в комментарии к задаче номер кейса и вопрос. Затем дизайнер отвечал под кейсом (в моём же комментарии) другим цветом. Когда комментарий становился совсем нечитабельным, переходили в другие. Некоторые правки отправлялись в slack, некоторые в telegram (часто было так, что уже не понимаешь о каком экране речь), другие же обсуждались на митапах/дейли, т.е. как понял, так и записал (а что-то пропустил).

Помимо интерфейсов ещё нужно показать/узнать логику взаимодействия компонентов/экранов. Не всегда было удобно созвониться, расшарить свой экран и пробежаться по логике, и я решил записывать видео своего экрана, с пометками. Раньше я занимался монтажом видео, поэтому мне не составило труда формировать короткие видео, где на определённом таймлайне всплывали стрелки, области выделения компонента или текст; можно было эпическую музыку вставить, но наверное это уже перебор.

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

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

Далее решил посоветоваться с коллегами, как можно улучшить коммуникацию, какие сервисы ещё можно использовать, но услышал от них, что нельзя вести проект в разных сервисах, т.е. если выбрали JIRA, значит там и будем всё делать. Но мне сложно было продолжать работу в таком формате, поэтому поиски продолжились.

Опыт с прошлыми командами, в офисе и на удалёнке напоминал о тех же проблемах, но не так ярко выраженных, как в текущих условиях. Я видел основную боль в том, что в разных командах используют разные методы коммуникации. В больших компаниях есть устоявшийся регламент и управление процессами (и то не везде всё ок с этим), но в средних и маленьких командах используют опыт коллег. Кто-то из основателей имел опыт в ИТ проектах, кто-то первый раз и в итоге придумывают свои способы коммуникации.

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

На тот момент я пилил один pet-проект, но решил его отложить и попробовать развить идеи, которые теперь всё больше и больше занимали мой ум. Сперва в Sketch отрисовал экраны, компоненты и их разные состояния. По ходу этого дорабатывал общую концепцию. Закончив с "дизайном" перешёл к выбору технологии.

Решил использовать Vue.js для скорости + библиотеку fabric.js. Выглядело всё это так себе, ведь я не учился дизайну, но для меня главное было показать общую концепцию и функционал.

Я предполагал, что покажу это своей текущей команде, вдруг им это будет интересно и они подключат своего инвестора к разработке (ведь они уже сделали один pivot). В общем взялся за код и где-то с мая по сентябрь я разрабатывал два модуля.

Основной модуль это кейс-трекер (его я на тот момент называл по-другому), который по моей задумке должен объединить в одном месте скрины с правками, описание правок и обсуждение по ним. При клике на чекбокс, правка исчезает со слайда, тем самым освобождая пространство (а ранее тратилось время на доп. пробегание глазами по всем номерам).

Второй модуль это видео-трекер, через который из браузера можно сделать запись своего экрана, сохранить её, накидать кейсов на таймлайны, передав логику взаимодействия компонентов/экранов. В итоге я планировал реализовать два инструмента, благодаря которым не нужно искать кучу инструментов, чтобы донести правки и логику до разработчика, а разработчику в свою очередь задать уточняющие вопросы дизайнеру (и обсудить это там же).

Но было одно но. Я совершенно не понимал, где эти модули будут располагаться и что это будет за сервис в целом. Не понимал, как связать всё это с задачами в JIRA. Код написан, прототип есть, некая концепция сформирована, но что делать дальше я не знал.

На моё счастье (уже не помню как) я попал в сообщество Mesto.co и там начал поиск тех, кому этот проект покажется интересным. До этого я немного искал по соц. сетям, регистрировался в сервисах поиска кофаундеров, но безрезультатно. В Mesto я сделал небольшой пост о себе и о своём проекте. Как и ожидал, в комментариях некоторые написали, что такие задачи уже решаются через существующие сервисы.

Но на следующий день мне написал Дмитрий Майданюк и предложил пообщаться по проекту. У Димы есть опыт в бизнесе, и на тот момент он развивал два своих стартапа. Он сразу предложил ряд идей (напр. интеграция с JIRA, Slack) и расписал дальнейшую стратегию (кастдев, выяснить кто наша ЦА, яснее сформулировать концепцию и т.д.).

Через 2-3 дня в команду пришёл Александр Гуриновский, дизайнер с большим опытом, талантом и трудолюбием. И за пару недель я увидел, как мои наработки превращаются в полноценный проект. Я вспоминал, как 3 месяца назад гулял по балкону (на улицу ходили только за продуктами) и задавал себе вопрос: "Что я такое делаю, нужно ли это будет кому-либо, не трачу я время зря?". И вот мы уже с командой полноценно трудимся!

Прошло пол года, было много сложностей и разных решений, но нам удалось приблизиться к запуску Beta-версии. Впереди ещё много работы: подтвердить гипотезу, набрать первых пользователей, привлечь первый раунд инвестиций, собрать команду для реализации MVP.

Кто-то задаст вопрос: может стоило мне сразу пойти с идеей искать в команду специалистов? Скорее всего это был бы другой продукт, да и таких специалистов вряд ли удалось бы заинтересовать лишь идей. Лучше, когда концепция более менее проработана. Да и всё таки, когда видишь проделанную работу и можно "потрогать" продукт, легче принять решение готов ли ты в этом участвовать или нет.

CTO Productium,

Дмитрий Держаев.