REORGANIZACJA grupy "Madagaskar" (pomysły)

Realizujemy po kolei (przegłosowane przez nas wszystkich) priorytety na II półrocze 2015. 2 pierwsze pozycje są już wdrożone, 3 kolejne w trakcie:
https://docs.google.com/spreadsheets/d/1mK75LlDhjftvZrG_jC7GxFCtjutAjemeaKuttHo-L-M/edit?usp=sharing

4-tym z kolei priorytetem (o randze 3) jest punkt: "Zmienić struktury/organizację projektu" i właśnie o tym punkcie jest ten wątek.
Kilka os. pisało wprost, że o wiele bardziej zaangażowałby się w "Madagaskar" gdyby nasza grupa miała inną organizację. M.in te osoby (a tak na prawdę to - każdy uczestnik)właśnie mają szansę przeforsować korzystną dla nich organizację naszej grupy.

Jeżeli ktokolwiek z Was ma swoją wizję nowej organizacji grupy "Madagaskar", to niech proszę ją przedstawi w tym wątku .Wasz post może zawierać link (np. do publicznego dokumentu na gdrive) do jakiejkolwiek, bardziej obszernej prezentacji (np. do pdfa przedstawiającego Wasz koncept). Pisząc o "organizacja" NIE mam na myśli takich kwestii jak zintegrowanie narzędzi w projektu w platformę Web (to temat ważny ale dot. Infratruktury a nie organizacji , z resztą ten temat jest wdrażany przez Michu). Przez pojęcie "organizacja" rozumiem np:

• zasady egzaminowania;
  
• podziały na zespoły;
  
• zasady rotacji grupy;
  
• liczebność grupy "Madagaskar";
  
• role w uczestników w "Madagaskarze";
  
• itp.
  

Proszę jednak nie bać się ewentualnych nieporozumień i wstawiać tu własne koncepty na (w Waszym rozumieniu) organizacyjny aspekt funkcjonowania "Madagaksaru"

Ja sam mam przeświadczenie, że trzeba (znowu!) wprowadzić kilka radykalnych zmian w naszej organizacji , a swój pomysł przedstawię tutaj najpóźniej za tydzień (proszę nie czekać na mnie tylko wcześniej zgłaszać własne pomysły).

W tym wątku obowiązuje wolna amerykanka co do dyskusji. W dowolnym momencie można zgadzać/niezgadzać się (+argumentować) z poszczególnymi elementami przedstawianych tu konceptów (w kolejnym wątku będzie zakaz dyskusji a już tylko głosowanie).

Czas na umieszczanie pomysłów w tym wątku, to 3 tygodnie: do 11-go października 23:59.

powodzenia (odkryjcie w sobie talent inżyniera procesów :p )

Może to drobny pomysł, ale przydała by się jakaś mikro-gałąź do aktualizowania pierwszych, przestarzałych zadań.
Jestem nowym członkiem grupy madagaskar posiadającym już jakieś umiejętności przed dołączeniem do zespołu. Wykonuję akurat zadanie 04 i zdecydowanie - pierwszym warsztatom poważnie przydało by się pewne odświeżenie. Aktualizacja materiałów szkoleniowych, wykonanie filmiku w VS 2013 lub 2015, mile widziane dodanie dźwięku. Nie piszę tego z magicznym, leniwym podtekstem "niech ktoś" - sam chętnie ofiaruję swój czas i jak tylko zakończę zaliczać te pierwsze warsztaty mogę pomóc w ich aktualizacji.

Ale dlaczego? W Visual Studio 2010 jest dobrze!
- Jest dobrze, ale może być lepiej. Jeżeli obecnie dołączy ktoś, kto dopiero zaczyna przygodę z programowaniem od zera, nie ma sensu aby przyswajał sobie VS 2010. Ja korzystam z wersji 2013 i dostrzegam pewne subtelne różnice, lepiej oswajać się wizualnie z interfejsem aktualnego oprogramowania (sam z 2015 jeszcze nie miałem do czynienia).

Dźwięk nie jest potrzebny
- Jest przydatny. Gdy dołączyłem do was w sierpniu uważnie przejrzałem forum i zauważyłem że temat udźwiękowienia filmów był już wałkowany. Jeżeli pojawiło się wtedy konkretne rozwiązanie to proszę ten podpunkt pominąć. Jeżeli jednak temat umarł śmiercią naturalną to warto do niego wrócić. Serio, oglądanie niemal godzinnych materiałów w idealnej ciszy jest bardzo złym środowiskiem do przyswajania informacji. Wykorzystanie tylko wzroku do nauki jest nieefektywne, gdyby jakikolwiek lektor czytał TO SAMO co jest napisane, uczeń wykorzystał by kolejny zmysł zwiększając w ten sposób znacząco efektywność nauki.

P.S. - chyba w poprzednich postach się nie przywitałem, więc witam wszystkich

burgund napisał:Może to drobny pomysł, ale przydała by się jakaś mikro-gałąź do aktualizowania pierwszych, przestarzałych zadań.
Jestem nowym członkiem grupy madagaskar posiadającym już jakieś umiejętności przed dołączeniem do zespołu. Wykonuję akurat zadanie 04 i zdecydowanie - pierwszym warsztatom poważnie przydało by się pewne odświeżenie.

