In meinem Hauptprojekt arbeitet mein Redaktionsteam seit neuestem mit OTRS als Ticket-System.

Warum tun wir das?

  • Wir haben einen großen Arbeitsanteil an Support der Editoren unseres Confluence-Systems, damit ist ein solches Ticket-System sinnvoll.
  • Das Redaktionsteam ist gewachsen und Tasks werden stärker verteilt. Mit OTRS wird klarer, wer was tut bzw. in der Pipeline hat.
  • Unsere User können an ein zentrales Postfach mailen und damit ein Ticket im OTRS erzeugen, das sich dann idealerweise selbst verteilt.
  • OTRS wurde eigentlich primär für eine Hotline eingeführt, soll aber zukünftig als Service auch anderen Gruppen zur Verfügung stehen. Da wir die Inhouse-Dokumentation von OTRS unterstützen, ist es sinnvoll, auch selbst damit zu arbeiten.

(Mögliche) Nachteile der OTRS-Nutzung:

  • Es ist besser sichtbar, wieviele und was für Anfragen ein Team bearbeitet. Das möchte vielleicht nicht jedes Team.
  • Es ist nicht möglich, Tickets auf regelmäßige Wiederholung zu stellen (z.B. “alle vier Wochen Auswertung X”). OTRS ist auf Durchfluß optimiert, nicht auf Dauerpflege und langfristige Aufgaben. Solche Informationen haben wir daher im Confluence belassen.
  • Auch bei Verwendung von OTRS muss man als Redaktionsleitung regelmäßig prüfen, dass keine Tickets durchs Raster fallen und unbeantwortet bleiben.
  • Neue Prozesse müssen definiert und mit dem Team etabliert werden. Dies verursacht etwas organisatorischen Aufwand.
  • Unsere User müssen sich daran gewöhnen, statt direktem persönlichem Kontakt zumindest im Mail-Header mit OTRS die Mails auszutauschen. Manche interpretieren dies dahingehend, dass unserem Team das OTRS “übergestülpt” wurde – was nicht der Fall ist. Hier hilft nur Aufklären im Gespräch.

Bisher überwiegen die Vorteile für uns – und davon abgesehen ist es für Redakteure im Bereich der Softwaredokumentation gut, auch einmal mit Ticketing-Systemen zu arbeiten, da diese in Support und Entwicklung sehr häufig sind.

Für andere Redaktionsteams würde ich eine Empfehlung von OTRS daran festmachen, wie hoch der Supportanteil in der Arbeit ist. Für Verteilung von Dokumentations-Arbeitspaketen ist es aus meiner Sicht weniger sinnvoll, hier sollten eher klassische Projektmanagement-Werkzeuge eingesetzt werden.

 

Seit 2011 arbeite ich mit SNP Dragoman. Mit diesem Tool können SAP-Übersetzungen leichter durchgeführt werden, da über den Export nach Excel ein Austausch mit Übersetzungsbüros, aber auch eine leichtere Inhouse-QM möglich ist.

Dragoman gehört inzwischen zum SNP Transformation Backbone, daher ist es vermutlich in vielen großen Firmen jetzt lizenztechnisch leichter verfügbar als früher.

Meine Beiträge werden sich beschäftigen mit

  • Auswertungen auf Basis von SAP-Entwicklungspaketen.
  • Auswertungen auf Basis von SAP-Transporten
  • Analysen als Hilfsmittel für Übersetzungen mit der SE63/SLXT

Weiterführende Links:

SNP Dragoman Herstellerseite

Webinar von SDL Trados zu SNP Dragoman (Youtube)

 

Mrz 182013
 

Neulich las ich einen Artikel, in dem ausgeführt wurde, dass Best Practices oft das Festhalten an veralteten Standards und Ideen bedeutet.

Vielleicht bin ich ja so altmodisch, aber manche Standards, die sich in der Softwareentwicklung durchgesetzt haben, finde ich doch ganz sinnvoll.

Anbei einige Not-To-Dos aus meiner beruflichen Praxis.

  • Bei der Installation “das System ist Unicode-fähig” zu melden, ohne dies auch nur einmal getestet zu haben.
  • Bei Serverupdates direkt die Änderungen auf den Produktivserver einzuspielen, statt ein sauberes Staging über den Testserver mit Tests und Freigabe durchzuführen.
  • Bei Softwareupdates einen angeblichen Bugfix zu liefern, der sich als umfangreiches Update mit veränderter Oberfläche  herausstellt — und dann noch ohne aktualisierte Dokumentation, womit die neuen Optionen relativ nutzlos werden.

 

 

Neulich kam eine ungewöhnliche Anfrage rein – ein Styleguide und Dokumentationsberatung für eine in LaTeX geschriebene Systemdokumentation.

Mit LaTeX habe ich nur einmal zuvor gearbeitet, und dann damals mit Lyx, das dafür sorgt, dass man gar nicht erst der echten Syntax begegnet ;) Allerdings habe ich inzwischen zwei Jahre Docbook-Erfahrung, daher kann ich nach dem Lesen einiger Einführungen in LaTeX-Syntax zumindest grundlegend damit arbeiten.

Styleguides erstelle ich eigentlich regelmäßig, aber – das große Aber – normalerweise im Zuge der Dokumentationserstellung, also während ich selbst am Schreiben bin. Das ist mir erst jetzt bewusst geworden, dass ich ein Gefühl für die Materie brauche, bevor ich formale Dokumente zu deren Dokumentationserstellung schreiben kann.

Von dem her habe ich zu Übungszwecken den Styleguide selbst dann auch in LaTeX geschrieben. Und dabei gelernt, dass Tabellen in LaTeX-Syntax noch viel komplexer sind als in Wiki-Markup oder reStructured Text. Es ist halt nie handlich, eigentlich spaltenbasierte informationen in einen Zeilenfluß zu quetschen. Excel ist da definitiv einfacher, aber vom Vorschlag eines Kollegen neulich, man könne die Tabellen ja in Excel schreiben und dann einen Screenshot davon in die Dokumentation einbauen, kann ich nur dringend abraten. Zu schnell geht die Datei mit dem Original der Tabelle verloren, so daß zukünftige Generationen an Bearbeitern dann mühsam die Tabelle neu abtippen müssen.

Meine Installation auf Windows 7 besteht übrigens primär aus TeXMaker und MikTeX. Bei letzterem sollte man einstellen, dass fehlende Pakete auf Nachfrage nachgeladen werden. 

 

Zwei Lesetipps für das aktuelle Heft 3/12 der technischen kommunikation(*):

  • Praxistipps Word: Regelgerechtes Ersetzen auf S. 37 beschäftigt sich mit Regular Expressions aka Mustervergleich in der Word-Funktion Suchen und Ersetzen, der sich hinter dem Schalter “Platzhalter verwenden” versteckt.
  • Rechtschreibhilfen im Vergleich auf S. 45 bietet einen guten, wenn auch schmerzhaften Einblick in die Situation der Rechtschreibung in Deutschland, besonders auf die vielen gängigen/nicht gängigen//erlaubten/nicht erlaubten Variationen. Mein Bauchgefühl, dass das mit der Rechtschreibung immer weicher und dadurch definitiv auch schwammiger wird, wird hier voll bestätigt. Der Duden verliert dabei bei mir etwas – die Rechtschreibungsvorschläge von Wahrig und dpa gefallen mir tendenziell besser. Der Verlierer allerortens ist die Konsistenz; es ist schwierig genug, firmenspezifische Terminologie konsistent zu halten – wenn man dies auch noch mit dem “normalem Deutsch” machen muss, bläht es den hausinterne Redaktionsleitfaden (so vorhanden) reichlich auf.

