Dołączyłem do firmy, nad którą pracuję jako świeższy. Ze względu na ograniczoną liczbę wykwalifikowanych pracowników w zakresie tworzenia oprogramowania GIS, a ponieważ byłem jednym z nich, zostałem bezpośrednio zatrudniony jako kierownik projektu.
Znałem się dobrze z Javą i GIS i przeprowadziłem samodzielnie zmotywowane badania usług opartych na lokalizacji, ale nie z zarządzaniem projektami i programowaniem strukturalnym. To było rok po ukończeniu specjalizacji z geologii, a podczas poprzedniego roku pracowałem jako nauczyciel akademicki na uniwersytecie.
Dzięki zainteresowaniu, jakie miałem w pracy, pojawiła się okazja i ostatecznie zostałem również odpowiedzialny za dział Business Intelligence firmy. Firma we mnie uwierzyła. Sam studiowałem koncepcje hurtowni danych i BI i udało mi się również połączyć GIS z BI.
Obecnie współpracuję z dwoma programistami nad naszym narzędziem BI w C # WPF, w którym czasami gram rolę programisty (co lubię).
Bardzo starałem się zastosować dobre metodologie tworzenia oprogramowania przy zwinnym zarządzaniu projektami, ale nie było to bardzo udane. Ponadto, chociaż wierzę w dobrze zaprojektowany kod, jeśli chodzi o produkt, z powodu braku wiedzy technicznej mojego CEO (który jest bezpośrednio nade mną), zwykle nie mam czasu potrzebnego na to. Czas ten znacznie poprawia brak wiedzy specjalistycznej w zakresie konkretnego języka kodowania jako całości (na przykład WPF w przeciwieństwie do Javy). Nie ma również systemu kontroli wersji.
Jestem bardzo zmęczony sposobem, w jaki wszystko idzie, ponieważ nie jest on ustrukturyzowany i spędzam większość czasu zastanawiając się nad tym, jak uporządkować rzeczy. Mam nadzieję, że z dobrym doświadczeniem zawodowym pomożesz mi przezwyciężyć tę sytuację.
Odpowiedzi:
Mieliśmy podobny problem (oczywiście bez szczegółów technicznych) w firmie, w której pracuję około dwa lata temu.
Musisz to zrobić krok po kroku. Nie staraj się szybko wdrażać zwinnego oprogramowania. Jest wiele rzeczy do nauczenia się i zastosowania. Nie pozwól też, że brakuje ci wiedzy specjalistycznej.
Buduj powoli (ale tak szybko, jak to możliwe: P), stabilnie i pewnie.
Poleciłbym kolejne kroki (aby to zrobić, możesz na chwilę przełączyć się z zarządzania na rozwój, ale to powinno być w porządku)
Jeśli to możliwe, zatrudnij konsultanta, aby mógł sprawdzić proces i udzielić lepszych porad.
Nie bądź leniwy ani zniechęcony. Po prostu ucz się na swoich błędach i wypróbuj różne podejścia. To dopiero początek!
Edytować:
Oto niektóre linki i książki, które ostatnio czytałem / używam ...
Uczenie się git: Pro Git
Oto niektóre z blogów, które poleciłbym (większość z nich jest zorientowana na platformę .NET):
W przypadku książek możesz zobaczyć listę Buiding A Solid Programming Core na Amazon. Poleciłbym również te:
źródło
Jako menedżer Twoim zadaniem jest uzyskanie czasu potrzebnego do prawidłowego ukończenia projektu. Zbliżając się do dyrektora generalnego, upewnij się, że masz wszystkie dane , które Cię popierają, i powody, dla których szacunki są tak samo długie. To twoja odpowiedzialność jako kierownik aby uczynić prezes zrozumieć, dlaczego to trwa n godzin / dni / tygodni do ukończenia danego zadania. Czasami może to być trudne, ale nie spotkałem prezesa, który chciałby , aby jego firma upadła, i założę się, że jeśli powiesz to w takich kategoriach (jeśli wszystko inne zawiedzie), może zmienić melodię.
Jeśli dyrektor generalny nie chce dać ci czasu potrzebnego na wykonanie zadań, to IMHO bądź gotowy przejść do innej pracy lub przygotować się na ciągłe marsze śmierci. W ostateczności wyjaśnij dyrektorowi generalnemu wypalenie, które bez wątpienia wyniknie z nierealnych oczekiwań.
Powiedziawszy to, musisz także upewnić się, że programiści dostarczają ci dokładnych szacunków (niezwykle trudne, prawie niemożliwe bez odpowiednich projektów technicznych, które również powinny gdzieś tam być).
Zwinność nie jest dobra we wszystkich domenach programistycznych. Działa w przypadku niektórych typów projektów, w innych niestety zawiedzie. Być może będziesz musiał wypróbować kilka różnych metodologii, zanim znajdziesz taką, która działa dobrze .
Skonfiguruj kontrolę wersji . Naprawdę zajmuje to 5–10 minut, aby skonfigurować Git, jeszcze kilka minut, aby uprościć podstawowe operacje, i dzień lub dwa czytanie, aby upuścić bardziej zaawansowane koncepcje.
źródło
Hmm, nie jestem pewien, czy spotkałem cię na imprezie Agile / XP w Toronto - brzmi znajomo
Wygląda na to, że potrzebujesz przerwy. Spędź długi weekend, upij się, jeśli chcesz, i zapomnij o pracy na kilka dni.
Uspokój się. Samokształcenie jest dobre i tylko dlatego, że metodologia nie działa z zaangażowanymi osobowościami, nie oznacza, że robisz to źle i nie jest to osobista porażka.
Istnieje strona (beta) pm.stackexchange.com, skierowana do zarządzania projektami, możesz tam znaleźć przydatne porady / wsparcie - ale na pewno nie zapomnij o tym tutaj.
Przechodząc do rzeczy technicznych:
Postaw jeden jako najwyższy priorytet. Wolę scentralizowane systemy, takie jak SVN (Subversion), niż git / mercurial, ponieważ skradziony laptop nie będzie miał tak dużo historii lokalnie. Szczególnie ważne, jeśli coś super tajnego (np. Hasła i klucze ssh) zostało przypadkowo wpisane. Ale to kwestia gustu. Nic nie marnuje więcej czasu niż błędy z „ręcznej kontroli wersji” - np. Przywracanie kodu do tego, co myślisz.
Powodzenia
źródło
Wygląda na to, że masz kilka problemów: 1. Komunikowanie się z nietechnicznym kierownictwem wyższego szczebla, aby mogli wspierać Twój program doskonalenia; oraz 2. Prowadzenie programu usprawnień do sukcesu.
Najtrudniejszą częścią numeru 1 jest po prostu pamiętanie, że kierownictwo wyższego szczebla często nie będzie zainteresowane szczegółami tego, nad czym pracujesz. (Gdyby tak było, robiliby to sami, zamiast wręczać to tobie!) Wydaje się, że wielką przeszkodą jest „dlaczego” i możesz spojrzeć na CMM 1.1 w celu uzyskania opisu korzyści biznesowych z udoskonalenia procesu program. Niezależnie od tego, czy użyjesz CMM, czy czegoś innego do faktycznego ulepszenia swojego procesu, nie będzie to miało znaczenia w tej dyskusji, tylko dane z badania Carnegie-Mellon, które pokazuje, że bardziej dojrzałe organizacje dostarczają projekty szybciej przy mniejszym zróżnicowaniu czasu dostawy.
Istnieje wiele dróg do sukcesu w procesie doskonalenia procesów, wszystkie są zwykle bardzo długie. Doświadczenie z CMM pokazuje, że przejście z poziomu 1 na 5. może zająć od 8 do 10 lat. Doświadczenie z 6 sigma pokazuje, że każda iteracja daje pewną poprawę, ale potrzebuje wielu iteracji, aby usunąć większość potencjalnych problemów i zanim do niej dojdziesz 6 znaków jakości, praca jest wykonywana zupełnie inaczej, bez ryzyka podjęcia próby zastąpienia wszystkiego na raz.
Jeśli w twojej branży powszechnie stosowane jest podejście do poprawy jakości, poświęć trochę czasu, aby sprawdzić, jak ma ono zastosowanie do oprogramowania i użyj go, aby reszta firmy słyszała o czymś, co już zna i wspiera. Możemy godzinami rozmawiać o konkretnych narzędziach i praktykach programowych, ale dyrektorzy generalni niebędący programistami szybko się zorientują. Porozmawiaj o standardowych praktykach branży, a on ożywi się, ponieważ mówisz w jego języku. Porozmawiaj o oprogramowaniu w typowych warunkach branżowych, a on zacznie zadawać odpowiednie pytania, aby lepiej zrozumieć Twoje wyzwania i Twoje plany poprawy wyników firm.
W ten sposób nie wygrasz każdego prośby o wsparcie, prawdopodobnie dostaniesz o wiele mniej pustych spojrzeń i więcej wygranych!
Powodzenia, proszę pana!
źródło
Wszystkie wasze sugestie są rzeczywiście rozsądne i są drogą dla wielu firm. Ale nie są uniwersalne, szczególnie w zespołach, które nie są tak doświadczone. Powodem, dla którego tak nie jest, jest to, że wymagają trochę pracy, aby skonfigurować i utrzymywać - nawet kontrolę wersji - co wielu uważa, że jest to stawka dla każdego projektu oprogramowania. Ponieważ wymagają one trochę pracy, muszą również zapewnić pewne korzyści. I może być tak, że w twojej konkretnej sytuacji tak nie jest! A przynajmniej ludzie, których zadaniem jest podejmowanie decyzji, nie widzą korzyści!
Jak zauważyli inni, musisz:
źródło