Pros
Tolles Produkt ohne Zweifel. Gutes Onboarding, um die Mitarbeiter mit dem Unternehmen, der Mission, den Produktdetails und den Gründen für Entscheidungen vertraut zu machen. Nach 2 Monaten werden Sie klar verstehen, woran und warum Sie arbeiten (auf Produktebene) und wie sich dies auf Menschen auf der ganzen Welt auswirkt. Anständige Entschädigung + mögliche Boni. Erfahrene Teammitglieder sind bereit, ihr Wissen und ihre Hilfe zu teilen. Allgemeine technische Diskussionstreffen über die iOS-Entwicklung und zwischen iOS- und Android-Teams, um alle zwei Wochen Wissen auszutauschen, helfen Ihnen dabei, Ihre Fähigkeiten auf die nächste Stufe zu heben.
Kontras
Jede Woche unzählige Treffen. In der Regel sind nicht mehr als 2 Stunden effizienter ununterbrochener Arbeit möglich. Ein bisschen besser in letzter Zeit mit (fast) "freien Tagen für Meetings" montags und freitags, aber immer noch das Wechseln des Kontexts ist ein großes Hindernis, um Dinge zu erledigen. Jira Flow besessener Manager mit vielen Tickets, die nur einen Titel ohne Beschreibung enthalten, weil: "Wir haben bereits darüber gesprochen, erinnerst du dich nicht?" und "Fragen Sie ein Teammitglied, wenn Sie es nicht bekommen". Es gibt auch "gefälschte" Aufgaben, die "echte" Aufgaben für einige Zeit in Sprints ersetzen (z. B. wenn etwas unklar ist oder von etwas Äußerem im Original abhängt). Aus meiner Sicht scheint es, als würde man einen guten Eindruck auf die Berichte hinterlassen. Zwei unabhängige Boards für Sprintaufgaben: eines in Jira und eines im anderen. Sondertreffen, um Aufgaben entsprechend den Erwartungen an ihre voraussichtlichen Daten auf das andere Board zu verschieben. Zuweisen dieser Aufgaben in der anderen, ohne Änderungen mit Jira zu synchronisieren. Manuelles Kopieren, das alle Sprintaufgaben von Jira auf die andere vor dem Meeting einfügt (tatsächlich wird dies von einem der Mitarbeiter durchgeführt). In der Apps-Entwicklung: großer Widerstand gegen Kritik oder Vorschläge zur Codebasis, wenn die Änderungen nicht vom Teamleiter stammen. Die Gründe sind normalerweise die folgenden: - Wir machen es so, weil wir es so machen. - Dieser war die Entscheidung des Teamleiters, niemand weiß warum, aber es sollte so sein. - Es mag auf den ersten Blick unklar sein [oder auf den zweiten], aber irgendwann werden Sie sich daran gewöhnen (wenn Sie es die ganze Zeit im Auge behalten können). Neue Leute gewöhnen sich schließlich auch daran. (In diesem Fall geht es speziell um die Benennung). Im Allgemeinen: großer Widerstand gegen jeden Vorschlag insgesamt mit einem Ergebnis wie: Vielen Dank für Ihren großartigen Beitrag, aber könnten Sie bitte vermeiden, ihn mit dem Team zu teilen? Andernfalls fühlen sie sich frustriert und haben den Eindruck, dass ihre Arbeit schlecht war / ist (jeder Vorschlag bestand aus einer Frage nach den Gründen für etwas, Erklärungen, warum es unpraktisch sein könnte und wie es verbessert werden kann). Mit all den guten Worten über "Tun Sie, was für das Team am besten ist" können Sie Ihren Teammitgliedern nicht gerne bei einer Aufgabe helfen, die bis zu 2 Monate dauern kann, während Sie sie in 2 Tagen lösen können, da Sie sich in der Vergangenheit damit befasst haben und sind sich möglicher Hindernisse bewusst. Alle 2 Wochen müssen Sie ein Retrospektivspiel spielen: - Wie können Sie den letzten Sprint in einem einzelnen Tweet beschreiben? - Wenn Sie auf eine einsame Insel gehen würden, welche Art von Gericht würden Sie mitbringen? Dies wird vom Teamleiter erzwungen, der nie daran teilnimmt und nur ein Beobachter ist. Es gibt auch nie ein greifbares Ergebnis. Glücklicherweise bleibt auch ein wenig Zeit für den echten Retro mit Problemen im vorherigen Sprint und Möglichkeiten, dies zu beheben. Es ist absolut unklar, was der Teamleiter außer der Teilnahme an Besprechungen tut. Manchmal Teilnahme an den technischen Diskussionen, aber wie: Dies ist meine Vision und es sollte so gemacht werden, weil es mir gefällt (in schöneren Worten ausgedrückt). Aus genau diesem Grund habe ich es persönlich vorgezogen, technische Fragen mit einem hochrangigen Teammitglied zu besprechen, das ein viel besseres Feedback gab und die richtigen Gründe für einige Entscheidungen / Vorschläge mitteilen konnte. Eine andere Sache ist über Erwartungen. Wenn Sie etwas tun, das dem Teamleiter nicht gefällt, erhalten Sie einen ähnlichen Dialog wie: TeamLead: Ich habe erwartet, dass Sie es so und so machen. Ich: Und genau so habe ich es gemacht. Sie können es hier und da überprüfen. TeamLead: Nun ... ja, aber es steckt nicht genug Eifer darin. Einzelgespräche sind völlig nutzlos. Zuerst erhalten Sie ein Feedback darüber, woran Sie arbeiten, was Sie reparieren und verbessern müssen. Später haben Sie eine Bestätigung über Ihre Verbesserungen erhalten. Am Ende erhalten Sie jedoch das Feedback, dass sich an der Vision des Teamleiters nichts geändert hat [ab dem Zeitpunkt des ersten Feedbacks]. Sie befinden sich also in einer Situation, in der Sie glauben, Ihre Arbeit verbessert zu haben und sich auf andere Dinge konzentrieren zu können, dies aber tatsächlich nicht getan haben. Bei Teamproblemen besteht eine große Chance, dass der Teamleiter Ihnen sagt: Ich möchte mich nicht darum kümmern, wenn Sie möchten, können Sie es selbst erledigen. (Dies ist eine tatsächliche Zitatantwort zu einigen Gesundheitsproblemen, die einige Teammitglieder betrafen und sich wiederum auf die Arbeit auswirkten, weil Menschen krank wurden.) Wenn Sie eine Beförderung wünschen (sagen wir von Junior zu Middle oder von Middle zu Senior), ist es besser, ein anderes Unternehmen zu finden. Hier wird das Management eine andere Person einstellen, anstatt Sie wachsen zu lassen (dieses winzige Detail wurde versehentlich entdeckt). Es gibt auch keine Erfahrung damit, Leute in verschiedene Abteilungen wechseln zu lassen (das wurde mir im Interview mit dem CTO gesagt).
