À quel type de groupe participez-vous habituellement aux hackathons ? Initialement, nous avons indiqué que l'équipe idéale était composée de cinq personnes : un manager, deux programmeurs, un concepteur et un spécialiste du marketing. Mais l'expérience de nos finalistes a montré qu'on peut gagner un hackathon avec une petite équipe de trois personnes. Sur les 26 équipes qui ont remporté la finale, 3 ont concouru et ont gagné avec des mousquetaires. Comment ils l'ont fait - lisez la suite.
Nous avons discuté avec les capitaines des trois équipes et avons réalisé que leur stratégie avait beaucoup en commun. Les héros de cet article sont les équipes PLEXeT (Stavropol, nomination du ministère des Télécommunications et des Communications), « Composite Key » (Tula, nomination du ministère de l'Information et des Communications de la République du Tatarstan) et Jingu Digital (Ekaterinbourg, nomination du Ministère de l'Industrie et du Commerce). Pour ceux que ça intéresse, une brève description des commandes est cachée sous le chat.
Description des commandesPLEXeT
L'équipe est composée de trois personnes : un développeur (web, C++, compétences en sécurité de l'information), un concepteur et un manager. Nous ne nous connaissions pas avant le hackathon régional. L'équipe a été constituée par le capitaine sur la base des résultats des tests en ligne.
Clé composée
L'équipe compte trois collègues développeurs : fullstack avec dix ans d'expérience dans l'informatique, le backend et le mobile, et backend axé sur les bases de données.
Jingu numérique
L'équipe est composée de deux programmeurs - backend et AR/Unity, ainsi que d'un designer qui était également responsable de la gestion de l'équipe. Gagné dans la nomination du ministère de l'Industrie et du Commerce
Choisissez une tâche proche de vos compétences
Vous souvenez-vous qu'il y avait une telle rime « club de théâtre, club photo, et je veux aussi chanter » ? Je pense que beaucoup de gens connaissent ce sentiment : quand tout autour de vous est intéressant, vous voulez vous montrer d'une nouvelle manière dans votre direction et essayer une nouvelle industrie/un nouveau domaine de développement. Le choix ici dépend uniquement des objectifs de votre équipe et de votre volonté de prendre des risques - pouvez-vous accepter votre erreur si soudainement, au milieu du hackathon, vous réalisez qu'il est irréaliste de résoudre ce problème ? Les expériences du type « Je ne suis pas doué en développement mobile, mais qu'est-ce que c'est ? » ne conviennent pas à tout le monde. Êtes-vous du genre amateur ?
Artem Koshko (), commande « Clé composite »: « Au départ, nous avions prévu d’essayer quelque chose de nouveau. Au niveau régional, nous avons essayé plusieurs packages Nuget, auxquels nous n'avons jamais eu accès, ainsi que Yandex.Cloud. À la fin, nous avons déployé CockroachDB dans Kubernetes et essayé d'y effectuer des migrations à l'aide d'EF Core. Certaines choses se sont bien passées, d’autres moins. Nous avons donc appris de nouvelles choses, nous sommes testés et nous sommes assurés de la fiabilité des approches éprouvées..
Comment choisir une tâche si vos yeux s'égarent :
- Réfléchissez aux compétences nécessaires pour résoudre ce cas et si tous les membres de l'équipe les possèdent.
- Si vous manquez de compétences, pouvez-vous les compenser (proposer une autre solution, apprendre rapidement quelque chose de nouveau)
- Effectuer une brève recherche du marché pour lequel vous allez fabriquer un produit
- Calculez la concurrence : à quelle piste/entreprise/tâche le plus de gens iront-ils ?
- Répondez à la question : qu’est-ce qui vous motivera le plus ?
Oleg Bakhtadze-Karnaukhov (), commande PLEXeT: «Nous avons pris la décision d'une escale de dix heures à l'aéroport - juste au moment de l'atterrissage, une liste de pistes et de brefs énoncés de tâches sont arrivés dans notre courrier. J'ai immédiatement identifié quatre tâches qui m'intéressaient en tant que programmeur et pour lesquelles le plan d'action après le démarrage était clair - ce qui devait être fait et comment nous le ferions. Ensuite, j'ai évalué les tâches de chaque membre de l'équipe et évalué le niveau de compétition. En conséquence, nous avons choisi entre les tâches de Gazprom et celles du ministère des Télécommunications et des Communications de masse. Le père de notre designer travaille dans le secteur pétrolier et gazier ; nous l’avons appelé et lui avons posé des questions sur l’industrie. Au final, nous avons réalisé que oui, c'est intéressant, mais nous ne pourrons rien proposer de fondamentalement nouveau et nous ne pourrons certainement pas faire correspondre les compétences, car il y a trop de spécificités industrielles à prendre en compte compte. Finalement, nous avons pris un risque et sommes allés sur la première piste.
Diane Ganieva (), l'équipe Jingu Digital : « Au niveau régional, nous avions une tâche liée à l'agriculture et à la finale - AR/VR dans l'industrie. Ils ont été choisis par toute l’équipe afin que chacun puisse prendre conscience de ses capacités. Ensuite, nous avons éliminé ce qui ne nous intéressait pas. »
Fais tes devoirs
Et nous ne parlons pas de préparation de code pour le moment : cela n’a généralement aucun sens. Il s'agit de communication au sein de l'équipe. Si vous n'avez pas encore joué ensemble, n'avez pas appris à vous comprendre et à vous mettre d'accord, réunissez-vous plusieurs fois à l'avance et simulez un hackathon, ou au moins appelez-vous pour discuter des points principaux, réfléchissez à travers un plan d’action et discuter des forces et des faiblesses de chacun. Vous pouvez même trouver un cas et essayer de le résoudre - au moins schématiquement, au niveau de « comment se rendre du point A au point B ».
Au cours de ce paragraphe, nous courons le risque d'attraper des inconvénients dans le karma et les commentaires, en disant, comment est-ce possible, vous ne comprenez rien, mais qu'en est-il de l'excitation, du dynamisme, du sentiment que maintenant un prototype va naître du primordial bouillon (bonjour, cours de biologie).
Oui mais.
L'improvisation et le dynamisme ne sont bons que s'ils ne constituent qu'un léger écart par rapport à la stratégie - sinon les risques sont trop grands pour passer du temps à nettoyer le chaos et à corriger les erreurs, au lieu de travailler, manger ou dormir.
Oleg Bakhtadze-Karnaukhov, équipe PLEXeT: « Je ne connaissais aucun des membres de mon équipe avant le concours ; je les ai sélectionnés et invités en fonction de leurs compétences et de leurs évaluations lors de la phase de test en ligne. Lorsque nous avons remporté le hackathon régional et réalisé que nous devions encore aller ensemble à Kazan et terminer le projet de hackathon à Stavropol, nous avons décidé de nous réunir et de nous entraîner. Avant la finale, nous nous sommes rencontrés deux fois - nous avons trouvé un problème aléatoire et l'avons résolu. Quelque chose comme un championnat de cas. Et déjà à ce stade, nous avons constaté un problème de communication et de répartition des tâches - pendant que Polina (conceptrice) et Lev (manager) réfléchissaient au style d'entreprise, aux caractéristiques du produit, recherchaient des données de marché, j'avais beaucoup de temps libre. Nous avons donc réalisé que nous devions assumer une nomination plus difficile (je ne me vante pas, nous avons juste principalement rencontré des tâches liées au Web, mais pour moi, ce n'est qu'une ou deux) et que je devais m'impliquer davantage dans les processus de travail. . En conséquence, lors de la finale, lors des recherches préliminaires, j'ai travaillé sur la modélisation mathématique et le développement d'algorithmes.
Artem Koshko, équipe Composite Key : « Nous nous sommes préparés davantage mentalement ; il n’a pas été question de préparer un code. Nous avions déjà attribué des rôles dans l'équipe à l'avance - nous sommes tous les trois programmeurs (nous avons une pile complète et deux backends, et en plus je connais un peu le développement mobile), mais il était clair que quelqu'un devrait prendre en charge le rôles de concepteur et de gestionnaire. C’est ainsi que, à mon insu, je suis devenu chef d’équipe, me suis essayé en tant qu’analyste commercial, conférencier et créateur de présentations. Je pense que si nous n’en avions pas parlé à l’avance, nous n’aurions pas pu gérer correctement le temps et nous n’aurions pas pu accéder à la défense finale.
Diana Ganieva, Jingu Digital : "Nous ne nous sommes pas préparés pour le hackathon, car nous pensons que les projets de hack doivent être créés à partir de zéro - c'est juste. A l'avance, au stade de la sélection des morceaux, nous avions une idée générale de ce que nous voulions faire".
Vous ne pouvez pas travailler seul avec des développeurs
Diana Ganieva, équipe Jingu Digital: « Nous comptons dans notre équipe trois spécialistes dans des domaines différents. À mon avis, c'est la composition idéale pour un hackathon. Chacun est occupé avec sa propre entreprise et il n’y a pas de chevauchement ni de division des tâches. Une personne supplémentaire serait superflue.
Les statistiques ont montré que la composition moyenne de nos équipes est de 4 à 5 personnes, dont (au mieux) un designer. Il est généralement admis qu'il est nécessaire de renforcer l'équipe avec des développeurs de différents horizons - afin de pouvoir à la fois ajouter à la base de données et surprendre avec une « machine » si quelque chose se passe. Au mieux, ils emmènent toujours un designer avec eux (ne vous offusquez pas, on vous aime !), la présentation et les interfaces ne se dessineront pas toutes seules, au final. Le rôle de manager est encore plus souvent négligé - cette fonction est généralement assumée par le capitaine d'équipe, développeur à temps partiel.
Et c’est fondamentalement faux.
Artem Koshko, équipe Composite Key: « À un moment donné, nous avons regretté de ne pas avoir intégré un spécialiste spécialisé dans l'équipe. Même si nous avons réussi d'une manière ou d'une autre à gérer la conception, cela a été difficile avec le plan d'affaires et d'autres éléments stratégiques. Un exemple frappant est celui où il a fallu calculer le public cible et le volume du marché, TAM, SAM.
Oleg Bakhtadze-Karnaukhov, équipe PLEXeT: « La contribution du développeur au produit est loin de représenter 80 % du travail, comme on le croit généralement. On ne peut pas dire que c'était plus facile pour les gars - presque toute la majeure partie des tâches leur incombait. Mon code sans interfaces, présentations, vidéos, stratégies n'est qu'un ensemble de symboles. S'il y avait eu plus de développeurs dans l'équipe à leur place, nous y serions probablement parvenus, mais tout aurait semblé moins professionnel. Surtout, la présentation est généralement la moitié du succès, à mon avis. Pendant la soutenance puis dans la vraie vie en quelques minutes, personne n'aura le temps de comprendre si votre prototype fonctionne réellement. Si vous vous laissez emporter par des projets, personne ne vous écoutera. Si vous allez trop loin dans le texte, tout le monde comprendra que vous ne savez pas vous-même ce qui est important dans votre produit, comment le présenter et qui en a besoin.
Gestion du temps et détente
Rappelez-vous comment, dans des dessins animés pour enfants comme « Tom et Jerry », les personnages mettaient des allumettes sous leurs paupières pour les empêcher de se fermer ? Les participants au hackathon inexpérimentés (ou trop enthousiastes) se ressemblent à peu près.
Lors d'un hackathon, il est facile de perdre le contact avec la réalité et la notion du temps - l'atmosphère est propice à un codage débridé sans pauses pour se reposer, dormir, s'amuser dans la salle de jeux, communiquer avec des partenaires ou assister à des master classes. Si vous considérez cela comme les Championnats du monde ou les Jeux olympiques, alors oui, c’est peut-être ainsi que vous devriez vous comporter. Pas vraiment.
Artem Koshko, équipe Composite Key: «Nous avons mangé beaucoup de chak-chak, beaucoup - une tour en a été construite au milieu de notre table, cela nous a gardé le moral et nous a donné des glucides au bon moment. Nous nous reposions et travaillions presque tout le temps ensemble, et ne nous reposions pas séparément. Mais ils ont dormi différemment. Andrey (développeur fullstack) aime dormir le jour, Denis et moi aimons dormir la nuit. Par conséquent, j'ai travaillé davantage avec Denis le jour et avec Andrey la nuit. Et il dormait pendant les pauses. Nous n’avions pas de système de travail ni de définition des tâches, tout était plutôt spontané. Mais cela ne nous a pas dérangés, car nous nous comprenons bien et nous nous complétons. Cela a aidé que nous soyons collègues et communiquions étroitement. Je suis l'ancien stagiaire d'Andrey et Denis est venu dans l'entreprise en tant que stagiaire.
Et ici, au fait, se trouve cette même montagne Chak-Chak.
Presque tous les participants que nous avons interrogés ont cité une gestion compétente du temps comme le principal critère de réussite du hackathon. Qu'est-ce que ça veut dire? Vous répartissez les tâches de manière à avoir du temps pour dormir et manger, et les tâches ne sont pas accomplies de manière régulière. tout s'est effondré, mais à un rythme qui convient à chaque membre de l'équipe.
Oleg Bakhtadze-Karnaukhov, équipe PLEXeT"Notre objectif n’était pas de travailler le plus d’heures possible, mais de rester productif le plus longtemps possible. Même si nous dormions 3 à 4 heures par jour, nous semblions réussir. Nous pourrions aller à la salle de jeux ou traîner sur les stands de nos partenaires, et réserver un temps normal pour manger. Le deuxième jour, nous avons essayé de soulager Lev autant que possible pour qu'il puisse dormir suffisamment et avoir le temps de se mettre en ordre avant la représentation. Les répétitions du hackathon nous ont aidés, car nous comprenions déjà comment répartir les tâches et la synchronisation de la routine quotidienne - nous mangions, dormions et étions éveillés en même temps. En conséquence, ils ont fonctionné comme un mécanisme unique.
Nous ne savons pas comment cette équipe a réussi à amener Agomoto's Eye au hackathon, mais à la fin, ils ont même réussi à tourner une vidéo sur le projet et à préparer un document.
Quelques conseils pour gérer votre temps lors d’un hackathon :
- Passez du grand au petit : divisez les tâches en petits blocs.
- Un hackathon est un marathon. Quelle est la chose la plus importante dans un marathon ? Essayez de courir au même rythme, sinon vous tomberez à la fin de la distance. Essayez de travailler à peu près à la même intensité et ne vous poussez pas jusqu'à l'épuisement.
- Réfléchissez à l'avance quelles seront les tâches de chaque participant et combien de temps cela lui prendra. Cela vous aidera à éviter les surprises lorsque la date limite approche dans une demi-heure et que vous n’avez pas un gros travail prêt.
- Vérifiez les coordonnées pour ajuster la portée des tâches. Avez-vous l’impression que tout va bien et qu’il vous reste encore du temps ? Génial : vous pouvez le consacrer à dormir ou à finaliser votre présentation.
- Ne vous attardez pas sur les détails, travaillez dans les grandes lignes.
- Il est difficile de faire une pause dans le travail, alors prévoyez du temps spécifiquement pour dormir, vous détendre ou vous relaxer. Vous pouvez par exemple définir des alarmes.
- Prenez le temps de préparer et de répéter votre discours. C’est obligatoire pour tout le monde et toujours. Nous en avons parlé dans l'un des précédents .
Et il y a aussi cette opinion alternative. Pour quelle option préférez-vous : la torture par le codage ou la guerre par la guerre et un déjeuner selon un horaire ?
Diana Ganieva, équipe Jingu Digital: « Chaque personne de notre équipe est responsable d’une chose, il n’y avait personne pour nous remplacer, nous ne pouvions donc pas travailler en équipe. Lorsqu'il ne restait absolument plus de force, nous dormions pendant trois heures, en fonction de la quantité de travail qui restait encore au participant. Nous n’avions absolument pas le temps de traîner, nous ne perdons pas de temps précieux là-dessus. La productivité a été soutenue, bien qu'avec un sommeil court et des friandises avec du thé - pas de boissons énergisantes ni de café.
Cachés sous la coupe se trouvent plusieurs liens utiles si vous souhaitez approfondir le sujet de la gestion du temps. Cela sera utile dans la vie de tous les jours - croyez l'auteur de ce post, qui est toujours en retard :)
Pour les conquérants du temps — Des techniques efficaces de gestion du temps ont été rassemblées sur le blog Netology par un chef de projet de Kaspersky Lab :
— Un bon article pour les débutants sur Cossa :
Essayez de vous démarquer
Ci-dessus, nous avons parlé de l'équipe qui a fait un don pour protéger le projet. Ils étaient les seuls sur leur parcours, et nous sommes sûrs que parmi les plus de 3500 XNUMX participants, il n'y en avait pas d'autres comme eux.
Bien sûr, ce n'était pas la raison principale de leur victoire, mais cela a certainement apporté un plus supplémentaire - au moins la sympathie des experts. Vous pouvez vous démarquer de différentes manières : certains de nos gagnants commencent chaque représentation par une blague sur la façon dont ils ont fabriqué une bombe (l'équipe Sakharov, bonjour !).
Nous ne nous attarderons pas là-dessus en détail, mais partagerons simplement un cas de l'équipe PLEXeT - nous pensons que cela vaut la peine de devenir une blague sur le fils d'une amie mère.
Oleg Bakhtadze-Karnaukhov, équipe PLEXeT : « Nous avons réalisé que nous étions en avance sur la courbe et avons décidé que ce serait cool de venir à la pré-défense avec une boîte de transfert. Le projet comporte de nombreux détails techniques, explications d'algorithmes, qui ne sont pas du tout inclus dans la présentation. Mais je veux le montrer. Les experts ont soutenu l’idée et ont même contribué à son optimisation. Ils n’ont même pas regardé la première version, ils ont dit qu’ils ne liraient jamais un tel tableau. Nous étions les seuls en défense.
Quelque chose va forcément mal se passer, et ce n'est pas grave.
Lors d’un hackathon, comme dans la vie ordinaire, il y a toujours place à l’erreur. Même s'il semble que vous ayez pensé à tout, qui d'entre nous n'a pas été en retard à un avion/examen/mariage simplement parce que les voitures ont décidé de rester coincées dans un embouteillage, l'escalier roulant a décidé de tomber en panne et le passeport a été oublié à la maison?
Oleg Bakhtadze-Karnaukhov, équipe PLEXeT : « Polina et moi avons passé toute la nuit à faire une présentation, mais à la fin, ils ont oublié de la télécharger sur l'ordinateur de la salle où a eu lieu la soutenance. Nous essayons de l'ouvrir à partir d'un lecteur flash, et l'antivirus perçoit le fichier comme un virus et le supprime. En conséquence, nous avons réussi à tout démarrer une minute seulement avant la fin de notre prestation. Nous avons réussi à montrer la vidéo, mais nous étions quand même très contrariés. Une histoire similaire nous est arrivée lors de la pré-défense. Notre prototype n’a pas démarré, les ordinateurs de Polina et Lev ont gelé et, pour une raison quelconque, j’ai laissé le mien dans le hangar où se trouvait notre piste. Et même si les experts ont vu notre travail le matin, nous ressemblions à une équipe d'excentriques avec un document, de belles paroles, mais aucun produit. Considérant que de nombreux participants percevaient mon travail sur les modèles mathématiques comme « il est assis, dessine quelque chose, ne regarde pas l'ordinateur », la situation n'était pas très bonne.
Cela peut sembler ringard, mais tout ce que vous pouvez faire dans cette situation, c'est expirer. C'est déjà arrivé. Non, vous n'êtes pas le seul, tout le monde se trompe. Même si c’est une erreur fatale, c’est une expérience. Et réfléchissez également : la personne qui vous évalue considérera-t-elle cette affaire comme un fakap ?
Partagez dans les commentaires quelle composition vous vous sentez le plus à l'aise pour travailler lors d'un hackathon (à la fois des personnes et des spécialistes) et comment vous construisez des processus en équipe.
Source: habr.com