Jetons un coup d'œil aux meilleures pratiques employées par Progress tout au long de l'ingénierie, de la gestion des produits et du support: ce qui guide notre travail, pourquoi ces processus sont-ils importants pour nous et comment pouvez-vous apprendre de nos propres meilleures pratiques internes.
Bonjour ! Je suis Mandy Mowers. Je travaille avec Progress depuis quelques années maintenant, en collaboration avec des rédacteurs externes pour créer du contenu de blog qui peut servir nos utilisateurs et d'autres acteurs de l'industrie de la technologie. Je n'ai pas eu beaucoup de chance de regarder à l'intérieur de cette entreprise, alors quand l'occasion s'est présentée de parler avec neuf des personnes responsables de nos produits, j'ai sauté dessus.
Je suis ravi de partager ce que je J'ai appris les pratiques et les processus qui guident le progrès.
Contexte du progrès et de Telerik
Pour fournir un peu de contexte, je voulais partager un peu l'histoire et la structure de l'entreprise.
Telerik a été fondée en 2002 à Sofia , Bulgarie. Telerik s'est bâti une réputation en créant des outils logiciels destinés aux développeurs pour le développement d'applications Web, mobiles et de bureau. Progress, une société de logiciels américaine fondée en 1981, a acquis Telerik en 2014.
Parce que «Telerik» était déjà synonyme de «produits de développement de qualité», Telerik.com est devenu l'hôte de tous nos DevTools, y compris les produits Telerik .NET et les produits JavaScript de l'interface utilisateur Kendo.
Les personnes que vous entendrez dans cette série travaillent toutes sur ce côté DevTools / Telerik / Kendo UI de Progress, impliquées dans la création de produits destinés à d'autres développeurs.
Écoutons ce qu'ils ont à dire!
Comprenez d'abord le problème
Un thème très important que j'ai entendu était de vous assurer que vous en appreniez pleinement sur le problème avant de vous plonger dans une solution.
Savoir Votre public: le nôtre est celui des autres développeurs
La première étape pour comprendre un problème consiste à comprendre qui est confronté au problème que vous essayez de résoudre. Dans notre cas, ce sont d’autres développeurs. Comme vous le verrez, écouter ces clients représente pour nous une part importante du cycle de travail.
Genady Sergeev — Directeur, Génie logiciel; Développement de produits d'outillage pour développeurs
![Genady-Sergeev "title =" Genady-Sergeev "style =" float: left; marge inférieure: 10px; margin-right: 20px; "data-method =" ResizeFitToAreaArguments "data-customsizemethodproperties =" {"MaxWidth": "200", "MaxHeight": "200", "ScaleUp": false, "Quality": "High"} "/> Nous ne sommes pas dans une position où nos clients sont de vrais développeurs de logiciels, donc le produit que nous créons doit les intéresser. Qu'est-ce que cela signifie? Cela signifie que nous devons être très doués pour comprendre la manière dont ces développeurs travaillent , quelles plates-formes sont codées, les environnements et les pratiques qui y sont pertinents, et comment ces choses changent avec le temps. </p>
<p> Nous devons nous adapter et créer nos composants et logiciels en suivant les mêmes pratiques, processus et outils que les développeurs auxquels nous essayons de vendre. Sinon, le résultat final ne les intéressera probablement pas. Lorsque vous y pensez, lorsque nous créons des démos et ou même la façon dont nous produisons du code, nous devrions utiliser les mêmes outils que ces développeurs. sinon nous arrivons avec quelque chose de différent de ce qu'ils recherchent. [19659003] <strong> Maria Veledinova – Chef de produit; Outils de développement PM & PMK </strong> </p>
<p> <img decoding=](https://i0.wp.com/d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2021/2021-03/genady-sergeev.png?w=660&ssl=1)
Avec votre connaissance de votre public et de sa douleur, commencez à définir vos objectifs pour le projet.
] Vesko Kolev — Vice-président, Produit; BU Outillage développeur
Et enfin, passez même ] plus de temps pour réfléchir à votre approche. Ayez une image claire de qui utilisera votre solution, du résultat que vous visez et de la voie que vous allez emprunter avant d'écrire un peu de code.
Todor Mitev – Ingénieur logiciel, Principal; Unite UX
Faites toujours vos devoirs. Il y a cette phrase célèbre, quelque chose comme: «Deux heures de planification peuvent économiser deux semaines de codage.»
Donc en effet, la recherche, l'exploration, le désir de voir la situation dans son ensemble et de voir le vrai problème et comment le résoudre est très, très, très important. Et lorsque vous atteignez votre objectif, cela vous procure un tel plaisir et une telle satisfaction que je ne peux pas l'exprimer. C'est l'une des choses que j'aime le plus dans mon travail.
Genady Sergeev — Directeur, Génie logiciel; Développeur Tooling Product Development
L'une des choses que j'essaie de dire est que nous devrions davantage réfléchir aux problèmes que d'essayer de les résoudre mécaniquement. Parfois, cinq minutes de réflexion ciblée peuvent économiser trois jours de travail mis dans la mauvaise direction. Dans notre travail, la productivité n'est pas linéaire.
Vesko Kolev — VP, Product; Developer Tooling BU
Disons que nous commençons un nouveau projet. Le codage ne devrait pas être la première chose que nous faisons. Par exemple, en ce moment, nous travaillons sur un produit qui webelieve est potentiellement une innovation disruptive. Nous y travaillons depuis quatre ou cinq mois et nous n’avons écrit que quelques lignes de code. Nous faisons des prototypes. Nous faisons des interviews.
La seule chose que je crois très importante et que j'instille chaque jour dans l'équipe est la suivante: nous ne devrions pas travailler en silos. Je pense que les équipes produit (ingénieurs, développeurs, support, chefs de produit, spécialistes du marketing, etc.) devraient, en particulier lorsqu'elles construisent de nouvelles choses, travailler en tant que startup, où tout le monde connaît le contexte et est suffisamment confiant pour comprendre le contexte complet. À ce stade, ils comprendront pourquoi il est important d'arrêter le désir interne de commencer à coder Day Zero.
Vous devez comprendre: quel est le problème, puis le résultat que vous voulez atteindre. Quel est le processus? Et réfléchissez ensuite à la manière dont vous pouvez l'automatiser. Plutôt que l'inverse.
L'autre chose qui pourrait être mentionnée ici est la façon dont nous raisonnons, et nous sommes de grands adeptes de la pensée fondée sur les principes, c'est-à-dire que le processus implique un raisonnement basé sur des principes que vous détenez des vérités.
Les grandes innovations surviennent lorsque les gens ne comprennent pas la différence entre difficile et impossible. Si vous considérez très vite que quelque chose est impossible, combien de choses contre-intuitives n'auraient jamais été découvertes? La réflexion sur les principes d'abord est l'autre chose. Nous essayons de raisonner et de prouver avec des expériences tout ce que nous pensons être factuel. Cela nous aide à être plus ouverts d'esprit et, espérons-le, à trouver des choses qui ne sont pas si évidentes mais qui sont potentiellement très précieuses. essayer de résoudre avant de le résoudre. Assurez-vous de savoir qui utilisera votre produit et parlez-en avec eux. Pensez au problème, élaborez une stratégie pour le contourner avant de coder une solution.
La prochaine fois, nous parlerons encore plus de l'écoute de vos utilisateurs.
Source link