Trong phần mềm này, các chủ nhà hàng có thể ký gửi hóa đơn của họ để mua hàng hóa. Sau khi tài liệu đã được gửi, văn phòng hỗ trợ có thể trích xuất và xem dữ liệu cũng như sự phát triển của chúng: nhà cung cấp, ngày, VAT, số lượng, sản phẩm, v.v. Điều này giúp bạn có thể hiểu rõ hơn và quản lý chi phí theo chi phí và chi tiết tiêu thụ.
Một nhóm nhân viên của Linkvalue đã hỗ trợ họ trong việc hiện thực hóa dự án này để giúp họ khởi chạy MVP sau 2 tháng nhằm tôn trọng thời gian tiếp cận thị trường của họ.

Nhóm Agapio chia sẻ phản hồi về định nghĩa nhu cầu của người dùng, xác nhận thị trường, phát triển kỹ thuật, ra mắt MVP và phát triển sản phẩm.

Định nghĩa nhu cầu của người dùng

Ý tưởng ban đầu là nâng cao năng suất của nhân viên kế toán trong việc xử lý hóa đơn. Sau nhiều cuộc trao đổi và phỏng vấn thực địa, hóa ra đây là một lĩnh vực phức tạp cần giải quyết. Nhưng một vấn đề cụ thể có thể được xác định: kế toán quản lý khách hàng của nhà hàng . Một mặt, các chủ nhà hàng có khối lượng thanh toán rất lớn, mặt khác lại cần khả năng hiển thị nhanh chóng. Trên thực tế, việc mua hàng của họ rất dễ hỏng và thường xuyên, và tỷ suất lợi nhuận của họ khá thấp. Do đó, họ có thể nhanh chóng thực hiện các tối ưu hóa có tác động tài chính mạnh mẽ.
Cuối cùng, không phải kế toán cần sự giúp đỡ, mà là chủ nhà hàng và kế toán của họ.
Vì vậy, ý tưởng phát triển thànhđề xuất một công cụ dễ dàng cho phép họ có khả năng hiển thị tức thì về việc quản lý tài chính của họ .

Theo quan sát này, các cuộc phỏng vấn và những ngày đắm chìm với các chủ nhà hàng đã được thực hiện. Họ đã làm cho nó có thể hiểu đầy đủ các chu trình quản lý đơn đặt hàng: nhận đơn đặt hàng, tiếp nhận, phân phối, tồn kho, xử lý hóa đơn, v.v. Và để xác thực khái niệm này.

Sau đó, nó đã được cung cấp cho 3 nhà hàng thí điểm để thử nghiệm một nguyên mẫu đầu tiên miễn phí để cố gắng cung cấp cho họ khả năng hiển thị tốt hơn trên hóa đơn của họ. Đây là loại MVP đầu tiên với một tệp Excel đơn giản.
Hàng tháng, họ gửi một mẫu gồm 100 đến 150 hóa đơn, được xử lý thủ công trong bảng Excel và chuyển sang một bảng điều khiển theo dõi.
Bước này giúp bạn có thể thu thập phản hồi của người dùng, để hiểu dữ liệu có giá trị nhất trong quá trình theo dõi và xác định các chức năng mong đợi. Nó cũng giúp xác thực rằng có nhu cầu thực sự vì người dùng thí điểm đã hài lòng và sẵn sàng trả tiền cho dịch vụ để làm cho dịch vụ trở nên hoàn thiện hơn.

Song song với việc thăm dò người dùng, một nghiên cứu thị trường đã được thực hiện bằng hai cách tiếp cận:

• Từ dưới lên: Thực hiện quảng cáo chiêu hàng với các chủ nhà hàng để đánh giá mức độ quan tâm của họ đối với công cụ.
• Từ trên xuống: Tổng hợp dữ liệu về các giải pháp hiện có, số lượng nhà hàng ở Pháp và Châu Âu, mức độ thành thục của họ về mặt công cụ, v.v.

