Jak prowadzić projekt rozwojowy bez wiedzy technicznej

Przez całą karierę byłem praktycznym programistą i uwielbiam pracować z kodem. Zawsze nie podobało mi się kierownictwo zespołu, który ma niewielką lub żadną wiedzę specjalistyczną w zakresie konkretnej technologii, a jednak nalega na pewne wdrożenie.

Teraz znajduję się po drugiej stronie lustra. Jestem głównym programistą grubego klienta, który ma zostać zaimplementowany w języku C #, jednak moje doświadczenie dotyczy budowania aplikacji internetowych Java. Chociaż wiem, że mogę wykorzystywać wzorce projektowe i paradygmaty OO w dowolnym języku, zgubiłem się, jeśli chodzi o standardy kodowania, narzędzia cyklu życia projektu oraz procedury wydawania / dystrybucji. Nie mam wątpliwości, że mogę poznać podstawy w ciągu miesiąca lub dwóch, ale są pewne doświadczenia, które można zebrać tylko z czasem.

Co powinienem zrobić i jak uniknąć stania się liderem projektu, którego nienawidziłem, kiedy się rozwijałem?

Szczerze mówiąc, nie ma znaczenia, ile masz doświadczenia z technologią, moja rada jest taka sama: nie egzekwuj decyzji technologicznych wobec tych, którzy będą musieli z nimi mieszkać, gdy będziesz zajęty zarządzaniem.

Bądź ze sobą szczery. Założę się, że powodem, dla którego nienawidziłeś tych wcześniejszych menedżerów, nie było to, że nie mieli oni wiedzy, z której mogliby podejmować decyzje, tylko dlatego, że egzekwowali decyzje i nigdy nie radzili sobie z konsekwencjami.

Dotyczy to tego, czy nigdy wcześniej nie dotykałeś platformy .NET, czy jesteś najbardziej doświadczonym programistą w zespole. Twoim zadaniem jest teraz zarządzanie, a nie podejmowanie technicznych decyzji.

Zarządzanie może, w zależności od poziomu umiejętności programistów, oznaczać doradzanie im, kiedy o to poproszą. „Czy zajrzałeś do Spring.NET?” (zwróć uwagę na brak instrukcji) to całkowicie dobra rzecz do powiedzenia. Ponadto „Google wokół, zobacz, co robi reszta świata, nie jesteśmy pierwszymi, którzy napotykają ten problem”.

Pod pewnymi względami, jako doświadczony programista Java, możesz być w lepszej sytuacji niż większość z nich. Większość platform i technologii Java ma analogiczny odpowiednik w .NET. Więc nie musisz mówić „Oto najlepsza rzecz do użycia”, możesz powiedzieć „Użyłem tego w Javie, czy znasz odpowiednik .NET?”

Zachęcaj także do wielu rozmów w zespole. Umawiaj cotygodniowe spotkania techniczne. Ostatecznie wszystko, czego potrzebujesz, to informacje; musisz wiedzieć, jakie decyzje podjęli i dlaczego. Nie musisz podejmować tych decyzji dla zespołu.

Miałem kilku bardzo dobrych menedżerów / liderów zespołów, którzy niewiele wiedzieli o technologii, a niektórzy z moich najgorszych menedżerów to ci, którzy myśleli, że wiedzą wszystko.

Aby być liderem, jeśli masz rozsądnie kompetentnych ludzi, najważniejsze jest, aby móc ocenić ich kompetencje i osąd, i dać każdemu tyle swobody, ile tylko da sobie radę, jednocześnie utrzymując „dzikie kaczki” na zadaniu, a „ledwo konkurenci „zajęci” „bezpiecznymi”, ale produktywnymi działaniami. Upewnij się, że wszyscy maszerują do tego samego perkusisty.

Twoim większym wyzwaniem jest prawdopodobnie trzymanie dystansu dla wyższego kierownictwa. Będą chcieli raportów, harmonogramów i znaczników, a ty musisz dowiedzieć się, czego chcą i jak je odpowiednio sfałszować. (Cóż, nie do końca „fałszywe”, ale opracuj dokumentację, która je satysfakcjonuje bez marnowania czasu lub czasu zespołu.)

Nie zostałeś wybrany ze względu na swoje umiejętności kodowania w C # i jeśli nie będziesz pisał kodu od samego początku, nie ma znaczenia, czy znasz C #, czy nie. Musisz zacząć myśleć na wyższym poziomie:

• Jakie umiejętności wnosi każda osoba z twojego zespołu do stołu?
• Które elementy mają kluczowe znaczenie dla powodzenia projektu?
• Co musisz wyprodukować oprócz samego kodu? (Testy? Dokumentacja?)
• Jak będziesz zbierać wymagania, jeśli jeszcze tego nie zrobiłeś?
• Jak Ty i Twój zespół podejdziecie do procesu projektowania?
• Wiesz, że posiadanie standardu kodowania jest ważne, ale możesz polegać na swoim zespole, aby dowiedzieć się dokładnie, jaki standard chcą stosować.
• Jak wcześnie wykryć problemy?

Niektóre z tych rzeczy mogą przejść na terytorium zarządzania projektami, ale jako główny programista będziesz ściśle współpracować z kierownikiem projektu w tych i innych kwestiach.

Oczywiście, naucz się efektywnie pracować w C # tak szybko, jak to możliwe. Pamiętaj tylko, że twoja rola polega na przejrzeniu szczegółów składni i frameworka oraz na szerszym obrazie.

Weź się w garść. Zacznij od zdobycia prostego C # i napisz kod. Wypróbuj kilka podstawowych rzeczy, które możesz zrobić z zasłoniętymi oczami w innym języku.

Przeczytaj o stylu programowania i konwencji. W każdym razie powinieneś znaleźć to częściowo w swoim podkładzie, ale możesz także używać produktów takich jak StyleCop i Resharper, aby egzekwować reguły stylu, których nie znasz. To skutecznie przeszkoli cię bardzo szybko robić rzeczy w powszechnie akceptowany sposób, aby uniknąć problemów z kompilacją oprogramowania.

Po prostu bądź sobą i zastosuj wiedzę projektową, którą już posiadasz. Podstawy są zasadniczo takie same, niezależnie od języka. Będą występować różnice w różnicach językowych pod względem struktury, będą one dość minimalne, a znaczna ich część stanie się bardzo widoczna, gdy zrzucisz razem aplikację testową lub dwie.

Jeśli są oczywiste rzeczy, których nie wiesz, bądź gotowy. Twój zespół będzie szanował uczciwość bardziej niż zwykłe staranie się bez pojęcia. Podejmuj przemyślane i uzasadnione decyzje i zawsze poświęć kilka minut na zastanowienie się nad odpowiedzią. Musisz być asertywny, nie próbując dominować, i nie możesz pozwolić, by twój brak wiedzy w jednym obszarze odzwierciedlał twoją zdolność kierowania zespołem. Przywództwo oznacza mentoring, ale mentoring nie oznacza, że ​​nie możesz wykazać chęci nauczenia się czegoś nowego.

Jeśli tak myślisz i naprawdę się o to martwisz, już uniknąłeś ryzyka zostania tego rodzaju liderem projektu. To zupełnie inna osobowość, która odważyłaby się podejmować decyzje bez odpowiedniej wiedzy. Po prostu miej otwarty umysł na to, co mówią ci współpracownicy, i twórz i zachęcaj do kultury dialogu i wymiany informacji w swoim zespole.

Wygląda na to, że tutaj jest kilka problemów.

Technologia zastosowana w prowadzonym przez Ciebie projekcie i proces rządzący rozwojem tego projektu.

Jesteś liderem zespołu lub głównym programistą? Główny programista wykonuje również sporo prac projektowych i programistycznych. Jedynym sposobem na obejście tego jest po prostu ułożenie się i poznanie nowej technologii .

Jeśli faktycznie przewodzisz zespołowi, musisz zaufać zespołowi i pozwolić mu kierować większością technicznego kierunku projektu. Oczywiście, pod względem koncepcyjnym, będziesz w stanie utrzymać ten układ kierowniczy we właściwym kierunku.

Procesy rządzące rozwojem projektu powinny w większości być na miejscu . To tylko kwestia przeczytania ich, zrozumienia ich i wykonania.

Jeśli nie, negocjuj z szefem, aby uzyskać mentora, który pomoże ci wdrożyć proces rozwoju. To jest bardzo ważne. Szybko zakończy się niepowodzeniem, jeśli proces nie zostanie wdrożony i będzie przeprowadzany ad hoc.

Powodzenia!

Okazja przychodzi od czasu do czasu .. Chwyć ją ... Powiedziałbym, spróbuj nauczyć się podstaw języka C #. Pobierz samouczek online, spróbuj nad nim popracować. początkowo ciężko byłoby nauczyć się nowej koncepcji, później, kiedy wykonasz pierwsze zadanie, będziesz mieć do niej zaufanie.

Myśl pozytywnie, staraj się podjąć trudne zadanie, debuguj własny kod i jestem pewien, że go opanujesz.

Nie trać okazji.

Myślę, że jeśli masz spore grono programistów .Net, w zespole jest duża wiedza, którą być może potrzebujesz, aby zacząć. Istnieje wiele podobieństw między Javą a .Net, że to, co już wiesz, może faktycznie zastosować mniej lub bardziej bezpośrednio. Ważne jest, aby wiedzieć, co jest ważne, aby uzyskać właściwy projekt i związane z tym ryzyko. Komunikuj się ze swoim zespołem tak często, jak to konieczne. Praktyka inżynierii oprogramowania ewoluuje w trakcie całego projektu, więc może być trudno mieć „najlepszą praktykę” na bardzo wczesnym etapie projektu.

W pewnym sensie miałem odwrotność twojego doświadczenia, w którym otrzymałem bardzo zielony zespół absolwentów, którzy nie są z dziedziny oprogramowania. Chociaż mam wszystkie powody, aby określić, co należy zrobić (byłem zatrudniony), zamiast tego szukałem praktyki, która pozwoli nam się poruszać, oraz wielu szkoleń i dyskusji, aby rozwinąć naszą praktykę inżynierii oprogramowania. Po drodze nauczyłem się stosów od zespołu i już prawie jesteśmy w stanie zrealizować nasz pierwszy projekt po ponad roku pracy!

Zgubiłem się, jeśli chodzi o standardy kodowania, narzędzia cyklu życia projektu oraz procedury wydawania / dystrybucji.

Znajdź produkt typu open source, który wykorzystuje tę samą technologię, której będziesz używać.

Jeśli to możliwe, znajdź taki, który jest w pewien sposób podobny do domeny problemowej. Nie jest to tak ważne, jak znalezienie projektu z tą samą technologią i aktywnymi aktualizacjami.

Pobierz ich działający kod. Przeczytaj to.

Dowiedz się, jakich narzędzi używają. Użyj ich.

Dowiedz się, jak zbudować i wydać projekt open source. Zbuduj go i zwolnij.

Projekt open source (z udziałem wielu autorów) zilustruje najlepsze praktyki.

Nie mam wątpliwości, że mogę poznać podstawy w ciągu miesiąca lub dwóch, ale są pewne doświadczenia, które można zebrać tylko z czasem.

Prawdziwe.

Ucz się od społeczności open source.