Kiedy skonfrontować dobrego lidera projektu lub szefa

Nasz szef projektu jest genialnym architektem oprogramowania, ogólnie łagodną i troskliwą osobą, maniakiem z natury i delikatnym głosem. Ale czasami my (koledzy z zespołu i ja) różnimy się w opiniach - szczególnie w kwestiach architektury oprogramowania, problemów z projektowaniem systemu, problemów z interfejsem użytkownika itp. Z naszym liderem.

Kiedy i jak (jeśli w ogóle) powinniśmy wyrazić różnicę w opiniach?

Załóżmy, że uważasz, że twój szef się myli. Masz trzy opcje

• rób to, co mówi i sfrustruj się, myśląc, że robisz coś głupiego - niezbyt długofalowo
• powiedz mu, że jest idiotą - albo to zignoruje, albo dostaniesz problemów z komunikacją - nic ci nie zrobi lub cię skrzywdzi.
• powiedz mu, że masz konkretne obawy dotyczące pomysłów, które on proponuje, i wyjaśnij te obawy - każdy dobry szef wyjaśni swoje stanowisko, a następnie podejmie decyzję, która będzie korzystna dla firmy. Jest całkiem prawdopodobne, że zobaczysz, że jego pomysł jest lepszy od twojego i zignorowałeś coś bardzo ważnego.

Zawsze myśl o wyniku. W większości przypadków nie chcesz mieć racji ze względu na rację, po prostu musisz wykonać dobrą robotę. Trzecia opcja pomaga to osiągnąć.

Traktuj go tak samo - delikatnie i z szacunkiem, wyrażając sprzeciw.

Bycie profesjonalistą oznacza szacunek dla rówieśników i przełożonych, nie oznacza to, że nie możesz się nie zgodzić, to po prostu oznacza, że ​​powinien być uprzejmy i pełen szacunku z natury.

Kiedy mój zespół ma wątpliwości lub zdanie odrębne na temat moich wskazówek, traktuję to jako okazję do edukacji, zarówno dla mnie, jak i członków mojego zespołu.

Czy to nie jest przykład starego błędu agresywnego lub pasywnego?

Klasyczna trzecia opcja to asertywność, która pozwala na konstruktywną krytykę i uprzejme spory.

Równie ważne - zaakceptowanie konstruktywnej krytyki (bez koniecznej zgody) i zaakceptowanie uzasadnionego nieporozumienia (brak obsesji na punkcie konkursu „kto ma rację, a kto źle”).

http://en.wikipedia.org/wiki/Assertiveness

A na koniec dnia zawsze będzie potrzebna pewna bierność - w stosunku do przełożonego. To on ponosi ostateczną odpowiedzialność za decyzje - zdolność, autorytet i odpowiedzialność to nie to samo, ale przynajmniej powinny iść w parze.

BTW - „People Skills” Roberta Boltona to dobra (i dość tania) książka do takich rzeczy - umiejętności słuchania, asertywności i nie tylko.

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

Ponieważ wydajesz się go szanować, a on wygląda na mądrego faceta, dlaczego nie zapytać go w następujący sposób:

„Jak twoja metoda / sposób / architektura radzi sobie z problemem x?” Jeśli tak się nie stanie, powiedz coś w stylu: „A co powiesz na to, aby w ten sposób rozwiązać problem x?”

W ten sposób możesz dowiedzieć się, czy już pomyślał o „problemie x” i czy się czegoś nauczył. A jeśli tego nie zrobi, pomyśli o tym i może skorzysta z twojego rozwiązania lub pomyśli o innym (może uda ci się to wypracować razem).

Chciałbym wymyślić konkretniejszy przykład, ale myślę, że powinieneś być w stanie zrozumieć ten pomysł.

Nie sądzę, żebyś najpierw trafił do swojego szefa, zwłaszcza jeśli nie jest programistą ani coś takiego.

I nie trzeba mówić, że jego droga jest zła, ale pytając, jak radzi sobie z pewnymi sytuacjami, może zdać sobie sprawę z problemu lub być w stanie powiedzieć, dlaczego to nie jest problem.

Mam nadzieję, że to pomoże.

Używając słowa CONFRONT, pokazujesz, że nie podchodzisz do problemu z właściwym nastawieniem.

To nie jest konfrontacja. To nie jest wrogie. Nie jest wojujący ani zły. Jest to dyskusja na temat różnych podejść oraz kosztów i korzyści.

Nie wchodź z sześcioma pistoletami płonącymi. Po prostu powiedz mu coś, o czym myślałeś. „Co gdybyśmy to zrobili w ten sposób?” Kto wie, możesz go przekonać.

A jeśli nie - a czasem nie - pamiętasz, że on może dobrze wiedzieć rzeczy, których nie znasz, na temat budżetów, harmonogramów, wymagań, innych priorytetów i tak dalej. Niekoniecznie jest idiotą tylko dlatego, że się z tobą nie zgadza.

Nie ma wątpliwości, że wątpisz w jakiekolwiek decyzje lub daną architekturę projektową / programową. Chyba że właśnie zacząłeś swoją pierwszą pracę, w którym to przypadku się mylisz w 99% przypadków, ponieważ brakuje ci części większego obrazu .

Kiedy ty (i / lub zespół) różnisz zdanie, zapytaj lidera projektu, czy ma on czas na omówienie tego, a może nawet zaplanuje małe spotkanie (15-30 minut). Wyraź swoją opinię z szacunkiem i słuchaj, dlaczego podjął decyzję inaczej. Jeśli zobaczę, jak go opisałeś, chętnie omówi i podzieli się swoimi spostrzeżeniami na temat problemu. Nie powie „bo tak powiedziałem” (tacy ludzie istnieją niestety). W takim przypadku po prostu zignoruj ​​swoją opinię, jeśli chcesz zachować pracę, lub powiedz ją i odejdź do innej pracy, ponieważ staniesz się nieszczęśliwy.

Dobra dyskusja może zakończyć się na kilka sposobów:

• Kierownik projektu zaakceptuje twoje rozwiązanie jako lepszy sposób rozwiązania problemu (i być może nauczył się nowej technologii, wzoru ... z którym nie miał jeszcze dużego doświadczenia).
• Ty i zespół zobaczycie większą część obrazu lub uzyskacie dobre wyjaśnienie, dlaczego powinniście to robić w ten i tamten sposób. Dowiesz się czegoś nowego i zrozumiesz, że początkowe rozwiązanie było prawidłowe, a może nawet znajdziesz sposób na ulepszenie go dzięki nowym informacjom (chociaż w pewnym momencie będziesz musiał się zgodzić).
• Dyskusja nie pomaga i nadal się nie zgadzasz. Wessaj go i zastosuj jego rozwiązanie (ponieważ najprawdopodobniej będzie miał więcej doświadczenia) lub odejdź.

Tak czy inaczej, powinieneś postrzegać to jako okazję do nauki i tak długo, jak utrzymujesz ją w cywilizacji i szacunku, będziesz miał wspaniałe doświadczenia z tymi dyskusjami.

Po prostu podnieś to!

W najbardziej uprzejmy i zrozumiały sposób, w jaki potrafię, zwykle powiem „Jestem zaniepokojony tym aspektem, jakie są twoje opinie na temat tego potencjalnego problemu?”

Umieszczę piłkę na jego dworze, żeby mnie edukować.

Znakiem nr 1 dojrzałego programisty i menedżera jest to, że mogą przyznać się do błędu. Pokaż najpierw swojemu szefowi, że wszyscy jesteście w pełni skłonni przyznać, że się mylicie, kiedy jesteście, i wyjaśnijcie swojemu szefowi, że oczekujesz od nich tej samej uprzejmości.

Jeśli masz dobrego szefa (i mówisz, że tak), to na ogół nie będzie problemu! Przekonasz się, że możesz prowadzić konstruktywną dyskusję i znaleźć najlepsze rozwiązanie dla was wszystkich.

Jedną z rzeczy, na którą musisz uważać: upewnij się, że przez większość czasu masz rzeczywiste techniczne, uzasadnione powody, by wątpić w proponowany projekt. „Czuje się źle” nie jest na ogół wystarczające i nie przyczyni się do konstruktywnej dyskusji. Jeśli zdarza się to zbyt często, twój szef nie będzie miał innego wyjścia, jak zewrzeć „dyskusję” (która jest faktem, więc tak naprawdę nie dyskusją) i powiedzieć „przepraszam, ale zrobicie to, co zasugerowałem, dopóki nie będziecie w stanie wykazać faktami, dlaczego jakiś inny pomysł jest wyraźnie lepszy. ”.

Właśnie dlatego szef jest szefem - w podejmowaniu decyzji, które mogą być trudne dla deweloperów.

Moim zdaniem i jak ogólnie zachowuję się z moim szefem:

Zawsze wyrażaj swoją opinię i rób to jak najszybciej, dopóki temat jest gorący. Idealnie, gdy masz kłótnię nad nowym problemem lub projektem, a nie robisz to później, kiedy zebrałeś swoją odwagę i już podjęto decyzje.

Powinieneś otwarcie zasugerować swoje opinie, obawy, problemy i upewnić się, że pojawiają się one jako sugestie lub obawy, a nie narzucać, że należy to zrobić w taki sposób.

Zrób z tego nawyk i stań się lepszym komunikatorem, członkiem zespołu, a z kolei lepszym zespołem. Dobry zespół będzie otwarcie mówił o negatywnych rzeczach, a także o pozytywach. Dobry lider zespołu wysłucha swojego zespołu i podejmie decyzję, biorąc pod uwagę dostarczone informacje.

Powodzenia.

Jeśli jest tak dobrym architektem, jak to opisujesz, po prostu podejdź do niego w sposób wykształcony z logicznymi i konkretnymi powodami swoich obaw.

Jeśli masz czas / zasoby, spróbuj wykonać kilka testów scenariuszy, które mogłyby udowodnić, że masz rację, posiadanie niektórych danych po twojej stronie to ogromny plus.

Po rozmowie z nim może on tylko:

a) Zgadzam się z tobą: Problem rozwiązany!

b) Odrzuć je i wyjaśnij, dlaczego: może w końcu to ty się mylisz.

c) Odrzuć je bez powodu: jeśli jest nierozsądny i jesteś całkowicie pewien, wyrażaj swoje zaniepokojenie odpowiedzialnym projektem, w tym przypadku naprawdę potrzebujesz zimnych danych, a jeśli możesz, wsparcie innych członków zespołu. Nie ucieszy to architekta, ale jest etyczną rzeczą (wyobraź sobie, że projektujesz budynek i widziałeś wadę w strukturze ...)

Moje pytanie brzmi: kiedy i jak (czy?) Wyrazić różnice w opiniach.

Absolutnie Tak jest odpowiedzią. O ile nie zdarzają się jakieś rzadkie sytuacje wymykające się spod kontroli, w których nawet potencjał zawirowań lub utraty pracy z tego powodu jest tak wielki, powinieneś konfrontować się z innymi, gdy masz odmienne opinie.

Prawdziwy klucz tutaj brzmi: kiedy i jak.

Po pierwsze: „Kiedy”: każde środowisko jest inne, ale w niektórych miejscach odbywają się cotygodniowe spotkania lub dyskusje przy otwartym / okrągłym stole, w których poruszanie określonych tematów jest odpowiednią areną do tego. Najważniejszą rzeczą, której nie chcesz robić, jest upokorzenie lub upublicznienie osobistego argumentu projektowego, który jest między tobą a tylko 1 lub 2 innymi osobami. Ludzie, którym rzucasz wyzwanie, nie docenią wyzwania, a może nawet zawstydzenia w miejscach publicznych. W takich sytuacjach staraj się umówić spotkanie 1 na 1 z osobą (osobami), o których mowa, aby szczegółowo opisać swoje przemyślenia.

2. „Jak”: Jeśli wybierasz się do seniora, upewnij się, że wszystkie kaczki są w rzędzie, popierając swoje myśli. Nie możesz tak po prostu wędrować do biura osób na wyższych stanowiskach, mówiąc: „Wszystkie formularze internetowe muszą zostać zatrzymane, a my musimy zrobić MVC!”. Na pytanie „Dlaczego?” i mówicie: „Cóż, to właśnie robią wszyscy i to we wszystkich czasopismach”, to nie zajdzie daleko. Przygotuj się na dyskusję w przód i w tył i poproś o uzasadnienie swoich przemyśleń na temat architektury, kodowania, projektowania, najlepszych praktyk itp. Jeśli masz przykłady działającego kodu, aby uzasadnić (tj. Małą wiązkę testową do udowodnienia myśli), może to pomoc również. Ważne jest, aby nie wdać się w bitwę ego lub pozwolić, by emocje wzrosły.

Ostatecznie, jeśli masz solidne, uzasadnione i logiczne sugestie, należy je wziąć pod uwagę. Bądź jednak przygotowany, że na świecie są tylko nierozsądni ludzie, którzy nie chcą słuchać nikogo oprócz siebie. Mam nadzieję, że nie jesteś poparty w kącie z tego rodzaju osobowością.

Powodzenia!

Nie jestem pewien, jak możesz zostać genialnym architektem oprogramowania bez popełniania błędów i zadawania pytań. Myślę, że można bezpiecznie założyć, że był już w takiej sytuacji.

Inteligentni, dojrzali, profesjonalni ludzie nie mogą długo oprzeć się pokusie lepszych pomysłów. Nawet jeśli na początku jest zdenerwowany pytaniem o swoje pomysły, w końcu powinien przyjść i zyskasz szacunek. Jeśli nie jest ani dojrzały, ani zawodowy, masz większy problem i być może to go zaświeci.

Jeśli jest zawodowym architektem, uszanuje i zaakceptuje drugą opinię. Jednak w każdym przypadku musisz dobrze przygotować alternatywę na podstawie faktów / wiedzy specjalistycznej, a także dobrze ją przedstawić. Należy również pamiętać, że w przypadku architektury istnieją zasadniczo dwie różne możliwości takich problemów:

1. Jedno podejście / projekt może być po prostu dobre lub złe, jak w matematyce 2 + 2 = 4, a nie pięć. W przypadku błędu musisz jak najszybciej znaleźć właściwe rozwiązanie, oparte na faktycznych zastrzeżeniach.
2. Zdecydowanie najwięcej tematów w projektowaniu systemu to możliwe podejścia, które nie są wyłączne. Istnieją również inne alternatywy, których wybór zależy od doświadczenia, smaku, uprzedzeń, ogólnego obrazu itp. Aby nie dopilnować możliwie lepszego podejścia, zwykle odbywają się prezentacje i dyskusje, gdy deweloperzy są zachęcani do zabrania głosu i dzielenia się swoimi opiniami. Należy jednak pamiętać, że istnieją okresy na dyskusje i okresy wdrażania, w programowaniu zwinnym etapy te są dobrze zdefiniowane.