Potrzebujesz bohatera: kierownika projektu

Ten artykuł jest dla Ciebie, odważnego przedsiębiorcy z pomysłem na aplikację w sercu i odrobiną gotówki w banku. Diagramy, które nabazgrałeś na serwetkach koktajlowych, zakłócą cały świat, a wywrotki pełne pieniędzy zostały już wysłane do twojego domu. Aby upewnić się, że dotrą na czas, oto kilka prostych porad, jak sprawić, by cykl produkcyjny przebiegał sprawnie.

Dlaczego potrzebujesz kierownika projektu w pierwszej kolejności

„Programy komputerowe to najbardziej złożone rzeczy, jakie wytwarzają ludzie” — mówi Douglas Crockford. Być może wcześniej nie słyszałeś tego imienia, ale jest dość znany jako programista. Obecnie jest starszym architektem oprogramowania w PayPal i jest pionierem wszelkiego rodzaju fajnych technologii, które wykraczają poza zakres tego artykułu. To ktoś, kto dużo wie o pracy przy dużych projektach.

Jeśli chodzi o mnie, programuję od 13 lat i nawet teraz w pewnym momencie każdy projekt zabiera mnie na niezbadane terytorium. Istnieje tak wiele różnych technologii, a nowe techniki są opracowywane w tak alarmującym tempie, że nigdy nie czuję, że jestem całkowicie na szczycie tego, co się dzieje. Chociaż każdy projekt ma swoje unikalne wyzwania, istnieją pewne stałe:

• Projekt ma presję czasu.
• Budżet jest mniejszy niż bym chciał.
• Jestem droższy niż klient by sobie życzył.
• Nie słucham tak perfekcyjnie, jak by sobie tego życzył klient.
• Klient nie tłumaczy rzeczy tak perfekcyjnie, jak bym chciał.

Oczywiście potrzebujemy opiekunki. Ktoś musi wkroczyć, aby ustalić podstawowe zasady, zachować wszystkich uczciwość i upewnić się, że nie zapominamy o niczym ważnym. Ktoś musi ułatwić komunikację między wszystkimi stronami.

Ten ktoś, ten bohater, jest kierownikiem projektu.

Toptal nie oferował umów z kierownikami projektów, kiedy zaczynałem pisać ten artykuł, ale teraz to robią. Synergia! Mogę sobie tylko wyobrazić, że moce, które przeczytały poniższe rady i zdały sobie sprawę, że zabrakło im wspaniałej okazji.

Dlaczego programista nie jest dobrym kierownikiem projektu

Pomijając certyfikat Project Management Institute, najważniejszą rzeczą, jaką kierownik projektu może wnieść do stołu, jest doświadczenie. W rezultacie wielu programistów byłoby całkiem przyzwoitymi kierownikami projektów; mamy większe doświadczenie w projektach technicznych niż ktokolwiek inny, a nasze umysły analityczne są biegłe w katalogowaniu informacji i wyznaczaniu konkretnych celów.

Bóg wie, płacisz nam wystarczająco dużo, więc wydaje się rozsądne oczekiwać, że damy sobie radę, zamiast zmuszać cię do płacenia za czyjś czas, prawda?

Cóż, na początek płacisz nam za kodowanie.

Kiedy wychodzimy z naszego programistycznego oszołomienia, aby podjąć decyzje dotyczące priorytetów lub spierać się o to, ile faktycznie zostanie do zrobienia w tym tygodniu, kod nie jest pisany. Następnie powrót do „strefy” zajmuje co najmniej 10 minut, zwłaszcza jeśli jesteśmy zestresowani rozmową, którą właśnie odbyliśmy, co jest prawdopodobne, jeśli kłócimy się o priorytet funkcji. Boo hoo, wiem, ale chodzi o jak najefektywniejsze wykorzystanie kosztownych zasobów.

Co najważniejsze, tak naprawdę nie widać lasu dla drzew. Jeśli nie wyciągniesz nic więcej z tego artykułu, zrozum, proszę, że: kiedy spędzam cały dzień wpatrując się w kilka konkretnych błędów, mój mózg traci orientację w szerszej perspektywie.

Mój mózg nagradza mnie, gdy naprawiam te błędy i zakładam, że zrobiłem świetne rzeczy i mogę teraz grać w gry wideo. Kiedy ktoś przypomina mi, że strona główna jest nadal zepsuta, jest to całkowite zaskoczenie, ponieważ spędziłem dzień wypełniając swój mózg bardzo szczegółową wiedzą o bardzo małym fragmencie całego projektu i zapomniałem o reszcie. Tak właśnie działa mój mózg, a wielu innych programistów ma podobny charakter psychologiczny.

Dlaczego klient nie jest dobrym kierownikiem projektu

No cóż, jeśli my, programiści, nie chcemy brać odpowiedzialności za wykonanie zadań związanych z zarządzaniem projektami, to musi to spaść do Ciebie, klienta. To twoje pieniądze. To twoja wizja. W każdym razie jesteś ostatecznie odpowiedzialny za całość.

Ty jednak też masz dużo na głowie.

Wielu klientów to zwykli śmiertelnicy, którzy pracują na co dzień, jak reszta z nas, a niektórzy nawet cierpią z powodu prokrastynacji lub zapomnienia. Chociaż to niekoniecznie opisuje ciebie, w szczególności rozważ pomysł posiadania profesjonalnego pamiętającego, aby móc wrócić do ważnej pracy polegającej na utrzymywaniu całego projektu przy życiu.

Jeśli pracowałeś lub nadzorowałeś projekt techniczny o podobnym zakresie, rzeczywiście możesz być dobrym menedżerem dla swojego projektu. Jeśli nie, proszę nie lekceważ wartości kogoś, kto może przewidzieć problemy, które mogą się pojawić. Szacunki czasu są zawsze tylko szacunkowe, a błędy zwykle pojawiają się w najmniej dogodnych momentach. Koszt innego (nawet w niepełnym wymiarze godzin) pracownika jest opłacalny, aby mieć wokół siebie kogoś, kto wie, które części procesu wymagają lub mogą wymagać największej uwagi.

Weźmy na przykład zapewnienie jakości (QA). Właściwa kontrola jakości jest niezbędna, aby uzyskać z każdego projektu to, czego chcesz, i nigdy nie przyciąga uwagi, na którą zasługuje. Dobry kierownik projektu maksymalnie wykorzysta ograniczone zasoby QA, a także zapewni jakość Twoich programistów. Czasami wychodzimy z głębi, a czasami popełniamy błędy. Potrzebujesz osoby sprawnej technicznie na stanowisku nadzorczym, aby ustalić, czy twój programista ma tylko dzień wolny, czy w rzeczywistości nie pasuje do projektu. Wczesne rozwiązywanie problemów kadrowych może oznaczać różnicę między życiem a śmiercią dla twojego projektu.

Wreszcie, nawet ty, klient, czasami potrzebujesz trochę kontroli i/lub równowagi. Trudno mi o tym pisać, ponieważ programiści komputerowi nie są dobrze znani z naszej otwartej natury. Dość powiedzieć, że pracowałem przy wielu projektach, w których klient stanowczo twierdził, że wszystko jest na pierwszym miejscu i absolutnie wszystko, co jest potrzebne do wykonania. Choć nie mam wątpliwości, że była to prawda, klienci ci niestety nie mieli kontroli nad liczbą godzin w ciągu dnia. Nie uzyskali pozytywnego wyniku, na który chcieli i/lub na który zasługiwali, i uważam, że tego wyniku można było uniknąć, gdyby klient powierzył kierownikowi projektu uprawnienia do oceny nakładu pracy i taktownego, ale zdecydowanego kontrolowania rzeczy . Trudno jest dokonać beznamiętnego osądu, którego wymaga większość projektów technicznych, kiedy to twój pomysł i twoje pieniądze są na linii, a komputer nie dba o to, czy ty czy ja płaczemy i krzyczymy na to. (Wiem, że to prawda, ponieważ próbowałem tego wiele razy.)

Niekompletna lista technik zarządzania projektem technicznym

Niezależnie od tego, czy zdecydowałeś się zignorować poprzednie 1000 słów i samodzielnie zarządzać swoim projektem, czy też zamierzasz kogoś zatrudnić, ale chcesz mieć większą wiedzę na temat procesu, ta lista pomoże Ci. Nigdy (oficjalnie) nie byłem kierownikiem projektu, więc nie mogę powiedzieć, jakich narzędzi używałby dany kierownik projektu, ale odniosłem dobry sukces we wszystkich tych technikach:

Kamienie milowe

Rozpoczynając nowy projekt, większość ludzi intuicyjnie wie, że ważne jest, aby podzielić projekt na nieco bardziej łatwe w zarządzaniu fragmenty, z których każda zawiera się w przedziale od kilku tygodni do kilku miesięcy pracy. Na początku projektu dobrze jest zorganizować spotkanie inauguracyjne, aby ustalić te kamienie milowe. W porządku jest trochę niejasne, jak do nich dotrzeć, najważniejszą rzeczą jest ciągłe sprawdzanie po każdym kamieniu milowym, aby skorzystać z lepszego zrozumienia projektu przez wszystkich i upewnić się, że kamienie milowe projektu są nadal ( z grubsza) ten sam rozmiar, jak początkowo sądzono.

Szacunki czasu

My, programiści, absolutnie nie znosimy szacunków, ponieważ wiemy, że będą one błędne i wiemy, że zostaną użyte przeciwko nam. To dobrze, że się mylą, ponieważ z definicji opierają się na kilku niewiadomych. To również w porządku, że są wykorzystywani przeciwko nam, ponieważ nasza praca jest dość wygodna i nie zaszkodzi trzaskanie bata od czasu do czasu.

Dlatego nie krępuj się prosić o szacunki za każdym razem, gdy rozpoczynają się prace nad nowym kamieniem milowym. Powinieneś spodziewać się linii lub dwóch dla każdej głównej funkcji wraz z przybliżonym oszacowaniem, jak długo ta funkcja zajmie. Zwykle dokonuję optymistycznych szacunków, a potem podwajam je. Najczęściej ten dodatkowy czas jest przyczyną niewidocznych pułapek.

Historie użytkownika

Historie użytkowników to krótkie opisy pojedynczych funkcji w aplikacji. Są przydatne jako zapis ważnych cech i powinny być wielkości kęsa, zmieścić się na fiszce i często towarzyszyć im mały rysunek. Co ważniejsze, służą jako pomost między tym, czego chce klient, a tym, co programista ma do powiedzenia komputerowi. Są one wystarczająco proste dla Ciebie, klienta, do wybicia w kilka minut, ale wystarczająco szczegółowe, abyśmy my, programiści, mogli w nie zatopić zęby.

Aby uzyskać kilka szybkich informacji na temat historii użytkowników, uważam, że samouczki autorstwa Mountain Goat Software i Romana Pichlera są wysokiej jakości i zwięzłe. Aby uzyskać więcej informacji na temat całej filozofii zwinnego zarządzania projektami, wypróbuj ten wpis na blogu Toptal The Ultimate Introduction to Agile Project Management autorstwa Paula Barnesa.

Kompozycje (makiety)

Nie jest to artykuł o tym, dlaczego potrzebujesz projektanta, ponieważ wydaje mi się, że większość klientów już to rozumie, ale warto go powtórzyć, ponieważ zobaczysz ogromny wzrost wydajności, jeśli przedstawisz programistom konkretny, przemyślany projekt. Za każdym razem, gdy musimy podjąć decyzję projektową, musimy opuścić „strefę” i za każdym razem musimy się cofnąć i coś zmienić, bo nie otrzymaliśmy ostatecznej wersji roboczej, no cóż, policzcie… ja' Nie narzekam, bo projektowanie jest fajne, ale z mojego doświadczenia wynika, że ​​jest to źródło nr 1 możliwych do uniknięcia, dodatkowych godzin pracy.

Większość projektantów udostępnia kompozycje, znane również jako kompozycje, w Adobe Photoshop, Adobe Illustrator lub Sketch. Jeśli robisz to sam, możesz skorzystać z jednego z niezliczonych narzędzi internetowych, takich jak Balsamiq czy InVision. Kompozycja nie musi mieć tych samych kolorów i stylów co gotowy produkt (ponieważ można je później łatwo zmienić), ale poświęć trochę czasu, aby upewnić się, że wszystkie elementy interfejsu użytkownika są obecne i uwzględnione.

Spotkania na stojąco

Długie spotkania są czasem nieuniknione, ale naprawdę nie chcesz przeciążać programistów ani zajmować więcej czasu niż to konieczne. Miałem klientów, którzy zdawali się oczekiwać, że zapamiętam wszystko, co zostało powiedziane podczas dwuipółgodzinnego spotkania; byli bardzo rozczarowani. Spotkanie stand-up jest zazwyczaj ograniczone do 15 minut i zwyczajowo stoi się przez cały czas. Aspekt stojący ma zapewnić wszystkim uczestnictwo, a także sprawić, by spotkanie było krótkie.

Podczas stand-upów wszyscy chodzą w kółko, aby przedstawić krótki raport o stanie, informując wszystkich członków zespołu o postępach innych. Więcej o stand-upach znajdziesz na ExtremeProgramming.Org. Jeśli wszyscy pracujesz zdalnie i nie chcesz, aby wszyscy codziennie korzystali ze Skype, możesz wypróbować zabawne narzędzie, takie jak 15Five, jako alternatywę dla stand-upów. 15Five pozwala członkom zespołu wnosić wkład w dogodnym dla nich momencie, a także poprosi ich o pytania ankietowe, aby uzyskać bardziej szczegółowe odpowiedzi.

System biletowy

Chociaż każdy może utrzymywać system karteczek samoprzylepnych i Dokumentów Google (z zadaniami każdego wyróżnionymi różnymi kolorami), to naprawdę nie jest to konieczne; wiele osób próbowało rozwiązać ten problem za Ciebie. Basecamp i Trello słyną z łatwości obsługi, podczas gdy Pivotal stara się zawrzeć całą filozofię „agile” w bardzo zgrabnym pakiecie. Niezależnie od Twojego wyboru, dobry system biletowy pozwoli Ci co najmniej:

• Twórz zadania
• Przypisz priorytet i termin
• Połącz zadania i podzadania
• Przypisz różne rozdzielczości, takie jak „zakończone” lub „nieudane testowanie”
• Pokaż wszystkie zadania przypisane do określonego użytkownika

Kiedy kierownik projektu pokaże Ci 40 jasnoczerwonych biletów o najwyższym priorytecie, które należy odebrać tego samego dnia, naprawdę zrozumiesz wartość tego projektu z lotu ptaka.

Kontrola źródła

Możesz nawet nie spojrzeć na kod w systemie kontroli wersji swojego projektu, ale kontrola źródeł (lub wersjonowanie) jest jednym z najważniejszych narzędzi, jakimi dysponujemy, najlepszym systemem tworzenia kopii zapasowych, jaki można sobie wyobrazić.

Większość nowoczesnych projektów używa Git, chociaż czasami natkniesz się na Subversion (SVN) podczas pracy nad projektami, które istnieją już od jakiegoś czasu. Github umożliwia hostowanie nieograniczonej liczby repozytoriów publicznych za darmo (plus zawiera większość światowych projektów open-source), podczas gdy Bitbucket umożliwia hostowanie nieograniczonej liczby prywatnych repozytoriów i dlatego jest preferowanym wyborem dla projektów komercyjnych.

Niezależnie od tego, który system kontroli wersji wybierzesz, przechowuje on nasz kod zdalnie na wypadek, gdyby coś się wydarzyło, a także śledzi za każdym razem, gdy „przekazujemy” mu kod, zmuszając nas do napisania krótkiej wiadomości opisującej, nad czym pracowaliśmy. Zapobiega to wzajemnemu nadpisywaniu kodu przez różnych programistów, pozwala nam zobaczyć wszystkie zmiany, które zostały wprowadzone w danym okresie, a także pozwala nam tworzyć nowe gałęzie kodu do przechowywania funkcji, które nie są uruchamiane od razu. Zawiera nawet komendę o nazwie „blame”, która pokazuje, kto był odpowiedzialny za daną linię kodu i kiedy została popełniona.

Kontrola źródła jest największa.

Rozwój oparty na testach

Jest to stosunkowo droga praktyka, co oznacza, że ​​nie jest często stosowana w projektach, w których budżet jest ograniczony do kilku freelancerów. Więc ty, jako startupowy przedsiębiorca, nie powinieneś czuć się źle, że tego nie robisz, ale muszę przed tobą rzucić ten pomysł, ponieważ zapewnia on najlepszą ochronę przed błędami. Zasadniczo Twoi programiści spędzają dodatkowe cenne godziny na pisaniu testów (małych bloków kodu), które zapewniają, że określone części aplikacji zachowują się w określony, przewidywalny i powtarzalny sposób. Na przykład mógłbym napisać test, który zapewnia, że ​​po kliknięciu przycisku „zaloguj się”, otworzy się wyskakujące okienko z polem nazwy użytkownika.

Piękno testów polega na tym, że po ich napisaniu mogę je wszystkie uruchomić jednym poleceniem. Jeśli mam napisanych 200 testów, mogę je uruchomić po wydaniu nowej wersji aplikacji, aby upewnić się, że w żadnej z tych 200 funkcji nie zostały wprowadzone żadne błędy. To nie jest idealne, ale jest tak blisko, jak możemy zagwarantować, że aplikacje są wolne od błędów (przynajmniej w wersji lite).

Zakończyć

To wszystko, co wiem o zarządzaniu projektami. Nie jestem pewien, jak wiele z tego przeszłoby na zebranie w Project Management Institute, ale to wszystko, co zdobyłem pracując nad projektami internetowymi w ciągu ostatniej dekady. Oczywiście radzę zatrudnić kogoś, aby czerpać korzyści z jego doświadczenia, ale mam nadzieję, że te informacje okażą się przydatne, nawet jeśli nie jesteś w stanie tego zrobić. Będziesz najwyższym autorytetem w tym projekcie, więc im więcej zrozumiesz jego wewnętrzne działanie, tym większe prawdopodobieństwo, że poprowadzisz go do zwycięstwa.