Bonjour, je me pose une question : quelles sont les prestations les plus
demandées en ce moment à des prestataires ayant une spécialisation Java ?
Je suppose que le monde pro (secteur privé ou public) est certainement
plus enclin à faire appel à des SSII (ce qui semble une particularité
française) mais bon...
Si on met de côté cet aspect des choses, quelles sont les compétences
Java les plus demandées en ce moment à ces prestataires, ou *mieux*
encore celles pour lesquelles on trouve le moins de monde ?
des vrais experts J2EE qui n'ont pas besoin de lire la doc pour coder.
Je trouve ça beaucoup trop académique comme critère de sélectio n. Il vaut mieux justement s'intéresser à quelqu'un qui n'a pas peur de lire p lutôt qu'à quelqu'un qui prétend tout connaître de J2EE, ce qui est imp ossible.
...
Quand la techno est choisie, sur des arguments solides, il est toujours temps de se plongeant dans la doc tech nique.
C'est un peu contradictoire, non ? Comment choisir la technologie "sur des arguments solides" sans connaitre la partie technique ?
D'ailleurs je pense que ce n'est probablement pas le meme metier, choisir la technologie releve de l'architecture, implementer du developpement. Evidemment, sur un petit projet c'est souvent la meme personne qui fait les deux.
des vrais experts J2EE qui n'ont pas besoin de lire la doc pour coder.
Je trouve ça beaucoup trop académique comme critère de sélectio n. Il vaut
mieux justement s'intéresser à quelqu'un qui n'a pas peur de lire p lutôt
qu'à quelqu'un qui prétend tout connaître de J2EE, ce qui est imp ossible.
...
Quand la techno est choisie, sur des
arguments solides, il est toujours temps de se plongeant dans la doc tech nique.
C'est un peu contradictoire, non ? Comment choisir la technologie "sur
des arguments solides" sans connaitre la partie technique ?
D'ailleurs je pense que ce n'est probablement pas le meme metier,
choisir la technologie releve de l'architecture, implementer du
developpement. Evidemment, sur un petit projet c'est souvent la meme
personne qui fait les deux.
des vrais experts J2EE qui n'ont pas besoin de lire la doc pour coder.
Je trouve ça beaucoup trop académique comme critère de sélectio n. Il vaut mieux justement s'intéresser à quelqu'un qui n'a pas peur de lire p lutôt qu'à quelqu'un qui prétend tout connaître de J2EE, ce qui est imp ossible.
...
Quand la techno est choisie, sur des arguments solides, il est toujours temps de se plongeant dans la doc tech nique.
C'est un peu contradictoire, non ? Comment choisir la technologie "sur des arguments solides" sans connaitre la partie technique ?
D'ailleurs je pense que ce n'est probablement pas le meme metier, choisir la technologie releve de l'architecture, implementer du developpement. Evidemment, sur un petit projet c'est souvent la meme personne qui fait les deux.
David JOURAND
Bonjour,
Quand la techno est choisie, sur des arguments solides, il est toujours temps de se plongeant dans la doc technique.
C'est un peu contradictoire, non ? Comment choisir la technologie "sur des arguments solides" sans connaitre la partie technique ?
Par "doc technique" j'entendais les APIs... Il n'y a donc rien de contradictoire : on peut comprendre la techno sans en connaitre les APIs sur le bout des doigts.
D'ailleurs je pense que ce n'est probablement pas le meme metier, choisir la technologie releve de l'architecture, implementer du developpement.
Peut être est-ce une des raison que tant de projets n'arrivent pas à leur terme ou dans des délais bien supérieurs à ce qui avait été prévu, ou qui ne correspondent pas du tout (ou plus) au besoin...
Je suis adepte des méthodologies agiles, où chacun est architecte et développeur.
Evidemment, sur un petit projet c'est souvent la meme personne qui fait les deux.
C'est aussi possible sur des projets un peu plus importants. Ce serait aussi possible, amha, sur des projets beaucoup plus importants, si la volonté existait...
-- David Jourand
Bonjour,
Quand la techno est choisie, sur des
arguments solides, il est toujours temps de se plongeant dans la doc
technique.
C'est un peu contradictoire, non ? Comment choisir la technologie "sur
des arguments solides" sans connaitre la partie technique ?
Par "doc technique" j'entendais les APIs... Il n'y a donc rien de
contradictoire : on peut comprendre la techno sans en connaitre les APIs
sur le bout des doigts.
D'ailleurs je pense que ce n'est probablement pas le meme metier,
choisir la technologie releve de l'architecture, implementer du
developpement.
Peut être est-ce une des raison que tant de projets n'arrivent pas à
leur terme ou dans des délais bien supérieurs à ce qui avait été
prévu, ou qui ne correspondent pas du tout (ou plus) au besoin...
Je suis adepte des méthodologies agiles, où chacun est architecte et
développeur.
Evidemment, sur un petit projet c'est souvent la meme personne qui fait
les deux.
C'est aussi possible sur des projets un peu plus importants. Ce serait
aussi possible, amha, sur des projets beaucoup plus importants, si la
volonté existait...
Quand la techno est choisie, sur des arguments solides, il est toujours temps de se plongeant dans la doc technique.
C'est un peu contradictoire, non ? Comment choisir la technologie "sur des arguments solides" sans connaitre la partie technique ?
Par "doc technique" j'entendais les APIs... Il n'y a donc rien de contradictoire : on peut comprendre la techno sans en connaitre les APIs sur le bout des doigts.
D'ailleurs je pense que ce n'est probablement pas le meme metier, choisir la technologie releve de l'architecture, implementer du developpement.
Peut être est-ce une des raison que tant de projets n'arrivent pas à leur terme ou dans des délais bien supérieurs à ce qui avait été prévu, ou qui ne correspondent pas du tout (ou plus) au besoin...
Je suis adepte des méthodologies agiles, où chacun est architecte et développeur.
Evidemment, sur un petit projet c'est souvent la meme personne qui fait les deux.
C'est aussi possible sur des projets un peu plus importants. Ce serait aussi possible, amha, sur des projets beaucoup plus importants, si la volonté existait...
-- David Jourand
Laurent Bossavit
D'ailleurs je pense que ce n'est probablement pas le meme metier, choisir la technologie releve de l'architecture, implementer du developpement. Evidemment, sur un petit projet c'est souvent la meme personne qui fait les deux.
Et sur un grand projet, l'architecte est déjà parti depuis longtemps quand les ingés s'apercoivent que ce qu'il a choisi ne tient pas la route. ;)
Pour rester dans le "topic", la question était: Quelles compétences sont recherchées chez un Freelance ?
Question posée par quelqu'un qui, si j'ai bien compris, cherche à le devenir.
Il faut se demander: *pourquoi* a-t-on recours à un freelance ? Il y a les bonnes et les mauvaises raisons. Les mauvaises:
- parce que c'est de la main-d'oeuvre flexible: cf. ci-dessus, la flexibilité a des désagréments; le meilleur collaborateur d'un projet, c'est celui qui va rester sur le projet jusqu'à la fin et qui sait donc que s'il fout la zone en début de projet (mauvais code, mauvaise archi, mauvais recueil des besoins, etc.) c'est lui qui subira les conséquences;
- parce que son CV a les bons mots clé: les qualités d'une personne efficace sur un projet, ce n'est pas J2EE ou PHP ou XSLT ou whatever; c'est la capacité de tenir les promesses qu'il fait et de ne pas promettre plus qu'il (ou elle) ne sait tenir; la volonté d'apprendre et de s'améliorer; l'ouverture sur les autres y compris sur d'autres sujets que professionnels;
- parce qu'il est moins cher que les autres: la qualité ça se paye.
Les bonnes raisons:
- parce qu'il va transférer de la compétence à l'équipe permanente - parce qu'il apporte quelque chose de rare ou de neuf - parce qu'il apporte un regard critique sur ce est déjà là - parce qu'il exige de faire du bon boulot de bout en bout - parce qu'il est avant tout motivé par la réussite du client - parce que c'est une personne de confiance
Le freelance qui sait faire cela, qu'il soit architecte, ingénieur, testeur ou n'importe quoi, trouvera du travail sans peine et sera un excellent partenaire de l'entreprise. Lire la doc ou pas, c'est secondaire par rapport à tout ça...
Laurent
D'ailleurs je pense que ce n'est probablement pas le meme metier,
choisir la technologie releve de l'architecture, implementer du
developpement. Evidemment, sur un petit projet c'est souvent la meme
personne qui fait les deux.
Et sur un grand projet, l'architecte est déjà parti depuis longtemps
quand les ingés s'apercoivent que ce qu'il a choisi ne tient pas la
route. ;)
Pour rester dans le "topic", la question était:
Quelles compétences sont recherchées chez un Freelance ?
Question posée par quelqu'un qui, si j'ai bien compris, cherche à le
devenir.
Il faut se demander: *pourquoi* a-t-on recours à un freelance ? Il y a
les bonnes et les mauvaises raisons. Les mauvaises:
- parce que c'est de la main-d'oeuvre flexible: cf. ci-dessus, la
flexibilité a des désagréments; le meilleur collaborateur d'un projet,
c'est celui qui va rester sur le projet jusqu'à la fin et qui sait donc
que s'il fout la zone en début de projet (mauvais code, mauvaise archi,
mauvais recueil des besoins, etc.) c'est lui qui subira les
conséquences;
- parce que son CV a les bons mots clé: les qualités d'une personne
efficace sur un projet, ce n'est pas J2EE ou PHP ou XSLT ou whatever;
c'est la capacité de tenir les promesses qu'il fait et de ne pas
promettre plus qu'il (ou elle) ne sait tenir; la volonté d'apprendre et
de s'améliorer; l'ouverture sur les autres y compris sur d'autres sujets
que professionnels;
- parce qu'il est moins cher que les autres: la qualité ça se paye.
Les bonnes raisons:
- parce qu'il va transférer de la compétence à l'équipe permanente
- parce qu'il apporte quelque chose de rare ou de neuf
- parce qu'il apporte un regard critique sur ce est déjà là
- parce qu'il exige de faire du bon boulot de bout en bout
- parce qu'il est avant tout motivé par la réussite du client
- parce que c'est une personne de confiance
Le freelance qui sait faire cela, qu'il soit architecte, ingénieur,
testeur ou n'importe quoi, trouvera du travail sans peine et sera un
excellent partenaire de l'entreprise. Lire la doc ou pas, c'est
secondaire par rapport à tout ça...
D'ailleurs je pense que ce n'est probablement pas le meme metier, choisir la technologie releve de l'architecture, implementer du developpement. Evidemment, sur un petit projet c'est souvent la meme personne qui fait les deux.
Et sur un grand projet, l'architecte est déjà parti depuis longtemps quand les ingés s'apercoivent que ce qu'il a choisi ne tient pas la route. ;)
Pour rester dans le "topic", la question était: Quelles compétences sont recherchées chez un Freelance ?
Question posée par quelqu'un qui, si j'ai bien compris, cherche à le devenir.
Il faut se demander: *pourquoi* a-t-on recours à un freelance ? Il y a les bonnes et les mauvaises raisons. Les mauvaises:
- parce que c'est de la main-d'oeuvre flexible: cf. ci-dessus, la flexibilité a des désagréments; le meilleur collaborateur d'un projet, c'est celui qui va rester sur le projet jusqu'à la fin et qui sait donc que s'il fout la zone en début de projet (mauvais code, mauvaise archi, mauvais recueil des besoins, etc.) c'est lui qui subira les conséquences;
- parce que son CV a les bons mots clé: les qualités d'une personne efficace sur un projet, ce n'est pas J2EE ou PHP ou XSLT ou whatever; c'est la capacité de tenir les promesses qu'il fait et de ne pas promettre plus qu'il (ou elle) ne sait tenir; la volonté d'apprendre et de s'améliorer; l'ouverture sur les autres y compris sur d'autres sujets que professionnels;
- parce qu'il est moins cher que les autres: la qualité ça se paye.
Les bonnes raisons:
- parce qu'il va transférer de la compétence à l'équipe permanente - parce qu'il apporte quelque chose de rare ou de neuf - parce qu'il apporte un regard critique sur ce est déjà là - parce qu'il exige de faire du bon boulot de bout en bout - parce qu'il est avant tout motivé par la réussite du client - parce que c'est une personne de confiance
Le freelance qui sait faire cela, qu'il soit architecte, ingénieur, testeur ou n'importe quoi, trouvera du travail sans peine et sera un excellent partenaire de l'entreprise. Lire la doc ou pas, c'est secondaire par rapport à tout ça...
