Temat: 2 lata doświadczenia - ale skąd je wziąc?

Sławomir Marcjański:

Hmm w SCRUM przydzielanie zadań?

No taka tam modyfikacja :) W zasadzie nie mamy co głosować i rozdzielać zadań na spotkaniu, bo mamy krótkie terminy dla poszczególnych sprintów i w zasadzie każdy w obecnym projekcie ma wąskie specjalizacje. Wiem, że to złe z tylu powodów, że hoho, ale obecnie inaczej nie możemy. Jak jest jakaś rzecz do wykonania, to w zasadzie wiemy, kto ma ją wykonać.

Fakt - jest coś takiego, że sposób wykonania często jest trochę podobny do religii. Trudno wszystkim narzucić jedną wiarę, i wymaga dużo subtelności forsowanie swojej wizji. Nawet jeżeli jest się na wyższym stanowisku w hierarchii trzeba uważać żeby kogoś nie urazić (wiedza i doświadczenie nie zawsze idą w parze z „wysokością” stanowiska).

Dokładnie. Nic dodać, nic ująć.

Już wspominałem kiedyś o kreatywności - niestety często jako szary członek zespołu trzeba się dostosować i kopać swój rowek wedle planu kogoś innego - tak to już jest. Mnie niestety na dłuższą metę taka praca wymęcza psychicznie - czuję się że jestem robotem i tak mi zostanie.Jednak jeżeli idzie o architekturę absolutnie niedopuszczalnym jest żeby każdy forsował swoją wizję bo wyjdzie coś jak Picasso zamiast da Vinci. Trzeba gadać i dumę w kieszeń czasem chować.

Ja też nie lubię być trybikiem. To męczy psychicznie. Lubię mieć kontrolę nad swoją pracą. Chcę, aby w zespole ludzie również podchodzili kreatywnie do swoich zadań. Obecnie realizujemy taki projekt, że w zasadzie wyciskamy z .NET i Windows wszystko, co się da. Z drugiej strony mocno wydumane rozwiązania (virtuale przez dziedziczeni i metody pomocnicze) bardzo męczą.

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Sławomir Orłowski:

Chcę, aby w zespole ludzie również podchodzili kreatywnie do swoich zadań.

Jak ich motywujesz do tego?

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Sergiusz B. edytował(a) ten post dnia 29.08.11 o godzinie 22:01

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Ponieważ jest okazja porozmawiać z kimś doświadczonym, pozwolę sobie wtrącić swoje 'trzy gorsze' ;p

Ja też nie lubię być trybikiem. To męczy psychicznie.
Lubię mieć kontrolę nad swoją pracą. Chcę, aby w zespole ludzie również podchodzili kreatywnie do swoich zadań.

Znam programistów (i to naprawdę dobrych) którzy marzą o tym, żeby 'być trybikami'. Chcą spełniać taką funkcję ponieważ nie chcą 'myśleć' nad swoim zadaniem; nie chodzi o to, że nie są kreatywni - wręcz przeciwnie - są 'mega' kreatywni i potrafią wymyślić setki rozwiązań danego zadania.

Problem polega na tym, że każde rozwiązanie ma swoje wady i zalety, a ponieważ programista nie zna kontekstu swojego zadania (nie zna wszystkich wymagań / całej architektury / docelowej platformy sprzętowej), nie potrafi dobrze tych wad i zalet ocenić. W konsekwencji - nie może wybrać dobrego rozwiązania problemu; a za złe - programista dostaje 'po głowie'.

Obecnie realizujemy taki projekt, że w zasadzie wyciskamy z .NET i Windows wszystko, co się da. Z drugiej strony mocno wydumane rozwiązania (virtuale przez dziedziczeni i metody pomocnicze) bardzo męczą.

Zapewniam, że gdyby nie obiektywność (dziedziczenie, metody wirtualne) i metody pomocnicze (extension methods?) to rozwiązanie (ostateczna architektura) było by jeszcze bardziej męczące. :)

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Jakub Wojt:
Problem polega na tym, że każde rozwiązanie ma swoje wady i zalety, a ponieważ programista nie zna kontekstu swojego zadania (nie zna wszystkich wymagań / całej architektury / docelowej platformy sprzętowej), nie potrafi dobrze tych wad i zalet ocenić. W konsekwencji - nie może wybrać dobrego rozwiązania problemu; a za złe - programista dostaje 'po głowie'.

