Change: Embrace It, Don't Deny It: Tools and Techniques Inspired by Software Development Can Introduce the Flexibility Needed to Make Changes during Product Development with Minimal Disruption
Pourquoi ce travail est dans la base
Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.
Notice bibliographique
Résumé
Change from plans during a new-product development project is a topic that increasingly places developers and their managers in a dilemma. On the one hand, change is becoming increasingly commonplace. Customers, who are presented with more and more options today and can turn to the Internet for competitive product information, change their minds more frequently and are more insistent on being satisfied. Such changes by customers put pressure on development programs to make changes accordingly. In addition, markets shift more often and abruptly as the competitive arena becomes more turbulent and complex. For example, as globalization flattens the Earth, competitors appear from unexpected places, and they often bring with them new, disruptive business models. For example, Huawei appeared from nowhere in China to become a major threat to telecommunications equipment giants such as Cisco and Alcatel-Lucent, and Haier likewise has given Whirlpool a rough ride (1). Another market shift is the one in consumer goods regarding the relative power between manufacturers (Procter & Gamble and Rubbermaid, for example) and retailers (such as Walmart and Home Depot) (2). Such market shifts raise the likelihood of changes midstream in a development project. Finally, technology--both the technology that goes into the product and the technology (like computer-aided design tools) used to develop it--is changing at an accelerating pace. New technologies appear and existing ones become obsolete or simply passe. Sometimes a new technology provides unexpected benefits that one would like to exploit during a project, such as the enthusiastic reception of portable music players by runners and others exercising physically, which, in turn, demands unexpected changes during product development to incorporate resistance to rain, perspiration and vibration. Alternatively, sometimes the benefits touted by the purveyors of the new technology don't pan out. This opens more opportunities for change in the midst of development. On the other hand, many managers, at all levels, do not welcome change during a project. For them, mid-project changes open the door to product cost and development budget overruns, schedule slippage and product defects. Hard-pressed to deliver profit on a quarterly basis, managers, especially at higher levels, rightly see change as disruptive. Consequently, management has built development systems aimed at predictability and certain success, such as: phased development (including StageGate[R]), Six Sigma and Project Office. Although such systems clearly have benefits, their gains in predictability come with a corresponding side effect of rigidity. In summary, although change during development is increasingly common, I instead see managements adopting systems that are increasingly resistant to change. This article shows how to introduce the flexibility needed to make changes during product development with minimal disruption, which I believe will separate the future winners from the losers. Consider this example of turbulence encountered by Quadrus, a Calgary-based software development company, in developing an application for a Canadian online drugstore. This is a volatile market driven by ongoing supplier, political, regulatory, and legal thrusts. Extreme change was the essence of the management challenge Quadrus faced. In addition, its client was coming from behind in a bid to become a market leader. Quadrus responded by using very short (two-day) development iterations--each producing working software--and weekly online deployments, which not only kept up with the changing environment but aggressively led the change. By having a positive attitude toward change and employing systems that could reorient quickly, Quadrus' client could respond to competitive challenges and regulatory demands faster than competitors, thus leading the change to gain competitive advantage (3, p. 249). …
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,002 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,001 | 0,002 |
| Études des sciences et des technologies | 0,001 | 0,000 |
| Communication savante | 0,000 | 0,000 |
| Science ouverte | 0,002 | 0,003 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle