planet #openweb

Le plus court chemin entre deux points est toujours la ligne droite, si et seulement si les deux points sont parfaitement alignés.

Ce week-end, c’était mise en production. Un petit pas pour le soft, mais des traitements portants sur des centaines de millions d’enregistrements, et une fenêtre de tir extrêmement réduite, application B2B oblige.

Jeudi matin, après une batterie de tests portant sur des volumes six fois moindres que ceux que nous avions à traiter, le couperet tombe : si le rapport entre le temps passé et la quantité de données est linéaire, il nous faudra plus de 30 heures pour migrer.

– C’est la merde… tu as un plan B ?
– Oui, en cours de test.
– Et un plan C ?
– Non mais dans le quartier, on devrait facilement trouver un plan Q.

Quatre heures plus tard, nous avons la confirmation que le plan B nous permettra de migrer dans les temps, et devrait même nous offrir une heure d’un rab’.

Imaginez que vous deviez traverser un pays, au hasard, l’Australie, en un temps limité. Ce pays est parcouru de bout en bout par une gigantesque route, toute droite. À première vue, la solution la plus simple consiste à affréter une voiture, la charger de bidons d’essence – il n’y a aucune station le long de la route route – et à se lancer à deux en se relayant au volant, car il n’y a pas non plus d’hôtel.

Ça, c’est le plan A. Le plan A est souvent (toujours) la manière la plus simple et la plus sûre de faire les choses : en misant sur la simplicité, on s’affranchit des problèmes que peuvent engendrer un système complexe.

En pratique, il y a pas mal de raisons de s’en faire. Que faire si le moteur casse en chemin et qu’il vous faille attendre une dépanneuse pour recommencer le trajet depuis le début ? Qu’arrivera-t-il si la route est coupée par les intempéries, ou rançonnée par des pirate ?

Dans les faits, la ligne droite n’est pas toujours le plus court chemin entre deux points, parce qu’elle implique une absence totale d’imprévus. Cette ligne droite, c’est le plan A.

Votre plan B est très différent.

Vous avez la possibilité de traverser le pays en zig-zag, par avion, mais au prix d’une demi douzaine d’escales, et d’un kilométrage forcément plus élevé. Il faut coordonner les vols afin de prendre votre correspondance au bon moment, en évitant les attentes au maximum, ce qui vous oblige à travailler avec plusieurs compagnies aériennes souvent concurrentes. Au final, pourtant, ce plan B s’avère le meilleur : l’avion est plus rapide que la voiture, cela compense le kilométrage. En cas d’orage ou de problème technique, pas besoin de recommencer depuis le départ, il suffit juste de recommencer l’étape. Pas la peine de s’encombrer de ressources, puisqu’on fait le plein à chaque aéroport.

Le problème du plan B, c’est qu’il est plus compliqué à élaborer, que le plan A, parce qu’il passe par toute une série d’étapes au lieu d’aller au plus simple. Il est également moins évident intellectuellement, parce qu’il exige d’étudier les problèmes sous tous les angles. Il demande un plus grand effort, mais offre en contrepartie une plus grande sécurité, des étapes plus courtes, donc aux aléas plus prévisibles,

Si chaque fois que vous vous lancez, vous élaborez un plan A, puis un plan B, vous vous rendrez très vite compte que c’est presque toujours le second que vous mettrez à exécution.

Cet article a été originellement publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

L’annonce par ASP Servers d’une solution de Cloud Quantique® garantissant à ses clients un niveau de disponibilité record de 100% a jeté un pavé dans l’écosystème de l’hébergement haute disponibilité, reléguant Amazon, Azure et Rackspace au rang mammouths fossilisés d’un autre âge. Pourtant, cette technologie révolutionnaire apporte avec elle des paradigmes qui vont fondamentalement bouleverser notre manière d’envisager l’informatique, mais également l’arithmétique la plus élémentaire.

La fin des données telles que nous les connaissons

Le Cloud Quantique® apporte une révolution dans la manière dont nous envisageons l’existence mêmes des données stockées sur nos systèmes d’information. C’est un bouleversement des paradigmes de l’informatique moderne, puisque, tant qu’on ne cherchera pas à accéder à une donnée, il sera impossible de garantir si elle est là, ou non. Ce problème de la mesure de l’existence des données dérive directement d’un des fondements de la physique quantique élaboré en 1935, et permet de dire qu’à un instant T, une donnée existe et n’existe pas à la fois (ou qu’un disque dur de RAID est vivant selon la supervision, mais mort en réalité).