Pierwsze moje odczucie było takie, że poruszasz temat NIE dotyczący organizacji projektu, ale poprawy treści (w Twoje propozycji - laborek) jakie nasza grupa oferuje (czyli wydawałoby się że proponujesz coś nie na temat). Ale ale ! ...
... po dłuższym zastanowieniu dotarło do mnie, że podchodzisz do tematu z organizacyjnego punktu widzenia - ponieważ proponujesz wydzielenie dedykowanej gałęzi w projekcie - i tu muszę uznać to za pomysł godny rozważenia (brawo!). Temat lektora proponowałem w priorytetach na pierwszą połowę 2015 (moja propozycja umarła). To że ten temat wraca ze zdwojoną siłą mnie nie dziwi. Ja bym poszedł o krok dalej (względem tego co proponujesz) - wykonać "odświeżenie" warsztatów (o którym wspominasz) ale nie poprzez wyprodukowanie (na nowym Visual Studio)  nowych wideo z lektorem , ale poprzez wyprodukowanie (owszem na Nowym Visualu) laborek ale w nowej formule jak (niedawno opublikowany) w17, tu przykład:
https://docs.google.com/document/d/1F821OR-p93SR8yCPtu4tCfxa_9-zNJBEFbKLd_2p37w/edit?usp=sharing

Chętni producenci takich odświeżonych unitów nie będą musieli się przebijać przez metodologię nagrywania i montowania wideo, tylko mają proste narzędzie to płodzenia tekstów , zrzutów ekranów i mogą jechać z koksem (ja mogę im wysyłać zrzut z całego tekstu z wideo, który potraktują jako ściągę do prawie "zerżnięcia żywcem" do odświeżonego materiału). Problemem (do wykonania tej akcji) jest aktualnie mała moc przerobowa na jakiekolwiek akcje rozwojowe w "Madagaskarze". Szacuję że tylko jakieś 10%-20% uczestników pracuje na rozwój grupy . Zamierzam za kilka dni zaproponować taki pomysł (w tym wątku) na reorganizację, że (jeśli się uda) min 50% z docelowo 200 uczestników będzie chętnych do działania, a wtedy znajdą się chętni również na "odświeżenie" laborek. Szczegóły wkrótce (płodzę prezentację :p). Bo wyzwaniem (wg mnie) który musimy rozwiązać w aktualnej organizacji grupy "Madagaskar" są 2 (równoległe) zjawiska:

• znowu rosnąca kolejka chętnych do wejścia do naszej grupy;
  
• aktualnie niewielki % aktywnych uczestników w projekcie (nie chcę od razu "sprzątać" tych ludzi, chcę wykorzystać szansę aktywowania ich w naszym zespole do działania  bo pewnie sporo wartościowych ludzi w ekipie mamy "uśpionych");
  

Darujcie kolejny wpis-elaborat. Czekam na kolejne propozycje (lub na kontynuację dyskusji dot. propozycji burgunda)

1. Zasady egzaminowania
Uważam, że zasady egzaminowania powinny zostać takie same z jedną zmianą. Kamienie milowe- za zaliczenie 5-10 warsztatów. Co do poprawiania warsztatów z VS 2010, uważam że jeśli mamy to zrobić to tak aby były jednolite z resztą – brak ankiet, instrukcje w formie pdf z ewentualnymi zrzutami ekranów

2. Podziały na zespoły
Kamienie milowe miałyby służyć głównie temu, aby uczestnik, który zdobył już jakieś doświadczenie (30 warsztatów przykładowo, nie ważne czy programuje już czy dopiero zaczął tylko po tym możemy oceniać to doświadczenie na tym etapie), zostałby przydzielony do grupy innych użytkowników i jednego group managera. Każda grupa miałaby do napisania wspólnie jakąś aplikację – temat narzucony odgórnie lub technologie, manager by przydzielał do zadań, sprawdzał wykonanie itp. (praca zespołowa). Myślę, że to dobry pomysł, bo każdy jest w stanie coś zdziałać jedni zrobią prostsze rzeczy bo mają mniej kamieni milowych, inni zrobią coś bardziej skomplikowanego, a managerowie mogą również brać udział w kodowaniu. Obecnie tylko zaawansowani użytkownicy mogą programować,a myślę że dla nich też byłoby wyzwaniem zarządzać teamem mniej doświadczonych uczestników czy być po prostu tą grupą najlepsza. Do tego można dorzucić kamienie milowe drużyny i ranking- zdrowa konkurencja dodatkowo zachęci do rozwoju.

3. Zasady rotacji grupy
Uważam, że grupa zarządzająca projektem powinna być podzielona na:
- administrację (facebook, strona, forum, zarządzanie zespołami, promocja)
- projektowanie (nowe warsztaty, zadania dla grup programistów, instrukcje, korekta)
- egzaminowanie (egzaminacja grup oraz uczestników)

Rotacja myślę, że w tych grupach powinna być w miarę dowolna np. po okresie 3 miesięcy możemy przejść do innej grupy, dzięki czemu każdy zapozna się z zasadami każdego działu i będzie mógł w przyszłości wybrać co najbardziej mu odpowiada – wybór stałych przewodniczących tych grup.

