Comment embaucher un développeur freelance

La plupart des projets de développement échoués n'ont pas été mal codés. Ils ont été mal spécifiés, embauchés sur le mauvais signal, et transférés de manière si incomplète que le développeur suivant a dû tout recommencer. La partie technique est rarement là où l'argent disparaît.

C'est une bonne nouvelle pour un acheteur non technique, car cela signifie que les décisions les plus importantes sont celles que vous êtes qualifié pour prendre. Vous n'avez pas besoin d'évaluer le JavaScript de quelqu'un pour bien embaucher. Vous devez être capable de décrire le problème précisément, de reconnaître des preuves pertinentes, de poser des questions difficiles à bluffer, et d'insister sur un transfert qui vous laisse les clés en main. Ce guide vous accompagne à travers ces quatre points.

Décidez ce que vous construisez réellement

Commencez par le résultat, pas par la technologie. J'ai besoin d'une application n'est pas un brief; les clients doivent pouvoir réserver et payer un créneau sur leur téléphone, et je dois voir les réservations de demain dans une seule liste l'est. La deuxième version peut être chiffrée, testée et discutée. La première ne le peut pas.

Avant de parler à qui que ce soit, notez quatre choses:

• Le travail à faireCe qu'un utilisateur devrait pouvoir accomplir et qu'il ne peut pas faire aujourd'hui. Une phrase par capacité, dans le langage de l'utilisateur plutôt que technique.
• Les incontournablesLa poignée de choses sans lesquelles la construction est inutile. Si votre liste en contient plus de six, c'est une liste de souhaits, pas une spécification.
• Ce qui existe déjàSite actuel, hébergement, domaine, fournisseur de paiement, CRM, feuilles de calcul. Chaque intégration est un travail, et les intégrations non déclarées sont la cause des dépassements d'estimations.
• Qui le maintientUn logiciel n'est pas un achat, c'est un engagement. Décidez maintenant si vous conserverez le développeur, en embaucherez un autre, ou le gérerez vous-même.

Une discipline utile: décrivez la première version comme la plus petite chose qui serait réellement utile. Tout le reste va sur une deuxième liste. Les développeurs chiffrent la première liste; la deuxième liste est ce que vous financez une fois que la première rapporte.

Quel type de développeur vous avez besoin

Développeur couvre une douzaine de métiers distincts qui ne sont pas interchangeables. Embaucher le mauvais est l'erreur de catégorie la plus courante et la plus coûteuse dans ce processus.

• Front-endCe que l'utilisateur voit et touche: mise en page, interaction, réactivité, accessibilité. Embauchez pour une refonte, un site marketing ou une nouvelle interface sur un système existant. Voir freelances en développement front-end.
• Back-endDonnées, logique, API, authentification, paiements. Embauchez lorsque la valeur réside dans ce qui se passe après avoir appuyé sur le bouton. Voir freelances en développement back-end.
• Full-stackLes deux, à un niveau fonctionnel. Le bon choix pour la plupart des petites constructions, car la coordination entre deux spécialistes coûte plus cher qu'elle n'économise à petite échelle.
• CMS et plateformeWordPress, Shopify, Webflow et similaires. Si votre besoin est satisfait par une plateforme existante, embaucher un développeur personnalisé pour la reconstruire est de l'argent gaspillé. Voir développement WordPress et développement Shopify.
• MobileiOS ou Android natif, ou multiplateforme. Une discipline véritablement différente du web, avec ses propres contraintes de révision et de publication en magasin. Voir développement d'applications mobiles.
• Maintenance et correctionsDébogage, mises à jour, performances, sécurité. Souvent l'embauche la plus précieuse de toutes, et celle que les acheteurs repoussent le plus longtemps. Voir maintenance de site web.

Si vous ne savez vraiment pas de quel type vous avez besoin, c'est en soi un petit travail, peu coûteux et bien défini: payez un développeur expérimenté pour une courte conversation de cadrage avant de commander quoi que ce soit.

Choisir la technologie avant la personne

Vous n'avez pas besoin de choisir le langage. Vous devez prendre une décision: plateforme ou personnalisé. Cela a plus d'effet sur votre coût total que tout autre choix dans ce guide.

