Hi, mich würde interessieren wie ihr den Überblick über den aktuellen Stand eurer Projekte behält. In meiner Idealvorstellung gibt es eine zentrale Dokumentation (wie auch immer), und der Projektleiter hat die Hand drauf und sieht zu, dass das aktuell gehalten wird. Realität sieht, zumindest bei mir, leider anders aus. Gibt nichts zentrales, Kommunikation mit Meetings und Email, und ich muss mir selber meine "Projektvorstellung" dokumentieren. Wäre nicht das große Problem, ich schreibe mir das halt im Evernote nieder. Und weil es wie das Amen im Gebet irgendwann Streitereien gibt, warum ABC schreibe ich mir immer auch gleich dazu woher diese Info stammt und von wann. Problem: das wird unübersichtlich, ich kann auch nicht einfach mal die Doku umstrukturieren etc. Schreibe ich das aber nicht dazu, dann kann ich im Streitfall hunderte Emails und Protokolle durchschauen. Habt ihr da einen effizienten Ansatz dafür, ev. auch eine geeignete Softwarelösung? Würde mich über eure Ideen dazu freuen.
Es gibt diverse Tracking Lösungen, wir haben z.B. Jira auf der Arbeit. Projektpläne werden in MS Teams gemacht. Leider werden viele Meetings dann doch per Excel getrackt, aber die liegt zumindest auf dem zum Projekt gehörigen Sharepoint, sodass immer die aktuelle Datei vorhanden ist.
Jan K. schrieb: > Jira auf der Arbeit. Jira ist gut, habe ich auch bei manchen Kunden im Einsatz, wird aber leider sehr "lean" eingesetzt. > Projektpläne werden in MS Teams gemacht. Leider werden viele Meetings > dann doch per Excel getrackt, aber die liegt zumindest auf dem zum > Projekt gehörigen Sharepoint, sodass immer die aktuelle Datei vorhanden > ist. Schaust du dann immer die "offiziellen" Quellen durch? Ich müsste da wohl erst durchsetzen, dass alles zentral niedergeschrieben wird. Das darf dann bestimmt ich machen ;) Aber selbst hier stellt sich für mich die Frage, wie/ob ich dann eine Referenz zur entsprechenden Entscheidung habe. Habt ihr die Themen in Tickets abgelegt, wird das nicht mit der Zeit auch unübersichtlich?
Wieviel Prozent deiner Arbeitszeit werden dir explizit zum Lesen von Doku zugebilligt? Wieviel Prozent deiner Arbeitszeit werden dir explizit zum Verfassen von Doku zugebilligt? Ich habe mich hinsichtlich Qualität und Umfang von Doku immer an diesen Vorgaben orientiert. Beispiel: Wenn niemand Doku liest braucht man auch keine schreiben.
Schreib Dir doch alles auf die Hand. Immer dabei. Nix wird vergessen.
Holger schrieb: > Wenn niemand Doku liest braucht man auch > keine schreiben. Eigentlich ist die Doku für dich gedacht, um deine Arbeit zu planen und zu verfolgen. Eine Taskliste muss man zumindest haben.
Holger schrieb: > Wieviel Prozent deiner Arbeitszeit werden dir explizit zum Lesen > von > Doku zugebilligt? > Wieviel Prozent deiner Arbeitszeit werden dir explizit zum Verfassen von > Doku zugebilligt? Wenig :) Aber um die klassische Lösungsdokumentation geht es mir hier weniger, auch wenn die natürlich gewissen Einfluss hat. > Ich habe mich hinsichtlich Qualität und Umfang von Doku immer an diesen > Vorgaben orientiert. Beispiel: Wenn niemand Doku liest braucht man auch > keine schreiben. Ich muss ja Zeug entwickeln. Da wird beschlossen die Bestandslösung nur minimal anzupassen, dann hat Person A die Idee eines kompletten Redesigns, in Meeting B wird über eine Cloudlösung diskutiert, dann kommt ein E-Mail ich möge die Architektur bitte doch komplett neu designen. Außerdem brennt es in einem ganz anderen Projekt und ich komme erst zwei Wochen später wieder zu diesem Thema zurück. Jetzt muss zuerst einmal ich wissen, was denn nun der Letztstand ist, damit ich arbeiten kann. Zwei Monate später kommt ein Programmmanager/CIO/... zu mir und fragt mich warum ich die Luxuslösung implementiere und Geld verbrate, wenn wir doch nur eine Minimalanpassung geplant hatten. Da habe ich dann gerne halt auch die Info greifbar, wer welche Änderungen wann durchgesetzt hat mit Referenz auf E-Mail/Agenda etc. Nur wird mit dem ganzen "Papertrail" halt auch meine Übersicht für mich selbst, was ich denn nun zu tun habe, unübersichtlich.
Dirk K. schrieb: > https://blueant.de/de/ Mir geht es primär um Doku für mich selbst, "für kleine und mittelständische Unternehmen ab 50 mit bis zu 200 Anwendern" ist mir da eine Nummer zu groß.
Jan H. schrieb: > Mir geht es primär um Doku für mich selbst, "für kleine und > mittelständische Unternehmen ab 50 mit bis zu 200 Anwendern" ist mir da > eine Nummer zu groß. Ah ok. Für mich selbst: 1. Outlook E-Mails als Aufgabe markieren bei Einzelpunkten. 2. Exceltapete mit Aufgaben, Terminen, Reihenfolgen und Abhängigkeiten 3. One Note, wenn Übersicht über verschiedene Projekte gleichzeitig notwendig ist. Am Anfang beim ersten KMU (eher Klitsche) hatte mir 1. gereicht. Jetzt, beim einem Unternehmen welches in die obige Kategorie passt und ich eine Vorgesetztenfunktion inne habe, reicht nicht mal mehr One Note. EDIT: A. S. schrieb: > Tickets. Bei mir Track/SVN Das hilft auch ungemein.
:
Bearbeitet durch User
Jan H. schrieb: > Hi, > mich würde interessieren wie ihr den Überblick über den aktuellen Stand > eurer Projekte behält. In meiner Idealvorstellung gibt es eine zentrale > Dokumentation (wie auch immer), und der Projektleiter hat die Hand drauf > und sieht zu, dass das aktuell gehalten wird. > Realität sieht, zumindest bei mir, leider anders aus. Gibt nichts > zentrales, Kommunikation mit Meetings und Email, und ich muss mir selber > meine "Projektvorstellung" dokumentieren. Wäre nicht das große Problem, > ich schreibe mir das halt im Evernote nieder. Und weil es wie das Amen > im Gebet irgendwann Streitereien gibt, warum ABC schreibe ich mir immer > auch gleich dazu woher diese Info stammt und von wann. Problem: das wird > unübersichtlich, ich kann auch nicht einfach mal die Doku > umstrukturieren etc. Schreibe ich das aber nicht dazu, dann kann ich im > Streitfall hunderte Emails und Protokolle durchschauen. > Habt ihr da einen effizienten Ansatz dafür, ev. auch eine geeignete > Softwarelösung? Würde mich über eure Ideen dazu freuen. Nach welchem Modell entwickelt ihr denn? V-Modell? Oder agil via Sprints? Der Ort an dem alle Infos zusammenfließen Müssen: Pflichtenheft! (Egal ob Word Dokument oder per R4Jira). Deine Aufgabe ist es dieses Dokument mit dem aktuellen Entwicklungsstand zu befüllen. Änderungswünsche aus Besprechungen, Emails, Telefonaten müssen ebenfalls im Pflichtenheft eingepflegt werden. Erst wenn der Kunde das Pflichtenheft frei gibt darfst du die Änderungen umsetzen. Um das Einholen der Freigabe muss sich der Projektleiter kümmern. Also so kenne ich das. Entwickeln per EMail und Buschfunk ist Harakiri. Viel Spaß beim nächsten Audit.
A. S. schrieb: > Tickets. Bei mir Track/SVN Wir haben hier Redmine. Funktioniert gut um zuzuweisen wer was macht. Wo es nur um mich selbst geht wird's schon etwas umständlich. Um Entscheidungen für mich zu dokumentieren fehlt mir die Phantasie wie das praktisch funktionieren soll.
Dirk K. schrieb: > Jetzt, beim einem Unternehmen welches in die obige Kategorie passt und > ich eine Vorgesetztenfunktion inne habe, reicht nicht mal mehr One Note. An dem Punkt bin ich nun auch angelangt, daher die Frage.
Dr. Best (Jetzt neu mit Zucker) schrieb: > Nach welchem Modell entwickelt ihr denn? V-Modell? Oder agil via > Sprints? Kommt auf das Projekt draufan, aber meistens chaotisch und behaupten das wäre "Scrum" ;) > Der Ort an dem alle Infos zusammenfließen Müssen: > Pflichtenheft! (Egal ob Word Dokument oder per R4Jira). Deine Aufgabe > ist es dieses Dokument mit dem aktuellen Entwicklungsstand zu befüllen. > Änderungswünsche aus Besprechungen, Emails, Telefonaten müssen ebenfalls > im Pflichtenheft eingepflegt werden. Erst wenn der Kunde das > Pflichtenheft frei gibt darfst du die Änderungen umsetzen. Um das > Einholen der Freigabe muss sich der Projektleiter kümmern. > Also so kenne ich das. > Entwickeln per EMail und Buschfunk ist Harakiri. Viel Spaß beim nächsten > Audit. Das wäre wünschenswert. Aber wenn ich der einzige bin der das Pflichtenheft aktualisiert und es dem PM egal ist (oder er es sogar untersagt damit er nicht jede Änderung wieder absegnen gehen muss) hält sich der Nutzen auch für mich gering. Audit hatte ich bisher noch keines, aber natürlich immer wieder Personen die kommen um zu wissen wieso weshalb warum. Harakirientwicklung: durchaus. Leider sind die Kunden meist zufrieden damit, weil einfach für sie. Vielleicht muss ich da eh mehr Druck auf besseres Projektmanagement machen, hab ja sonst nichts zu tun...
Hail, Bill ! schrieb: > https://www.google.com/search?q=ISBN-13978-3-96010-365-3 Am Zeitmanagement hapert es nicht, da bin ich auch schon weiter als "Outlook".
Jan H. schrieb: > In meiner Idealvorstellung gibt es eine zentrale > Dokumentation So mache ich das privat. Eine einzige pdf-Datei enhaelt alle notwendigen Informationen Ich habe Templates fuer Pic-Controller und Arduinos.Selbst einfachste Projekte werden bei mir dokumentiert.Code kann man - wenn man will - als Datei anhaengen oder als pdf audrucken und in die Dokumentation mit einfuegen. Wer ohne Dokumentation arbeitet wird schon nach einem Jahr Probleme habe nochmal nachvollziehen zu koennen was man mal gemacht hat. Fuer die Dokumentation empfehle ich das kostenlose yEd(Flussdiagramm) und einen pdf-Editor (PDF-Xchange fuer den man allerdings einmalig mit 40€ zu bezahlen hat). Wer keinen professionellen pdf-Editor hat und mit irgendwelcher Freeware rumhampelt tut mir leid(reine Zeitverschwendung und viele nicht vorhandene Features).Man schmeisst genug Geld fuer chinesische Fakeprodukte zum Fenster raus,da duerften 40€ wohl nur "Peanuts" sein.... Im Anhang ein dokumentiertes Mini-Projekt
Hi, Wenn du die Lösung gefunden hast, dann kannst dich als Berater selbstständig machen. Wir nutzen auch diverse Tools. U.a. auch Jira und Confluence, Outlook und OneNote, Excel, SharePoint, Polarion, TFS, Doors. Jedes Projekt macht hier was anderes, neue Projekte sollen Jira und Confluence nutzen. Alles hat Vor und Nachteile. Zeitmanagement und Planung können alle. Aber die Frage war nach Entwicklertagebuch. Bei Jira kann man super Anhänge und Emails anhängen, aber wenn die Tasks geschlossen sind sind sie teilweise projektübergreifend schlecht zu finden. Vielleicht liegt es aber auch an unserer Jira Konfiguration. Ich bin zurück bei OneNote und wenn möglich werden die Ereignisse mit der Requirement-ID aus Doors oder dem Jira Task niedergeschrieben. Auch wenn ich kein Microsoft Fan bin, aber das ablegen von Emails in OneNote sowie due Aufgabensynchronisation von OneNote <-> Outlook geht gut. Und die Suchfunktion ist spitze. Viele Grüße
Klingt danach als ob es sich für dich lohnen würde zwei Dokumente zu führen: 1. Ein Entscheidungsprotokoll Das führst du Notfalls für dich alleine. Besser wäre es wird vom Team geführt. Noch besser wäre ihr hättet ein vernünftiges Aanforderungs- und Änderungsmanagement. In das Entscheidungsprotokoll kommt rein was wann wer verkündet / entschieden hat. Mit Links auf entsprechende E-Mails, usw. Das wird ständig fortgeschriebenen und muss gelegentlich gewartet werden. Dabei gehst du (oder das Team) alle dokumentierten Entscheidungen durch und markierst ob die noch gültig sind. Gelöscht wird nichts, nur markiert. Du kannst dir aussuchen ob du neue Entscheidungen immer an den Anfang schreibst (also die Einträge umgekehrt nach Datum sortierst) oder ans Ende (nach Datum sortiert). Ich bevorzuge umgekehrt nach Datum sortiert. 2. Eine Aufgabenliste Da schreibst du dir rein was du noch machen musst und warum, und was du schon erledigt hast. Also eigentlich zwei Dokumente in einem. In der Mitte gibt es einen Strich. Alles was über dem Strich steht muss noch gemacht werden, alles was drunter steht ist erledigt. Wenn diese Dokumente nicht reichen dann gibt es die große weite Welt der Personal-Productivity-Systeme. Dabei sind einige schon sektenähnlich. Der nächste Schritt wären Projektmanagement-Systeme. Nur bist du ja nicht der Projektleiter. Trotzdem, es gibt zum Beispiel Personal Scrum und Scrum of One. Da spuckt dir auch methodenmäßig niemand in die Suppe, weil du alle Rollen selbst ausfüllst :)
Jan H. schrieb: > Aber wenn ich der einzige bin der das > Pflichtenheft aktualisiert und es dem PM egal ist (oder er es sogar > untersagt damit er nicht jede Änderung wieder absegnen gehen muss) hält > sich der Nutzen auch für mich gering. Ich dachte, du wärst der PM. So schaut es anders aus: der macht also seinen Job nicht. Klar kannst du dagegen etwas versuchen, aber solange die Instanz darüber das nicht erkennt anhand: Jan H. schrieb: > Zwei Monate später kommt ein Programmmanager/CIO/... zu mir und fragt > mich warum ich die Luxuslösung implementiere und Geld verbrate, wenn wir > doch nur eine Minimalanpassung geplant hatten. ist die Aussicht auf Erfolg sinnlos. Jan H. schrieb: > Da habe ich dann gerne > halt auch die Info greifbar, wer welche Änderungen wann durchgesetzt hat > mit Referenz auf E-Mail/Agenda etc. Das ist also das Ziel: den eigenen Arsch an die Wand bekommen. Da tendiere Ich weiterhinzu One-Note und die entscheidenden E-Mails einfach reinschieben. Und nach Meetings eine Antwort auf die Einladung schicken, wie du es verstanden hast und das oder eine gegenteilige Antwort speichern. Schwierig. Dir viel Erfolg
Dirk K. schrieb: > Jetzt, beim einem Unternehmen welches in die obige Kategorie passt und > ich eine Vorgesetztenfunktion inne habe Herzlichen Glückwunsch zur Beförderung! Es sieht so aus, dass dein Arbeitgeber deine Arbeit wertschätzt, das freut mich ehrlich für dich.
Messtechnikexperte schrieb: > Holger schrieb: > >> Wenn niemand Doku liest braucht man auch >> keine schreiben. > > Eigentlich ist die Doku für dich gedacht, um deine Arbeit zu planen und > zu verfolgen. Eine Taskliste muss man zumindest haben. Projektdokumentation != Produktdokumentation Als Entwickler sollte man für PROJEKTdokumentation gar nicht zuständig sein, dafür gibt es 100%-Projektmanager. Wenn Projektmanager Teile der Projektdokumentation an Entwickler delegieren, dann sinkt die Entwicklungsleistung entsprechend. Wenn Entwickler bürokratisch ihre Arbeitsplanung dokumentieren sinkt auch die Bereitschaft, im Anschluss eine gescheite PRODUKTdokumentation zu verfassen über das, was sie tatsächlich entwickeln. Was wiederum erklärt, warum so viel weggeschmissen und neu entwickelt wird (liegt nicht an der Projektdokumentation).
Senf D. schrieb: > Herzlichen Glückwunsch zur Beförderung! Es sieht so aus, dass dein > Arbeitgeber deine Arbeit wertschätzt, das freut mich ehrlich für dich. Auch wenn es keine "Beförderung" im klassischen Sinne war: danke. Es wurde in einer anderen Abteilung eine solche Stelle neu geschaffen, ich habe das mitbekommen, mich intern beworben und wurde genommen. Holger schrieb: > Projektdokumentation != > Produktdokumentation > > Als Entwickler sollte man für PROJEKTdokumentation gar nicht zuständig > sein, dafür gibt es 100%-Projektmanager. Nicht zuständig - ja. Zuarbeiten - dennoch ja. Dies hier klingt eher nach einem Weisungsproblem: Jan H. schrieb: > Da wird beschlossen die Bestandslösung nur > minimal anzupassen, dann hat Person A die Idee eines kompletten > Redesigns, in Meeting B wird über eine Cloudlösung diskutiert, dann > kommt ein E-Mail ich möge die Architektur bitte doch komplett neu > designen. Das klingt so, als wenn dies verschiedene Personen waren. Interessante Frage: welche ist weisungsbefugt dir gegenüber? Selbst ohne die Antwort wäre folgendes denkbar als Antwort auf die E-Mail an Person B: "Person A hat minimale Anpassung beschlossen. Dies (komplettes Redesing) widerspricht dem. Bitte mit Person A abstimmen, was nun umgesetzt werden soll." Und das an die beiden senden. Sollen die sich doch darum streiten ;) So ziemlich diese Situation hatte ich im ersten Unternehmen. Person A war "Sprachrohr der GF" und erteilte mir Anweisung. Person B hat mit mir zusammen einen (alten) Fehler entdeckt und wollte mich anweisen, dass sofort zu korrigieren. Das habe ich verweigert und auf die Absprache mit Person A hingewiesen, da der abgesprochene Termin sonst nicht haltbar wäre (PCBs waren schon in Auftrag gegeben). Da Person A nicht erreichbar war, konnte Person B das nicht mit ihm absprechen. Blöd. Auf meine weitere Weigerung reagierte Person B sehr allergisch und drohte mir mit dem Chef. Ich habe dem zugestimmt. Person B zieht im Gespräch mit Chef massiv über meine Arbeitsverweigerung(!) her. Technisch habe ich der notwendigen Korrektur zugestimmt und auf das vom GF ernannte Sprachrohr und den abgesprochenen Plan verwiesen, den Person B nicht überstimmen kann aufgrund der Weisungsbefugnis. Chef hat entschieden, ich soll das korrigieren und Person A über die Verschiebung des Termins informieren. Man, mir ging echt der Arsch auf Grundeis, konnte aber cool bleiben. Das Ganze kam weder bei Person B noch beim Chef gut an. Waren halt Freunde. Merke: Recht haben und Recht bekommen sind verschiedene Dinge. Insofern ist solch eine Vorgehensweise mit Vorsicht zu genießen. Da muss man schon ordentlich dickes Fell haben und solche Dinge durchstehen können und sich nicht vor negativen Konsequenzen scheuen. Ich war danach halt als Querulant gebrandmarkt, auch wenn meine Kollegen das ebenso sahen. Den Querulanten habe ich dann weiter gemacht und die Unzulänglichkeiten der undurchsichtigen Weisungsbefugnisse regelmäßig aufgezeigt. Was habe ich gelernt: einen Chef kann ich nicht ändern. Wohl aber meinen AG... Fünf Jahre vorwärts: mein ehemaliger Chef ist nicht mehr Chef in der alten Firma. Und beim jetzigen Unternehmen habe ich "Querulant" eine Führungsposition. Ich fühle mich bis heute im Recht, vielleicht hatte ich sogar Recht ;) Das ist meine Erfahrung. Vielleicht hilft es dir :)
Holger schrieb: > Projektdokumentation != > Produktdokumentation > > Als Entwickler sollte man für PROJEKTdokumentation gar nicht zuständig > sein, dafür gibt es 100%-Projektmanager. kleinliche Auslegung von Worten. Natürlich ging es um das, was der Entwickler vor Augen ("pro ject") hat. Jeder Entwickler ist immer auch ein wenig ein Projektleiter: Ich sehe jede Aufgabe als Projekt, insbesondere, wenn sie umfangreich genug ist, dass sie Wochen oder Monate umfasst. Dazu gehört, dass man sich einen Plan macht, was man in welcher Reihenfolge zu tun gedenkt und wie lange das etwa dauern kann. Das ist nötig und machbar und hilft zu planen, wann man mile stones fertig haben wird - auch wenn es nur einzelne Stichpunkte sind. Teil dieses Planes sind auch die Schaltungselemente, die aufgebaut, getestet und ins Layout überführt werden müssen und dazu gehört wieder der Stand, also die Qualität der Schaltung und der Erfüllungsgrad der Anforderung, dass man entscheiden kann, ob man weiterentwickeln muss oder mit einem Zwischenstand leben kann. Aus qualitativer und quantitativer Füllung ergibt sich eine Prozentzahl, die man dem Hauptprojektleiter jederzeit geben kann um zu schätzen, ob die Gruppe als Ganzes noch im Plan ist und wer zurückhängt.
Holger schrieb: > Wieviel Prozent deiner Arbeitszeit werden dir explizit zum Lesen von > Doku zugebilligt? > Wieviel Prozent deiner Arbeitszeit werden dir explizit zum Verfassen von > Doku zugebilligt? Wenn mir ein Mitarbeiter mit akademischen Grad die Fragen stellen würde, würde ich davon ausgehen, dass er seinen Job nicht im Griff hat.
Obsidian.md oder Dendron.so als FOSS Alternative
Jan H. schrieb: > Hi, > mich würde interessieren wie ihr den Überblick über den aktuellen Stand > eurer Projekte behält. > Habt ihr da einen effizienten Ansatz dafür, ev. auch eine geeignete > Softwarelösung? Würde mich über eure Ideen dazu freuen. Stift und Papier. Wer schreibt der bleibt.
Hallo WD, Walademir Putiniewski schrieb: > Stift und Papier. > Wer schreibt der bleibt. Ernsthaft? Schonmal was von Digitalisierung gehört? Auf Papier verbringst du am Ende mehr Zeit mit Suchen nach/in Notizen als mit Arbeiten. ;) Mit freundlichen Grüßen Thorsten Ostermann
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.