Ich hatte gerade eine Diskussion mit einem Mitarbeiter von mir über den Standard der Abteilung Programmiersprache. Er war der Meinung, dass die Wahl der Programmiersprache beim Projektteam liegen sollte. Ich bin der Meinung, dass das Management die Gesamtentscheidung darüber treffen sollte, welche Sprache verwendet wird. Wenn zwei Sprachen zu den Projektkriterien passen, sollte der Wunsch des Teams berücksichtigt werden? Ich würde gerne die Erfahrungen von allen hören.
Denken Sie daran, dass das Management den Code behalten muss, wenn das Programmiererteam weiterarbeitet, und auch neue Programmierer einstellen müssen, um es in Zukunft zu erhalten. Wenn das Team also Erlang oder Haskell wählen möchte, hat das Management die Verantwortung, nein zu sagen. (Entschuldigung, Erlang und Haskell Devs auszuwählen, aber es gibt nicht viele von euch).
Im Allgemeinen ist dies das Problem - das Team möchte etwas nutzen, das ihnen irgendwie nützt, aber der Fokus sollte auf der Zukunft des Codes liegen, der dem Unternehmen gehört und von der Firma bezahlt wird (dh Ihr Lohn) ). Sie müssen sicherstellen, dass sie in Zukunft unterstützt werden können.
Sie würden auch für Ihr Training bezahlen, also liegt es ganz an der Verwaltung.
Das Team kann Vorschläge machen und versuchen, die Entscheidung zu beeinflussen, und ich bin mir sicher, dass alle außer den schlechtesten Unternehmen dem Team aufmerksam zuhören würden, aber die Entscheidung des Managements am Ende.
Ich denke, dass die Teammoral ziemlich schrecklich leiden wird, wenn sie sagen: "Wir würden gerne diese Sprache benutzen." und das Management sagt "Nein, Sie müssen stattdessen diese Sprache verwenden."
Es muss wirklich eine gemeinsame Entscheidung sein und jeder muss seine Argumentation unterstützen.
Dies ist eigentlich eine "Vertrauen" -Frage in Verkleidung.
Wenn das Management Vertrauen hat, ist die Wahl ein Kinderspiel (lassen Sie die technischen Experten entscheiden).
Ich würde jedem Team empfehlen, diese Situation durchzugehen, um sich die zugrunde liegende Vertrauensfrage anzusehen, anstatt sich ausschließlich auf das Sprachproblem zu konzentrieren.
Konzentriere dich auf die Ursache und das Ergebnis / Symptom wird sich selbst beheben.
Ja. Beide Gruppen sollten Input haben. Viele verschiedene Aspekte müssen darüber hinaus berücksichtigt werden, obwohl dies ein wichtiger Aspekt sein kann. Arbeitsmarkt (Fähigkeit, neue Leute für die Arbeit einzustellen), Sprachunterstützung, Werkzeuge, etc.
Die eigentliche Frage ist, was der Vorteil ist, wenn man eine Sprache einer anderen Sprache auswählt:
Funktionalität: Was kann die Arbeit bekommen besser jetzt und in der Zukunft? Wird diese Technologie Entscheidung beweist eine felsenfeste Entscheidung für die Zukunft dieses Projekts und Interessiert mich das überhaupt (von a Management-Position, natürlich)?
Kosten: Muss ich zusätzlich kaufen Hardware oder Software dafür Technologiewahl? Will ich sein fest mit dieser Hardware / Software? Ist das Entwicklungsteam versiert? die vorgeschlagene Technologie oder Muss ich neues Blut anstellen?
Tatsache ist, dass das Management diese Fragen stellen sollte, und die Entwicklung sollte für sie ein Resonanzboden sein.
Meiner Meinung nach kommt es sehr auf die Situation an.
Natürlich sollten Sie ihren Wunsch berücksichtigen, aber eine große Sache zu berücksichtigen wäre, welche Sprache das Team am produktivsten ist. Auch eine große, die manchmal vorbei ist, ist, wer wird das Projekt in der langfristig und was sind ihre Kompetenzen?
Der letzte für mich ist ein ziemlich großer, zu oft geht ein Programmierer mit einer Edge-Case-Technologie in eine seltsame Richtung, hauptsächlich weil er / sie es "ausprobieren" möchte oder weil es neu und heiß ist. In diesen Fällen ist die Wartbarkeit oft weitgehend vergessen und es kommt zurück, um das Unternehmen zu beißen, sobald der Programmierer weg ist und jemand anderes die Wartung des Projekts übernehmen muss.
Andererseits, wenn Ihr Team sich sehr stark dafür interessiert, lohnt es sich, einen Riss zu verursachen?
Am Ende des Tages hängt das wiederum von Ihrer Situation und der Art des Projekts ab.
Ich denke, dass es bei beiden Ansätzen Gefahren gibt. Programmierer neigen dazu, mit den coolen und unterhaltsamen aufstrebenden Technologien zu gehen, und das Management könnte mit der stark vermarkteten oder kommerzialisierten Technologie gehen (aber unpopulär mit dem Anti-Microsoft-Entwickler-Team;)).
Es muss jemand in einer Architektenrolle sein, der sich mit beiden Gruppen abstimmen und eine objektive Entscheidung treffen kann, die auf den Geschäftszielen und den Bedenken der Entwickler basiert. Diese Person muss die Gesamtziele des Systems verstehen, die von den Kunden benötigte Infrastruktur, die Robustheit und die Unterstützung der Technologie abwägen. etc ... natürlich hängt es von der Größe des Unternehmens / Projekts ab, was die Auswirkungen dieser Entscheidungen angeht.
Ihre erste Sorge sollte sein, ob die Sprache die Arbeit macht oder nicht. Mark Twain sagte: "Für einen Mann mit einem Hammer sieht alles wie ein Nagel aus." Nur weil das Team mit einer Sprache vertraut ist, heißt das nicht, dass es das beste Werkzeug ist. Auf der anderen Seite würden Entwickler, die in einer Sprache gut gewürzt sind und Domänenexperten sind, produktiver mit ihren eigenen Tools arbeiten.
Das zweite Problem betrifft die Verfügbarkeit von Entwicklern. Wenn das Team weiterzieht, wer wird es unterstützen? Es kann teuer werden, entweder für eine obskure Sprache zu mieten oder umzuschulen. Die Sprache kann auch neu genug sein, damit die Entwicklerbasis nicht zustande kommt.
Das dritte Problem betrifft die Verfügbarkeit / Stabilität des Werkzeugs. Müssen Sie jedes Mal, wenn sich die Sprache ändert, ständig neu schreiben (ich denke an VB / .Net). Und wer unterstützt es? Was passiert mit der Sprache, wenn der Verkäufer aufgibt?
Die kurze Antwort ist dann, dass wenn das Team eine Präferenz hat, sie ein starkes Argument für ihre Wahl darstellen sollten; überzeugend genug, um den Chef davon zu überzeugen, dass die Schmiergelder des Verkäufers nicht die Mühe wert sind. Versuchen Sie, die Argumentation des Managements zu verstehen, damit Sie die Entscheidung akzeptieren können, wenn Sie sie nicht widerlegen können.
Natürlich ist der Input des Teams wichtig. Wenn Sie sich für ein wichtiges architektonisches Stück Ihrer Bewerbung entscheiden und das Team denkt, dass es nicht daran beteiligt war, dann werden Sie moralische Probleme haben. Die Entscheidung sollte schließlich vom Management getroffen werden (vorausgesetzt, das Management ist technischer Natur) und den leitenden Architekten und PMs.
Aber eine Sache, an die Sie sich erinnern sollten, wenn Sie eine Sprache wählen, ist, dass Sie eine höhere Erfolgsquote haben werden, wenn das Team mit Ihrer Wahl vertrauter und zufriedener ist. Wenn Sie dem, was sie zu sagen haben, zuhören und dann mit konkreten geschäftlichen und technischen Gründen zu ihnen kommen, warum Sie nicht mit ihrer Entscheidung gegangen sind, dann haben sie sich zumindest gefühlt, dass sie gehört wurden und Teil des Prozesses waren.
>Letztendlich muss es die Entscheidung des Managements sein, nur weil sie die Last der Nachwirkungen tragen, wenn Programmierer gehen, und auch die Interessen des Unternehmens bei der Wahl vertreten. Bei einer Sprachauswahl müssen nicht nur die Fähigkeiten / Fähigkeiten des derzeitigen Programmteams berücksichtigt werden, sondern auch alle zukünftigen Mitglieder und alle Hilfskräfte im Hinblick auf marktfähige Fähigkeiten. Sie möchten nicht zu sehr auf eine Sprache verzichten, wenn Sie keine qualifizierten Mitarbeiter finden, die sie unterstützen. Wenn sich die Sprache dem Ende ihres populären / unterstützten Lebens nähert, besteht zudem die Gefahr, dass sie bis zu dem Punkt obsolet wird, an dem sie früher als erhofft umgeschrieben werden muss.
Ich mache die allgemeine Annahme, dass die Wartbarkeit, die Fähigkeit und der Typ der Sprachauswahl nicht grundsätzlich verschieden sind (d. h. ML vs. C ++).
Wenn man diese Faktoren im Hinterkopf behält und die Sprachwahl anders ist, dann wäre die Verwendung der Sprachwahl des Teams für die Moral am besten und würde zu einem besseren Produkt führen, ohne die langfristige Wirkung zu beeinträchtigen Aussichten der Anwendung.
Meine Erfahrung an unserem Arbeitsplatz, Management hat eine Diskussion mit dem technischen Team, wo das technische Team Vorschläge zu der Programmiersprache gab, die wir kennen und am besten arbeiten. Dann entscheidet das Management die Programmiersprache, die die Abteilung verwendet. Es sollte in beide Richtungen funktionieren, da das technische Team in der Lage sein muss, mit der Programmiersprache zu arbeiten (um termingerecht liefern zu können) und für das Management mittel- bis langfristig auf das Geschäft, Ressourcenmanagement und Training einplanen kann.
Die Auswahl der Sprachen für ein Projekt sollte die Präferenzen der Teams enthalten, die nicht die richtigen Entscheidungen für das Projekt und seine Umgebung außer Kraft setzen.
Das Programmierteam sollte mehr Erfahrung mit den Sprachen auf der engeren Auswahlliste haben als das Managementteam, für das sie eingestellt wurden, und es sollte technisch besser qualifiziert sein, um zu beurteilen, welche Technologien für sie besser geeignet sind.
Nur wenn das Managementteam mindestens so gut qualifiziert und erfahren in den Entscheidungen ist, sollten sie versuchen, die kollaborativen Entscheidungen des Teams zu beeinflussen, es sei denn, es gibt nichttechnische Geschäftsauswirkungen auf die Entscheidungen, und diese sollten zur Prüfung vorgelegt werden / p>
Gutes Management lassen die Mitarbeiter tun, was sie angestellt haben und wo sie können, also sollte IMHO die Wahl an das Programmierteam delegieren.
Ein fröhliches Programmiererteam wird produktiver sein, am Ende ein besseres Ergebnis haben und nicht murren, wenn es Schwierigkeiten hat, mit seiner Wahl zu arbeiten.
Das Management sollte sich mehr darum kümmern, dass das endgültige Projekt rechtzeitig, innerhalb des Budgets und mit einem positiven Ergebnis abgeschlossen wird, und dann mit den Technologien, die verwendet werden, es sei denn, die Entscheidungen haben spezifische geschäftliche Auswirkungen, die behoben werden müssen.
Die Mitglieder des Programmteams und die Mitglieder des Managementteams sind alle im selben Team, und alle Bedürfnisse sollten berücksichtigt werden, einschließlich der Technologien, die die Teammitglieder am besten verwenden und die für jedes Projekt am besten sind Überlegung nur durch geschäftliche Notwendigkeiten oder sachliche technische Überlegungen.
Um einen berechtigten Geschäftsgrund dafür zu finden, dass die Wahl eines Programmteams nicht unterstützt wird, könnte die Technologie nicht so ausgereift sein, dass Teammitglieder zu vernünftigen Kosten von einem vernünftigen Pool oder einer einfachen Schnittstelle zu aktuellen oder geplanten Ressourcen ersetzt werden können / p>
Es gibt eine Menge zu dieser Frage. Am Ende treffen die Personen, die für die Arbeit bezahlen, die Wahl. Aber:
Wenn das Management nicht klüger ist als die Leute, die sie eingestellt haben, sollten sie ihre Eingaben berücksichtigen. Das Management erklärt Codern normalerweise nicht, dass mit jeder Sprachwahl Ausgaben verbunden sind, die andere Entscheidungen wünschenswerter machen. Das führt bei den Programmierern zu Unmut, wenn sie glauben, dass ihr Rat ignoriert wurde.
Es gibt eine ganze Reihe von Individuen, die ein ernsthaft fehlerhaftes Urteilsvermögen haben. Sie kennen nur eine Sprache und empfehlen diese nur. Das Management hat es vielleicht schon erfunden und wird seine guten Ratschläge ignorieren. Programmierer oder Management können übertriebene Technophile sein und technische Lösungen annehmen, auch wenn sie nicht im besten Interesse des Projekts sind. Sie können auch starke Meinungen haben und nicht genug emotionale Reife haben, um anderen zu widersprechen.
Mitarbeiter können wissentlich Dinge vorschlagen, die nicht im besten Interesse des Projektinhabers sind, weil das, was sie vorschlagen, in ihrem eigenen Interesse liegt.
Meistens glaube ich, dass die Entscheidungen aus emotionalen Gründen getroffen werden, nicht aus rationalen Gründen.
Ein guter Projektmanager wird seine leitenden Ingenieure in die Lage versetzen, diese Entscheidung zu treffen und seine Aufgabe zu erfüllen: das Projekt zu managen, d. h. das Entwicklungsteam vor "oberer Management-BS" zu schützen. Ein guter Projektmanager wird auch von seinen leitenden Ingenieuren verlangen, im Detail zu begründen, warum sie mit einer bestimmten Programmiersprache arbeiten (wenn die Wahl der Sprache überhaupt wichtig ist). Wenn er mit der Begründung nicht zufrieden ist, denke ich, dass es seine Aufgabe ist, das Entwicklungsteam in eine Richtung zu lenken, in der jeder leben und arbeiten kann. Erzwingen einer Sprache in einem Entwicklungsteam? Keine gute Idee. Das Projekt wird zum Scheitern verurteilt sein.
Stimmen Sie mit anderen Plakaten überein, dass es sich um eine gemeinsame Entscheidung handeln sollte. Aber - oft muss das Management längerfristig denken als nur das Projektteam, zum Beispiel der laufende Wartungsaufwand. So kann die Lebensdauer der Software ein Faktor sein. Wenn das Team etwas wählt, das nicht Mainstream ist, werden sie immer einen Kampf an den Händen haben.
Außerdem gehört das endgültige Sagen normalerweise dem Kunden. Wenn das Projekt in-house ist, kann der Kunde nur lokale Verwaltung / Tech sein. Für andere Kunden wird das Team einige sehr pessimistische Gründe brauchen, um gegen ihre Wünsche zurückzuschlagen.
Es tut mir leid - aber in welchem anderen Zweig der Technik wäre das überhaupt eine Frage? Boeing Designer entschieden, dass es cooler wäre, Raketenmotoren anstelle von Turbofans zu verwenden?
Betrachten Sie die Sprache. Wenn es eine leicht befüllbare Programmierposition ist (dh wenn Sie jemanden in einer Woche einstellen können, um einen Job eines dieser Programmierer zu besetzen - sollten sie gehen), dann gehen Sie mit der Empfehlung des Teams. Sie werden nicht glauben, wie viel Arbeit sie tun werden, wenn Sie ihnen das sagen. Andernfalls müssen Sie möglicherweise mehrere Positionen füllen. Setzen Sie nicht auf eine schlechte Wirtschaft und halten Sie Softwareentwickler in ihren Sitzen. Dies ist eigentlich eine perfekte Zeit zum Einkaufen. Halten Sie sie glücklich, aber stellen Sie sicher, dass die Sprachwahl keine obskure, tote Sprache ist.
Ich würde mich definitiv mit dem Team beraten, das die Entwicklung zu der Zeit macht. Geben Sie ihnen das Design-Dokument und erhalten Sie ihr Feedback. Das gibt ihnen zumindest das Gefühl, dass ihre Entscheidung zählt.
Manager müssen andere Dinge berücksichtigen, z. B. Kosten für das Trainingspersonal in der gewählten Sprache, Kosten für den Kauf von IDEs (falls erforderlich), Wartungskosten für die Codebasis nach der ersten Entwicklung.
Nachdem der Manager eine informierte Entscheidung getroffen hat, sollten die Entwickler die Möglichkeit haben zu fragen, warum die bestimmte Entscheidung getroffen wurde. Überlasse die Entscheidung dem Management, aber fördere die Transparenz der Entscheidung.
Es ist interessant, dass die Wahl der Programmiersprache ein so bedeutendes Thema für das Management sein sollte, während die Verwendung einer aufwendigen Open-Source-Bibliothek oder eines Frameworks oft ohne große Rücksichtnahme erfolgen wird.
Historisch gesehen gab es eine gewisse Logik, denn die Änderung der Programmiersprache bedeutete den Wechsel der Plattformen, aber jetzt, da Programmiersprachen standardisiert sind, um auf den CLR- oder JVM-Plattformen zu laufen, teilen die Bibliotheken und Bereitstellungsumgebungen die Kosten der Diversifizierung verschiedene Sprachen können weniger sein als abhängig von komplexen Frameworks.
Wenn Ihre Anwendung beispielsweise eine Regelengine benötigt, ist es möglicherweise besser, eine JVM-Version von prolog zu verwenden, als von einer obskuren Java-Rule-Engine-API abhängig zu sein.
Sie müssen das Team berücksichtigen, es sind diejenigen, die es schaffen. Wenn sie mit der Sprache nicht arbeiten / können, wird es das Projekt wirklich hart machen.
Offensichtlich wird das Management das letzte Wort haben, dafür ist Management da, aber sie müssen die Präferenzen / Vorschläge des Teams berücksichtigen. Ich denke, dass sie einen wirklich guten Grund haben müssen, nicht die Sprache zu wählen, die das Team vorschlägt
Wenn Ihre Programmierer beispielsweise Java besser als C # verstehen, ist es sinnvoll, Java zu verwenden, wenn einer von beiden funktioniert. Wie bei jeder Entscheidung auf dieser Ebene könnte das Management Gründe haben, sich für das eine oder das andere zu entscheiden. Sie sollten auf das Team hören, aber die ultimative Entscheidung sollte ihnen gehören.
Ich finde, dass Entwickler in der gewählten Sprache tatsächlich ein Mitspracherecht haben sollten. Manager scheinen generell die Gewohnheit zu haben, mit "Schlagworten" zu gehen. (Gut) Programmierer werden hoffentlich die beste Sprache für den Job kennen, eine Meinung, die auf jahrelanger Erfahrung basiert, die dem Management fehlt.
Tags und Links programming-languages project-management project-planning