Une construction sur plateforme — WordPress, Shopify, Webflow, un outil sans code — signifie que la majeure partie du logiciel existe déjà et que vous payez pour la configuration, la conception et les parties qui vous sont spécifiques. C'est plus rapide, moins cher et plus facile à transmettre à la personne suivante, car des milliers de développeurs le connaissent. La limite est que vous vivez à l'intérieur des hypothèses de la plateforme.

Une construction personnalisée signifie que le logiciel est écrit pour vous. Il s'adapte exactement, et il coûte plusieurs fois plus cher à créer et à maintenir, car seule la personne qui l'a écrit le connaît tant qu'elle ne l'a pas documenté. Le personnalisé est la bonne réponse lorsque ce que vous faites est le produit; c'est la mauvaise réponse pour un site vitrine ou une boutique standard.

Deux règles pratiques. Premièrement, si une plateforme grand public fait quatre-vingts pour cent de ce dont vous avez besoin, commencez par là et payez pour les vingt pour cent manquants. Deuxièmement, quel que soit le choix, demandez pourquoi — un développeur qui ne peut pas expliquer le choix en fonction de vos exigences choisit ce qu'il aime, pas ce dont vous avez besoin. Si vous envisagez la construction complète d'un site, notre guide des coûts de site web présente les fourchettes.

Rédiger un brief qu'un développeur peut citer

Un bon brief technique est court et précis. Il ne dit pas au développeur comment construire; il lui dit ce qui doit être vrai une fois qu'il a terminé.

• Le problème, en un paragraphe. Ce qui se passe actuellement et pourquoi ce n'est pas acceptable.
• Les user stories. En tant que client, je peux… afin de…. Cinq à quinze d'entre elles constituent une véritable spécification.
• Les intégrations. Nommez chaque système externe par son nom, y compris ceux que vous considérez comme triviaux.
• Ce que vous fournissez. Copie, images, designs, identifiants, données de test. Les lacunes non déclarées deviennent des heures facturables.
• Contraintes. Date limite, fourchette budgétaire, hébergement sur lequel vous devez rester, conformité que vous devez respecter.
• La définition de terminé. Déployé où, testé comment, documenté à quel niveau, livré avec quoi.

Incluez une fourchette budgétaire. Les acheteurs la retiennent dans l'espoir d'obtenir un devis plus bas; en pratique, cela ne fait que produire des propositions visant la mauvaise échelle, et vous perdez une série de correspondances en le découvrant. Notre guide pour rédiger un brief de projet qui obtient d'excellentes propositions contient un modèle plus complet, et prix horaire vs prix fixe explique quel modèle de tarification votre brief demande.

Établir une liste restreinte

Visez trois à cinq candidats. Moins, et vous n'avez pas de comparaison; plus, et vous ne ferez pas l'évaluation correctement pour aucun d'entre eux.

Il y a deux directions de recherche. Commencez par le travail si votre tâche est bien définie et que vous voulez acheter quelque chose de spécifique — parcourez les annonces à prix fixe sous développement de site web, développement de logiciels ou applications web, ou par marketplace à conception web, développeurs WordPress, développement d'applications mobiles ou experts Shopify.

Commencez par la personne si le travail nécessite une discussion. Parcourez les développeurs par discipline ou par outil — React, WordPress, PHP, Python ou Webflow — ou publiez le brief et laissez les propositions venir à vous. Sur Zinn Hub, publier un projet est gratuit, et vous pouvez le diriger vers un domaine spécifique tel que développement de site web, développement back-end ou développement d'applications mobiles.

Filtrez rigoureusement sur la pertinence et légèrement sur tout le reste. Un développeur qui a livré trois choses similaires aux vôtres bat presque toujours un développeur ayant deux fois plus d'expérience dans un domaine différent.

Comment lire un portfolio de développeur

Vous ne pouvez pas auditer le code de quelqu'un, et vous n'en avez pas besoin. Un portfolio vous en dit beaucoup si vous savez quoi regarder.

