Get best of the week

Comment Amazon est organisé

Comme de nombreuses autres entreprises américaines, l'organisation du flux de travail d'Amazon repose sur des principes de base, dont le principal objectif est d'aider les employés à prendre la bonne décision en fonction des valeurs de l'entreprise. Nous avons discuté avec un chef de produit d'Amazon, qui a parlé des principes suivis par l'entreprise, de la façon dont ils aident dans les tâches et des processus que l'équipe traverse lors du développement d'un nouveau produit. Ci-dessous, nous avons laissé un lien vers une vidéo avec une interview complète.

Mission, vision et principes d'Amazon


À ma connaissance, la mission d'Amazon est d'être l'entreprise la plus orientée client au monde. Tous les produits sur lesquels la société travaille sont développés dans le but de fabriquer d'abord le produit pour le client, puis d'augmenter ses ventes.

Il existe 14 principes dans lesquels vit une entreprise et ils sont utilisés dans tous les processus de travail. Ces principes sont assez basiques, ils n'ont rien de spécial. Ils sont guidés par le lancement d'un nouveau produit, lors des entretiens, ou lors d'un retour d'expérience à un collègue. Ils ne sont pas obligés de mémoriser, mais lorsque vous travaillez dans une entreprise, si vous voulez, vous ne voulez pas, vous commencez à suivre ces principes.

Beaucoup d'entre eux se séparent. Par exemple, comme Think Big et Bias for Action. L'un dit: «Penser globalement» et l'autre dit: «Agir, pas planifier». En fait, il existe de nombreux principes de ce type qui entrent en conflit les uns avec les autres. Mais c'est tout le problème. Si les employés étaient obsédés par le principe Think Big, alors tout le monde allongerait les délais. Et si seul le biais pour l'action était respecté, ils réaliseraient rapidement de petits projets et ne penseraient pas aux grands.

Beaucoup disent que la culture amazonienne est plus exigeante. Les gens viennent ici pour travailler, étudier et se développer. Et quand ils sont fatigués, allez chez Microsoft.

En effet, Amazon est une entreprise plus dynamique et à croissance rapide. Nous essayons de grandir dans des directions différentes. Mais le modèle commercial de Boeing et de Microsoft n'a pas changé depuis de nombreuses années. Google a la même chose: le moteur de recherche reste leur principale source de revenus.

Amazon est encouragé à générer constamment de nouvelles idées. Il y a toujours beaucoup de projets dans le processus de développement. Lorsque le travail sur un produit se termine, tout le monde passe immédiatement à un autre. Et en même temps, des objectifs élevés pour chaque projet sont toujours fixés au sein des départements.



Processus de développement de produits


La première chose que vous devez faire avant de définir la tâche est de tester l'hypothèse. Pour cela, MVP ou MLP est utilisé. Sur la base de ces concepts, un grand document est compilé, qui est ensuite examiné par toute l'équipe. Deux choses doivent être soulignées dans le document:

Comment le projet résoudra-t-il le problème des clients? Le document a 1 page afin d'expliquer succinctement l'idée et de transmettre sa valeur.

Quelles questions les consommateurs peuvent-ils poser sur le produit? Et des questions techniques: comment allons-nous monétiser? Où acheter du matériel technique? Qui sera l'entrepreneur? Tout doit être décrit dans le document sous forme de questions et réponses.

Si nous comprenons que tout le monde a aimé l'idée, elle va dans le développement. Le chef de produit compile une liste d'exigences, en les décomposant au stade de la version Agile. Tout est organisé de telle manière afin de tester étape par étape une chose et d'obtenir des commentaires.

La chose la plus importante dans l'équipe est de ne pas attendre les instructions. Si vous rencontrez un problème, vous devriez déjà avoir une solution. Et le gestionnaire ne peut que donner son avis - que vous ayez trouvé ou non une bonne solution.

L'équipe a toujours un calendrier pour les jours où elle sera terminée. Chaque semaine, les employés se réunissent pour discuter des tâches. Nous les montrons sur un tableau de bord avec les statuts - vert, jaune et rouge.

Le vert signifie que tout va bien, l'attention à la tâche n'est pas requise. Jaune - quelque chose s'est mal passé, mais nous savons comment le réparer. Par exemple, ils prévoyaient de terminer le projet avant le 1er mai, mais il y avait un problème que nous essaierons de résoudre d'ici le 1er mai. Et rouge - quelque chose s'est mal passé, et nous ne savons pas encore comment respecter les délais.

Après cela, chaque développeur montre des démos avec le travail effectué. Au cours de ces réunions, le chef de produit a la possibilité de donner son avis et de changer le chemin de la tâche. Pour le reste - la possibilité de demander conseil à des collègues, si vous ne savez pas comment résoudre l'un des problèmes. Les rapports hebdomadaires de l'équipe soutiennent la culture Agile lorsque tout le monde essaie de publier quelque chose pour la publication, plutôt que de tirer avec elle pendant une année entière.

Lorsque le projet est prêt, il est approuvé par le chef de produit et envoyé à l'étape suivante - les tests. La société dispose de testeurs internes qui vérifient si la fonctionnalité ne fonctionne pas et d'un groupe de testeurs bêta, qui à leur tour donnent leur avis. Après leurs tests, le développement est publié en quelques jours. Et c'est là que le travail sur la tâche se termine.



Organisation des processus de travail dans l'entreprise


Scrum - une méthode de hiérarchisation des tâches pour les 2-3 prochaines semaines - pour un sprint.

Sprint est un court terme dans lequel vous dites: «OK, les dix prochaines semaines, nous ferons ces 10 tâches. Et nous ne travaillerons que sur eux et rien d'autre. » Cela a ses avantages et ses inconvénients. D'une part, vous n'êtes pas distrait par d'autres tâches. Mais vous devez constamment faire des ajouts, et ils vont beaucoup sprinter.

Il n'y a rien de tel dans la programmation que vous venez de vous asseoir et de commencer à écrire du code. Tout d'abord, le chef de produit recueille toutes les exigences, décrit les fonctions du nouveau produit. Ensuite, tout va au design. Les programmeurs s'assoient et décrivent ce qu'ils devront faire en fonction des exigences, par exemple, s'intégrer au système, créer un cadre spécifique, etc. La troisième étape est le code en cours, où l'employé est déjà assis et commence à écrire du code. Puis test. Et la dernière étape est la sortie.

Et ici, Kanban est une méthodologie dans laquelle vous définissez des limites pour chaque étape. Un groupe d '«exigences» ne peut pas avoir plus de 3 fonctions. Jusqu'à ce que je transfère l'une des exigences à la conception, je ne peux pas ajouter de nouvelles tâches.

Autrement dit, le flux des tâches est réglementé. Si vous avez plus de développeurs, vous pouvez étendre les tâches. Les avantages de la méthodologie sont qu'elle est flexible. Moins - la priorité peut changer constamment contrairement à Scrum. À tout moment, vous pouvez inclure une tâche qui n'existait pas auparavant.

Les deux approches se rapportent à la méthodologie Agile. Cela signifie que vous divisez toujours une grande version en petits morceaux et les libérez le plus souvent possible afin de ne pas faire ce dont l'utilisateur n'a pas besoin.

Dans Scrum, nous évaluons chaque tâche en points. Vous ne pouvez pas les mesurer avec quoi que ce soit, c'est plutôt une valeur relative. Par exemple, une tâche représente 4 points de plus que la tâche estimée à 2. De tels points vous permettent de voir combien le développeur a clôturé sa tâche.
Chez Kanban, c'est plus compliqué.

Notre autre règle est de ne prendre en charge que 3 tâches. Si l'équipe compte 10 développeurs, alors tout le monde travaille sur ces tâches, personne ne peut en prendre un nouveau. Parce que si chaque développeur assume une tâche, ce qui prend 2 mois de temps de développement, il n'y aura que 2 versions par mois, respectivement.

C'est pourquoi il y a des restrictions sur au moins 3 tâches, chacune ayant 3 développeurs. De plus, si quelqu'un est libéré, il ne peut pas entreprendre un nouveau projet. Il devrait aider ses collègues à effectuer le reste des tâches définies pour le sprint. Et seulement après la sortie du projet, vous pouvez prendre de nouvelles tâches.

More articles:


All Articles