Bug 2564 - Mania organizowania i strukturyzowania - ograniczyć to
Summary: Mania organizowania i strukturyzowania - ograniczyć to
Status: VERIFIED FIXED
Alias: None
Product: Inne
Classification: Zespół Aviary.pl
Component: Ogólne (show other bugs)
Version: nieokreślona
Hardware: Wszystkie Wszystkie
: P3 normalny
Assignee: Hubert Gajewski
QA Contact: inne
URL:
Depends on:
Blocks: 2420
  Show dependency treegraph
 
Reported: 2009-07-23 12:34 CEST by Hubert Gajewski
Modified: 2012-08-20 11:17 CEST (History)
5 users (show)

See Also:


Attachments

Description Hubert Gajewski 2009-07-23 12:34:15 CEST
Zapis ze spotkania:
dyskusja na temat manii organizowania i strukturalizowania.
Przede wszystkim chodzi o to, aby nie popadać w przesadę typu kierownik jednoosobowego
projektu. Należy mieć podejście bardziej zdroworozsądkowe do tego.

1. Sytuacje typu samotny kierownik wynikają tylko i wyłącznie z braku ludzi. 
Chciałbym, żeby w każdym projekcie były przynajmniej dwie osoby, w tym jedna od kontroli jakości. Jedna z tych dwóch osób powinna być szefem. To już nie wydaje mi się przesadą, bo chciałbym mieć osobę, która za taki projekt odpowiada. Wszystkie jednoosobowe projekty powinny być zamknięte.

2. Chciałbym ograniczyć częstotliwość aktualizacji Matriksa - żeby to było raz na 6 miesięcy (już to proponowałem na spotkaniu, ale nie było zainteresowania) i odbywało się na miesiąc przed spotkaniem. Sytuacja na tyle się ustabilizowała, że nie jest mi potrzebna (choć nie wiem jak innym) tak częsta aktualizacja.
A najlepiej, jakby jakieś narzędzie automatycznie to wypełniało w oparciu o rzeczywiste dane (tyle, że to temat przyszłości).
Comment 1 Wojciech Szczęsny 2009-07-23 14:07:32 CEST
(In reply to comment #0)
> Wszystkie jednoosobowe projekty powinny być zamknięte.

Moim zdaniem przyjęcie takiego założenia jest zbyt daleko idące. Jeśli w projekcie jest niewiele pracy i z rzadka coś się dzieje, to wystarczy, żeby jedna osoba na stałe tym się zajmowała. Gdy jest potrzeba sprawdzenia, można poprosić kogoś z zespołu.

Przykładowo; ja sprawdzam tłumaczenia ankiet społeczności, ale w każdej chwili równie dobrze mógłby to zrobić ktoś inny. Tego rodzaju projekt nie wymaga na bieżąco śledzenia i wdrażania się w jego arkana, by dokonać kontroli jakości.
Comment 2 Hubert Gajewski 2009-07-23 15:31:04 CEST
Tak jak w Camino? :-)
Comment 3 Wojciech Szczęsny 2009-07-24 02:20:33 CEST
Czy akurat Camino powinno zostać tak, jak jest - tego nie wiem :)

Chodzi mi głównie o to, by nie przyjmować z góry założenia, że zamykamy projekty jednoosobowe. Lepiej ocenić każdy projekt indywidualnie, czy w takiej formie może funkcjonować, czy nie.
Comment 4 Wojciech Kapusta 2009-08-31 08:59:25 CEST
Dobrym przykładem przerostu biurokratycznego jest to → http://wiki.aviary.pl/Obowi%C4%85zki_i_cele

Np. "Poziomy do określenia statusu, jeśli cel nie jest osiągnięty". Pomijając samo nadzwyczaj mętne sformułowanie, schemat ten jest jest poniekąd oczywistą oczywistością - albo coś jest realizowane terminowo, albo nie jest. Być może w zakładzie produkcyjnym ma to jakiś sens, ale tu go nie widzę.
Comment 5 Marek Stępień 2009-08-31 09:11:31 CEST
Małe reductio ad kononowiczem: zamknijmy wszystkie projekty, niech nie będzie niczego. :)
Comment 6 Hubert Gajewski 2009-09-10 03:41:59 CEST
(In reply to comment #4)

> Np. "Poziomy do określenia statusu, jeśli cel nie jest osiągnięty". Pomijając
> samo nadzwyczaj mętne sformułowanie, schemat ten jest jest poniekąd oczywistą
> oczywistością - albo coś jest realizowane terminowo, albo nie jest. Być może w
> zakładzie produkcyjnym ma to jakiś sens, ale tu go nie widzę.

No z tym faktycznie coś trzeba zrobić...
Comment 7 Hubert Gajewski 2009-12-18 05:16:00 CET
(w odpowiedzi na komentarz #4)
1. Proponuję:
- wyrzucić "Poziomy do określenia statusu, jeśli cel nie jest osiągnięty"

Oczywiście z celu musi jasno wynikać, czy ktoś coś robi terminowo, czy nie.
W Matriksie, czy na stronie wiki byłoby albo zielono (cel osiągnięty) albo żółto (cel nie osiągnięty - ze względu na opóźnienie, czy cokolwiek innego)

(w odpowiedzi na komentarz #0)
2. Jeśli nikt nie poda jakieś dobre kontrargumentu - zmieniam minimalną częstotliwość aktualizacji Matriksa. Będzie to raz na 6 miesięcy z terminem aktualizacji: tydzień przed spotkaniem.
Comment 8 Hubert Gajewski 2009-12-28 03:17:08 CET
(w odpowiedzi na komentarz #7)
Minęło 10 dni. Czekam na ewentualne uwagi jeszcze do końca dzisiejszego dnia.
Comment 9 Joanna Mazgaj 2010-01-02 08:13:25 CET
(w odpowiedzi na komentarz #8)
> (w odpowiedzi na komentarz #7)
> Minęło 10 dni. Czekam na ewentualne uwagi jeszcze do końca dzisiejszego dnia.

Trochę spóźnione, ale brak uwag poza poparciem dla Wojciecha, aby nie zamykać jednoosobowych projektów tylko dlatego, że są jednoosobowe.

Note You need to log in before you can comment on or make changes to this bug.