침착함을 유지하고 새로운 개발 팀으로 전환

소프트웨어 제품은 수명 기간 동안 한 개발 팀에서 다른 개발 팀으로 전환하는 것이 일반적입니다. 제품의 여러 단계에 따라 다양한 유형의 개발 팀이 필요할 수 있습니다. 초기 버전을 구축하기 위한 컨설팅, 유지 관리를 위한 단독 프리랜스 개발자, 규모를 확장하기 위한 사내 팀 또는 일부 " 팝".

이러한 일이 얼마나 자주 발생하는지에도 불구하고 많은 비기술적 설립자와 제품 소유자는 다음 팀을 불러올 때가 되었을 때 준비가 되어 있지 않고 분주합니다. 이로 인해 새 팀이 빠른 진행을 할 수 없고 시간이 낭비되며 관련된 모든 사람이 좌절하게 되는 경우가 많습니다.

이것이 당신이 될 수 있는 것처럼 들리면, 지금 또는 미래에 어느 정도 우려해야 합니다. 다행히도 이러한 상황에 대비하고 가능한 한 원활하게 전환하기 위해 취할 수 있는 단계를 안내해 드리겠습니다.

횃불 통과: 새로운 개발 팀 온보딩

이번 글에서는 그러한 변화에 대비하는 데 도움이 될 체크리스트를 알려드리겠습니다. 제품을 보다 친밀한 수준에서 알게 되고 제품을 만드는 데 필요한 모든 다양한 서비스와 기술을 더 잘 제어할 수 있으므로 자신감 있고 비교적 쉽게 새 팀에 합류할 수 있습니다.

하지만 팀 전체를 교체하지 않는다면 어떻게 될까요? 귀찮게 이걸 읽어야 하나?

이전 팀 중 일부가 남아 있더라도 원활한 전환에 필요한 모든 답변과 정보가 없을 수 있습니다. 이전 팀에서 새 팀으로 지식을 이전하는 과정에서 연속성을 제공하고 도움 을 줄 수 있지만 기존 팀 구성원에 의존하는 것이 제품 소유자가 담당하고 이전을 촉진하는 것을 대체할 수는 없습니다. 또한, 책임을 지지 않으면 기존 팀원과 신규 팀원 간의 마찰이 생기거나 기존 팀원에게 불필요한 업무 부담을 주어 새로운 팀원과 소통하고 다양한 문제를 해결하는 데 너무 많은 시간을 낭비하게 만들 수 있습니다.

그러나 일부 팀원이 계속 참여하고 있다면 전환 노력에 있어 귀중한 자산이 될 수 있습니다. 그들과 상의하고 루프에 유지하고 너무 많은 전환 관련 작업으로 그들을 과도하게 하지 않으면서 그들의 경험을 활용하십시오. 그들이 모든 힘든 일을 할 것이라고 기대하지 마십시오! 그게 당신의 일입니다.

그래서 더 이상 고민하지 않고 뛰어 들어 봅시다!

문서 수집

프리랜스 개발자는 종종 이전에 본 적이 없는 기존 코드베이스에 뛰어들라는 요청을 받습니다. 이것은 특히 Toptal 소프트웨어 엔지니어에게 해당됩니다. 우리의 목표는 항상 가능한 한 빨리 일어나서 고객에게 긍정적인 영향을 미칠 수 있도록 하는 것입니다.

프로젝트에 대한 명확하고 철저한 문서에 액세스하면 온보딩 프로세스를 크게 가속화하고 개발자가 진행을 방해할 수 있는 함정을 피하는 데 도움이 됩니다.

좋은 문서는 최소한 다음 주제를 다루어야 합니다.

