Rufbereitschaft - der Diskussionsthread

[Albi]

vor 7 Stunden schrieb Colamann:

Statt vier Leute auszuprobieren, hättet ihr ach den ersten zwei Jahre einarbeiten können. Hätte das gleiche gekostet, und meines Erachtens nach eine höhere Erfolgswahrscheinlichkeit gehabt.

Seh ich ähnlich, ziemlicher schwachfug jeden rauszuwerfen der nach 6 Monaten ein scheinbar komplett kaputt Programmiertes System nicht aus dem FF versteht, so wird das ja nie was. Wenn mein Chef das so halten würde, hätten ich und mein Kollege wahrscheinlich auch keinen Job mehr, wir arbeiten im Mainframe Bereich, mehr alte Technologie etc geht ja fast garnet und sowas dauert halt seine Zeit, zumal man da nicht alles mal schnell googlen kann und Millionen ergebnisse zu jedem Problem bekommt wie bei JAVA.

 

Wenn man so ein System hat und weiß das es kaputt is, es aber nicht auf die schnelle neu machen kann (was durchaus verständlich ist) weils zu viel Kosten und Aufwand ist und starke einbußen bedeutet, dann muss man halt etwas geduldiger sein, Leute mehr als nur 6 Monate einarbeitet. Mein Chef hat uns jetzt nach ca. 2,5 Jahren gesagt das er uns jetzt aus "ausgeblidet" sieht und wir einen Wissenstand haben mit dem er zufrieden ist und mit dem wir alles schon sehr gut alleine Schmeißen können. 

Und dann wenn man mehr Leute hat und die auf einem Stand sind, die Alten Hasen vielleicht auf eine mögliche Neuentwicklung ansetzt, die diesen Schei* wieder auf eine saubere Schiene bringen, so das bei späteren Einstellungen zum Neusystem vielleicht eure Traumvorstellung von Maximal 6 Monate Einarbeitungszeit auch Realtität wird.

Jedenfalls find ich es utopisch zu glauben, das jeder den man Einstellt ein Altsystem mit vielen verwüchsen und unsauberer Programmierung nach 6 Monaten gelernt sein muss und wenn es nicht klappt man sie schnell raushaut anstatt etwas mehr Vertrauen und Zeit zu investieren und dafür dann Leute zu haben die es können.

[Velicity]

Naja gibt ja durchaus immer wieder mal Leute die das hinkriegen und das auch häufig wesentlich schneller als 6 Monate. Es geht ja gar nicht so sehr, das ganze System auswendig zu kennen und alles zu verstehen. Das ist kaum möglich. Aber man muss sich an alles selbstständig rantasten können. Als Dienstleister mit vielen Kunden gehört nun einmal auch der Support dazu bzw. ist ein maßgeblicher Punkt.

Wenn der Kunde sagt es steht, dann kann man den eben schlecht sagen, sorry ich verstehe unser System selbst nicht. Dann muss man sich auch, wenn man mit dem System nix zutun hatte zumindest soweit lang hangeln können, dass man das Problem versteht und lösen kann. Kannst ja schlecht sagen, mit dem Part hatte ich persönlich noch nix zutun, da brauch ich noch ein halbes Jahr Einarbeitungszeit.

Wenn das nach einen halben Jahr noch nicht läuft, dann wird das auch in 20 Jahren nicht laufen. Es geht um die Herangehensweise. Ich habe heute noch mal mit ganz alten Projekten, Schnittstellen und Lösungen zutun, die weit weg von unseren aktuellen Core sind, von denen ich keine Ahnung hab. Trotzdem kann ich, wenn es deshalb beim Kunden steht, in 10-15 Minuten nachvollziehen was schief läuft und dafür sorgen, dass der Kunde weiterarbeiten kann.

Geht ja nur drum bei einem Problem oder generell im System zu verstehen, was die einzelnen Komponenten sind, wie die miteinander kommunizieren etc. pp. Sprich kapieren was für Schichten gibt es da, in welcher liegt das Problem und das immer weiter eingrenzen. Man merkt meiner Meinung nach schon deutlich unter diesen 6 Monaten, ob das was werden kann oder nicht. Wird aber meist trotzdem bis ans Ende der Probezeit gezogen. Ich hätte die Leute persönlich wohl schon nach der halben Zeit aussortiert.

Alternative ist dann eben, dass es immer an den selben Leuten hängen bleibt, was bedingt schon bei uns passiert, weil einige sich zwar über Wasser halten können aber trotz Jahrzehnten Erfahrungen mit unseren System bei komplexeren Sachen verloren sind. Klar hilft man den Leuten, sorgt aber dann auch dafür, dass trotz der Rufbereitschaft immer die selben 2-3 Kollegen bei jeden 2ten Problem dazu gezogen werden, was durchaus stressig werden kann, wenn man mal Pech hat und es nen paar Nächte in Folge vorkommt.

Ist dann natürlich auch nicht unbedingt fair gegenüber denen die fitter sind. Wir brauchen da halt einfach nen anderen schlag Leute. Sind hauptsächlich die jungen Leute die auch in ihrer Freizeit irgendwelche Hobbyprojekte umsetzen, sei es was mit anderen Programmiersprachen, nen Raspberry Pi, mal andere Betriebssysteme auf die Router klatschen usw. Wer häufig über den Tellerrand blickt, der lernt einfach sich in neue Sachen intuitiv einzuarbeiten.

Einstellen tun wir nun einmal wenn wir brauchen und Platz haben, weil z.B. andere in Rente gehen. Dann brauchen wir jemanden und zwar nicht in 3 Jahren, sondern möglichst gleich. Ja das System ist schrecklich und ja ich würde persönlich alles neu machen. Bedeutet dann aber auch nen Jahr arbeit, Frage ist wo kommt das Gehalt dann her, wenn man keine neuen Projekte umsetzt? Und nein hier und da Refactoring wird nicht helfen, da ist vieles schon von Grund auf falsch.

Wenn der eine nach 2 Monaten fit im System ist und der andere nach 6 Monaten nicht wie soll das laufen. Das ist erst einmal schon mal unfair gegenüber denen, die es sind, denn die Arbeit bleibt bei denen hängen. Und wie sieht es aus mit der Bezahlung. Derjenige wäre für mich persönlich dann eben mindestens 3 mal schlechter/langsamer, soll der nur 1/3 Gehalt bekommen? Vorteil wäre natürlich, dass derjenige dann keine Steuern zahlen muss 

Nein mal Spaß beiseite wir sind nun einmal ein Dienstleister und tüfteln nicht im stillen Kämmerchen oder im Keller an neuen Produkten. Da ist es einfach elementar, dass die Leute aktiv mitarbeiten können. Wie gesagt es geht nicht darum alles zu kennen und zu verstehen usw. Sondern die Hauptfunktionalitäten zu verstehen und sich in Sachen selbstständig einarbeiten zu können. Und das ist einfach eine Fähigkeit die nix mit dem Unternehmen oder dem System zutun hat, das liegt an der Person und was diese Person mitbringt.

[Graustein]

Wenn einer in Rente geht Nachwuchs zu holen ist imo eins der größten Probleme vieler Firmen. Da muss einer kommen 1-2 Jahre bevor ein alter Hase in Rente geht.

[hs1]

vor 47 Minuten schrieb Velicity:

Ja das System ist schrecklich und ja ich würde persönlich alles neu machen

Woran liegt es eigentlich, dass Systeme "schrecklich" werden? Schlechte Code-Qualität? Fehlende Vorgaben und keinerlei Prüfung des Codes? Keine Weiterbildungsmaßnahmen für die Softwareentwickler? Keine Planung, sondern "mach mal eben schnell"?

 

[Velicity]

vor 26 Minuten schrieb hs1:

Woran liegt es eigentlich, dass Systeme "schrecklich" werden? Schlechte Code-Qualität? Fehlende Vorgaben und keinerlei Prüfung des Codes? Keine Weiterbildungsmaßnahmen für die Softwareentwickler? Keine Planung, sondern "mach mal eben schnell"?

 

Nun groß Vorgaben, Prüfung oder Weiterbildung gibt es nicht. Planung halt je nach Größenordnung der Änderungen. Bin auch noch nicht ewig dabei, würde aber sagen einige schreiben ganz einfach grässlichen Code, zum anderen werden viele Probleme mit Workarounds und Pflastern gefixt. Wenn sowas dann 20 Jahre anwächst, dann ist das schon gruselig und erreicht dann ein Level, wo auch keiner an die Core Sachen mehr ran will, weil man damit 50 andere Sachen kaputt macht.

Weiteres Problem wird wohl gewesen sein, dass man die Programmiersprachen und Frameworks gewechselt hat aber möglichst ein Programm haben wollte, dass genauso funktioniert. Und auch genauso programmiert aussieht, was für die aktuellen Sprachen und Frameworks einfach nicht effizient funktioniert. Das Ganze damals wohl auch als Stück für Stück Umstellung, was manchmal einfach nicht klappen kann.

Viel ist sicher auch mach mal eben schnell. Haben hohe Stundenpreise, dafür gehen die Angebote mit wenigen Stunden raus. Sorgt dann dafür, dass es eigentlich immer Probleme gibt, die anschließend kostenfrei im Produktivsystem behoben werden.

Sehe aber eben auch die Probleme, sind schon etwas länger am Diskutieren für einen erneuten Wechsel, von dem was unter der Haube ist. Auch hier müsste man eigentlich von 0 anfangen, dafür auf Projekte verzichten. Das geht finanziell nicht, ergo wird auch das wieder ein riesiger Haufen Sche.. werden, weil diese Stück für Stück Umstellung einfach nicht vernünftig klappen kann. Das fühlt sich selbst bei Microsoft mit der Systemsteuerung und den Einstellungen mehr als unschön an. Ein 10-20 Mann Unternehmen, dass kundenspezifische Lösungen erstellt und das bei einem  kompletten System, bei wesentlich größeren Änderungen probiert (Sprache/Platform), das kann meiner Meinung nach nicht gut gehen.

Aber da kann man auch nicht viel diskutieren. Habe dazu im Unternehmen schon oft meine Meinung geäußert. Wie man das finanzieren soll wüsste ich aber auch nicht. Ist einfach ne Situation, bei dem das ganze System an Beatmungsmaschinen hängt und man diese nur weiter betreiben kann oder die Maschinen abschalten kann.

Klingt so aber sicher auch zu dramatisch. Konzentriere mich eben oft auf Sachen die nicht laufen und diese Ecken bei mir an. Läuft auch ne Menge super, Atmosphäre passt, die Leute kommen miteinander klar, mehre Kollegen sind seit Jahrzehnten da usw. Aber das System ist einfach zu einem ziemlich schwer zu wartenden Haufen gewachsen, den man nicht mehr entwirren kann. Und neu machen ist finanziell nicht drin. Habe aber schon viele Konkurrenzprodukte gesehen, da scheint mir das nicht viel besser zu laufen, ebenso sehe ich es immer wieder bei Schnittstellenpartnern.

Scheint bei großen kundenspezifischen Lösungen häufiger vorzukommen. Und bis man die Erfahrungen hat, weiß was schief gelaufen ist und was man ändern müsste, ist das wohl meist zu spät.

Bearbeitet 31. Dezember 2017 von Velicity

[Colamann]

Am 22.12.2017 um 08:02 schrieb Velicity:

Sehe da keinen schnellen Ausweg raus, außer den ganzen Laden umkrempeln, was anfangen würde bei kompletter Neuimplementierung des Cores, der über 20-30 Jahre gewachsen ist. Besserer Codequalität, Dokumentation, weniger Programmiersprachen um auch hier schon mal mehr Redundanzen zu haben und anschließend mehr Leute einzustellen. [...]

Das Ganze würde aber darauf hinaus laufen 1-2 Jahre im stillen Kämmerchen zu entwickeln, in der Zeit keine Projekte umsetzen zu können, womit keine Kohle reinkommt, ergo nicht möglich, sofern die Leute nicht umsonst arbeiten möchten und ihre Miete von Luft und Liebe bezahlen können.

Velicity hatte das vorher schon geschrieben. Gerade das mit den vielen Programmiersprachen klingt für mich nach "jeder macht, wie er gerade meint, hauptsache schnell".

Für mich klingt es so, als wären die Margen zu klein. Anscheinend reicht das Geld ja nur dafür, das überalterte Produkt soweit am Laufen zu halten, daß man es noch verkaufen kann. Das erinnert mich an meine Zeit in einer Agentur.

[Colamann]

Das geht hier leider gerade ganz schön off-topic. Aber ich fände es sehr interessant, dieses Gespräch in einem eigenen Thread weiterzuführen!

[Saheeda]

vor 2 Stunden schrieb Velicity:

Wenn das nach einen halben Jahr noch nicht läuft, dann wird das auch in 20 Jahren nicht laufen. Es geht um die Herangehensweise. Ich habe heute noch mal mit ganz alten Projekten, Schnittstellen und Lösungen zutun, die weit weg von unseren aktuellen Core sind, von denen ich keine Ahnung hab. Trotzdem kann ich, wenn es deshalb beim Kunden steht, in 10-15 Minuten nachvollziehen was schief läuft und dafür sorgen, dass der Kunde weiterarbeiten kann.

Geht ja nur drum bei einem Problem oder generell im System zu verstehen, was die einzelnen Komponenten sind, wie die miteinander kommunizieren etc. pp. Sprich kapieren was für Schichten gibt es da, in welcher liegt das Problem und das immer weiter eingrenzen. Man merkt meiner Meinung nach schon deutlich unter diesen 6 Monaten, ob das was werden kann oder nicht. Wird aber meist trotzdem bis ans Ende der Probezeit gezogen. Ich hätte die Leute persönlich wohl schon nach der halben Zeit aussortiert.

Für mich klingt das nach einem der Hauptprobleme für miesen Code. Wenn man immer nur "schnell-schnell" arbeiten soll und damit alles nur oberflächlich versteht, ist es fast schon vorprogrammiert, dass die eigene Lösung nur Gefrickel ist oder beim nächsten Husten ganz schnell andere Teile des Systems ins Wanken bringt.

Ich halte es für unmöglich, ein fremdes System in 15 Minuten soweit zu verstehen, dass man eine stabile Lösung einbauen kann.

[Velicity]

vor 3 Stunden schrieb Saheeda:

Für mich klingt das nach einem der Hauptprobleme für miesen Code. Wenn man immer nur "schnell-schnell" arbeiten soll und damit alles nur oberflächlich versteht, ist es fast schon vorprogrammiert, dass die eigene Lösung nur Gefrickel ist oder beim nächsten Husten ganz schnell andere Teile des Systems ins Wanken bringt.

Ich halte es für unmöglich, ein fremdes System in 15 Minuten soweit zu verstehen, dass man eine stabile Lösung einbauen kann.

Darum geht es auch nicht. Es geht nicht darum, dann fix das System umzuschreiben. Es geht darum, dass der Kunde nun erst einmal weiterarbeiten kann. Klar muss der Fehler, sofern es einer ist, vernünftig entfernt werden und das geht auch nicht in 15 Minuten. Alleine den Fehler nachvollziehen wird länger dauern.

Es gibt aber immer wieder klassische Sachen ala eine Exception innerhalb einer Loop, die nicht in dieser Loop gefangen wird, sondern außen. Von Hunderten von Sachen die innerhalb der Loop bearbeitet werden, funktioniert eine nicht. Muss auf dem Papier nicht einmal unser Fehler sein. Ggf. hat ein Schnittstellenpartner was falsch gemacht usw. Dann muss man da halt mal reinsteppen können, sehen dass es sich um so einen Fehler handelt, den einen Satz ggf. mal manuell überspringen, damit der Kunde arbeiten kann und sich dann in Ruhe darum kümmern, wie es zu dem Fehler kam.

An der Stelle ist aber nicht Zeit Stunden lang für Ursachen zu forschen oder ähnliches. In dem Moment hat der Kunde 40-50 Leute da, die ihre Hände in den Hosentaschen haben. Der muss erstmal wieder arbeiten können. Geht ja nur drum zu erkennen, die Sachen haben nix miteinander zutun, hier hätte wohl die Exception in der Loop abgefangen werden müssen, der eine Satz hängt, den umgehe ich manuell.

