1,651 판독값

성장 프로젝트에 대한 개발자의 사고방식

~에 의해 Dmitrii Galkin9m2024/04/20

너무 오래; 읽다

성장하는 프로젝트에서 개발자는 코딩 방식의 완벽함을 추구하는 것보다 비즈니스 가치 제공을 우선시해야 합니다. 도구와 기술은 최종 목표를 달성하기 위한 수단일 뿐이며 목표 자체는 아닙니다. 프로젝트에 대한 즉각적인 가치를 기반으로 기능이나 도구 구현의 필요성과 시기를 질문하는 것이 중요합니다. 또한 개발자는 처음부터 완벽한 코드나 아키텍처를 사용하려는 욕구에 얽매이지 않고 프로젝트의 비즈니스 측면을 이해하고, 위험을 예측하고, 확장 가능한 솔루션을 제공하는 데 집중해야 합니다. 완벽한 솔루션보다는 효과적이고 가치 중심적인 결과를 지향하는 사고방식을 유지하는 것과 마찬가지로 피드백을 수집하고 이를 기반으로 조정하는 것이 중요합니다.

많은 기술을 익히고 복잡하고 로드가 많은 서비스를 구축하는 방법을 아는 것만으로는 스타트업이나 성장하는 프로젝트의 개발자에게 충분하지 않습니다. 저는 경력을 쌓으면서 성장하는 많은 프로젝트에 참여했고 두 개의 스타트업을 처음부터 만들었습니다. 이 글에서는 개발 과정에서 무엇에 집중해야 하는지, 완벽주의가 최고의 아이디어까지 망치는 이유에 대한 내 경험을 공유하겠습니다.

도구는 수단이지 목적이 아닙니다

모든 개발자에게 프로젝트를 단독으로 시작하는 것은 확실한 도전입니다. 모든 일을 완벽하게 해야 한다고 느끼는 것은 매우 자연스러운 일입니다. 완벽주의에 대한 욕구는 동료들이 나를 추가 '인쇄물'로 판단하거나 패턴이나 도구를 사용하지 않는다는 이유로 나를 판단할 것이라는 두려움이 반영된 경우가 많다는 것을 깨닫는 데 시간이 좀 걸렸습니다. 그리고 이렇게 됩니다. 프로덕션 서버가 무너지고, 고객이 불평하고, 저는 해고되고, 세상은 종말을 맞이하게 될 것입니다.

모든 도구, 패턴 또는 프로그래밍 언어는 도구일 뿐이며 목표는 아닙니다. 더 자주 질문하세요. 지금 이것이 왜 필요한가요? 그것은 무엇을 제공할 것인가? 어떤 측정항목이 개선되나요? 예를 들어, 지금 linter를 구성하는 이유는 무엇입니까? 지금 CI/CD를 사용자 정의해야 하는 이유는 무엇입니까? 하루에 10번 배포를 수행하는 경우 아마도 필요할 것입니다. 일주일이나 한 달에 한 번씩 릴리스를 배포한다면 그렇지 않을 가능성이 높습니다. CI/CD 사용자 정의에 많은 시간이 걸리지만 개발 속도를 높이거나 프로젝트와 고객에게 가치를 제공하지 못한다면 지금 구현해야 합니까?

애완동물 프로젝트에서는 저장소와 코드의 구조를 끝없이 개선하고 패턴을 실험하는 등 새로운 것을 시도하는 것이 합리적입니다. 이 경우 우리가 구현하는 도구가 목표입니다 . 생산 프로젝트의 주요 목표는 고객에게 가치를 제공하는 것입니다. 클라이언트는 우리가 작은 따옴표나 싱글톤 대신 큰 따옴표를 사용하고 하드코드가 없다는 사실을 결코 알지 못할 것입니다.

리팩토링은 개발 속도와 성능을 높이고, 버그를 줄이며, 백로그 차단을 해제하는 경우에만 필요합니다.

품질에 대한 헌신은 완벽주의에 대한 욕구가 아니라 제품의 목표를 추구해야 합니다. 따라서 성장하는 프로젝트의 개발자는 결코 완벽주의자가 아니라는 점을 기억하는 것이 중요합니다.

비즈니스 가치가 최우선입니다

성장하는 프로젝트의 개발자에게는 비즈니스 가치를 이해하는 것이 필수적입니다. 이미 만들어진 사양에 따라서만 코딩하는 일반 개발자라면 처음에는 어려울 수 있습니다.

제품이 탄생하는 초기 단계에서는 사용자에게 제공되는 가치가 아직 입증되지 않았지만, 입증되어야 할 가치는 이해관계자의 마음 속에 존재합니다. 이 단계에서는 불필요한 로직으로 코드베이스를 오버로드하는 실수를 저지를 수 있습니다. 예를 들어 주문 핸들러를 작성해야 합니다. 아직 하나의 유형만 있지만 데이터베이스에 주문이 포함된 테이블 하나와 주문 유형이 포함된 두 번째 테이블을 생성합니다.

이해관계자가 언젠가는 이 논리가 필요할 수도 있다고 주장하기 때문에 이렇게 한다고 가정해 보겠습니다. 실제로는 결코 필요하지 않을 수도 있습니다. 지금 가치가 없다면 불필요한 엔터티를 생성하지 마십시오. 더 중요한 것은 비즈니스 시간과 비용을 낭비하지 마십시오.

"내가 이해관계자와 논쟁을 벌이게 될까요?"라는 합리적인 질문이 제기될 수 있습니다. 글쎄요, 가끔은 그럴 겁니다. 이해관계자들은 상세한 분석을 기대합니다. 성장하는 프로젝트의 특성상 리소스가 부족한 경우가 많기 때문에 개발자는 분석 기술을 갖추고 있어야 합니다. 제품의 생존 가능성은 말 그대로 제품에 달려 있으므로 제품 기능의 가치를 지속적으로 검증해야 합니다.

자신을 얇게 분산시키면 비즈니스에 리소스가 부족해지고 저장소를 보관하게 됩니다.

많은 질문을 해보세요: "이 기능을 지금 구현하는 이유는 무엇입니까? 지금 이 문제를 해결해야 합니까? 이 문제가 존재합니까?" 위에서 설명한 기술과 정확히 동일합니다. 올바른 질문을 할 수 있으면 귀하의 전문성이 드러납니다. 고객에게 진정으로 가치를 제공하는 일에만 시간과 비즈니스 자원을 투자하면 됩니다.

해커톤은 비즈니스 가치를 이해하는 것이 결과에 어떤 영향을 미치는지 보여주는 훌륭한 예입니다. 제한된 시간 내에 명확하게 정의된 문제에 대한 비이상적이지만 실행 가능한 솔루션이 제시되어야 합니다. 개발자가 프로젝트에서 영감을 얻고 왜 이 작업을 하는지 명확하게 이해하면 이틀 만에 결과가 잘 나옵니다.

계획은 위험에 따라 달라집니다

전략 게임을 상상해 보세요. 벌목꾼과 신병이 있습니다. 목표는 전사를 만드는 것입니다. 먼저 벌목꾼은 나무를 모아 신병들이 군사 훈련을 배울 수 있는 막사를 건설해야 합니다. 나무를 수확하려면 벌목꾼이 지도의 미탐사 지역을 통해 숲에 도달해야 합니다. 지도를 보면 숲은 게임 하루 만에 도달할 수 있고, 나무를 자르는 데는 반나절 정도, 막사를 짓는 데는 일주일이 걸린다. 그러니까 막사는 열흘 정도 뒤에 나타날 거예요.

벌목꾼이 숲에 도착하는 데 거의 하루가 걸렸지만 갑자기 강물이 길을 막았습니다. 목표가 변경됩니다. 반대편으로 가려면 댐, 다리 또는 보트를 건설해야 합니다. 아니면 다른 곳에서 숲을 찾는 것이 더 나을 수도 있습니다. 성급한 평가는 전략의 실패로 이어진다. 정찰병이 지도의 미발견된 부분을 먼저 탐색했다면 이러한 위험은 피할 수 있었을 것입니다.

숙련된 개발자는 이해관계자에게 명확하지 않은 위험(타사 서비스와의 통합, 코드 기반 확장의 복잡성 등)을 인식합니다. 위험을 평가하고 이에 대해 경고하는 것은 귀하의 책임입니다. 대부분의 이해관계자는 이러한 위험을 인식하지 못하지만 이는 그들에게 중요한 평가에 영향을 미칩니다.

예시 작업: 귀하의 서비스를 결제 서비스와 통합합니다. 먼저 결제 서비스를 설정하고 액세스 권한을 얻은 후 문제가 발생할 수 있는 부분을 조사하세요. 통합하기 전에 통합 방법을 이해하세요. 2~3주 개발 후에 기능을 제 시간에 완료할 수 없거나 결제 서비스에서 조건을 변경했거나 필요한 기능에 대한 지원을 비활성화하여 통합이 실패했다는 사실을 알아내는 것보다 하루를 연구에 보내는 것이 더 낫습니다. .

위험을 해결한 후에는 작업을 계획하고 작업에 대한 예상 시간을 제공해야 합니다. 이것이 내가 사용하는 프레임워크입니다:

시나리오를 작성하거나 현장에서 시각화합니다. 예를 들어 사용자가 버튼을 클릭하면 문서가 다운로드됩니다. 귀하가 이해하는 접근 방식을 선택하십시오.

보다 기술적인 관점에서 스크립트가 어떻게 작동할 수 있는지 분석합니다. 옵션이 많을수록 좋습니다. 나는 옵션을 평가하고 문제를 가장 빨리 해결할 수 있는 위험을 최소화하면서 잠재적으로 확장 가능한 솔루션을 선택합니다.

시나리오를 코딩해야 하는 논리적 부분으로 나누세요.

