Quelle est l'importance de la connaissance du domaine par rapport à la connaissance technique?
Je travaille sur une application de trading et de gestion des risques et bien que venant d'un arrière-plan C #, on m'a demandé de travailler sur des packages SSIS. Maintenant je peux vivre avec ça. Le problème, c'est qu'il y a trop d'accent sur la compréhension des affaires. Le trading (le trading d'énergie pour être exact) est un ÉNORME domaine et comprendre chaque petit peu est accablant. Mais depuis deux mois, je travaille sur la compréhension des termes commerciaux - Mark To Market, Risk Metrics, Positions, PnL, Grecs, Instruments, Book Structure ... chaque petit détail (vous obtenez le point). Maintenant à mon humble avis, c'est le travail d'un BA. Bien sûr, il est très important pour les développeurs de comprendre l'entreprise, mais où tracez-vous la ligne?
Quand j'en ai parlé à mon manager, il s'est presque moqué de moi en disant que n'importe qui peut apprendre une technologie en une semaine. C'est l'entreprise qui est la plus difficile. Mon aspiration à long terme est de rester sur le plan technique, sans doute devenir architecte (si possible). Si je voulais tellement me concentrer sur les affaires, j'aurais poursuivi un MBA!
Je veux savoir si je me trompe ou si je suis trop naïf pour comprendre l'importance de l'entreprise ou ma frustration est-elle justifiée?
Le travail d'un programmeur consiste à traduire les exigences du langage naturel en implémentations de langage machine. Vous ne pouvez pas le faire efficacement si vous ne parlez couramment que d'un côté ou de l'autre. À moins que vous n'écriviez des compilateurs ou un logiciel de contrôle de version, à peu près tous les travaux de programmation nécessiteront une quantité importante de connaissances hors programmation.
Benjol et votre manager ont raison, mais laissez-moi développer:
apprendre le domaine de l'entreprise est la façon dont vous ajoutez de la valeur au processus et augmentez votre valeur pour l'entreprise
c'est la différence entre un singe de code programmeur et développeur
Il y a un dicton qui vient du département d'informatique de mon université:
Si vous souhaitez créer un logiciel pour les géologues, vous devez d'abord comprendre la géologie. Si vous souhaitez créer un logiciel pour les physiciens, vous devez d'abord vous familiariser avec la physique. Si vous voulez comprendre les affaires, vous devez d'abord apprendre à parler affaires.
J'entends des gens ici tout le temps dire que le développement de logiciels est un domaine créatif. Je pense que cela est vrai dans une certaine mesure. Cela implique de la créativité dans la mesure où il faut être capable de voir hors des sentiers battus pour résoudre une série de problèmes.
Ce que cela ne signifie pas, c'est que vous pouvez simplement vous asseoir et construire de manière si créative tout ce que vous voulez. Ce n'est pas une classe d'art, c'est de l'ingénierie, et vos clients et parties prenantes vont s'attendre à ce que vous créiez quelque chose qui résout leurs problèmes, pas quelque chose qui soit juste cool".
Afin de résoudre un problème, vous devez d'abord comprendre le problème. Vous devez entrer dans la tête de vos utilisateurs et comprendre comment ils pensent.
Que vous développiez des logiciels pour la finance, le marketing, les ventes, la géologie, la physique ou tout autre domaine pris en charge par le logiciel, vous devez faire partie de ce domaine.
C'est pour cette raison même que, en plus de mon diplôme en informatique, j'ai également obtenu un diplôme en commerce; cela a eu un impact énorme sur ma capacité à communiquer des solutions potentielles et à livrer des produits performants.
Si vous souhaitez en savoir plus sur ce que je rechercherais lors de l'embauche d'un ingénieur en logiciels d'entreprise, consultez ce Exemple d'annonce d'emploi d'un ingénieur d'affaires que j'ai écrit en réponse à une autre question.
Vous pouvez survivre sans beaucoup de connaissances du domaine ou de contact client en tant que codeur de bas niveau, mais un architecte logiciel est quelqu'un qui connaît très bien le domaine et communique activement avec toutes les parties prenantes.
À mon avis, vous avez tort et vous êtes trop naïf.
Comme votre manager l'a dit (légèrement désinvolte), n'importe qui peut apprendre une technologie en une semaine. La seule chose qui vous démarquera et vous rendra utile à votre entreprise est votre connaissance des affaires. Et plus c'est dur, plus vous en valez la peine.
De toute évidence, si vous trouvez que cette entreprise particulière est stupéfiante, vous pouvez chercher quelque chose de différent. Mais si votre idée du paradis consiste à pirater ensemble de petits sites Web php, méfiez-vous: il y aura des milliers de script kiddies qui le feront aussi.
Sérieusement, "je suis juste un codeur, ne me confondez pas avec les faits" ne suffira pas.
Je travaille également dans le négoce d'énergie. La connaissance des affaires représente 90% de l'emploi. Vous ne pouvez pas contourner cela - c'est une entreprise compliquée.
Si vous ne comprenez pas au moins les bases du trading et les marchés sur lesquels vous travaillez, vous allez avoir du mal, peu importe la qualité d'un codeur.
Je travaille avec certains BA qui ne peuvent tout simplement pas obtenir les bonnes conditions. Je dois compter sur mes propres compétences analytiques et ma compréhension des connaissances en affaires pour faire le travail.
Je pense que si vous travaillez pour un magasin qui vend des logiciels Energy Trading, votre expérience peut différer - mais dans le commerce de l'énergie informatique d'entreprise, l'accent est mis sur la compréhension du marché et la façon dont les logiciels peuvent d'abord apporter des solutions aux problèmes de l'entreprise.
Les technologies réellement utilisées et leur mise en œuvre arrivent loin derrière.
Le gars ci-dessus qui a fait le commentaire Excel ne sait pas à quel point son commentaire est approprié. Les traders créent souvent leurs propres petites applications de trading dans Excel/VBA (c'est tout ce qu'ils savent), puis le service informatique finit par hériter de ces mess de programmes.
J'adorerais reconstruire certaines de ces applications dans un langage "correct", mais ce n'est tout simplement pas toujours une priorité.
Si vous développez pour une entreprise, vous finirez par avoir une idée plus claire et plus détaillée des règles commerciales que quiconque dans l'entreprise. Ce n'est pas nécessairement parce que vous êtes plus intelligent que tout le monde, cela vient parce que c'est la seule façon de faire le travail.
Votre réaction pourrait être "Mais que font les analystes commerciaux?"
Les analystes commerciaux participent à de longues réunions avec les clients qui tentent d'en tirer des exigences suffisamment claires pour qu'un développeur puisse travailler. Je regarde la façon dont ils doivent traiter avec les clients et je suis reconnaissant de ne pas avoir à le faire.
J'aime faire des analogies entre le développement logiciel et l'architecture. Les deux sont des arts appliqués. Les deux nécessitent une modélisation élaborée dans l'esprit. L'aspect qui s'applique à cette question est que l'écriture de logiciels sans connaissances commerciales est comme concevoir un bâtiment sans comprendre le mode de vie et les besoins des habitants. Je pense que beaucoup d'entre nous ont vu (ou même vécu/travaillé dans) des bâtiments qui peuvent sembler beaux et modernes et ainsi de suite de l'extérieur, ne sont tout simplement pas tilisables de l'intérieur. (Dans le pire des cas, ils ne sont même pas gentils: (()
Mise à jour
Commentaire de Gaurav:
ce qui m'intéresse, c'est dans quelle mesure un développeur doit-il faire des efforts pour comprendre le domaine de l'entreprise. Faut-il aller jusqu'au bout, ou il y a une ligne à tracer.
Je ne pense pas que vous puissiez tracer une ligne n'importe où en général. À moins qu'il y ait des parties de l'application/du domaine que vous n'avez pas besoin de toucher (donc de comprendre) jamais. Ce qui est IMHO très rare dans la vraie vie, sur le long terme. Toute partie d'une application en cours d'utilisation recevra des rapports de bogues et des demandes de fonctionnalités. Les domaines changent également, car la législation, les règles fiscales, les politiques, les habitudes correspondantes - en bref, le monde réel - changent. Cela doit également être suivi dans le logiciel.
Mais même sans demandes externes de modifications, les tests unitaires et la refactorisation du code hérité nécessitent également la compréhension des domaines concernés. Sinon, il vous suffit de "geler" le comportement actuel de l'application, sans savoir s'il est réellement correct ou non.
Update2
que se passe-t-il si le développeur [...] change fréquemment le domaine d'activité sur lequel il travaille?
Cela signifie bien sûr qu'une grande partie de l'investissement (de votre temps et de l'argent de votre employeur) pour acquérir vos connaissances commerciales est perdue :-( Si vous savez que cela va se produire, bien sûr, cela ne vaut peut-être pas la peine de creuser trop profondément dans un domaine spécifique. Notez cependant que les domaines ne sont pas --- (totalement différents, il existe des principes fondamentaux qui peuvent être réutilisés entre différents domaines. Et surtout, la conception pilotée par domaine approche vous gagnez est réutilisable.
Je travaille dans le secteur bancaire depuis plus de dix ans à développer des applications de trading et je reconnais qu'il est important pour les développeurs de bien comprendre l'entreprise. Mais maintes et maintes fois, pendant les processus d'entrevue, si la personne n'a pas une bonne connaissance de l'entreprise, elle ne passe pas la porte.
Cela a conduit à un nombre important d'applications et de systèmes critiques développés par ces personnes possédant une solide connaissance des affaires mais des compétences techniques faibles à moyennes. Ces systèmes finissent toujours par être mal conçus qui plantent constamment, criblés de bugs, ne se mettent pas à l'échelle, presque impossibles à corriger sans casser quelque chose, et c'est si le projet ne finit pas par être annulé en raison de compétences techniques insuffisantes pour l'obtenir. en production.