• Ouvrez les liens en direct. Une capture d'écran ne prouve rien. Chargez le site sur votre téléphone, utilisez-le, cassez-le. Tout ce qui est cassé aujourd'hui a été validé cassé.
• Recherchez des problèmes similaires aux vôtres. Pas la même industrie — la même forme. Un flux de réservation est un flux de réservation, qu'il vende des coupes de cheveux ou des hélicoptères.
• Vérifiez ce qu'ils ont fait. Sur les projets d'équipe, demandez quelles parties étaient les leurs. J'y ai travaillé peut signifier beaucoup ou très peu.
• Testez les bases vous-même. La page se charge-t-elle rapidement? Fonctionne-t-elle sur un téléphone? Les formulaires sont-ils utilisables avec un clavier? Ce sont des signaux de savoir-faire qu'un acheteur non technique peut très bien lire.
• Lisez les avis comme un ensemble de preuves. Un avis élogieux est du bruit. Un modèle à travers de nombreux avis, surtout concernant la communication et les délais, est un signal. Sur Zinn Hub, les avis nécessitent un achat confirmé.
• Demandez ce qui n'a pas fonctionné. La meilleure réponse à parlez-moi d'un projet qui s'est mal passé est une histoire spécifique, peu flatteuse et bien analysée. Il n'existe pas de développeur qui n'ait eu que des projets sans accroc.

Pour une version systématique de ceci, parcourez notre liste de contrôle en 12 étapes pour la vérification des freelances.

Questions à poser avant d'embaucher

Le but n'est pas de piéger qui que ce soit. C'est d'entendre comment quelqu'un pense quand la réponse n'est pas répétée.

• Expliquez une réalisation passée Parlez-moi de l'un de ces projets et des compromis que vous avez faits. Un bon développeur nommera quelque chose qu'il a choisi de ne pas faire et pourquoi. Le jargon sans compromis est un signe avant-coureur.
• Qu'est-ce qui vous inquiète iciDemandez quelle est la partie la plus risquée de votre brief. Quiconque dit rien, c'est simple ne l'a pas lu correctement.
• Qu'est-ce qui manque De quoi auriez-vous besoin de ma part que je n'ai pas fourni? Les candidats solides répondent à cela immédiatement et en détail.
• Comment vais-je voir les progrèsUn lien de staging, une mise à jour hebdomadaire, un tableau partagé. Toute réponse est acceptable; aucune réponse ne l'est pas.
• Que se passe-t-il après le lancementFenêtre de correction de bugs, conditions de support, documentation. Convenez-en avant de commencer, pas quand quelque chose tombe en panne.
• Qui est propriétaire du codeDemandez directement. La réponse devrait être vous, à la livraison, par écrit, y compris tout ce qui est nécessaire pour l'exécuter.

Testez avant de vous engager

L'assurance la moins chère disponible pour un acheteur est un petit travail rémunéré avant un grand. Pas un essai non rémunéré, que les bons freelances refusent et qui ne vous dit rien sur le comportement de quelqu'un lorsque l'argent est en jeu — une tâche réelle, petite et rémunérée.

Une bonne tâche de test est représentative, autonome et réalisable en une seule séance: corriger un bug spécifique, rendre une page responsive, ajouter un formulaire et le connecter, améliorer une page lente. Ce que vous évaluez réellement n'est pas le code. C'est de savoir s'ils ont posé une question de clarification avant de commencer, s'ils ont livré ce qui était demandé plutôt que ce qu'ils préféraient, s'ils ont expliqué ce qu'ils ont fait, et si le délai qu'ils ont donné était le délai que vous avez obtenu.

Sur Zinn Hub, le format naturel est un Micro Zinn — une tâche à prix fixe à $5, $10, $15 ou 20 $. Parcourez les corrections de bugs et petites tâches de code ou les corrections et ajustements de bugs de site web, ou commencez par un prix avec les $20 Micro Zinns. Notre guide sur tester un freelance avant de vous engager explique comment structurer et juger le test.

Ce que cela coûte et comment payer

La tarification du développement varie plus que toute autre catégorie de freelance, car le travail varie davantage. Ce qui suit sont des fourchettes de marché typiques pour l'ensemble du travail, pas les prix de Zinn Hub, et chaque freelance fixe les siens.

• Petite tâche

  Moins de $200

  Une correction de bug, un conflit de plugin, un formulaire, un passage de vitesse, une petite fonctionnalité sur une construction existante. Mieux vaut l'acheter comme une tâche à prix fixe.

• Construction standard

  $500–$2,000

  Un site ou une boutique basé sur une plateforme: configuration du thème, plusieurs modèles de page, formulaires, intégrations de base, lancement.

• Avancé

  $2,000–$8,000

  Fonctionnalités personnalisées, comptes et connexions, paiements, intégrations tierces, ou une conception sur mesure implémentée à partir de zéro.

