Wahnsinn ist die Unfähigkeit, die Nähte zu sehen, die Delirium und Realität verbinden. Stephen E. King
Nachdem ich Ende des Jahres als Projektmanager interviewt worden war, traf ich viele Fragen, die im Namen von hr'ov und im Namen qualifizierter Spezialisten wie der letzte Quatsch erscheinen könnten. Natürlich ist jedes Unternehmen auf seine Weise seltsam, aber das Ziel einiger Probleme ist mir immer noch ein Rätsel.
Ein Projektmanager ist ein Spezialist, der immer im Kontext sein sollte. Es ist unmöglich, die Geschäftsziele und den Hintergrund ihrer Umsetzung ohne Fragen zu verstehen: Warum? warum? wie? Im Interview ist es das Ziel des Managers, durch Eingabe seines Kontexts eine klare Antwort auf die gestellte Frage zu geben. Deshalb versuche ich immer, nicht auf das „Spiel“ zu achten, das bei den Interviews anwesend ist, und auch bei den scheinbar dümmsten Fragen zu argumentieren.
Allen Managern ist bewusst, dass das Interview ein gemütlicher, stundenlanger Spaziergang durch das Minenfeld ist. Diese Aussage wird vom alten Managerfahrrad perfekt demonstriert: "Die erste Firma fragte mich, was ich tun würde, wenn das Team keine Zeit für die Veröffentlichung hätte. Würde ich das Team nach Überstunden fragen oder würde ich den Code selbst schreiben?" Ich antwortete, dass ich mich hinsetzen würde, um den Code selbst zu schreiben, und sie lehnten mich mit der Motivation ab: "Es wird bei uns nicht akzeptiert." Die zweite Firma stellte mir die gleiche Frage und ich antwortete, dass ich die Mannschaft bitten würde, Überstunden zu machen. Die anschließende Ablehnung dieser Firma wurde durch die Tatsache motiviert, dass dies nicht der Fall war. In der dritten Firma stand ich erneut vor dieser unglücklichen Frage, und die Antwort darauf war die Frage - wie ist es für Sie üblich? "
Deshalb habe ich speziell für die Leser von Habr die meiner Meinung nach interessantesten Fragen aufgeschrieben und beschlossen, die möglichen Antworten darauf zu analysieren. Fragen werden wahnhaft und vernünftig sein.
1) Sie haben ein Scrum-Team von Entwicklern und Testern. Entwickler arbeiten, bewerten Aufgaben in historischen Punkten und Tester in Stunden. Der Tester wurde mit der Programmierung der Taste beauftragt, weiß jedoch nicht, wie er die Verlaufspunkte verwenden soll. Wie erklärt man ihm die Methode zur Bewertung der von ihm zu verwendenden Aufgabe?Manchmal erreicht Scrum den Punkt der Absurdität. Bei der Beantwortung dieser Frage ist zu beachten, dass die Teams im Gedränge universell sind, aber in einem anderen Sinne des Wortes. Der Kontext in dieser Angelegenheit ist insgesamt nicht sehr wichtig. Sie müssen dem Mitarbeiter nur erklären, wie die Story Points berücksichtigt werden. Sie müssen seine früheren Aufgaben übernehmen, sie auf ein Blatt Papier schreiben und anbieten, sie mit der Fibonacci-Skala zu vergleichen, um ihm das eigentliche Konzept des Story Points zu erläutern: den Arbeitsaufwand * die Komplexität * die Risiken. Danach kann der Tester die Aufgabe des Entwickelns der Schaltfläche mit den in der Vergangenheit erledigten Aufgaben in Bezug auf die Komplexität und dementsprechend mit dem Wert in den Verlaufspunkten vergleichen.
2) Was soll ich tun, wenn ein Remote-Mitarbeiter die Leistung verloren hat?
Die abstrakteste Frage, die Sie stellen können. Die Unternehmenskultur und die Unternehmenswerte sind in erster Linie für die komfortable Arbeit des Fernfahrers verantwortlich. Wenn ein Unternehmen beispielsweise über eine qualitativ hochwertige Kommunikation verfügt und eine aktive gemeinsame Erörterung von Aufgaben und Problemen in einem praktischen Messenger ermöglicht, kann ein entfernter Mitarbeiter den Wert und den Einstieg in die Arbeit eines Teams und Unternehmens spüren. Wenn sich die Kommunikation auf einen Brief pro Tag beschränkt, fühlt sich eine Person nicht mit Kollegen verbunden . Auch wenn Aufgaben einfach zum Meister fliegen und monatelang zum Verkauf freigegeben werden, ohne dass Rückmeldungen und Erfolgsaussagen für jeden einzelnen Mitarbeiter vorliegen, fühlt sich der Mitarbeiter vom Team isoliert. Er setzt seine Stärke und seine Emotionen in seine Arbeit ein, erhält sie jedoch nicht als Antwort. In diesem Zusammenhang beginnt emotionales Burnout auch ohne Überanstrengung der Arbeit. Daher ist es notwendig, die Frage nicht zu stellen, warum der Mitarbeiter schlecht ist, sondern was seine Motivation dämpft, an seinen Aufgaben zu arbeiten und sie dann zu lösen.
3) Ein Mitarbeiter kommt täglich zu spät zu einer Besprechung. Was soll ich tun?"Er teilt nicht die Werte des Teams und des Unternehmens, warum brauchen wir einen solchen Mitarbeiter?" - Als ich einen solchen Satz von hr hörte und ich dachte, es lohnt sich wirklich, eine Person zu behalten, die 80 Kilometer vom Büro entfernt wohnt, geben sie ihm morgens keine Fernbedienung Er ist ständig zu spät für Staus um 9 Uhr?
Wenn ich antworte, meine ich bereits, dass Sie als Scrum Master oder Projektmanager dem Mitarbeiter zweimal erklären wollten, wie wichtig die täglichen Rallyes für die allgemeine Bewegung des Teams in Richtung des Ziels in einem kontinuierlichen Fluss sind.
Kundgebungen sollten zusätzlich zu den internen Regeln für effektives Verhalten Regeln für ihre Ernennung für ihren bequemen Besuch enthalten:
- Informieren Sie sich bei den Teilnehmern der Rallye über eine für alle günstige Zeit, vielleicht besteht für jemanden ein hohes Risiko, dass er 10-15 Minuten zu spät kommt, während derer die Rallye endet, oder die Teilnehmer der Rallye haben andere Zeitzonen, und jemand hat Ihre Zeit um 9:00 Uhr morgens in Moskau.
- Bereiten Sie einen Veranstaltungsort für Besprechungen vor, damit sich die Teammitglieder nicht von Besprechungen lösen, bei denen sie schreien müssen, um sich in der Mitte des offenen Raums zu hören.
Alle Menschen sind unterschiedlich - das ist eine Binsenweisheit. Jemand ist weniger organisiert, ein anderer mehr, wenn alle Voraussetzungen für eine bequeme Teilnahme an der Rallye erfüllt sind, aber ein separater, leicht organisierter Mitarbeiter dennoch nicht rechtzeitig zur Besprechung erscheinen möchte, können gewaltfreie Auslöser eingeführt werden, um die Motivation eines solchen Mitarbeiters zu steigern. Zum Beispiel:
- Um zu Beginn der Rallye ein wenig Dopamin zu verabreichen, indem Sie über einige Erfolge des Unternehmens oder der Abteilung berichten, jemandem zu den Erfolgen oder den Feiertagen gratulieren und über großartige Neuigkeiten in der Branche berichten. An zufälligen Tagen können Sie zu Beginn des Meetings einen kleinen Kuchen auf den Tisch legen (und warum nicht?).
- Spielen Sie das Spiel "Wer hatte keine Zeit - er war zu spät." Wer zu spät kommt - das führt Besprechungsnotizen aus, zum Beispiel die folgenden 2 Besprechungen. Auf diese Weise können Sie zu Beginn des Meetings ein Gefühl komischer Bosheit entwickeln und denjenigen, die pünktlich ankamen, bestätigen, dass ihr pünktliches Eintreffen das richtige Verhalten im Team und in der Firma ist.
- Vielleicht ist die Hauptsache, auf die Sie nicht zurückgreifen sollten, eine Geldstrafe. Gemäß der Arbeitsgesetzgebung der Russischen Föderation können Sie keinen Abzug vom Gehalt vornehmen, und die Motivationskomponente ist in der Regel niedrig genug, um den Mitarbeiter in die Tasche zu schlagen und ihn damit zu motivieren.
4) Unterschied zwischen Wasserfall mit Free-Wave und Scrum?Es ist nicht schwierig, diese Frage zu beantworten, wenn man ständig mit Methoden arbeitet. Bei Waterfall und Scrum geht es um Prozesse. Die Free-Wave-Methode ist eine Planungsmethode. Daher erhalten wir eine Trickfrage, in der die Incident-Wave-Methode eine unnötige Bedingung ist, und die Frage ist für Ihr klares Verständnis der Wasserfall- und Scrum-Methoden ausgelegt. Scrum ist ein iteratives Modell, mit dem Sie ein Projekt in Betrieb nehmen können, bis Sie die vollständige Menge an Anforderungen erhalten, in denen Sie die Produktanforderungen ändern können und der Iterationsprozess wiederholt wird. Wasserfall ist ein klarer Hinweis auf zukünftige Produktanforderungen, und eine Abweichung von diesen unterbricht die Prozesse. Und Sie können nach der Wave-Approach-Methode alles planen. Übrigens, wer auch immer etwas über die Trägheit des Wasserfalls sagt, aber selbst PMBOK verbietet nicht, Rolling Wave Planning damit zu verwenden.
5) Bei Rallyes im Stehen berichten einige Ihrer Kollegen dem Team nicht über die gestrigen Arbeitserfolge, sondern „melden“ sich bei Ihnen. Was soll ich tun?Um die Frage zu beantworten, sollten Sie die Situation auf sich selbst anwenden, wenn Sie nicht in eine solche Situation geraten. Um das Problem zu lösen, können Sie den Fokus der Aufmerksamkeit verschieben. Wenn Ihr Kollege über gestern spricht, schauen Sie sich einfach die anderen Teammitglieder an, und Ihr Kollege wird unwissentlich seinen Fokus auf denjenigen verlagern, den Sie gerade ansehen. Außerdem kann jedes Meeting seinen Standort zwischen Kollegen ändern.
6) Angenommen, der Mitarbeiter hat einen Manager + Vorgesetzten + 2 weitere Manager aus anderen Projekten (der Mitarbeiter arbeitet gleichzeitig an mehreren Projekten), und zwei oder drei seiner Manager haben ihm einmalig dringende Aufgaben gestellt. Was soll er beginnen?
Eine Frage aus der Kategorie eines mathematischen Problems: "Vasya kaufte 1000 Bananen ...". Und warum?
Bei solchen Hierarchien im Unternehmen sind Meinungsverschiedenheiten zwischen der Führungskomponente unvermeidlich, der Entwickler sollte sich in solchen Situationen nicht gönnen und in eine selbständige Zerlegung zwischen 10 Führungskräften geraten, deren Aufgabe vorrangiger ist, hierfür gibt es einen Manager seines Teams oder direkten Vorgesetzten.
7) Der Unterschied zwischen Teamleiter und Teamleiter?Offensichtlich ist der technische Leiter der mächtigste technische Spezialist. Mit einem Teamleiter wird es immer schwieriger, sobald die Position des Teamleiters nicht von Unternehmen zu Unternehmen interpretiert wird. Vielleicht ist dies eine der subjektivsten Besonderheiten in der IT. Angenommen, ein Entwickler kommt zu einem Interview und fragt ihn: "Was denkst du, was macht das Leitungsteam?" Und der Teamleiter des Entwicklers bei der vorherigen Arbeit leitete nicht nur das Team und war in diesen Teilen ein cooler Spezialist, sondern schaffte es auch, die Kaffeemaschine zu bedienen und Roadmaps für den Projektmanager zu zeichnen. Wer nicht fragt - jeder hat seine eigene Interpretation. Die einzige fundierte Antwort auf diese Frage lautet: "Zeigen Sie mir Ihre Stellenbeschreibungen für Teamleiter und Teamleiter, und ich werde Ihnen den Unterschied erläutern."
8) Wie kann man den Entwicklern den Wert von Baupunkten erklären?Wer auch immer etwas sagt, außer für Entwickler, die Hauptwerte der Gebäudepunkte sind die einfache Berechnung und die Einbeziehung von Risiken in diese Bewertung im Gegensatz zu einer stündlichen Bewertung. Bei der Bewertung mit Building Points muss der Entwickler nicht die Verpflichtung übernehmen, die Aufgabe beispielsweise in 2 Stunden zu erledigen, damit er unmittelbar nach Ablauf der Zeit beginnt, mit der Forderung nach dem Ergebnis zu ziehen. Die Zeit, die Sie in die Bewertung investieren, um eventuell auftretende Probleme zu lösen, ermöglicht Ihnen ein komfortables Arbeiten ohne unnötigen Stress und ständige Besuche des Managers mit der Anforderung, die Aufgabe zu übergeben.
9) Wie erklärt man den Entwicklern den Wert von Scrum?Als ehemaliger Entwickler kann ich eine ganze Ode an den Agile-Ansatz schreiben, einschließlich des SCRUM-Frameworks, da das Leben der Teammitglieder viel einfacher wird. Nehmen wir ein paar Punkte:
- Eine außergewöhnlich seltene Präsenz des Direktivenmanagements und nur in einer kritischen Situation. Das heißt, alle Aufgaben sind für den kommenden Sprint geplant, und theoretisch kann sie niemand ändern, in der Praxis kommt es manchmal zu höherer Gewalt, aber niemand ist davor sicher.
- Kollektive Verantwortung: Das Scrum-Team kann die Verantwortung für die Produktqualität nicht auf einen einzelnen Teilnehmer verlagern.
- Der Product Owner priorisiert nur Aufgaben im Backlog, verwaltet die Aufgaben des Teams jedoch nicht im klassischen Sinne. Das Team entscheidet in Zusammenarbeit mit dem Product Owner selbst, welche Aufgaben der nächste Sprint übernimmt.
Sie können viele Punkte über den Wert von Scram schreiben. Wenn die Hauptpunkte den Entwickler von Ihrem Team nicht überzeugt haben, können Sie auf die Meinung anderer Kollegen zu diesem Ansatz zurückgreifen. Beispielsweise hat einer meiner ehemaligen Kollegen diese Frage beantwortet:
„In Scrum-Befehlen werden Prozesse debuggt. Sie haben einen Sprint-Plan und in der Regel gibt es keine dringenden Direktiven-Push-Ins in der Form: "alles fallen lassen, neue dringende Aufgaben sind angekommen". Das Team überwacht das Timing und die Entwicklung wird vorhersehbar, Sie können planen. Aus diesem Grund haben aktuelle Aufgaben im Sprint nur wenige Sperren. Als Entwickler möchte ich, dass bei der Übernahme meiner Aufgabe alles bereit ist: Sowohl der Rücken als auch das Design werden gezeichnet. Keine Notwendigkeit zu rennen und andere zu schütteln. “
Wenn der Wert von Scrum immer noch nicht akzeptiert wird, ist das Lesen des Scrum-Handbuchs der letzte Ausweg. Und vielleicht hat Ihr Scrum-Team eine schlechte Entscheidung (Denken Sie darüber nach).
Zusammenfassend möchte ich Managern aller Fachrichtungen eine Empfehlung zum Verhalten während des Interviews geben - nehmen Sie jedes „Spiel“ als neuen Analysefall, da „Spiel“ häufig nicht nur in Angelegenheiten, sondern auch im Leben vorkommt und es dann im Laufe der Zeit für Sie sein wird Der relevante Satz lautet: "Wer auch immer mit der Uhr gearbeitet hat, lacht nicht über den Zirkus".
PS: Wenn Sie interessante Fragen zur Nachmittagszeit haben, hinterlassen Sie diese bitte in den Kommentaren!