Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Moins de 35 h
Entre 35 h et 40 h
Entre 40 h et 45 h
Entre 45 h et 55 h
+ de 55 h
Discussion :
D'une part, c'est la mediane, non pas la moyenne. D'autre part cela ne concerne que les "employés et opérateurs", pas les techniciens ou les ingénieurs.Envoyé par alex_vino
Sachant que dans l'informatique il y a beaucoup de moyen/haut salaire 4k-6k, comment peut-on arriver a 1400€ de moyenne.
Ils calculent comment a l'INSEE
Article tres interessant, mais je suis abasourdi par certains chiffres, surtout venant de sources fiables
Je sais plus ou mais j'avais déjà vu plusieurs articles avec des retours d'expérience qui expliquaient qu'il ne servait a rien de travailler un grand nombre d'heures car au bout d'un moment, avec la fatigue, on finit par faire du mauvais code qui au final coûtera plus cher au projet...
Alors si c'est pour pondre dans l'urgence du code de mauvaise qualité sous la pression et la fatigue, mieux vaut reporter à demain, arriver en forme et finir le boulot dans des bonnes conditions.
Si tout est toujours urgent, c'est qu'il y a clairement un problème...
[troll]Tu ne prends pas en compte ceux qui font du mauvais code à tête reposée.[/troll]
Plus sérieusement, 100% d'accord. Foutre la pression sur les devs et les faire trimer plus que leurs heures, ça trouve sa place dans l'extreme programming, l'urgence, le scotch, le copier/coller brutal, bref tout ce qui à long terme est contre productif et néfaste pour le moral de l'équipe et la qualité du projet.
Les cadres
Surtout quand ils sont cadres !
Je travaille un peu plus de 40h par semaine, ça dépend de beaucoup des événements des différents projets sur lesquels j'interviens (analyse, développement, validation, acceptance, support, etc.)Combien d’heures travaillez-vous par semaine ? (Votez sur le forum)
Seulement, il y a déjà deux heures/semaine de prévue en heure supplémentaire et encore deux heures que je récupère.
Je gagne environ 2300€ net, ce qui est beaucoup pour rester le cul assis sur une chaise avec des horaires de bureau (environ 8h-12h et 14h-18h).
Vu que le domaine de l'informatique est très large (service dépannage, montage/assemblage, support de niveau 1 à 3, service, édition, commerciale, consultant, etc.), c'est difficile de se faire une idée sur le "réalisme" de ce montant ; il faudrait avoir également le salaire moyen pour avoir une idée de la répartition.
Je dirai que c'est un peu juste si on compare au SMIC, puisqu'il s'agit généralement de technicien (bac+2/3).
Rester sur une chaise ne signifie pas que la valeur de notre travail est amoindri. Somme toute notre travail a de la valeur suivant ce qu'il produit/rapporte pour la société.
Personnellement, je ne valorise/n'estime pas la valeur de mon travail par ce qu'il génère mais par ce qu'il me coûte, notamment en pénibilité, difficulté, etc.
A salaire égale, je préfère mon boulot à celui d'un maçon, seulement, lui il gagne moins que moiEt en plus il doit se payer des frais de santé que je n'ai pas car en plus mon salaire comprends une complémentaire santé !
Sans compter que les seuls travaux indispensables sont ceux qui produisent directement...
Sans agriculteurs, sans ouvriers du batiment et du textile, sans éboueurs, nos compétences en informatique n'empêcheraient pas la civilisation de s'effondrer.
La rémuneration de chacun ne dépend que de sa valeur de marché, donc de l'offre et de la demande. D'où qu'un maçon a un travail plus pénible et plus important mais moins rémunéré; personne n'a dit que c'est juste. Le pire dans cette histoire, c'est que les tentatives de reformer cela ont (très) mal fini. Nature humaine, quand tu nous tiens....
Je crois me lire quand j'avais 20 ans et que j'étais fier de travailler et de faire mon petit trou... jusqu'au jour à je me suis rendu compte qu'en fait j'étais simplement exploité à mort... et que, bien évidemment, je n'ai rien eu en retour.
Relis toi dans quelques années, tu vas être surpris de ce que tu avais écrit à l'époque !
Ca n'a aucun rapport. Si tu fais en 4 heures le travail de 3 personnes (j'avais fait ça ici : le travail de 2 personnes sur 7 jours, réalisé en une matinée, et de manière plus fiable) alors à toi tout seul à la fin du mois, tu coute 2300 mais tu fais économiser 2 salaires.
Enfin à toi de voir
Perso j'ai signé un contrat 39h : soit 35h + 4h suppl. à 125%.
JE suis nouveau dans la boite et je ne compte pas le 1/4 suppl. tous les jours ...
Est-ce que tu fais économiser 2 salaires ou est-ce les autres qui surcoutent 2 salaires ? Il ne faudrait pas confondre ;-)
Ca me rappelle la discussion, êtes-vous un bon programmeur. La plupart du temps la réponse est : en absolu non, relativement à mon équipe oui. Donc quelle est la réponse "absolue" ?
ça dépend les critères que tu te donnes pour te juger bon, si tu te juges par rapport à ce que les autres pensent de toi, ce que tu produis, ...
Y'a surtout beaucoup de réponse possible.
Quel est le meilleur developpeur:
--Celui qui code son programme le plus vite?
--Celui qui code son programme avec le moins de bugs?
--Celui qui code son programme pour qu'il s'execute le plus vite possible, en prenant le moins de place possible sur le disque?
La question était purement rhétorique et n'avait qu'une seule conclusion : il ne faut pas être nombriliste mais voir les choses de manière beaucoup plus large pour bien relativisé ta position.
La seule réponse qui me vienne m' a été donné lors des mes maigres cours généraliste sur la qualité : un produit de bonne qualité est un produit qui répond au besoin ni plus, ni moins !
Donc un bon développeur est celui qui fera le minimum demandé sans en faire plus !
Même pas, à mon sens. Là, je viens de finir un projet ou on m'a demandé d'integrer des fichiers(souvent pourris) dans un traitement. J'ai rajouté, volontairement, hors specs, un traitement de "rejet" qui envoie un mail au fournisseur du fichier pour lui dire "ton fichier machin a été rejeté parceque le code banque est pourri". Parceque dans l'ancienne chaine, ça plantait tout le temps.
Résultat : au lieu d'avoir un truc qui plante en permanence et qu'il faut relancer à la mimine plusieurs fois par jour en trafiquant le fichier pour avoir un code banque correct, on a un système auto-protecteur(le fichier n'est intégré que si il est correct). Et qui, en plus, pousse l'équipe en amont à corriger ses traitements. Au bout de 3 mois, on a quasiment plus de rejets, et quand on en a, ça force à une modification pérenne et non pas à une bidouille de fichiers "la rache compliant" qu'il faudra refaire encore et encore.
La qualité, c'est la qualité produit(ce dont on t'a parlé), mais aussi la qualité process(ce que j'ai fait). Et aussi la qualité fournisseur, mais ça s'applique moins dans nos métiers. Dans l'automobile, par contre, c'est fondamental. Et c'est encore d'autres règles.
J'ai effectivement parlé de qualité produit.
Cependant la qualité process dans ton cas aurait été : J'ai détecté une limitation, vous devriez corrigé votre besoin (cahier des charges, task tracker, spécification, etc).
Car tu as un introduit un changement non tracé (et donc non recetté), d'un point de vue purement qualité, tu as introduit une anomalie (ie. un écart à la spécification).
De plus, tu as passé du temps sur une activité non prévue.
C'est bien beau en théorie mais quand tu as un client qui ne comprends rien à ce qu'il veut, quand on lui présente le produit tel qu'il l'a spécifié et te dit que c'est pas du tout ça qu'il voulait, et ceci régulièrement, tu fais quoi? Bah tu commences à prendre des initiatives et te dire "tiens, si j'étais le client, est-ce que ça serait pas mieux comme ça?".
En même temps une histoire assez drôle au boulot: sur un projet ou on avait rajouté un truc utile en plus gratuitement, le client râle:
- mais on vous a jamais demandé ça pourquoi vous l'avez fait?!"
- c'est bon on vous l'a pas fait payer...
- mais même on l'a jamais demandé!
- ah vous voulez qu'on l’enlève alors
- non
- bah vous le voulez alors?
- non
- bah on va l'enlever alors
- non ne l'enlevez pas
Des fois les mecs savent vraiment pas ce qu'ils veulent
C'est mon enfer au quotidien
En général, tu peux squizzer le truc car les spécifications sont bien floues. Ou alors on utilise également des exigences contradictoires.
Tu peux également utiliser des documents de relecture ou d'autres pour tracer les points, suggérer fortement la modification et demander un avenant. Si le client est flemmard (ne modifie pas ces spécifications), il te renvoie tes suggestions attaché dans l'avenant.
PS : évites de travailler dans le domaine aéronautique, spatiale ou automobile
EDIT: Si ton client ne suit/n'impose pas de processus qualité, il ne tient qu'à toi de t'y tenir ou pas !
C'est mon enfer au quotidien
PS : évites de travailler dans le domaine aéronautique, spatiale ou automobile
Mais justement, j'ai rajouté un aileron sur la fusée pour faire beau et ils sont pas contents
PS: je bosse dans l'automobile ^^
Possible, mais.....
J'ai eu une dizaine d'anomalies là-dessus, donc ça a été recetté quand même!!! dont 8 étaient des demandes d'amélioration déguisées, en fait. Si ils avaient été assez stupides pour se limiter à leur plan de recette, on ne serait pas allé bien loin, ni sur ce sujet, ni sur d'autres.
Le fait que ça soit moi qui soit en charge de bidouiller les fichiers en cas de plantage a du jouer, aussi.....
Je considère que notre métier est de faire une appli qui marche. Si un bricolo nécéssaire n'est pas spécifié(du genre, la gestion d'erreurs), mais qu'il est nécéssaire au bon fonctionnement de l'appli, il faut le faire quand même. Je demande à mon dentiste de me coller un bridge, si il a des opérations en plus à faire pour que ça tienne, ça n'est pas à moi de les spécifier.
Le produit(dans notre cas le fichier final produit) est tel que demandé, ni plus, ni moins. Le process, c'est à nous de le faire pour qu'il soit efficace. Mais se limiter bêtement à la spec, c'est en général aller dans le mur - sauf méthodes de type aérospatial qui coutent 10 fois plus cher(hypothèse basse).
Au final, si j'avais proposé le truc, ils auraient refusé, car "trop cher". En fait, je leur ai fait gagner du temps et de l'argent, et dès qu'ils ont vu le truc ils se sont jetés dessus en en demandant plus. C'est mal, mais ça marche.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager