Chers étudiants, ce billet vous est dédié. Nous venons de finir ensemble une nouvelle année de cours et de projets. Vous m’avez surpris, impressionné, déçu, énervé, enchanté, épaté, fait rire aussi parfois… mais surtout, vous m’avez rendu du code, présenté des documents, vous avez soutenu des présentations devant moi et je vous en remercie. Pour que tout cela soit encore meilleur l’année prochaine, je tenais à vous donner quelques conseils.

À propos de votre code

• Évitez de rendre un code monolithique, entièrement écrit dans un nombre réduit de fichiers : un code compact est aussi difficile à lire qu’il est difficile à maintenir. Découpez, autant que possible, votre code en petits fichiers à l’objectif clair.
• Quels que soient le langage ou la nature du projet, pensez à intégrer des fichiers README (.txt ou .md) dans certains dossiers pour expliquer les choses, à commencer par celui que vous placerez à la racine du projet. Expliquez-y pourquoi vous avez écrit ce code et comment l’utiliser (installation comprise).
• Dans un questionnaire, faites toujours un tour des questions avant de démarrer. Ne perdez pas votre temps sur des questions difficiles avant de vous êtres assurés que des points « faciles » n’étaient plus à prendre.

Plus spécifiquement, concernant le RWD :

• Si on passe 35h à vous dire que Bootstrap n’est pas utile quand le projet ne le nécessite pas et qu’on vous apprend trois techniques différentes pour faire mieux et sans, ne le sortez pas de votre manche à l’examen.
• Le point de rupture n’est pas là pour embarquer un maximum de devices mais pour, au contraire, diviser la population et mieux adresser chaque partie. Un point de rupture mobile à 740px est clairement très large…

À l’écrit :

• Travaillez le niveau de langue. N’utilisez pas « on », mais « nous ». « On a foiré le projet » , c’est moins joli que « Nous avons commis des erreurs ».
• Attention à l’orthographe : vous avez des correcteurs sur tous les éditeurs de texte, servez-vous en.
• L’orthographe ne fait pas tout : conjugaison, grammaire, style et… typographie (oui, les virgules ne sont pas en option ; pensez à la phrase « Venez manger, les enfants »).
• Commencez toujours par expliquer ce dont l’utilisateur a besoin pour justifier ce que vous avez réalisé. Si vous avez du mal à basculer du besoin vers la réalisation, c’est que vous avez un problème de périmètre.
• Faites un export PDF, n’envoyez jamais de document Word.

Équipe projet :

Vous allez faire des dizaines de projets où l’on vous demandera des fiches d’équipe. Prenez l’habitude d’en écrire, avec un design adapté. Ayez toujours de quoi faire votre petite fiche sous la main : une photo qui vous valorise et un descriptif de votre profil (savoir-faire, savoir-être, précédentes expériences).

N’hésitez pas à introduire une représentation visuelle de vos responsabilités :

• par le biais de pictogrammes ;
• en utilisant la matrice RACI.

Présentation

• Si vous numérotez vos slides à la main, pensez à revoir ces numéros avant la soutenance…
• Dans vos slides, évitez d’écrire des phrases complètes. Leur lecture distrait le public.
• Pensez à changer de fond d’écran avant de brancher le projecteur. Vos préférences sexuelles n’ont pas vocation à se retrouver projetées en 4 × 3.

À l’oral

• Répétez. Rien de plus énervant qu’un groupe qui se regarde dans le blanc des yeux en attendant qu’un d’entre eux se décide à dire quelque chose.
• Corollaire du précédent point : dans les bonnes présentations, la parole se donne, elle ne se prend pas. Organisez-vous pour vous passer la parole.
• Ne vous reprenez pas entre vous : remerciez-vous. Pas de « Je voudrais revenir sur ce qu’à dit Machin car il a tort ». Plutôt « Merci à Machin d’avoir introduit le sujet, je vais désormais y revenir en détails ».
• Ne soyez pas trop directifs : « Nous vous remercions de garder vos questions pour la fin de la présentation » est maladroit. Préférez « Si cela ne vous dérange pas, nous répondrons à vos questions en fin de présentation. Si quelque chose vous perturbe, nous seront ravis d’y répondre. »
• Attention au vocabulaire et au niveau de langue. À l’oral aussi, préférez « nous » à « on ». N’utilisez pas de termes connus pour dire autre chose (notamment, ne dites pas que vous avez fait preuve d’agilité si vous n’avez pas emprunté les méthodes agiles. Parlez plutôt de souplesse ou d’adaptabilité).