Imaginez un peu les conséquences d’une telle révolution sur nos services de la vie quotidienne, et au delà sur le législateur. Tant que vous ne visitez pas le profil d’une personne sur Facebook, celle-ci est mariée avec vous et célibataire à la fois. Le Cloud Quantique® ouvre donc la porte à la polygamie de fait ; va-t-on pour autant l’interdire ? La question est difficile.

Ce principe n’est d’ailleurs pas limité au Cloud Quantique®, puisqu’il s’applique à l’hébergement traditionnel. Les personnes ayant eu à restaurer des données à partir d’une sauvegarde le savent bien : tant qu’on ne cherche pas à le récupérer, le backup est là et pas là à la fois.

sqrt(0,9995²) = 1

Le niveau de disponibilité record de 100% annoncée par le livre blanc sur le Cloud Quantique® à partir de la réplication s’appuie sur une remise en cause fondamentale des axiomes de Peano. Deux data center offrant une disponibilité de 99.995% (au mieux) permettent en effet de garantir une disponibilité de 100%.

Appliqué à de gros volumes, sqrt(0,9995²) = 1 a déjà des impacts insoupçonnés sur l’ensemble de l’économie mondiale. C’est même, encore une fois, une véritable révolution, puisqu’il n’est plus possible de connaître à l’avance la valeur exacte d’un ensemble de titres boursiers. Devant la panique générée par cette découverte, les quotations de Paris, New York et Hong Kong ont d’ailleurs été suspendues, et le problème se répand déjà de manière quantique à l’économie réelle : on s’en fiche et on ne s’en fiche pas à la fois.

Cet article a été originellement publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

Ce qui suit est la traduction autorisée de 2013 Guide To Hiring Engineers (based on the 1943 Guide To Hiring Women) de Penny Herscher.

Cet article est destiné aux personnes en charge du management des ressources d’ingénierie durant la révolution numérique de 2013.

11 conseils indispensables pour tirer le maximum de vos ingénieurs :

La question de savoir si les entreprises des nouvelles technologies doivent engager des développeurs à des postes autrefois occupés par des analystes système et de théoriciens de l’informatique hardcore ne se pose plus. L’explosion d’Internet et des terminaux mobiles, et la raréfaction des ressources techniques qui s’ensuivit a depuis longtemps clôt le débat. L’important aujourd’hui est de savoir comment sélectionner les meilleurs ingénieurs et comment utiliser au mieux leurs compétences.

Voici onze conseils utiles tout droit venus de la Silicon Valley :

1- Choissez des ingénieurs célibataires. Ils ont généralement plus de temps que leurs confrères mariés ou en couple, ils seront moins enclins à rentrer tôt chez eux, ils aiment leur travail sinon ils feraient autre chose, ils ont la pèche, travaillent dur et codent efficacement.

2- Si vous devez utiliser des développeurs plus âgés, employez-en qui n’ont pas travaillé toute leur vie dans l’informatique. Les vieux développeurs qui n’ont jamais été en contact avec les clients ont du mal à s’adapter et tendance à être frileux et franchement soupe au lait quand il s’agit d’ajouter des fonctionnalités. Il est bon de rappeler régulièrement l’importance de la qualité et de l’expérience utilisateur aux vieux développeurs.

3- L’expérience montre que les développeurs enclins au surpoids et qui grignotent à longueur de journée sont plus productifs que leurs confrères plus en forme enclins à consacrer du temps à faire du sport.

4- Faites passer un examen clinique à chaque développeur, afin de vous assurer qu’ils ont toutes leurs facultés de concentration et ne se droguent pas. Non seulement cette étape protègera-t-elle votre entreprise contre de possibles procès à venir, mais vérifier que votre future ressource ne se drogue pas permettra également de valider que le développeur est apte physiquement et mentalement à travailler pour vous.

5- Revenez régulièrement sur l’importance du temps de travail, combien une minute perdue par ci par là peut avoir d’importantes conséquences sur le planning produit. Tant que ce point n’est pas parfaitement compris, la productivité des équipes risque de s’en ressortir fortement.

