Qu'est-ce qu'un bon ou un mauvais développeur freelance ?

Comme dirait les inconnus : “Mais au fond, quel est la différence entre le bon et le mauvais freelance ? Le mauvais freelance il voit un contrat il le fait et le bon freelance il voit un contrat bah il le fait mais c’est un bon freelance…”

Je pense que, lorsque l’on fait un une offre pour un contrat, la compétence technique n’est pas le seul facteur qui va faire que l’on obtient ce contrat ou pas. Selon vous, quels sont les autres facteurs ?

Que pensez-vous du temps et du prix ? Par exemple, si l’on demande une évaluation de temps, est-ce mieux de faire une évaluation juste, optimiste, pour avoir plus de chance d’obtenir le contrat, ou pessimiste, pour ce couvrir en cas de problème ? C’est pareil pour le prix, est-ce mieux de brader son prix ou de faire payer pour donner l’impression qu’on est plus expert.

Par exemple, si on nous offre un contrat pour faire une partie très simple, faut-il mieux prévoir le refactoring et les conseils, etc. ou juste faire la tâche en la faisant comme le reste de l’application ?

Bref, quels sont vos tactiques et techniques pour vendre et laisser le client satisfait ?

1 J'aime

Je pense que la différence entre le bon et le “mauvais”, compétence techniques et temps plus ou moins équivalent ou alors variant de + ou moins 33% c’est la communication avec le client.
Celui qui arrivera à bien justifier et communiquer avec le client et à le maintenir dans un état émotionnel proche de la confiance et positif sera perçu d’une meilleure manière que cela qui fait tout bien mais qui à des lacunes au niveau de la communication et peut être perçu comme étant moins bon ou alors moins sympa.

1 J'aime

@xmaximin je suis tout à fait d’accord avec toi. Dans le fond, il faut savoir ce vendre. Ça arrive souvent que tu peux faire confiance à quelqu’un alors que ce qu’il vend est pas terrible (c’est pour ça qu’SAP se vend). C’est certain qu’il y a une partie qui émane de la confiance en soit mais j’imagine qu’il y a des trucs à apprendre.

Avez-vous des bouquins ou d’autres ressources à conseiller sur le sujet ?

1 J'aime

D’après mon expérience personnelle :

  • Respect des délais annoncés au départ. Ne pas avoir peur de bosser un peu le soir / week-end si on est en retard. Le client est toujours “content”, et ca permet de prévoir dans son agenda le jour de démarrage des nouveaux projets avec d’autres clients.

  • Ne pas avoir peur de trop facturer, j’ai remarqué depuis que mon tarif journalier à augmenté que je n’attire que des “bons” clients. Au début j’avais tendance à trop baisser pour à tout prix avoir le client et je l’ai regretté par la suite on me considérait comme un employé et/ou je n’avais pas de crédibilité.
    Avec des tarifs plus élevés je signe plus facilement avec des clients qui sont prêt à mettre le prix qui me permet de rentrer dans mes frais et gagner convenablement ma vie. De plus ces clients me font totalement confiance.

  • Par la suite je pense qu’une qualité indispensable est la flexibilité, par ex. après la livraison d’un projet, le client souhaite faire un ajout. Je pense qu’il ne faut pas se borner à vouloir facturer une modification qui prendrait 5 / 10 minutes. J’ai des clients à moi qui se plaignent de dev freelance qui ne veulent pas changer par ex. un ordre dans un tableau sans facturer. Evidemment il faut que la demande soit raisonnable, mais moi perso j’ai opté pour offrir ce genre de petits détails si le client me parait réglo.
    Du coup avec ces clients, souvent au projet suivant ils me disent, tu rajoutes une journée en plus sur ton devis ca couvrira les modifs que tu nous avait faites gratuitement sur l’autre projet.
    Je suis donc convaincu qu’il savoir sacrifier un peu de temps pour “rendre service”.

Pour résumer :

Respecter les délais de livraison au jour près !
Ne pas se brader (du moins le faire au début une fois ou 2 pour voir les conséquences)
Etre flexible

6 J'aimes

Bonjour à tous,

je ne suis pas en freelance mais je trouve la réponse de @BenjaminB très pertinente!

J’aurai juste une réserve à apporter concernant la flexibilité.
Je suis totalement d’accord avec ce genre de petite faveur ou d’attention à apporter au client, mais attention à ce que ça ne dérive pas.
Cela m’est arrivé avec mon équipe “d’offrir” ce genre de choses, mais après avoir offert une petite chose (changement de la couleur d’un bouton par exemple), on va être tenté d’en offrir une moyenne, etc.
Et le client risque de ne pas comprendre pourquoi soudainement il n’a plus le droit à ce petit geste.

Une piste serait de prévoir, lors du devis, une petite réserve pour la maintenance (il y en aura toujours de toute façon), en définissant clairement avec lui le type de demande qui rentrerait dedans.

Exemple : pour cette demande, tu as utilisé 30 minutes dans les 4 heures de maintenance que tu as payé. Il te reste 3h30.

En résumé c’est la même chose que dans le scénario de @BenjaminB, sauf qu’on anticipe cela.
Car tous les clients ne seront malheureusement pas aussi réglo que dans l’exemple donné.

Qu’en pensez-vous ?
Est-ce une idée intéressante en freelance ou justement ça ne vous semble pas flexible ?

2 J'aimes

Je suis totalement d’accord avec toi sur le fait que ca peut dériver.
C’est pourquoi je le fait qu’avec des clients de confiance et jamais les nouveaux.
Je suis certain d’avoir un retour avec ces clients la.

Donc une partie maintenance dans les devis oui je suis ok mais il faut pouvoir le justifier. Le client pourrait te dire attendez moi je sais ce que je veux je vais pas changer en cours de route ou après la livraison. (c’est du vécu).

D’après moi les critères essentiels pour un freelance serait avant tout ses capacités et son niveau de compétences ( parfois un freelance postule pour une mission dont il ne maîtrise pas le langage à 100% par exemple ) et ça c’est très grave . Autre critère très important serait le délai de livraison de la mission , livrer en retard donne une très mauvaise impression à l’entreprise .

Parfois on tombe sur des clients généreux ,d’après mon expérience et en livrant le service avant la date prévue j’arrivais à négocier un revenu supplémentaire et ça marché très bien .

Je ne vois pas en quoi c’est “grave” de prendre une mission dont on ne maitrise pas le language.
Justement si je me suis aussi mis en freelance pour avoir l’opportunité d’apprendre de nouvelles technos.

L’année dernière j’ai pris un mission pour développer une appli Android interne à une entreprise (je suis plutôt spécialisé appli web / Symfony2).
Je n’avais jamais fait de Java même pas une ligne de code.

Alors oui j’ai perdu un peu de temps pendant le dev, oui ce n’est peut être pas le plus beau code, mais il y’as des tests unitaires, une appli qui fonctionne correctement et un client content.

Donc le mot “risqué” est il me semble plus approprié, mais dire que c’est “grave” ça me choque !

Bonne réflexion que tu lances là :)

Pour la justifier, on peut toujours lui évoquer les usecases classiques (un jour tu peux avoir besoin de modifier l’aspect de certains éléments de ton site, par rapport à une période particulière de l’année, etc)

Et le rassurer : si cette réserve de temps n’est pas dépensée, on peut envisager de la déduire de la prochaine mission.

J’ai souvent remarqué qu’en donnant du sens à ce que l’on fait, les relations avec le client étaient plus solides car plus transparentes.