“technische kommunikation” ist die Verbandszeitschrift der tekom e.V., dem deutsche Fachverband für Technische Kommunikation und Informationsentwicklung.

Mai 182012
 

Neulich habe ich mich im Büro ein wenig mit Eigenorganisation beschäftigt und bin dabei auf Personal Kanban gestoßen.

Besonders zwei Aspekte von Kanban finde ich interessant:

  • den Durchfluß möglichst gleichförmig zu halten und
  • die Zahl der in Arbeit befindlichen Tasks möglichst klein zu halten.

Unpraktisch finde ich bei Kanban (wie auch bei Scrum) die Notation von links nach rechts – sowas ist an einer Pinnwand ja ganz nett, aber in Standardsoftware auf einem Bürorechner schlecht abzubilden.

Da ich im Büro sowieso schon Outlook exzessiv für tägliche ToDos genutzt habe, kam ich auf die Idee, den Kanban-Workflow von oben nach unten im Kalender abzubilden. Der Screenshot zeigt die grundlegende Situation:

  • Zuoberst (Zeitraum 5-7 Uhr) stehen die ToDos, die ich an diesem Tag abarbeiten will.
  • ToDos, die in Arbeit gehen, verschiebe ich in den Zeitslot, in dem ich gerade bin.
  • Erledigte Aufgaben wandern in die Abendschicht.
Outlook-Screenshot mit Kanban-Workflow

Kanban in Outlook

Vorteile:

  • Ich habe immer einen guten Überblick über den Durchfluss und die Verteilung der Aufgaben.
  • Aufgaben in Arbeit blocken den jeweiligen Zeitpunkt im Kalender, so dass Kollegen bei der Terminvergabe eher rückfragen.
  • Am Ende des Tages habe ich eine Übersicht über alles Erledigte (früher habe ich sowas einfach gelöscht, dann zeigt nur der leere Kalender einen erfolgreichen Tag… nicht sehr motivierend).

Nachteil: Da alles über Outlook-Termine läuft, ploppen oft Terminerinnerungen hoch.

Aufgaben, die nicht erledigt werden konnten, verschiebe ich z.B. auf den nächsten Arbeitstag frühmorgens, d.h. in die nächsten ToDos.

Mein Fazit nach zwei Monaten mit Personal Kanban in Outlook – klappt super und ist eine sehr pragmatische Lösung für Kanban innerhalb einer Standard-Officeumgebung, in der man weder Software installieren noch ständig etwas im Internet pflegen will.

 

Die Änderungsverfolgung in Word ist ein schönes und gern genutztes Feature. Leider muss man sich normalerweise mühsam mit der Maus von Änderung zu Änderung klicken, um dann ebenfalls per Maus diese anzunehmen oder abzulehnen.

Diesen Vorgang können Sie enorm beschleunigen, wenn Sie die wichtigsten Funktionen der Änderungsüberarbeitung auf Tastaturbefehle legen. Dazu gehen Sie folgendermaßen vor (Beispiel Word 2003):

  1. Machen Sie einen Rechtsklick auf die Buttonleiste in Word und wählen Sie unten im Menü die Option Anpassen.
  2. Auf dem Fenster “Anpassen” klicken Sie auf die Schaltfläche Tastatur. Das Fenster “Tastatur anpassen” öffnet sich.
  3. Hier gehen Sie zur gewünschten Funktion, in unserem Fall unter Extras > ExtrasÜberarbeitungsMarkierungNächste.
  4. Klicken Sie ins Feld Neue Tastenkombination und drücken Sie die gewünschten Tasten, hier beispielsweise ALT+W. Die gedrückten Tasten werden angezeigt. In der Zeile “Derzeit zugewiesen an” können Sie prüfen, ob eein Konflikt vorliegt – in diesem Fall ist die Tastaturkombination bisher nicht zugewiesen.
    Tastatur anpassen
  5. Um diese Kombination zu speichern, klicken Sie auf Zuordnen. Die Kombination erscheint dann im Feld Aktuelle Tasten.
  6. Sie können jetzt weiteren Funktionen  Tastaturkombinationen zuordnen. Klicken Sie am Schluss auf Schließen.