Rotacja w grupach programistycznych wspomnianych w punkcie drugim powinna być ograniczona, lider powinien być stały, a liczba w grupie powinna być po prostu równana – większa sprawiedliwość. Stała współpraca zapewnia większą efektywność i integrację uczestników.

4. Liczebność grupy "Madagaskar", mechanizm ostrzeżeń
Liczebność powinna być ograniczona moim zdaniem ale procentowo. 20-30% to zespoły zarządzające z punktu 3, zaś reszta to uczestnicy, jednak maksymalnie łączna ilość to 200 osób, myślę, że tyle wystarczy. Ważniejsza jest proporcja, tak aby wszystko sprawnie działało, bo przy 180 uczestnikach i 20 osobach odpowiedzialnych może być ciężko zachować porządek.

System ostrzeżeń- brak progresu w warsztatach 3-4 miesiące powoduje otrzymanie ostrzeżenia, 3 punkty i wycofanie z grupy na pewien okres lub całkowicie. Chętnych będzie przybywać jeśli grupa będzie się rozrastać i prężnie działać. Co do zadań w grupach programistycznych to już kwestia dogadania, bo okres wakacyjny czy świąt będzie powodował pewne roszady.
5. Role w uczestników w "Madagaskarze"
Uczestnicy projektu Madagaskar powinni wykonywać warsztaty, a po uzyskaniu odpowiedniego kamienia milowego dołączyć do grupy i spełniać zadania ustalone przez project managera.

Mam świadomość , że pomysły nie są doskonałe. Jednak jedynie burza mózgów możemy dojść do ciekawych rozwiązań. Jedyne czego powinniśmy unikać to zbyt dużej szczegółowości. Ilość plików w warsztatach osobiście jest dla mnie spora, a do tego dochodzą katalogi. Na dysku gogle może przyjemnie to wygląda, ale po ściągnięciu uważam, że jest to dosyć zbyt rozbite. Co do warsztatów to może warto udostępnić jednego pdfa aktualizowanego o nowe warsztaty z rozdziałami – rozdział to kolejny warsztat, dodać loga i wygląd grupy Madagaskar i mamy materiał reklamowy w postaci instrukcji, która nawet jak wyjdzie na zewnątrz to i tak ludzie z ciekawości zajrzą co to jest ten Madagaskar i może zostaną.

Sorry za ilość ale krócej nie dałem rady tego wyjaśnić.
Pozdrawiam!

Nemiz napisał:Sorry za ilość ale krócej nie dałem rady tego wyjaśnić.

Nie martw się, ja właśnie trzaskam 6-tą stronę specyfikacji mojego pomysłu na reorganizację :p (chyba wstawię ją tu w sobotę w nocy)

A więc przedstawiam mój pomysł na reorgzanizację (tylko 9 str :p )
https://docs.google.com/document/d/14BUa94e_8m4wrLYiKvSAGV8Bl18JNaJTX_-YCksUHUs/edit?usp=sharing

Proszę piszcie czy wam się podoba, czy Wam się nie podoba, co byście zmienili.

@Nemiz część z Twoich założeń pokrywa się z moimi, napisz więc proszę (z tych elementów które się u Ciebie różnią) co podtrzymujesz z czego się wycofujesz itp. (po lekturze mojego dokumentu).

Czekam na Wasze uwagi, ale też Wasze pomysły na reorganizację 
... decyzje zacznę (wspólnie z Wami) podejmować wkrótce !

W newslettrowym anonsie (do wszystkich) dot. tego wątku wspomniałem o pomysłach moich i Nemiza, a nie wspomniałem nic o zgłoszonym tu pomyśle burgunda. Bardzo przepraszam za to (wtopa).

Witam

Dawno nie pisałem na forum, a ten wątek jest (IMHO) obowiązkowym dla KAŻDEGO z nas!

Sam pomysł utworzenia/zmiany grup i ich w nowy sposób "zapisania" jest trafny. Mam kilka uwag/pytań:

a) Grupa Developów powinna być (początkowo) mniejsza (ok.150 osób), powiększać się do docelowej (200) w miarę zapotrzebowania. Prawdopodobnie, jeżeli powyższe zostanie przyjęte trzeba będzie zmniejszyć odsetek w "ogonie" np.do 20%

b) Czy punkty uzyskane w warsztatach na "kamieniach milowych" będą "chronić od znalezienia się w "ogonie" dev-ów?

c) Obecnie mamy 39 miejsc "zamrożonych" w warsztatach (po chłopsku: od 14 lab w górę student ma nielimitowany czas na zalkę wyższej laborki (nie dotyczy 17 warsztatu bo jest najwyższy); proponuję podwyższyć to do 16 warsztatu.

d)  Proponuję aby w pliku Raporty osobno prowadzić arkusz Studentów a osobno arkusz Developerów ( wiem, że na arkuszu developów znajdowaliby się również Studenci - niedopuszczalne z punktu bazodanowca (to cios w Twoje ITSerce Koszmarku:)) albo przynajmniej aby te tabele były wyświetlane w osobnych arkuszach (tak chyba lepiej...?)

