Comment organiser le développement dans une startup de logiciels allégés ?

Salesflare à l'intérieur de l'entreprise

La création d'une entreprise technologique peut être un processus chaotique, stressant et gratifiant.

But one of the things that can really help early on is to have structures in place that empower your team to work effectively and efficiently — especially on the development side. The last thing your company needs is chaos around building your product. 😱

Alors, comment commencer ? Et devez-vous sous-traiter ou embaucher en interne ?

Below is a quick guide to building and structuring your SaaS development team — and if you do decide to outsource, you can use this guide as a framework as well. 🤩


Categorizing development at your company

One of the things that can help with development structure is to break down the different types of development tasks at the company into categories, so you can have a better idea of prioritization, delegation and organization within the team. 🤝

Vous trouverez ci-dessous les trois catégories de développement que nous avons chez Salesflare :

Enjeux sont des éléments qui ne fonctionnent pas et qui doivent être corrigés dans le produit.

But what has priority? And how do you organize them? That’s why we’ve broken issues down into three additional categories: instant issues, instant staging and non-instant issues.

Instant issues are the ones that — you guessed it — need to be addressed immediately. These can be things that are really broken, things that the users notice, things in the app that need to be fixed, etc. 🚨

guy throwing bucket of water on a hay fire

Instant staging is not as “instant” as instant issues, but these are things that need to be fixed before releasing the newest software version into the production environment. These are mostly issues that we notice on our staging environment through internal testing.

Les problèmes non instantanés sont moins prioritaires et sont discutés lors de la réunion de préparation du sprint (nous y reviendrons).

Améliorations de l'interface utilisateur ont une priorité plus élevée que les problèmes non instantanés et comprennent tout ce qui, dans le développement, a trait à l'expérience et à la facilité d'utilisation du produit. Il s'agit essentiellement de choses qui améliorent l'expérience des clients.

Caractéristiques sont de nouvelles fonctionnalités que nous voulons ajouter au produit, telles que les actions en masse, le filtrage avancé, etc. Il s'agit des tâches les moins prioritaires parmi celles planifiées au cours d'un sprint.

Si la répartition des types de développement peut vous aider à mieux organiser votre équipe, comment décider qui s'occupe de quoi ?


Support Hero is here to save the day!

As a SaaS company ourselves, we understand the importance of addressing issues promptly to give customers the best experience possible. However, that doesn’t mean that we should have the entire team spending their days jumping on issues — we’d never get any other work done! 👨‍💻👩‍💻

That’s why we use a system that both removes distractions and increases productivity within the development team. We call it the Support Hero.

superman

The Support Hero is one person on the development team, rotated daily, that focuses on instant issues that need to be addressed (and answers more in-depth and technical questions users have), so that the team can stay focused on their tasks. 💪

Any issues that can’t be fixed in that exact moment by the Support Hero are logged in GitHub, the software we use for code and issue management, and is then addressed as soon as possible.

The beauty of having a Support Hero is that even with a small team, you can offer high-quality support to your customers — any in-depth technical issues can be fixed on the spot, avoiding the frustrating process of having to hand off issues to the “right” person.

Le plus beau, c'est qu'il n'y a pas d'autre solution : having a Support Hero brings your developers closer to your customers. 💛


It’s all about structure

Now that we’ve touched on the types of development and how to delegate issues, let’s discuss how to organize your structure. All of the different components below come together to inform how the team moves forward.

Une vision du produit et une feuille de route can help you know where you want to bring the product, so you can then have features in mind that will get you there — this ideally overlaps with what you pick up from your support. 👓

Soutien est tout sur l'obtention d'un retour d'information de la part des clients. Cela comprend les demandes de fonctionnalités, les problèmes et les améliorations de l'interface utilisateur, qui suivent la vision du produit et la feuille de route susmentionnées. Enregistrez-les et apportez-les à la réunion de préparation du sprint.

Un outil de suivi des problèmes reports errors both on the back-end and the front-end. It also allows you to see what issues appear even without people telling you. One suggestion is Elastic APM — but there are many options out there.

Tests internes allows your whole team to test new features before they go live. We test actively before releasing updates from staging to production. And since we use Salesflare internally, we can therefore detect possible issues and improvements in the product ourselves as well. It’s always good to have your team use your product whenever possible to get first-hand exposure to any issues that can arise and to have a deep understanding of your own product.

Hotjar Les sessions d'enregistrement peuvent aider votre équipe à voir comment les gens interagissent avec le produit et où les choses se passent mal (ou bien). Les enregistrements d'utilisateurs, même s'ils ne sont pas nécessaires au quotidien, peuvent vous donner des indications supplémentaires sur la manière dont les utilisateurs se servent de votre produit, puisque vous pouvez voir ce qu'ils font sans qu'ils aient besoin de vous l'expliquer.


Time to sprint!

Structure your development team’s work into sprints — an agile methodology. As a general guideline, two-week-long sprints are most common for IT and software product development. 🏃‍

However, it’s recommended to prepare ahead of your sprint meetings — otherwise things can get a bit chaotic and off-topic.

This can be addressed by having sprint preparation meetings. The CTO, product owner, and product manager (read more about the difference between product owner vs product manager) attend this meeting, and use this time to look at instant issues that are remaining, UX improvements, non-instant issues, and features. This helps set the agenda and priorities for the upcoming sprint without needing to take time out of the sprint meeting itself. ✅

Then, of course, it’s time to have your sprint meeting! The sprint meeting zooms in technically on what was discussed during the sprint preparation meeting, so that the development team knows exactly how they will go about things. It also gives a platform to review instant issues together as a team. This meeting should include the CTO and development team. The product owner and support team can also join, but are less needed at this stage.

At the start of this meeting, it’s a good idea to reflect on the previous sprint — what went well, what went wrong, etc.


What’s in your toolkit?

The tools you use within your company can set your development team up for success. We’ve already touched on Hotjar and Elastic APM, but some other tools to consider for more streamlined communication and task management include:

Slack — pour les discussions internes, les mises à jour/notifications, le partage de fichiers et les gifs amusants occasionnels

Trello — pour la tâche/la gestion et le suivi des projets qui fait quoi dans un sprint donné

GitHub — où nous suivons les problèmes, les demandes de fonctionnalités, etc.

Intercom — pour communiquer avec les clients

A great aspect of using these tools is that they can interact with one another. For example, we get updates from Trello and Github in Slack. And in Trello we use a GitHub power-up that integrates GitHub info into Trello. 🌐

De plus, nous pouvons relier GitHub aux conversations Intercom, ce qui nous permet d'avoir toujours le contexte à portée de main ; et lorsque nous livrons des fonctionnalités ou corrigeons des problèmes, nous pouvons communiquer à ce sujet sans faute.


Regardless of how you decide to structure development at your company, it’s always important to make sure that your team — no matter how big or small — can work within the processes you decide to utilize. 🚀

Don’t be afraid to change things if they aren’t working! The key is to find what works for you and your company and go with that.

Nous espérons que ce guide rapide vous a donné un peu d'inspiration sur la manière de constituer et de structurer votre équipe de développement !

Have more great ideas? Tell us in the comments! ✨


Cet article vous a plu ? Consultez le reste de notre Salesflare à l'intérieur de l'entreprise série.


Pour plus d'informations sur les startups, le marketing de croissance et les ventes

👉s'inscrire ici

👉follow @salesflare on Twitter ou Facebook

 
Ali Colwell