6- Donnez chaque jour un planning détaillé à vos développeurs, de telle sorte qu’ils soient occupés du matin au soir et ne dérangent pas le management avec de constantes questions. Beaucoup de sociétés disent que les développeurs font d’excellents ouvriers si leur donne du travail prédécoupé, mais qu’ils ont du mal à prendre des initiatives.

7- Quand c’est possible, permettez aux développeurs de varier les projets dans la journée. Les développeurs sont moins moroses et plus généralement plus heureux avec un peu de changement.

8- Donnez à vos développeurs un certain nombre de pauses durant la journée. Vous devez être plus souple avec la psychologie des geeks. Un développeur aura plus facilement confiance en lui et sera plus efficace si on le laisse regarder des vidéos de chat, jouer à la console ou boire un Coca Light plusieurs fois par jour.

9- Faites attention à la manière dont vous leur donnez des instructions, ou que vous critiquez leur travail. Les développeur sont des êtres sensibles ; ils ne supportent pas les remontrances aussi bien que les commerciaux. Ne ridiculisez jamais un développeur, c’est le meilleur moyen de le rendre totalement inefficace.

10- Faites attention à ne pas dire trop de gros mots devant un développeur. Bien que ses pareils jurent à longueur de temps quand ils jouent à un FPS, les développeurs n’aiment pas les environnement de travail où l’on prononce trop de gros mots.

11- Achetez plusieurs tailles et types de chaises, bureaux et écrans. Chaque développeur a des préférences quant à son environnement de travail. C’est un point sur lequel il ne faut pas déroger si l’on veut garder ses développeurs heureux.

Cet article a été originellement publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

N’importe quel imbécile peut avoir 15 idées géniales par jour, mais tout le monde n’est pas capable de la réaliser. J’ai d’ailleurs une douzaine de projets qui attendent que je m’y remette.

La semaine dernière, Alex Delivet estimait à 1/100 le ratio biz guy / développeur prêts à se lancer dans l’aventure entrepreneuriale. Même si ces proportions sont exagérées, et qu’elles tournent aux alentours de 1/10, la disparité entre les profils nécessite de faire attention quand on recherche son cofondateur technique.

Entre les listes de diffusion de développeurs et mon adresse de contact, j’ai vu passer pas mal de wanna be entrepreneurs qui se tiraient une balle dans le pied avant même d’avoir pu commencer à raconter leur histoire. J’en ai tiré 7 conseils fondamentaux pour prendre contact avec son futur cofondateur.

1. Présentez-vous (!!!)

Se présenter est le B A BA de la politesse, à tel point que la plupart des gens passent à côté.

Le premier contact n’est pas un elevator pitch, mais l’établissement d’une relation entre personnes ; c’est vous que vous vendez avant de vendre votre projet. Présentez-vous avant de parler de votre projet. Si vous avez déjà brièvement rencontré votre interlocuteur, rappelez-lui qui vous êtes, et dans quelles circonstances.

Se présenter avant d’annoncer son projet donne en plus le contexte : qui êtes-vous ? D’où venez-vous ? Quelle est votre formation, votre profil ? Qu’avez-vous fait avant de lancer votre entreprise ? N’hésitez pas à ajouter des liens qui peuvent vous sembler intéressants : liens vers votre blog, votre compte Twitter, votre profil Linkedin ou mieux, votre compte Github. Ne forcez pas votre interlocuteur à vous googler, il le fera certainement de lui-même si votre mail l’intéresse.

2. Présentez votre projet

Présentez rapidement votre. Soyez précis et concis au lieu de rester dans le flou. Je souhaite monter une plate-forme Web, autrement dit une startup montre que vous ignorez où vous allez et vous place directement dans la case “guignol pas sérieux qui ne sait pas de quoi il parle”. Et si vous voulez vraiment terminer dans le répertoire spam de votre interlocuteur, la solution la plus rapide est probablement de mentionner un NDA.

Personne ne veut vous voler votre idée, parce que personne n’en a rien à faire. En parler permet d’obtenir des avis, des conseils, des pistes d’extension ou de réalisation… Mes derniers échecs m’ont appris une chose : on ne peut pas maturer une startup en stealth mode ; c’est une connerie monumentale. En parler autour de soi est la meilleure manière de sortir la tête du guidon et d’être ramené à la – souvent dure – réalité.

