Wenn Sie diesen Beitrag lesen, kennen Sie wahrscheinlich den Begriff „DevOps“. Der Begriff „DesignOps“ ist jedoch wohl nicht so geläufig. Sie können versuchen, DesignOps mit DevOps zu verbinden, um die Bedeutung zu entschlüsseln. Und Sie würden nicht ganz falsch liegen, aber Sie würden nur auf die Spitze des Eisbergs schauen.
Design Operations („DesignOps“) ist ein zunehmend wichtiger Bereich für Designteams, die ihren Teams helfen möchten, den Wert zu steigern, den sie für ihre Gastorganisationen und die Kunden dieser Organisation produzieren. Da dies ein aufkeimendes Interessengebiet ist, bestehen immer noch Unstimmigkeiten in der Verwendung von „DesignOps“, sowohl als Begriff als auch als Praxis.
In diesem Blogbeitrag präsentiere ich meine eigene Denkweise rund um DesignOps, die stark von den wachsenden Gesprächen unter Designkollegen von Organisationen wie Autodesk, Uber, Airbnb, Pinterest, Expedia und sogar Nicht-Technologieunternehmen wie CapitalOne, Royal Bank of Canada beeinflusst wurde (RBC) und GE.
Entwickler- und Designer-Tools sind nicht (immer) gleich
Wenn Sie ein Entwickler sind, programmieren Sie. Sie können Code in TextEdit oder Notepad schreiben und FTP verwenden, oder Sie bevorzugen Editoren wie Emacs und vi. Sie können dann damit beginnen, andere Tools wie eine IDE, Versionskontrolle oder Datenrepos hinzuzufügen. Und Sie können schließlich ein CI-System überlagern und Problemverfolgung und automatisierte Tests hinzufügen. Jede dieser Ebenen von Tools soll Sie als Programmierer verbessern und für Ihr Unternehmen wertvoller machen. Die Wahl der verwendeten Werkzeuge ist eine operative Entscheidung.
Betriebssysteme, die aus Prozessen, Praktiken und Tools bestehen – wie Agile, Projektmanagement-Software (JIRA usw.) sowie Ruhe- und Kollaborationsräumen – sollen Sie als Entwickler produktiver machen und dadurch Ihren Output verbessern. All diese Dinge zielen darauf ab, Sie in Ihrem Handwerk besser zu machen: Codieren.