e) co do terminów wprowadzenia wymagań  - według mnie nie ma co czekać - trzeba wyczyścić projekt z uczestników, którzy już o projekcie zapomnieli (przykładem może być część osób z listy Zespół Wsparcia)  i wprowadzać nową krew (tutaj proszę bez obrazy)
Tylko szybkie, czyste cięcie może wyklarować projekt  - na początku na pewno będzie ciężko ale nie bawmy się w NFZ i nie liczmy "martwych dusz".

To na razie tyle ode mnie, i jeszcze raz piszę: pomysł jest super! Trzeba rozbić projekt i poskładać go na nowo!
Pozdrawiam
Tomtom

P.S. Co do czasu wdrożenia to można odpalić ankietę...

Podpunkt c) popieram. Czasu na wykonanie zadań i tak jest wystarczająco.
Co do podpunktu d), to z bazodanowego punktu widzenia wystarczy każdemu członkowi grupy nadać indywidualne id i już można tworzyć tabel i arkuszy ile się zechce.

tomtom1 napisał:
a) Grupa Developów powinna być (początkowo) mniejsza (ok.150 osób), powiększać się do docelowej (200) w miarę zapotrzebowania. Prawdopodobnie, jeżeli powyższe zostanie przyjęte trzeba będzie zmniejszyć odsetek w "ogonie" np.do 20%

Rozumiem, tak jak pisałem w dokumencie - tego typu parametry będę traktował jako "suwaki" które będę ustawiał w zależności od rozwoju wypadków

tomtom1 napisał: b) Czy punkty uzyskane w warsztatach na "kamieniach milowych" będą "chronić od znalezienia się w "ogonie" dev-ów?

Nie. Wynika to z ustalenia jakie mieliśmy z rok temu, czyli że student za zaliczenie warsztatu szkoleniowego nie dostaje punktów w "rejestratorze", tym samym nie pnie się w górę w rankingu deweloperów w "rejestratorze". Egzaminator z kolei za przeegzaminowanie tego studenta dostaje punkty w "rejestratorze" jako szerokorozumiany Deweloper "Madagaskaru" (podobnie jak koordynator egzaminów za skoordynowanie egzaminu).

tomtom1 napisał:c) Obecnie mamy 39 miejsc "zamrożonych" w warsztatach (po chłopsku: od 14 lab w górę student ma nielimitowany czas na zalkę wyższej laborki (nie dotyczy 17 warsztatu bo jest najwyższy); proponuję podwyższyć to do 16 warsztatu.

Powiem więcej. Mój pomysł z tą "krechą" 80% wyszkolenia = brak terminów okazał się nietrafiony. Za niedługo wycofam się z tego pomysłu (niech karty przedłużenia będą jedynym artefaktem, chroniącym studenta przed poślizgami w terminach).

tomtom1 napisał:d)  Proponuję aby w pliku Raporty osobno prowadzić arkusz Studentów a osobno arkusz Developerów ( wiem, że na arkuszu developów znajdowaliby się również Studenci - niedopuszczalne z punktu bazodanowca (to cios w Twoje ITSerce Koszmarku:)) albo przynajmniej aby te tabele były wyświetlane w osobnych arkuszach (tak chyba lepiej...?)

Aj tam aj tam (jaki cios?) Ależ ja właśnie taki mam plan ! Będą 2 listy w dwóch arkuszach. Pierwsza (ważniejsza) to będzie lista Deweloperów właśnie. Drugi (osobna bajka) to będzie lista studentów z gałęzi szkoleniowej. Będzie to 100 Deweloperów którzy zdecydowali się dodatkowo szkolić , a więc będzie to 100 dubli wpisów z pierwszego arkusza (dla mnie żaden problem).

tomtom1 napisał:co do terminów wprowadzenia wymagań  - według mnie nie ma co czekać

Też się ku temu pomału skłaniam.

Odnośie zmian zaproponowanych przez koszmarka:
Organizacja:
Uważam, że brak specjalizacji faktycznie jest lepszym pomysłem niż zaproponowany przeze mnie podział. Mam nadzieję, że uczestnicy warsztatów nie wyjdą z założenia "wszystkich, czyli niczyje" i nie zaniedbają dobra ogółu. Liderzy każdej gałęzi to bardzo dobre rozwiązanie. Dodatkowe role na pewno wyjdą w trakcie rozwoju grupy.

Do czego mam zastrzeżenia to ich ilość odpowiedzialnych osób- 13 to trochę mało. Uważam, że powinniśmy utrzymać wspomniane przeze mnie 20% całej ilości.

Drugą sprawą do jakiej mam zastrzeżenia to możliwość rozwoju poza szkoleniami. Uważam, że projekty paro osobowe byłyby świetną okazją sprawdzenia swoich umiejętności pracy w zespole oraz podziałem różnych zadań. Dlatego podtrzymuję propozycję wprowadzenia podziału na zespoły. Można by dołączyć do tego projekty jakie może/ musi wykonać grupa aby zostać zaakceptowana (jakaś aplikacja, tak aby zobaczyć czy zespół ma szansę się utrzymać). Nawet jeśli to będą 3-4 zespoły 5 osobowe to i tak uważam, że może dodatkowo zachęcić to nowych użytkowników, żeby dołączyć do takich zespołów i zacząć od prostych rzeczy, ale czuć że jest się częścią projektu, za który ponosimy odpowiedzialność.

Upublicznienie i kalibracja:
Uważam, że wdrożenie zmian odnośnie wycofywania nieaktywnych uczestników powinno zacząć się od teraz ale z wydłużonym okresem na aktywność i podwyższyłbym te kryteria przy sporym napływie, tak aby uczestnicy, którzy chcą się zapisać też nie "stali" w kolejce , bo na pewno to ich zniechęci.

Nemiz napisał:Odnośie zmian zaproponowanych przez koszmarka:
Drugą sprawą do jakiej mam zastrzeżenia to możliwość rozwoju poza szkoleniami. Uważam, że projekty paro osobowe byłyby świetną okazją sprawdzenia swoich umiejętności pracy w zespole oraz podziałem różnych zadań. Dlatego podtrzymuję propozycję wprowadzenia podziału na zespoły. Można by dołączyć do tego projekty jakie może/ musi wykonać grupa aby zostać zaakceptowana (jakaś aplikacja, tak aby zobaczyć czy zespół ma szansę się utrzymać). Nawet jeśli to będą 3-4 zespoły 5 osobowe to i tak uważam, że może dodatkowo zachęcić to nowych użytkowników, żeby dołączyć do takich zespołów i zacząć od prostych rzeczy, ale czuć że jest się częścią projektu, za który ponosimy odpowiedzialność.

To ma dla mnie sens ! (będę myślał). U nas w firmie (w dziale) mieliśmy pawie 20 os. zespół Scrumowy (za duży !). Jak zostały rozbite na 2 mniejsze zespołu (po około 5 deweloperów 2 testerów 1 analityk itp.) to nagle wszyscy zaczęli intensywniej "trzaskać" swoją robotę (poczuli się bardziej odpowiedzialni za efekt pracy) ... u nas może być podobnie. ... np. Stravi proponuje (bo nie może kazać, może tylko motywować) jakąś akcję programistyczną w gałęzi deweloperskiej "wszystkim" (bo takie ma wytyczne ode mnie) ... może dlatego temat idzie na razie dość wolno ..  przemyślę to !!

Nie wiem czy to coś wniesie do tematu, ale można założyć grupę na gitter co mogłoby być wygodniejsze do zadawania jakiś pytań czy nawet zwykłej luźnej dyskusji, czy też nawet jak tu wspominano do podziału na grupy np warsztat od 1-10 itd itd. Ludzie mogli by dzielić się swoimi problemami, doświadczeniami i pogadać

Stefanoww napisał:Nie wiem czy to coś wniesie do tematu, ale można założyć grupę na gitter co mogłoby być wygodniejsze do zadawania jakiś pytań czy nawet zwykłej luźnej dyskusji, czy też nawet jak tu wspominano do podziału na grupy np warsztat od 1-10 itd itd. Ludzie mogli by dzielić się swoimi problemami, doświadczeniami i pogadać

A czy poniższa gałąź mniej lub bardziej nie spełnia tego wymagania ? (czy może chodzi Ci coś o jeszcze innego):
https://madagaskar.forumpolish.com/f7-4-inne

Co do uwag dot. laborek też jest wydzielona gałąź. Daj znać proszę czy o to właśnie Ci chodzi czy o jeszcze coś innego. Pozdr !

Nemiz napisał:Do czego mam zastrzeżenia to ich ilość odpowiedzialnych osób- 13 to trochę mało. Uważam, że powinniśmy utrzymać wspomniane przeze mnie 20% całej ilości.

Ja raczej nie będę podchodził do obsadzania ról w ten sposób żebyśmy osiągali jakiś wyznaczony pułap np. 20% załogi to os. decyzyjne. Na razie obsadzam rolę jeżeli pojawia się potrzeba. Natomiast dobry news dla Ciebie jest taki, że będę musiał wkrótce obsadzić rolami specjalnymi kolejne 3 (chętne) os:

• co najmniej 1-go Kontrolera Jakości Kodu ("Master Code Reviewer") oraz 1-go Właściciela PRoduktu ("Product Owner") dla próbnej aplikacji której dewelopment chyba zaczyna się rozkręcać w naszej eksperymentalnej "fabryce": https://madagaskar.forumpolish.com/t153-todo-app-funkcje-wymagane-i-opcjonalne
  
• 9-go egzaminatora (dla laborek nr 17 oraz produkowanej 18)
  

... a więc będzie już min 16 os. stanowiących kręgosłup operacyjny "Madagaskaru".

pozdr !

Ważne, żeby było ich wystarczająco, jeśli osoby te podołają przy większej ilości uczestników to wiadomo, że na siłę nie ma sensu dokładać.

Chętnie bym coś zrobił dla ogółu ale chyba na razie wiedza nie pozwala

Pozdrawiam!

Finalizuję akcję.
Poniżej przedstawiam listę zmian organizacyjnych które mam zamiar wprowadzić (tych na bazie moich pomysłów, ale też na bazie pomysłów oraz uwag innych uczestników). Darujcie, że nie uruchomię tu ankiety (choćby dlatego że wątek ten nie cieszy się jakimś ogromnym zainteresowaniem). Wypowiedzcie się proszę finalnie, czy dacie mi zielone światło na wdrożenie poniższego zestawu zmian (przy czym z części tych zmian się wycofam, jeżeli okażą się "w praniu" nietrafione):

Zacznę od zestawu moich propozycji zmian (na bazie poniższej prezentacji którą tu wcześniej serwowałem) :
https://docs.google.com/document/d/14BUa94e_8m4wrLYiKvSAGV8Bl18JNaJTX_-YCksUHUs/edit?usp=sharing):

• upublicznię warsztaty szkoleniowe (przyczyny podane w pow. dokumencie) - zrobię to w chwili gdy liczba os chętnych do dołączenia do grupy "Madagaskar" znacznie przewyższy liczbę miejsc wolnych;
  
• wszyscy uczestnicy w grupie "Madagaskar" staną się jej tzw. DEWELOPERAMI. Słowo Deweloper w “Madagaskarze” nie oznaczałoby stricte programisty, a (slangowo określając) “rozwojowca” projektu - osobę która wykonuje najróżniejsze aktywności ROZWOJOWE dla grupy (detale oczywiście opisane w dokumencie z pow. linka);
  
• "Zespół Wsparcia" przestanie istnieć - Proszę mnie źle nie zrozumieć - usunę zespół (jako nazwę), ale wszyscy uczestnicy byłego "zespołu wsparcia" staną się Deweloperami "Grupy Madagaskar"(adekwatnie do nowej struktury organizacyjnej) 
  
• "Zespół Programistów" zmieni nazwę na "Zespół Studentów Warsztatów" - liczebność uczestników zdających egzaminy z warsztatów nie ulegnie zmianie (nadal 100 os.),  przy czym każdy ze studentów będzie również Deweloperem "Grupy Madagaskar" (w myśl zasad opisanych w poprzednich podpunktach);
  
• Najważniejsza Zmiana ! : Wszyscy Deweloperzy Grupy "Madagaskar" (a więc wszyscy uczestnicy) będą musieli spełniać wymagania dot. poziomu zaangażowania (aktywności) w akcje rozwojowe grupy. Wszystko jest opisane w mojej prezentacji (link powyżej) natomiast w wielkim skrócie - tylko ogon ostatnich 25% uczestników w rankingu "rejestratora" będzie poddawany wymaganiu wypracowania w "rejestratorze" min 0.25 pkt (ekwiwalent 15 min pracy) raz na 2 miesiące, w dowolnej akcji rozwojowej (którą będzie można sobie wybrać ze specjalnego "worka zadań"); Tą zmianę uruchomię w chwili osiągnięcia (a raczej przekroczenia) maksymalnej liczby 200 osób (gdy zacznie się powiększać liczba chętnych do dołączenia do tego projektu, to pojawi się okazja do pożegnania się z uczestnikami od dawna nieaktywnymi w "Madagaskarze") ... to się stanie wkrótce, gdyż nieustannie coraz to nowi internauci zgłaszają akces do "Madagaskaru";
  

Pozostałe zmiany:

• wycofam się ze zwalniania z terminów zaliczeń, uczestników o poziomie wyszkolenia min 80%. Ta zmiana okazała się nietrafiona. Docelowo jedynie ostatni (najnowszy) warsztat nie będzie trzeba zaliczać w wyznaczonym, obowiązkowym terminie (po to aby nie było lawiny chętnych uczestników na zaliczenie nowej laborki krótko po jej opublikowaniu);
  
• pomysł Burgunda - wydzielić gałąź do aktualizowania przestarzałych warsztatów. Głównie chodzi o zaprezentowanie (ciągle aktualnych) z grubsza tych samych zagadnień z podstaw programowania , ale na nowszym IDE (najnowszym Visual Studio). Implemetacja pomysłu - poinformowałem o tym pomyśle Coffeinę (lidera produkcji laborek), zgadza się z tym pomysłem, wkrótce podniesie ten temat w swojej gałęzi , może znajdą się chętni (nie tyle na nagrywanie wideo, co opracowanie nowej wersji warsztatów w3-w16 ale w formie statycznych dokumentów czyli w takiej formule jak w warsztacie 17);
  
• pomysł Nemiza - sformować niewielkie zespoły, które będą zajmowały się realizacją wyznaczonych zadań (np. programistycznych). Po dłuższym zastanowieniu (pomysł ciekawy) nie chcę tego wdrażać! (na razie!). Próbowałem opracować jakiś schemat organizacyjny na tą zmianę i wymiękłem. Nie mówię że się nie da, ale w najróżniejszych wariantach wychodzi mi to samo - bardzo wzrośnie nakład pracy mojej oraz innych liderów na obsługę/koordynację pracy tych kilku zespołów. Poczekajmy z tym jeszcze ! Na razie miejmy 1 zespół i obserwujmy czy zwiększy się liczba os. aktywnych w rozwoju grupy (po wprowadzeniu "wymagań"  o których pisałem wcześniej). Potem (np. słodki problem - zbyt duża liczba chętnych do działania) można rozważyć opcję zdekomponowania takiej licznej (aktywnej) ekipy na mniejsze teamy.
  
• pozysł Stefanowwa - założyć grupę na https://gitter.im/ . Nie wdrożę tego ponieważ (cytuję z serwisu) "For private teams or communities, it's free for up to 25 users and just $5 per user for larger teams. " (nas ma być docelowo 200, nie ogarnę scenariusza wyciągania 25 wybrańców którzy będą mogli się tam udzielać za darmo)
  

To dajcie proszę mi zielone światło na to, aby wdrożyć powyższy zestaw zmian (tych na które się powyżej zdecydowałem). Czekam na Wasze finalne opinie  zanim zacznę "jechać z koksem".

Osobiście uważam że plany są OK, może coś drgnie do przodu i zrobi się dynamiczniej. Osobiście uważam że nadal i tak podstawową rolą projektu jest szkolenie i szczególną uwagę należy poświęcić poziomowi wiedzy i jednolitości całej grupy.

Według mnie reorganizacja projektu zaproponowana przez koszmarka ma sens. Ja jednak nie wprowadzałbym tych wszystkich zmian naraz. Na początek upubliczniłbym wszystkie warsztaty i poczekałbym, co będzie się działo. Czy nastąpi jakiś lawinowy napływ chętnych do przystąpienia do projektu czy też nie. Chciałbym przypomnieć, że w miesiącach lipiec i sierpień utrzymywały się wolne miejsca w Madagascarze, a dziś kolejka chętnych do przystąpienia do projektu też nie jest zbyt długa. Także pytanie jest czy uda zapełnić się 200 miejsc? To na pewno okaże się z czasem.
Co do aktywizacji uczestników projektu i najważniejszej zmiany w projekcie, uważam, że dzisiaj problemem braku aktywności niektórych uczestników Madagascaru jest z jednej strony pewnie brak czasu, ale z drugiej strony też duża różnica poziomów pomiędzy poszczególnymi uczestnikami. I trzeba by przede wszystkim dążyć, jak tę różnicę szybko zniwelować. Z tego wynika pewnie, że niektórzy uczestnicy boją się zaangażować w jakieś akcje rozwojowe projektu, bo po prostu sądzą, że nie dadzą rady. Może przydałoby się przydzielać zadania dla poszczególnych uczestników (albo uczestnik będzie mógł wybrać zadanie) z tzw. worka zadań, które będą adekwatne do poziomu wiedzy na jakim obecnie się znajduje? Tutaj wyznacznikiem byłby numer ostatniego zaliczonego warsztatu przez uczestnika. Nie wiem czy jest to warte przemyślenia?
Ale ogólnie uważam, że zmiany są potrzebne.

Uda się zapełnić 200 miejsc. Nigdy nie mieliśmy jakiegoś większego problemu o liczbę chętnych osób. Sam jestem studentem informatyki i wiem ilu z mojego roku chciałoby się nauczyć programować, ale uważa to za "zbyt wielki" wysiłek. Trzeba ich do tego umiejętnie "popchnąć" dobrą reklamą . Osobiście podoba mi się taka reorganizacja

#approved Koszmarek :D

trajan170 napisał:Na początek upubliczniłbym wszystkie warsztaty i poczekałbym, co będzie się działo. Czy nastąpi jakiś lawinowy napływ chętnych do przystąpienia do projektu czy też nie.

Oczywiście, że trudno to przewidzieć, ale ja obstawiam, że dużo Internautów po pobieżnym przejrzeniu 17-tu (zbyt szybko publicznie udostępnionych) laborek stwierdzi, że dopiero raczkujemy w fazie wstępnej OOP (a to nie prawda bo gałąź szkoleniowa nie jest jedyną gałęzią w tym projekcie), po czym wielu z nich zrezygnuje do dołączenia do grupy. Dlatego raczej będę skłaniał się ku temu, aby póki są wolne miejsca w projekcie dostęp do warsztatów był poprzedzony wymaganym założeniem konta w projekcie (wejściem w struktury grupy). Tym samym chcę zwiększyć szanse na pozyskanie ludzi, którzy wciągną się w ideę rozwoju "Madagaskaru". Jeżeli natomiast już osiągniemy te 200 os, to wtedy dopiero całkowicie upublicznię warsztaty - nie będziemy się wtedy martwić o to, że nie mamy kompletu pomimo, że napływ uczestników będzie wtedy przypuszczalnie mniejszy (gdyż będą rezygnować z dołączenia z powodów o którym pisałem powyżej). Wierzę jednak, że (po osiągnięciu max 200 os) nadal będą do nas napływać kolejni rekruci, ale Ci bardziej świadomi swojego wyboru (Ci co doczytali wszystkie założenia i nie są zainteresowani tylko i wyłącznie szkoleniem) i Ci właśnie będą dołączać do projektu przez mechanizm rotacji (po wyłączaniu baaaardzo długo niekatywnych z godnie z zasadami opisanymi w moim pomyśle).

trajan170 napisał:Także pytanie jest czy uda zapełnić się 200 miejsc?

