En fait, la raison d'embaucher en cdd c'est une question de visibilité et d'honnêteté.
Visibilité : je ne suis pas certain que la tendance actuelle continue. Dans 6 mois, la tendance sera plus sûre.
Honnêteté : je pourrais proposer un CDI, période d'essai renouvelée et, si la tendance ne se confirme pas, interrompre le contrat. C'est juste pas très réglo.
Après, faire un cdd puis cdi, c'est une manière honnête - je pense, de prendre un risque. Maîtrisé dans un premier temps - je connais le coût global pour un cdd de 6 mois, puis plus risqué ensuite - pas de visibilité réelle sur un cdi, mais expérience avec le collaborateur et meilleure vision de la tendance.
Après, je pourrais aussi faire un cdi direct en prenant le risque dès le debut (pour moi et pour le salarié sans qu'il le sache)… c'est aussi histoire d'être fier de ce que je fais : je suis transparent, je ne fais pas de coup fourré (enfin je pense).
Recruter quand tu es une très petite structure, c'est un risque (et un stress), qu'on n'imagine pas forcément quand on est salarié… mais j'ai qu'une envie : recruter cette personne et transformer en cdi.
Merci pour cette récompense. Ceci étant dit, je suis déjà abonné à Linux Magazine France par l'intermédiaire de algoo (ma société) ; du coup je vous propose : soit d'offrir l'abonnement à quelqu'un d'autre, soit de le convertir en un bouquin (il y en a pas mal d'intéressants que je n'ai pas encore achetés;).
Et dans tous les cas, merci pour votre super boulot !
En quoi avoir une part variable est un problème ?
C'est un problème parce que ton employeur peut spontanément décider de ne peut t'octroyer la part variable sans aucune raison.
Non. Une part variable doit être basée sur des conditions s'appuyant sur des critères précis : objectifs, CA généré, etc. Et l'employeur ne peut pas décider spontanément que tu n'as pas atteint les objectifs car c'est contractuel.
Je pense que ce à quoi tu fais référence c'est une part variable sans critères précis. Mais fondamentalement, avoir une part variable est légal, et il y a des métiers où c'est très classique (typiquement les métiers commerciaux). Par ailleurs si tu as un contrat qui stipule que tu as une part variable sans préciser les modalités d'octroit ou non de la part variable, je ne sais pas si c'est illégal ou simplement caduque, si tu as des liens je suis preneur.
Bonjour tintin_chez_blaireaux_land. Comme tu as créé un compte spécialement pour rédiger ce journal, je me dis (à tord peut-être?) que ton propos est ironique par rapport au journal de référence.
Dire qu'une "ESN" cherche à tout prix à baiser les salariés c'est exactement comme dire "les salariés sont tous des jemenfoutistes qui comptent leurs 35h et en font le moins possible".
Il y a 2 techniques sans entube que tu n'as pas évoquées pour réduire la masse salariale :
recruter des profils moins élevés quand le travail le permet. Inutile d'embaucher des ingés systématiquement
recruter des collaborateurs qui ne sont pas systématiquement dans la confrontation. (on ne parle pas de pigeons, on parle de personnes qui cherchent des solutions plutôt que de simplement soulever des problèmes)
Je pourrais aussi évoquer le montage d'antennes à l'île Maurice ou en Thaïlande, mais on n'est plus dans la même philosophie
Il existe également des techniques pour "ne pas se faire baiser" quand on cherche à gagner sa vie avec un boulot technique :
faire jouer la concurrence en cherchant sur plusieurs postes en parallèle et négocier
demander plus que ce que l'on veut pour obtenir ce que l'on attend
se faire recruter par des boîtes qui paient bien
se mettre à son compte
savoir écouter et prendre du recul. Nelson Mandela disait "soit je gagne, soit j'apprends". Si tu te fais baiser une fois et que tu l'admets, tu te feras pas avoir la prochaine fois.
prendre en considération l'intérêt technique du boulot en complément de l'intérêt financier
prendre en considération ce que l'on va apprendre
choisir un manager plutôt qu'un boulot (en gros, choisir le taff ou tu "sens" le mieux ton futur chef, parce qu'un bon manager te fera progresser plus vite et de manière plus agréable/intéressante qu'un "petit chef" qui va juste te filer le taff qu'il veut te laisser faire)
Un dernier truc : tant que tu auras l'impression que c'est de la prostitution de chercher un boulot et passer des entretiens pour "vendre" tes compétences, je pense que tu seras déçu de l'importance qu'on t'accorde. Le problème n'est probablement pas "combien on paie pour ton cul" mais que de toute façon tu considères que ces négociations sont dégradantes (mais ces négociations sont de toute façon un passage obligé) et que tu es convaincu qu'on patron va toujours chercher à te baiser.
Et il semblerait que la part variable se fasse de plus en plus (suivant si on est en contrat ou pas), en tout cas ça vient d’arriver dans ma boîte.
En quoi avoir une part variable est un problème ? Ca n'est ni bien ni mal, tout dépend du niveau de ton fixe et des modalités de la part variable.
Mon frère est persuadé d’être à 36k. J’ai pas osé lui dire qu’il était à 33k grand max (sans compter les heures supp’ qu’il a pu faire…).
Lol. Si déjà entre confrères et même frangins vous ne vous aidez pas pourquoi quelqu'un qui va "exploiter" ton travail devrait le faire ?! (exploiter au sens : tu fais un boulot pour que ton entreprise en tire un profit - ça peut être abusif comme ça peut être "normal")
Il en manque sûrement beaucoup, je n’ai qu’un an de bouteille dans le métier.
[…]
Globalement l’informatique a bénéficié d’une exception économique pendant des décennies. Je m’attends plutôt à une déflation salariale dans les années qui vont suivre, surtout au vu de la mentalité qui règne en informatique.
Je t'invite à prendre un peu plus de recul ; tu as un an d'expérience et tu es déjà capable de tirer des conclusions sur le marché et le métier ?!
Bref si moins cher de productivité au moins aussi bonne qu'au bureau
Sur le sujet de la productivité ça se discute. Le travail en équipe est parfois bien plus efficace sur un tableau blanc, et les solution à distance ne sont pas encore au niveau.
Par ailleurs, en terme relationnel, la communication n'est pas toujours géniale (ils faut des personnes compétentes pour la communication et le travail à distance, et ce des 2 cotés)
En dernier lieu, pas mal d'info transite de manière informelle dans l'entreprise, ce qui devient plus difficile à distance.
Il ne faut pas voir uniquement la productivité du tele-travailleur, mais aussi celle des collègues et d'une manière plus globale celle de l'équipe.
Heureux de voir que je ne suis pas seul à considérer la recherche d'emploi comme de la prostitution. (au moins les putes sont consentantes, elles)
Les putes ne sont pas plus consentantes que n'importe quelle personne qui cherche un taff. Outre le côté méprisant de ton message vis-à-vis des prostituées, tu te positionnes en victime lorsque tu cherches un boulot. Rien ne t'empêche de ne pas «chercher un taff» : tu peux vendre tes compétences et non ta personne (ce que font les freelances en général), ou encore être tellement bon ou connu pour qu'on vienne te recruter et non l'inverse.
Et si on n'a pas les gens qui vont bien, on peut mettre en place toutes les méthodes qu'on veut, le résultat ne sera jamais terrible et ça prendra toujours plus longtemps que nécessaire. La clé, c'est de recruter les bonnes personnes pour construire une équipe efficace et qui se complète bien. Le reste, ça va plutôt tout seul.
Entre deux équipes qui sont bien constituées, celle qui met en place (en plus) des méthodes de travail sera probablement meilleure.
Personnellement, un des trucs qui m'a toujours le plus plu dans ce métier (note : on bossait sur des applications métier, pas des sites web),
Je ne sais pas ce que tu entends par "faire des sites web" ; on ne fait pas de sites web, on fait des applications web. On ne peut pas comparer "développer une application métier" et "développer une application web" car il s'agit d'aspects orthogonaux : une appli web, ça parle des technologies, une appli métier de la finalité.
c'est la capacité à découvrir des métiers totalement différents et de s'en imprégner, c'est vraiment super enrichissant et motivant. Et je pense qu'on devrait mettre cela plus en avant.
Je te rejoints totalement, et c'est bien pour ça qu'on développe des applications web et non des sites web.
Notre métier n'est pas de faire du graphisme mais de comprendre les besoins des utilisateurs (professionnels ou pas) et de leur proposer des outils qui résolvent un certain nombre de leurs problèmes.
Deux exemples sur des projets qu'on a fait l'an dernier :
une plateforme de mise en relation entre éditeurs de logiciels et acheteurs. C'est pas notre métier, nous on est réalisateurs. Mais notre client c'est son métier de faire ça, et ce qu'on développe c'est un outil qui répond à ses besoins (il faut donc comprendre son métier)
une plateforme de multidiffusion d'annonces immobilières. C'est pas notre métier de faire de l'immobilier, mais une fois que tu comprends le quotidien des agents immobiliers ciblés, tu comprends rapidement quelle valeur ajoutée tu peux/dois leur proposer.
C'est sûr on fait aussi du graphisme, on construit des écrans "responsive", mais notre différenciateur, ça n'est pas de faire un site beau et qui s'adapte à l'écran de l'utilisateur - ça tu prends n'importe quelle agence web et si tu paies correctement tu es sûr d'avoir un bon résultat ; notre différenciateur c'est d'être capable de comprendre les besoins exprimés et non exprimés et de conseiller et accompagner le client.
Bref, tout ça pour dire qu'on fait bien des applications métier et qu'on est très content de le faire - pour les même raisons que toi :)
Réduire les coûts sans se soucier des impacts ou seulement de la qualité, je ne trouve pas que ça soit "naturel".
Personne n'a dit que c'était sans se soucier des impacts. Réduire les coûts c'est naturel, et toute personne qui met en concurrence 2 offres le fait. Qu'il s'agisse de professionnels et de particuliers.
Ca ne veut pas dire ne pas se soucier des impacts ni de la qualité, ça veut juste dire : "si tu peux payer moins cher pour le même produit/service, tu le fais". En tout cas, quand tu achètes, ça entre en ligne de compte.
La question "est-ce que c'est le même service" est une autre question et c'est de la responsabilité des personnes concernées d'expliquer que non ça n'est probablement pas le même service.
cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire
Pas du tout: c'est justement quand on ne sait pas exactement ce qu'il faut faire qu'il faut réfléchir.
On sait ce qu'on veut à court terme, mais on est en général incapable de savoir ce qu'il faudra avoir dans 1 an ou dans 2 ans. Et dans ces conditions on n'anticipe pas sur la flexibilité à implémenter pour d'hypothétiques fonctionnalités qui pourraient arrivent dans quelques années.
Plus tu réfléchis en début de projet à toutes les problématiques, plus tu retardes la sortie et en particulier la sortie de la v1. Donc plutôt que retarder ta v1 pour "mieux prévoir ta v2, v3 et autre", tu sorts ta v1 au plus vite, et tu capitalise sur l'expérience de ta v1 pour définir ta v2. Et tu vas de proche en proche.
Le point 8 signifie : plus ton code est utilisable/testable par quelqu'un qui ne connait rien à rien de ta pile technologique, mieux c'est.
Si tu fais une appli web avec mongodb, redis, nginx, etc, si tu es capable de donner un outil qui "en un clic ou en une ligne de commande" fait tout le setup et permet à n'importe qui de le tester, c'est du temps gagné car des personnes non compétentes pourront te remonter des bugs (donc tu pourras arriver à un niveau de qualité équivalent en passant toi-même moins de temps à tester)
Dans l'hypothèse où l'on aurait commencé par le développement, puis écrit les tests, outre le fait qu'on prend le taureau par les cornes (on écrit la solution avant d'avoir écrit les spécifications), le risque est d'avoir conçu une solution qui ne va pas répondre à 100% des besoins, ce qui veut dire qu'on doit faire du refactoring ou qu'on accepte une couverture partielle des besoins.
Pour moi tu passe à coté. Ce n'est pas le fait de commencer par l'un ou par l'autre qui va changer quoi que ce soit. C'est le fait ta façon de communiquer avec l'utilisateur/le product owner/le client (appel le comme tu veux) qui va changer cela. Et le TDD n'aide pas vraiment à faire ça. C'est plus le BDD car il va permettre de faire valider les tests par le client (l'objectif théorique étant que ce soit le client qui écrive les tests).
Bah le TDD permet d'écrire la spec (en termes de dév, certes, mais au moins ça définit le fonctionnement). Le BDD est une extension de ça et va plus loin.
Mais globalement ce que j'essaie d'exprimer c'est ce que tu dis (avec probablement un vocabulaire plus modeste sur le sujet;)
le principe est simple : "un module = une responsabilité". Et inversement.
Si le concept est simple son application ne l'est pas vraiment. C'est quoi une responsabilité ? C'est quoi un module ? Une classe ? Une fonction ? Quelle est la granularité de tes responsabilités ? Je pense savoir faire un découpage correct et appliquer des pattern qui vont me permettre de définir les abstractions correctes entre les responsabilités, mais de là à affirmer que je produit quelque chose de bon, je ne m'avancerais pas.
Il n'y a pas de règle pour dire "granularité trop faible" ou "granularité trop importante". Ce qui compte, c'est déjà de se poser la question, et souvent naturellement on va se rendre compte que des composants sont à responsabilité multiple ou responsabilité éclatée.
Et on travaille rarement seul, donc si tu discute sur un module donné, tu vas probablement arriver à un consensus.
Enfin qu'est-ce qu'un module, bah tout dépend du niveau de vision que tu as. Ca peut être une classe, une fonction, un ensemble de classes… tout dépend des technos que tu utilises, mais globalement "plus tes composants peuvent être considérés comme des boîtes noires, mieux c'est".
Souvent les développeurs veulent faire des choses compliquées, et exploiter les fonctionnalités d'un langage au maximum. Mais la réalité c'est qu'un logiciel qui est écrit simplement fonctionne aussi bien qu'un logiciel exploitant toutes les particularités d'un langage.
C'est exact, mais cela néglige complètement l'aspect maintenance (et aussi l'aspect apprentissage). Si une version, en plus d'être plus courte, est plus facile à maintenir, il n'y a aucune raison de ne pas la retenir!
Non justement, l'aspect maintenance est au coeur de cette remarque. Tu ne peux pas présumer du niveau d'expertise du développeur qui fera la maintenance de ton code. Pour caricaturer, si ton code est maintenable par un développeur qui ne connait pas ta techno, c'est une bonne chose.
En python (la techno sur laquelle je travaille beaucoup), il y a des moyens de rendre le code tellement concis que tu es obligé de le lire à voix haute, voire de le réécrire en structure classique pour être sûr de ce qu'il fait (et encore). C'est 3 lignes de code économisées pour un niveau de crainte complètement disproportionné quand tu cherches à comprendre/faire évoluer le code.
Exemple de code trop concis :
msg = "Hi " + ("there" if not name else ("Neo" if name == "Anderson" else name))
(ne ris pas, ça existe ce genre de code;)
(et encore, là c'est pas imbriqué dans des boucles et des set de listes de générateurs;)
Technique n°2 — se limiter strictement au cahier des charges
Parfois, en tant que développeur, on se dit "ah mais si je fais ça de telle manière, ça prend juste quelques jours de plus et ça permet d'avoir un système plus évolutif". Et en général plus complexe, donc plus fragile.
Oui et non, vu que très certainement il va falloir faire la maintenance du logiciel, cela peut être une bonne chose de s'y préparer – avec discernement, mais c'est justement ce discernement que peut apporter l'expérience au travers d'une palette de techniques éprouvées et validées qui résolvent justement ce problème.
D'une manière générale (et je m'inclus dans le lot), la tendance est de sur-anticiper les attentes des futurs développements. Si tu as une bonne couverture de test, tu peux faire du refactoring conséquent en limitant les risques.
Je te rejoins sur le fait que c'est avec l'expérience qu'on est capable de mieux en mieux de déceler ce qu'il serait bon d'anticiper et ce qui ne l'est probablement pas. Sans jamais en être certain.
Disons que si on se limite strictement au cahier des charges de façon la plus littérale qui soit, on peut dans certains cas torcher un programme tout mal fichu “qui fait le job” mais dont les évolutions sont impossibles à partir de 4-5 itérations, et là on se retrouve dans la pire situation, avec un bug en prod et un logiciel tellement mal conçu que réécrire tout ou partie est un a priori nécessaire à la réparation! (Vécu.)
Dans ce contexte, je parles d'un cahier des charges qui vient aussi avec des perspectives d'évolution.
Dans le contexte dans lequel je suis, je prends en compte non seulement les possibilités d'évolution, mais aussi les coûts associés. Et ça, peu de développeur le perçoivent. L'anticipation d'une feature qui viendra peut-être et qui fragilise le code au point que tu passes des plombes à stabiliser c'est un paquet d'argent perdu (ou investi) d'une manière ou d'une autre (et dans le cas où on considère que c'est investi, c'est un investissement avec quel chance d'être rentable ?)
Si tu sens qu'il y a une limitation dans le cahier des charges et que tu penses qu'il faut vraiment anticiper tel ou tel aspect, je te renvoie au point n°1 : en discuter avec le client. Ca ne t'apportera peut-être pas de réponse, mais ce qui est certain c'est que si tu n'en parles pas c'est un pari que tu fais.
Merci pour tes retours, qui m'invitent à leur tour à des remarques
Réduire les coûts sans sacrifier la qualité est évidemment intéressant pour l'entreprise ou le client car :
- soit vous avez la même chose pour un coût inférieur,
- soit vous avez un périmètre fonctionnel plus étendu pour le même prix.
Ce n'est pas totalement vrai. Les plus gros défauts des analyses de coûts que je peux lire sont systématiquement 1. qu'elles font l'hypothèse que l'univers peut être modélisé avec des additions et dans quelques cas extrêmes des multiplications, et 2. qu'elles ne décrivent pas assez soigneusement le système qu'elles étudient. Ici c'est le 2, car lorsque tu as livré ton produit, ton entreprise n'est plus la même! Tu as des développeurs qui ont acquis des connaissances, soit purement techniques, soit plus conceptuelles (techniques de programmation, techniques de génie logiciel, gestion de projet par exemple), par exemple.
Il n'empêche que c'est intéressant pour l'entreprise de pouvoir réduire les coûts pour une qualité équivalente. Ça n'est pas forcément LA solution à retenir (et en tout cas surtout pas la solution à retenir systématiquement). Après il faut savoir faire la distinction entre les cas où c'est à mettre en oeuvre et les cas où c'est à proscrire.
Et je te rejoins sur le fait que certains projets peuvent ne pas être concernés par "une rentabilité optimale en terme de temps de dév". Mais sur certains projets (au hasard, des dév sur des technos vieillissantes et des produits qui sont condamnés), on peut réduire les temps de dév sans "bacler le travail", ce qui permet de consacrer plus de temps à d'autres projets.
Il ne faut surtout pas écrire de script de setup. A moins de vraiment savoir ce qu'il faut faire (et encore) c'est probablement pas quelques heures et probablement un script sur lequel il faudra revenir.
Maintenant sur le besoin je suis parfaitement d'accord. Mais il ne faut surtout pas réinventer la roue. Utiliser ansible, chef, puppet ou, celui que je préfère, terraform. Du Terraform, une ou plusieurs machines sous CoreOS, des containers et ça en devient juste super agréable tout ça pour un coût limité, une très bonne répétabilité et un démarrage rapide.
Si certains veulent essayer voici un exemple qui montre par exemple comment faire tourner facilement un ElasticSearch en container sur un CoreOS via Terraform. C'est un exemple comme un autre mais je trouve qu'il montre plutôt bien l'intérêt de ces solutions.
Mettre au point un déploiement ansible/chef/puppet juste pour permettre à quelqu'un de faire un test, c'est clairement pas un gain de temps court-terme.
Un "script" tu mets ce que tu veux dedans - l'idée c'est que tu as en quelques heures un outil qui permet à n'importe qui de setup son environnement sans rien connaitre. Si tu veux mettre un docker derrière, CoreOS via terraform ou n'importe quoi, peu importe : ça dépend des compétences que tu as et des outils que tu connais.
Mais ce qui compte c'est que tu sois capable de fournir à un testeur, à un chef de projet, à un admin sys ou à n'importe qui une solution du type "tu lances cette commande et tu as l'appli dispo à telle adresse et configurée avec les données de base".
De manière plus générale, tu essaie de vendre l'idée que la qualité c'est simple, que ça ne prend pas de temps, etc et je ne te rejoins pas du tout là dessus.
Ce n'est pas du tout ce que je dis. Ce que je dis, c'est que pour un développement donné, tu peux souvent gagner en temps de travail sans réduire la qualité en mettant en oeuvre une certaine méthodologie
Je me cite : "Les stratégies 1 et 2 sont moins couteuses que la 3, mais la qualité est partiellement sacrifiée et le niveau de finition également en faveur d'un temps de développement réduit (à court terme)"
Faire de la qualité c'est compliqué, sinon tout le monde le ferais. Non seulement c'est compliqué, mais en plus c'est long à mettre en place.
On est d'accord :)
C'est un mensonge de commercial d'affirmer qu'on peut faire de la qualité en un minimum de temps à coût 0.
Personne ici n'a dit ça. Le seul truc que j'ai dit c'est que tu peux réduire ton temps de développement sans forcément perdre en qualité, je n'ai à aucun moment dit "tu peux faire du haut-de-gamme au prix du low-cost".
Je ne trouve pas du tout évident que la méthode 3 soit la plus coûteuse ou la plus lente. Partir sur un projet sans architecture et sans conception (en supposant que le projet soit assez simple pour le permettre) maximise les coûts très rapidement à cause du nombre de choses à faire et refaire, du nombre de bugs ou des mauvaises performances.
Si tu considères uniquement le temps de travail technique (développement, tests, conception, etc), la technique 3 est la plus économique. Mais cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire (si techniquement ce n'est pas un problème, c'est souvent un problème en terme de parts de marché)
Les techniques 1 et 2 sont les plus rapides pour arriver à un périmètre fonctionnel donné, ce qui permet rapidement :
de valider ou d'invalider des hypothèses,
dans le cas où on commercialise, de rentrer de l'argent et prendre des parts de marché.
Le time-to-market est un élément très important à prendre en compte, et dans ce contexte, plus tôt tu as un produit commercialisable (même si limite techniquement), plus tôt tu acquiers des clients, des parts de marché, donc également de la légitimité. Il faut bien voir l'économie comme une compétition et en particulier le monde des startups est féroce.
Pour ceux qui connaisent des jeux tels que starcraft, il y a une stratégie quand tu as les Zergs qui est d'aller tuer dans l'oeuf tes ennemis car en début de partie les Zergs ont un moment où ils sont en supériorité pour une durée donnée. C'est exactement la même chose avec les startups : faire un produit qui est sur le marché le plus vite possible va largement compliquer la vie des concurrents et donc conforter la place de leader du premier arrivé - et donc paradoxalement faire un produit un peu pourri techniquement pour arriver le premier est le meilleur gage de pérennité.
Par exemple le module pour integrer piwik est a plus de trente balle
30 balles ? Tu parles de faire du ecommerce et 30€ ça te bloque ? Je suis curieux de voir ton business plan.
(alors que c'est un truc ultra simple et que je parie que leur sonde n'est meme pas compatible cross canal (lan, wan, tor)).
Si c'est simple, je comprends pas pourquoi tu t'emm… à regarder les plugins au lieu de le faire toi-même.
En plus des modules proprio, voila quoi… > (Je prefere le systeme de bounty*1 d'autres cms)
*1 un site ou tu fais une annonce genre "j'ai besoin de telle fonctionnalité je met 50, 100, 200 euro" et le premier qui la code empoche le bounty et la fonctionnalité reste libre
Tu parles de faire du commerce… C'est du business.. Aucun pro ne développe sérieusement des fonctionnalités pour 50€.
Je suis curieux de savoir quel est ton métier et combien tu gagnes de l'heure.
[^] # Re: Pertinent
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message [poste pourvu] Poste ingénieur R&D en développement à Grenoble - CDD 6 mois en vue d'un CDI. Évalué à 3.
Merci pour la précision. Effectivement, le moinsage m'avait un peu blasé ;)
[^] # Re: petite question : pourquoi CDD de 6 mois et pas directement un CDI ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message [poste pourvu] Poste ingénieur R&D en développement à Grenoble - CDD 6 mois en vue d'un CDI. Évalué à 5.
Je t'invite à lire ceci :
https://www.cfdt.fr/portail/vos-droits/questions/reponses/cdi-suite-a-un-cdd-peut-on-echapper-a-la-periode-d-essai-prod_183490
Une période d'essai qu'on ne peut pas interrompre et qu'on paie 10% plus cher… je vois pas l'intérêt de déguiser quoi que ce soit…
Je suis preneur d'explications : ça m'évitera de faire la même erreur à l'avenir.
[^] # Re: petite question : pourquoi CDD de 6 mois et pas directement un CDI ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message [poste pourvu] Poste ingénieur R&D en développement à Grenoble - CDD 6 mois en vue d'un CDI. Évalué à 6.
En fait, la raison d'embaucher en cdd c'est une question de visibilité et d'honnêteté.
Visibilité : je ne suis pas certain que la tendance actuelle continue. Dans 6 mois, la tendance sera plus sûre.
Honnêteté : je pourrais proposer un CDI, période d'essai renouvelée et, si la tendance ne se confirme pas, interrompre le contrat. C'est juste pas très réglo.
Après, faire un cdd puis cdi, c'est une manière honnête - je pense, de prendre un risque. Maîtrisé dans un premier temps - je connais le coût global pour un cdd de 6 mois, puis plus risqué ensuite - pas de visibilité réelle sur un cdi, mais expérience avec le collaborateur et meilleure vision de la tendance.
Après, je pourrais aussi faire un cdi direct en prenant le risque dès le debut (pour moi et pour le salarié sans qu'il le sache)… c'est aussi histoire d'être fier de ce que je fais : je suis transparent, je ne fais pas de coup fourré (enfin je pense).
Recruter quand tu es une très petite structure, c'est un risque (et un stress), qu'on n'imagine pas forcément quand on est salarié… mais j'ai qu'une envie : recruter cette personne et transformer en cdi.
# Merci aussi
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primées de février 2017. Évalué à 3.
Salut,
Merci pour cette récompense. Ceci étant dit, je suis déjà abonné à Linux Magazine France par l'intermédiaire de algoo (ma société) ; du coup je vous propose : soit d'offrir l'abonnement à quelqu'un d'autre, soit de le convertir en un bouquin (il y en a pas mal d'intéressants que je n'ai pas encore achetés;).
Et dans tous les cas, merci pour votre super boulot !
[^] # Re: il en manque
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les salaires sans sacrifier la qualité. Évalué à 2.
Non. Une part variable doit être basée sur des conditions s'appuyant sur des critères précis : objectifs, CA généré, etc. Et l'employeur ne peut pas décider spontanément que tu n'as pas atteint les objectifs car c'est contractuel.
Non ça n'est pas illégal
Je pense que ce à quoi tu fais référence c'est une part variable sans critères précis. Mais fondamentalement, avoir une part variable est légal, et il y a des métiers où c'est très classique (typiquement les métiers commerciaux). Par ailleurs si tu as un contrat qui stipule que tu as une part variable sans préciser les modalités d'octroit ou non de la part variable, je ne sais pas si c'est illégal ou simplement caduque, si tu as des liens je suis preneur.
# journal ironique ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les salaires sans sacrifier la qualité. Évalué à 9.
Bonjour tintin_chez_blaireaux_land. Comme tu as créé un compte spécialement pour rédiger ce journal, je me dis (à tord peut-être?) que ton propos est ironique par rapport au journal de référence.
Dire qu'une "ESN" cherche à tout prix à baiser les salariés c'est exactement comme dire "les salariés sont tous des jemenfoutistes qui comptent leurs 35h et en font le moins possible".
Il y a 2 techniques sans entube que tu n'as pas évoquées pour réduire la masse salariale :
Je pourrais aussi évoquer le montage d'antennes à l'île Maurice ou en Thaïlande, mais on n'est plus dans la même philosophie
Il existe également des techniques pour "ne pas se faire baiser" quand on cherche à gagner sa vie avec un boulot technique :
Un dernier truc : tant que tu auras l'impression que c'est de la prostitution de chercher un boulot et passer des entretiens pour "vendre" tes compétences, je pense que tu seras déçu de l'importance qu'on t'accorde. Le problème n'est probablement pas "combien on paie pour ton cul" mais que de toute façon tu considères que ces négociations sont dégradantes (mais ces négociations sont de toute façon un passage obligé) et que tu es convaincu qu'on patron va toujours chercher à te baiser.
[^] # Re: il en manque
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les salaires sans sacrifier la qualité. Évalué à 2.
En quoi avoir une part variable est un problème ? Ca n'est ni bien ni mal, tout dépend du niveau de ton fixe et des modalités de la part variable.
Lol. Si déjà entre confrères et même frangins vous ne vous aidez pas pourquoi quelqu'un qui va "exploiter" ton travail devrait le faire ?! (exploiter au sens : tu fais un boulot pour que ton entreprise en tire un profit - ça peut être abusif comme ça peut être "normal")
Je t'invite à prendre un peu plus de recul ; tu as un an d'expérience et tu es déjà capable de tirer des conclusions sur le marché et le métier ?!
[^] # Re: Télétravail
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les salaires sans sacrifier la qualité. Évalué à 4.
Sur le sujet de la productivité ça se discute. Le travail en équipe est parfois bien plus efficace sur un tableau blanc, et les solution à distance ne sont pas encore au niveau.
Par ailleurs, en terme relationnel, la communication n'est pas toujours géniale (ils faut des personnes compétentes pour la communication et le travail à distance, et ce des 2 cotés)
En dernier lieu, pas mal d'info transite de manière informelle dans l'entreprise, ce qui devient plus difficile à distance.
Il ne faut pas voir uniquement la productivité du tele-travailleur, mais aussi celle des collègues et d'une manière plus globale celle de l'équipe.
[^] # Re: il en manque
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les salaires sans sacrifier la qualité. Évalué à 6.
Les putes ne sont pas plus consentantes que n'importe quelle personne qui cherche un taff. Outre le côté méprisant de ton message vis-à-vis des prostituées, tu te positionnes en victime lorsque tu cherches un boulot. Rien ne t'empêche de ne pas «chercher un taff» : tu peux vendre tes compétences et non ta personne (ce que font les freelances en général), ou encore être tellement bon ou connu pour qu'on vienne te recruter et non l'inverse.
[^] # Re: reglage personnalisé ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Empêcher Libreoffice de masquer/afficher les barres d'outil de manière intempestive. Évalué à 2.
Ça me rassure de voir que je ne suis pas le seul à trouver ça gênant :)
[^] # Re: Les gens.
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
Entre deux équipes qui sont bien constituées, celle qui met en place (en plus) des méthodes de travail sera probablement meilleure.
Je ne sais pas ce que tu entends par "faire des sites web" ; on ne fait pas de sites web, on fait des applications web. On ne peut pas comparer "développer une application métier" et "développer une application web" car il s'agit d'aspects orthogonaux : une appli web, ça parle des technologies, une appli métier de la finalité.
Je te rejoints totalement, et c'est bien pour ça qu'on développe des applications web et non des sites web.
Notre métier n'est pas de faire du graphisme mais de comprendre les besoins des utilisateurs (professionnels ou pas) et de leur proposer des outils qui résolvent un certain nombre de leurs problèmes.
Deux exemples sur des projets qu'on a fait l'an dernier :
C'est sûr on fait aussi du graphisme, on construit des écrans "responsive", mais notre différenciateur, ça n'est pas de faire un site beau et qui s'adapte à l'écran de l'utilisateur - ça tu prends n'importe quelle agence web et si tu paies correctement tu es sûr d'avoir un bon résultat ; notre différenciateur c'est d'être capable de comprendre les besoins exprimés et non exprimés et de conseiller et accompagner le client.
Bref, tout ça pour dire qu'on fait bien des applications métier et qu'on est très content de le faire - pour les même raisons que toi :)
[^] # Re: Pas pour moi
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
Personne n'a dit que c'était sans se soucier des impacts. Réduire les coûts c'est naturel, et toute personne qui met en concurrence 2 offres le fait. Qu'il s'agisse de professionnels et de particuliers.
Ca ne veut pas dire ne pas se soucier des impacts ni de la qualité, ça veut juste dire : "si tu peux payer moins cher pour le même produit/service, tu le fais". En tout cas, quand tu achètes, ça entre en ligne de compte.
La question "est-ce que c'est le même service" est une autre question et c'est de la responsabilité des personnes concernées d'expliquer que non ça n'est probablement pas le même service.
[^] # Re: Pas évident
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 2.
On sait ce qu'on veut à court terme, mais on est en général incapable de savoir ce qu'il faudra avoir dans 1 an ou dans 2 ans. Et dans ces conditions on n'anticipe pas sur la flexibilité à implémenter pour d'hypothétiques fonctionnalités qui pourraient arrivent dans quelques années.
Plus tu réfléchis en début de projet à toutes les problématiques, plus tu retardes la sortie et en particulier la sortie de la v1. Donc plutôt que retarder ta v1 pour "mieux prévoir ta v2, v3 et autre", tu sorts ta v1 au plus vite, et tu capitalise sur l'expérience de ta v1 pour définir ta v2. Et tu vas de proche en proche.
[^] # Re: script de setup d'un environnement fonctionnel
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 10.
Le point 8 signifie : plus ton code est utilisable/testable par quelqu'un qui ne connait rien à rien de ta pile technologique, mieux c'est.
Si tu fais une appli web avec mongodb, redis, nginx, etc, si tu es capable de donner un outil qui "en un clic ou en une ligne de commande" fait tout le setup et permet à n'importe qui de le tester, c'est du temps gagné car des personnes non compétentes pourront te remonter des bugs (donc tu pourras arriver à un niveau de qualité équivalent en passant toi-même moins de temps à tester)
[^] # Re: Pleins de remarques
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 2.
Bah le TDD permet d'écrire la spec (en termes de dév, certes, mais au moins ça définit le fonctionnement). Le BDD est une extension de ça et va plus loin.
Mais globalement ce que j'essaie d'exprimer c'est ce que tu dis (avec probablement un vocabulaire plus modeste sur le sujet;)
Il n'y a pas de règle pour dire "granularité trop faible" ou "granularité trop importante". Ce qui compte, c'est déjà de se poser la question, et souvent naturellement on va se rendre compte que des composants sont à responsabilité multiple ou responsabilité éclatée.
Et on travaille rarement seul, donc si tu discute sur un module donné, tu vas probablement arriver à un consensus.
Enfin qu'est-ce qu'un module, bah tout dépend du niveau de vision que tu as. Ca peut être une classe, une fonction, un ensemble de classes… tout dépend des technos que tu utilises, mais globalement "plus tes composants peuvent être considérés comme des boîtes noires, mieux c'est".
[^] # Re: Hypothèse fondamentale discutable
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
Non justement, l'aspect maintenance est au coeur de cette remarque. Tu ne peux pas présumer du niveau d'expertise du développeur qui fera la maintenance de ton code. Pour caricaturer, si ton code est maintenable par un développeur qui ne connait pas ta techno, c'est une bonne chose.
En python (la techno sur laquelle je travaille beaucoup), il y a des moyens de rendre le code tellement concis que tu es obligé de le lire à voix haute, voire de le réécrire en structure classique pour être sûr de ce qu'il fait (et encore). C'est 3 lignes de code économisées pour un niveau de crainte complètement disproportionné quand tu cherches à comprendre/faire évoluer le code.
Exemple de code trop concis :
msg = "Hi " + ("there" if not name else ("Neo" if name == "Anderson" else name))(ne ris pas, ça existe ce genre de code;)
(et encore, là c'est pas imbriqué dans des boucles et des set de listes de générateurs;)
[^] # Re: Hypothèse fondamentale discutable
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
D'une manière générale (et je m'inclus dans le lot), la tendance est de sur-anticiper les attentes des futurs développements. Si tu as une bonne couverture de test, tu peux faire du refactoring conséquent en limitant les risques.
Je te rejoins sur le fait que c'est avec l'expérience qu'on est capable de mieux en mieux de déceler ce qu'il serait bon d'anticiper et ce qui ne l'est probablement pas. Sans jamais en être certain.
Dans ce contexte, je parles d'un cahier des charges qui vient aussi avec des perspectives d'évolution.
Dans le contexte dans lequel je suis, je prends en compte non seulement les possibilités d'évolution, mais aussi les coûts associés. Et ça, peu de développeur le perçoivent. L'anticipation d'une feature qui viendra peut-être et qui fragilise le code au point que tu passes des plombes à stabiliser c'est un paquet d'argent perdu (ou investi) d'une manière ou d'une autre (et dans le cas où on considère que c'est investi, c'est un investissement avec quel chance d'être rentable ?)
Si tu sens qu'il y a une limitation dans le cahier des charges et que tu penses qu'il faut vraiment anticiper tel ou tel aspect, je te renvoie au point n°1 : en discuter avec le client. Ca ne t'apportera peut-être pas de réponse, mais ce qui est certain c'est que si tu n'en parles pas c'est un pari que tu fais.
[^] # Re: Hypothèse fondamentale discutable
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 1.
Merci pour tes retours, qui m'invitent à leur tour à des remarques
Il n'empêche que c'est intéressant pour l'entreprise de pouvoir réduire les coûts pour une qualité équivalente. Ça n'est pas forcément LA solution à retenir (et en tout cas surtout pas la solution à retenir systématiquement). Après il faut savoir faire la distinction entre les cas où c'est à mettre en oeuvre et les cas où c'est à proscrire.
Et je te rejoins sur le fait que certains projets peuvent ne pas être concernés par "une rentabilité optimale en terme de temps de dév". Mais sur certains projets (au hasard, des dév sur des technos vieillissantes et des produits qui sont condamnés), on peut réduire les temps de dév sans "bacler le travail", ce qui permet de consacrer plus de temps à d'autres projets.
[^] # Re: script de setup d'un environnement fonctionnel
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 4.
Mettre au point un déploiement ansible/chef/puppet juste pour permettre à quelqu'un de faire un test, c'est clairement pas un gain de temps court-terme.
Un "script" tu mets ce que tu veux dedans - l'idée c'est que tu as en quelques heures un outil qui permet à n'importe qui de setup son environnement sans rien connaitre. Si tu veux mettre un docker derrière, CoreOS via terraform ou n'importe quoi, peu importe : ça dépend des compétences que tu as et des outils que tu connais.
Mais ce qui compte c'est que tu sois capable de fournir à un testeur, à un chef de projet, à un admin sys ou à n'importe qui une solution du type "tu lances cette commande et tu as l'appli dispo à telle adresse et configurée avec les données de base".
[^] # Re: Pleins de remarques
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 6.
Ce n'est pas du tout ce que je dis. Ce que je dis, c'est que pour un développement donné, tu peux souvent gagner en temps de travail sans réduire la qualité en mettant en oeuvre une certaine méthodologie
Je me cite : "Les stratégies 1 et 2 sont moins couteuses que la 3, mais la qualité est partiellement sacrifiée et le niveau de finition également en faveur d'un temps de développement réduit (à court terme)"
On est d'accord :)
Personne ici n'a dit ça. Le seul truc que j'ai dit c'est que tu peux réduire ton temps de développement sans forcément perdre en qualité, je n'ai à aucun moment dit "tu peux faire du haut-de-gamme au prix du low-cost".
[^] # Re: Pas évident
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 8.
Si tu considères uniquement le temps de travail technique (développement, tests, conception, etc), la technique 3 est la plus économique. Mais cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire (si techniquement ce n'est pas un problème, c'est souvent un problème en terme de parts de marché)
Les techniques 1 et 2 sont les plus rapides pour arriver à un périmètre fonctionnel donné, ce qui permet rapidement :
Le time-to-market est un élément très important à prendre en compte, et dans ce contexte, plus tôt tu as un produit commercialisable (même si limite techniquement), plus tôt tu acquiers des clients, des parts de marché, donc également de la légitimité. Il faut bien voir l'économie comme une compétition et en particulier le monde des startups est féroce.
Pour ceux qui connaisent des jeux tels que starcraft, il y a une stratégie quand tu as les Zergs qui est d'aller tuer dans l'oeuf tes ennemis car en début de partie les Zergs ont un moment où ils sont en supériorité pour une durée donnée. C'est exactement la même chose avec les startups : faire un produit qui est sur le marché le plus vite possible va largement compliquer la vie des concurrents et donc conforter la place de leader du premier arrivé - et donc paradoxalement faire un produit un peu pourri techniquement pour arriver le premier est le meilleur gage de pérennité.
Cette explication est assez simpliste, mais c'est la réalité (alors bien sûr l'enjeu est aussi en général de lever des fonds mais à fonds levés égaux, celui qui prendra le premier la place sur un marché sera souvent celui qui survit. Je t'invite à lire l'article suivant : http://www.newyorker.com/tech/elements/in-silicon-valley-now-its-almost-always-winner-takes-all
[^] # Re: En bas ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Empêcher Libreoffice de masquer/afficher les barres d'outil de manière intempestive. Évalué à 2.
Je voudrais éviter une config spécifique à cette application - sur toutes les autres les barres d'outils sont en haut.
[^] # Re: Pas anormal
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Que pensez-vous du comportement de Prestashop?. Évalué à 2.
30 balles ? Tu parles de faire du ecommerce et 30€ ça te bloque ? Je suis curieux de voir ton business plan.
Si c'est simple, je comprends pas pourquoi tu t'emm… à regarder les plugins au lieu de le faire toi-même.
Tu parles de faire du commerce… C'est du business.. Aucun pro ne développe sérieusement des fonctionnalités pour 50€.
Je suis curieux de savoir quel est ton métier et combien tu gagnes de l'heure.
[^] # Re: lolix-v2
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Lolix down ?. Évalué à 8.
Dans une phase de creux de mon activité, j'avais contacté Rodolphe pour proposer de contribuer à prix coûtant. Je n'avais eu aucune réponse.
Ca m'avait du coup "un peu" blasé d'avoir contribué financièrement…
# Autre "avantage" que j'ai oublié de mentionner...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Stage de fin d'étude en pré-embauche - développeur backend python/go sur Grenoble. Évalué à 2.
On est abonné aux magazines des éditions Diamond : Linux Magazine France, Linux Pratique, Misc et Hackable.