|
"A Systems Development Manager parle avec une langue fourchue." - Loi de Bryce INTRODUCTION Afin d'être Systems Development Manager, vous devez être un tas de choses: l'homme avant, éducatrice, de mentor, de la sauge, homme politique, etc Ah oui, autre chose, vous devez aussi être un hypocrite. Afin que vous pour survivre dans le monde de l'entreprise d'aujourd'hui, vous avez à dire une chose à vos supérieurs et du personnel, mais alors faire quelque chose de tout à fait différente dans la pratique. Permettez-moi de vous donner quelques exemples: * D'une part, les gestionnaires savent qu'il est important de faire le travail au stade initial de conception de systèmes, par exemple, analyse les systèmes actuels, les besoins en informations de définition, d'établir l'architecture des systèmes appropriés, etc, mais d'un autre côté, ils encouragent leur personnel à Rush au codage sans penser d'abord le problème à travers. C'est parce que la programmation est une tâche beaucoup plus tangible que l'analyse des systèmes, fournissant ainsi la preuve démonstrative à l'utilisateur final que le projet progresse. Les gestionnaires de rationaliser ce en prétendant qu'ils travaillent dans une cocotte-minute et, comme tel, «Nous n'avons pas le temps de bien le faire." * D'une part, les gestionnaires affirment qu'ils veulent la normalisation dans leur effort de travail (pour permettre à tous de communiquer et de travailler sur un niveau commun), mais d'autre part, les normes sont jetées par la fenêtre le bouton moment Comes To Shove. * D'une part, les gestionnaires voulons que les travailleurs interchangeables qui peuvent facilement reprendre là où un autre travailleur qui quitte son congé, mais d'autre part, ils ne sont pas disposés à former les travailleurs à un niveau uniforme et cohérente des compétences. * D'une part, les gestionnaires à comprendre les vertus du partage et la réutilisation des ressources d'information, par exemple, intégrer les systèmes et éliminer les chevauchements, mais d'autre part, aucun mécanisme n'est mis en oeuvre pour vérifier la redondance. Par conséquent, le manque d'intégration de systèmes, l'intégrité des données est douteuse au mieux, et les systèmes sont régulièrement réécrit encore et encore, ce qui représente l'effort de travail redondant. * D'une part, les gestionnaires de connaître leurs systèmes et les logiciels devraient être correctement documentés, afin d'accélérer la maintenance et les futures modifications / améliorations, mais d'autre part, la documentation est l'une des premières choses sacrifié quand un projet est retardé. On suppose que le système sera documenté par la suite, mais malheureusement, ce n'est jamais. Au lieu de documents devant être considéré comme un outil essentiel de travail et un sous-produit de design, il est considéré comme une tâche sans conséquence et lourdes. * D'une part, les gestionnaires affirment qu'ils veulent tous un travail de qualité, mais d'autre part, ils ne sont pas disposés à imposer la discipline nécessaire, l'organisation, et la responsabilité de mettre en œuvre un environnement de qualité. * D'une part, les gestionnaires de la promesse de mettre en œuvre les projets à temps et selon le budget, mais d'un autre côté, cela se produit rarement comme la gestion de projet est superficiellement mises en oeuvre dans leurs organisations. * D'une part, les gestionnaires veulent que leurs systèmes d'être portable, ce qui les rend indépendants de leur environnement machine, mais en revanche ils sont en proie à la dernière promesse technique et développer des systèmes adaptés à un dispositif physique particulier. La «pilule» APPROCHE Évidemment, vous ne pouvez pas avoir les deux tableaux. Vous devez prendre une position et mettre en œuvre en conséquence. Fondamentalement, il existe deux solutions: un outil ou une approche orientée vers la gestion-oriented approach. En surface, l'outil d'approche orientée semble être la moins douloureuse car elle ne nécessite pas de manœuvres politiques ou chutzpah gestion. Je me réfère à ce que la pilule "" approche pour résoudre les problèmes. Laissez-moi vous expliquer. Il ya des années, le comédien George Carlin a parlé de comment la culture de la drogue en Amérique du arrivé. C'était son argument selon lequel on nous apprend à avaler une pilule à un âge précoce, comme avec des vitamines pour les enfants. En vieillissant, il devient de ce fait naturel pour nous d'avaler une pilule pour tout ce maux que nous connaissons. Elle mai ne pas être le bon traitement, mais nous croyons qu'elle est l'approche la plus rapide pour satisfaire notre problème. Demandez à n'importe quel médecin, et ils vous diront placebos peut faire des merveilles dans certaines situations, mais ils savent aussi qu'ils ont des limites et ne peuvent remplacer le traitement médical approprié. Cette pilule "phénomène" n'est pas différent de l'achat d'un nouvel outil de développement qui prétend résoudre tous vos problèmes. Vous savez quoi? Il n'ya pas d'outil. Il n'existe pas, c'est un mythe que les taux de là-haut avec le lapin de Pâques et la Fée des dents. Pas plus qu'elle ne ait jamais existé. La réalité est que nous aurons toujours besoin d'une variété d'outils qui abordent différents aspects du processus de développement. Et je comprends cela, dans un logiciel seul, il ya des centaines de façons de la peau d'un chat, merci de différents langages de programmation, la conception et des techniques de base de données, D'un autre côté, il ya la gestion-oriented approach. Cela nécessite la structure, la discipline et la responsabilité; trois mots laids dans le paysage des systèmes actuels de développement. Mais avant de s'attaquer à rien d'essentiel, il est essentiel qu'un tel environnement est créé. Pouvez-vous imaginer la conception d'un pont ou un bâtiment sans ces disciplines en place? À peine. Pourquoi devrais-systèmes en être autrement? Ce qui est nécessaire est la création d'une attitude professionnelle parmi le personnel, grâce auquel un système est considéré comme un produit qui peut être conçu et fabriqué comme n'importe quel autre produit. Une fois que nous avons la bonne perspective, nous pouvons organiser le personnel en conséquence et de créer un effort concerté de développement. Certes, nous allons utiliser les outils pertinents dans le processus de développement, mais nous devons reconnaître que les outils vont et viennent, et sont appliquées de manière dynamique. C'est le processus de construction de systèmes qui devraient être considérés comme un précurseur à l'application d'outils, de nos méthodologies. Ce n'est que lorsque nous pouvons réorganiser notre environnement de développement homogène en un environnement homogène que nous serons en mesure d'agir comme de vrais professionnels. Malheureusement, cela exige une certaine force de gestion, ce qui est une denrée rare de nos jours. Beaucoup de gens, lèvent les bras et dire que c'est pas possible en raison de la gestion des réalités d'aujourd'hui et de se résigner à faire de petites applications négligeables, d'où la dichotomie mentionnée plus haut. Mais il faut considérer ce que nous avons accompli au cours des trente dernières années. Nous avons essayé les outils CASE, 4GL, les générateurs de programme, le prototypage sida, les rédacteurs de rapports, d'outils BPR, forfaits SGBD, établis programmeur, etc Certes, nous avons quelques outils de développement de grande demande, mais si elles sont si bon, pourquoi vivons-nous toujours des problèmes ? La réponse est évidente: nous avons abdiqué contrôle de gestion sur l'environnement des systèmes de notre développement. Il est maintenant temps pour les gestionnaires de systèmes de développement de se battre pour leurs départements, leur profession, et eux-mêmes, et agissent comme des gestionnaires. Toutes les choses que vous prétendez vouloir et le soutien sont à votre portée, tant que vous commencer à se comporter davantage comme un gestionnaire, par opposition à un pion pour le dernier gadget à la programmation. Face it, vous avez été séduites et abandonnées par vos fournisseurs d'outils. Vous pouvez parler la conversation, mais pouvez-vous marcher vraiment le pied? CONCLUSION Gestion d'un environnement de développement de systèmes exige quelqu'un habile dans les fondamentaux du management, n'est pas intimidé par la technologie, et a une vue plus globale des systèmes. Certains gestionnaires de meilleurs systèmes de développement que j'ai rencontrés au cours des années ont été des gens qui n'avaient pas de connaissances informatiques, mais, au contraire, venait d'une zone utilisateur et ne sont pas intimidés par la dernière charabia technique. Ils étaient des pragmatiques qui ont été axées sur les résultats et mis en œuvre un environnement de gestion lorsque la terminologie et les concepts de développement ont été normalisées et uniformément appliquées. Franchement, certains des meilleurs candidats pour le poste de directeur du développement des systèmes, sont les critiques les plus vives du département. Entreprises dit alors: "Ok, mettre ou de se taire." Malheureusement, la plupart des responsables du développement d'aujourd'hui sont l'antithèse de ce que je viens de décrire. Si le choix est entre la qualité et de vitesse, ils auront toujours la vitesse. Le point est que vous pouvez avoir les deux sans pour autant sacrifier non plus, il demande juste de la maîtrise de la gestion. Tous les gestionnaires de développement de systèmes savoir ce que la guérison est, ils sont tout simplement pas disposés à le prendre. Mais comprendre cela, vous ne pouvez avoir votre gâteau et le manger aussi. |