더 나은 해커톤 구축: LiveOps Hack Day의 XNUMX가지 핵심 원칙
Keith McFarlane, 수석 설계자 Keith McFarlane, 수석 설계자

우리는 최근 24번째 LiveOps Hack Day 행사를 열었는데, 그것은 뭔가 특별했습니다. 매우 열정적이고 헌신적인 팀과 개인의 노력 덕분에 불과 XNUMX시간 만에 수많은 정말 흥미로운 아이디어가 실현되었습니다. 데모 시간에 표시된 몇 가지 해킹은 다음과 같습니다.

  • Pivot to Video – 이 팀은 다음을 사용하여 실시간 상담원 채팅 대화를 비디오 세계로 옮기는 방법을 찾았습니다. 톡박스.
  • 다중 채널 시각화 – 보고 팀은 여러 작업 항목을 동시에 처리하면서 상담원이 처리하는 겹치는 작업 스트림을 보는 새로운 방법을 제시했습니다.
  • Agent Telephony in-Browser – 엔지니어는 에이전트 폰 패널 애플리케이션과 Twilio의 자바스크립트 기반 클라이언트로 PC만으로 음성통화가 가능합니다.
  • Scriptable Callflow – 일부 플랫폼 엔지니어는 REST API를 통해 세분화된 전화 통신 기능을 제어하는 ​​매끄러운 방법을 찾았습니다.
이것은 이번에 완료된 프로젝트의 일부일 뿐입니다. 이것들과 다른 것들은 그리 멀지 않은 미래에 제품이 될 수 있습니다.

우리는 첫 번째 이벤트를 개최한 이후 수년 동안 Hack Day를 개선하기 위해 노력해 왔으며 많은 점증적 변경을 수행하는 동안 얼마나 밀접하게 준수하느냐에 따라 이벤트를 성사시킬 수 있는 일련의 핵심 원칙도 확인했습니다.

1) 훌륭한 해킹은 백로그가 아니라 마음에서 나온다

엔지니어나 제품 관리자가 자신이 좋아하는 백로그 항목을 가속화하기 위한 핑계로 Hack Day를 사용하려는 경우를 너무나 자주 보았습니다. 이것은 확실히 유용한 것을 성취하지만 이벤트의 진정한 목적인 혁신을 무산시킵니다. 개발자는 이 시간을 사용하여 가장 거친 소프트웨어 꿈을 추구하고 새로운 기술을 시도해야 합니다. 제품 관리자도 마찬가지입니다. 그들은 개발자와 팀을 이루어 예상치 못한 방식으로 다른 웹 서비스와 통합하거나 정상적인 상황에서 위험해 보이는 아이디어를 정의하고 구현하려고 시도해야 합니다. 약간 다른 순서로 진행되는 비즈니스가 아니라 탐색의 기회가 되어야 합니다.

개발자의 경우 해킹 데이 프로젝트로 백로그 항목을 선택하는 것은 본질적으로 제품 관리 팀의 우선 순위를 무시하는 것입니다. 스크럼에 맞는 스토리 순서를 정하기 위해 들인 모든 생각과 토론을 생각해 보십시오. 그런 다음 모든 작업을 무시하고 무작위로 스토리를 선택한다고 상상해 보십시오. 분명히 전자가 후자보다 바람직합니다.

Hack Day는 예상치 못한 곳에서 훌륭한 아이디어가 나올 수 있도록 하는 것입니다. 기존 아이디어보다 새로운 아이디어를 추구하는 데 중점을 두지 않으면 대부분의 가치를 잃게 됩니다.

2) 집중, 집중, 집중; 스코프 크리프는 핵을 죽입니다.

모든 새로운 아이디어는 해킹 데이에 공정한 게임이 되어야 하지만, 가장 큰 성공은 사소하지만 가치 있는 기능을 완성하거나 다음과 같은 잘 정의된 예를 통해 큰 개념을 보여주는 것을 목표로 하는 작고 집중적인 노력에서 나온다는 것을 알게 되었습니다. 범위가 제한적입니다. 종종 이와 같은 프로젝트는 초기에 성공을 거둔 다음 시간이 허락하는 대로 기능을 추가할 수 있습니다. 또한 승리 조건이 잘 정의되어 있기 때문에 팀은 해킹이 너무 복잡하다고 판명되면 해킹을 포기하고 다른 아이디어로 초점을 옮길 수 있습니다.

모든 개발자는 머릿속에 떠다니는 "큰 개념"을 가지고 있습니다. 불행하게도 이들은 Hack Day의 일환으로 제한된 형태로도 구축하기 가장 어려울 수 있습니다. 해킹 형태로 이러한 거대한 계획 중 하나를 성공적으로 추구하고 싶다면 더 많은 사람들을 토론에 끌어들이고 그 자체로 잘 서 있지만 여전히 요점을 전달하는 작은 퍼즐 조각을 찾으십시오.

3) 때로는 해킹을 만드는 데 온 마을이 필요합니다.

특정 핵은 매우 명확하게 정의되고 범위가 제한되어 단일 개발자가 제 시간에 수행할 수 있습니다. 그러나 대부분의 웹 서비스가 복잡하기 때문에 진정으로 흥미로운 해킹에는 다양한 플랫폼에서 여러 주제 전문가의 노력이 필요하다는 것이 훨씬 더 일반적입니다.

본질적으로 해커톤은 사교 행사이며 혁신에 관한 것만큼이나 팀워크와 사기에 관한 것입니다. Hack Day 이벤트를 조직하는 경우 이벤트 자체 전에 팀 구성을 위한 포럼을 제공하십시오. 우리는 LiveOps에서 몇 년 동안 해킹 데이 사전 "모집" 회의를 개최하여 정상적인 프로젝트 작업 흐름 내에서 발생하지 않을 수 있는 팀 구성 조합을 생성하고 장기적으로 팀 간의 더 큰 상호 작용을 촉진했습니다.

4) 배포가 최고의 보상

예, 아이패드를 원하는 사람이라면 누구나 이미 아이패드를 가지고 있을지라도 일종의 가시적인 "최고의 해킹" 상품을 제공하는 것이 중요합니다. 그러나 모든 개발자가 프로덕션에서 기능으로 실행되는 자체 제품 아이디어를 가지고 있는 것은 아닙니다. 많은 엔지니어가 자신의 혁신적인 개념이 빛을 보지 못한 채 수년 동안 제품 관리자의 비전을 실현하기 위해 노력할 수 있습니다. 해킹이 제품으로서의 가능성을 보여주거나 즉시 사용할 수 있는 경우 회사의 이익과 관련된 엔지니어에 대한 보상으로 생산에 신속히 투입되어야 합니다.

모든 소프트웨어 회사(웹 스타트업뿐만 아니라)는 정기적인 해커톤을 개최하여 혁신을 불러일으키고, 동기를 부여하고, 팀 간의 커뮤니케이션 라인을 개선해야 합니다. 그러나 모든 회사 활동과 마찬가지로 이를 수행하는 데 더 효과적인 방법과 덜 효과적인 방법이 있습니다. 작동하는 것과 작동하지 않는 것을 추적하고, 시간이 지남에 따라 개선하고, 참가자 피드백을 경청하십시오. 위의 원칙은 LiveOps에서 매우 잘 작동했지만 시간이 지남에 따라 조직에 더 잘 작동하는 일련의 지침을 발전시킬 가능성이 높습니다.