Saas et B2B: rien ne sert d’innover sans compatibilité

Posted on by
Reply

Je viens récemment de faire les frais d’une évidence accablante: faire du Saas pour des clients B2B et des grosses boites du CAC, c’est bien plus contraignant et complexe d’un point de vue techno et interopérabilité que de dealer avec des utilisateurs lambda dans leur canap’ derrière leur Freebox ou Livebox..

Imaginez vos utilisateurs, bloqués sur Internet Explorer 7 ou Firefox 3, sans aucun pouvoir de changement (pas les droits d’admin, c’est ballot..) sous 5 couches de pare-feux d’entreprises plus méchants et débiles qu’utiles (je connais un admin sys qui veut pas d’ennuis, et qui par précaution, bloque tout..).
Dès lors, deux possibilités s’offrent à vous:

  • Vous vous battez contre le système et vous optez pour certaines technos et dealez des contrats annuels (licences) suffisamment importants pour justifier l’intervention de l’admin sys de vos clients pour mettre à jour les navigateurs des employés et faire le nécessaire d’un point de vue réseau / pare-feux pour assurer le bon fonctionnement de votre solution
  • Vous faites profil bas et gardez en tête toutes ces contraintes dans vos choix technos et plannings de développements, et prévoyez fallbacks et dégradations gracieuses pour faire marcher de façon transparente votre solution sur la pire des configuration que vous souhaitez supporter (globalement ie7 car vous n’êtes pas suicidaire au point de supporter ie6, sur le port 80 seulement et le protocole http uniquement..)

Votre philosophie d’entreprise sur ce point est très importante, car détermine la façon dont vous vendez/pricez votre solution, la façon dont vous l’implémentez chez vos clients et les technos/protocoles que vous utilisez.. Et si vous choisissez la deuxième solution, qui me semble la plus appropriée pour conquérir le monde et vous implanter plus facilement chez vos clients, attention à bien placer curseur sur la balance “compatibilité” et “qualité d’utilisation / performances”.

Et vous, pro du B2B, avez-vous déjà rencontré ce genre de problème? Avez-vous déjà effectué un ou plusieurs compromis/concessions pour fonctionner chez vos clients les plus récalcitrants? 

Quelques conseils pour rendre votre startup plus developer-friendly

Posted on by
Reply

Comme le montrent les réactions du précédent billet, un bon (voire un excellent) développeur ne rejoindra pas votre startup juste pour vos beaux yeux, trois nèfles, quelques pizzas et quelques bières. C’est sur ce point que nous avons décidé de plancher avec Guilhem cette semaine: comment rendre votre startup plus développeur-friendly ?

Une vraie situation d’équilibriste : comment, avec des moyens financiers limités et plein de batailles onéreuses à mener de front, valoriser le travail de vos développeurs, les gratifier à hauteur de leurs succès, de leur importance pour votre startup et les mettre dans les meilleures conditions possibles pour qu’ils produisent le meilleur d’eux-mêmes tout en « kiffant » réellement leur job? Attention, je ne dis pas ici de ne pas les payer, ni de les sous-payer! C’est un autre débat, si vous n’avez pas de sous, associez-les au projet, au capital, et il ne s’agit plus là d’employés mais de fondateurs qui prennent 100% des risques avec vous sans salaire. Ja parle ici de vos premiers réels employés, que vous payez, mais que vous ne pouvez engraisser honteusement comme peuvent se le permettre nos fameuses SSII, Web Agencies, banques, boites du CAC40 et consorts..

Je vous invite à lire la suite de cette réflexion co-écrite avec Guilhem sur son blog.

7 bonnes raisons pour quitter votre job en SSII ou Web Agency et rejoindre une startup

Posted on by
73
Aujourd’hui, un petit billet dans la série de co-écriture que nous avons entamé avec Guilhem il y a quelques jours. Ce coup-ci, c’est lui aux manettes pour le gros du billet!
La dernière fois que nous nous sommes croisés, nous avons pas mal discuté recrutement, code et ninjas, vaste sujet, assez critique pour une startup web. Je déplorais la “perte” de bons éléments (stagiaires, collègues, connaissances) en milieu SSII ou WebAgency quand nous est venu cette idée de billet qui fera peut-être grincer des dents certaines boites: 7 bonnes raisons pour tout plaquer et venir travailler dans une chouette startup!

A toi Guilhem!
**********
Bonjour à tous!
Ce n’est pas un secret : en France, on a un problème avec nos ingés et développeurs.
C’est vrai, ils font des écoles, des stages, tous les horizons leur sont ouverts, sont plutôt bons par rapport à leurs homologues étrangers… et patatras, les voilà qui se réfugient à 90% dans des SSII. Forcément, du point de vue de l’entrepreneur que je suis (et apparemment, je ne suis pas le seul), c’est frustrant, surtout lorsque l’on est persuadé que nos chers développeurs seraient bien plus heureux… dans nos startups !