• 개발 환경 설정 - 모든 신규 사용자의 첫 번째 작업은 응용 프로그램을 시작하여 자신의 컴퓨터에서 실행하는 것입니다. 그렇게 하는 프로세스는 기술마다 다릅니다. 일반적으로 소스 코드 가져오기, 데이터베이스 설정, 종속성 설치, API 키 및 자격 증명으로 환경 구성, 샘플 데이터 가져오기 등과 같은 작업이 필요합니다. 개발자는 해당 분야 내에서 이 프로세스와 관련된 모든 것을 잘 알고 있으며 그에 따라 세부 사항을 조정할 수 있어야 합니다.
• 자동화된 테스트 제품군 실행 - 애플리케이션의 테스트 통과를 확인하면 모든 것이 올바르게 설정되었으며 향후 변경 사항으로 인해 기존 기능이 손상되지 않습니다.
• 스테이징 및 프로덕션 서버에 배포 - 최신 변경 사항으로 라이브 애플리케이션을 업데이트하는 것은 고도로 스크립트화된 프로세스이며 이러한 작업의 순서는 가능한 한 자세히 설명해야 합니다.
• 새로 온보딩된 개발자와 관련된 기타 정보 - 모든 애플리케이션에는 고유한 특성이 있습니다. 이를 기록하면 이전 팀이 이미 처리 방법을 파악한 문제를 디버깅하는 데 낭비되는 많은 노력을 미래 팀에서 절약할 수 있습니다.

문서는 애플리케이션을 설정하고 코드베이스에 기여한 경험 이 있는 개발자가 작성해야 합니다.

전환이 발생하기 전에 이전 개발 팀이 위의 주제를 다루는 리소스를 만들어 지식 이전을 촉진하도록 요청하십시오!

글쓰기가 그들의 강점이 아닌 경우 개발 환경 설정, 배포 등을 보여주는 하나 이상의 스크린캐스트를 녹화하도록 요청하십시오. 오늘날에는 전체 개발 환경을 패키징하여 다른 사람에게 배포할 수 있는 Vagrant 및 Docker와 같은 도구도 있습니다. 본질적으로 누군가에게 망치를 만드는 방법에 대한 지침을 제공하는 대신 망치 자체를 제공하십시오.

프로젝트 문서가 얼마나 포괄적이고 효과적인지에 대한 리트머스 테스트는 새로운 개발자가 얼마나 빨리 개발 환경을 설정하고 애플리케이션을 실행할 수 있는지입니다.

제품 이해

훌륭한 문서가 있다고 해서 자신의 제품 기술에 대한 기본 사항을 알아야 할 필요가 있는 것은 아닙니다. 소프트웨어 제품의 소유자로서 귀하가 기술적인 지식이 없더라도 귀하의 애플리케이션을 최대한 이해하는 것은 귀하의 책임입니다.

다음 질문은 일반적이며 검색하지 않고도 답을 알고 있어야 합니다.

• 귀하의 애플리케이션은 어떤 기술 스택을 사용합니까? - 백엔드와 프론트엔드를 위한 많은 공통 애플리케이션 프레임워크가 있으며 모든 새로운 개발 팀은 애플리케이션에서 사용하는 프레임워크에 익숙해야 합니다. 백엔드 웹 기술의 몇 가지 예는 Ruby on Rails, Node.js 및 Django입니다. 프론트 엔드 웹 기술의 몇 가지 예는 React.js, Angular.js 및 Ember.js입니다.
• 어디에서 호스팅되나요? - 웹 호스트마다 배포 프로세스가 다르므로 다양한 수준의 경험이 필요합니다. 최근 몇 년 동안 클라우드 기술은 여러 가지 새로운 호스팅 옵션을 만들었으며 사용 중인 특정 옵션을 식별하고 다른 호스팅 옵션보다 선택한 이유를 설명해야 합니다.
• 개발 과정은 무엇입니까? - 팀에서 Git과 같은 특정 소스 제어 관리 도구를 사용합니까? 그렇다면 새로운 기능이 개발, 테스트, 승인 및 배포되는 프로세스는 무엇입니까? 프로세스는 표준화되고 적절하게 문서화되어야 하며 신규 이민자가 쉽게 복제할 수 있어야 합니다.
• 귀하의 애플리케이션은 어떤 타사 서비스를 사용합니까? - 일부 애플리케이션은 Shopify와 같은 타사 서비스를 기반으로 합니다. 타사 서비스에 대한 의존도가 점차 증가하고 있으며, 현재 추가 서비스를 사용하지 않더라도 프로젝트에서 나중에 타사 서비스를 사용하기로 결정할 수 있습니다.
• 애플리케이션을 실행할 수 있는 플랫폼은 무엇입니까? - 앱이 데스크톱 애플리케이션, 웹 앱, 반응형 모바일 웹사이트, 네이티브 iOS 애플리케이션, 네이티브 Android 애플리케이션 또는 기타 무엇입니까? 여러 플랫폼에서 실행되고 있습니까? 주어진 시간에 어떤 플랫폼이 우선 순위입니까? 귀사의 제품이 가장 강력하고 취약한 플랫폼은 무엇입니까? 애플리케이션의 현재 플랫폼과 확장할 수 있는 플랫폼에 대한 모든 세부 정보를 알고 있어야 합니다.

소유권을 가져라

오늘날의 소프트웨어 개발 프로세스는 과다한 타사 서비스와 도구를 활용합니다. 당신이 알든 모르든 당신의 애플리케이션도 예외는 아닙니다.

개발 과정에서 이전 팀이 귀하를 대신하여 등록했거나 필요한 서비스에 액세스하기 위해 자체 계정을 사용했을 수도 있습니다. 새 팀으로 전환한다는 것은 중개자를 통하거나 추적할 필요 없이 새 팀에 대한 액세스 권한을 부여할 수 있도록 애플리케이션이 의존하는 모든 서비스와 도구에 대한 소유권을 갖고 제어해야 함을 의미합니다. 원래 개발자.

다음은 애플리케이션에서 사용할 수 있는 다양한 외부 도구 또는 서비스의 목록입니다.

• 소스 제어 관리 - GitHub, Bitbucket, Gitlab
• 웹 호스팅 - Heroku, EngineYard, Digital Ocean, Bluehost, Amazon Web Services
• 파일 호스팅 - Amazon Web Services(S3)
• DNS 공급자 - GoDaddy, DNSimple, Hover
• 개발 서비스 - NewRelic, FileStack, Segment, Bugsnag(및 기타 수많은)
• 결제 서비스 - Stripe, Braintree, PayPal
• 블로깅 서비스 - WordPress, Tumblr, Ghost
• 전자 상거래 솔루션 - Shopify, Squarespace
• 분석/추적 - Google Analytics, Mixpanel, Kissmetrics
• 이메일 마케팅: MailChimp, 지속적인 연락

어떤 것이 적용 가능한지 나가는 개발 팀에 문의하십시오. 개발 팀이 소유 한 서비스의 경우 소유권을 귀하에게 이전하도록 요청하십시오. 그것이 가능하지 않다면 그들에게 새로운 계정을 만드는 것을 도와달라고 요청하고 애플리케이션이 그들의 계정 대신 당신의 계정을 사용하도록 하십시오. 이것은 애플리케이션에 대한 일부 구성 설정을 변경하는 것 외에는 아무것도 필요하지 않습니다.

말할 필요도 없이 모든 개발 계약이 첫날부터 귀하의 이익을 보호하고 어떤 일이 있어도 원활한 전환을 보장하는지 확인하십시오.

액세스 권한 부여

애플리케이션 생태계에 대한 확실한 이해와 애플리케이션이 사용하는 모든 다양한 도구 및 서비스에 대한 소유권을 통해 이제 들어오는 팀이나 개인에게 완전한 액세스 권한을 제공할 수 있습니다.

대부분의 서비스에서는 계정에 공동 작업자를 추가하고 특정 수준의 액세스 권한을 부여할 수 있습니다. 여기 보수적 인 것이 좋습니다 . 많은 창업자, 특히 개인 기업가는 개발자에게 서비스에 대한 전체 관리자 액세스 권한을 부여하고 모든 것을 처리하도록 하는 것을 선호합니다. 이것은 우리가 배운 바와 같이 미래에 전환하기 더 어렵게 만들 수 있는 루프에서 당신을 유지하는 부정적인 부작용이 있습니다.

개발자에게 전체 관리자 권한을 부여해야 합니까? 그것은 당신의 소명이며 대부분의 사람들은 이 접근 방식에 문제가 없습니다. 그러나 항상 미리 계획하고 결정이 새로운 개발 팀에 부정적인 영향을 미치지 않도록 해야 합니다. 프로젝트의 초기 단계에서 그렇게 하지 않으면 미래에 성가신 결과를 초래할 수 있습니다.

핸드오프 관리

이제 모든 기지를 다루었으므로 한 팀에서 다음 팀으로의 핸드오프를 관리해야 합니다. 다음은 들어오는 팀과 나가는 팀을 모두 처리하기 위한 몇 가지 기본 팁입니다.

들어오는 팀