Tu wszystko zamyka się w osobowości programisty i charakterze pracy, jaką wykonuje. W dużych projektach tak właśnie bywa i wtedy faktycznie lepiej wiedzieć mniej, niż więcej. W innych projektach programista pełni kilka funkcji i ma szerszą wiedzę ale i poziom odpowiedzialności. W jeszcze innych - zajmuje się tylko swoją działką - i wtedy jest w pełni rozliczany z rozwiązań, które przyjmie. Dysponuje jednak dużo większą wiedzą o projekcie, a często bywa także tzw. "ekspertem" (czyli posiada przydatną wiedzę) w danej dziedzinie. W dużych firmach trudniej o ten drugi model, ale zdarza się. Różne są projekty - "wiodące" (główny projekt firmy), pomocnicze (różne narzędzia dodatkowe), "pod klucz" (na zamówienie klienta), "autorskie" (zrealizujmy ten pomysł), "po dziadku" (utrzymywana i odświeżana praca z poprzednik lat, firm i zespołów), eksperymentalne ("a nuż się sprawdzi?"). Na szczęście dla introwertyków, ekstrawertyków, agile'owców i "all-is-mine" jest w czym wybierać :)

Fajnie byłoby, aby programista zawsze wiedział, co go w danej firmie czeka i od razu dobrać krawat do koszuli... ekhm projekt do swojego charakteru. Oczywiście takie luksusy pozwalające pogrymasić raczej nie są na porządku dziennym, więc pozostaje albo dopasować siebie do zespołu, albo... zespół do siebie. A najlepiej - aby wszyscy byli na tyle elastyczni, by się jakoś zgrać. A na to nie ma recepty, to wszystko zależy od nas samych. Jak w związku, tak i w pracy :)

Zapewniam, że gdyby nie obiektywność (dziedziczenie, metody wirtualne) i metody pomocnicze (extension methods?) to rozwiązanie (ostateczna architektura) było by jeszcze bardziej męczące. :)

O tak :) Ale ile trzeba na początku dyscypliny, by konsekwentnie stosować obraną strategię i nie ulegać pokusie "a, to sobie zrobię na sztywno, a potem w razie czego poprawię". Tutaj trzeba, jak chyba ze wszystkim, parę razy "upaść", by się samemu przekonać, że warto się trochę pomęczyć, by potem nie męczyć się o wiele bardziej. Podobnie, jak niektórzy muszą mieć choć jedną stłuczkę, by "poczuć to na sobie" i poważniej podchodzić do prowadzenia auta.Adrian Olszewski edytował(a) ten post dnia 01.09.11 o godzinie 17:01

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Jakub Wojt:
Zapewniam, że gdyby nie obiektywność (dziedziczenie, metody wirtualne) i metody pomocnicze (extension methods?) to rozwiązanie (ostateczna architektura) było by jeszcze bardziej męczące. :)

Może tutaj się źle wyraziłem. Oczywiście należy konsekwentnie stosować podejście obiektowe itd. Miałem bardziej na myśli niepotrzebne uogólnianie, czyli nie mapowanie rzeczywistej natury (złożoności) domeny problemu w kodzie, a zamiast tego tworzenie jakiś dodatkowych, zbędnych bytów. Jestem za podejściem, w którym trzeba stworzyć dokładnie to, co klient żąda. Nic ponad. Nie lubię podejścia, że sobie coś napiszę bardziej ogólnie, bo potem mi się to na pewno przyda. Program będzie bardziej wszechstronny, modułowy ... idealny :) Z racji mojej przeszłości uniwersyteckiej miałem czasem takie zakusy, z których projekty "prawdziwe" szybko mnie wyleczyły. Wystarczy, że jeden się nie udał i nie dostałem pensji :)

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Adrian Olszewski:

Jakub Wojt:
Zapewniam, że gdyby nie obiektywność (dziedziczenie, metody wirtualne) i metody pomocnicze (extension methods?) to rozwiązanie (ostateczna architektura) było by jeszcze bardziej męczące. :)

O tak :) Ale ile trzeba na początku dyscypliny, by konsekwentnie stosować obraną strategię i nie ulegać pokusie "a, to sobie zrobię na sztywno, a potem w razie czego poprawię". Tutaj trzeba, jak chyba ze wszystkim, parę razy "upaść", by się samemu przekonać, że warto się trochę pomęczyć, by potem nie męczyć się o wiele bardziej. Podobnie, jak niektórzy muszą mieć choć jedną stłuczkę, by "poczuć to na sobie" i poważniej podchodzić do prowadzenia auta.

