Software-Manager, der Entwickler zum Projektmanagement veranlasst

Ich bin ein Softwareentwickler, der in einem Embedded-System-Unternehmen arbeitet. Wir haben einen Projektmanager, der sich um den gesamten Projektzeitplan kümmert (einschließlich Elektrik, Qualität, Software und Fertigung), daher ist sein Softwarezeitplan sehr kurz.

Wir haben auch einen Software Manager, der mein Chef ist. Er veranlasst mich, den Software-Zeitplan zu schreiben und zu pflegen, Dokumente zu entwerfen (High- und Low-Level-Design), SRS, Änderungsmanagement, Überprüfungspläne und -berichte, Release-Management, Überprüfungen und natürlich die Software.

Wir haben nur einen Testingenieur für das gesamte Softwareteam (10 Mitglieder), und zu einem bestimmten Zeitpunkt laufen einige Projekte.

Ich verbringe 80% meiner Zeit damit, diese Dokumente zu erstellen. Mein Chef hat einen Prozesshintergrund und glaubt, dass wir eine bessere Dokumentation zur Verbesserung der Software benötigen:

1. Er ist der Ansicht, dass das Design von größter Bedeutung ist. Das Codieren besteht darin, "nur das Design aufzuschreiben", es sollte nicht zu lange dauern und "der gesamte Code sollte geschrieben werden, bevor die Hardware fertig ist".
2. Versteht den Unterschied zwischen einer zentralen und verteilten Versionskontrolle nicht, auch nachdem wir ihm gesagt haben, dass es einfacher ist, mit einem verteilten Modell zusammenzuarbeiten.
3. Versteht keinen Code und möchte jeden Fehler und die vorgeschlagene Lösung verstehen.
4. Ist der Ansicht, dass die Überprüfung durch den Entwickler und die Validierung durch den Tester erfolgen sollte. Unsere Überprüfung überprüft jedoch nur, ob die Implementierung korrekt ist (wir schreiben keine Komponententests, sie werden im Zeitplan nie berücksichtigt), und die Validierung ist ein Black-Box-Test, sodass die Komponententests fehlen.

Ich bin wirklich verwirrt.

1. Bin ich für die Pflege all dieser Dokumente verantwortlich? Es gibt mir das Gefühl, dass ich im Wesentlichen das Software-Projektmanagement mache. Ich bin mit der technischen Dokumentation einverstanden, aber ich glaube, dass die Planung nicht vom Entwickler durchgeführt werden sollte.
2. Ich mag es nicht wirklich, Dokumente zu erstellen, ich möchte Probleme lösen und Code schreiben. Nach meiner Erfahrung hilft das Erstellen von Designdokumenten nur bis zu einem gewissen Grad. Es ist nie die Lösung für besseren oder schnelleren Code.
3. Ich habe das Gefühl, dass es dem Chef nicht wirklich wichtig ist, bessere Produkte herzustellen, sondern nur, in den Augen des Managements ein guter Manager zu sein.

Was kann ich tun? In diesem Jahr habe ich 3 Monate lang das eigentliche Codieren durchgeführt, den Rest habe ich nur für das Erstellen von Dokumenten und das Warten auf Fehlermeldungen von Kunden aufgewendet.

Sie klingen wie ein Software Engineer.

Ein Projektmanager konzentriert sich mehr auf den Status des Gesamtprojekts und ordnet die Ressourcen auf effektive Weise zu, um sicherzustellen, dass die Meilensteine ​​rechtzeitig erreicht werden. Sie beseitigen außerdem Hindernisse und helfen den Projektressourcen, sich auf ihre spezifischen Aufgaben zu konzentrieren.

Das Verfassen und Verwalten von Design und technischer Dokumentation ist ein wichtiger Bestandteil der Arbeit als Softwareentwickler und für Ihre Rolle geeignet. Zu viel Gutes kann jedoch schlecht sein (siehe Analyse-Analyse ).

Er hält das Design für überragend, Kodierung bedeutet "nur das Design aufzuschreiben"

Wenn der Projektmanager die Designdokumente als vorrangig ansieht, erwartet er, dass die Dokumente im Prozess als zu liefernd gelten. Es ist keine verschwendete Zeit für Sie, wenn Sie der Meinung sind, dass sie wichtig genug sind, um 80% Ihrer Zeit dafür aufzuwenden.

es sollte nicht zu lange dauern und "der gesamte Code sollte geschrieben werden, bevor die Hardware bereit ist".

Dies ist Wunschdenken und eine ziemlich antiquierte Ansicht im Wasserfallstil, wie Softwareentwicklung funktioniert. Es ist ausnahmslos nie so sauber, egal wie viel Design und Vorbereitung Sie verwenden. In diesem Sinne sollten Sie jedoch klare Hardwarespezifikationen und geeignete Testumgebungen sowie nachgeahmte Hardwaresimulationen haben, mit denen Ihr Code interagieren kann, aber auch hier ist die reale Welt chaotisch.

Projektmanagement ist in einer perfekten Welt unglaublich einfach. Die Welt ist nicht perfekt, egal wie sehr Sie sich das wünschen, was ein echtes Projektmanagement unglaublich schwierig macht. Deshalb wird ihnen das große Geld ausgezahlt.

(2) Versteht den Unterschied zwischen einer zentralen und verteilten Versionskontrolle nicht.

Warum sollte es ihn interessieren? Wie wirkt es sich auf die Meilensteine ​​aus? Das tut es nicht.

3) Versteht keinen Code und möchte jeden Fehler und die vorgeschlagene Lösung verstehen

Sein Ziel ist es, Software zu arbeiten, und Ihre sollte es auch sein. Er muss den Code nicht verstehen, aber er muss die Probleme verstehen, die verhindern, dass Software funktioniert. Sobald Sie beide diese grundlegende Ebene auf Augenhöhe sehen, hilft Ihnen Ihr gemeinsames Ziel dabei, effektiver zusammenzuarbeiten.

(4) Die Überprüfung sollte nach Ansicht des Entwicklers und die Validierung durch den Tester erfolgen.

Was ist falsch an diesem Gefühl? Tester in der Rolle der Qualitätssicherung sollten sich mit der Validierung von Merkmalen und Anforderungen befassen. Entwickler sollten alle Anstrengungen unternehmen, um ihre Arbeit zu verifizieren und zu testen, bevor sie getestet wird.

Ich mag es nicht wirklich, Dokumente zu erstellen, ich möchte Probleme lösen und Code schreiben.

Wenn Sie lieber ein einfacher Programmierer wären, sollten Sie vielleicht mit Ihrem Chef darüber sprechen und herausfinden, ob das Projekt eine bessere Rolle für Sie spielt. Jemand muss die technische Dokumentation schreiben und warten. Vielleicht kann Ihnen einer der anderen Entwickler bei einigen dieser Aufgaben helfen, sodass Sie nicht 80% Ihrer Zeit damit verbringen, Dokumentation zu schreiben.

Nach meiner Erfahrung hilft das Erstellen von Designdokumenten nur bis zu einem gewissen Grad. Es ist nie die Lösung für besseren oder schnelleren Code.

Dies ist größtenteils der Fall ... aber nur, wenn alle zehn Entwickler 80% ihrer Zeit damit verbringen, technische Dokumentationen zu schreiben, die niemand jemals lesen wird. Dies ist ein gewaltiges Anti-Muster-Management, in dem ich zuvor gelebt habe. Wenn Sie feststellen, dass Sie den größten Teil der Dokumentation für das Team erstellen, ist es kaum fair, dass Ihnen das Recht verweigert wird, weitere Codierungsarbeiten durchzuführen.

Tatsache ist, dass die beste technische Dokumentation der Code selbst ist.

Ich habe das Gefühl, dass es dem Chef nicht wirklich wichtig ist, bessere Produkte herzustellen, sondern dass er in den Augen des Managements ein guter Manager ist

Ich habe das Gefühl, dass es ihm etwas ausmacht , weil das Produkt seine Abteilung ist. Wenn Projekte und Funktionen nicht abgeschlossen sind und die Kunden nicht zufrieden sind, wird ihn das obere Management nicht sonderlich interessieren. Das Problem ist, dass Ihre Sicht auf die notwendigen Qualitätsverbesserungen nicht mit seiner und der oberen Führungsebene übereinstimmt und die Wahrnehmung der Kunden, was sie für wichtig halten, wichtig ist.

Versuchen Sie zu verstehen, was für das Produkt wirklich wichtig ist, denn während Sie die Effizienz eines Prozesses um das Dreifache steigern können, muss der Kunde eine weitere wichtige Funktion in Kauf nehmen, wenn Sie eine ganze Woche damit verbringen.

Wir alle möchten für die Augen unseres Vorgesetzten gut aussehen. Daran ist nichts auszusetzen, es liegt in der menschlichen Natur, sich selbst zu dienen. Das ist eine Tatsache des Lebens.

Bis zu einem gewissen Grad stimme ich Ihrem Projektmanager zu. Die Softwareentwicklung geht weit über die Codierungsfunktionen hinaus. :-)

In Anbetracht Ihrer Situation gehe ich zu ihm und erkläre, dass seine Anfragen 80% Ihrer Zeit in Anspruch nehmen, und versuche zu verstehen, warum es für ihn wichtig ist, dass Sie diese Zeit damit verbringen, die Dokumentation zu pflegen, anstatt sie zu entwickeln (was über das Codieren hinausgeht).