• Application

  $8,000+

  Un véritable produit logiciel: systèmes multi-rôles, tableaux de bord, applications mobiles, tout ce qui implique une logique back-end significative et une ingénierie continue.

Les coûts varient en fonction de l'étendue, de la complexité et de l'expérience. Utilisez les fourchettes pour vérifier la validité d'un devis plutôt que comme un tarif — si un chiffre se situe à deux fourchettes de l'endroit où votre brief devrait être, cet écart est la conversation qui vaut la peine d'être eue.

Sur Zinn Hub, chaque Zinn a un prix fixé par son Zinner, les acheteurs ne paient pas de frais de plateforme, et tous les prix sont en USD avec un équivalent approximatif affiché dans votre propre devise. Une commande est payée et protégée en une seule somme; il n'y a pas de libération échelonnée ou par étapes, donc une construction par phases est placée comme des commandes séparées ou convenue comme des phases tarifées séparées dans votre brief de projet. Choisissez un Zinner protégé par la plateforme et votre paiement est conservé par Zinn Hub jusqu'à ce que la commande soit terminée; tout remboursement est crédité intégralement sur votre Zinn Wallet, en USD. Les Zinners qui connectent leur propre compte PayPal ou Stripe sont payés directement au moment du paiement.

Propriété, accès et transfert

C'est la section que les acheteurs sautent et regrettent plus tard. Mettez tout cela par écrit avant que le travail ne commence, car après la livraison, vous n'avez plus aucun levier.

• Comptes à votre nom. Le domaine, l'hébergement et tout service tiers doivent être enregistrés à votre nom, le développeur étant ajouté en tant qu'utilisateur. Jamais l'inverse.
• Propriété du code à la livraison. Indiquez clairement qu'au paiement final, le travail vous appartient pour l'utiliser, le modifier et le transférer ailleurs. Renseignez-vous sur les composants tiers avec leurs propres licences.
• Accès au dépôt. Même si vous ne l'ouvrez jamais, vous devez pouvoir le donner au développeur suivant.
• Identifiants, tous. Identifiants administrateur, clés API, accès à la base de données, accès au déploiement — transférés et confirmés comme fonctionnels avant le paiement final.
• Documentation. Une courte note écrite sur la façon de déployer, où se trouvent les choses et quoi faire si cela tombe en panne. Une page suffit; rien n'est insuffisant.
• Une fenêtre de correction de bugs. Une période définie après le lancement pendant laquelle les défauts réels sont corrigés sans frais supplémentaires. Trente jours est une demande courante et raisonnable.

Les conditions de droit d'auteur et de licence varient selon les pays et les contrats, il faut donc considérer ceci comme un guide général plutôt que comme un conseil juridique et obtenir des conseils professionnels pour tout ce qui est commercialement significatif.

Erreurs qui font échouer les projets de développement

• Embaucher avant que le brief n'existe. Chaque heure passée à spécifier en économise plusieurs en construction et en retravail. Rien d'autre sur cette liste n'est aussi important.
• Choisir uniquement en fonction du prix. Le devis le plus bas est souvent celui qui a le moins compris, et la différence se manifeste par des demandes de modification.
• Ajouter discrètement des fonctionnalités. Les petites demandes pendant une construction sont la façon dont les prix fixes deviennent des litiges. Regroupez-les, évaluez-les, décidez-les.
• Pas d'environnement de staging. Revoir le travail uniquement lorsqu'il est en ligne, c'est ainsi qu'un site cassé est découvert par les clients au lieu de vous.
• Sauter la vérification mobile. La plupart de vos visiteurs sont sur un téléphone. N'approuvez rien que vous n'avez pas ouvert sur un.
• Laisser le transfert jusqu'à la fin. Le moment de convenir de l'accès et de la propriété est avant le premier commit, pas pendant la dernière facture.
• Pas de plan de maintenance. Le logiciel se dégrade. Prévoyez un budget pour les mises à jour, les sauvegardes et la sécurité dès le premier jour, ou payez pour un sauvetage plus tard.
• Ignorer les signes avant-coureurs. Les réponses vagues, les petits délais manqués et la pression pour payer en dehors de la plateforme sont tous couverts dans notre guide sur les arnaques courantes des freelances.

Si vous hésitez encore à savoir si un freelance est la bonne solution, freelance vs agence compare les deux honnêtement pour la construction d'une petite entreprise.