Từ đó, nó đã được quyết định tài trợ bằng vốn cổ phần cho một phiên bản có thể bán được trên thị trường đầu tiên. Điều này để sau đó có thể tổ chức một buổi gây quỹ, không chỉ là một ý tưởng mà còn là một sản phẩm chức năng.
Do đó, mục tiêu là phát triển rất nhanh một sản phẩm với mức chất lượng đủ để tìm kiếm những khách hàng trả tiền mới. Đó là 6 tháng để viết thông số kỹ thuật, tìm nhà cung cấp dịch vụ, khởi chạy phát triển và phát hành phiên bản đầu tiên. Thời hạn đã được đáp ứng và do đó, không thể giải phóng thêm tiền bằng cách tung ra phiên bản đầu tiên rất nhanh.

Phát triển kỹ thuật

Đã có sự phân vân giữa việc thành lập một nhóm dịch giả tự do hay kêu gọi một nhà cung cấp dịch vụ chuyên về phát triển web. Đó là tùy chọn này đã được chọn cho một câu hỏi về hiệu quả.
Chúng tôi phải tìm một công ty có khả năng đảm nhận chủ đề này, thử thách nó ở cấp độ chức năng, thời gian phát triển, các tính năng cần đưa vào, v.v. Tất cả đồng thời tôn trọng ngân sách.

Các thông số kỹ thuật đã được tính toán phù hợp với ngân sách này. Các chức năng được giữ lại đã được hiệu chỉnh để có phiên bản đầu tiên tập trung vào các yếu tố cần thiết với mong muốn giới hạn thời gian phát triển. Theo logic nhanh nhẹn , cần phải phát triển những thứ tối thiểu cần thiết để có thể xuất hiện rất nhanh trên thị trường và xem kết quả.

Ngăn xếp kỹ thuật

Để đi nhanh nhất có thể, nguyên tắc là phải làm với kiến ​​thức của đội ngũ kỹ thuật:

• Quản lý phát triển được thực hiện trên Github .
• Heroku được chọn cho phần Hồng ngoại và phần triển khai.
  Đây là một sự thỏa hiệp vì một số công ty đưa ra lựa chọn này cuối cùng đã phải thay đổi các nhà cung cấp dịch vụ đám mây sau đó. Nhưng có một mặt nhanh chóng và không tốn kém. Và cuối cùng nó vẫn là một lựa chọn tốt cho đến ngày hôm nay, ít tốn kém hơn so với AWS hoặc GCP .
• Phần Front được tạo trong React .
• Auth0 đã được chọn cho phần xác thực. Nó luôn luôn đáp ứng nhu cầu. Không có vấn đề gì và không có nhu cầu hoặc mong muốn thay đổi.
• Cuộc thảo luận thực sự là về API. Cái này được tạo bằng GraphQL , với một lớp cho phép tích hợp API GraphQL trên cơ sở dữ liệu. Nó lấy mô hình dữ liệu từ cơ sở dữ liệu PostGre và tạo API GraphQL với khả năng tùy chỉnh và thêm các mô hình kinh doanh. Do đó, lớp phủ Hasura này làm cho nó có thể có một API GraphQL hoạt động nhanh chóng, cũng quản lý toàn bộ lớp ủy quyền truy cập API.
  Điều này cho phép triển khai nhanh chóng, giúp tiết kiệm rất nhiều thời gian phát triển, ngoài một số rắc rối khi giao tiếp với Auth0.

Đặc trưng

Le projet a été développé en mode sprint à partir du cahier des charges initial. Les use cases ont été redéfinis et redécoupés en fonctionnalités, classées selon leur priorité.
Il y a eu 4 sprints de 2 semaines. Le premier sprint a servi à poser les premières briques et un premier squelette de connexion. Puis à chaque livraison les priorités du prochain sprint et des fonctionnalités intégrées étaient redéfinies en fonction de l’avancement du projet et des découvertes faites au fur et à mesure.
En parallèle, la découpe des éléments en composants s’est organisée pour la partie Front, à partir des maquettes réalisées en amont de l’appel d’offres.

