Skip to content

Instantly share code, notes, and snippets.

@nicoolas25
Last active August 29, 2015 14:07
Show Gist options
  • Save nicoolas25/4f1938688ea207bcc178 to your computer and use it in GitHub Desktop.
Save nicoolas25/4f1938688ea207bcc178 to your computer and use it in GitHub Desktop.
Nouvel emploi

Nouvel emploi

Cet été je quittais une petite société de service de moins de 10 personnes pour rejoindre un éditeur qui compte une petite trentaine de personnes. Il y a deux semaines, je prenais mon poste et voici brièvement un petit bilan de ces premiers pas.

La structure

Avant tout, il faut savoir que mon ancien poste et mon nouveau poste ne sont pas les mêmes. Alors qu'avant j'étais plutôt fullstack, aujourd'hui je suis décidément backend. Ce changement est possible grâce à la manière dont l'entreprise se structure. En effet, les responsabilités liées au développement sont réparties entre différentes équipes : une équipe en charge du design, une autre en charge de l'intégration, encore une autre dédiée au frontent, une autre, dans laquelle je me situe, en charge du backend et surtout une équipe produit. Lorsque je parle d'équipe, il s'agit souvent de quelques personnes. Certains font parties de plusieurs équipes, etc.

Parmi les motivations qui m'on poussé à changer d'emploi, la structure est en tête de liste. Je suis donc très content de ne plus m'occuper du développement frontend, de ne plus avoir la responsabilité d'integrer au fil de l'eau des maquettes, dessinées par un client, qui devra très probablement être revue deux ou trois fois. Je suis également ravi de trouver, au sein de l'équipe backend, un devops en charge de l'infrastructure.

Je n'ai pas cité l'équipe marketing, l'équipe commerciale ni l'office manager qui sont tout aussi indispensable à la vie du produit et de l'entreprise.

L'agilité

J'ai pu lire nombre de billets de blogs à propos de l'agilité et même un livre ou deux. Malheureusement, pour les sociétés de service, le forfait est encore le moyen le plus sûr de signer un client. On peut s'imaginer être agile lorsque l'on travaille au forfait mais je pense que ce sont deux modes d'organisation en contradiction philosophique absolue.

Chez un éditeur, les contraintes sont toutes autres et peuvent plus facilement laisser place à des formes d'organisation agile. La confiance entre le produit et les équipes de développement est naturelle puisque nous sommes dans le même bateau. La technique se contente de produire le meilleur produit possible, le plus rapidement possible.

Le fait d'être agile n'était pas sur ma whishlist lorsque j'ai changé de société mais c'est fort appréciable et ça a pesé dans la balance lors de mon choix.

La montée en compétence

L'organisation de l'équipe est orientée à la distribution des compétences. Une très forte quantité de revue de code est présente quotidiennement. Github aide beaucoup pour ça puisque toute modification de la base de code passe par des pull-requests. Ce sont ces pull-requests qui sont revues par l'équipe avant d'en approuver le merge.

C'est depuis très longtemps que je suis convaincu des bénéfices d'une telle pratique. Il est très agréable de voir la qualité du code de l'équipe augmenter grâce aux intervention de chacun. La connaissance individuelle est répartie sur l'ensemble de l'équipe. Les astuces de chacuns sont partagées. Les points d'incertitude sont débatus.

La montée en compétence est également assurée par la variété des profils présents dans l'entreprise et par le challenge technique apporté par le produit.

Un remote mieux encadré

Un excellent point va également au télétravail. Même si j'y suis déjà famillier depuis 2011, des changements notables sont à signaler.

Un point hebdomadaire est fait par le CTO avec les télétravailleurs afin d'avoir leur ressenti. C'est l'occasion d'aborder les évènements de l'entreprise, d'échanger sur le mode de travail, et surtout de ne pas parler technique.

Les standups quotidiens, l'agilité, les revues et un produit commun aide énormément à l'intégration. Une grande part de la communication se passe sur Slack, ce qui permet à tout le monde d'être dans la boucle. Lorsque ce n'est pas le cas, certains prennent la peinne de faire un petit récapitulatif écrit, pour mémoire et pour le reste de l'équipe.

En plus de ça, pour assurer le coup, j'ai souhaité faire le déplacement au bureau deux fois par mois. Dans la mesure où il me faut seuleument deux heures pour m'y rendre, c'est acceptable.

Conclusion

Après ce quelques jours de travail, je suis très enthousiaste et après deux semaines, c'est bien normal. J'apprécie beaucoup ma nouvelle équipe, la structure que nous formons et les choix techniques qui ont été fais.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment