Ingenieur / Entwickler
Ingenieure und Entwickler sind das Rückgrat von Holistic Engineering Laboratories Ltd.. Sie entwerfen, bauen und warten die Systeme, die unsere Dienste antreiben. Ihr Fachwissen und ihre Hingabe fördern Innovationen und gewährleisten die Zuverlässigkeit unserer Produkte.
Regeln
Wenn Du für ein Thema eine Lösung erarbeitest, setze dabei immer auf die teuerste und komplexeste Lösung, denn was für Amazon und Google gut genug ist, sollte auch für Deine Firma gerade angemessen sein. Der Grundsatz "Keep it simple" ist nur für Anfänger. Die Komplexität kannst Du dann auch immer als Grund benennen, warum das Problem noch nicht gelöst ist, sondern man sich noch intensiver mit der technischen Seite der Lösung auseinandersetzen muss.
Wenn Du einen Workflow abbilden möchtest, benutze keinesfalls Standard-Workflows in Jira, sondern weise IT an, einen auf Deinen konkreten und sicher ganz besonderen Fall zugeschnittenen Workflow zu implementieren. Benutze dabei Status-und Resolution-Optionen möglichst inkonsistent und eine Terminologie, die sonst keiner versteht.
Arbeite auch bei einfachsten Tätigkeiten und Standardvorgängen mit möglichst komplexen Templates mit Checkboxen und Subtickets, idealerweise kombiniert mit der Notwendigkeit einer händischen Unterschrift. Achte darauf, dass das Ausfüllen dieses Templates mehr Zeit in Anspruch nimmt, als die Aufgabe an sich.
Wenn ein Sprint oder PI sich dem Ende neigt, stelle sicher, dass Du alle Tickets schließt, auch die, die noch nicht bearbeitet oder beendet sind. Damit stehst Du und Dein Team gut da. Du kannst dann auch für den nächsten Sprint/das nächste PI neue Tickets anlegen. Das ergibt eine wunderschöne Statistik und macht glücklicherweise keine verlässliche Aussage über den tatsächlichen Arbeitsfortschritt.
Mach aus jedem noch so technischen Task eine User Story, unabhängig davon, ob es hier überhaupt einen tatsächliche User gibt, und benutze dabei das Template "As a ... I want to ... so that ...". Falls Dir nichts passendes einfällt, kannst Du immer beginnen mit 'As a developer/architect/process owner ...'
Stell sicher, bei allen Entscheidungen mitzudiskutieren, wo Du keinerlei Expertise vorweisen kannst. Um dennoch kompetent zu erscheinen, bringe Argumente vor aus den Feldern Angst, Bedrohung, Zweifel oder Risiko(minimierung), (sogenannte FUD-Argumente).
Bei der Abschätzung von Arbeitsaufwänden sei maximal dynamisch: Benutze für jede Aufgabe eine andere Referenzskala, behalte aber die Benennung Deiner Maßeinheit gleich.
Halte Dich auf jeden Fall an das Motto DIY. Nutze keinesfalls vorhandeneTools oder Standardlösungen. Ein von Dir selbst entwickelte und nur von Dir wartbare Lösung garantiert Dir langfristige Arbeitsplatzsicherheit.
Von Dir als Ingenieur wird erwartet, dass Du Komplexität beherrscht. D.h., dass Du Probleme möglichst mit so komplexen Lösungen versiehst, dass selbst Du sie nach einiger Zeit nicht mehr verstehst, geschweige denn Kollegen oder Kunden. So beweist Du Deine Kompetenz am besten.
Klingt vertraut und dennoch merkwürdig?
Schau dir an, warum es diese Seite gibt – unsere Motivation und wie du damit arbeiten kannst in der Anwendung.