Salut et bonne année à toi aussi. Je te souhaite avant tout une bonne santé !
Comme cela a déjà été dit, la communication est un élément essentiel mais je rajouterai une précision : “informelle” !
Sinon je vois globalement deux grandes catégories de qualité :
- Acquisition
La capacité a capté les besoins. Je vois déjà deux qualités : l’observation et l’empathie. Je n’ai pas trop de conseil à donner pour les développer mais certains prétendent que les cours d’improvisation et de théâtre aident bien.
Mon principal conseil reste la communication “informelle” . Il serait mal venu de te poster pendant plusieurs heures derrière tes collègues pour les observer. Alors n’hésites pas à leur rendre visite sur leur poste de travail et “capté” le … WTFs/m ; ou plus sérieusement la façon dont il travaille globalement.
De mon expérience, le plus gros problème ce n’est pas de se focaliser sur l’existant et une solution logicielle mais de bien s’approprier leur façon de travailler et ensuite de leur proposer une solution opérationnelle et non strictement logicielle. Je vois trop souvent des solutions conçues sur l’utilisation d’un logiciel alors qu’un workflow / processus peut passer par plusieurs acteurs, actions et systèmes.
Par exemple : saisir / récupérer des informations par un “manager” puis transmisent à une tierce personne. La solution peut-être une série de formulaire Web ou de la saisie dans un fichier Excel envoyé par mail.
J’aime bien l’idée de Thinking outside the box.
- Restitution
La deuxième catégorie c’est tout ce qui concerne à montrer. C’est l’aspect le plus “technique”.
Cela va de la rédaction de documents, à la réalisation de maquette. Cela nécessite de graviter autour de l’ingénierie des exigences, UI designer, RAD, le commercial, etc. Le sujet est relativement vaste mais voici quelques trucs :
-
l’ingénierie des exigences reposent sur la gestion d’un inventaire. Si tu as l’habitude de travailler avec des task tracker (Jira, Mantis, etc.), tu as déjà de bonnes notions. La seule différence c’est qu’il faudra les organiser et les présenter sous la forme d’un document (Word la plupart du temps).
Je pense qu’il est fondamentale de détailler un maximum et tenir un historique de tous ces points. Et d’avoir un document de spécification qui trace bien l’état sur lequel tout le monde s’est mis d’accord. C’est un peu le “tag” de ta gestion de configuration des besoins.
-
Je n’ai pas une grande expérience d’UI designer mais j’aime bien les outils de wireframing comme Balsamiq. Il existe plein de concurrent, je te laisse trouver celui qui te convient et qui te permettra de communiquer au mieux avec tous les interlocuteurs. Bien que c’est outil soit par nature “statique”, il ne faut pas négliger les informations relatives à la “dynamique” (enchainement des écrans ET des actions utilisateurs,).
-
Le prototypage et le RAD sont des outils importants pour montrer quelque chose de concret très rapidement. Aujourd’hui de nombreux outils ont été développés pour construire des produits “prêt à livrer”. Ce qui permet souvent d’éviter le problème du “quick’n’dirty” (vite fait, mal fait) qui est déployé tel quel.
Cependant il ne faut pas négliger le travail de transformation du prototype en produit. C’est encore plus vicieux avec ces outils.
La veille technologique sera ta meilleure amis avec Twitter, InfoQ, DZone, ou autres. Le plus gros problème sera de faire le tri entre le contenu intérressant et ceux qui veulent vendre quelque chose (y compris et surtout du vent :))
-
La partie “commerciale” n’est pas à négliger. Vu que tu viens des SSII, tu sais comment marche le monde. Plus c’est “joli”, plus ca fait vendre aux directions ; et plus les directions en veulent, plus elles forcent leurs employés à “consommer”. C’est rarement le bénéficiaire / utilisateur qui choisit. En revanche, c’est à toi de capter ce dont ils ont besoin et d’aller le vendre ensuite.
Je trouve que les frameworks de présentation HTML5 en jettent pas mal ;) Ne pas hésiter à demander à des proches (non informaticiens de préférence) ce qu’ils en pensent, ils ont souvent un ressenti très proche des directions par rapport aux technologies.
PS : ne pas oublier tout de même leurs avis aux utilisateurs avant d’aller vendre quoique ce soit ^_^
- Divers
En fonction de tes compétences et de tes responsabilités, il peut y avoir énorment de choses à développer que tu ne maîtrises pas encore complétement après ton passage par des SSII. Il peut s’agir de la gestion de configuration (source, binaire), de déploiement (centralisé et distribué), sysadmin, etc.
Essayes d’identifier les tâches que tu peux déléguer en permanence, celles que tu pourrais être amené à effectuer toi-même, et celles qu’il faudra quoi qu’il en soit te palucher.
Pour ces dernières, il me semble évident d’envisager des formations, des conférences, etc. Pour les deuxième c’est assez variable, ca dépendra pas mal de vos capacités respectives à transmettre et assimiler un savoir ainsi que vos degrés d’expertise dans le domaine. Sinon un peu de lecture (bouquin, articles, etc.) peut parfois suffire.
Pour les dernières, je ne saurai que trop te conseiller de t’y intéresser (mais sans plus) pour la culture générale et faire de meilleures propositions en termes de solutions.
Enfin dernier point qui me vient à l’esprit : être mesuré. Cela commence par apprendre à temporiser. Les utilisateurs peuvent avoir des demandes urgentes et changer d’avis tous les quatre matins ou bien émettre des besoins qui s’opposent, etc.
Il existe quelques outils “techniques” (plugins, paramétrage, configuration dynamique, etc.) mais le plus simple reste de jouer la montre et d’attendre que les avis convergent (éventuellement vers le néant).
Voilà mon ressenti par rapport à mon expérience, et notamment en tant que développeur d’outils pour une équipe de développements ;)