Ist halt nur ein Beispiel. Wie gesagt geht dann weniger darum das halbe Programm umzuschreiben, sondern nur Problem festmachen, sofern es zum Stillstand führt schauen ob es einen akuten Workaround gibt und dann gehts weiter. Viele sind dann aber ganz panisch, kennen den Teil des System nicht und rennen rum wie ein Huhn ohne Kopf. Der Kunde ist natürlich selbst unter Stress und ruft daher im 3 Minuten Abstand an etc. pp. Damit muss man halt umgehen können.

Hat wenig mit dem eigentlichen System zutun oder der einzelnen Komponente, das läuft imo bei jeder Komponente gleich. Problem festmachen, eingrenzen. Ggf. mal reinsteppen und schauen was los ist. Es gibt Leute die kriegen das hin und es gibt Leute, die kriegen das eben nicht hin. Soll ja nicht negativ gemeint sein, einige spezialisieren sich eben eher sind in einen großen Unternehmen und reichen andere Probleme weiter in andere Fachabteilungen usw. In einem kleinen Unternehmen ist man eben Mädchen für alles.

vor 5 Stunden schrieb Colamann:

Velicity hatte das vorher schon geschrieben. Gerade das mit den vielen Programmiersprachen klingt für mich nach "jeder macht, wie er gerade meint, hauptsache schnell".

Für mich klingt es so, als wären die Margen zu klein. Anscheinend reicht das Geld ja nur dafür, das überalterte Produkt soweit am Laufen zu halten, daß man es noch verkaufen kann. Das erinnert mich an meine Zeit in einer Agentur.

Das mit den Sprachen hat schon seinen Sinn. Da sind einfach mit der Zeit noch weitere Plattformen dazugekommen. Einige alte unabhängige Prozesse sind erstmal in C verblieben, während vieles als Stored Procedures in der Datenbank läuft, neue Desktopanwendungen sind in C# umgesetzt. Anschließend kamen immer mehr mobile Sachen dazu. Erst CE Geräte, die mit einer Webapplikation befeuert werden, anschließend auch Androidgeräte. Für was anderes wurden dann bei Androidgeräten eher hardwarenahe Funktionen benötigt, da ist dann auch Java dazu gekommen.

Aktuell würde ich aber zumindest die Windows und einige CE/Androidsachen persönlich zusammenlegen und als Webapplikation umsetzen. Alleine schon um weniger Sprachen im Team zu haben und mehr Leute zu haben, die im Zweifel daran arbeiten können.

[Albi]

Ich glaube jetzt gehts wirklich zu sehr ins Offtopic, vielleicht kann ein Admin das in einen eigenen Thread schieben.

[Chief Wiggum]

Moin und frohes Neues,

ich war mal mit der Schere tätig.

[Gast jajaschogut]

Am 31.12.2017 um 13:09 schrieb Graustein:

Wenn einer in Rente geht Nachwuchs zu holen ist imo eins der größten Probleme vieler Firmen. Da muss einer kommen 1-2 Jahre bevor ein alter Hase in Rente geht.

Das Geld will niemand in die Hand nehmen, selbst bei 100 Mio. Umsatz (Industrie) nicht. Als junger Hüpper will man neue Sachen sehen und machen, eine "Rentenablösung" würde ich nur machen, wenn schon Frau+Kinder (evtl. Haus) vorhanden und Arbeitgeber extrem (!) solide oder Öffentlicher Dienst.

 

Rufbereitschaft kann aber auch entstehen, wenn neuer Kollege sich einfach mit Themen nicht beschäftigen will, sei es aus Angst oder Faulheit oder oder oder. Sich den "VMware-Schuh" anziehen will nicht jeder, v.a. wenn einem der "$softwareverteilungstool-Schuh" schon zu gross ist, von Datenbanken oder Maschinensteuerung braucht man auch nicht anfangen. Ich rede hier nicht von 30,40 Jahre alter Versicherungssoftware in Cobol oder Prolog oder $whatever.

[Gast jajaschogut]

Am 17.12.2017 um 13:49 schrieb jajaschogut:

Für die drei Tage zwischen Weihnachten und Sylvester gibts dieses Jahr erstmalig eine Regelung, vorher hats der frühere EDV-Leiter für umme gemacht: 100eur/Tag und "wenns mehr ist als gut zureden", dann Zettel ausfüllen für Zeiterfassung.

