Поставляйте меньшие единицы программного обеспечения и ограничивайте размеры локальных ветвей хоста

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

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

Если у вас есть проект, над которым нужно работать 6 месяцев, и который не будет запущен в эксплуатацию в течение 6 месяцев, это 5 месяцев и около 30 дней, когда пользователи не получат нулевой выгоды от вашей работы. Только когда он заработает, у остальной части Интернета появится шанс извлечь выгоду из того, что вы отправляете. И даже тогда именно тогда начинается масштабная тяжелая битва за усыновление. Если бы вы вместо этого выпускали часть проекта каждую неделю, пользователи начали бы получать выгоду на протяжении всего жизненного цикла проекта.

Дэйн Лайонс , мой бывший коллега, однажды сказал мне: «Мы должны продолжать добавлять атомарные единицы стоимости и выпускать столько релизов, сколько потребуется. Мы могли бы легко выпустить 10 релизов по [функциональности], прежде чем будем довольны ею и готовы двигаться дальше».

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

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

2. Чем дальше ваше подразделение отклоняется от реальности производства, тем сложнее коллегам по команде внести свой вклад в ваш проект и продвигать вперед смежные проекты.

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

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

Внося небольшие изменения более регулярно, вы даете возможность другим внести свой вклад. Они чувствуют, что то, что они поставляют, также будет работать, потому что вы оба уже согласны с тем, каков базовый уровень производства. Инкрементальный — ваш лучший друг. Это соединяет вас с реальностью. Если постепенные изменения негативно влияют на продукт, что заставляет вас думать, что более крупные изменения в том же направлении окажут положительное влияние на качество продукта?

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

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