더 작은 단위의 소프트웨어를 배송하고 로컬 호스트 지점의 크기를 제한하십시오.

지난 10년 동안 HackerNoon을 이끌면서 저는 많은 재능 있는 소프트웨어 개발자들과 함께 일했고, 그들의 임기 초기에는 대개 같은 말을 하게 되었습니다. 즉, 더 작은 단위의 소프트웨어를 출시하고 로컬 호스트 지점의 크기를 제한하라는 것입니다. 왜? 다음은 두 가지 주요 이유와 한 가지 큰 문제입니다.

1. 귀하가 프로젝트 완료를 위해 계속 작업하는 동안 사용자는 귀하의 작업에서 더 많은 혜택을 얻고 피드백을 제공합니다.

6개월 동안 작업해야 하는 프로젝트가 6개월 동안 실행되지 않으면 사용자가 작업에서 전혀 이익을 얻지 못하는 기간은 5개월 30일입니다. 그것이 라이브일 때만 인터넷의 나머지 부분도 귀하가 제공하는 것으로부터 이익을 얻을 수 있는 기회를 가질 수 있습니다. 그리고 그때에도 입양을 위한 대규모 오르막 전쟁이 시작되는 시점입니다. 매주 프로젝트의 일부를 배송한다면 사용자는 프로젝트 수명주기 동안 가치를 얻기 시작할 것입니다.

내 전 동료인 Dane Lyons는 나에게 이렇게 말한 적이 있습니다. “우리는 가치의 원자 단위를 계속 추가하고 필요한 만큼 많은 릴리스를 수행해야 합니다. 우리가 만족하고 다음 단계로 나아갈 준비가 되기 전에 [기능]에 대한 10개의 릴리스를 쉽게 가질 수 있습니다.”

CEO로서 나는 종종 신입사원이 수익성 있는 기여자가 되기까지 걸리는 시간을 판단합니다. 판매에서는 이것이 더 컷고 건조합니다. 판매가 보상을 초과했습니까? 물론 마케팅, 인프라 등에 대한 한계 비용과 같이 고려해야 할 다른 사항도 있지만 어떻게 분할하든지 영업사원보다 소프트웨어 개발자가 수익에 미치는 영향을 측정하는 것이 더 어렵습니다. 소프트웨어 개발자로서 새로운 역할을 맡고 있다면 홈런을 치기 전에 싱글들을 성공적으로 연결해 보는 것이 좋습니다.

소프트웨어 개발 게임에서는 점수에 대한 보편적인 규칙이 없습니다. 물론 어떤 사람들은 포인트 시스템을 할당하고 다른 사람들은 KPI를 정의하지만, 결국 가치 창출 여부와 방법을 결정하는 것은 제품을 사용하는 사람들입니다. 더 빨리 배송하면 피드백을 더 빨리 받을 수 있습니다. 귀하의 소프트웨어를 사용하는 사람들은 프로젝트의 다음 원자 단위를 구축하고 구축하지 않는 방법을 더 명확하게 만들 것입니다.

2. 귀하의 지점이 생산 현실에서 멀어질수록 팀원이 프로젝트에 기여하고 인접한 프로젝트를 진행하기가 더 어려워집니다.

최신 버전을 제공하지 않음으로 인한 외부 효과는 처음에는 확인하기가 더 어려울 수 있습니다. 모든 것이 연결되어 있습니다. 예를 들어 HackerNoon과 같은 제품에서는 프로필 페이지와 스토리 페이지가 진공 상태로 존재하지 않습니다. 하나의 제품 내에서 연결된 페이지로 존재합니다. 한 페이지의 기능이 변경되면 해당 페이지에 연결된 모든 페이지의 기능이 영향을 받습니다.

로컬 브랜치가 매우 큰 경우 이에 연결된 페이지나 기능에서 발생하는 다른 변경 사항은 비만 브랜치가 최종적으로 프로덕션에 출시되면 작동하지 않는 경우가 많습니다. 이것은 일을 깨뜨립니다. 이로 인해 버그가 발생합니다. 이로 인해 작업을 다시 수행해야 합니다. 이로 인해 팀원들은 당신과 함께 일하지 않으려는 욕구를 갖게 됩니다. 이로 인해 현지 지점에 모든 작업을 수행하기 전에 이미 경험한 것보다 더 나쁜 제품 경험이 생성될 수도 있습니다.

작은 변화를 보다 정기적으로 수행함으로써 다른 사람들이 기여할 수 있도록 힘을 실어주는 것입니다. 그들은 생산 기준이 무엇인지 이미 동의했기 때문에 그들이 출시하는 제품도 효과가 있을 것이라고 생각합니다. 증분은 당신의 bff입니다. 그것은 당신을 현실과 연결시켜줍니다. 점진적인 변화가 제품에 부정적인 영향을 미친다면, 같은 방향으로 더 큰 변화가 제품 경험에 긍정적인 영향을 미칠 것이라고 생각하는 이유는 무엇입니까?

그리고 아주 오래된 것은 다음과 같습니다. 너무 큰 가지가 될 수 있는 대담한 프로젝트를 두려워하지 마십시오. 왜냐하면 당신은 이 빌어먹을 일이 사람들을 위해 작동하는 방식에 변화를 만들 수 있는 나쁜 mofo이기 때문입니다.

일부 프로젝트는 대규모 분기여야 합니다. 예를 들어, 새 데이터베이스와 같이 대규모 종속성이 있는 항목은 기존 사용법에 너무 깊이 뿌리박혀 있을 수 있으므로 시계를 되돌려 연간 온프레미스 2.0 릴리스처럼 프로젝트에 접근하는 것이 가장 좋습니다. 그리고 ChatGPT와 같은 다른 획기적인 기술은 구축하는 데 너무 오랜 시간이 걸렸기 때문에 훈련되지 않고 불완전하며 신기술의 UX 버전을 출시하는 것은 채택이 의미가 없습니다. 큰 스윙을 해보세요. 활주로가 있을 때. 팀이 탑승했을 때. 그러나 자신을 거창하게 생각하지 마십시오. 대부분의 경우 소프트웨어 개발은 바퀴를 재발명하지 않습니다. 그것은 단순히 다음 원자 단위를 운송하는 것입니다.