Certaines fonctionnalités prévues au départ ont finalement été dépriorisées par l’équipe technique. Par exemple, les notifications sur des modifications de prix ou autre ont été mises de côté car elles nécessitaient d’intégrer un service de messagerie transactionnel.
Sur la partie back-office, il était également prévu des workflows plus calibrés que ce qui a été fait dans le temps imparti.
Il y a aussi eu un compromis fait sur la gestion des utilisateurs : d’une gestion de plusieurs utilisateurs il y a eu une limitation à un utilisateur par restaurant, avec un compte unique sur lequel il est possible de se connecter à plusieurs.
Il y a aussi eu plusieurs échanges techniques sur la chaîne d’intégration et de déploiement. Mais le temps passé sur les fonctionnalités a été privilégié par rapport à la structure de mise en production.
Ce choix pouvait paraître risqué mais s’est révélé pertinent. Il a finalement été possible de tourner un bon moment avec des contraintes ou des limitations qui ne semblaient pas pouvoir rester aussi longtemps sur un projet en production. Le délai et le budget ont été tenus avec un bon rapport qualité prix. Et tout ce qui a été produit a été challengé pour s’assurer de sa valeur.

Tests utilisateurs

Les maquettes avaient été validées avec les restaurants pilotes en amont du développement. En revanche, le temps de développement a été court et il n’y avait pas beaucoup de marge de manœuvre pour intégrer des utilisateurs et réagir à leurs retours. Il y avait aussi trop peu de temps pour travailler en parallèle sur un environnement de test avec un set de données pertinent. Et sur l’environnement de développement, l’équipe pouvait tout déconstruire à tout moment.
Mais il a été rapidement possible d’enregistrer un scénario de démo vidéo, qui a permis de lancer une phase de démarchage client en parallèle du développement. Ce qui permettait de montrer quelque chose de plus dynamique que des écrans statiques.

À noter que la volonté de départ était de sortir rapidement un produit pour aller l’éprouver. Le premier test, via un tableau Excel, n’avait coûté que du temps. Ce deuxième test, avec le développement d’un MVP, coûtait un peu d’argent mais il s’agissait toujours d’un test. En se disant qu’il y avait un risque que ce qui est développé pouvait finalement ne pas trouver son marché. Donc il fallait limiter les pertes, c’est-à-dire limiter le budget et le temps passé pour être à même de faire des essais successifs et trouver le bon market fit.
L’équipe technique s’est donc focalisée sur la sortie du MVP et Agapio sur le démarchage des premiers clients payants.

Lancement du MVP

Après avoir pu servir de démo du produit et de support de démarchage, le MVP est sorti fin 2019 et a été commercialisé auprès des premiers clients début 2020. Juste avant le Covid qui a entraîné la fermeture des restaurants !
Le démarrage a été prometteur avec de très bons retours client et une courbe de croissance intéressante, jusqu’à l’arrivée du premier confinement.
Malgré tout, aucun client n’a résilié l’offre et de nouveaux clients se sont abonnés dès mai 2020.

Un effet constaté après le lancement est l’intégration du produit entre le restaurateur et le comptable. Avant, le restaurateur envoyait directement ses factures à son comptable. Aujourd’hui il rentre d’abord ses données dans l’outil et a directement une visibilité dessus. Mais il doit ensuite redonner ses mêmes informations à son comptable, ce qui est redondant. Il y a donc eu une demande pour pouvoir extraire les données de l’outil, ce qui n’était pas prévu au départ. À la demande, les données étaient donc compilées manuellement dans un document Excel pour pouvoir être envoyées directement au comptable. De même pour la comparaison entre deux établissements. Depuis, l’outil permet de réaliser des exports comptables qui peuvent directement être intégrés dans un logiciel comptable.