War dieses Jahr ca. 5 Stunden, ein Drittel Endanwenderhändchen halten (Die Geschäftsführung hat Windows 10-2in1-Geräte bekommen, die werden sie aber zum grossen Teil wieder gegen ihre Win7-Laptop-Arbeitspferde tauschen), bissje Backupkontrolle, bissje VMware/Veeam.

Dieses Jahr muss ich vielleicht wieder ran, (sind ja nur 1,5 Tage), 2019 hab ich nen neuen Arbeitgeber.

es war 2016 halt viel ruhiger, das war vermutlich endlich mal Gelegenheit $Anwendungsserver umzuziehen/modernisieren, 2017 kamen halt unendlich viele neue Ideen auffen Tisch, die sich aber (teilweise gut sichtbar) in Luft auflösten, wie z.B. ein Druckerkonzept für drei Häuser mit mehreren Stockwerken, wenn dieses Jahr in ein Haus mit 1,5 Stockwerken umgezogen wird.

[ErB777]

Mal einen etwas "verstaubten" Thread aufgreifen:

Es steht in künftiger Zeit ein Arbeitgeberwechsel bei an. Vorstellungsrunden stehen an und paar sind bereits gelaufen.

In einem Gespräch ging es um die generelle Rufbereitschaft. Hierbei liegt die Rufbereitschaft ca. 1x Monat von Montag bis Sonntag, immer 8 bis 24 Uhr. Sprich, an Arbeitstagen von Montag bis Freitag normal arbeiten, dann zusätzlich nach Feierabend Rufbereitschaft sowie am Wochenende. Rufbereitschaft wird pauschal vergütet. Die Höhe der Vergütung wurde nicht genannt. Reaktionszeit 1 Stunde.

Da ich bisher nie Rufbereitschaft hatte (außer vielleicht an Arbeitstagen bis 18 Uhr erreichbar sein), würde ich gerne mal Meinungen und Erfahrungen zum Thema "Freizeit in der Rufbereitschaft" hören (lesen).

Wie regelt ihr eure Freizeit während einer Rufbereitschaft? Steht ihr häufig unter "Anspannung", dass ein Anruf kommen könnte und somit nicht wirklich entspannen könnt?

[Velicity]

@ErB777 Nun erstmal ist man natürlich in gewisser Weise örtlich gebunden bzw. muss fix Einsatzbereit sein. Das schränkt natürlich ein, 8-24 klingt aber noch human, bei mir ist die "Anspannung" eher, ob ich in Ruhe schlafen kann, da es bei uns dann 24/7 geht in der Woche, wo man dran ist.

Reaktionszeit ist natürlich auch so ein Thema, die ist bei uns je nach Kunde auch 1-2 Stunden. Natürlich gibt es dann Kunden, die das schnell eskalieren lassen. Sprich man steht 10 Minuten unter der Dusche und anschließend hat man einen Anruf vom Kunden, einem vom Chef, warum keiner an den Support geht und ggf. eskaliert das hoch bis zum GU.

Ebenfalls gibt es natürlich Wellen. Mal ist nix los, mal hat man 2-3 Fälle auf einmal, erreicht ggf. gerade einen Kollegen des Fachbereichs nicht, kann selbst wenig machen usw. Mal hat man ne Woche da ist so gut wie gar nix los, mal hat man ne Woche wo man quasi 2-3 Tage hintereinander so gut wie nicht geschlafen hat, das fällt bei dir dann ja Gottseidank weg.

Overall ist es gutes Geld für die Zeit, die man wirklich arbeitet. Eine gewisse Anspannung ist bei mir zumindest aber immer da. Denke das hängt aber auch stark von der Persönlichkeit ab. Der eine hat da ggf. die Ruhe weg, der nächste ist leicht gestresst und der nächste verfällt wieder in totale Panik in einigen Situationen.

Ansonsten finde ich auch morgens die Zeit, wo alle langsam Richtung Büro aufbrechen als stressig, wenn denn Fälle anstehen. Man selbst ist gerade unterwegs und häufig betrifft das auch so gut wie alle anderen Kollegen. Einiges kann man dann hier und da kurz mit dem Handy machen, oft geht das aber natürlich nicht. Je nachdem was dann steht und wie groß das Problem ist, hat man dann Kunden dann halt im zwei Minuten takt am Telefon.