각 부분을 일 단위로 추정한 다음 1.11 계수를 곱합니다. 이것은 내 생일인 10월 11일인 내 개인적인 마법계수이다. 물론 농담이다(아니다). 내 조언은 프로젝트 범위에 따라 견적에 며칠 또는 몇 주를 추가하는 것입니다. 우리는 가능한 한 많은 위험을 예측하려고 노력하지만 일부 위험은 예측할 수 없습니다. 성공하지 못하는 것보다는 빨리 끝내는 것이 가장 좋습니다.

더 큰 견적을 내는 것을 두려워하지 마세요. 이해관계자가 "더 빨리 할 수는 없나요?"라고 물을 때. 단지 "아니오"라고 대답하지 말고 그 이유를 정당화하십시오. 위험에 대해 설명하고, 시나리오를 시연하고, 예를 들어보세요. 이해관계자는 문제를 무작위로 평가한 것이 아니라 분석했다는 점을 이해해야 합니다.

중요한 측면: 정신 상태도 위험합니다. 휴가를 계획하고 정신 건강에 주의를 기울여 지치지 않고 동기를 부여받으세요. 이는 귀하의 책임입니다.

MVP는 우주선이 아니다

"MVP를 만드는 방법은 무엇입니까?"라는 질문입니다. 내 경력 전체를 괴롭혔어요. 간단하게 들리네요 - 최소 실행 가능한 제품입니다.

위키피디아 정의:

MVP(최소 실행 가능 제품)는 초기 고객이 사용할 수 있을 만큼 충분한 기능을 갖춘 제품 버전으로, 향후 제품 개발을 위한 피드백을 제공할 수 있습니다.

MVP를 만들어야 할 때 때로는 엄청나게 많은 시간이 걸리는 우주선을 만드는 것과 비슷해지는 경우가 종종 있습니다. MVP 단계의 주요 목표는 클라이언트로부터 빠른 피드백을 얻고, 이 피드백을 바탕으로 '직진'할지 '우회전'할지 이해관계자와 합의하는 것입니다. 피드백을 수집하는 가장 좋은 방법은 측정항목입니다. 그들 없이도 성공하면 좋지만, 그렇지 않다면 적어도 그 이유를 알게 될 것입니다.

저의 첫 MVP에 대해 말씀드리겠습니다. UML, 디자인 패턴, 로드맵, 스토리 포인트, 시스템 요구 사항 사양, ADR, UI 테스트 등 많은 도구와 프레임워크를 찾았습니다. 이런 프레임워크는 대기업 내부에서 사용하기 때문에 다 사용하기로 했고, 컨퍼런스나 강연, 유튜브 등을 통해 이야기를 들었습니다.

서비스의 목적은 테스트 실행에 대한 데이터를 저장하는 것이었습니다. 1년간의 로드맵을 짜고, UML 로 상세한 아키텍처를 그리고, 백엔드를 위한 프레임워크를 고르는데 오랜 시간을 보냈고, Sentry에서 테스트와 로그를 위한 시스템을 설정하고, 예상했던 10개가 아닌 많은 사용자에 대한 부하를 계산했습니다. -15. 나는 완벽한 프로젝트를 만들고 싶었습니다.

첫 번째 버전을 완료하는 데 6개월이 걸렸습니다. 모든 출시와 그래프를 보고 보고서를 다운로드할 수 있었지만 데이터 수집에 문제가 있었습니다. 일주일에 2~3번씩 깨진 리포트가 나와서 서비스 이용이 불가능하게 됐지만, 저는 고집스럽게 그 계획을 따랐습니다.

그 후 몇 년 동안 저는 다양한 프로젝트를 진행했고 스타트업을 시작하려고 노력했습니다. 마케팅, 영업, 고객의 고통에 대해 배웠습니다. 그 경험은 내 사고방식을 바꾸었고 이 기사에서 공유하는 접근 방식을 개발할 수 있게 해주었습니다. 실제로 어떻게 작동하는지 보여주기 위해 최근 작업에 대해 설명하겠습니다.

API 방식의 속도를 높여야 했는데, 속도가 느려서 사용자가 짜증을 냈습니다. 내부 서비스와 데이터 구조와의 통합이 많아 어려움이 있었던 모놀리스에서 별도의 서비스로 옮기려는 계획이었습니다. 이 프로젝트는 실험적이었습니다. 가속화가 가능한지 아무도 몰랐습니다.

물론 모든 것을 다시 작성하여 완벽하게 만들 것을 제안할 수도 있습니다. 저는 모놀리스와 내부 서비스에 대한 연구부터 시작하여 통합의 위험성을 조사했습니다. 그런 다음 Miro에서 간단한 다이어그램을 사용하여 전략을 만들고 모든 것을 반복으로 분류한 다음 작업을 시작했습니다.

때때로 이해관계자가 가장 먼저 알게 된 통합 문제가 있었습니다. 우선, 우리는 그것들을 해결했습니다. 예, 프로젝트에는 린터, 불완전한 테스트, 데이터베이스의 오래된 스키마 등 여전히 기술적 부채가 있었지만 클라이언트의 문제는 해결되었습니다.