La dernière année comprend justement des cours sur la création d'entreprise pour apprendre à bien monter sa boite, et notamment un gros rendu sur un projet ou tu dois défendre un projet de création d'entreprise
Après je sais pas ce que ça vaut j'en suis pas encore arrivé là
La dernière année comprend justement des cours sur la création d'entreprise pour apprendre à bien monter sa boite, et notamment un gros rendu sur un projet ou tu dois défendre un projet de création d'entreprise
Après je sais pas ce que ça vaut j'en suis pas encore arrivé là
C'est le cas de toute les écoles d'ingénieurs, de commerce et de management en dernière année, mais faut être réaliste 99% des projets ne seront jamais rentable car sois la technique est là mais niveau commercial sa coince et il faut trouver un associé en dehors de l'école, sois l'idée est là sur un PPT avec des couts estimé à la louche car sans connaitre la technique difficile d'estimé un prix pour une application et surtout aucune connaissance au niveau juridique et comptable. L'idéale serais que ce genre de projet sois fait en collaboration inter école, mais là c'est au niveau de l'humain que ça coince.
La plupart des gens de mon école voient dans un chef d'entreprise le métier de glande ultime, sans commercial, sans technique ou sous prétexte que l'entreprise t'appartiens du fait que tu en as eu l'idée tu délègues juste les rôles à d'autre en empochant la totalité de l'argent, c'est caricaturale mais il sacralise cette fonction pensant que les employés ne sont que les rouages d'une montre et qu'ils sont perdue et inutile sans l'horloger qui vas les assembler ( et le pire c'est qu'on me prend limite pour un communiste quand j'explique ça alors que je suis de tendance ultra libérale ... )
EDIT :
Après quelque recherche pour décortiquer le flou entre les fonctions de commercial, manager, chef de projet je suis tombé sur ceci : http://blogs.mediapart.fr/blog/mathieu/240212/ssii-societe-de-prostitution-neo-liberale-legale-partie-i ce qui correspond bien à mon expérience dans ce milieu et le nombre de "stage" de 6 mois avec proposition d'embauche en CDI de ces boites. Ainsi que l'image que j'ai du chef de projet/commercial, je me doute que c'est une vision apocalyptique mais ça fais peur de voir à quel point la technique est sous estimé au profit du commercial cela créant exactement l'effet inverse niveau productivité & motivation. Et pour finir cela http://decugis.blogspot.fr/2010/03/le-taux-de-reussite-des-grands-projets.html .
Je viens un peu après la bataille (des nuits à coder ca laisse pas le temps -_-) mais mon expérience c'est que dans les boites ou j'étais/suis, on cherche sur des lead développeurs plutôt que des managers. C'est à dire des gens avec une expertise technique suffisante pour développer et aider les autres à développer.
Niveau salaire c'est variable, ca dépend surtout de ton importance pour la boite, de tes qualités de négociateurs, etc...
(par exemple la je suis "simple" développeur prestataire et mieux payé que mon responsable client.
Je suis à la fois chef de projets et développeur. J'ai vécu cette dualité que ce soit en SSII ou en interne. Pour des projets les plus petits en ressources (genre... que moi, sans compter la maà®trise d'ouvrage) mais aussi des projets faramineux en terme de budget, de défis techniques et d'interlocuteurs multiples (que j'appelle les projets "Star Trek").
Voilà bien longtemps que j'ai compris que prendre par la main la maitrise d'ouvrage (équipe marketing, directeur financier, comptable, que sais-je encore) fait parti du boulot de chef de projet, si l'on veut éviter le pire à savoir : "Vous avez fait ce que j'ai demandé, mais ce n'est pas ce que je veux". Ainsi la plupart du temps je rédige leur cahier des charges.
Je n'ai pas de problème de reconnaissance, visiblement on me fait confiance.
Le bémol toutefois est lorsque je suis confronté à des décisions purement politique (dont les tenants et aboutissants m'échappent souvent) qui font capoter un projet. J'ai quitté (volontairement) plusieurs boites à cause de cela.
Le bémol toutefois est lorsque je suis confronté à des décisions purement politique (dont les tenants et aboutissants m'échappent souvent) qui font capoter un projet. J'ai quitté (volontairement) plusieurs boites à cause de cela.
Un projet est animé par trois forces :
- la technique (la maà®trise d'oeuvre, les développeurs),
- le besoin (la maà®trise d'ouvrage, les utilisateurs),
- et la stratégie (la politique, le sponsor)
Si ces trois forces tirent dans le même sens le projet a de bonnes chances de réussir. Dans le cas contraire ...
Plus le projet est gros et plus il y a de politique. Si vous pensez que les projets capotent à cause de la politique, prenez conscience que s'il n'y avait pas de politique il n'y aurait pas de projet. Au départ d'un gros projet il y a toujours un type qui a une forte volonté de changement et qui met le pognon pour ça.
Entre autre raisons, il est assez courant qu'un projet capote par une résistance au changement des utilisateurs ; lorsque les besoins qui sont exprimés ne vont pas dans le sens de la stratégie qui a été définie (plus ou moins explicitement). Dans ce cas là , le maà®tre d'oeuvre peut avoir le sentiment de se retrouver entre le marteau et l'enclume, et généralement comme il est souvent externe c'est lui qui paye les pots cassés !
Vos différents entre chefs de projet et clients me rappelle tout à fait ce que j'ai vécu en interne de ma boà®te pendant 25 ans!
Travaillant en recherche avec des scientifiques, je devais, suivant cahier des charges (?), concevoir, réaliser, essayer puis livrer au scientifique demandeur l'appareil de test introuvable dans le commerce.
Grosso modo cela se passait ainsi (de manière symbolique):
- Voila le cahier des charges, il te faut combien de temps pour nous faire l'appareil ?
- laissez moi évaluer la chose en fonction de ce que vous avez mis dans ce cahier.
- Oui, mais 2 mois ça te suffira ?
24h après
- A vue de nez et après avoir évalué le CDC il me faut 3 mois et demi plus ou moins une semaine et tel budget.
- Bon d'accord tu as le feu vert et tu imputes sur le budget machin-truc.
Connaissant assez bien mes demandeurs, sur le mouton à 5 pattes qu'ils demandaient j'ajoutais une sixième patte, une deuxième queue et j'ajoutais des cornes, des rondes et des carrés, faisant du mouton à 5 pattes un animal absolument innommable ! Puis je livrais l'appareil avec un retard d'une ou deux semaines. Mais durant ces quatre mois le scientifique avait réfléchi ce qui donnait un dialogue du genre suivant lors de la livraison:
- tu vois j'ai ajouté telle et telle possibilités à ce que tu demandais, ça te va?
- ah oui c'est bien, .... Mais tu n'as pas mis d'ailes !
- Ben non, tu voulais un mouton à 5 pattes, pas un dragon! (rien à voir avec toi Draken)
- Ouais mais vu l'évolution de l'étude, les ailes me seraient bien utiles. Bon je garde l'appareil, refais le même avec des ailes.
- deux, quatre ou huit ailes? Non, écris moi plutôt une annexe à ton cahier des charges.
- D'accord, tu l'auras demain au courrier interne.
Tablier, tu as mis en avant tout les problèmes de la conduite de projet traditionnelle (waterfall).
Bien sur, c'est mon expérience entre 1967 et 1992-95. Et dans une entreprise de recherche très hiérarchisée, chapeautée par des X en pagaille, "la conduite agile" c'était strictement inconnu et je dirai même impossible!
Oui, mais en SSII, je pense que c'est la seule manière d'avoir de la souplesse tout en respectant un budget figé à l'avance et en tenant compte des compétences de l'équipe affectée au projet.
Cela consiste généralement à être souple sur des changements acceptables, c'est-à -dire
-qui ne remettent pas en cause l'architecture,
-qui ne sont pas clairement hors du budget prédéfini,
-qui sont compatibles avec la compétence de l'équipe (mais ça on le dit pas au client),
-qui touchent des parties non encore développées ou facilement modifiables.
Autrement dit, il faut se donner la latitude de lâcher des trucs pour pouvoir se battre sur des trucs plus conséquent.
Parfois un petit rien peut faire plaisir au client et ensuite il sera plus enclin à accepter un truc qui arrange l'équipe.
C'est clairement horrible de travailler dans des conditions pareils non ? Niveau Stress et reconnaissance de devoir s'adapter aux réclamations d'un client qui vas changer d'avis car lui même ne sais pas ce qui lui faut ? Et j'imagine que en cas d'échecs cela retombe sur l'équipe technique ?
Réponses
La dernière année comprend justement des cours sur la création d'entreprise pour apprendre à bien monter sa boite, et notamment un gros rendu sur un projet ou tu dois défendre un projet de création d'entreprise
Après je sais pas ce que ça vaut j'en suis pas encore arrivé là
C'est le cas de toute les écoles d'ingénieurs, de commerce et de management en dernière année, mais faut être réaliste 99% des projets ne seront jamais rentable car sois la technique est là mais niveau commercial sa coince et il faut trouver un associé en dehors de l'école, sois l'idée est là sur un PPT avec des couts estimé à la louche car sans connaitre la technique difficile d'estimé un prix pour une application et surtout aucune connaissance au niveau juridique et comptable. L'idéale serais que ce genre de projet sois fait en collaboration inter école, mais là c'est au niveau de l'humain que ça coince.
La plupart des gens de mon école voient dans un chef d'entreprise le métier de glande ultime, sans commercial, sans technique ou sous prétexte que l'entreprise t'appartiens du fait que tu en as eu l'idée tu délègues juste les rôles à d'autre en empochant la totalité de l'argent, c'est caricaturale mais il sacralise cette fonction pensant que les employés ne sont que les rouages d'une montre et qu'ils sont perdue et inutile sans l'horloger qui vas les assembler ( et le pire c'est qu'on me prend limite pour un communiste quand j'explique ça alors que je suis de tendance ultra libérale ... )
EDIT :
Après quelque recherche pour décortiquer le flou entre les fonctions de commercial, manager, chef de projet je suis tombé sur ceci : http://blogs.mediapart.fr/blog/mathieu/240212/ssii-societe-de-prostitution-neo-liberale-legale-partie-i ce qui correspond bien à mon expérience dans ce milieu et le nombre de "stage" de 6 mois avec proposition d'embauche en CDI de ces boites. Ainsi que l'image que j'ai du chef de projet/commercial, je me doute que c'est une vision apocalyptique mais ça fais peur de voir à quel point la technique est sous estimé au profit du commercial cela créant exactement l'effet inverse niveau productivité & motivation. Et pour finir cela http://decugis.blogspot.fr/2010/03/le-taux-de-reussite-des-grands-projets.html .
Je viens un peu après la bataille (des nuits à coder ca laisse pas le temps -_-) mais mon expérience c'est que dans les boites ou j'étais/suis, on cherche sur des lead développeurs plutôt que des managers. C'est à dire des gens avec une expertise technique suffisante pour développer et aider les autres à développer.
Niveau salaire c'est variable, ca dépend surtout de ton importance pour la boite, de tes qualités de négociateurs, etc...
(par exemple la je suis "simple" développeur prestataire et mieux payé que mon responsable client.
Je suis à la fois chef de projets et développeur. J'ai vécu cette dualité que ce soit en SSII ou en interne. Pour des projets les plus petits en ressources (genre... que moi, sans compter la maà®trise d'ouvrage) mais aussi des projets faramineux en terme de budget, de défis techniques et d'interlocuteurs multiples (que j'appelle les projets "Star Trek").
Voilà bien longtemps que j'ai compris que prendre par la main la maitrise d'ouvrage (équipe marketing, directeur financier, comptable, que sais-je encore) fait parti du boulot de chef de projet, si l'on veut éviter le pire à savoir : "Vous avez fait ce que j'ai demandé, mais ce n'est pas ce que je veux". Ainsi la plupart du temps je rédige leur cahier des charges.
Je n'ai pas de problème de reconnaissance, visiblement on me fait confiance.
Le bémol toutefois est lorsque je suis confronté à des décisions purement politique (dont les tenants et aboutissants m'échappent souvent) qui font capoter un projet. J'ai quitté (volontairement) plusieurs boites à cause de cela.
Un projet est animé par trois forces :
- la technique (la maà®trise d'oeuvre, les développeurs),
- le besoin (la maà®trise d'ouvrage, les utilisateurs),
- et la stratégie (la politique, le sponsor)
Si ces trois forces tirent dans le même sens le projet a de bonnes chances de réussir. Dans le cas contraire ...
Plus le projet est gros et plus il y a de politique. Si vous pensez que les projets capotent à cause de la politique, prenez conscience que s'il n'y avait pas de politique il n'y aurait pas de projet. Au départ d'un gros projet il y a toujours un type qui a une forte volonté de changement et qui met le pognon pour ça.
Entre autre raisons, il est assez courant qu'un projet capote par une résistance au changement des utilisateurs ; lorsque les besoins qui sont exprimés ne vont pas dans le sens de la stratégie qui a été définie (plus ou moins explicitement). Dans ce cas là , le maà®tre d'oeuvre peut avoir le sentiment de se retrouver entre le marteau et l'enclume, et généralement comme il est souvent externe c'est lui qui paye les pots cassés !
Vos différents entre chefs de projet et clients me rappelle tout à fait ce que j'ai vécu en interne de ma boà®te pendant 25 ans!
Travaillant en recherche avec des scientifiques, je devais, suivant cahier des charges (?), concevoir, réaliser, essayer puis livrer au scientifique demandeur l'appareil de test introuvable dans le commerce.
Grosso modo cela se passait ainsi (de manière symbolique):
- Voila le cahier des charges, il te faut combien de temps pour nous faire l'appareil ?
- laissez moi évaluer la chose en fonction de ce que vous avez mis dans ce cahier.
- Oui, mais 2 mois ça te suffira ?
24h après
- A vue de nez et après avoir évalué le CDC il me faut 3 mois et demi plus ou moins une semaine et tel budget.
- Bon d'accord tu as le feu vert et tu imputes sur le budget machin-truc.
Connaissant assez bien mes demandeurs, sur le mouton à 5 pattes qu'ils demandaient j'ajoutais une sixième patte, une deuxième queue et j'ajoutais des cornes, des rondes et des carrés, faisant du mouton à 5 pattes un animal absolument innommable ! Puis je livrais l'appareil avec un retard d'une ou deux semaines. Mais durant ces quatre mois le scientifique avait réfléchi ce qui donnait un dialogue du genre suivant lors de la livraison:
- tu vois j'ai ajouté telle et telle possibilités à ce que tu demandais, ça te va?
- ah oui c'est bien, .... Mais tu n'as pas mis d'ailes !
- Ben non, tu voulais un mouton à 5 pattes, pas un dragon! (rien à voir avec toi Draken)
- Ouais mais vu l'évolution de l'étude, les ailes me seraient bien utiles. Bon je garde l'appareil, refais le même avec des ailes.
- deux, quatre ou huit ailes? Non, écris moi plutôt une annexe à ton cahier des charges.
- D'accord, tu l'auras demain au courrier interne.
Et c'était reparti pour un tour !!!!!!
Tablier, tu as mis en avant tout les problèmes de la conduite de projet traditionnelle (waterfall).
Ce genre de problème n'arrive pas avec la conduite agile (enfin ca arrive moins).
On pourrait comme ça coller à la demande du client mais :
- pour un coût supérieur à celui de l'agile
- avec l'inconvénient que tant que le client ne voit rien de concret les meetings sont peu efficaces
Bien sur, c'est mon expérience entre 1967 et 1992-95. Et dans une entreprise de recherche très hiérarchisée, chapeautée par des X en pagaille, "la conduite agile" c'était strictement inconnu et je dirai même impossible!
Oui je comprends mieux
Par contre les grosses boites ont du mal à évoluer ^^
Cela consiste généralement à être souple sur des changements acceptables, c'est-à -dire
-qui ne remettent pas en cause l'architecture,
-qui ne sont pas clairement hors du budget prédéfini,
-qui sont compatibles avec la compétence de l'équipe (mais ça on le dit pas au client),
-qui touchent des parties non encore développées ou facilement modifiables.
Autrement dit, il faut se donner la latitude de lâcher des trucs pour pouvoir se battre sur des trucs plus conséquent.
Parfois un petit rien peut faire plaisir au client et ensuite il sera plus enclin à accepter un truc qui arrange l'équipe.
(Ou pas, il y a des salauds comme partout...)
C'est clairement horrible de travailler dans des conditions pareils non ? Niveau Stress et reconnaissance de devoir s'adapter aux réclamations d'un client qui vas changer d'avis car lui même ne sais pas ce qui lui faut ? Et j'imagine que en cas d'échecs cela retombe sur l'équipe technique ?