Keith McFarlane, architecte en chef
Nous avons récemment organisé notre onzième événement LiveOps Hack Day, et c'était quelque chose de spécial ; un certain nombre d'idées vraiment intéressantes ont vu le jour en seulement 24 heures grâce aux efforts d'équipes et d'individus très passionnés et dévoués. Quelques-uns des hacks montrés au moment de la démo étaient :
- Pivot vers la vidéo - l'équipe impliquée dans celui-ci a trouvé un moyen de déplacer une conversation de chat en direct avec un agent dans le monde de la vidéo en utilisant tokbox.
- Visualisation multicanal - notre équipe de reporting a présenté une nouvelle façon d'examiner les flux de travail qui se chevauchent qu'un agent gère tout en traitant simultanément plusieurs éléments de travail.
- Agent Telephony in-Browser - l'ingénieur a montré l'intégration de notre application de panneau téléphonique d'agent avec TwilioClient basé sur JavaScript de , permettant des appels vocaux à l'aide d'un PC seul.
- Flux d'appels scriptable - certains de nos ingénieurs de plate-forme ont trouvé un moyen astucieux de contrôler les fonctions de téléphonie granulaires via l'API REST.
Nous avons travaillé pour améliorer le Hack Day au fil des ans depuis que nous avons organisé le premier événement, et bien que nous ayons apporté de nombreux changements progressifs, nous avons également identifié un ensemble de principes fondamentaux qui peuvent faire ou défaire l'événement en fonction de leur degré de suivi.
1) Les bons hacks viennent du cœur, pas du backlog
Trop souvent, j'ai vu des ingénieurs ou des chefs de produit essayer d'utiliser Hack Day comme excuse pour accélérer leurs éléments de backlog préférés. Bien que cela accomplisse certainement quelque chose d'utile, cela va à l'encontre du véritable objectif de l'événement : l'innovation. Les développeurs devraient utiliser ce temps pour poursuivre leurs rêves logiciels les plus fous et essayer de nouvelles technologies. Il en va de même pour les chefs de produit ; ils doivent faire équipe avec des développeurs pour s'intégrer à d'autres services Web de manière inattendue, ou pour tenter de définir et de mettre en œuvre une idée qui semblerait risquée dans des circonstances normales. Ce devrait être une opportunité d'exploration, pas comme d'habitude dans un ordre légèrement différent.
Pour les développeurs, choisir un élément du backlog dans le cadre de votre projet de journée de piratage revient essentiellement à faire un pied de nez aux priorités de l'équipe de gestion des produits. Pensez à toutes les réflexions et discussions qui ont été nécessaires pour obtenir le bon ordre d'histoire pour votre mêlée, puis imaginez ignorer tout ce travail et sélectionner des histoires au hasard. Il est clair que le premier est préférable au second.
Hack Day consiste à permettre à de grandes idées d'émerger d'endroits inattendus. Si l'accent n'est pas mis sur la poursuite d'idées nouvelles plutôt que sur celles existantes, il perd la majeure partie de sa valeur.
2) Concentrez-vous, concentrez-vous, concentrez-vous ; portée fluage tue hacks morts
Alors que toute nouvelle idée devrait être un jeu équitable pour le jour du hack, j'ai remarqué que les plus grands succès proviennent de petits efforts ciblés qui visent à compléter une fonctionnalité mineure mais précieuse, ou à démontrer un grand concept à travers un exemple bien défini qui est portée limitée. Souvent, des projets comme celui-ci peuvent réussir tôt, puis ajouter des fonctionnalités au fur et à mesure que le temps le permet. De plus, comme les conditions de victoire sont bien définies, l'équipe peut abandonner le hack s'il s'avère trop complexe et se concentrer sur une autre idée.
Tous les développeurs ont de « grands concepts » flottant dans leur tête ; malheureusement, ceux-ci peuvent être les plus difficiles à construire, même sous une forme limitée, dans le cadre du Hack Day. Si vous voulez poursuivre avec succès l'un de ces grands projets sous forme de hack, attirez plus de gens dans la discussion et trouvez un petit morceau du puzzle qui se suffit à lui-même, mais qui fait quand même passer votre message.
3) Parfois, il faut un village pour créer un hack
Certains hacks sont si clairement définis et limités dans leur portée qu'un seul développeur peut les réaliser à temps ; Cependant, aussi complexes que soient la plupart des services Web, il est beaucoup plus courant que tout hack vraiment intéressant nécessite les efforts de plusieurs experts en la matière sur un certain nombre de plates-formes différentes.
Au fond, les hackathons sont des événements sociaux, et ils concernent autant l'esprit d'équipe et le moral que l'innovation. Si vous organisez un événement Hack Day, fournissez un forum pour la formation de l'équipe avant l'événement lui-même ; nous avons organisé une réunion de « recrutement » pré-Hack-Day pendant plusieurs années chez LiveOps, ce qui a permis d'obtenir des combinaisons d'équipe qui pourraient ne pas se produire dans le flux normal de travail de projet et de favoriser de plus grandes interactions entre les équipes sur le long terme.
4) Le déploiement est la meilleure récompense
Oui, il est important d'offrir une sorte de prix tangible du "meilleur hack", bien que tous ceux qui veulent un iPad en aient probablement déjà un. Cependant, tous les développeurs n'ont pas leur propre idée de produit en cours d'exécution en tant que fonctionnalité en production ; de nombreux ingénieurs peuvent travailler à concrétiser les visions des chefs de produit pendant des années sans que leurs propres notions innovantes ne voient le jour. Si les hacks s'avèrent prometteurs en tant que produits, ou s'ils sont immédiatement utilisables, ils devraient être accélérés en production à la fois pour le bien de l'entreprise et comme récompense pour les ingénieurs impliqués.
Chaque entreprise de logiciels (pas seulement les startups Web) devrait organiser régulièrement des hackathons pour favoriser l'innovation, accroître la motivation et améliorer les voies de communication entre les équipes. Cependant, comme pour toute activité d'entreprise, il existe des moyens plus efficaces et moins efficaces de s'y prendre. Gardez une trace de ce qui fonctionne et ne fonctionne pas, apportez des améliorations au fil du temps et écoutez les commentaires des participants. Bien que les principes ci-dessus aient très bien fonctionné pour nous chez LiveOps, vous développerez très probablement un ensemble de directives qui fonctionneront mieux pour votre organisation au fil du temps.