Zu Ihrer Information , Atlassion , ein Software-Unternehmen, hat ein Verhältnis von 13 Entwicklern für eine QS-Person und die meisten Tests (Planung und Ausführung) werden von den Entwicklern durchgeführt. Das habe ich bei einer ihrer Präsentationen auf der Agile 2012 erfahren und unsere Teams, die ich derzeit versuche, diese Praxis zu emulieren.

Ich würde jedoch auch mit Ihrem Projektmanager besprechen, ob er bereit ist, Scrum als Methode auszuprobieren, um das gesamte Team voranzubringen. Angesichts Ihrer Beschreibung glaube ich nicht, dass Sie Scrum verwenden.

Wie Sie war ich äußerst frustriert, Pläne beizubehalten, die sich ständig änderten, und ein leichtgewichtiger Ansatz von Scrum half mir, diese Frustration zu überwinden.

Meiner Erfahrung nach waren die leistungsstärksten Teams diejenigen, die mit dem geringsten Prozessaufwand konfrontiert waren, der für ihre Arbeit erforderlich war. Irgendwann beginnt ein zusätzlicher Prozess, dem Produkt Qualität zu nehmen. Wenn QA anfängt, Fehler zu übersehen, weil sie sich mehr darum kümmern, Papierkram aus dem Weg zu räumen, und DEV keine Funktionen codiert oder Fehler behebt, weil sie Dokumentation schreiben, dann haben Sie ein Problem. Die Frage, ob dies in Ihrem Unternehmen tatsächlich der Fall ist, kann jedoch nur von Mitarbeitern Ihres Teams (nicht von uns) beantwortet werden.

Es gibt eine Sache, die Ihr Chef sehr falsch meint, und die Tatsache, dass Sie so wenig Qualitätssicherung und keine Unit-Tests haben. Ein Fehler, den ein Entwickler verursacht, ist per Definition ein Versehen für ihn. Es ist ein Prozessproblem, von Entwicklern zu erwarten, dass sie immer ihre eigenen Funktionen testen und darüber hinaus nur wenige Tests durchführen. Die Qualitätssicherung kann durch automatisierte Tests in Abhängigkeit von Ihrer Domain bis zu einem gewissen Grad ersetzt werden. Wenn Sie jedoch keines von beiden haben, lassen Sie Fehler wahrscheinlich durch. Dies kostet in der Regel mehr, als wenn Sie sie frühzeitig finden.

Aus einer strengen Geschäftsperspektive heraus ist die Einstellung von QS billiger als die Einstellung von Entwicklern. Wenn die Teams ein gutes QA / DEV-Verhältnis haben, können Sie mehr Boden für das ausgegebene Geld abdecken.

Die CMMI-Implementierungen, die ich gesehen oder direkt gehört habe, waren alle prozess- und dokumentationsintensiv. Ihre Chefs glauben, dass die Dokumentation detailliert genug sein sollte, um die Implementierung trivial zu machen, was stark impliziert, dass seine Erwartungen ähnlich sind.

Wenn Sie einen überproportionalen Anteil der Dokumentationserstellung / -wartung erhalten, ist es sinnvoll, eine gleichmäßigere Verteilung zu fordern. Wenn die anderen Entwickler ähnliche Dokumentationen wie die Codierungsverhältnisse haben und Sie die meiste Zeit mit dem Schreiben von Code verbringen möchten; Es kann an der Zeit sein, einen neuen Arbeitgeber zu finden.

Sie sprechen von medizinischen Systemen ... daher ist Sicherheit von höchster Wichtigkeit - und daher ist die Dokumentation (insbesondere die Rückverfolgbarkeit) von entscheidender Bedeutung.

Ein Tester scheint ein bisschen leicht zu sein, aber ansonsten sind Sie dafür verantwortlich, dass die Dokumentation vorhanden ist.

Meine Erfahrung in der medizinischen Welt ist begrenzt, aber in der Welt der Luft- und Raumfahrt / Verteidigung haben wir Do-178B (jetzt C), das ein Lebenszyklusmodell vorschreibt, das die Dokumentation und das erforderliche Testniveau spezifiziert (abhängig von der Sicherheitskritikalität). das Design Assurance Level] der Software), und in der Automobilwelt haben wir ebenfalls ISO26262.

Wenn die Dokumentation nicht vorhanden ist, wird das Produkt nicht zertifiziert.

Das Wichtigste ist jedoch, mit den erforderlichen Unterlagen zu arbeiten, um Ihr Produkt zu verbessern. Versuchen Sie nicht, die Unterlagen als Nachdenken zurückzuentwickeln, da sie dann keinen realen Zweck erfüllen.