Мой первый раз: история моего первого опыта в IT

Для тех, кто любит сухие выводы, ловите уроки:

Менеджер проекта в стартап нужен СРАЗУ, а не когда все уже устали от хаоса и отсутствия ответственного.
Тестировать нужно тогда, когда понятно ЧТО тестировать, а не просто потому что есть кому этим заняться.
Решения ЧТО именно сейчас нужно продукту и В КАКОМ ВИДЕ решает продакт-менеджер, если он есть. Но по факту — тот, кто готов брать ответственность. Классно, если к моменту описания тз по каждой фиче уже есть такой, или хотя бы проджект менеджер (см. пункт 1).
MVP в глазах смотрящего. Очень важно договорится сразу о том, что значить в этой аббревиатуре слово "минимально". Иначе придется делать сразу жизнеспособный продукт (совсем не минимально).

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

Это я сейчас смогла коротко и емко описать идею стартапа. В начале все казалось куда менее конкретно — приложение для туризма с массой возможностей.

Ноябрь. Я влетела в проект, как в поезд, который уже набрал скорость и знал куда едет. Правда на дрезине. Стейкхолдеры еще в августе собрали большую команду из джунов-разработчиков и уже допиливали mvp, но что-то шло не так. В этот момент решили пригласить проджект — менеджера.

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

Урок № 1 — если ты придумал продукт, но не имеешь опыта в разработке, сначала найди себе проджект-менеджера, который будет собирать команду. А не наоборот. Мне кажется, даже джун сможет сориентироваться какие специалисты нужны проекту в первую очередь. Также он же сможет хотя бы мало-мальски распределить приоритеты, ну и будет кому нести ответственность за неправильные решения😅.

Джун, который берет ответственность на себя

Декабрь — релиз MVP. Нельзя сказать, что в какой-то момент мы его «зарелизили», ведь все делалось по харду сразу на проде. Получилась действительно работающая версия вэб-приложения, которая глобально никого не устраивала.

Ладно, у нас все было не так жестко, как у этих ребят.

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

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

Команда и до меня искала специалиста для бесплатной консультации, но эти ребята как ведьмаки — слишком круты, чтобы тратить свое время без чеканной монеты. Мне удалось найти нужного девопса. Такой Генри Кавилл не в роли ведьмака, а в роли супермена, который не смог пройти мимо утопающих и подарил бэкендерам 3 часа своего времени.

Проблемы на фронте: был дизайн и был продукт — совершенно разные непересекающиеся сюжетные линии.

Эта тотальная оторванность фронтов от дизайнера тоже шла из неправильного менеджмента, а не личных качеств или навыков специалистов. Дизайнер рисовал макеты без требований, основываясь на своем видении. А фронт ничего не понимал в макетах, но вопросы не задавал, поворчали командой и сделали по-своему. Это во-первых имело мало общего с UX/UI, во-вторых привело к хаосу на тестировании.

Мой первый раз: история моего первого опыта в IT

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

Урок № 2. Тестировать нужно тогда, когда понятно ЧТО тестировать, а не просто потому что есть кому этим заняться. Иначе ничего толкового от этого этапа вы не получите, только нервы себе потреплите, и зря время добрых людей потратите.

Отдохнув в январе и соскучившись по созвонам (да-да! такое оказывается бывает) команда предложила «допилить» проект. Для меня это важный момент — вот сейчас я смогу сделать продукт, который я смогу сделать все так, как считаю нужным и довести проект до адекватного состояния.

Февраль. Я нашла нового дизайнера. Мы с ней на берегу обсудили как должны быть выстроены процессы работы.

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

Урок № 3. Очередное подтверждение правилу «какое тз, такой и креатив». Если стейкхолдер детально не понимает чего хочет, нужно придумать за него: показать варианты и согласовать как будем делать. Корявый подход с точки зрения продуктовой разработки, но я пока и не продакт, а проджект.

Также в этот раз мы уже развернули тестовый стенд, старались релизить обновления хотя бы раз в две недели как завещал scrum. Я постоянно рефлексировала на тему процессов и ритуалов, об этом напишу в следующий раз.

Самый важный аспект — мы все работали бесплатно, пока стейкхолдеры активно искали инвесторов, подавались на гранты. Когда ребята предложили «допилить», они не понимали какой пласт работы предстоит допиливать, а я вошла во вкус, тем более с новым дизайнером чью прыть было тоже не остановить. Не удивительно, что за столь долгий срок неоплачиваемой работы над проектом некоторые ребята нашли работу или ушли в другие проекты. Так что скорость разработки упала до скорости улитки, а я добирала фронтов в том же Практикуме, чтобы закрыть оставшиеся задачи. У нас уже не было дедлайнов, но было мое желание сделать приличным свой первый продукт и не оставлять свои тз в столе. Новые задачи в бэклог я уже не добавляла, понимая что делать их вот-вот будет некому.

Урок 4. Очень четко осознала, что всем нужно учиться видеть самую минимальную версию продукта, проводить какие-то брейнштормы и воркшопы на эту тему. Упрощать, упрощать, чтобы довести до минимума. Потому что иначе разрыв между ожиданием и реальностью не избежен, и кому то за это придется платить. В данном случае платила за это команда своим временем и навыками.

В следующей жизни буду дельфином, однозначно.

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

Июль. Мы запустили веб-приложение и отпустили проект в жизнь. Буду считать, что это запуск пилотной серии сериала, который побьет рекорды просмотров. А сейчас я открыта новому опыту. Ссылку на продукт не прилагаю спецом, чтобы не думалось тут, что это рекламный пост. Оставлю это для своего cv.

По факту - джун, в душе - сеньор.