Maintenance

Après le lancement, c'est avant la mise à jour

Les premiers commentaires des utilisateurs et les critiques de l'app store arrivent. Nous voyons de nombreux endroits dans l'application où il est possible de l'optimiser davantage ou d'y ajouter de nouvelles fonctionnalités qui la rendraient encore meilleure. De même, des rapports de crash et des bugs font maintenant surface et doivent être corrigés.

En plus des corrections de bogues et des nouvelles fonctionnalités, des mises à jour sont nécessaires pour revoir l'apparence de l'app store. Dans le cadre de l'ASO (App-Store-Optimization), l'apparence de l'App-Store et les mots-clés doivent être optimisés en permanence. C'est donc là aussi qu'un développeur doit devenir actif.
Ceci est important car les téléchargements ainsi obtenus sont organiques, c'est-à-dire qu'ils sont générés par la recherche dans l'App Store, sans avoir à payer de publicité ou autre. Et plus nous avons de téléchargements, plus nous sommes en haut du classement de l'App Store et plus il est facile de nous trouver. Il en résulte un effet boule de neige, avec lequel vous pouvez obtenir lentement mais durablement des résultats fantastiques - l'ASO durable et continu peut être un grand facteur de succès dans le nombre de téléchargements.

Support

Nous réalisons donc qu'après le lancement du premier projet, un soutien technique sera encore nécessaire. Il est donc extrêmement important pour le projet de planifier tôt comment gérer le soutien et comment procéder après le téléchargement. Le développeur actuel peut-il prendre en charge la maintenance de l'application ? À quelle fréquence les mises à jour doivent-elles être soumises ? Combien de temps le développeur doit-il prévoir par mois pour le projet ? Quels sont les coûts à prévoir ?

Il faut également se rappeler qu'il est généralement difficile de trouver des développeurs qui soient prêts à poursuivre le projet de quelqu'un d'autre. Avec les projets d'autres personnes, le développeur ne sait jamais quels risques techniques sont cachés "sous le capot". Par conséquent, ces demandes ne sont pas très populaires auprès des promoteurs qui ont une bonne situation de commande, et c'est généralement le cas des bonnes.

Support - combien et comment ?

Avec les applications, il s'agit moins d'un support avec des temps de réponse minimaux. Car même si l'application a un bug critique, elle doit repasser par la revue Apple pour la mise à jour. L'examen de l'application prend généralement quelques jours. Par conséquent, les actions de nuit n'apportent pas le succès escompté à court terme, mais conduisent plutôt à d'autres insectes qui s'insinuent pendant la course effrénée.

Cela peut également être pris en compte lors des négociations avec le promoteur et, si nécessaire, des avantages en termes de coûts peuvent être obtenus grâce à des délais de réaction plus généreux. À cette fin, chaque projet/application doit être soumis à une évaluation individuelle des risques au préalable.

Si l'application communique avec son propre backend, par exemple, des bogues peuvent parfois être corrigés entre-temps par des "solutions de rechange" au niveau du backend. De plus, les temps de réponse courts sont toujours meilleurs avec le backend, car les changements peuvent être publiés immédiatement ici.

Le super-accident - L'examen accéléré d'Apple

Dans le pire des cas, il est possible de demander à Apple un "Expedited Review". Ainsi, l'application est révisée et publiée pratiquement du jour au lendemain.
Vous ne devez le demander qu'en cas d'extrême urgence. Apple n'accorde un examen accéléré que dans des cas exceptionnels, vous devriez donc garder cet as pour une véritable urgence.

Que se passe-t-il maintenant au niveau des projets ? - Valider le produit

Après la sortie de la première version, l'accent doit maintenant être mis sur la validation de l'idée de l'application. Bien sûr, il ne sert à rien de trouver une bonne configuration pour la maintenance et le développement du produit s'il s'avère rapidement que personne n'utilise l'application. Ou dans le cas des start-ups, les investisseurs ne sont pas intéressés.
Autrement dit, jusqu'à ce que vous soyez sûr qu'il vaut la peine de poursuivre le projet, il est recommandé d'utiliser les ressources minimales et de ne corriger que les bogues critiques.

Souvent, les gens ont l'impression/illusion qu'une modification d'une fonction ou la fonction "tueur" va changer la donne et que les utilisateurs vont affluer. Cette seule fonction ferait de l’application une application parfaite.

Cela vient généralement du fait que l'on sait maintenant comment concevoir de nouvelles fonctionnalités et les faire développer. Elle est généralement beaucoup plus concrète et plus proche de vous que le marketing et la vente de l'application. C'est donc là que vous voyez la solution pour la première fois.
Cependant, vous ignorez le fait que sans la portée nécessaire, les utilisateurs ne connaîtront jamais cette caractéristique. Donc, d'abord le marketing et les ventes - puis le développement !
Si le projet prend d'abord de l'élan et de l'ampleur, il se comporte bien sûr différemment, mais il faut d'abord y arriver.
Les décisions à prendre concernant les produits devraient alors se fonder autant que possible sur des chiffres plutôt que sur de pures théories. Il est donc fortement recommandé d'intégrer un outil d'analyse. Et là encore, les numéros ne peuvent être collectés que si vous avez un minimum de trafic / nombre d'utilisateurs.

Le produit est validé - et maintenant ?

Félicitations d'abord - maintenant, le vrai travail commence !
Maintenant, les exigences changent. Il ne s'agit plus de créer quelque chose de concret le plus rapidement possible à partir d'un élément vague (du concept à l'application), mais maintenant d'améliorer continuellement le produit et de créer un nouveau potentiel de succès.
Il est maintenant temps de passer le plus rapidement possible de l'approche itérative et orientée vers les projets à une approche continue orientée vers les produits. C'est là que des mots à la mode comme "intégration continue", "constructions nocturnes" et "Kanban" entrent en jeu.

L'intégration continue et le kanban

Afin d'intégrer ainsi de petites améliorations dans l'application de manière aussi continue que possible et de les diffuser sous forme de bêta, au moins en interne, à intervalles rapprochés.
Les petits changements réduisent également le risque de casser quelque chose de grand dans le processus.
L'objectif est maintenant de disposer d'une version disponible à tout moment qui soit meilleure que la précédente et qui puisse être diffusée à tout moment. Nous n'attendons pas d'étapes, nous avons aujourd'hui une version de l'application qui est meilleure que celle d'hier ... Cela nous donne également un maximum de flexibilité pour utiliser les mises à jour comme outil de marketing sans en rendre les développeurs fous. Maintenant, le développement n'est plus organisé avec Scrum en sprints, mais avec Kanban, car cela reflète mieux la structure continue - comme un flux de tâches prioritaires qui sont livrées en temps voulu (en bêta).

Nous l'avons fait !

Nous avons une application, nous savons ce qui se passe après la première sortie. Maintenant, le succès dépend de l'application, de la chance et du bon timing - nous souhaitons à tous ceux qui entreprennent ce voyage eux-mêmes, beaucoup de succès et de résilience.

En effet, avec 1,4 million d'applications dans l'App Store (source Statista, janvier 2015), il ne faut pas s'attendre à ce que les utilisateurs se débrouillent seuls après le téléchargement. La vente et le marketing d'une application sont un travail difficile et exigent au moins autant d'efforts que le développement proprement dit.

Obtenez gratuitement un devis