Spieszę zapewnić, że nie krytykowałem podejścia obiektowego. Trochę źle się wyraziłem, co mam nadzieję wytłumaczyłem postem powyżej. Ja używam wyłącznie programowania zorientowanego obiektowo. Zgadzam się jak najbardziej, że należy zachować dyscyplinę. Dodatkowo należy przejechać się na błędach (co mi się zdarzyło). Nie robić nic "na szybko". Ale tutaj z tym "na szybko", albo trzeba być team leaderem, żeby kontrolować coś takiego, lub mieć dobrego lidera. W przeciwnym razie nawet przy dobrych chęciach na nie samodzielnym stanowisku można wyjść na mało kompetentnego. Ja działałem przez krótki czas w takim zespole - brak projektanta, architekta bo przecież programiści wiedzą co mają pisać. Nie muszę opisywać jak to się skończyło (ech rok pracy w plecy).

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Sergiusz B.:

Sławomir Orłowski:

Chcę, aby w zespole ludzie również podchodzili kreatywnie do swoich zadań.

Jak ich motywujesz do tego?

Wybieram współpracowników (jeśli mogę). Można wtedy odsiać osoby kreatywne i chętne do pracy. Staram się też za każdym razem służyć pomocą w rozwiązywaniu problemów. Nie zostawiam kogoś z problemem, który go przerasta. Staram się uzmysłowić, że praca, która ma być wykonana jest nieodzownym elementem całego procesu. Bez niej ani rusz. Za każdym razem, przy projektowaniu konsultuję się z programistami. W przypadku nadgodzin, ja również zostaję i pracuję. Zawsze staram się mieć jasny plan i cel, do którego dążymy. Daje to poczucie spokoju. Nie krążymy po omacku i wiemy ile już za nami a ile jeszcze przed. Niestety na wypłaty nie mam wpływu :)

Temat: 2 lata doświadczenia - ale skąd je wziąc?

[...] W konsekwencji - nie może wybrać dobrego rozwiązania problemu; a za złe - programista dostaje 'po głowie'.

Tu wszystko zamyka się w osobowości programisty i charakterze pracy, jaką wykonuje.

Wolę określenia 'wiedza' i 'wyobraźnia' ;)

W dużych [...] Dysponuje jednak dużo większą wiedzą o projekcie, a często bywa także tzw. "ekspertem" (czyli posiada przydatną wiedzę) w danej dziedzinie.

Ale wtedy posiada (a przynajmniej powinien) wiedzę o 'kontekście' (architekturze, platformie sprzętowej, biznesie) swoich pomysłów...

Może więc, teoretycznie, ocenić ich uzyteczność.

Fajnie byłoby, aby programista zawsze wiedział, co go w danej firmie czeka i od razu dobrać krawat do koszuli... ekhm projekt do swojego charakteru.

IMHO to odpowiedzialność pracodawcy. Tzn. to pracodawca powinien tak dobierać zespół, żeby jego 'członkom' dobrze się współpracowało; w konsekwencji - żeby 'dobrze' realizował swoje zadania.

Oczywiście takie luksusy pozwalające pogrymasić raczej nie są na porządku dziennym, więc pozostaje albo dopasować siebie do zespołu, albo... zespół do siebie. A najlepiej - aby wszyscy byli na tyle elastyczni, by się jakoś zgrać. A na to nie ma recepty, to wszystko zależy od nas samych. Jak w związku, tak i w pracy :)

hm ... dlaczego w takim razie nie dokumentuje się 'wymagań funkcjonalnych' dla partnerów / partnerek ? ;)

Zapewniam, że gdyby nie obiektywność (dziedziczenie, metody wirtualne) i metody pomocnicze (extension methods?) to rozwiązanie (ostateczna architektura) było by jeszcze bardziej męczące. :)

O tak :) Ale ile trzeba na początku dyscypliny, by konsekwentnie stosować obraną strategię i nie ulegać pokusie "a, to sobie zrobię na sztywno, a potem w razie czego poprawię".

Do tego trzeba wiedzy a nie dyscypliny.
Tzn. strategia realizacji projektu jest pochodną wiedzy o projekcie i wiedzy 'nabytej'. A przynajmniej tak interpretuję swoje doświadczenia ;)

Tutaj trzeba, jak chyba ze wszystkim, parę razy "upaść", by się samemu przekonać, że warto się trochę pomęczyć, by potem nie męczyć się o wiele bardziej. Podobnie, jak niektórzy muszą mieć choć jedną stłuczkę, by "poczuć to na sobie" i poważniej podchodzić do prowadzenia auta.

Ta zasada chyba nigdy się nie zdezaktualizuje... niestety.

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Zapewniam, że gdyby nie obiektywność (dziedziczenie, metody wirtualne) i metody pomocnicze (extension methods?) to rozwiązanie (ostateczna architektura) było by jeszcze bardziej męczące. :)

Może tutaj się źle wyraziłem. [...] Miałem bardziej na myśli niepotrzebne uogólnianie, czyli nie mapowanie rzeczywistej natury (złożoności) domeny problemu w kodzie, a zamiast tego tworzenie jakiś dodatkowych, zbędnych bytów.

IMHO tak właśnie robią kreatywni programiści.
Kreatywność jest użyteczna ale tylko pod warunkiem, że umie się nad nią zapanować (brzmi to trochę jak 'opanować chaos' ale nie umiem lepiej tego nazwać).

Jestem za podejściem, w którym trzeba stworzyć dokładnie to, co klient żąda. Nic ponad.
Nie lubię podejścia, że sobie coś napiszę bardziej ogólnie, bo potem mi się to na pewno przyda.

To bardzo dobre podejście ale ma jedną wadę - klient nie opisze (jeśli któryś kiedyś to zrobi to powieszę sobie jego zdjęcie nad biurkiem) jak w przyszłości system będzie rozwijany / zmieniany.

Łatwo jest stworzyć pierwszą wersję systemu. Dużo trudniej jest ten system rozwijać przez kilka kolejnych lat... MVC jest tez 'ogólne' i 'na wyrost'.

Jeśli 'szeregowy' programista programuje coś 'ogólniej niż trzeba' to znaczy to tylko tyle, że ma pomysł i wiedzę (jest kreatywny) ale jeszcze nie wie (bo skąd ma to wiedzieć), że dane uogólnienie jest niepotrzebne / szkodliwe.

Dlatego właśnie twierdzę, że 'bycie trybikiem' czasami jest najlepszym rozwiązaniem.

Program będzie bardziej wszechstronny, modułowy ... idealny :) Z racji mojej przeszłości uniwersyteckiej miałem czasem takie zakusy, z których projekty "prawdziwe" szybko mnie wyleczyły. Wystarczy, że jeden się nie udał i nie dostałem pensji :)

Też brałem udział w tej 'wojnie' .. ;) I widziałem, jak ginęli w niej 'zbyt ogólni' i 'niedostatecznie ogólni' programiści.

... Tylko jeden ? ;)Jakub Wojt edytował(a) ten post dnia 01.09.11 o godzinie 21:29

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Jakub Wojt:

Jestem za podejściem, w którym trzeba stworzyć dokładnie to, co klient żąda. Nic ponad.
Nie lubię podejścia, że sobie coś napiszę bardziej ogólnie, bo potem mi się to na pewno przyda.

To bardzo dobre podejście ale ma jedną wadę - klient nie opisze (jeśli któryś kiedyś to zrobi to powieszę sobie jego zdjęcie nad biurkiem) jak w przyszłości system będzie rozwijany / zmieniany.

To prawda, nie opisze. Ale my również nie jesteśmy w stanie przewidzieć tego, co klient zechce. Więc wydaje mi się, że powinienem robić dokładnie to co trzeba w danej iteracji projektu. Ważne, aby iteracje były krótkie i było ich dużo w projekcie. Wtedy łatwo dojść do tego, co klient naprawdę chce.

Łatwo jest stworzyć pierwszą wersję systemu. Dużo trudniej jest ten system rozwijać przez kilka kolejnych lat... MVC jest tez 'ogólne' i 'na wyrost'.

Przyznam, że znam MVC "po łebkach". Aktualnie robię bardzo ... dziwne rzeczy z WinAPI i .NET.

Jeśli 'szeregowy' programista programuje coś 'ogólniej niż trzeba' to znaczy to tylko tyle, że ma pomysł i wiedzę (jest kreatywny) ale jeszcze nie wie (bo skąd ma to wiedzieć), że dane uogólnienie jest niepotrzebne / szkodliwe.

Dlatego właśnie twierdzę, że 'bycie trybikiem' czasami jest najlepszym rozwiązaniem.

Rozumiem. Każdy powinien pracować na swoim stanowisku, w ramach swojej odpowiedzialności.

Program będzie bardziej wszechstronny, modułowy ... idealny :) Z racji mojej przeszłości uniwersyteckiej miałem czasem takie zakusy, z których projekty "prawdziwe" szybko mnie wyleczyły. Wystarczy, że jeden się nie udał i nie dostałem pensji :)

Też brałem udział w tej 'wojnie' .. ;) I widziałem, jak ginęli w niej 'zbyt ogólni' i 'niedostatecznie ogólni' programiści.

Szukanie optimum - to najtrudniejsze. Łatwo znaleźć ekstremum (minimum lub maksimum) - jest mnóstwo algorytmów na to. Ale jak znaleźć optimum? Co to jest optimum ;)

... Tylko jeden ? ;)

No na razie jeden - niech tak zostanie :)

Temat: 2 lata doświadczenia - ale skąd je wziąc?

To bardzo dobre podejście ale ma jedną wadę - klient nie opisze (jeśli któryś kiedyś to zrobi to powieszę sobie jego zdjęcie nad biurkiem) jak w przyszłości system będzie rozwijany / zmieniany.

To prawda, nie opisze. Ale my również nie jesteśmy w stanie przewidzieć tego, co klient zechce. Więc wydaje mi się, że powinienem robić dokładnie to co trzeba w danej iteracji projektu.

Jeśli projekt nie ma 'elastycznej architektury' to iteracje nie pomogą.
Rozwiązaniem jest architektura. A raczej - odpowiednie zaplanowanie hierarchii klas (np. Model, View, Control). To (odpowiednie planowanie hierarchii klas) próbują czasem robić 'kreatywni' programiści.

Kurcze, na jaki temat teraz piszemy ?... Nie wiem jak podsumować tą część posta. ;)

Ważne, aby iteracje były krótkie i było ich dużo w projekcie. Wtedy łatwo dojść do tego, co klient naprawdę chce.

Hm.. ja wyznaję zasadę, że powinno się współpracować tylko z takim klientem, który 'od początku' wie czego chce tzn. robimy jeden system a nie 'naście' prototypów.

Łatwo jest stworzyć pierwszą wersję systemu. Dużo trudniej jest ten system rozwijać przez kilka kolejnych lat... MVC jest tez 'ogólne' i 'na wyrost'.

Przyznam, że znam MVC "po łebkach". Aktualnie robię bardzo ... dziwne rzeczy z WinAPI i .NET.

Ale MVC jest niezależne od technologii...
W sumie - MVC jest tak pojemne (ogólne) że prawie bezużyteczne.

Też brałem udział w tej 'wojnie' .. ;) I widziałem, jak ginęli w niej 'zbyt ogólni' i 'niedostatecznie ogólni' programiści.

Szukanie optimum - to najtrudniejsze. Łatwo znaleźć ekstremum (minimum lub maksimum) - jest mnóstwo algorytmów na to. Ale jak znaleźć optimum? Co to jest optimum ;)

To maksimum funkcji jakości :)
... jakość każdy definiuje po swojemu ;)

... Tylko jeden ? ;)

No na razie jeden - niech tak zostanie :)

Amen :)

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Jakub Wojt:

To bardzo dobre podejście ale ma jedną wadę - klient nie opisze (jeśli któryś kiedyś to zrobi to powieszę sobie jego zdjęcie nad biurkiem) jak w przyszłości system będzie rozwijany / zmieniany.

To prawda, nie opisze. Ale my również nie jesteśmy w stanie przewidzieć tego, co klient zechce. Więc wydaje mi się, że powinienem robić dokładnie to co trzeba w danej iteracji projektu.

Jeśli projekt nie ma 'elastycznej architektury' to iteracje nie pomogą.
Rozwiązaniem jest architektura. A raczej - odpowiednie zaplanowanie hierarchii klas (np. Model, View, Control). To (odpowiednie planowanie hierarchii klas) próbują czasem robić 'kreatywni' programiści.

Kurcze, na jaki temat teraz piszemy ?... Nie wiem jak podsumować tą część posta. ;)

Moim zdaniem piszemy o tym samym. Tylko wychodzimy z innych punktów.

Ważne, aby iteracje były krótkie i było ich dużo w projekcie. Wtedy łatwo dojść do tego, co klient naprawdę chce.

Hm.. ja wyznaję zasadę, że powinno się współpracować tylko z takim klientem, który 'od początku' wie czego chce tzn. robimy jeden system a nie 'naście' prototypów.

No właśnie tutaj też sytuacja jest bardzo niejasna. Czy klient, który dajmy na to chce urządzenie i oprogramowanie do robienia np. kawy już wie czego chce? Teoretycznie tak. Ale ... Ja lubię podejście Scrum i ogólnie zwinne, czyli właśnie dużo iteracji. Wtedy współpracując z klientem dochodzimy razem do rozwiązania optymalnego dla nas wszystkich. Nie wszyscy klienci tak chcą. W zasadzie nie wyobrażam sobie klienta, który zamawia duży system informatyczny i wie czego chce od razu. Ja takiego nie spotkałem :) A Ty? Problemem w iteracjach może być fakt, że trudno od razu wycenić pracę. No przynajmniej ja się jeszcze tego dobrze nie nauczyłem.

Łatwo jest stworzyć pierwszą wersję systemu. Dużo trudniej jest ten system rozwijać przez kilka kolejnych lat... MVC jest tez 'ogólne' i 'na wyrost'.

Przyznam, że znam MVC "po łebkach". Aktualnie robię bardzo ... dziwne rzeczy z WinAPI i .NET.

Ale MVC jest niezależne od technologii...
W sumie - MVC jest tak pojemne (ogólne) że prawie bezużyteczne.

Stosuję MVVM, które jest wariacją MVC dla WPF. I zgadzam się (podpisując obiema rękami), że należy założyć model, a następnie go konsekwentnie realizować.

Też brałem udział w tej 'wojnie' .. ;) I widziałem, jak ginęli w niej 'zbyt ogólni' i 'niedostatecznie ogólni' programiści.

Szukanie optimum - to najtrudniejsze. Łatwo znaleźć ekstremum (minimum lub maksimum) - jest mnóstwo algorytmów na to. Ale jak znaleźć optimum? Co to jest optimum ;)

To maksimum funkcji jakości :)
... jakość każdy definiuje po swojemu ;)

Tak jest

... Tylko jeden ? ;)

No na razie jeden - niech tak zostanie :)

Amen :)

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Sławomir Orłowski:

Wybieram współpracowników (jeśli mogę).

A jeśli nie możesz? Jak sobie radzisz z "trudnymi" osobowościami?

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Ważne, aby iteracje były krótkie i było ich dużo w projekcie. Wtedy łatwo dojść do tego, co klient naprawdę chce.

Hm.. ja wyznaję zasadę, że powinno się współpracować tylko z takim klientem, który 'od początku' wie czego chce tzn. robimy jeden system a nie 'naście' prototypów.

No właśnie tutaj też sytuacja jest bardzo niejasna. Czy klient, który dajmy na to chce urządzenie i oprogramowanie do robienia np. kawy już wie czego chce?

Jeśli nie wie - dlaczego uważa, że może zarobić / zaoszczędzić na tym (system informatyczny) pieniądze ?

Systemy informatyczne mają za zadanie generować zyski / oszczędności dla właścicieli. Jeśli właściciel nie wie 'z -analizowalną- dokładnością' co dany system ma robić to IMHO zamiast zlecać jego wykonanie, powinien się udać do jakiejś firmy konsultingowej.

Zamawianie czegoś czego nie potrafi się dobrze zdefiniować jest według mnie trochę niepoważne. Wymagania systemu są pochodną celów biznesowych. Jeśli wymagania są niejasne to najprawdopodobniej również cele b. są niejasne; w konsekwencji dochodowość całego przedsięwzięcia ( którego elementem jest system informatyczny ) najprawdopodobniej będzie mierna.

Robienie (albo branie w tym udziału) rzeczy miernych jest bezcelowe.

Nie wiem... ja lubię pracować z kompetentnymi ludźmi którzy są dokładnie wiedzą czego chcą; tacy najprawdopodobniej nie przyjdą do analityka (systemowego) z mglistymi wyobrażeniami.

Teoretycznie tak. Ale ... Ja lubię podejście Scrum i ogólnie zwinne, czyli właśnie dużo iteracji. Wtedy współpracując z klientem dochodzimy razem do rozwiązania optymalnego dla nas wszystkich.

Mnie w takich sytuacjach zawsze męczy pytanie 'skąd właściwie wiem, że to rozwiązanie jest dobre dla klienta'.

Nie wszyscy klienci tak chcą. W zasadzie nie wyobrażam sobie klienta, który zamawia duży system informatyczny i wie czego chce od razu.

Nie musi wiedzieć wszystkiego.
Chodzi jedynie o to, żeby jego pomysły mogły w formie możliwie 'niezmienionej' przejść przez etap analizy systemowej.

Ja takiego nie spotkałem :) A Ty?

Ja parę razy takiego widziałem; ale z daleka i niewyraźnie więc nie jestem pewny... ;)

W sumie ta sytuacja mnie nie zaskakuje. Dobry, precyzyjny biznes plan ( w konsekwencji plan funk. systemu informatycznego który jest jego częścią) jest tak na prawdę programem który działa na rynku – procesorze.

Analogii jest z resztą cała masa a kluczowe w ww. kontekście brzmią
– ilu programistów wymaga (np. od przełożonego) dokładnego plan implementacji systemu przed jego wykonaniem ?
- jakie są efekty implementacji dużych systemów bez planu ? (freelance)

Problemem w iteracjach może być fakt, że trudno od razu wycenić pracę. No przynajmniej ja się jeszcze tego dobrze nie nauczyłem.

Zapewniam – to jest dość proste pod warunkiem, że się wie co trzeba zrobić.Jakub Wojt edytował(a) ten post dnia 05.09.11 o godzinie 14:14

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Wracam do pisania :)

Jakub Wojt:

Hm.. ja wyznaję zasadę, że powinno się współpracować tylko z takim klientem, który 'od początku' wie czego chce tzn. robimy jeden system a nie 'naście' prototypów.

No właśnie tutaj też sytuacja jest bardzo niejasna. Czy klient, który dajmy na to chce urządzenie i oprogramowanie do robienia np. kawy już wie czego chce?

Jeśli nie wie - dlaczego uważa, że może zarobić / zaoszczędzić na tym (system informatyczny) pieniądze ?

Musi dostosować się do wymagań innego klienta, ISO czy coś w tym stylu. Wie, że musi mieć system, który fakturuje, ale nie zna szczegółów.

Systemy informatyczne mają za zadanie generować zyski / oszczędności dla właścicieli. Jeśli właściciel nie wie 'z -analizowalną- dokładnością' co dany system ma robić to IMHO zamiast zlecać jego wykonanie, powinien się udać do jakiejś firmy konsultingowej.

No to jest dobry pomysł. Popieram.

Zamawianie czegoś czego nie potrafi się dobrze zdefiniować jest według mnie trochę niepoważne. Wymagania systemu są pochodną celów biznesowych. Jeśli wymagania są niejasne to najprawdopodobniej również cele b. są niejasne; w konsekwencji dochodowość całego przedsięwzięcia ( którego elementem jest system informatyczny ) najprawdopodobniej będzie mierna.

Zgadzam się, choć nie do końca. Cel może być jasny. Wymagania nie. Cel: musimy zwiększyć udział w rynku nowym urządzeniem. Na początku wymagania są rozmyte. Urządzenie szybsze, tańsze i różowe. Potem się precyzują. Ale system już w trakcie precyzowania się już powstaje.

Robienie (albo branie w tym udziału) rzeczy miernych jest bezcelowe.

O tak.

Nie wiem... ja lubię pracować z kompetentnymi ludźmi którzy są dokładnie wiedzą czego chcą; tacy najprawdopodobniej nie przyjdą do analityka (systemowego) z mglistymi wyobrażeniami.

No ja mam akurat takie szczęście, że część moich zleceniodawców mają wg. Twojej definicji dosyć mgliste wyobrażenie. Ale dobrze płacą :)

Teoretycznie tak. Ale ... Ja lubię podejście Scrum i ogólnie zwinne, czyli właśnie dużo iteracji. Wtedy współpracując z klientem dochodzimy razem do rozwiązania optymalnego dla nas wszystkich.

Mnie w takich sytuacjach zawsze męczy pytanie 'skąd właściwie wiem, że to rozwiązanie jest dobre dla klienta'.

No bo go o to pytam co dwa tygodnie:)

Nie wszyscy klienci tak chcą. W zasadzie nie wyobrażam sobie klienta, który zamawia duży system informatyczny i wie czego chce od razu.

Nie musi wiedzieć wszystkiego.
Chodzi jedynie o to, żeby jego pomysły mogły w formie możliwie 'niezmienionej' przejść przez etap analizy systemowej.

Przy projektowaniu kaskadowym tak. Ale właśnie techniki zwinne, scrum pomagają działać w projektach nietypowych. Trudno na początku w całości wszystko określić.

Ja takiego nie spotkałem :) A Ty?

Ja parę razy takiego widziałem; ale z daleka i niewyraźnie więc nie jestem pewny... ;)

Fatamorgana? :)

W sumie ta sytuacja mnie nie zaskakuje. Dobry, precyzyjny biznes plan ( w konsekwencji plan funk. systemu informatycznego który jest jego częścią) jest tak na prawdę programem który działa na rynku – procesorze.

Analogii jest z resztą cała masa a kluczowe w ww. kontekście brzmią
– ilu programistów wymaga (np. od przełożonego) dokładnego plan implementacji systemu przed jego wykonaniem ?
- jakie są efekty implementacji dużych systemów bez planu ? (freelance)

Problemem w iteracjach może być fakt, że trudno od razu wycenić pracę. No przynajmniej ja się jeszcze tego dobrze nie nauczyłem.

Zapewniam – to jest dość proste pod warunkiem, że się wie co trzeba zrobić.

Mamy chyba jednak inne projekty na warsztacie. Ja mam zdecydowanie bardziej "riserczowe". Zwyczajnie nie jestem w stanie określić wielu aspektów systemu we wstępnej fazie projektu. Może też nie umiem projektować - to bardzo prawdopodobne.

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Sergiusz B.:

Sławomir Orłowski:

Wybieram współpracowników (jeśli mogę).

A jeśli nie możesz? Jak sobie radzisz z "trudnymi" osobowościami?

Tutaj nie dam dobrej rady. Nie mam "dobrych praktyk". Sam bym się nauczył, jak pracować z trudnymi osobowościami. Staram się, żeby praca była jasno określona.

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Zamawianie czegoś czego nie potrafi się dobrze zdefiniować jest według mnie trochę niepoważne. Wymagania systemu są pochodną celów biznesowych. Jeśli wymagania są niejasne to najprawdopodobniej również cele b. są niejasne; w konsekwencji dochodowość całego przedsięwzięcia ( którego elementem jest system informatyczny ) najprawdopodobniej będzie mierna.

Zgadzam się, choć nie do końca. Cel może być jasny. Wymagania nie.
Cel: musimy zwiększyć udział w rynku nowym urządzeniem.

Celem jest zawsze zarobienie -pieniążków- ;)

Na poważnie - trzeba sobie zadać pytanie, czy takie urządzenie się sprzeda... Albo wiemy co robimy i mamy jasno zdefiniowaną grupę odbiorców albo grupa potencjalnych odbiorców zmienia się wraz z postępami prac na urządzeniem.

Na początku wymagania są rozmyte. Urządzenie szybsze, tańsze i
różowe. Potem się precyzują. Ale system już w trakcieprecyzowania się już powstaje.

... trochę jak ze złym pisaniem programu - jego architektura i funkcjonalność powstaje wraz z implementacją ;)

Według mnie, dobrze określone cele to właściwie wymagania.

Teoretycznie tak. Ale ... Ja lubię podejście Scrum i ogólnie zwinne, czyli właśnie dużo iteracji. Wtedy współpracując z klientem dochodzimy razem do rozwiązania optymalnego dla nas wszystkich.

Mnie w takich sytuacjach zawsze męczy pytanie 'skąd właściwie wiem, że to rozwiązanie jest dobre dla klienta'.

No bo go o to pytam co dwa tygodnie:)

A można takiemu wierzyć jeśli czasem zmienia zdanie i wcześniejsze decyzje ? ;)

Nie musi wiedzieć wszystkiego.
Chodzi jedynie o to, żeby jego pomysły mogły w formie możliwie 'niezmienionej' przejść przez etap analizy systemowej.

Przy projektowaniu kaskadowym tak. Ale właśnie techniki zwinne, scrum pomagają działać w projektach nietypowych. Trudno na początku w całości wszystko określić.

Wiem. To właściwie tak samo trudne jak programowanie. Programowanie jakiejś funkcjonalności 'wyciągnie' wszystkie jej niejasności i sprzeczności.

Pytanie czy klient chce je poznać na etapie realizacji (implementacji)...

Problemem w iteracjach może być fakt, że trudno od razu wycenić pracę. No przynajmniej ja się jeszcze tego dobrze nie nauczyłem.

Zapewniam – to jest dość proste pod warunkiem, że się wie co trzeba zrobić.

Mamy chyba jednak inne projekty na warsztacie. Ja mam zdecydowanie bardziej "riserczowe". Zwyczajnie nie jestem w stanie określić wielu aspektów systemu we wstępnej fazie projektu.

Czyja to jest wina ? :)

Temat: 2 lata doświadczenia - ale skąd je wziąc?

Skąd wziąść dwa lata doświadczenie - może trzeba spojrzeć tutaj

http://www.goldenline.pl/forum/2896296/junior-asp-net-...