Jak odnieść sukces jako główny programista? [w oczekiwaniu]


47

Zostałem głównym programistą w konkretnym projekcie, ale mam trudności ze skupieniem się na dużym obrazie i upewnieniem się, że wszystkie części projektu zostały uwzględnione.

O czym powinienem pamiętać, zarządzając tym projektem? Jak mogę się upewnić, że wszystko jest załatwione tak, jak powinno?


3
Wyjaśnij: „Trudno mi zachować przegląd i duży obraz projektu” Co jest trudne? Co cię rozprasza? Jakie masz problemy? Co wolisz robić
S.Lott

Czy możesz bardziej opisać swoją sytuację? Czy to duży zespół? Jakie są twoje oczekiwania jako Lead? (techniczne przywództwo? zarządzanie zakresem? architektura i projektowanie?) Czy istnieje Project Manager? Menedżer produktu?
Al Biglan

1
Nie wystarczająco długo, aby być prawdziwą odpowiedzią, ale niektórzy ludzie po prostu nie są przystosowani do tych ról. Często to widzę.
Bill

Odpowiedzi:


53

Widziałem tę podróż do innych programistów, którzy przechodzili do seniorów lub liderów. Oto kilka sugestii, które przedstawiłem innym.

  • Zrozum, jaki jest cel projektu.

Często nie chodzi o wszystkie funkcje, które zostały wprowadzone do projektu. Chodzi o podstawowy zestaw funkcji spełniających potrzeby biznesowe. Zawsze miej to na uwadze, ponieważ jest to twój główny cel.

  • Podział tego, co trzeba zrobić na zadania. Zrozum zależności między nimi.

Załamanie projektu powinno być dość proste. Rozbij go na jak najwcześniejszym etapie projektu. Jeśli musisz połykać części, zrozum, że stanowią one ryzyko, dopóki nie zrozumiesz, co należy zrobić.

  • Zrozum, jakie są otwarte pytania lub niejasności projektu.

Początkowo nie będziesz w stanie rozwiązać wszystkich niejasności (chociaż powinieneś spróbować). Upewnij się, że kierownik i interesariusze projektu rozumieją, czym są i jakie ryzyko stwarzają dla projektu.

  • Biznes nienawidzi niespodzianki.

Upewnij się, że wszyscy wiedzą (najlepiej codziennie, ale co tydzień), jaki jest status projektu. A przez status rozumiem, co zostało zrobione, co pozostało do zrobienia, otwarte pytania, problemy itp. Należy zgłaszać wszystko, co może wpłynąć na zakończenie projektu.

  • Codziennie przejrzyj duży obraz.

Powinieneś codziennie przeglądać duży obraz przez godzinę. Zadaj sobie pytania. Co zostało ukończone? Co pozostało do zrobienia? Jakie są otwarte pytania? Jaki jest cel Powinieneś być w stanie podać komuś szczegółowy status projektu, ilekroć o to poprosi.


5
+1 głównie za ostatnie dwa punkty. Te dwa są niezwykle ważne.
konfigurator

42

Pierwszą radą, którą ci dam, jest zaakceptowanie faktu, że zarządzanie zespołem jest ważniejsze niż wykonywanie własnych zadań programistycznych. Oznacza to, że kiedy masz 3 juniorów, którzy potrzebują pomocy, Twoim zadaniem jest pomóc nie narzekać na to, jak to odbiera ci rozwój. Prowadząc, często stajesz się przeszkodą na drodze do postępu, jeśli najpierw skupiasz się na własnych zadaniach programistycznych.

Ponadto musisz nauczyć się delegować. Trudno jest powierzyć komuś zadania, kiedy możesz to zrobić łatwo w ciągu godziny, a wiesz, że będą szaleć przez cały dzień. Jednak nigdy nie będą się rozwijać, chyba że dostaną zadania, a ty będziesz pracował w nadgodzinach, gdy twój zespół gra.

Co więcej, nigdy nie naprawiaj cudzego kodu. Powiedz im, co jest nie tak (i ​​dlaczego), i napraw je. Albo wejdziesz w cykl, w którym musisz wszystko naprawić, ponieważ nie poprawia się. Jeśli nie mogą tego naprawić, zastanów się, czy powinni zostać w zespole. Nie pozwól słabym członkom zespołu zostać, ponieważ naprawiasz wszystko, co robią.

Jako ołów możesz stać się złym facetem i przekazywać im nieprzyjemne wiadomości (zarówno w górę, jak i w dół łańcucha). To również pasuje do pracy. Oznacza to, że musisz dokonać słabej oceny wyników; musisz im powiedzieć, że termin został przesunięty w górę lub wymagania uległy zmianie; musisz popchnąć leniwego faceta, który nie robi postępów; i musisz powiedzieć przełożonym, kiedy termin nie zostanie dotrzymany oraz dlaczego i co z tym robisz. Prowadzenie nie polega na byciu lubianym, ale na skuteczności. Twoim zadaniem jest wyciąganie oprogramowania z domu, a nie nawiązywanie przyjaźni. Komunikacja jest kluczowa, a unikanie złych wiadomości ostatecznie pogarsza sytuację. Klient jest o wiele bardziej skłonny poradzić sobie z informacją, że minie jeszcze trzy tygodnie na miesiąc przed uruchomieniem, niż kiedy minie data uruchomienia, a następnie powiesz mu, że potrzebujesz jeszcze trzech tygodni.


1
Świetne myśli
Roy Tinker

8
również dobre streszczenie, dlaczego ludzie na ogół nie chcą tej pracy.
Kevin

2
@Kevin, rzadko kiedy podwyżka wynagrodzenia jest warta dodatkowej odpowiedzialności kierownika technicznego, a następnie ogólnie tylko wtedy, gdy chcesz awansować na stanowisko, które jest wyłącznie zarządzaniem. Jeśli chcesz pozostać techniczny, widziałem, jak wiele osób staje się liderami technologii, a następnie ponownie prosi o bycie starszym programistą.
HLGEM

31

Oto moja nieformalna lista kontrolna. To bardzo nieformalne ... Nie robię wszystkiego codziennie, ale jeśli nie uderzę w te wszystkie rzeczy co tydzień, trochę się martwię, a jeśli nie uderzę ich co miesiąc, powinienem panikować. Przebieg różni się całkowicie w zależności od kultury firmy / zespołu, osobistego stylu i rodzaju projektu.

  • Rozmawiaj z zespołem indywidualnie - czy wszyscy w zespole - mają pożyteczną pracę? wiesz, jaki jest ogólny cel produktu i bieżąca wersja? czy wiedzą, w jaki sposób zarabiasz pieniądze i jaki jest główny cel Twojej działalności? czy wiedzą, jak ich obecna praca pasuje do tego wszystkiego?

  • Rozmawiaj z zespołem wspólnie - zbierz je wszystkie razem z ważnymi wiadomościami, zbierz grupy, aby upewnić się, że komunikacja odbywa się z tobą i bez ciebie. Jako niewielki zespół to prawdopodobnie sesje strategii grupowej. Gdy zespół powiększy się, stanie się tak, że będziesz musiał poprowadzić go przez główne punkty i nieuchronnie stanie się on scenariuszem rozmowy na ich temat. To nie jest źle - są chwile, kiedy bardzo ważne jest, aby wszyscy słyszeli, jak przekazujesz wszystkim informacje publiczne . Więc wszyscy wiedzą, że podajesz informacje uniwersalnie. Ale spotkanie „ty - dla - wszystkich” bardzo różni się od spotkania dotyczącego strategii grupy, w którym jesteś bardziej przewodnikiem.

  • Wypróbuj pracę zespołu - postaraj się uzyskać ankietę na temat pracy każdego. Przeczytaj ich kod, uruchom ich funkcje, wypróbuj ich przypadki testowe. Nie celuj w 100% wszystkich prac, spróbuj pobrać próbki od wszystkich. Przekaż im informacje zwrotne, ale także zanotuj obszary silnych i słabych stron w zespole.

  • Sprawdzaj się wcześnie i często - to nie jest brązowy nos, to jest na bieżąco. Jeśli nie wiesz, czego potrzebuje Twój zarząd i co myśli o nim kierownictwo, to w jaki sposób Twój zespół może spełnić oczekiwania? Musisz mieć naprawdę dobre wyniki ze swoim szefem i musisz być w jego zespole, tak jak twoi ludzie są w twoim zespole. Umiejętność skutecznego komunikowania się z szefem w sprawach błahych zwiększa pewność, że będziesz w stanie uzyskać pomoc i jasne zrozumienie, kiedy nadejdzie kryzys. To także dobry sprawdzian rzeczywistości, gdzie znajdują się Twoje duże rolety.

  • Okresowo sprawdzaj zasoby zespołu - ludzie będą krzyczeć, gdy poprzednio dostępny zasób stanie się niedostępny, ale sprawdź pod kątem nieznanych punktów bólu. Gdzie są twoje punkty pośrednie? Czy są jakieś nowe przydatne narzędzia? Większość drużyn ma faceta, o którym myślę, że jest Łowcą narzędzi, który zawsze jest na bieżąco z najnowszymi i najlepszymi gadżetami. Wyrównuj rozmowy między Tool Hunterem i GuyWhoHatesEverythingNew, aby znaleźć kolejny punkt ewolucji. Narzędzia obejmują wszystko - SW, HW, przestrzeń fizyczną, zasoby edukacyjne.

  • Poznaj i bądź w kontakcie z zespołami wsparcia. Każda firma jest inna, ale znają osoby odpowiedzialne za kontrolę jakości, pisanie dokumentów, kwestie prawne, udogodnienia, finanse i wszelkie inne grupy wspierające specyficzne dla Twojej firmy. Są najlepszymi wyzwalaczami, jakie mogę sobie wyobrazić, ponieważ widzą świat zupełnie inny niż ty.

  • Poznaj swoją konkurencję - spędzaj co najmniej trochę czasu w tygodniu, zastanawiając się, jak ktoś rozwiązałby problemy, które rozwiązuje Twój produkt, gdyby nie korzystał z Twojego produktu. To może nie być jedna firma, ale co oferuje to inne rozwiązanie, czego nie oferujesz?

  • Przejrzyj koszty i harmonogram- Jak prawdopodobne jest, że Twój zespół będzie oznaczał ich obecny termin? Co powiesz na następny termin? Jaka jest szybkość spalania twoich kosztów? Za jakie duże nadchodzące zakupy jeszcze nie zapłaciłeś? Co pozostało z twojego budżetu? Szczegóły różnią się w zależności od sposobu śledzenia finansowego, ale nawet w bardzo nieformalnej firmie powinieneś mieć pojęcie o tym, ile dni / tygodni / miesięcy pozostałego budżetu i jaki jest twój ostateczny termin dla obecnego produktu. Gdzieś w jakiś sposób ktoś lepiej planuje „ilu ludzi potrzebujemy do wykonania tej pracy?” oraz „czy możemy sobie pozwolić na ich wypłatę w przyszłym miesiącu / kwartale / roku?”. Musisz znać te liczby i mieć wkład w kolejne kroki. Potrzebujesz krystalicznie czystego planu na następny tydzień, który mógłbyś wyjaśnić teraz, gdyby ktoś wszedł i zapytał. Potrzebujesz całkiem dobrego planu na następny miesiąc, zmieni się to tylko w 2-3 miejscach, gdy uderzy rzeczywistość. Potrzebujesz szkicowego planu na kwartał i generała poza szczytem głowy na rok. W przeszłości nawet w dużym projekcie liczby były tylko liczbami. Posłuchaj ich, ale zdaj sobie sprawę, że nikt nie podpisał krwią.

To jest moje miejsce na szczycie mojej głowy. Zasadniczo się do tego dodam, gdy uderzam go w głowę „niespodzianką” (wyobrażam sobie, że jestem wrażliwy na obszar, za którym tęskniłem, a potem udaje mi się złożyć go na listę kontrolną. G „niespodzianka” z przymusowym uśmiechem i zaciśniętymi zębami ).

Ponadto - bądź przygotowany na zmianę kontekstu strachu. Jeśli dopiero zaczynasz w zarządzaniu, prawdopodobnie masz mały zespół, a ktoś w zarządzie pomyślał, że dobrze byłoby spędzić trochę czasu na zarządzaniu zespołem i trochę czasu na robienie indywidualnych działań. Można to zrobić, ale zmiana kontekstu między nimi jest trudna. Zaplanuj to. Zablokuj czas na zmianę (jak przed i po obiedzie) i poznaj swój mniej wyszkolony zestaw umiejętności i zdaj sobie sprawę, że będziesz musiał przeciągnąć się tam kilka razy - więc zarezerwuj czas na zrobienie czegoś „związanego z dużym obrazem” i wymyśl, że potrzebujesz co najmniej dwóch godzin, aby naprawdę dostać się gdziekolwiek.

Przełącznik kontekstu działa w obu kierunkach - od zarządzania do pracy i na odwrót. Ale kiedy przechodzisz od punktu siły i praktyki do miejsca dyskomfortu i mniej praktyki, odczuwasz ból bardziej, a impuls do wycofania się jest silny. Wiedz o tym i walcz z tym i zdaj sobie sprawę, że rzucanie się na dużym zdjęciu sprawia, że ​​lepiej sobie z tym radzisz.


5
„Wyrównuj rozmowy między Tool Hunterem a GuyWhoHatesEverythingNew, aby znaleźć kolejny punkt ewolucji”. Kocham to.
Hugh

12

Przeczytaj tę książkę: Herding Cats: A Primer dla programistów, którzy prowadzą programistów

Jakiś czas temu podarowałem tę książkę mojemu szefowi i podobało mu się. Kiedy to czytałem, wydawało się, że on wie o czym mówi. I tak jest. Autor opowiada o swoich doświadczeniach. Nie jest zbiorem „prostych prawd” menedżera - to słowa byłego programisty. I należy rozumieć, że to było JEGO doświadczenie, ale twoje może być inne. Tak więc w niektórych kwestiach powinieneś wyglądać krytycznie. „Menedżer nie może już być programistą - to ważne”.


6

Kiedy niedawno przejąłem kierownictwo techniczne małej firmy nad produktem, którego nie opracowałem, bardzo pomocne w zarządzaniu rzeczami było udokumentowanie w języku angielskim działania produktu - funkcje, które udokumentowałem w ogórku, oraz do elementów wewnętrznych Napisałem objaśnienia modelu obiektowego i przepływ przez różne kontrolery. Zauważyłem, że A) produkt był trochę bałaganem :) I B) Dowiedziałem się znacznie szybciej, jak działa aplikacja, więc mogłem przeprowadzić inteligentną rozmowę o tym, jakie były problemy i co wymagało refaktoryzacji, lub co zajmie wdrożenie danej funkcji.

Pomagają też zdjęcia - nie zadzieram z produktami takimi jak Visio, po prostu używam kredek i czystego papieru (naprawdę, robię - pracuję w domu i często obok mojego 2-letniego dziecka), ale to, co działa dla ciebie, jest tym, czego powinieneś używać.


4
Miałem pracę, w której odziedziczyłem stół kreślarski, którego nikt inny nie chciał. Zrobiłem wszystkie projekty baz danych na papierze i długopisie, ponieważ Visio był zbyt wolny do projektowania. Mogłem opracować projekt bazy danych na papierze w około 1/10 czasu potrzebnego do stworzenia dokumentu projektowego w Visio.
HLGEM

4
Nie mogłem powiedzieć dlaczego, ale wydaje mi się, że myślę szybciej, kiedy muszę zwolnić, aby pisać. Nawet koduję na papierze, gdy utknę na problemie. Zabijanie drzew na ołtarzu produktywności ... :)
karmajunkie
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.