Żaden problem. Po pierwsze dlatego , że Rafek już nam pokazał, że jest demonem PR'u. Uczestnicy napływają nieustannie a napływali by jeszcze szybciej gdybym go nie hamował :p (po wejściu zmian organizacyjnych dam mu znowu zielone światło na werbunek pełną parą).
Po drugie - po wejściu zmian organizacyjnych nowi rekruci przestaną odpadać z projektu, gdyż np. wylot z zespołu studentów laborek będzie wiązał się z pozostaniem w Zespole Deweloperów a więc pozostaniem w projekcie. Tak więc do osiągnięcia 200 os w zepsolu (i dopiero wtedy odpaleniu mechanizmów rotacji) liczba uczestników "Madagaskaru" będzie tylko przybywać (odpadać będą tylko Ci co sami poproszą o wyłączenie ich ze struktur, ale to się zdaża niemal nigdy)

trajan170 napisał:Co do aktywizacji uczestników projektu i najważniejszej zmiany w projekcie, uważam, że dzisiaj problemem braku aktywności niektórych uczestników Madagascaru jest z jednej strony pewnie brak czasu, ale z drugiej strony też duża różnica poziomów pomiędzy poszczególnymi uczestnikami. I trzeba by przede wszystkim dążyć, jak tę różnicę szybko zniwelować. Z tego wynika pewnie, że niektórzy uczestnicy boją się zaangażować w jakieś akcje rozwojowe projektu, bo po prostu sądzą, że nie dadzą rady. Może przydałoby się przydzielać zadania dla poszczególnych uczestników (albo uczestnik będzie mógł wybrać zadanie) z tzw. worka zadań, które będą adekwatne do poziomu wiedzy na jakim obecnie się znajduje?

No właśnie, uważam że niemożliwe jest jak najszybsze wyrównanie poziomu wiedzy zespołu, więc nie opierałbym strategii działania naszej grupy na próbie dokonania tej niemożliwej rzeczy. Zamiast tego (jak zauważyłeś) postawię na "worek zadań" który mam nadzieję zaoferuje szeroki wachlarz zadań programistycznych, organizacyjnych, redakcyjnych itp. ... gdzie każdy (nawet os. zaczynające przygodę z programowaniem ) znajdzie coś dla siebie, i natrzaska punkty oraz udziały dla siebie jako "rozwojowca" grupy "Madagaskar".

trajan170 napisał:Tutaj wyznacznikiem byłby numer ostatniego zaliczonego warsztatu przez uczestnika. Nie wiem czy jest to warte przemyślenia?

Muszę Cię zmartwić, ale ponieważ W17 to wstęp do OOP, to warsztaty traktowałbym tu jako "rozgrzewkę" a nie jako wyznacznik kompetencji z wiedzy IT uczestnika. Ta "rozgrzewka" ma spowodować, że uczestnik będzie zdobywał dalszą wiedzę na własną rękę (z innych serwisów edukacyjnych) i wykorzystywał tą wiedzę (oczywiście) dla siebie ale też do rozwoju naszej grupy (m.in może brać udział w produkcji kolejnych laborek które będą łatały mam nadzieję coraz mniejszą dziurę wiedzy pomiędzy gałęzią szkoleniową a gałęzią rozwoju oprogramowania , kierowaną przez Straviego w "Madagaskarze").

Witam

Według mnie można wprowadzać zmiany...

Tak off topic:
Fajną sprawą jest to, że młodzi ludzie, którzy wiążą swoją karierę z szeroko pojętym programowaniem mogą "na żywo" uczestniczyć OSOBIŚCIE w namiastce pracy w teamie programistów, z narzędziami powszechnie używanymi w zespołach projektowych... Mało tego: za FREE mogą się konsultować z doświadczonymi programistami uczestniczącymi w projekcie tworzenia aplikacji! Myślę, że spokojnie można takie doświadczenia wpisywać w CV (praca zdalna w grupie dev-ów)

Być może będzie tak, że w grupie Deweloperów-niestudentów:) znajdą się osoby, które mają doświadczenie ale chciałyby się sprawdzić/rozbudować CV/pobawić się i będą aplikowały do zespołu któregoś z liderów?  


Pozdrawiam
Tomtom

tomtom1 napisał:Być może będzie tak, że w grupie Deweloperów-niestudentów:) znajdą się osoby, które mają doświadczenie ale chciałyby się sprawdzić/rozbudować CV/pobawić się i będą aplikowały do zespołu któregoś z liderów? 

Każdego z liderów gałęzi "Madagaskaru" gorąco namawiam aby prędzej czy później (gdy poczują się pewni po wdrożeniu się w rolę) poszukali sobie równoważnych zastępców (takich jakby "backupów") aby primo nie czuli się osamotnieni w swojej roli, secundo zachowali ciągłość działania projektu na wypadek perturbacji (zdarzeń losowych).

Plany fajne i powinny wpłynąć na plus dla grupy. IMHO ciekawym pomysłem jest też sformatowanie tych niewielkich zespołów, mogłoby to wpłynąć na znaczny wzrost aktywności oraz na lepsze zapoznanie się członków MADAGASKARu. Może w przyszłości uda się to wdrożyć

Osobiście nie mam żadnych zastrzeżeń związanych z zaplanowaną reorganizacją. Byle do przodu.