Aber auffällig sind wohl immer die "schlimmeren" Situationen. Wie gesagt overall ist es gutes Geld für wenig Arbeit. Frequenz und was für Probleme und ob du jedes alleine lösen kannst, ob du andere Kollegen erreichst usw. kann natürlich stark abweichen von meinen Erfahrungen.

Generell sind das bei mir dann auch die "faulen" Wochen. Wo ich ggf. ne Staffel einer Serie am Abend schaue und auch mal eine Tiefkühlpizza in den Ofen oder Konserve in den Topf kommt, anstatt dass ich jeden Tag im Supermarkt stehe und den Kunden an der Kasse dran hab.

Wenn es feste Abläufe gibt durch Hobby und co. z.B. einen Verein, dann gibt es meist auch nen Kollegen mit den man sich den Ball da ein wenig hin- und herschieben kann. Sprich an den Tag schanzt man ihn im Fall des Falles eben was zu und er hat ggf. auch so einen Tag.

Bearbeitet 9. November 2018 von Velicity

[Showtime86]

Bei uns gibt es auch noch eine "Rufbereitschaft light", die teilen wir uns so auf, dass jeder von uns einmal im Monat macht. Montag-Freitag von 7-20 Uhr, Samstag von 7-14 Uhr und Sonntags gar nicht.

Wir kriegen dafür pauschal einen kleineren Betrag extra aufs Gehalt, ohne weitere Abrechnung bei Einsätzen. Da es aber noch ein Relikt aus alter Zeit ist und kaum noch Anrufe kommen, nehme ich den Bonus gerne mit.

Ich passe mich da auch nicht sonderlich in meinem Verhalten an, da in der Regelung nur drin steht, dass man am Telefon erreichbar sein muss.

[Funfare1337]

ich hatte immer ca. alle 5 Wochen eine Woche Rufbereitschaft. Es kam bei mir 2 oder 3 mal zu einem Anruf / Ausfall auf unserer Seite der wirklich aktiv behandelt werden musste. (Innerhalb eines Jahres!)

Daher hatte ich da absolut keine Anspannung oder mir groß Gedanken gemacht. Die einzige wirkliche Einschränkung war bezüglich Feiern/Alkohol und dass ich meinen Laptop stets in Reichweite haben musste. Reaktionszeit war 30 Minuten. Dafür konnte ich dann am nächsten Morgen später kommen, die Ruhezeit muss natürlich eingehalten werden.

Es kommt also sehr auf die Anzahl der Anrufe in der Rufbereitschaft an. Bei uns war die Anforderungen zum Kontakt der Rufbereitschaft sehr hoch. Es wurde nur angerufen, wenn das System komplett ausfällt oder einige kritische Punkte erfüllt sein (keine Zahlung möglich etc), wegen Kleinigkeiten durfte nicht angerufen werden.

Die Reaktionszeit sehe ich als recht human an, man darf sich da aber auch selber nicht den krassen Stress machen. Natürlich wollen die Kunden "sofort" eine Antwort und Lösung haben, aber sie zahlen halt auch nur für ne Reaktionszeit von 1h, also warum soll man sich dann selbst unnötig Stress machen.

Geh das Ganze einfach recht entspannt an, achte aber vorallem darauf dass du nicht wegen jeder "Kleinigkeit" angerufen wirst und dass du deine Ruhezeit einhalten kannst, alles andere Endet sonst in dauerhaften Anrufen und Ausbeuterei. 

[ErB777]

vor 39 Minuten schrieb Funfare1337:

Geh das Ganze einfach recht entspannt an, achte aber vorallem darauf dass du nicht wegen jeder "Kleinigkeit" angerufen wirst und dass du deine Ruhezeit einhalten kannst, alles andere Endet sonst in dauerhaften Anrufen und Ausbeuterei. 

