Keith McFarlane, Chefarchitekt
Wir haben vor Kurzem unser elftes LiveOps Hack Day-Event abgehalten, und es war etwas Besonderes; Dank der Bemühungen einiger sehr leidenschaftlicher und engagierter Teams und Einzelpersonen wurden in nur 24 Stunden eine Reihe wirklich interessanter Ideen zum Leben erweckt. Einige der Hacks, die zur Demo-Zeit gezeigt wurden, waren:
- Pivot to Video – das an diesem Projekt beteiligte Team hat einen Weg gefunden, ein Live-Chat-Gespräch mit Agenten in die Welt der Videonutzung zu verlagern tokbox.
- Multichannel-Visualisierung – unser Reporting-Team präsentierte eine neue Möglichkeit, die sich überschneidenden Arbeitsströme zu betrachten, die ein Agent bearbeitet, während er gleichzeitig mehrere Arbeitselemente bearbeitet.
- Agenten-Telefonie im Browser – der Techniker zeigte die Integration unserer Agenten-Telefon-Panel-Anwendung mit Twilio's JavaScript-basierter Client, der Sprachanrufe allein über einen PC ermöglicht.
- Skriptfähiger Callflow – Einige unserer Plattformingenieure haben einen raffinierten Weg gefunden, um granulare Telefoniefunktionen über die REST-API zu steuern.
Wir haben im Laufe der Jahre seit der ersten Veranstaltung daran gearbeitet, den Hack Day zu verbessern, und obwohl wir viele inkrementelle Änderungen vorgenommen haben, haben wir auch eine Reihe von Grundprinzipien identifiziert, die die Veranstaltung über Erfolg oder Misserfolg entscheiden können, je nachdem, wie genau sie befolgt werden.
1) Großartige Hacks kommen von Herzen, nicht aus dem Rückstand
Allzu oft habe ich gesehen, wie Ingenieure oder Produktmanager versuchten, den Hack Day als Vorwand zu nutzen, um ihre bevorzugten Backlog-Elemente zu beschleunigen. Während dies sicherlich etwas Nützliches bewirkt, verfehlt es den wahren Zweck der Veranstaltung: Innovation. Entwickler sollten diese Zeit nutzen, um ihren wildesten Software-Träumen nachzugehen und neue Technologien auszuprobieren. Dasselbe gilt für Produktmanager; Sie sollten sich mit Entwicklern zusammentun, um auf unerwartete Weise in andere Webdienste zu integrieren oder einen Versuch zu unternehmen, eine Idee zu definieren und umzusetzen, die unter normalen Umständen riskant erscheinen würde. Es sollte eine Gelegenheit zur Erkundung sein, nicht wie gewohnt in einer etwas anderen Reihenfolge.
Für Entwickler bedeutet die Auswahl eines Backlog-Elements als Hack-Day-Projekt im Wesentlichen, die Prioritäten des Produktmanagementteams zu übersehen. Denken Sie an all die Gedanken und Diskussionen, die in die richtige Story-Reihenfolge für Ihr Scrum geflossen sind, und stellen Sie sich dann vor, all diese Arbeit zu ignorieren und Storys nach dem Zufallsprinzip auszuwählen. Ersteres ist letzterem eindeutig vorzuziehen.
Beim Hack Day geht es darum, großartige Ideen an unerwarteten Orten entstehen zu lassen. Ohne Betonung darauf, neue Ideen statt bestehender zu verfolgen, verliert es den größten Teil seines Wertes.
2) Fokus, Fokus, Fokus; Scope Creep tötet Hacks tot
Während jede neue Idee für den Hack-Tag ein faires Spiel sein sollte, habe ich festgestellt, dass die größten Erfolge von kleinen, konzentrierten Bemühungen kommen, die darauf abzielen, ein kleines, aber wertvolles Feature zu vervollständigen oder ein großes Konzept durch ein gut definiertes Beispiel zu demonstrieren im Umfang begrenzt. Projekte wie dieses können oft früh erfolgreich sein und dann Funktionen hinzufügen, wenn es die Zeit erlaubt. Da die Siegbedingungen genau definiert sind, kann das Team den Hack aufgeben, wenn er sich als zu komplex erweist, und sich auf eine andere Idee konzentrieren.
Alle Entwickler haben „große Konzepte“ im Kopf; Leider können diese im Rahmen des Hack Day am schwierigsten zu bauen sein, selbst in begrenzter Form. Wenn Sie eines dieser großen Pläne in Form eines Hacks erfolgreich verfolgen möchten, ziehen Sie mehr Leute in die Diskussion und finden Sie ein kleines Puzzleteil, das für sich allein steht, aber dennoch Ihren Standpunkt klar macht.
3) Manchmal braucht es ein ganzes Dorf, um einen Hack zu erstellen
Bestimmte Hacks sind so klar definiert und in ihrem Umfang begrenzt, dass ein einzelner Entwickler sie rechtzeitig umsetzen kann; So komplex die meisten Webservices auch sind, es ist weitaus üblicher, dass jeder wirklich interessante Hack die Bemühungen mehrerer Fachexperten auf verschiedenen Plattformen erfordert.
Im Kern sind Hackathons soziale Events, bei denen es genauso um Teambildung und Moral geht wie um Innovation. Wenn Sie eine Hack Day-Veranstaltung organisieren, stellen Sie vor der eigentlichen Veranstaltung ein Forum für die Teambildung bereit; Wir haben mehrere Jahre vor dem Hack-Day ein „Rekrutierungs“-Meeting bei LiveOps abgehalten, das Teambildungskombinationen hervorgebracht hat, die im normalen Ablauf der Projektarbeit möglicherweise nicht vorkommen, und auf lange Sicht eine stärkere Interaktion zwischen den Teams fördert.
4) Bereitstellung ist die beste Belohnung
Ja, es ist wichtig, einen greifbaren Preis für den „besten Hack“ anzubieten, obwohl wahrscheinlich jeder, der ein iPad haben möchte, bereits eines hat. Allerdings hat nicht jeder Entwickler eine eigene Produktidee, die als Feature in der Produktion läuft; Viele Ingenieure können jahrelang daran arbeiten, die Visionen von Produktmanagern zu ermöglichen, ohne dass eigene innovative Ideen das Licht der Welt erblicken. Wenn Hacks als Produkte vielversprechend sind oder wenn sie sofort verwendbar sind, sollten sie zum Wohle des Unternehmens und als Belohnung für die beteiligten Ingenieure schnell in die Produktion gebracht werden.
Jedes Softwareunternehmen (nicht nur Web-Startups) sollte regelmäßige Hackathons veranstalten, um Innovationen hervorzurufen, die Motivation zu steigern und die Kommunikationswege zwischen Teams zu verbessern. Wie bei jeder Unternehmensaktivität gibt es jedoch effektivere und weniger effektive Vorgehensweisen. Verfolgen Sie, was funktioniert und was nicht, nehmen Sie im Laufe der Zeit Verbesserungen vor und hören Sie sich das Feedback der Teilnehmer an. Obwohl die oben genannten Prinzipien für uns bei LiveOps sehr gut funktioniert haben, werden Sie höchstwahrscheinlich eine Reihe von Richtlinien entwickeln, die im Laufe der Zeit für Ihre Organisation besser funktionieren.