La sortie du produit et son adoption rapide par les clients ont permis d’obtenir de nombreux retours utilisateurs et d’avoir des remontées sur ce type de besoins non anticipés.
Et depuis, pour chaque idée de nouvelle fonctionnalité, les utilisateurs sont consultés. Si l’idée est globalement validée, un premier effort limité est déployé pour en proposer une première version. Et selon les retours utilisateur soit un investissement plus conséquent et réalisé, soit l’énergie est redéployée sur un autre sujet.

Retours d’expérience

Il n’y a pas eu de gros imprévus ou de déceptions. Même s’il y a eu des hypothèses qui ne se sont pas toujours révélées correctes. Il n’y a jamais eu non plus de problème de production, à part quelques soucis de performances sur le volume de données, qui ont été résolus.
De plus, il y a de bonnes relations avec les clients, ce qui permet d’avoir un dialogue régulier, et d’avoir une remontée rapide des problèmes. Cela facilite la réactivité en cas de bug et la prise en compte des demandes d’évolution dans une feuille de route.

Le bilan est donc très satisfaisant. D’autant plus que l’équipe technique était alignée avec la manière de faire : sortir au plus vite un produit qualitatif avec les fonctionnalités principales pour pouvoir rapidement être sur le marché et dans les mains des utilisateurs.
Avec le recul il y a peut-être tout de même des points qui auraient pu être faits différemment, que ce soit des choix techniques ou des fonctionnalités laissées de côté. Même si cela pouvait nécessiter d’y passer quelques semaines de plus. Car maintenant que le produit est en production avec des clients, il est plus complexe d’opérer des changements drastiques. Mais lors du développement il était difficile de discerner les différents impacts à venir sur ces points.

Prochaines étapes

La stratégie est de sécuriser progressivement ce qui a été fait. En effet, il est toujours compliqué de repartir de zéro. On peut avoir l’impression que c’est une solution qui réglerait tous les problèmes et que l’on peut essayer de se débarrasser de la dette technique en recommençant depuis le début. Mais malgré les apprentissages et l’expérience, il y aura à nouveau des contraintes de temps, de budget et autres, qui engendreront à leur tour de la dette technique. De plus cela inclurait des problématiques autour de la migration des données et des utilisateurs, avec soit la migration des anciens utilisateurs, soit le maintien de deux versions parallèles.
Bien que le principe de devoir tout redévelopper à un moment était une option, elle n’a finalement pas été retenue. L’objectif est de bâtir sur l’existant.
La question se pose par contre de quitter Heroku pour passer sur AWS. Mais tant que ce n’est pas un réel besoin, l’énergie est investie ailleurs.
Il y a par contre une refonte UX prévue, basée sur les connaissances accumulées en termes de workflows et de la manière dont les utilisateurs utilisent l’outil. Il y aura donc un travail de refonte, suivi de l’intégration de nouvelles fonctionnalités attendues par les clients. Mais au niveau architecture technique ou autre, il n’y a pas de changement prévu.

La levée de fonds a aussi permis de recruter des collaborateurs internes dédiés au projet.
L’accompagnement pour lancer le projet, et adresser les problématiques de production et de performance même après la mise en production a été nécessaire et confortable. Mais maintenant, avec des personnes en interne, il n’y a pas d’intérêt d’avoir deux équipes qui travaillent en parallèle au quotidien.
Par contre, il y aura probablement toujours besoin de prestation sur des sujets spécifiques, pour chercher de l’expertise ou pour avoir une capacité de développement plus importante.

Nous publions également régulièrement des articles sur des sujets de développement web et mobile, de data science, de conception produit et d’organisation du travail. N’hésitez donc pas à suivre notre compte Medium pour être notifié de nos prochaines publications et réaliser votre veille professionnelle.

Vous pouvez également suivre nos publications et notre actualité professionnelle, via nos différents réseaux sociaux : LinkedIn, Twitter, Facebook, Instagram, Youtube, Twitch, et notre newsletter mensuelle.

Để tìm hiểu thêm về công ty và kiến ​​thức chuyên môn của chúng tôi , bạn cũng có thể tham khảo trang Linkvalue và các lời mời làm việc của chúng tôi trên trang Chào mừng đến với Jungle .