Der Arbeitsplatz ist als IT-Systemadministrator ausgeschrieben und man ist Admin für die Kollegen sowie die Kunden. Rufbereitschaft gilt hier nur für den Kunden. Vergessen zu erwähnen. Da wird es mir nicht möglich sein, Kunden abzuweisen, weil dieser mich für einen Firlefanz anruft, den man auch in normaler Arbeitszeit angehen kann. ?

 

@Velicity

Es wurde auch bekannt gegeben, dass man mit dem Kollegen ohne Probleme auch die Woche oder einen Tag tauschen kann. Das finde ich gerade ganz passend, da ich quartalsweise Arztbesuche habe.

[neikei]

vor 9 Minuten schrieb ErB777:

Da wird es mir nicht möglich sein, Kunden abzuweisen, weil dieser mich für einen Firlefanz anruft, den man auch in normaler Arbeitszeit angehen kann.

Das lässt sich aus meiner Sicht nicht so pauschal sagen. Wenn dein neuer Arbeitgeber verschiedene Kunden hat, können die durchaus unterschiedliche SLAs bei deinem Arbeitgeber abgeschlossen haben. Kunde A hat beispielsweise den Premium-Service und darf auch außerhalb der Bürozeiten anrufen und Kunde B hat den Standard-Service und darf nur innerhalb der Bürozeiten anrufen.

Kleiner Tipp: Auch wenn du bei einem neuen Arbeitgeber anfängst und die Rufbereitschaft schon im Vorstellungsgespräch Thema war, würde ich immer dazu raten erstmal eine ruhige Einarbeitungsphase ohne Rufbereitschaft anzustreben. Wenn du dich dann sicher in deiner Arbeit und den Kundenumgebungen fühlst, kannst du mit der Rufbereitschaft beginnen. Am Anfang vielleicht auch noch mit einem Kollegen als Backup, den du bei Fragen erreichen kannst.

[tTt]

Ich bin bisher von Rufbereitschaften eher verschont geblieben, aber grundsätzlich verstehe ich Rufbereitschaften nur zur Notfallversorgung, wenn quasi gar nichts mehr geht. 

Vieles geht ja per Remote. Bei uns gibts nen 24/7 SPOC und die Kollegen der Hotline rufen bei noch zu definierenden Fällen uns in der Rufbereitschaft als 2nd/Last-Level-Support an. 

Teilweise eben auch zur weiteren Eingrenzung der Störung und Einschätzung der betrieblichen Auswirkungen. Nur bei kritischen Fällen sollen wir überhaupt angerufen werden. Was kritisch ist muss noch definiert werden.

Mein aktueller Arbeitgeber geht wohl dazu über, dass wir nur noch telefonisch und ggf. per Remote zur fachlichen Qualifikation und Eingrenzung herangezogen werden sollen und wenn Vor-Ort etwas bei den Kunden mit 24/7-Support zu erledigen ist, ein externer Dienstleister losgeschickt wird, der die eigens diagnostizierte Störung beheben soll.

Aber das ist derzeit noch in Planung, derzeit haben wir offiziell keine Rufbereitschaften. 

Ich hatte für das aktuell noch zu betreuende RZ mehrere Rufbereitschaften. 

Ich hab mich da aber nicht einschränken lassen und war schon malnicht Vor-Ort (war bekannt). Das hätte dann ein anderer Kollege übernommen, kam aber nicht dazu, es war kein Fehler in unserer Abteilung, sprich Fehlalarm. 

Aber grundsätzlich sollte man sich nicht allzu stressen wenn man Rubereitschaft hat. Man ist örtlich vielleicht nicht so flexibel, aber kann halt fast alles machen, außer alkohk, da ggf. örtlicher Einsatz mit KFZ bzw. beschwipst mit Kunden oder Dienstler telefonieren ist auch nicht so passend  

Letztlich ist die Frage nach dem Stresslevel abhängig von der in der SLA genannten Reaktionszeit. 

hab aber bisher immer nur Rufbereitschaften übernommen, wenn privat eher weniger geplant war. Hatte im Team bisher ganz gut gepasst. 

Stressig wars dann trotz Einsatz nicht.

Man sollte aber fachlich fit und die betrieblichen Abläufe kennen, bevor man die Rufbereitschaft übernimmt. Stimme @neikei zu: Erstmal gut einarbeiten vor Teilnahme an Rufbereitschaften.