Basé sur ma propre expérience et sur l'expérience de mes amis, je vois que de nombreuses entreprises ont des idées étranges pour développer leurs propres cadres et usines de SO (construit des squelettes de la demande pour vous). Ces idées sont généralement basées sur la croyance que le cadre propre sera beaucoup mieux que tout autre disponible. Comment gérer de telles idées et comment expliquer que ce n'est pas toujours un bon moyen d'y aller?
Pourquoi je pense que les cadres internes / usines ne sont pas bons:
Pourquoi je pense que les entreprises font cela:
Je comprends que la solution ou un cadre parfois propre pour un scénario spécialisé est nécessaire, mais je suis fatigué de tous ces "grands cadres internes" pour la création d'applications Web ou de bureau. Ai-je tort? Ces cadres sont-ils vraiment nécessaires (.NET et Java World)? Pouvez-vous me fournir un exemple ou une raison pour laquelle il est bon d'avoir un cadre / usine interne?
Merci pour des réponses mais je m'attendais à ce que certains conseils comment traiter un problème en tant que développeur (à l'exception de la modification d'un emploi) et non comme un gestionnaire.
3 Réponses :
La généralisation est mauvaise, mais voici ce que j'ai remarqué, en particulier dans les grands projets d'entreprise:
Un tel comportement est généralement entraîné par l'un de ces plus d'ingénieurs en logiciels (ils nomment généralement Themselve Architecte logiciel ) qui tombent dans les descriptions que vous avez écrites dans votre question. Tout le monde doit être fier de quelque chose d'avoir le courage de se réveiller le matin. J'ajouterai qu'ils sont généralement condamnés à cette raison et tentent d'appliquer les derniers modèles de conception sans réfléchir aux implications et au retour sur investissement de l'entreprise. La clé est de ne pas embaucher ce genre de personne (ou d'essayer de l'entraîner pour comprendre les conséquences d'affaires de ses choix). Essayant de les rendre fiers de travailler pour la société au lieu de travailler sur leur cadre peut également aider.
Les délais manqués, les bugs, le taux de vitesses élevées ont tendance à être résolus en appliquant des méthodologies de fantaisie (généralement mal implémentées) comme Scrum ou embauché des consultants très tarifés qui feront pire des choses, ... au lieu de suppression (ou de coaching ) Les personnes qui n'auraient pas dû être embauchées à la première place.
Suppression de la personne en question est dans la plupart des cas une mauvaise chose depuis sa propre chose. Alors lui apprendre à comprendre les conséquences de ses choix est probablement le moyen le plus approprié de résoudre le problème. Mais pour faire cela, vous avez besoin d'un Donc, mon seul conseil serait:
embaucher de meilleurs gestionnaires qui comprennent très bien le développement des entreprises et des logiciels. Ils n'engageront pas ce genre de personne ou essaieront de leur apprendre à envisager des affaires en plus de développement de logiciels purs. Ils comprend également que le carburant de motivation le plus puissant pour les employés les rend
Developer a plus de contrôle que vous pensez. Par exemple, un développeur peut décider de ne pas accepter un emploi et son responsable associé.
Bien sûr c'est un choix. Mais je pense que ce devrait être le dernier. Vous pouvez toujours changer le travail - et rencontrer un nouveau cadre.
Dans mon expérience, la cause la plus courante des cadres excédentaires est ... Développeurs ennuyés ! Les développeurs non ligneux constatent que le développement de cadres pour résoudre leurs problèmes est beaucoup plus amusant que de résoudre ces problèmes - le résultat final est des cadres qui souffrent de tout ce qui précède (car bien sûr, le développeur n'a fait que les bits amusants), et éventuellement pas Même résoudre le problème réel (parce que l'objectif était de s'amuser, de ne pas résoudre le problème).
La solution est difficile - il est difficile de savoir ce que c'est que motivent les développeurs comme tout le monde motivé par différentes choses, mais des développeurs motivés qui sont occupés à faire des choses qu'ils aiment ne pas voir à souffrir de cette maladie!
Cela dit, bien pensé des cadres lorsqu'ils sont correctement utilisés sont définitivement une bonne chose - Toutefois, si sa seule sera utilisée en interne, il pourrait être préférable de penser à la fois comme une extension de factorisation et réutilisation du code plutôt que comme cadre.
Un signe classique que quelqu'un souffre d'un syndrome de structure de développeur ennuyé est quand un cadre est en cours de développement pour résoudre le cas général quand il n'y a pas encore de solution pour le cas spécifique < / em>:
Le deuxième cas de cours conduit au pire type de cadre - le cadre générique mammouth qui n'est jamais utilisé une fois, pour résoudre un problème qui est beaucoup plus simple que le cadre lui-même.
considère plutôt que ces types de cadres plus en tant qu'exercice de "refactorisation étendue" - si le cadre est produit comme moyen de regrouper et de ranger le code commun sur une base selon les besoins, le cadre augmentera de manière dynamique et complexité - Ayant déjà résolu le problème avant de commencer à produire des cadres, c'est bien aussi car cela signifie que vous êtes déjà des experts dans tout ce que le cadre doit faire.
Enfin, essayez de garder les développeurs d'être ennuyés (ils obtiennent toutes sortes de malicatifs autrement!)
MDR! Étape 1 pour garder les développeurs d'être ennuyés: des licornes et des arcs-en-ciel.
J'ajouterais d'autres raisons que ces choses évoluent et je l'ai vue dans plus d'un endroit: - Lock-in développeur. Une fois que vous avez les Devs codant dans une compétence non transférable, il leur est plus difficile de partir. - Lock-in auteur. Une fois que vous avez plusieurs applications en maintenance en fonction du cadre, vous avez l'organisation dépendant du groupe administratif. - Contrôle politique. La centralisation permet au cadre de devenir un canal de contrôle politique.
Il rend également plus difficile d'apporter de nouvelles personnes et du type d'organisation qui tentera de verrouiller les développeurs comme cela susceptibles d'avoir un chiffre d'affaires assez élevé de toute façon.