Мышление разработчика в проектах роста

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

Инструменты — это средство, а не цель

Для каждого разработчика запуск проекта в одиночку — серьезная задача. Очень естественно чувствовать, что нужно все делать идеально. Мне потребовалось некоторое время, чтобы осознать, что стремление к перфекционизму чаще всего является отражением страха, что коллеги осудят меня за лишний «отпечаток» или за неиспользование шаблона или инструмента; и вот оно: производственный сервер рухнет, клиенты начнут жаловаться, меня уволят, и миру придет конец.

Любой инструмент, шаблон или язык программирования — это всего лишь инструмент , а не цель. Чаще задавайте вопрос: Зачем мне это сейчас? Что это даст? Какие показатели это улучшит? Например: зачем настраивать линтер сейчас? Зачем настраивать CI/CD сейчас? Если вы выполняете развертывание 10 раз в день, вероятно, вам это нужно. Если вы развертываете релиз раз в неделю или месяц, скорее всего, вы этого не сделаете. Если настройка CI/CD займет много времени, но не ускорит разработку и не принесет пользы проекту и клиентам, стоит ли ее внедрять сейчас?

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

Рефакторинг необходим только тогда, когда он позволит увеличить скорость и производительность разработки, уменьшить количество ошибок или разблокировать отставание.

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

Ценность бизнеса на первом месте

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

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

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

Можно задать резонный вопрос: «Собираюсь ли я спорить с заинтересованной стороной?» Ну, иногда будешь. Заинтересованные стороны ожидают подробного анализа. Специфика растущих проектов чаще всего заключается в нехватке ресурсов, поэтому разработчикам необходимо обладать аналитическими навыками. Вам необходимо постоянно проверять ценность функций продукта, поскольку от этого буквально зависит его жизнеспособность.

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

Задавайте много вопросов: «Зачем внедрять эту функцию сейчас? Должны ли мы решить эту проблему сейчас? Существует ли эта проблема вообще?» С технологиями все точно так же, как описано выше. Умение задавать правильные вопросы показывает ваш профессионализм. Вам нужно тратить свое время и бизнес-ресурсы только на то, что действительно приносит пользу вашим клиентам.

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

План зависит от рисков

Представьте себе стратегическую игру: у вас есть лесоруб и рекрут. Цель — создать воина. Сначала лесоруб должен собрать дрова и построить казармы, где новобранец сможет пройти военную подготовку. Чтобы заготовить древесину, лесорубу нужно добраться до леса через неизведанную часть карты. Судя по карте, до леса можно добраться за один игровой день, рубка леса займет примерно полдня, а строительство казармы — неделю. Так что казармы появятся дней через десять.

Лесорубу почти сутки добирались до леса, но внезапно путь преграждает река. Цель меняется: нам нужно построить дамбу, мост или лодку, чтобы перебраться на другой берег, а может, лучше поискать леса в другом месте. Преждевременная оценка приводит к срыву стратегии. Если бы разведчик сначала исследовал неизведанную часть карты, этого риска можно было бы избежать.

Опытный разработчик осознает риски, которые не очевидны для заинтересованной стороны: интеграция со сторонними сервисами, сложность расширения кодовой базы и так далее. Ваша обязанность — оценить риски и предупредить о них. Чаще всего заинтересованные стороны не знают об этих рисках, но они влияют на важную для них оценку.

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

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

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

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

• Разбейте сценарии на логические части, которые необходимо закодировать.

• Оцените каждую часть в днях, а затем умножьте на коэффициент 1,11. Это мой личный магический коэффициент, у меня день рождения 11 октября. Это, конечно, шутка (или нет). Мой совет — добавить к оценке пару дополнительных дней или даже недель, в зависимости от масштаба проекта. Хотя мы стараемся предвидеть как можно больше рисков, некоторые из них предусмотреть невозможно. Лучше закончить дело раньше, чем потерпеть неудачу.

  
  

  Не бойтесь давать более высокую оценку: когда заинтересованная сторона спрашивает: «Не можете ли вы сделать это быстрее?» не просто отвечайте «Нет», а обоснуйте почему. Расскажите о рисках, продемонстрируйте сценарии и приведите примеры. Заинтересованная сторона должна понимать, что вы проанализировали проблему, а не просто оценили ее случайным образом.

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

MVP — это не космический корабль

Вопрос «Как создать MVP?» беспокоил меня всю мою карьеру. Звучит просто: минимально жизнеспособный продукт.

Определение в Википедии:

Минимально жизнеспособный продукт (MVP) — это версия продукта с достаточным количеством функций, чтобы ее могли использовать первые клиенты, которые затем могут оставить отзыв для будущей разработки продукта.

Я часто замечал, что когда вам нужно создать MVP, иногда это больше похоже на постройку космического корабля, которая занимает смехотворно много времени. Основная цель на этапе MVP — получить быструю обратную связь от клиента и на основе этой обратной связи договориться с заинтересованной стороной, «идем ли мы прямо» или «поворачиваем направо». Лучший способ сбора обратной связи — метрики. Прекрасно, если у них получится и без них, но если нет, то вы хотя бы будете знать, почему.

Расскажу о своем первом MVP. Я нашел множество инструментов и фреймворков: UML, шаблоны проектирования, дорожную карту, Story Points, спецификацию системных требований, ADR, тесты пользовательского интерфейса и так далее . Я решил использовать все это, потому что эти фреймворки используются внутри крупных компаний, и я слышал о них на конференциях, лекциях и YouTube.

Целью сервиса было хранение данных о тестовых запусках. Я за год собрал дорожную карту, нарисовал подробную архитектуру на UML , долго выбирал фреймворк для бэкенда, настроил систему тестирования и логов в Sentry и посчитал нагрузку на множество пользователей вместо ожидаемых 10 -15. Я хотел сделать идеальный проект.

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

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

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

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

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

Все итерации достигли цели, и с 4-й попытки мы достигли 100%. Чтобы переписать все с нуля, потребовалось бы 10 итераций, но даже за меньшее время мы получили масштабируемый сервис, решивший проблему. Вопрос только в подходе.

Кодекс разработчика в растущем проекте

• Откажитесь от перфекционизма. Хотя в мире полно технологий, решающих проблемы, не обязательно знать все, чтобы сделать проекты полезными для людей.

• По возможности используйте готовые решения.

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

• Оценивайте риски с самого начала и четко сообщайте о них заинтересованным сторонам.

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

• Собирайте обратную связь и метрики всеми возможными способами. Метрики — надежный способ найти точки роста.

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