Discussion :

[ulspider]

Le gars a bossé un an sur une techno, il a forcément appris quelque chose (on suppose qu'il est intelligent et pas toujours sur facebook )
Et même si le projet s'est ou va se planter (de son fait ou pas), un échec, c'est formateur ( mais ca aussi, c'est francais : un échec, c'est forcément que mal)
Mais pour être plus concret : s'il postule au Canada, ou même a Paris, est ce que tu crois que le gars en face va vraiment s’intéresser à savoir si un projet en interne a bien fini ? Au pire, timewarp dit "je l'ai livré, ceci était bien, ceci etait mieux que l'outil avant, ceci est a améliorer (pour pas faire arrogant)", le recruteur va pas aller plus loin. Surtout pour un poste technique, mais aussi pour un truc plus management - a mon avis.

Ce n'était pas pour être blessant que je disais cela. Je dis juste qui si une personne me dit qu'il quitte un projet où il était enfermé dans un bocal pendant un an, sur les technologies A, B, C, D, E, F qu'il a choisit tout seul (avec quel recul ?) et que le projet n'est pas mené jusqu'au bout ou qu'il ne correspond pas aux attentes du métiers, il est difficile de juger la personne sur les technologies A, B, C, D, E, F.

L'échec fait certes partie de l'apprentissage mais il faut que l'on sache pourquoi afin d'aller de l'avant. Faire sa critique en étant sur un projet seul, ce n'est pas

[tim3w4rp]

l'abandon n'est pas forcément un échec technique, çà peut être un échec de management de projet de la part du développeur et/ou de l'entreprise. C'est donc possible de maîtriser les technologies correctement même en abandonnant le projet.
Ne pas confondre technologies et attentes fonctionnels.

[phili_b]

Je suis le seul à me dire qu'un an sur un projet où il est tout seul et qui va surement se vautrer avant ou après son départ, ça n'apporte rien ?! Franchement si je vois arriver une personne qui a bossé sur ces technologies mais qui n'a pas de résultats concluants, c'est presque comme s'il n'avait pas d'expérience.

Pour moi :
Projet mené à bien = Expérience validée
Et dans le cas contraire, cela ne vaut rien.

Ben non. Si quelqu'un me fait un prototype d'une voiture qui roule mais que le client n'achète pas j'aurais des doutes sur le business model mais pas sur l'ingénieur qui a conçu la voiture ni le technicien qui l'a construite.

Si tim3w4rp fonce dans le mur sans rien faire, sans se poser de questions (ce qui n'est pas le cas vu son message ici), alors oui c'est un échec. Mais si tim3w4rp fait tout pour que ça fonctionne mais que son patron est un mur et qu'il dresse une barrière entre les utilisateurs et tim3w4rp, et que par ailleurs son produit fonctionne pour moi ce n'est pas un échec.

Tout dépend de lattitude de tim3w4rp et de ses prérogatives réelles. S'il a pleinement ses prérogatives et qu'il est chef de projet, oui il est responsable, s'il n'a aucune prérogatives et que son patron le cantonne à des fonctions techniques je ne vois pas ce qu'il peut faire de mieux. Au pire on peut le juger mal sur la gestion de projet, mais pas sur son expérience technique.

[mister3957]

Essaye de prendre du recul, de la hauteur, de mettre à plat les choses et de tirer la sonnette d'alarme rapidement, par mail.

Tu exposes les faits, pourquoi tu penses que ça n'ira pas, tes propositions pour que ça rentre dans les clous afin que ce soit ton décideur par la suite qui fasse le choix "mur ou pas mur ?", mais au moins ta transparence te protégera lorsque le stress va monter en même temps que l'approche de la deadline et à ce moment là si quelque chose est à remettre en cause, ce ne sera pas ton travail, mais ses choix.

Par ailleurs si son emploi du temps ne lui accorde qu'un jour par mois au projet qu'il t'as confié, ce n'est pas ton problème, tu peux toujours lui expliquer qu'il n'est pas possible de concilier gestion de projet avec tout le recul que cela demande et code / recherche / conception qui demande de rentrer dans une forme de "bulle" pour qu'un point particulier avance correctement.

S'il n'est pas familier avec l'informatique, utilise des analogies.

[tim3w4rp]

Essaye de prendre du recul, de la hauteur, de mettre à plat les choses et de tirer la sonnette d'alarme rapidement, par mail.

Tu exposes les faits, pourquoi tu penses que ça n'ira pas, tes propositions pour que ça rentre dans les clous afin que ce soit ton décideur par la suite qui fasse le choix "mur ou pas mur ?", mais au moins ta transparence te protégera lorsque le stress va monter en même temps que l'approche de la deadline et à ce moment là si quelque chose est à remettre en cause, ce ne sera pas ton travail, mais ses choix.

Par ailleurs si son emploi du temps ne lui accorde qu'un jour par mois au projet qu'il t'as confié, ce n'est pas ton problème, tu peux toujours lui expliquer qu'il n'est pas possible de concilier gestion de projet avec tout le recul que cela demande et code / recherche / conception qui demande de rentrer dans une forme de "bulle" pour qu'un point particulier avance correctement.

S'il n'est pas familier avec l'informatique, utilise des analogies.

très bons conseils. merci à toi.

[mister3957]

très bons conseils. merci à toi.

C'est ce que j'attends de mes développeurs, de la transparence afin d'avoir toutes les cartes pour faire ensuite les bons choix.

[Njörd]

Bonjour tim3w4rp,

Je suis dans le même cas que toi, à savoir sur un ou plusieurs projets seul (sur la partie technique) dans une PME.

L'important est que tu sois bien organisé et que tu documentes un maximum :
- ce qui a été fait
- ce que tu es en train de faire
- ce qu'il te reste à faire

Cela te permet d'avoir une vision d'ensemble de ton projet et tu peux remonter régulièrement des informations à ton patron. Si tu ne le vois qu'une fois par mois, envoi lui des mails de suivi. Ainsi, qu'il les lise ou non, il ne pourra pas dire que tu ne lui a pas fait remonter les informations importantes.

Pour le côté technique, il y a les tests unitaires. Côté PHP tu as atoum et PHPUnit. Côté JS tu peux faire tes propres tests de façon basique ou passer par un framework de test (un article présentant bien la chose côté JS). Le souci c'est que la courbe d'apprentissage est assez longue, notamment au début sur la mise en place. Mais vu que tu code en JS principalement, tu peux au moins mettre en place les TU côté JS. Tu y gagneras beaucoup de temps et de clarté et surtout, tu rationaliseras ce que tu fais déjà : alert(); console.log(); + F5

Sur DVP les avis sont mitigés, certains te diront ça sers à rien d'autres te diront que c'est très important. Personnellement, je trouve que ça te permet d'avoir une garantie minimum lorsque tu modifies une partie de ton code.

Pour le Canada, regarde du côté du visa vacances / travail. Si tu es âgé de moins de 35 ans c'est jouable. Cela te donne un an pour travailler et te faire un réseau. La partie la plus dur est effectivement de demander le visa permanent avec l'appui d'une entreprise (d'où l'importance du réseau). Dans tous les cas, c'est une expérience enrichissante qui te permet de valoriser ton ouverture d'esprit, de travailler ton anglais (si tu fais l'effort d'aller ailleurs que dans les villes où l'on parle français => Vancouver par exemple), de voir une autre façon de fonctionner un pays et ses entreprises, de valoriser ton expérience de 5 ans (en France bac+2 ça joue contre toi, en Amérique ce n’est pas ce qui compte).

Enjoy et ne te décourage pas. Avoir un projet de A à Z, sur du JS, c'est une expérience que tu pourras valorisée. Le tout est de savoir mettre en avant les côtés positifs de cette expérience.

[GuillaumeJ]

Le PVT, c'est jouable pour le canada, oui, mais y a beaucoup de demandes.
Ca implique de chercher un travail sur place, mais par contre en toute liberté.

Vu ce que je sais de son profil, il pourrait tout a fait je pense trouver un boulot de France, et partir du coup avec un visa temporaire de 3 ans : c'est assez simple et rapide, et tu as ta job sous le code, et ta première rentrée d'argent au bout de 15 jours (voir même une aide de ton employeur pour venir : j'ai eu 500$, d'autres 5000..). C'est - je trouve - moins stressant.
Par contre, c'est un visa associé a ton employeur : s'il te vire, il faut en redemander un, tu peux pas changer de boulot sans redemander un visa, et ainsi de suite. Tu es donc moins libresi tu pars a deux, la conjointe obtient elle un visa ouvert (n'importe ou, n'importe qui, n'importe quoi comme travail))
Dans mon cas, vu le marché chaud bouillant de l'emploi ici, je rate sans doute des opportunités, mais bon, je suis pas vraiment un ambitieux carriériste, et je suis plutôt content de mon employeur et de mes conditions de travail. Et maintenant que j'ai un an d'ancienneté, y a un circuit un peu accéléré pour avoir un visa permanent.
(enfin, on est parti loin de son post initial, mais j'aime bien être précis : au pire, il peut commencer a laisser son pc ouvert sur le site d'immigration Canada pour montrer a son boss qu'il pense a partir, et avoir un levir de négociation )

[Njörd]

Bonjour GuillaumeJ,

Je suis complètement d'accord avec toi, ce n'est pas non plus la fête Tu as le visa à partir du moment où ton dossier est complet (ah oui, pas de casier judiciaire, notamment par rapport à l'alcool genre conduite en état d'ivresse) et que tu as envoyé parmi les premiers (cette année ils ont fermé, pour le programme à 7000 visas, au bout de deux semaines là où l'année dernière ils avaient fermé les inscriptions au bout de trois mois).

Pour le HS, je souhaitais apporter une note positive de plus pour la question du départ au Canada (ou ailleurs). Je trouve que c'est une excellente expérience à vivre dans sa vie. Expérience souvent critiquée en France où on aime bien ... critiquer

Pour le reste, une bonne organisation, un reporting régulier pour assurer ses arrières. Pour le côté contact humain absent (CP et utilisateurs finaux) seule de la diplomatie peu débloquer la situation