3. Apprenez à coder et réalisez un prototype

Apprenez à coder, ça n’a rien de vraiment sorcier. Il existe de nombreux sites d’apprentissage de la programmation. Certains comme Coursera ou Codecademy sont même gratuits, et largement suffisants pour réaliser le premier prototype de votre produit.

Si vous n’avez aucune légitimité en tant qu’entrepreneur, personne n’acceptera de vous suivre sur votre simple bonne mine. Fermez ce fichier Excel sur lequel vous prenez vos désirs pour des réalités, et lancez vous : vous montrerez à ceux que vous contactez que vous êtes capable de vous débrouiller pour obtenir ce que vous voulez, même si c’est moche, que c’est fonctionnellement hyper limité et que ça ne scalera jamais. Au moins, ça existe.

4. Faites les choses à l’endroit : d’abord les hommes, ensuite la technique

À moins d’être vous-même développeur et de vouloir partir sur une technologie que vous connaissez vraiment, ne vous bridez pas en cherchant un CTO qui maîtrise [insérez ici un buzzword à la mode] sous pretexte que 01 Informatique dit que c’est bien.

Le marché est réduit, cherchez d’abord la personne avec laquelle vous aurez vraiment envie de fonder votre entreprise, vous vous focaliserez sur la technologie après. Peut-être avez-vous lu que Ruby On Rails ne scalait pas, que PHP était broken by design, ou que Java bouffait une quantité incroyable de ressources, développeurs et machines mélangés. Ce n’est pas grave. Si Mr. (ou Mrs.) Right maîtrise une technologie, ce serait dommage de passer à côté. Assurez-vous juste que cette technologie soit un tant soit peu pratiquée sur le marché : Scala, oui, Fortran77, non !

5. Ne parlez pas de vivre à crédit !

Par principe, une startup n’a pour argent que celui de ses fondateurs. Personne ne vous fera confiance si vous expliquez d’entrée de jeu que vous comptez vivre à crédit, et dépenser l’argent des autres.

Soyez honnête : dites que vous n’avez pas encore de business model, ou mieux, n’en parlez pas du tout pour un premier contact. Mais d’une manière générale, bannissez de votre vocabulaire des termes comme “business angels”, “capitaux risqueurs”, ou “crowdfunding”. Ils donnent une image catastrophique de votre capacité à monter un business.

6. Soyez humble

Vous prenez contact avec quelqu’un qui sait des choses que vous ne connaissez pas et dont vous avez besoin.

Si vous vous montrez un tant soit peu hautain vis à vis de “la technique”, vous êtes mort. Pour que votre duo fonctionne, il faudra que vous passiez les prochaines années à apprendre pourquoi il considère certaines choses importantes, et d’autres pas (et vice versa). Même si c’est le cadet de vos soucis, il vous faudra apprendre à comprendre ce qu’il fait.

Ne donnez pas l’impression que vous avez déjà planifié toute l’aventure, vous montrerez que vous êtes complètement à côté de la plaque. Votre business plan est un document dans lequel vous prenez vos désirs pour des réalités, pas le scénario d’un film (catastrophe) tel qu’il sera réalisé.

7. Soyez concis

Ne racontez pas votre vie, c’est un premier contact, pas une séance chez le psy. Vous devez donner envie à votre interlocuteur de reprendre contact avec vous pour un petit déjeuner, une bonne bouffe ou un café.

Il y a quelques mois, j’ai travaillé avec quelqu’un qui considérait qu’un mail ne devait pas faire plus de trois phrases. Sans aller aussi loin, mettez-vous à la place de votre interlocuteur : combien de temps seriez-vous prêt à consacrer à ce genre de sollicitations ? Et non, votre projet n’est pas génial au point que la terre doive s’arrêter de tourner pour vous.

Je terminerai par un dernier conseil, qui sort du cadre de ce billet. Vous voulez vraiment lancer une startup et vous croyez que votre projet va révolutionner le monde ? Participez à un startup week-end. Durant 54 heures, vous serez confronté à la réalité, monter un business plan, créer un prototype et pitcher des investisseurs ou des entrepreneurs aguerris, et travailler avec des vrais gens, pas juste avec une feuille Excel.

Cet article a été originellement publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.