Skip to content

Serverumzug für alle Domains

Wir sind seit einiger Zeit dabei unseren gesamten Server umzuziehen. Unser alter Provider wechselt das Rechenzentrum und machte uns als Alternative ein so deutlich teureres Angebot, dass wir uns entschlossen den Anbieter zu wechseln. In diesem Rahmen stellen wir noch einige andere Punkte um, die bisher teils noch akzeptabel waren, aber bei einer Neueinrichtung dann direkt mit geändert werden müssen. Wir haben bei allem so gründlich wie möglich vorab getestet und so sicher wie es geht sind wir dabei Schritt für Schritt vorzugehen. Da der Umzug nicht von uns geplant war, mussten wir uns an einen Zeitplan halten, den wir nicht selbst erstellen konnten. Einiges klappt wie gewünscht, manches dauert deutlich länger oder hat Konsequenzen, die vorab nicht erkennbar waren. Heute mittag ließen wir etwas umschalten, was an sich keine Auswirkung auf die Erreichbarkeit hätte haben sollen.

Alles weg nichts geht mehr

Doch plötzlich war keine Domain, kein Mail nichts mehr erreichbar. Ich kann nicht behaupten, dass sich solche Momente mag. Das Problem ließ sich in zwanzig Minuten lösen, in dieser Zeit war jedoch nichts mehr erreichbar. Ich hoffe, dass das der erste und letzte Totalausfall war. Allerdings kann ich das nicht garantieren, nicht alles lässt sich von uns so steuern, dass nichts schiefgehen kann.

Support des alten Providers hierbei

Als nichts mehr ging, klärte ich kurz ab, ob es an uns liegen kann, ob uns vielleicht ein Fehler unterlief. Das war jedoch nicht der Fall. Deshalb rief ich beim - bis vor kurzem besten mir bekannten - Support an. Tja, es wird Zeit zu wechseln: Am Telefon erstmal eine Warteschleife von rund zwei Minuten. Dann hatte ich einen Callcentermitarbeiter am Apparat: Ich sage: "Ich habe über vierzig vollständig tote Domains inklusive Mail" Er fragt: "Halten Sie das für so dringend, dass sich da in den nächsten 90 Minuten jemand drum kümmern soll?" Ich frage mich: "Nun was ist wohl dringender als alle Domains vollständig tot?" Ich sage: "Ja, selbstverständlich halte ich das für so dringend, dass sich das jemand in den nächsten 90 Minuten ansehen soll." Er sagt: "Nun, dann müssten wir Ihnen 79.- Euro für diesen Notfall berechnen." Ich antworte: "Ich bin mir sehr sicher, dass das nicht unser Fehler ist, aber in jedem Fall ist es jetzt dringend." Er fragt: "Kann ich dann bitte mal Ihren Namen, mindestens eine betroffene Domain haben?" Puh! Kaum hatte ich aufgelegt, bekam ich netterweise intern per SMS den Hinweis, dass es wieder geht. Ich rief also nochmal an und sagte, dass es sich erledigt habe. Ein großes und dickes Dankeschön an dieser Stelle an Dirk, Hampa und Ramon, die uns bei dieser Umstellung unterstützen! :) Diese Domain ist jetzt umgezogen worden...

Der ideale IT-Arbeitsplatz : Umfrage

  • Rechnermuseum im Schaufenster Rechnermuseum miradlo
Dirk fragte in einem Beitrag nach dem idealen Arbeitsplatz. Inzwischen gibt es einige Kommentare und darauf verweisende Beiträge, sowie von ihm selbst zwei Folgeartikel. Seinen eigenen Beitrag gibt's unter mein idealer Arbeitsplatz, sowie Gedanken zu einem Remote-Arbeitsplatz unter Arbeiten aus der Ferne. Wie immer bei solchen Themen habe ich zunächst nur den Einstiegsartikel gelesen, weil ich zunächst meine Sichtweise unbeeinflusst überlegen möchte.

Mein idealer Arbeitsplatz in der IT

Was mir wichtig ist, zeigt teils schon meine berufliche Laufbahn.

"Der ideale IT-Arbeitsplatz : Umfrage" vollständig lesen

Azubi-Ecke : online lernen und üben : IT-Handbuch für Fachinformatiker

