Kierując zespołem, czy jestem apodyktyczny?

Jestem w czymś, co wydaje mi się bardzo dziwną pozycją. Jestem „liderem zespołu” w roli dla konkretnego projektu, starszy inżynier oprogramowania na stanowisku. W moim zespole mam 4 programistów, z których jeden pełni podobną rolę w innym projekcie, ale teraz mój ma priorytet, więc pracuje nad moim. Mam również 2 testerów, z których jeden jest menedżerem. Kolejnym członkiem zespołu jest „Przedstawiciel klienta”, który jest częścią całkowicie niezwiązanego działu. Mam również menedżera, który jest bezpośrednio nade mną i uważam, że także ponad menedżerem testu, który jest częścią mojego zespołu ... chociaż nie jestem tego pewien.

Próbowałem wyjaśnić, dlaczego moja rola jest dokładnie kilka razy. Trudno mi było ustalić, gdzie zaczyna się i kończy mój autorytet, jeśli w ogóle mam. Odpowiedź, nad którą obecnie pracuję, brzmi: „jestem technicznym liderem” zespołu. Wydaje się to oznaczać, że mój autorytet jest ponad decyzjami technicznymi dotyczącymi architektury, projektowania oraz standardów procesów / kodowania, które dotyczą samego kodu produktu.

Dzisiaj coś się wydarzyło, a wyniki kodu, które przekazałem jednemu z członków mojego zespołu, zostały przedstawione reszcie firmy podczas naszego pokazowego spotkania Scrum. Przedstawiciel klienta popisuje się. Pokazano dziś coś, z czym naprawdę się nie zgadzam i nikt nawet nie zapytał mnie, czy chcę mieć coś do powiedzenia na temat tego, co się stało. Krótko mówiąc, w celu umożliwienia użytkownikowi wyświetlenia wartości w raporcie na następujące sposoby (jednostki „doc”, jednostki projektowe, zaokrąglone, nie zaokrąglone) zapewniły pola dostępu dla każdej permutacji. Tak więc mamy wartość w zaokrąglonych jednostkach doc, zaokrąglonych jednostkach projektu, zaokrąglonych jednostkach doc, niezaokrąglonych jednostkach projektu. Każdy rekord, z którym użytkownik będzie chciał pracować, ma wiele takich wartości i każdy z nich jest permutowany w ten sposób.

Naprawdę tego nienawidzę.

Osoby, które pokazaliśmy, chcą mieć pewność, że interfejs API, którego używamy do raportów, jest taki sam, jak sposób, w jaki robimy takie rzeczy, jak eksport danych do Excela. Niestety, teraz nabieramy tempa w kierunku, który moim zdaniem jest naprawdę bardzo zły.

Na następnym spotkaniu trochę mnie zdenerwowałem i zapytałem dwie osoby, które to zrobiły: „Dlaczego nie byłem zaangażowany w tę decyzję?” To jest problem, który wciąż się pojawia i mam trudności z tym, żeby po prostu wciągnąć ludzi do zespołu, który mam prowadzić, aby zapytać mnie, czy chcę się zaangażować. Czasami tego nie robię i myślę, że cokolwiek wymyślą, będzie dobrze. Innym razem to robię. Chyba, że ​​ludzie mnie pytają, choć trudno mi nawet wiedzieć, że dzieje się coś, co wymaga mojego wkładu i nie daje mi takiej możliwości.

Niestety, mój autorytet nie rozciąga się na mówienie ludziom: „Następnym razem, gdy pójdziesz sam i zrobisz coś takiego, nawet nie rozmawiając ze mną, będziesz dyscyplinowany”. To kwestia „PR”, która jest jednym z obszarów, który wyraźnie nie wchodzi w zakres moich uprawnień. Właściwie to mi nie przeszkadza, ponieważ nie chcę zajmować się tego rodzaju gównem, jeśli ktoś inny chce.

Dziś jednak mój menedżer przed wszystkimi (które, jak sądzę, jest częściowo moją winą za takie wychowanie) powiedział mi, że nie mogę być zaangażowany w każdą decyzję i muszę delegować zadania.

Oczywiście myślę, że mam rację ... zawsze tak robię. Nie mówię rzeczy, które uważam za BS. Myślę, że powinienem zostać poproszony o tę kwestię i zapytany, czy mam lepszy pomysł. Moim kierunkiem było by po prostu zdecydowanie o JEDNEJ wartości, która jest teraz dostępna, ponieważ tak naprawdę były to bardzo początkowe etapy nowej funkcji i omówienie opcji zapewnienia dalszego dostępu w przyszłości, jeśli będzie to pożądane. Nigdy nie zatwierdziłbym ani nie zalecił obecnego wdrożenia i naprawdę nie sądzę, że powinien był ujrzeć światło dzienne.

Pytanie brzmi: czy to ja jestem nierozsądny?

Cóż, oboje rozmawialiśmy o tym i zgodziliśmy się, że oboje „upuściliśmy piłkę” i wydaje się, że jesteśmy na tej samej stronie. W poniedziałkowe poranki ... Postaramy się upewnić, że moja rola jest jasna w zespole i że tak, to ja decyduję, kiedy musi nastąpić zmiana projektu lub zadania; Dostaję propozycję i albo się zgadzam, albo decyduję, że muszę przyjrzeć się głębiej. Są też inne fragmenty, nad którymi mogę spróbować popracować, aby upewnić się, że wiedzą, że mogą do mnie przyjść.

Wygląda na to, że musisz monitorować zatwierdzenia źródła. Perforce ma tę umiejętność natywnie, Git ma ją przez haki, inni, na pewno, mają własne metody. Nie musisz dopracowywać każdego zatwierdzenia, ale przynajmniej powiadomienie i ich różnicowanie da ci krótkie spojrzenie na wszystko, co dzieje się w twoim projekcie.

Co do twojego menedżera mówiącego, że musisz delegować zadania, nie jestem pewien, czy zgodziłbym się - z zespołem czterech programistów powinieneś być w stanie to obsłużyć. W każdym razie mogę być po jego stronie (lub jej). Oczywiście, nawet w przypadku delegowanych zadań, powinieneś poprosić o aktualizację statusu lub omówienie zmian w projekcie itp.

Na spotkaniach nigdy nie powinno się wychodzić z niczego negatywnego - brzmi to tak, jakbyś ty i twój menedżer upuścili piłkę. Bezwzględna najgorsze, co można kiedykolwiek zrobić, aby peer to Embarrass nich. Jako lider (jak w przypadku swojego kierownika) musisz być przystępny i godny zaufania. Uśmierzanie kogoś doprowadzi do urazy, która osłabi twoją zdolność kierowania zespołem (a także doprowadzi do niezadowolenia pracowników).

Ja nienawidzę słysząc słowo „dyscyplina” od nikogo w roli głównej. Dyscyplina (przynajmniej w tym kontekście) jest negatywna i nieproduktywna. Należy z kimś współpracować (osobiście, a nie w miejscu spotkania), dowiedzieć się, dlaczego coś zrobił i zapewnić alternatywy, jeśli nie zgadzasz się z zaproponowanymi przez Ciebie rozwiązaniami. Czasami okaże się, że osoba, z którą pracujesz, ma rację, a twój instynkt jelitowy jest w błędzie. Dlaczego? Spędzili więcej czasu na tym konkretnym problemie niż ty.

Martwi mnie jeszcze coś: „Zawsze myślę, że mam rację”. IMO, to najgorsze z możliwych podejść. Państwo powinno oczywiście być pewni swoich umiejętności, ale uświadomić sobie, że jeśli nie jesteś głęboko w szyję specyficznego problemu, a nawet więcej razy, niż nie, wasze sugestie są wychodzi z tylnego (bez względu na to ile masz doświadczenia) i nie może być najlepszym. Jeśli ktoś, kto jest skoncentrowanie się na specyficzny problem stanowi alternatywę, to jest twoja praca (dobrze, jak ich, w zależności od swojego poziomu doświadczenia), aby udowodnić, dlaczego twój jest lepszy, a nie po prostu powiedzieć „Jestem ołowiu i Zawsze myślę, że mam rację ”, w co wierzy moje zdanie.

Podsumowując

Tak, w niektórych punktach jesteś nierozsądny, ale w innych nie. Jako potencjalny klient spodziewam się, że jeśli zostaną wprowadzone zmiany w architekturze lub architekturze, zostaną one przynajmniej przez Ciebie pominięte.

Jednak Twoim zadaniem jest również zapewnienie ogólnej jakości systemu i kodu, co musisz zrobić samodzielnie. Czy Twoja firma stosuje recenzje kodu? Czy programiści projektują to, nad czym pracują przed wejściem do kodu? Jeśli nie, możesz zacząć zastanawiać się nad zastosowaniem tego rodzaju mechanizmów kontroli jakości.

Być może jesteś sprawdzany pod kątem zarządzania, a jeśli tak, to się nie udaje (co może nie być złą rzeczą; wielu z nas jest dobrymi programistami i byłoby złymi menedżerami, a ja wolałbym programować niż zarządzać programistami).

Menedżerowie często nie mają uprawnień do wszystkiego, co powinni robić. I tak załatwienie sprawy jest oznaką dobrego menedżera. Musisz znaleźć sposoby na nakłonienie ludzi do robienia rzeczy bez podejmowania jakichkolwiek działań dyscyplinarnych. (Uwaga: publiczne dyskredytowanie ludzi nie jest. Chwalić publicznie, krytykować na osobności i okazywać zainteresowanie podwładnymi jako ludźmi).

Menedżerowie również muszą delegować zadania, nawet gdy boli. Prawdopodobnie spędzisz więcej czasu na rozwiązywaniu tego problemu niż na pisaniu go samemu i to jest w porządku. Kiedy już sobie z tym poradzisz, ludzie, którzy to zrobili, powinni byli się czegoś nauczyć i rzadziej będą robić rzeczy w niewłaściwy sposób w przyszłości.

Właściwy sposób radzenia sobie z czymś takim jest na osobności, najpierw pytając programistów, dlaczego zrobili to w ten sposób. Nie na spotkaniu i nie zakładając z góry, że masz rację i że się mylą (nawet jeśli masz rację i są w błędzie). Daj im szansę wyjaśnienia. To nie znaczy, że musisz podjąć decyzję; w końcu jesteś liderem technicznym. Oznacza to, że musisz podać im powody, aby zrobić to po swojemu, i powinieneś rozwiązać wszelkie podstawowe problemy, które pojawią się podczas tego prywatnego spotkania.

Ponadto menedżerowie ponoszą odpowiedzialność za to, co wychodzi od ich pracowników. Powinieneś starać się nie oślepiać niczym, co robią, szczególnie przed klientem. Może to obejmować śledzenie rejestracji kodu lub szybkie mini-konferencje ze swoimi programistami (chociaż musisz być ostrożny, nie chcesz ich przerywać, gdy znajdują się w strefie). Być może powinieneś porozmawiać ze wszystkimi programistami popołudniu przed spotkaniem z przedstawicielem klienta.

Nie bierz tego osobiście

To wysiłek zespołu. Twój lider techniczny, nie jedyny facet w projekcie. Powinieneś skupić się na tym, aby zespół uczył się na błędach lub na zmianie procesu.

Prowadź i ucz się

Częścią każdego stanowiska kierowniczego, w tym technicznego, jest zrozumienie, że robisz, co możesz najlepiej z ludźmi, których masz. Im więcej zespół współpracuje, tym więcej będzie wiedział, kiedy poruszać sprawy, a kiedy nie. Tylko upewnij się, że nie wpadniesz w pułapkę dyktowania swojej drużynie. Sprawdzaj, co poszło źle i co poszło dobrze co tydzień. Komunikuj się ze swoim zespołem, jeśli chcesz, aby działali inaczej. Środki karne powinny zawsze być ostatecznością i zwykle oznaczają, że albo musisz kogoś zwolnić, albo zawiodłeś w swojej roli.

Przejrzyj przed prezentacją dla klienta

Jeśli prowadzisz projekt, dlaczego nie zapoznałeś się z funkcją i implementacją przed jej prezentacją?

Jeśli to źle, napraw to

Wyjaśnij jasno, dlaczego coś jest nie tak i zmień to. Jest droższy, ale jeśli to rzeczywiście źle, napraw to. Jeśli nie jest źle, po prostu inaczej niż chciałeś, aby rzeczy były zrobione, to znowu; zrozum, że nie jesteś jedynym pracującym nad projektem.

Czy była jakaś specyfikacja dokumentująca, co powinno zostać zaimplementowane? Biorąc pod uwagę zbyt otwarty koniec, deweloperzy często wypełniają puste pola (lub wymagają mikrozarządzania) tym, co uważają za stosowne.

W efekcie trafiasz do swojego menedżera z komunikatem „Więc zamiast pracować nad tym, co jest w specyfikacji, postanowili zamiast tego zrobić [funkcja]. Teraz jesteśmy z tyłu, z powodu funkcji, która nie została zatwierdzona w pierwszej kolejności”.

Następnie możesz zacząć pracę nad wyszorowaniem tej funkcji, gdy deweloperzy zostaną ponownie przypisani.

edytuj> I nie, nie sądzę, że jesteś apodyktyczny. Ich praca kończy się na twoim tyłku.

Często znajduję się w tej samej pozycji i wydaje się, że nigdzie nie dochodzę do tego na spotkaniach i dyskusjach. Czasami w ostateczności, zanim zrezygnuję z podjętej decyzji (albiet nie moja), wysyłam do odpowiednich stron wiadomość e-mail z czarno-białym uzasadnieniem.

Następnie zarchiwizowałem ten e-mail, więc upewniam się, że mam go na przyszłość, na wypadek, gdyby był potrzebny później, gdy kierownik lub klient zapyta, dlaczego coś zostało zrobione w ten sposób lub dlaczego zmiana kosztuje tyle kosztuje.

Uważam, że niesłusznie mówiłeś o tym w sposób, w jaki to zrobiłeś, jak przyznałeś. Nie mylisz się twierdząc, że powinieneś mieć pewien wkład w projektowanie na tym poziomie, ale nie jestem pewien, jak spodziewasz się, że wdrożenie będzie rozsądne. Ludzie nie zamierzają uruchamiać twojego projektu, jeśli uznają go za prosty; ponieważ mogą równie łatwo się mylić, mówiąc, że jest to proste, jak w przypadku samego projektu, nie znajdziesz ludzi chętnych do pokazania wszystkich swoich złych projektów. W tym momencie jestem najbardziej ciekawy twoich nawyków pracy i wzorców komunikacyjnych, ale tak naprawdę, bez względu na to, jak to wszystko się robi, czasami będziesz po prostu ślepy na te rzeczy. Brak starannego sprawdzania każdego zatwierdzenia Nie jestem pewien, jak udowodnisz to.

Zbyt często czuję się tak emocjonalnie:

 I of course think I'm right....I always do. 

ale rozumiem intelektualnie, że czasami się mylę. Wiem też, kiedy wybrać walkę - nie można się o wszystko kłócić, a czasem nieoczekiwane porozumienie z twojej strony może zdziałać cuda.

Kim jest prawdziwy lider?

Czy ktoś może zwolnić podwładnego, każdego podwładnego. (ale nie trzeba zatrudniać nowego)

Czasami większość ludzi jest „oznaczana” jako lider jakiegoś projektu, ale bez siły ognia ktoś jest bardziej „przewodnikiem” / „nauczycielem” niż prawdziwy lider.

Ale znowu może się zdarzyć, że możesz być liderem zespołu, ale nie prowadzić obecnego projektu. W najgorszym przypadku klient prowadzi projekt. W tym momencie, jeśli projekt się nie powiedzie (i się nie powiedzie), to nie jesteś odpowiedzialny.

A najgorszym przypadkiem jest istnienie dwóch liderów projektu.

Jako wojsko łańcuchy dowodzenia są wszystkim (nie tak radykalne, jak „umrzeć za projekt”, ale wystarczająco blisko). W tej sprawie twój menedżer złamał twój status, obniżył moralność „twoich” ludzi i wcale nie pomógł.

Tak, twój szef ma rację - nie możesz brać udziału w każdej decyzji. W rzeczywistości niemożliwe jest złapanie wszystkiego takiego, chyba że zrobisz to wszystko sam. Myślę, że stąd pochodzisz - czujesz, że nie będziesz w stanie dobrze poradzić sobie z całym projektem, jeśli nie będziesz zaangażowany w każdy najmniejszy szczegół, ale nie możesz zaangażować się w każdy najmniejszy szczegół bez przytłoczenia cię (co całkowicie zdemoralizuje zespół i prawdopodobnie wypali cię).

Odpowiedzią jest, aby nie martwić się o rzeczy, które się nie udają - zawsze tak robią - zamiast martwić się o ich późniejsze naprawienie w konstruktywny sposób.

Jeśli będziesz na bieżąco z komunikacją, możesz nie tylko delegować zadania, ale także pozwolić swoim starszym osobom odejść i zrobić to, o czym wiedzą, że jest potrzebne, bez powstrzymywania ich od recenzji, dyskusji i nieudanych prób ich kontrolowania. Zaufaj im, aby postępowali właściwie i bądź na miejscu, aby porozmawiać o tym, co się dzieje, abyś mógł być na bieżąco (i wsuń nos, gdy poczujesz, że jest to naprawdę potrzebne).

Masz kilka problemów. Najpierw twój menedżer opowiedział się po stronie twojego zespołu i powiedział, żebyś delegował więcej. To pokazuje brak pewności co do umiejętności kierowania zespołem. To pokazuje, że chociaż masz tytuł lidera technicznego, w rzeczywistości nie jesteś nim, ponieważ nie masz autorytetu. Musisz usiąść ze swoim przełożonym i mieć to z serca do serca. Nikt nie może odnieść sukcesu na wiodącym stanowisku technicznym bez wsparcia swojego kierownika i bez upoważnienia do zmiany decyzji projektowych podjętych przez zespół bez jego zgody. Nie masz uprawnień do wykonywania swojej pracy. Twój szef musi zrozumieć, że nie jesteś w stanie wygrać i że musi udzielić ci publicznego poparcia, aby się polepszyło. Odpowiedzialność bez autorytetu to najgorsza możliwa sytuacja, w której można się znaleźć.

Następnie twój zespół cię oślepił. Musisz z nimi o tym porozmawiać. Powinieneś odbyć z nimi dyskusję projektową, zanim zrobią jakiś rozwój i na długo przed publiczną prezentacją. Delegowanie części projektu jest w porządku (chociaż Ty, a nie oni, możesz zdecydować, co według Ciebie powinno zostać przekazane), ale nie jest w porządku, aby kontynuowali bez informowania Cię. Stracili twoje zaufanie, zasłaniając cię wzrokiem, teraz muszą nauczyć się lepszego zachowania. Musisz często się z nimi kontaktować, aby upewnić się, że nie zasłaniają cię ponownie, a jeśli tak, powinieneś formalnie zgłosić problem HR. Przewody nie są popularne, gdy programiści umyślnie omijają je po otrzymaniu zakazu, zasługują na konsekwencje. Nie robi nie ważne, czy cię lubią, czy nie, ale w tej chwili nie szanują cię. Muszą mieć pokrewieństwo za swoje niewłaściwe zachowanie, bo inaczej się pogorszy. Nie można jednak naprawić tej części problemu, dopóki nie zostanie rozwiązany problem obsługi zarządzania.

Następnie wysadziłeś w powietrze publicznie, musisz publicznie przeprosić. Pomoże ci to odbudować swoją reputację.

Następnie musisz wziąć każdą osobę na osobność i powiedzieć im o konsekwencjach ich ciągłego złego zachowania (po tym, jak poprosisz swojego przełożonego o zgodę na udzielenie ci konsekwencji). Chwała publiczna i wsparcie, prywatna krytyka powinna być twoją regułą. Być może będziesz musiał częściej się z nimi zameldować poza spotkaniami grupy, aby nie mogli cię oślepić.

Teraz, szczerze mówiąc, zarówno ci powyżej, jak i pod tobą wyraźnie myślą, że jesteś kimś, kogo można zignorować i nie informować o tym, musisz zrobić poważną duszę, szukając siebie, co powoduje, że cię nie szanują. Musisz także zdecydować, czy nie byłbyś szczęśliwszy, nie będąc liderem technologicznym, czy też powinieneś przenieść się do miejsca, w którym będziesz mieć uprawnienia do pełnienia tej odpowiedzialności. Jeśli zdecydujesz, że chcesz pozostać w tej pozycji, będziesz musiał poprosić ludzi, aby wyrównać z tobą, dlaczego traktują cię tak źle. Będzie to bolesne i prawdopodobnie nie będziesz chciał usłyszeć odpowiedzi, ale musisz wiedzieć, dlaczego jesteś postrzegany w sposób, w jaki wyraźnie cię postrzegają.