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

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

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

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

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

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

Правки

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

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

На одном слайде могло быть до 20 пунктов

Свежий взгляд

Прошло 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,

0
6 комментариев
Написать комментарий...
Statett

Интересная статья

Ответить
Развернуть ветку
Дмитрий Держаев
Автор

Благодарю!

Ответить
Развернуть ветку
Сергей Божнюк

Да. Зачет. Сострадаю по правкам. И прям реально в точку. И пример зачетный, при проектировании дома. Я люблю приводить пример с автомобилем).

- Давайте тут фару сделаем фиолетовой. 
- А зачем? 
- Ну типа, чтобы фара выделялась) И типа хотим отличаться от конкурентов.
- Эээмммм. Но! Ночью же будет плохо видно? - Сергей, по задаче надо сделать так. Мы лучше знаем. 

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

Но да ладно. Мои шаги банально просты. +Очередной клиент в ЧС, в котором я фиксирую. Если в следующий раз обратится, то вписываю это пунктик с пометкой "ты дизайнер вот и рисуй (потрачено: -10 часов правок)". 

Ответить
Развернуть ветку
Дмитрий Держаев
Автор

Сергей, здорово, что поделился опытом с примером! :)

Ответить
Развернуть ветку
Дмитрий Держаев
Автор

Сергей, здорово, что поделился опытом с примером! :)

Ответить
Развернуть ветку
Александр Савченко

Привет! Звучит интересно, а потрогать где-то можно уже?

Ответить
Развернуть ветку
3 комментария
Раскрывать всегда