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

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

20 января 2024 г.

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

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

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

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

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

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

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

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

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

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

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

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

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE