2배 빠른 기능 출시를 시작한 방법(사례 연구)

기업이 일상 업무를 앱에 의존하는 경우 기업의 요구 사항을 신속하게 해결할 수 있을 만큼 민첩해야 합니다. 당신이하지 않으면 다른 사람들은 분명히 할 것입니다. 용서할 수 없는 SaaS의 세계에서 중요한 기능을 지연(또는 버그가 많은 코드 조각을 서두르는 것)은 클라이언트를 잃는 것을 의미합니다. 견고한 애자일 워크플로 는 모든 차이를 만들 수 있습니다.

우리는 계속해서 성장하는 기능 세트와 상당한 사용자 기반을 갖춘 프로젝트 관리 앱인 Active Collab 을 지원하는 팀입니다. 이것은 기능의 가장 작은 변경조차도 많은 사람들에게 영향을 미친다는 것을 의미합니다.

SmashingMag에 대한 추가 정보:

• 충성도 높은 사용자에게 피해를 주지 않고 새로운 기능을 출시하는 방법
• 웹사이트 시작 체크리스트 – 라이브를 시작하기 전 15가지 필수 체크 사항
• 모바일 장치용 웹 디자인에 대한 사용자 중심 접근 방식
• 무엇이든 시작하는 방법
  

따라서 개발 프로세스는 지연을 최소화하면서 원활하게 표준에 맞게 실행해야 합니다. 변경 사항이 최종 사용자에게 전달되기 전에 피드백, 디자인, 개발, 품질 보증 및 배포라는 5가지 중요한 단계를 거칩니다. 이 기사에서는 8년이 넘는 기간 동안 비즈니스에서 각 단계에 대해 배운 내용(어려운 방법)을 공유합니다.

모닝콜

세부 사항에 들어가기 전에 이 모든 것이 어떻게 되었는지 살펴보겠습니다. 충분한 조사 없이 몇 년 동안 기능을 추가한 후, 우리 앱은 기능 팽창으로 고통받았습니다. 우리는 수년 동안 너무 많은 기능을 추가하여 새로운 사용자가 UI의 복잡성에 겁을 먹었습니다(다시는 돌아오지 않음). 모든 단일 기능을 처음부터 다시 작성해야 하는 경우에도 처음부터 다시 빌드해야 한다는 것을 알고 있었습니다.

그런 다음 지연이 발생했습니다. 새 버전의 기능은 일정보다 지속적으로 뒤쳐져 있었습니다. 예를 들어, 주니어 개발자는 QuickBooks와의 통합을 개발해야 했습니다. 필요한 복잡성, 기술 또는 지식을 정확하게 예측하지 못했습니다. 게다가 그는 그 임무를 맡은 유일한 사람이었고 아무도 그를 빨리 도와줄 수 없었습니다. 결과적으로 2주 작업이 5주가 소요되었습니다. 몇 가지 적신호였습니다.

보다 민첩한 접근 방식으로 전환해야 할 때가 되었습니다. 우리는 다양한 애자일(그리고 그다지 애자일이 아닌) 방법에서 우리가 좋아하는 것을 가져와서 경험과 결합하여 자체 버전을 내놓았습니다.

기능이 최종 사용자에게 제공되기 전에 이동해야 하는 경로를 자세히 살펴보겠습니다.

제안에서 기능으로

우리의 워크플로에서 새로운 기능은 개발 팀에 도달하기 훨씬 전에 형태를 갖추기 시작하며 일반적으로 사용자 피드백에서 시작됩니다. 이것은 우연이 아닙니다. 우리는 일반적으로 한 명의 사용자가 특히 시끄럽거나 단순히 뭔가 있으면 좋을 것이라고 생각했기 때문에 아무 필요도 없는 기능을 출시했습니다. 사용자에게 어떤 기능이 필요할지 상상하는 대신 이제 실제 수요에 따라 결정을 내립니다.

린 제조 방식을 사용하는 경우 고객이 특정 기능을 다른 기능보다 더 자주 요청하여 특정 기능을 "가져온다" 고 말할 것입니다. 우리의 지원 및 영업 팀은 그들의 요구와 아이디어를 공유하는 사용자와 지속적으로 연락하기 때문에 프로세스의 큰 부분입니다.

피드백을 기반으로 우리 팀은 다음과 같은 양식을 업데이트합니다.

필요한 정보가 모두 없는 경우 고객에게 직접 연락합니다. 이것은 일반적으로 신중하게 선택한 샘플에 대한 대상 설문 조사로 수행됩니다. 요점은 우리가 듣는 것입니다. 피드백은 손실되지 않습니다. 항상 인정되고 문서화됩니다.

다음 단계는 분석입니다. 매달 점수를 집계하여 어떤 기능이 가장 많은 표를 얻었는지 확인합니다. 또한 적절한 분류를 통해 소프트웨어의 어떤 부분이 작업해야 하는지에 대한 더 넓은 관점을 얻을 수 있습니다. 예를 들어 캘린더에 불만이 많은 경우 가장 많은 표를 얻은 기능(예: 캘린더 내보내기)을 도입하는 대신 전체 섹션을 개편하는 것을 고려할 것입니다.

그러나 결과가 나왔더라도 기능 도입에 대한 결정은 최종적인 것이 아닙니다. 우리의 할 일 목록에 올리기 전에 우리는 항상 철저한 온전한 검사를 합니다.

• 이 기능은 사용자에게 어떤 이점을 제공합니까?
• 우리 제품 철학에 부합합니까?
• 불필요한 복잡성을 추가합니까?
• 기존 인터페이스 및 기능과 잘 어울리나요?
• 합리적인 시간 내에 이를 제공할 수 있는 리소스가 있습니까?

기능이 체크리스트를 통과하고 제품 소유자가 이를 승인하면 드로잉 보드로 이동할 차례입니다.

사용자를 위한 디자인

경험을 통해 우리는 새로운 기능을 추가하는 것이 단순히 UI 위에 추가하는 것이 아니라 사용자를 염두에 두고 기존 디자인과 혼합해야 한다는 것을 배웠습니다. 이렇게 하지 않으면 곧 너무 복잡한 앱을 갖게 되어 용감한 소수만이 시험판의 처음 5분을 통과할 것입니다(예, 우리는 거기에 있었습니다). 좋은 첫인상을 위해서는 미학도 중요하지만 우리의 주된 관심사는 사용의 용이성입니다 . 기능은 사용자에게 자연스럽게 느껴지는 방식으로 추가되어야 합니다.

우리는 사용자가 이 옵션을 어디에서 기대할까요?

기존 사용자의 경우 새 디자인이 익숙한 패턴을 따르고 워크플로를 방해하지 않는 것이 중요합니다. 또한 우리 모두에게 (무의식적으로) 익숙한 산업 표준과 관습이 있습니다. 사용자가 습관을 완전히 바꿀 것이라고 기대하지 마십시오. 인터페이스가 직관적이지 않으면 다른 곳을 찾을 가능성이 더 큽니다.

키보드 단축키를 사용하십시오. 자신만의 단축키 세트를 만들고 사용자가 배우기를 기대할 수 있습니다(아마 배우지 않을 것입니다). 또는 사람들이 이미 사용하고 있는 것을 추가할 수 있습니다. 예를 들어 많은 사용자가 이미 Slack을 사용하고 있으므로 이미 익숙한 바로 가기를 추가했습니다(빠른 점프를 위한 Command + K 는 Active Collab 에서도 작동함).

사용자 흐름이 제자리에 있으면 UX 디자이너가 Sketch에서 디자인을 조롱합니다. 초기 단계에서는 HTML을 거의 사용하지 않습니다. 세심하게 고려된 스케치 시각화는 코딩을 시작할 때 역추적할 필요가 없는 충분한 유연성을 제공합니다. 초기 디자인은 일반적으로 최종 제품의 약 80%와 일치하게 됩니다. 나머지는 도중에 추가 및 조정됩니다.

디자인 프로세스의 또 다른 중요한 단계는 복사입니다. 우리 카피라이터는 단어 하나하나에 많은 관심을 기울입니다. 우리는 접근하기 쉽게 들리고 최대한 이해하기 쉽도록 우리만의 스타일 가이드를 가지고 있습니다. 예를 들어, "SSL 인증서" 대신 "보안 인증서"라고 말하면 일반 사용자에게는 익숙하지 않을 수 있는 내용을 일반 사용자의 용어로 전달합니다.

이 모든 작업이 완료되면 기능이 개발 팀에 할당됩니다. 팀은 워크로드에 따라 프로젝트 관리자, 리드 개발자, 여러 백엔드 및 프론트 엔드 개발자로 구성됩니다. 프로젝트 관리자는 모든 것이 순조롭게 일정대로 실행되는지 확인하고 수석 개발자는 기술적인 부분을 처리합니다. 또한 주니어 개발자를 조정하고 멘토링합니다.

일을 시작할 시간

시작 회의는 지루한 동기 부여 모임이 아닙니다. 개발 팀(주니어 및 시니어 개발자로 구성)이 프로젝트 관리자 및 제품 소유자를 만날 수 있는 기회입니다.

공허한 독백을 허용하는 대신 모든 사람의 말을 실행 가능한 작업에 넣는 데 중점을 둡니다. 하루 종일 세 가지 중요한 회의 가 열립니다.

• 제품 소유자는 주어진 기능, 그 이면의 아이디어, 초기 설계 및 예상 결과를 팀에 제공합니다.
• 그런 다음 팀은 실행 계획, 잠재적 문제 및 테스트 일정에 대해 논의하는 자체 회의를 갖습니다.
• 최종 회의에는 관련된 모든 사람이 참석하고 계획이 최종 형태를 취합니다. 이 회의가 끝나면 팀은 데모 및 최종 마감일에 대한 견적을 제공합니다.

하루에 세 번의 회의가 많은 것처럼 들릴 수 있지만 이를 통해 문제를 조기에 해결합니다. 이 단계에서 공백을 채우면 개발자가 많은 시간, 잘못된 시작 및 역추적을 절약할 수 있습니다. 회의는 또한 팀워크를 장려하고 모든 사람이 자신의 기여를 환영한다고 느끼게 합니다.

회의 후 팀은 필요한 모든 정보를 갖게 됩니다.

1. 뭐라고 요? 이것은 기능의 범위이며 수행해야 하는 모든 것뿐만 아니라 잠재적인 차단 및 병목 현상을 포함합니다. 우리는 가능한 한 많은 시나리오와 극단적인 경우를 예상하려고 노력합니다. 그들 모두를 예측하는 것은 쉽지 않습니다. 그들은 우리가 갈 때 종종 올라옵니다.
2. 왜요? 제품 소유자는 기능의 비즈니스 가치 를 추정하고 노력할 가치가 있는 이유를 설명합니다. 이러한 방식으로 팀은 고객과 제품에 대한 이점을 명확하게 파악할 수 있습니다. 여기에서 가장 중요한 동기는 모든 사람이 자신의 일이 왜 중요한지, 그리고 그것이 회사 전체에 어떻게 기여하는지 이해해야 한다는 것입니다.
3. 어떻게? 기능을 완료하는 데 필요한 단계 를 설명하여 개발자가 나침반을 잃지 않도록 합니다. 또한 복잡성 태그를 추가하여 현실적인 기대치를 설정했습니다. 우리는 티셔츠 크기를 선택했습니다. S는 몇 시간 안에 해결할 수 있지만 XXL은 완료하는 데 몇 주 이상이 걸립니다.
4. 누구? 팀 리더는 기능이나 작업을 정시에 완료하고 진행 상황에 대해 제품 소유자를 업데이트할 책임이 있습니다. 다른 팀 구성원은 자신의 하위 작업 집합에 할당되므로 누가 무엇에 책임이 있는지 완벽하게 알 수 있습니다. 이를 가능한 한 투명하게 유지하면 누군가 어려움을 겪고 있거나 지연을 일으키는지 여부를 확인하는 데 도움이 됩니다.
5. 언제? 모든 것을 고려하여 기한이 추정 됩니다. 작업이 지연되면 원인을 분석하고 그 경험을 다음에 사용합니다. 그렇게 하면 기한을 놓친 것이 스트레스의 원인이 아니라 학습 기회가 됩니다.

시작하는 날은 바쁠 수 있지만 매우 유익합니다. 모두가 아이디어와 의견을 제시합니다. 작업은 주석, 편집 및 업데이트를 위한 허브로 비어 있습니다. 하루가 끝날 무렵, 개발 팀은 앞으로의 작업에 대한 명확한 그림과 구축할 견고한 기반을 갖게 됩니다.

작업을 시작하기 전에 다음 체크리스트를 살펴봅니다.

• 기능 설명,
• 완료 단계 설명,
• 제품 소유자가 할당한 비즈니스 가치,
• 팀에서 할당한 복잡성,
• 식별된 기능 및 버그 종속성,
• 식별된 성능 기준(필요한 경우),
• 예정된 데모,
• 팀 리더가 설정한 시작 및 종료 날짜.

작업이 "진행 중" 열로 이동하는 순간입니다.

코딩 타임이다!

디스플레이에 팀워크

우리 개발자들은 결코 혼자 작업하지 않습니다. 항상 팀이 노력하며, 새로운 기능을 출시하는 가장 효율적인 방법입니다. 팀이 도입되기 전에 (하위) 개발자는 문제에 봉착하여 며칠 동안 (아무도 깨닫지 못한 채) 빙글빙글 돌았을 것입니다. 또는 외로운 레인저 유형이 아니었다면 계속해서 동료와 관리자의 주의를 산만하게 했을 것입니다.

반면에 팀에서는 다양한 기술과 경험 수준을 가진 사람들을 혼합합니다. 이것은 모든 사람에게 자신의 수준에 적합한 일련의 작업이 할당되었음을 의미합니다. 또한, 선배들은 후배 팀원들을 관리하고 코칭하는 방법을 배울 수 있는 혜택을 받고 후배들은 도움을 요청할 수 있습니다. 그것은 팀의 노력이고 모두가 같은 목표를 향해 노력하고 있기 때문에 질문은 주의를 산만하게 하는 것으로 간주되지 않으며 팀은 모든 문제를 훨씬 더 효율적으로 해결할 수 있습니다. 팀은 자체 조직화 엔티티가 되어 작업을 단계(또는 스프린트)로 나누고 데모 중에 작업을 발표합니다.

보여주고 말해

일정에 따라 팀은 제품 소유자를 위해 시연할 것입니다. 데모의 목적은 기능이 현재 상태에서 얼마나 잘 수행되고 있으며 더 다듬어야 할 부분을 보여주는 것입니다. "몇 가지 마무리 작업이 필요합니다"(한 달 더 걸릴 작업)와 같은 변명을 허용하지 않는 현실 확인입니다. 또한 상황이 잘못되기 시작하면 제품 소유자가 신속하게 대응해야 합니다.

주간 회의

우리는 모든 개발자가 참석하는 정기적인 짧은 일일 회의로 시작했습니다. 각 개발자는 작업 중인 내용, 문제, 차단 요소 및 도움이 필요한지 여부를 간략하게 설명합니다. 이러한 회의가 더 집중되고 가시적인 결과를 제공해야 한다는 것이 곧 명백해졌습니다. 그래서 일주일에 한 번 정도 개별 팀과 회의를 하는 것으로 바꿨습니다. 이것이 제품 소유자와 프로젝트 관리자가 루프를 유지하고 모든 잠재적인 문제가 그 자리에서 처리되는 방식입니다.

테스트하기

코드가 작성되고 데모가 성공적으로 완료되었으며 모든 것이 멋지게 마무리된 것 같습니다... 기능을 릴리스하고 앱이 충돌하는 것을 볼 때까지. 그렇기 때문에 우리가 만드는 모든 기능은 품질 보증 (Q/A)을 거칩니다. 언제나. 우리 테스터는 가능한 모든 시나리오를 세심하게 살펴보고 모든 옵션을 확인하고 다양한 환경에서 테스트를 실행합니다. 기능이 처음에 Q/A를 통과하는 경우는 거의 없습니다.

생산성을 높이기 위해 이 단계에서 개발자가 새로운 기능을 시작할 수 있도록 했습니다. 그래서 이제 개발팀은 기능을 검토하는 동안 작은 유지 관리 작업으로 바쁘게 움직입니다. Q/A에서 문제가 발견되면 개발자는 즉시 수정하여 다시 제출합니다. 기능이 Q/A를 통과하고 코드 검토로 넘어갈 때까지 프로세스가 반복됩니다.

이것은 시니어 개발자가 코드가 우리 표준에 따라 작성되었는지 확인하는 때입니다. 릴리스 전 마지막 단계는 문서를 작성하는 것입니다. 아무도 사용법을 모르는 기능을 릴리스한 후 지원 이메일에 휩쓸리고 싶지 않을 것입니다. 또한 당사 카피라이터는 릴리스 정보를 업데이트하고 이메일 공지 및 블로그 게시물과 같은 마케팅 자료를 작성합니다.

"완료"에 대한 정의는 다음과 같습니다.

• 자동 테스트 작성,
• Q/A 완료 및 모든 결과 작업 완료,
• 코드 검토가 완료되고 코드가 마스터에 병합되었습니다.
• 릴리스 정보가 업데이트되었습니다.
• 기능 및 버그 종속성이 식별되었습니다.

작업은 "릴리스 Q"라는 최종 단계에 도달했습니다.

출시일

새로운 릴리스 날짜를 선택할 때 우리는 즉시 금요일과 월요일을 선택했습니다. 금요일은 잠재적인 문제가 월요일까지 해결되지 않기 때문에 좋지 않습니다. 게다가 지원 팀은 그 당시 이미 꽤 바빴습니다. 모든 주요 업데이트는 주말에 완료해야 하는 준비가 필요하기 때문에 월요일은 최적의 시간이 아닙니다. 최종 수정을 위해 하루를 남겨두는 것이 항상 좋습니다. 이것은 옵션을 3일로 좁히고 우리는 화요일을 선택했습니다. 이유는 다음과 같습니다.

• 월요일에 릴리스를 검토하고 배포하기 전에 마무리 작업을 추가해야 합니다.
• 번역되지 않은 문구가 있는 경우(저희 웹 앱은 7개 언어로 제공됨) 번역을 완료할 수 있는 충분한 시간이 있습니다.
• 마케팅 팀은 소셜 미디어를 통해 뉴스레터와 공지 사항을 보낼 수 있는 충분한 시간이 있습니다.
• 남은 주 동안 빠르고 효율적으로 업그레이드 지원을 제공할 수 있습니다.
• 어떤 이유로든 마감일이 지났더라도 수요일이나 목요일에 작업을 완료할 수 있습니다.

자유 활동의 날

주요 릴리스 다음 날은 팀의 무료 날입니다. 이것은 그들이 새로운 기술을 배우거나 흥미롭다고 생각하는 업무와 관련된 모든 일을 할 때입니다. 모두가 우리가 다음 날 어떤 기능을 시작할지 알고 싶어하지만 팀에서는 아직 그것에 대해 논의하지 않습니다. 대신 그들은 긴장을 풀고 Erlang의 역사에 대한 프레젠테이션을 보거나 PSR-7과 미들웨어가 현대 PHP 개발에 중요한 이유에 대한 기사를 읽거나 회고적인 토론을 할 것입니다. 배터리를 재충전하고 잘한 일을 축하하기에 좋은 날입니다.

버그 헌트의 날

주요 새 기능을 개발하는 것 외에도 항상 기존 기능에 대해 수행해야 할 작업이 있습니다. 버그 수정이든, 디자인 업데이트이든, 기능의 작은 변경이든, 팀은 합리적인 시간에 이를 처리해야 합니다.

이것이 우리가 적어도 한 달에 한 번 버그 헌팅의 날을 갖는 이유입니다. 모든 개발자가 주요 프로젝트 작업을 중단하고 유지 관리에 관심을 돌릴 때입니다. 이러한 집중적인 노력은 대성공으로 입증되었습니다. 모든 사람이 같은 날 버그에 대해서만 작업하고 서로를 도울 수 있을 때 팀은 수많은 문제를 해결합니다.

결과는 무엇입니까?

이제 큰 기능을 릴리스하는 데 시작부터 개발, 테스트, 코드 검토, 문서화 및 최종 릴리스까지 평균 약 3주가 소요됩니다. 45일이 소요되는 데 사용되는 동일한 복잡성의 기능입니다. 우리의 관점에서는 생산성이 100% 증가 합니다. 우리는 동일한 리소스와 인력으로 이를 달성했으며 유일한 차이점은 개선된 워크플로입니다.

따라서 한 가지 유의할 점은 다음과 같습니다. 변화에 대한 두려움을 없애는 기업 문화를 육성하면 팀이 하는 일을 더 잘할 수 있습니다. 회사 성장에 도움이 되는 한 스크럼, 칸반 또는 린(Lean)이라고 하는 것은 중요하지 않습니다. 실험과 혁신은 애자일 접근 방식의 핵심입니다. 다른 솔루션을 테스트하고, 결과를 측정하고, 결과에 따라 기존 방식을 수정하는 것을 두려워하지 마십시오. 좋은 결과가 따를 것입니다.