Für die Änderungsbearbeitung verwende ich folgende Kombinationen, die meiner Ansicht nach am günstigsten dafür auf der Tastatur angeordnet sind:

Kürzel Funktion Name in Word-Auswahlliste
ALT+W Zur nächsten Änderung gehen ExtrasÜberarbeitungsMarkierungNächste
ALT+E Änderung annehmen ExtrasÜberarbeitungsMarkierungenAnnehmen
ALT+A Änderung ablehnen ExtrasÜberarbeitungsMarkierungenAblehnen
Jan 132012
 

Seit dieser Woche in meiner Leseliste: @iam_freelancer mit vielen Links zu Infos für (nicht nur, aber besonders) nebenberufliche Freelancer.

Da man auch als gestandener Vollzeit-Selbstständiger immer mal auf der Suche nach neuen Ideen und Inspirationen für das zukünftige Business ist – und sich gegenebenfalls auch alle paar Jahre mal umorientieren muss – kann ich diesen Tweet allen empfehlen, die sich mit Freelancing beschäftigen :)

 

Es gibt sicherlich sehr viele bessere Lösungen, aber manchmal sitzt man mit einem IE und einem Office-Paket da und braucht gaaanz schnell die Farbe eines Textes… und da habe ich heute dazugelernt, wie das auch gehen kann.

  1. Den zu analysierenden Text der Webseite nach Word kopieren (sowohl in Version 2003 als auch 2010 getestet).
  2. Auf ein Wort darin klicken, z.B. den blauen Link.
  3. Neben dem Button “Schriftfarbe” auf den Pfeil klicken und die Option “Weitere Farben” wählen. Farbwerte von Webtexten auslesen mit Word 1
  4. Im Farben-Fenster auf die Registerkarte “Benutzerdefiniert” klicken. Dort finden sich dann die RGB-Farben des Textes.
    Farbwerte für Webtexte mit Word auslesen
  5. Dies kann man dann in eine webtaugliche Farbe übersetzen, beispielsweise auf http://html-color-codes.info/.

Wie gesagt – keine schöne Methode, aber sie funktioniert schnell und mit typischen Großfirmenbordmitteln :)

Jan 072012
 

Nach nur wenigen Jahren habe ich endlich dieses Blog von WordPress-Version 2.6 auf 3.3.1 umgezogen. Im Zuge dessen habe ich auch einige Plugins entfernt und neue dazugeschaltet.

Beim Umzug bin ich folgendermaßen vorgegangen.

1) Lokale Installation auf meinem Rechner (Xampp existierte schon):

  • Kopie der Original-Installation lokal erstellen.
  • Produktive Datenbank exportieren. (Der WordPress-Export hat leider immer wieder Kommentare unterschlagen.)
  • SQL-Export bearbeiten, um alle URL-Angaben durch localhost zu ersetzen.
  • SQL-Datei lokal mit phphmyadmin importieren.

2) Der eigentliche Upgrade-Test:

  • Alle Plugins abschalten
  • WP3-Dateien ins Verzeichnis kopieren (alte Dateien damit überschreiben).
  • wp_admin/upgrade.php aufrufen.
  • Ggf. Datenbankupgrade durchführen.
  • wp_admin aufrufen und prüfen, ob noch alles läuft.

Da bei mir lokal alles problemlos ging, habe ich das Upgrade dann auf dem Produktivserver durchgeführt, einige alte Plugins weggeräumt und die neuen eingerichtet. Es ging erstaunlich einfach.

So sehr ich Drupal für komplexe Projekte liebe, so wunderbar ist WordPress für kleine Blogs wie dieses hier.

© 2012 Doku-Hotline Suffusion theme by Sayontan Sinha