Jozo, Auszubildender zum Fachinformatiker Anwendungsentwicklung im zweiten Lehrjahr arbeitet bei uns in den verschiedensten Bereichen mit. Darüberhinaus sind regelmäßige Schulungen zu den verschiedensten Themen selbstverständlich, sowie auch immer wieder die Teilnahme an Barcamps.

Abwechslungreiche Wissensvermittlung

Zu einer sinnvollen Ausbildung gehören meines Erachtens möglichst auch verschiedene Eindrücke und Wege sich Wissen anzueignen. Ein Teil, der dazu beiträgt sind eben Barcamps, bei denen sehr unterschiedliche Menschen zu Themen rundums Web Sessions halten. Jozo sieht mich ständig, erfährt, hört und lernt was in unserem Alltag an Tätigkeiten rundums Web so anfällt. Jedoch auch bei uns im Unternehmen soll möglichst nicht nur auf eine Art und von einer Person Information kommen.

Öffentlich Lernen

Roland hat sich daher von Anfang an vor allem um den Bereich Programmieren gekümmert. Roland und Jozo sehen sich zeitweise kaum persönlich, für einen regelmäßigen Austausch ist das zuwenig. Vieles an Kommunikation läuft bei uns über unser Mitarbeiterblog, doch manches wäre eventuell auch für andere Azubis oder Interessierte interessant. Deshalb führen die beiden einen Teil ihrer Kommunikation öffentlich in Rolands Schulungsblog, kleine Übungsaufgaben, die Schritt für Schritt das Programmieren vertiefen gibt es in der Kategorie Unterricht.

Zwischenprüfung

Die Zwischenprüfung vor kurzem, lieferte, ein aus meiner Sicht bedenkliches Ergebnis mit einem Durchschnitt von nur 64 von 100 Punkten. (Stand in unserer IHK-Region, wobei auch die anderen Ergebnisse weder in Baden-Württemberg, noch deutschlandweit berauschend waren. ) Auch Jozos Ergebnis lag weit unter seinen bisherigen Schulnoten und entsprach bei weitem nicht dem, was am Ende herauskommen sollte.

Theoretisches anhand des IT-Handbuchs

Um bei den theoretischen Kenntnissen sicherzugehen, dass alles irgendwann mal intensiver angesprochen wurde, kam mir die Idee es anhand des Buchs "IT-Handbuch für Fachinformatiker" anzugehen. Der Vorzug ist, Jozo hat die Papierversion, zum Lesen ganz sicher die beste Variante. Da das Buch jedoch auch als kostenloses E-Book zu haben ist, können Roland und ich regelmäßig nachsehen, welche Inhalte genau angesprochen werden.

Azubi-Ecke im Schulungsblog

Mit entsprechenden Rückfragen lässt sich so sicherstellen, dass Jozo in allen Bereichen fit für die Abschlussprüfung wird. Die einzelnen Kapitel fasst Jozo jetzt nach und nach zusammen, wobei wir jetzt für den Start mal einige Zeit eingeplant haben, in der weitgehend vom Alltagsgeschäft befreit ist und sich aufs Lernen konzentrieren kann. Die Zusammenfassungen und etwaige Kommentare stehen öffentlich in der Azubi-Ecke im Schulungsblog. Falls andere Auszubildende Lust haben, sich daran zu beteiligen, sind sie herzlich eingeladen und können gern jederzeit kommentieren. Selbstverständlich sind die Kommentare dort auch für alle anderen offen, die Spaß dran haben sich zu beteiligen, seien es Interessierte oder auch Ausbilder.

Fazit?

Nein, hier gibt es noch kein Fazit, es ist eine Idee, ein Versuch, der mehr Spaß macht, wenn sich einige beteiligen. Ob sich das bewährt, sehen wir erst nach und nach. Speziell für Jozo denke ich, hat es den Vorteil, dass er jetzt täglich zumindest zwei völlig unterschiedliche Ansprechpersonen hat. Ich fände es prima, wenn sich mehr noch öffentlich abspielen würde, dann könnte ich auch mal noch öfter kommentieren, ohne dass es auffällt... ;-)

Nutzer von Open-Source in Unternehmen sind zufrieden mit der Software

In der  Studie von Heise, war die Fragestellung zur Open-Source-Software in Unternehmen, unterteilt in einige Schwerpunkte die ersten beiden sind die folgenden:
  • Welche Rolle spielt Open-Source-Software (OSS) in Unternehmen und Verwaltungen in Deutschland?

    • 40% der Befragten gaben an, dass Open-Source-Software sehr wichtig/unternehmenskritisch stark eingesetzt wird.
    • 43% schätzen die Rolle noch als wichtig ein
    • Damit bestätigt das andere Studien, die herausfanden, dass OSS in unternehmenskritischen Berichen ebenso genutzt wird, wie in weniger wichtigen Bereichen.
    • Hier gibt es klare Unterschiede in den Branchen: Während die IT-lastigen Branchen, sowie Gewerbe und Handwerk OSS auch stark (90%) in unternehmenskritischen Berichen einsetzen,
    • trifft das in den für Banken, Versicherungen, Verwaltung, Industrie und Sozialwesen nur zu 67 bis 75 Prozent zu.
    • Wird Open-Source-Software in kleinen Unternehmen (bis zu zehn Mitarbeiter) eingesetzt, so wird sie stärker auch in unternehmenskritischen Bereichen eingesetzt (49%), während dieser Anteil in den mittleren Betrieben auf 30% sinkt.
    • Entgegen den Gerüchten, dass OSS eher mal von Mitarbeitern getestet und genutzt wird, kam hier heraus, dass der Einsatz zu 95% der Inhaber und Geschäftsführer für wichtig gehalten wird; noch mit über 80% sehen das die IT-Leiter so.
Für mich kam es unerwartet wie häufig OSS sogar in unternehmenskritischen, also den wichtigsten Bereichen eines Unternehmens eingesetzt wird. In meinem direkten Umfeld sind wir mit miradlo doch eher allein, als ein Unternehmen welches nahezu ausschließlich mit Open-Source-Software arbeitet. Aus meiner Sicht war es eine logische Konsequenz aus den Erfahrungen vor Unternehmensgründung, dass es auch hier nur mit OSS funktionieren kann. Mein Interesse galt bereits während des Studiums verstärkt der Open-Source-Software und auch der Bewegung Open-Source als solcher. Unter anderem habe ich mich in einem Projekt damit befasst, inwieweit Managementtechniken auch in diesem Umfeld genutzt werden und falls ja mit welcher Software. Damals war das Ergebnis, dass Open-Source grundsätzlich anders funktioniert und abläuft und somit nur sehr bedingt vergleichbar ist.
  • Wie zufrieden sind Unternehmensanwender mit OSS?

    • 49% der Befragten sind sehr zufrieden
    • 48% der Teilnehmer sind zufrieden mit der eingesetzen Open-Source-Software
    • weniger zufrieden sind nur zwei Prozent und nur eine Person ist unzufrieden
    • Auch in anderen Studien konnte bestätigt werden, dass rund 90% der Nutzer zufrieden sind mit OSS.
    • Ähnliche Werte ergeben sich bei der Frage nach dem Reifegrad von OSS, dieser wird zu über 80% als gut bis sehr gut bewertet.
    • Die Zufriedenheit steigt, je stärker OSS eingesetzt wird.
    • Das steht in klarem Gegensatz zu den Zahlen für lizenzpflichtige Software, dort sind nur 44% zufrieden oder sehr zufrieden mit der Software.
Auch hier hatte ich kein solch deutliches Ergebnis erwartet. Klar, wir sind nach jahrelangem Umgang und mit entsprechendem Wissen zufrieden mit unserer eingesetzten Software. Dass das jedoch ebenso selbstvertändlich für fast alle Nutzer von Open-Source-Software gilt, finde ich schon sehr erstaunlich. Insbesondere beeindruckend ist das in Anbetracht dessen, dass selbiges für die Anwender von lizensierter Software nur zu 44% gilt. Für mich zeigt sich hier deutlich einer der Vorzüge von OSS, denn damit kann viel leichter ausprobiert und auch mal gewechselt werden. So muss man nicht bei einer Software bleiben, die einem nicht gefällt, weil sie halt bezahlt ist.

Studie zum Einsatz von Open-Source in Unternehmen