• 기대치 설정 - 새 팀은 가장 중요한 목표가 무엇인지 알아야 올바른 방향으로 집중할 수 있습니다. 새로운 팀이 즉시 달성할 수 있는 것에 대한 자신의 기대치를 관리하는 것도 마찬가지로 중요합니다.
• 자주 체크인하십시오 - 새 팀이 가라앉거나 수영하도록 내버려 두지 마십시오. 당신은 그들이 필요한 모든 것을 갖추고 있는지 확인하기 위해 자주 체크인하고 그들이 스스로를 보호할 필요가 없다고 느끼길 원합니다. 세세한 관리 없이 이 작업을 수행하십시오. 그들이 필요하면 지원하고 도움을 주기 위해 있다는 것을 알게 하되 불필요한 압력을 가하지 마십시오.
• 인내심 - 개발자가 새로운 코드베이스에 적응하는 데 시간이 걸립니다. 새로운 팀이 이전 팀의 속도와 일치하기까지 약간의 학습 시간이 있음을 이해하십시오.

나가는 팀

• 모든 미해결 코드 수집 - 모든 소스 코드가 기본 리포지토리에 체크인되었는지 확인하고 배포되었거나 배포되지 않은 상태를 알고 있는지 확인합니다. 새 팀은 어디에서 작업을 시작하고 시작해야 하는지 정확히 알아야 합니다. 나 자신도 메인 리포지토리에 코드를 넣지 않고 배포한 팀을 대신하는 상황을 경험했습니다. 이로 인해 나가는 팀이 소스 코드를 일관된 상태로 유지했다면 쉽게 피할 수 있었던 버그, 중복 작업 및 골칫거리가 발생했습니다.
• 액세스 수준 업데이트 - 좋은 조건으로 헤어졌다면 코드 및/또는 배포에 대한 액세스 권한을 남겨두는 것이 좋습니다. 많은 팀이 새로운 팀이 완전히 인수할 때까지 전환 단계에서 기꺼이 도와줍니다. 그렇지 않은 경우 우발적인 문제나 새 팀과의 충돌을 방지하기 위해 다운그레이드하거나 액세스 권한을 취소하는 것이 좋습니다.
• 그들의 노고에 감사드립니다 - 전환은 바쁠 수 있습니다. 새 팀을 처리하느라 바쁘더라도 프로젝트에 기여한 팀에 감사하는 것을 잊지 마십시오.

결론

인생의 모든 전환은 두려울 수 있으며, 잘 될지 여부에 대한 불확실성, 미지의 것에 대한 두려움 등을 가져옵니다. 새로운 개발 팀으로의 전환도 다르지 않지만 쉽게 할 수 있는 조치를 취해야 합니다. 대부분의 경우 약간의 장기 계획만 있으면 됩니다.

소프트웨어 제품, 개발 프로세스 및 프로세스에 포함된 모든 사항에 대한 기술 및 비기술적 이해를 높이면 한 팀에서 다음 팀으로의 전환을 최대한 원활하고 원활하게 수행하는 데 도움이 됩니다.

무엇보다도, 새로운 팀은 당신의 게임에서 최고의 자리를 지켜준 것에 대해 존경하고 감사할 것입니다! 시간과 노력을 절약할 수 있으므로 비용도 절약할 수 있습니다. 또한, 새로운 팀이 높은 전문적 기준을 고집한다는 사실을 빨리 깨달을수록 좋습니다. 그들은 프로젝트를 인수한 후 이러한 관행을 계속 구현하여 다음 전환도 원활하게 만들 가능성이 있습니다.

따라서 소프트웨어 제품의 소유권 이전에 선행해야 하는 핵심 사항을 검토해 보겠습니다.

• 애플리케이션, 개발 환경 및 배포 프로세스에 대해 가능한 한 많은 문서를 수집하거나 생성합니다.
• 제품의 내부와 외부를 파악하십시오.
• 애플리케이션의 모든 타사 서비스 및 종속성을 제어하고 모든 것에 대한 사용자 이름과 비밀번호를 보유하십시오.
• 새로운 팀이 시작하고 실행하는 데 필요한 모든 것에 액세스할 수 있도록 준비하십시오.
• 능동적으로 행동하고 어떤 것도 우연이나 나가는 개발 팀에 맡기지 마십시오.