Quelle est la différence entre développement et R&D?
Un collègue m'a demandé d'expliquer clairement la différence entre le développement ordinaire et la recherche et développement (R&D) et je n'ai pas pu le faire. Après avoir lu Wikipédia, je n'ai toujours pas la réponse précise.
Selon Wikipedia (légèrement modifié):
Il existe deux modèles principaux:
Dans un modèle, la fonction principale est de développer de nouveaux produits ;
dans l'autre modèle, la fonction principale est de découvrir et de nouvelles connaissances sur des sujets scientifiques et technologiques dans le but de découvrir et de permettre le développement de nouveaux produits précieux , processus et services.
Le premier modèle prête à confusion. Est-ce à dire que le développement (et non la R&D) consiste exclusivement à ajouter de nouvelles fonctionnalités à un produit, à résoudre des bugs et à faire de la maintenance? Que se passe-t-il si quelque chose qui a été précédemment développé en tant que nouvelle fonctionnalité devient un produit distinct?
Le deuxième modèle est moins déroutant, mais quand même, comment qualifier si quelque chose est une nouvelle connaissance ou une connaissance existante qui vient d'être redécouverte?
Plus tard, Wikipedia ajoute que le développement ordinaire est différent de la R&D en raison de:
profit presque immédiat ou amélioration immédiate.
Ce n'est pas encore assez clair. Comment qualifier "profit quasi immédiat"? Que se passe-t-il si une tâche a un profit immédiat mais nécessite des recherches approfondies? Ou s'il est basique mais a un profit incertain, comme l'application d'un style commun sur la base de code?
Par exemple, appartient-il au développement ou à la R&D pour:
Développer un moteur qui résume l'accès à la base de données, simplifiant et raccourcissant énormément le code des autres applications (existantes ou qui seront écrites à l'avenir) qui devraient accéder à la base de données?
Établir une nouvelle architecture orientée services pour l'ensemble de l'organisation des ressources de l'entreprise, afin de passer d'un ensemble d'applications distinctes et autonomes à un ensemble de services Web bien organisés et interconnectés, comme ce qui est utilisé par Amazon?
Concevoir un nouveau protocole de communication pour permettre une réplication plus rapide des données entre deux centres de données de l'entreprise?
Concevoir un nouveau type de test logiciel tout en travaillant sur un produit spécifique, sachant que ce type de test améliorera/simplifiera le processus de test?
Prouver que la programmation fonctionnelle est plus appropriée que OOP pour une application spécifique, basée sur des preuves, la logique et l'expérience précédente?
Améliorer l'application existante en ajoutant des gestes sur des écrans tactiles, après avoir fait des études et des tests qui montrent que ces gestes améliorent la productivité des utilisateurs dans un rapport d'au moins 1,4 pour un ensemble précis de tâches?
Vous cherchez un moyen d'améliorer considérablement l'efficacité de l'utilisation de l'énergie (PUE) d'un centre de données?
Créer un langage spécifique au domaine (DSL)?
En bref, comment pourrais-je déterminer si je fais de la R&D tout en travaillant sur quelque chose?
Grande question.
Il est important de faire la distinction entre "développement" et "R&D".
- Point 1
R&D = expérimenter des idées/technologies qui pourraient ne jamais devenir réellement un produit.
Développement de logiciels = travailler sur un produit/service souhaité par un vrai client.
- Point 2
La R&D consiste à développer de nouvelles solutions pour un domaine de problème spécifique. Le résultat final de cet effort est quelque chose que j'appelle des "jouets de recherche".
Pour être un produit logiciel, le jouet de recherche doit être complètement réimplémenté. Ne pas le faire se traduira par un produit qui plaira à une base d'utilisateurs de plus en plus élite et érudite. Le problème ici est que cette base d'utilisateurs élite et érudite n'a généralement pas d'argent à dépenser.
Pour être un succès, le produit logiciel doit être une ré-implémentation fidèle du jouet de recherche, accessible et aimé par l'utilisateur du produit. Pour être vraiment remarquable, le produit logiciel doit simultanément faire appel à l'utilisateur Elite et érudit.
- Point 3
La recherche implique une recherche savante ou scientifique et tend à viser le plus grand bien d'une industrie ou d'une société dans son ensemble. Le développement de produits a des motivations et des résultats différents: il est déterminé par le potentiel de profit. L'état de développement des produits est sain. L'état de la recherche sur l'éclairage ne l'est pas.
Nous avons besoin d'un engagement collectif pour le plus grand bien afin de répondre à ces questions. Mais ce n'est pas seulement de la philanthropie; la réponse viserait un objectif pratique. Les sources lumineuses qui sont spectralement accordées au système visuel seront plus durables. Ils utiliseront moins d'énergie en générant leur sortie dans les régions du spectre où le système visuel répond le plus fortement, résultant en une meilleure visibilité pour les utilisateurs du bâtiment. Cet exemple renforce la différence entre la recherche et le développement de produits.
- Point 4
Tout développement de nouveaux produits en R&D. Je pense que certains d'entre vous confondent science pure et abstraite avec R&D. Ce ne sont pas les mêmes. La R&D peut être très orientée produit. Les scientifiques sont peut-être à la recherche d'un vaccin pour guérir le SIDA. C'est une tâche très spécifique de créer un produit à vendre et c'est certainement de la R&D et pas seulement des gars assis à jouer avec tout ce qu'ils ressentent.
- Point 5
R&D dans le monde technique = trouver des moyens de faire quelque chose d'intéressant ou d'important, en utilisant des techniques et des technologies connues comme point de départ.
Développement de logiciels = trouver des moyens de faire quelque chose d'intéressant ou d'important, en utilisant des techniques et des technologies connues comme point de départ.
- Point 6
La quasi-totalité du développement logiciel est la partie D de la R&D. Parfois, il y a très peu de R dans la "R&D" logicielle. Parfois, il y a un R assez important dans la "R&D" du logiciel.
Cela dépend de plusieurs mesures. Par exemple,
Gérant le développement de logiciels pour des entreprises de tailles diverses, la R&D prend différentes significations selon la taille de l'entreprise, la clientèle, etc.
Dans une petite entreprise de logiciels, avec seulement une main pleine d'employés, la frontière entre les logiciels de R&D et les logiciels de production est généralement très petite. Ce qui un jour est un projet de R&D logiciel, peut être expédié le lendemain en tant que logiciel de production aux clients.
À mesure que les éditeurs de logiciels se développent et qu'ils possèdent une ou plusieurs lignes de logiciels de production, ils tendent à créer une plus grande séparation entre les projets de logiciels de R&D et les produits de logiciels de production (pour des raisons évidentes). Cet écart de R&D est généralement créé pour créer une plus grande diversification de leurs produits logiciels pour demain, tout en permettant au développement de logiciels de production de continuer à produire aujourd'hui.
Cela ne veut pas dire que les logiciels de production n'obtiendront pas de nouvelles fonctionnalités innovantes. Les développeurs de logiciels de production sont généralement aussi "pointus" que les développeurs R&D. En fait, dans une entreprise, nous avions un programme d'enrichissement qui permettait aux développeurs de logiciels de production de tourner dans et hors des projets de R&D. Cela a non seulement ajouté une nouvelle puissance de cerveau aux équipes de R&D, mais dans de nombreux cas, les développeurs de production sont revenus avec de nouvelles idées sur la production de meilleurs logiciels de production.
- Point 7
D = "savoir où vous voulez être à la fin", et R parce que "au début du projet, vous ne savez pas ce qui sera nécessaire pour y arriver"
- Point 8
La recherche et le développement sont les chanceux qui peuvent faire tout ce qu'ils veulent sans responsabilité.
Bonne recherche/ressource sur ce sujet:
La différence réside dans les attentes.
Lorsque je travaillais en R&D, je devais principalement fournir les résultats de la recherche .
Lorsque je travaillais dans le développement, je devais principalement fournir un logiciel fonctionnel .
Ceux-ci ne sont pas totalement séparés et il peut y avoir des zones grises assez importantes entre les deux. En cours de développement, il arrivait parfois que l'on m'attende à effectuer des recherches . De même, dans l'un des projets de recherche, j'ai été chargé de développer un programme particulier.
Comme d'autres l'ont dit, la R & D implique la recherche. Pour moi, la recherche travaille sur quelque chose que personne ne sait faire à l'heure actuelle. Si cela a été fait, ce n'est pas de la recherche, même si cela peut nécessiter des investissements importants en temps pour étudier les solutions existantes et la littérature.
À propos de votre liste:
- Développer un moteur qui résume l'accès à la base de données, simplifiant et raccourcissant énormément le code des autres applications (existantes ou qui seront écrites à l'avenir) qui devraient accéder à la base de données?
De nombreux ORM existent. À moins que le vôtre ne fasse quelque chose de vraiment différent, je ne le considérerais pas comme de la R & D.
- Établir une nouvelle architecture orientée services pour l'ensemble de l'organisation des ressources de l'entreprise, afin de passer d'un ensemble d'applications distinctes et autonomes à un ensemble de services Web bien organisés et interconnectés, comme ce qui est utilisé par Amazon?
Nan.
- Concevoir un nouveau protocole de communication pour permettre une réplication plus rapide des données entre deux centres de données de l'entreprise?
Si cela améliore les protocoles connus, je considérerais cette R & D.
Concevoir un nouveau type de test logiciel tout en travaillant sur un produit spécifique, sachant que ce type de test améliorera/simplifiera le processus de test?
Prouver que la programmation fonctionnelle est plus appropriée que OOP pour une application spécifique, basée sur des preuves, la logique et l'expérience précédente?
Améliorer l'application existante en ajoutant des gestes sur des écrans tactiles, après avoir fait des études et des tests qui montrent que ces gestes améliorent la productivité des utilisateurs dans un rapport d'au moins 1,4 pour un ensemble précis de tâches?
Vous cherchez un moyen d'améliorer considérablement l'efficacité de l'utilisation de l'énergie (PUE) d'un centre de données?
Créer un langage spécifique au domaine (DSL)?
Aucune de ces choses ne semble inclure la recherche. Pour donner d'autres exemples de choses que je considérerais comme R & D:
Améliorer l'inférence de type dans Scala, permettant une meilleure unification
Inventez un nouveau type d'optimisation du compilateur
Créer une nouvelle base de données qui présente des différences significatives avec les existantes - disons comme CouchDB l'était quand il a été conçu
Développer une bibliothèque fonctionnelle et utilisable pour une programmation réactive fonctionnelle
Trouvez un nouvel exploit dans les logiciels ou protocoles existants
Inventez un nouvel algorithme de compression
Informellement, la façon dont je le définirais (et comment je l'ai généralement vu utilisé dans la pratique) est quelque chose comme:
L'expression R&D est utilisée pour signifier que vous n'êtes pas sûr de l'approche exacte pour réaliser quelque chose, et/ou si cela peut même être fait, et de la façon dont cela fonctionnera.
(EDIT: reformulé légèrement)
Fondamentalement, c'est une façon rapide et courante de dire qu'il y a une grande inconnue à venir. Tenter de répondre à votre vraie question alors, cela dépend vraiment de qui fait la classification; bon nombre de ces éléments semblent comporter un important volet de recherche, mais je suppose que certaines personnes pourraient en réaliser bon nombre sans aucune recherche. Cela dépend à la fois de la tâche et de l'individu.
En regardant la liste réelle, je classerais personnellement ceux-ci en fonction de si j'ai fait quelque chose d'assez similaire dans le passé, et serais donc très confiant dans ce que je suis sur le point de faire (ou du moins, être en mesure de donner une bonne base de données estimations).
40 000 $ par an bosse de salaire?
En R&D, le R utilise parfois la recherche pour décrire une chose qui est également décrite comme un développement technologique où nous découvrons comment faire quelque chose que nous ne savions pas faire. Peut-être bien décrit comme de la recherche appliquée, nous pourrions concevoir quelque chose sur mesure, puis essayer généralement de le breveter ou de le protéger ou de l'exploiter de manière concurrentielle.
Le R pourrait également faire référence au risque, car les projets de recherche et développement tentent souvent de combiner à la fois la découverte et l'exploitation de nouvelles technologies et l'exploitation de technologies connues. Parmi les autres risques de cette approche, il y a la division de votre concentration, la construction de prototypes qui NE SONT PAS destinés à être jetés, et la probabilité que le marketing soit impliqué et traite les estimations comme des contrats.
La R&D est un terme qui peut habiller un département principalement impliqué dans le développement. La plupart des projets technologiques devraient combiner la recherche avec une sorte de prototype, mais fabriquer une ou une douzaine de quelque chose ne me semble pas être un développement à moins qu'il ne puisse être transféré à la fabrication.
La recherche comprend généralement une notion de rigueur comme l'examen de la littérature ou des brevets à la recherche d'antériorités, l'affirmation de nouvelles innovations et la démonstration de leur valeur et de leur caractère unique d'une manière ou d'une autre. La recherche universitaire synthétise parfois des idées issues de la littérature universitaire, modélise mathématiquement certains phénomènes ou rapporte une étude de cas avec analyse, conclusions et proposition d'étude future.
Peut-être que la R&D s'intéresse à des choses qui n'ont pas été faites auparavant mais qui seront à court terme disponibles en tant que produit.