Alors je m’adresse à vous, développeurs et jeunes padawans encore sur les bancs de l’école, en vous proposant quelques arguments pour vous aider à faire le grand saut, et à quitter (ou refuser de rejoindre) le monde affreuxxxxxxxxxx des SSII (beurk) :
  • L’argent ne fait pas tout. C’est sûr que de prime abord, les SSII ont une proposition de valeur assez alléchante : un bon salaire. Alors OK, en sortant des études, c’est sympa d’avoir un chouette niveau de vie, de pouvoir se refaire une garde-robe (ah, ah), et se payer des bières sans compter à la dépense. Pour ceux pour qui l’argent est le seul et unique critère, la SSII semble le bon endroit pour s’épanouir. Pour les autres, vous pouvez continuer la lecture et surtout, demandez-vous si, en-dehors de l’aspect salarial, le compte y est dans votre situation actuelle.

Soyez agiles, mettez des process!

Posted on by
1

Je pense que vous l’avez assez lu ou qu’on vous l’a assez répété, ce qui fait qu’une startup bien souvent tire son épingle du jeu c’est une pincée d’idée, un zeste d’équipe et une bonne dose d’exécution. Et l’exécution, quand on est une toute petite équipe, avec peu de moyens, une multitude d’idées et peu de temps, elle dépend de l’organisation et la rigueur que l’on va instaurer. Cela peut paraitre étrange voire paradoxal pour une startup qui se veut innovante, révolutionnant le monde et créative, mais une startup qui réussit est une startup qui met en place très tôt des process. Quand j’écris process, je ne parles pas de réunions interminables, de hiérarchie faisant pâlir un arbre généalogique, de points, de re-points, de rapports, etc… panoplie exacerbée des grosses boites type CAC40, mais de moyens/méthodes/outils simples et assez rigoureux qui permettent au petit monde d’une startup d’avancer droit, efficacement, focus et agilement.

L’agilité. Voilà dont il est question. Et cette agilité est cruciale lorsqu’on en vient à développer une solution technique avec peu de moyens, de budget une un grande ambition.

Quelques écueils éviter:

  • Des délais de développement interminables: évitez des cycles de développement trop longs et trop ambitieux. Découpez votre projet en briques fonctionnelles et développez-les les unes après les autres tout en iterant dessus (ou modèle Lean).
  • Des features inutiles ou trop complexes: astreignez-vous à sortir uniquement des MVP de vos nouvelles features, épurez tout du superflu dans un premier temps.
  • Manque de flexibilité et adaptation aux retours clients/consommateurs: plus vous vous avancez loin dans vos développements sans de feedback réel d’utilisation de clients, plus vous aurez à casser ensuite pour reconstruire..
  • Manque de synchronisation et de visibilité entre les équipes: backend, front, market, produit.. tout ce petit monde a son rôle à jouer au bon endroit et au bon moment, comment donner de la visibilité à chacun et bien huiler tous ces rouages?

Quelques pistes de process simples à mettre en place:

  • Pour vos développements, adoptez la méthodologie Scrum: prise en main, 20 minutes. Commencez par des post-it sur un tableau blanc. Dès que vos équipes grossissent, optez pour une webapp simple et efficace (j’utilise Scrumwise au quotidien). Vous avez ainsi un cadre pour vos développements, l’obligation d’aller vite et de prévoir des projets concis et simples sur de courtes périodes (fini la galère du Gantt) vous permettant de vous adapter rapidement à toutes situations. Filez faire un tour sur l’excellent blog de Guilhem pour un billet croisé sur la mise en place de la méthodo Scrum.
  • Pour votre équipe Biz, optez pour du project management simple ou de la quick todo: Bascamp ou Producteev permettront aux équipes non techniques d’avoir aussi leur quotidien cadré et de la visibilité sur ce que chacun fait. Fini les points de 3 heures régulièrement, un rapide coup d’oeil aux différentes todos feront l’affaire, et un point hebdomadaire plus approfondi suffira désormais.
  • Pour votre vision et votre projet, optez pour des cycles courts et dynamiques: au niveau business, établissez un plan mensuel. Etablissez une ligne de conduite claire, les objectifs business à atteindre, les moyens à mettre en oeuvre, ce qui ne doit pas être fait (éviter les distractions) et tenez vous à cette ligne de conduite! Au niveau produit/développement de votre solution, optez pour des cycles de 2 à 3 mois maximum: listez tout ce que vous souhaitez faire (évolutions, améliorations, nouvelles features..), priorisez, écrémez, pensez MVP à chaque fois, et décidez quelles seront les 4-5 chantiers que vous retiendrez pour ce cycle. Établissez vos scrums ensuite sur des délais plus courts.