via Dirk wurde ich auf die Studie von Heise aufmerksam. Ausführlich auf zehn Seiten beschreibt Heise die Ergebnisse der Studie. Das Ergebnis ist erstaunlich und ich hätte es so nicht erwartet. Klar, muss man berücksichtigen, dass die Werte durch eine Befragung bei Heise und einem Unternehmen, Wilken, welches selbst mit Open-Source-Software arbeitet, entstanden. Sicherlich wären die Zahlen bei einer Umfrage des Spiegels oder ähnlichen Portalen nicht diesselben. Die Leser von Heise sind durchschnittlich interessierter an IT ganz allgemein. Hinzu kommt, dass sicherlich ein höherer Anteil derjenigen, die selbst Open-Source kennen, daran interessiert waren an einer Open-Source-Umfrage teilzunehmen. "Studie zum Einsatz von Open-Source in Unternehmen" vollständig lesen

Projektorganisation oder Matrixorganisation?

Immer wieder steht man als Firma oder Projektleiter vor der Herausforderung die Projekte sinnvoll aufzusetzen. Wenn die Mitarbeiter in der Matrixorganisation bleiben, und die Projekte sich die Mitarbeiter teilen, enstehen folgende Vorteile:
  • Wenn ich das Projekt in der Matrixorganisation betreibe ,gefährde ich den täglichen Betrieb nicht. Die Mitarbeiter sind in ihrer bestehenden Organisation und können schnell von einem Projekt zum Betrieb wechseln.
  • Mehrere Projekte können sich dieselben Mitarbeiter teilen. Die Mitarbeiter müssen nicht zu 100% von einem Projekt finanziert und betreut werden. Mehrere kleinere Tasks können gleichzeitig abgearbeitet werden.
  • Die Organisation bleibt stabil. Es gibt keine größeren Wechsel und die Mitarbeiter wissen über eine lange Zeit wo sie arbeiten.
Die Nachteile der Matrixorganisation für Projekte sind:
  • Viele Projekte benötigten dieselben Mitarbeiter. Der einzelne Mitarbeiter muss sehr schnell zwischen verschiedenen Projekten umschalten und verliert an Effizienz.  Im schlimmsten Fall kann der Mitarbeiter keine Leistung mehr bringen, da er permanent zwischen den Aufgaben wechseln muss. Dies führt zu Frust und schlechten Ergebnissen.
  • Bei strategisch wichtigen Projekten kann die Koordination innerhalb der Matrixorganisation dazu führen, dass der Projektfortschritt extrem gebremst wird.
Aus diesen, und natürlich noch vielen anderen, Gründen muss vor Projektbeginn nachgedacht werden welche Organisationsform zu wählen ist. Die Projektorganisation verursacht Unruhe unter den Mitarbeitern, da sie für die Projektlaufzeit nur für das jeweilige Projekt zur Verfügung stehen. Der Vorteil ist jedoch, dass sehr effizient und gezielt an einem einzigen Projekt gearbeitet wird. Je nach Zeitrahmen und Aufgabenstellung, kann es daher sinnvoll sein, eine Projektorganisation innerhalb einer Matrixorganisation zu etablieren.

Welche Prozesse müssen wirklich umgesetzt werden? ::: Managementprozesse

Wir haben vor kurzem wieder mal ein Projekt gestartet und wie immer kam die Frage auf, ob wir wirklich alle Prozesse durchführen müssen. Die Fragen waren:
  • Müssen wir ein proaktives Risikomanagement aufbauen?
  • Braucht es ein Changemanagement?
  • Ist ein Costtracking wirklich notwendig?
  • Wieso brauchen wir ein Stakeholder-Management?
  • Wer macht denn heute noch Support-Prozesse oder Incident-Management um Projekte an den Betrieb zu übergeben?
Wie immer gab es im Team mehrere Bestrebungen. Die Einen wollten am liebsten alle Prozesse aufsetzen und im Papierstapel ertrinken. Die Anderen wollten am liebsten gar nichts machen und einfach schnell mal das Projekt fertig stellen. Tja, da war also unser Dilemma. Entweder wahnsinnig viel schreiben, viele Protokolle erstellen, viele Dokumente unterschreiben und weiter leiten, oder schnell und schlank durchs Projekt schreiten und beim ersten politischen Rülpser unter die Räder kommen. Wir saßen also zusammen und stellten unsere Anforderungen zusammen. Wir wussten, dass dieses Projekt politisch nicht leicht werden wird. Es ist ziemlich dick und wir müssen viele Mitarbeiter an verschiedenen Standorten koordinieren. Das schreit nach viel Prozess, Planung und Koordination. Aber wie immer haben wir nicht viele Mitarbeiter, die uns beim Planen und Koordinieren helfen können. Das kostet Geld und ist für die Auftraggeber ziemlich nervig. Stellt euch vor ihr zahlt für den Umbau eurer Wohnung 10.000€ und davon für die Projektleitung 7.000€. Das würde euch sicher gefallen oder? Wie etwa nicht? ;) Und da hat einer von unseren altgedienten Projektleitern eine super Aussage gemacht:
  • Du kannst jeden Prozess weglassen.
  • Du kannst in deinem Projekt auf alles verzichten.
  • Mit jedem Prozess den du weglässt erhöht sich lediglich dass Risiko.
Und so haben wir uns auf ein hoffentlich vernünftiges Maß der eingesetzten Prozesse geeinigt. Wir lassen diverse Prozesse weg, oder behandeln sie etwas stiefmütterlich. Andere Prozesse, die wir wegen der Eigenheiten des Projektes als wichtig ansehen, setzen wir komplett um. Den Rest machen wir mit unserem Bauchgefühl. Denn wie schon Tom DeMarco sagte, das wichtigste Organ des Projektleiters ist der Bauch. Also dann auf ins Projekt und vertraut hier und da eurem Bauch! Ich für meinen Teil kann da auf einen relativ dicken Teil meines Körpers vertrauen :( Viel Spaß beim Leiten!

Episode 10: Anforderungen mit Interviews aufnehmen ::: Softwareprojekte

In Episode 8 Vorstudie strukturieren habe ich ein Beispiel für den Aufbau eines Vorstudiendokuments beschrieben. So ein Dokument ist ja ganz nett, aber wie kriegt man da sinnvolle Daten rein? Hier ein paar Gedanken zu diesem Thema, wie man Interviews einsetzen kann.

Gute Idee ::: Stakeholder

Eine wirklich gute Idee ist es, sich mit den betroffenen Stakeholdern zusammen zu setzen und sie zu fragen was sie wollen. Damit das einigermaßen geordnet gehen kann, verwende ich meistens folgendes Vorgehen.

Vor dem Interview

Ich mache mir vor dem Interview klar, welche Anforderungen und welche Sprache der jeweilige Stakeholder verwendet.
  • Ein Betriebsmitarbeiter spricht sehr technisch und will vor allem verstehen welche Auswirkungen die neue Software auf seine übrigen Systeme hat.
  • Ein Auftraggeber hat Vorstellungen von dem was er will. Im Normalfall ist er nicht in der Lage die Vorstellungen in einer IT-geeigneten Sprache zu formulieren.
  • Ein Anwender kann, falls es sich um die Ablösung eines bestehenden Systems handelt, noch sagen was ihm daran gefallen und nicht gefallen hat. Er oder sie wird viele Ideen haben und keine Idee konkret formulieren können.
  • Ein Zulieferer wird sein System perfekt verkaufen und einem das Gefühl geben, alle Probleme der Welt auf einmal mit der neuen Software lösen zu können.
  • Ein Partner, der an das zu erstellende System angebunden werden soll, wird so wenig wie möglich Auswirkungen auf sein System haben wollen.

Zusammenstellen von Fragen

Für die jeweiligen Stakeholder stelle ich einen Fragekatalog zusammen. Im Interview kann ich somit das Gespräch etwas steuern. Wichtig ist hierbei, dass die Gesprächspartner nicht zu sehr von den Fragen manipuliert werden. Sie sollen immer noch ihre Wünsche und Ansprüche formulieren können.

Während des Interviews

Im Interview versuche ich die Erkenntnisse jeweils in grafischer Form aufzuzeigen. Ich erstelle grobe Systemübersichten, Business-Abläufe usw. Diese lasse ich mir im Interview von dem jeweiligen Stakeholder bestätigen.

Nach dem Interview

Nach dem Interview schreibe ich die Erkenntnisse in der Vorstudie zusammen und lasse sie vom Stakeholder nochmals gegenlesen. Hiermit können ziemlich viele Fehlinterpretationen direkt beseitigt werden.

Episode 9: Wann muss der Betrieb mit ins Boot? ::: Softwareprojekte

Immer wieder stellt sich bei Projekten die Frage, ab wann der Betrieb involviert werden soll. Der Betrieb hat im Normalfall nicht genügend Mitarbeiter, um in jedem anstehenden Projekt mitzuarbeiten. Auf der anderen Seite muss gewährleistet werden, dass das erstellte Produkt auch vom jeweiligen Betrieb verwaltet werden kann.

Thomas hatte sich die beiden Familien angeschaut...

...und sich den Betrieb genauer betrachtet. Im Fall von Hans, Karl und Orlando kann man nicht von einem klassischen Betrieb sprechen. Die drei sind Entwickler und Betreiber in Personalunion. Bei der zweiten Familie ist die Entwicklung und der Betrieb voneinander getrennt. Die Entwicklung erstellt ein Programm und übergibt es an den Betrieb. Eine vernünftige Dokumentation, wie das jeweilige Programm zu bedienen und warten ist, gibt es nicht. Wenn ein Fehler auftritt, handelt der Betrieb intuitiv. Wenn das nicht klappt, wird der Incident an die Entwickler übergeben. Thomas will bei der Neugestaltung der gemeinsamen IT die beiden Betriebe zusammenlegen und einen möglichst stabilen Betrieb aufbauen. Seine Überlegungen: „Wenn ich den Betrieb permanent mit in das Projekt einbinde wird die Stakeholderliste unnötig groß. Jeder will mitreden und an eine Weiterentwicklung der Software ist kaum zu denken.“ „Wenn ich den Betrieb erst kurz vor der Abnahme einbinde, ist die Gefahr extrem hoch, dass die erstellte Software nicht betreibbar ist.“ Was für ein Dilemma! Nach einigem hin- und her entschied sich Thomas für folgendes Vorgehen: „Ich lass den Betrieb bei der Anforderungsanalyse all seine Anforderungen, die zu diesem Zeitpunkt bekannt sind, formulieren.“ Bekannte Anforderungen können sein:
  • Bekannte Betriebssysteme, die von den Mitarbeitern verwaltet werden können
  • Monitor-Elemente, die gesetzt sind und die eingebunden werden müssen
  • Angaben, wie Projekte dokumentiert und Betriebshandbücher aufgebaut sein müssen
  • Angaben, wie Artefakte an den Betrieb übergeben werden müssen
  • ...
„Zusammen mit den Anforderungen der Kunden erstelle ich die Architektur und das Detailkonzept. Das Detailkonzept wird vom Betrieb überprüft und anhand der detaillierten Informationen kann der Betrieb genauer angeben, was er wirklich braucht.“ „Danach lasse ich den Betrieb erst einmal wieder in Ruhe.“ Zu diesem Zeitpunkt werden im...

Projekt vor allem die neuen Komponenten

erstellt. „Wenn ein testbares System vorhanden ist, muss der Betrieb wieder ran und kontrollieren ob alles für ihn in Ordnung ist.“ Zu testen sind hier
  • Stabilität
  • Auswirkungen auf andere Komponenten
  • Installierbarkeit
  • Konfigurierbarkeit
  • Performance
  • ...
„Weiterhin werde ich die Betriebsmitarbeiter während dieser Tests schulen.“ Hier ist die Gefahr hoch, dass die Zeit für die Schulung nicht ausreicht, um die Mitarbeiter wirklich für den Betrieb fit zu machen. Und da haben wir auch wieder das Dilemma. Entweder hat man über eine lange Zeit viele Mitarbeiter blockiert und dafür aber später gut ausgebildete Kollegen oder man kommt im Projekt schneller vorwärts und fährt das Risiko, dass sich die Betriebsübergabe verschiebt. Ich selbst glaube, dass es hier keine ideale Lösung gibt. Man muss sich für einen Mittelweg entscheiden. Wichtig ist jedoch, dass der Betrieb von Anfang an ausreichend informiert wird.
tweetbackcheck