Il n’y a pas de remède miracle c’est évident, et même si la mise en place de tout ceci ne semble paradoxal ou pas important au début de votre startup (pas assez de monde pour que la complexité se fasse sentir et des process à définir) et qu’il vous semble avancer plus vite et plus efficacement tête baissée dans vos démarches commerciales, vos développements produit, ce recul et ces lignes de conduites vous permettront de garder efficacement le cap et de servir votre vision au mieux, contre vents et marées dans votre petite embarcation sans dévier mais vous permettant de pivoter au mieux pour éviter les récifs si cela se présente!

Mettez des tests dans vos développements (ils vous le rendront bien)

Posted on by
11

S’il y a bien quelque chose de chronophage et de littéralement barbant, c’est bien le debug de sa solution.. Qui n’a jamais connu les interminables sessions de correction à droite, puis à gauche, puis re à droite, etc..

Tout simplement, chaque nouvelle ligne de code peut porter préjudice à la solution actuelle (avoir du beau code découplé et modulaire limite toutefois la casse) et entrainer des régressions deci delà. La solution? Pour chaque bloc de code (fonction, module) écrit dans votre projet, écrivez un ou plusieurs tests (unitaires et/ou fonctionnels) associés. A chaque fois.

Ça peut vous paraître chiant, vous sembler prendre du temps et être contre productif au début, mais je vous garanti que cela va vous économiser un temps précieux plus votre projet avancera. Chaque nouvelle ligne qui entraine une régression vous sera signalée instantanément, plus de mauvaise surprise en production. Tout bug trouvé se voit corrigé et consigné dans un test pour ne plus jamais le voir ressurgir: ça vous donne envie de débugger car désormais le débug à un sens et n’est plus un processus vain et non pérenne!

Et vous, mettez-vous des tests dans vos développements, unitaires, fonctionnels? Je cherche à mettre en place des tests javascript (car de plus en plus du coeur de ma solution est uniquement en js désormais), avez-vous des reco à ce sujet? Merci d’avance pour vos commentaires :)

 

3 petits conseils aux wanabe entrepreneurs (Interview Business-Actor.com)

Posted on by
Reply

La semaine dernière j’ai eu la chance de re-croiser une bonne connaissance, @Flo__Hernandez, qui non content d’être un street-hockeyeur émérite, tiens désormais quelques bon blogs dont le récent http://business-actor.com/

Je vous invite à lire mon interview sur business-actor pour en savoir un peu plus sur Balloon surtout. En attendant et si ça peut vous aider à aller la lire en entier, voici une question extraite de cet interview:

FH : Si tu avais 3 conseils à donner aux jeunes entrepreneurs qui vont lire cette interview, quels seraient-ils?

GP : Ces conseils sont bien évidemment tintés de mon expérience chez Balloon, mais cela serait plutôt ça :

  • Ne vous lancez pas seul ou mal accompagné, cherchez des profils complémentaires
  • Croyez impérativement à votre vision et votre produit : c’est l’unique chose qui vous fera tenir dans les moments durs. Monter sa startup ce n’est pas pour être riche, aménager ses horaires ou faire uniquement ce qui plait : ces points en découleront avec un peu de chance si vous avez eu raison dans votre vision et que vous vous y êtes accrochés jusqu’au bout.
  • Parlez. Beaucoup. A votre famille, à vos amis, à de potentiels clients, à d’autres jeunes entrepreneurs. Vous êtes en terrain inconnu, pas besoin de faire signer de NDA et de développer secrètement votre idée dans votre garage. Prenez tout le feedback que vous pourrez récolter. Adaptez, pivotez si besoin.

 

6 conseils pour mettre en place la méthode Scrum dans votre startup (pas plus)

Posted on by
Reply

Que d’activité blogistique après deux semaines d’abstinence (avec un déménagement de Balloon notamment, 115m2 de bureaux à repeindre, re-moquetter et meubler, rien que ça.. )!

Je vais essayer de reprendre le rythme d’écriture que je m’étais initialement fixé, à savoir un à deux (trois?) billets par semaine. Et cette semaine cela commence fort, avec un premier billet ce matin ci-dessous ainsi qu’avec un billet commun sur le célèbre blog de Guilhem Bertholet, qu’on ne présente plus: anciennement responsable de l’incubateur HEC Paris et désormais à full time sur sa nouvelle startup qu’il nous concocte aux petits oignons, nous avons eu l’occasion de discuter de nombreuses fois aux apéroentrepreneurs notamment (comment, vous n’y allez pas? C’est un tort ;) ) ainsi qu’au sein de l’incubateur sur les mêmes sujets qui nous animent (et là je reprends ses mots): “avancer le plus vite possible, avec des ressources limitées, parfois dans le brouillard et en tout cas en devant innover sans cesse…”.

Je partage dans ce billet ma mise en place simple et efficace du modèle Scrum pour la gestion de mes équipes de développement au sein de Balloon. Pas de recette magique, juste un petit retour d’expérience et un appel à une mise en pratique rapide. Guilhem agrémente fort bien cela de sa vision et méthodologie business qui vient encadrer / accompagner le Scrum avec le reste des équipes, au sein d’une Lean Startup.
Bref, déjà un must read ici!

PS: n’hésitez pas à laisser ici ou sur le blog de Guilhem vos commentaires, sur l’article comme sur l’éclairage que cette écriture à 4 mains a pu apporter ;)

Ne codez pas des oeuvres d’art (mais bâtissez des cathédrales)

Posted on by
7

Quand j’ai vu tourner cette image sur Twitter ce week end, cela m’a fait gentiment sourire car c’est un peu le sentiment que j’ai eu lorsque j’ai effectué mon tout premier stage à la DSI de Louis Vuitton à la fin de mes études.

Quelle ne fut pas ma déception lorsque derrière le strass et les paillettes il y avait  en fin de compte un bonne majorité de vieux programmes d’une dizaine d’années faisant tenir la boite et nécessitant des experts vieux de la vieille pour maintenir ces pachydermes ancestraux en bon état de fonctionnement. Idem pour mon amie qui se retrouve au département technique d’un grand groupe français de paris en ligne et qui désespère de voir du code mort ou du code répété joncher les lignes de la solution en très forte proportion..

C’est là où je veux en venir justement. Des exemples comme ceux-ci je suis persuadé qu’il y en a des millions. Dans les grosses boites du CAC, même chez Google, Facebook ou dans toute startup à la mode. Et c’est qu’il y a une raison, qu’on ne saisit pas à la sortie de l’école, des étoiles plein les yeux songeant que l’on va travailler au quotidien sur un chef-d’oeuvre de code: le code que vous produisez ou que les équipes produisent pour votre solution doit avant tout être fonctionnel et servir votre business.

Continue reading →

Développement web: tenez vos délais! (ou tout du moins, essayez..)

Posted on by
4

Je profite de l’excellente réponse de Michael Wolfe qui buzz pas mal sur Quora à la question “Pourquoi la majorité des développements informatiques explosent régulièrement le planning prévu d’un facteur 2 à 3?” pour me pencher à mon tour sur celle-ci et essayer d’apporter quelques pistes qui jusqu’à présent semblent ne pas trop mal fonctionner.

Comment planifier au mieux les développements de sa solution et de ses différentes versions/features afin de tenir au mieux les délais engagés? Cette fameuse question, je pense que tout entrepreneur y a déjà été confrontée et y sera confronté en permanence tout au long de son aventure.

Il s’agit là d’une question relativement cruciale à ce niveau, car contrairement à de plus grosses entreprises, le retard des développements en début de vie d’une entreprise sur ses releases peut avoir des conséquences désastreuses… Contrairement à une grosse entreprise toujours, il est impossible souvent d’obtenir des subventions supplémentaires, d’ajouter des développeurs à l’équipe tirant la langue pour compenser/rattrapper le retard ou de commercialiser quoi que ce soit en attendant la fin du projet.

Voici quelques pistes qui méritent je pense d’être explorées et adapter en fonction de sa startup pour essayer de mieux gérer cela: Continue reading →

Qu’est ce qu’un Lead Dev (en startup)

Posted on by
6

Il arrive un temps dans une startup, plus ou moins tôt en fonction du profil des associés, de leur niveau et appétence technique, où il devient nécessaire de recruter un Lead Developeur (comprenez en français, “développeur en chef”. Oui, c’est beurk).

C’est mon cas actuellement. Et avant que de poster une offre, il convient de se poser et de réfléchir aux points suivants, afin d’avoir les idées claires:

  • À quoi correspond ce poste exactement? Quelles sont ses caractéristiques, comment s’insère-t-il par rapport aux postes existants?
  • Une fois ceci défini, de quel profil j’ai besoin au juste? De qui ai-je besoin?

Mon expérience personnelle m’a donné à réfléchir à ces points en deux fois, par une période d’essai d’intervalle..

Continue reading →