Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Henryk M.:

Jarek Żeliński:

Ja z tego powodu właśnie (z czym się dla odmiany nie zgadza 99% programistów i analityków IT) uważam, że najgorszy sposób na zbieranie wymagań na oprogramowanie, to pyta przyszłych użytkownika co by chcieli.. i tu chyba się zgodzisz, patrząc na to co piszesz :)

Jarku,

Być może nie do końca rozumiem to, co napisałeś, być może dokonałeś skrótu myślowego. "piję" do tego, że dla mnie (jako osoby działającej w branży IT od ponad 26 lat) najgorszym sposobem na zbieranie wymagań na oprogramowanie było i jest wymyślanie togo, co "ma być" i nie pytanie przyszłych użytkowników, co by chcieli uzyskać. Z analitykiem, który "wie lepiej", co ma być nie rozmawiałbym w ogóle, tylko od razu odesłałbym, skąd przyszedł.

Moim zdaniem wiele projektów, w których miało powstać oprogramowanie dedykowane poległo, bo dopuszczono do tego, by bardzo szczegółowy opis wymagań wykonał przyszły użytkownik. To nie ma sensu z dwóch podstawowych powodów w tych sytuacjach:
- jeżeli sponsor projektu to pracodawca, jego podwładni mają inny cel niż on: np. zachować status quo
- jako "niespecjaliści" mają wymagania oparte na własnym doświadczeniu, jeżeli ma powstać coś nowego to po prostu nie powstanie bo niby dlaczego? (burza mózgów to mit http://it-consulting.pl/autoinstalator/wordpress/2011/...

Miernik? W 100% przypadków, gdy miałem okazje widzieć pierwotna specyfikacją wymagań jako efekt życzeń użytkowników, ostateczny i na prawdę przydatny produkt (o ile zdołał powstać) nie miał nic wspólnego z pierwotną specyfikacją wymagań, więc po co powstały?

Przykład Forda (robiłby konie) czy początki ery lotnictwa (samoloty machające skrzydłami) są tego dobitnym przykładem.

Użytkownicy, ogólniej - klienci, oczekują określonych wartości (można je nazywać korzyściami), a nie samego produktu (w tym przypadku: oprogramowania).

Moim klientem nigdy nie jest użytkownik oprogramowania, bo kiedy to przyszły Użytkownik jest sponsorem projektu? Kto ma odnieść korzyści z nowego narzędzia pracy? Pracodawca czy jego podwładny? Wyobrażasz sobie specyfikowanie wymagań na system wynagrodzeń jako listę życzeń pracobiorców? Znamy to ze związków zawodowych...

Dlatego rynek ICT jest teraz tak dynamiczny.

Zawsze był...

Dlatego BOS jest - moim zdaniem - wartym uwagi podejściem ze względu na koncentrację na wartości z punktu widzenia klienta.

Kto i czym tu jest klientem?

Oczywiście, jest margines na kreatywność i pomysłowość analityków, którzy mają za sobą duże doświadczenie i mogą podpowiedzieć użytkownikowi/klientowi to i owo. Natomiast z analitykami, którzy sami wiedzą najlepiej, "jak ma być" nie rozmawiam i nie współpracuję od ponad 10 lat. To dinozaury z poprzedniej epoki, przynajmniej dla mnie.

takich też nie lubię, ja realizuję zawsze wymagania sponsora projektu, firmami kierują ich zarządy a nie operatorzy maszyn, recepcjoniści czy fakturzyści... z całym szacunkiem dla ich pracy, to nie oni odpowiadają za zarządzanie...

Tak przy okazji: sam zauważam, jak bardzo muszę zmienić swoje podejście do analizy wymagań. ostatnio projektuję rozwiązania (aplikacje) na sprzęt mobilny (przede wszystkim smartfony) i zauważam, jakim obciążeniem jest dla mnie wieloletnia praktyka i zdobyte doświadczenie przy projektowaniu i wdrażaniu bardzo dużych rozwiązań korporacyjnych. Tu się liczy trafienie dokładnie w punkt - poprzez dostarczenie "w trybie pilnym" wartości, jakiej oczekuje klient/użytkownik. I nie ma żadnego znaczenia, że rozwiązanie może mieć 10, 20 lub więcej dodatkowych funkcjonalności, czy też może być "łatwo kastomizowalne" :o) Tu widzę spory obszar dla zastosowań typu BOS.

Ja zaś osobiście nie widzę różnicy pomiędzy aplikacją na smartfona i na PCta, też je projektuję... Wymagania pozostają, zmieniają się ograniczenia...

Przyjmuję jednak, ze możesz mieć rację Jarku, na przykład w kontaktach z użytkownikami w dużych firmach (korporacjach), dla których podstawową wartością jest wypłata "za obecność w pracy", a nie za kreatywność. Od takich użytkowników nie spodziewałbym się sensownych propozycji (żartuję).

Nie żartuj, ironizowanie też nie pomaga, duże korporacje zaś, to tylko pewna specyfika podobnie jak duże urzędy. Nie zapominaj, że te duże korporacje, jakie by nie były, jednak nie są bankrutami. (ale daleko mi też do pochwalania metod w jaki wiele z nich zarabia).

Niezależnie od tego co tu napiszemy, jest bardzo prosty miernik jakości analizy wymagań i projektowania (niezależnie od tego czy projekt jest informatyczny, organizacyjny czy inny): zgodność pierwotnego projektu z tym co w ostateczności powstanie - to uczy pokory. Wszelkie gadanie, że projekt ma prawo się zmieniać w moich oczach stanowi tyko wytłumaczenie złego projektowania. Zastanów się dlaczego maszyn tokarskich nie projektują tokarze, dlaczego samochodów nie projektują taksówkarze, dlaczego samolotów nie projektują piloci.... to na prawdę ma głęboki sens. Jedyne co projektują użytkownicy to np. garnitur na miarę u krawca ale bardzo często albo jest z szablonu albo bywa tragedią estetyczną.... Owszem należy zapytać pilota czy tokarza o to gdzie dla niego wygodniej będzie umieścić np. prędkościomierz, ale nie dyskutujemy z nimi czy w ogóle go umieścić, narzucamy im to.

Wydaje mi się, że być może obserwujemy te same zjawiska na rynku a inaczej interesujemy ich źródła...

P.S.
A tak z ciekawości: kto wg. Ciebie powinien opisać wymagania na oprogramowanie do rejestracji czasu pracy? (przypomnę, że aktorami są w tu niemalże w 100% Ci, których czas pracy jest rejestrowany...)Jarek Żeliński edytował(a) ten post dnia 03.02.13 o godzinie 23:50

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Właśnie siadam do kolejnego projektu i nasunęła mi sie pewna myśl w kwestii tak zwanych wymagań. Problem w tym, że pojęcie 'wymaganie" jest tak pojemne jak czarna dziura.

Uważam, że rolą analityka NIE JEST ZBIERANIE WYMAGAŃ, bo wymagania powinien mieć sponsor projektu (i nie powinny to być np. listy rozwijane w menu)!

Rolą analityka jest analiza! Analiza polega na analizie (:)), zrozumieniu analizowanego przedmiotu (firma, zjawisko na rynku, interakcje społeczne - testowanie projektu prawa, itp.) i jednoznaczne udokumentowanie wyników. Tak więc produktem pracy analityka jest przede wszystkim model tego co zostało zanalizowane. Celem jest zrozumienie. Jak to się ma do oprogramowania? Ma się bardzo, bo należy zamienić (a raczej olać) słowa przyszłego usera "chcemy tak bo zawsze tak robiliśmy" na obiektywny i logiczny - zrozumiały - opis tego co jest robione. A gdzie wymagania? No wymaganie to np. "program ma wspierać wystawianie faktur VAT" ale nie pytam o to "usera" tylko drążę ustawę i ewentualnie konsultuje z biegłym rewidentem, usera w ogóle nie pytam o to jak liczyć podatek VAT i jak obsłużyć magazyn.

Jednym z powszechnych przykładów tego jak "user stawia wymagania", są kretyńskie systemy dopuszczające w magazynach ujemne stany magazynowe! To jest niezgodne z prawem! Da się sprzedawać legalnie, nawet towar w drodze, trzeba jednak zrozumieć zjawisko, przepisy i zaproponować legalne rozwiązanie (a są takie).

Jak się ma tego BOS? Prawdę mówiąc po pierwsze nie znam definicji BOS nie nakładającej się na obecne, znane pojęcia z ekonomii i marketingu (np. nisza rynkowa), po drugie w projektach z obszaru zarządzanie i marketing czyli szeroko pojęte IT w biznesie, nie znam przypadku udanego projektu, w którym wymagania były efektem burzy mózgów przyszłych użytkowników... ale to,
że nie znam, mimo pracy w branży od 1991 roku :) nie znaczy że nie istnieją :)Jarek Żeliński edytował(a) ten post dnia 04.02.13 o godzinie 10:17

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Jarek Żeliński:

Moim zdaniem wiele projektów, w których miało powstać oprogramowanie dedykowane poległo, bo dopuszczono do tego, by bardzo szczegółowy opis wymagań wykonał przyszły użytkownik. To nie ma sensu z dwóch podstawowych powodów w tych sytuacjach:
- jeżeli sponsor projektu to pracodawca, jego podwładni mają inny cel niż on: np. zachować status quo
- jako "niespecjaliści" mają wymagania oparte na własnym doświadczeniu, jeżeli ma powstać coś nowego to po prostu nie powstanie bo niby dlaczego? (burza mózgów to mit http://it-consulting.pl/autoinstalator/wordpress/2011/...

Jarku, nie o tym pisałem. Napisałem, że odsyłałbym za drzwi analityków, którzy "wiedzą lepiej".
Jednym z kluczowych zadań analityka jest przeprowadzenie [b]razem z klientem/użytkownikiem[/i] kompletnej, profesjonalnej analizy problemu. Analityk wie jak analizę wykonać, klient wie, co chce uzyskać. Z takiej współpracy może powstać dobry produkt.

Powstanie systemu IT nie jest celem samym w sobie. Ma on wspierać realizację celów danej firmy. Czy analityk systemowy jest specjalistą np. w produkcji opakowań szklanych? wyrobów z tworzyw sztucznych? produkcji butów? itp. Nawet, jeżeli specjalizujesz się w jakiejś branży, to twoim atutem jest doświadczenie zebrane w wielu miejscach, np. w bankach, ale to pracownicy danego banku wiedzą lepiej, czego potrzebują.

Poza tym zakładam, że analityk współpracuje z właściwymi, kluczowymi dla danego tematu, pracownikami w firmie, a nie z ludźmi z łapanki na korytarzu. To jednak jest temat na inna dyskusję.

Nie wiem także, dlaczego wspomniałeś o burzy mózgów. To jest narzędzie "przedanalityczne" :o), przydatne na etapie kreowania nowych pomysłów i rozwiązań, ale nie na etapie analizowania wykonalności.

Miernik? W 100% przypadków, gdy miałem okazje widzieć pierwotna specyfikacją wymagań jako efekt życzeń użytkowników, ostateczny i na prawdę przydatny produkt (o ile zdołał powstać) nie miał nic wspólnego z pierwotną specyfikacją wymagań, więc po co powstały?

Może, Jarku, zabrakło interakcji analityka z osobami przygotowującymi wymagania?
U mnie sprawy miały się zwykle (nie napiszę zawsze :o) odwrotnie: gdy miałem czas na współpracę z przygotowującymi wymagania pracownikami danej firmy, powstawała specyfikacja "szczupła" 9tylko tyle, ile naprawdę potrzeba) i satysfakcjonująca wszystkie strony.
Zmiany w trakcie realizacji to inna sprawa. Przy takim podejściu było ich niewiele, i nie były kłopotliwe.

Przykład Forda (robiłby konie) czy początki ery lotnictwa (samoloty machające skrzydłami) są tego dobitnym przykładem.

Ford akurat dokładnie przeanalizował potrzeby użytkowników. Jest świetnym przykładem twórczego wkładu analityka w proces tworzenia zupełnie nowego produktu.
Poza tym zwróć uwagę na różnice: Ford opracował całkowicie nową koncepcję transportu, był odkrywcą. To jego konkurenci dostarczali na rynek "powozy z silnikami", ponieważ nie potrafili wyjść poza schemat bryczki ciągniętej przez konie (nota bene stąd się wzięły "konie mechaniczne" :o)
Tworząc kolejny system IT, choć może i różny od poprzednich, nie wchodzimy na ten poziom. Są to działania z zakresu B+R - inny rodzaj analizy.

Użytkownicy, ogólniej - klienci, oczekują określonych wartości (można je nazywać korzyściami), a nie samego produktu (w tym przypadku: oprogramowania).

Dokładnie tak, dlatego warto i trzeba dowiedzieć się, jak definiują (określają) te wartości. O to mi właśnie chodziło.

Moim klientem nigdy nie jest użytkownik oprogramowania, bo kiedy to przyszły Użytkownik jest sponsorem projektu? Kto ma odnieść korzyści z nowego narzędzia pracy? Pracodawca czy jego podwładny? Wyobrażasz sobie specyfikowanie wymagań na system wynagrodzeń jako listę życzeń pracobiorców? Znamy to ze związków zawodowych...

Wyobrażam sobie specyfikowanie wymagań na system wynagrodzeń jako współpracę z tymi, którzy:
- używają ten system bezpośrednio,
- znają procesy biznesowe firmy oraz mają doświadczenie w obsłudze podobnych (poprzednich) rozwiązań - wiedzą, co należałoby zmienić,
- wiedzą, jak ma współpracować z innymi systemami w firmie (niekoniecznie od strony technicznej),
- wiedzą, ile firma może zapłacić za system,
- pracobiorcy, ci, którzy pobierają wypłaty (oczywiście nie wszyscy :o) - oni także mają coś do powiedzenia.

Nie są to ci, którzy pobierają wypłaty, choć i tak wspomniane osoby znajdują się na liście płac :o)
Wydaje mi się, że mylisz interesariuszy w danym przedsięwzięciu z jego sponsorami.

Oczywiście, jest margines na kreatywność i pomysłowość analityków, którzy mają za sobą duże doświadczenie i mogą podpowiedzieć użytkownikowi/klientowi to i owo. Natomiast z analitykami, którzy sami wiedzą najlepiej, "jak ma być" nie rozmawiam i nie współpracuję od ponad 10 lat. To dinozaury z poprzedniej epoki, przynajmniej dla mnie.

takich też nie lubię, ja realizuję zawsze wymagania sponsora projektu, firmami kierują ich zarządy a nie operatorzy maszyn, recepcjoniści czy fakturzyści... z całym szacunkiem dla ich pracy, to nie oni odpowiadają za zarządzanie...

Jarku, w takim razie nie kontynuuje dyskusji na ten temat. Masz takie podejście do współpracy z Klientem - rozumiem. Ja mam inne. Nie kwestionuję, tylko przedstawiam swój punkt widzenia, oparty na swoim doświadczeniu.
To nie matematyka, i nie ma jedynie właściwych rozwiązań.

Pozdrawiam

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Henryk M.:
Jednym z kluczowych zadań analityka jest przeprowadzenie [b]razem z klientem/użytkownikiem[/i] kompletnej, profesjonalnej analizy problemu. Analityk wie jak analizę wykonać, klient wie, co chce uzyskać. Z takiej współpracy może powstać dobry produkt.

masz rację, ale warto chyba zaznaczyć, że analiza i projektowanie to odrębne etapy, po drugie użytkownik raczej określa swoje cele a nie projektuje oprogramowanie, tego ostatniego nie robi ani user ani analityk ;)

Powstanie systemu IT nie jest celem samym w sobie. Ma on wspierać realizację celów danej firmy.

bingo - czyli nie cele jej pracowników

Czy analityk systemowy jest specjalistą np. w produkcji opakowań szklanych? wyrobów z tworzyw sztucznych? produkcji butów? itp.

A czy architekt projektujący biuro dla firmy turystycznej jest specjalistą od sprzedawania wycieczek?

pracownicy danego banku wiedzą lepiej, czego potrzebują.

i tu mam problem, bo mój ostatni projekt dla pewnego banku pokazał coś zupełnie odwrotnego :)

Nie wiem także, dlaczego wspomniałeś o burzy mózgów. To jest narzędzie "przedanalityczne" :o), przydatne na etapie kreowania nowych pomysłów i rozwiązań, ale nie na etapie analizowania wykonalności.

wspomniałem, bo bardzo często dostaję "specyfikacje wymagań" jako właśnie produkty burzy mózgów,... nie pytaj mnie dlaczego...

gdy miałem czas na współpracę z przygotowującymi wymagania pracownikami danej firmy, powstawała specyfikacja "szczupła" 9tylko tyle, ile naprawdę potrzeba) i satysfakcjonująca wszystkie strony.

bo taka powinna być :)

Ford akurat dokładnie przeanalizował potrzeby użytkowników. Jest świetnym przykładem twórczego wkładu analityka w proces tworzenia zupełnie nowego produktu.
To jego konkurenci dostarczali na rynek "powozy z silnikami", ponieważ nie potrafili wyjść poza schemat bryczki ciągniętej przez konie (nota bene stąd się wzięły "konie mechaniczne" :o)

słowo klucz: "przeanalizował ich potrzeby a nie "spisał ich oczekiwania" ...

Tworząc kolejny system IT, choć może i różny od poprzednich, nie wchodzimy na ten poziom. Są to działania z zakresu B+R - inny rodzaj analizy.

i tu się chyba różnimy, ja staram się unikać sytuacji (chronić przed nią klientów), w której sami piszą o nowym oprogramowaniu: "dostaliśmy dokładnie to co chcieliśmy, ale zupełnie nie to czego potrzebujemy".

Wyobrażam sobie specyfikowanie wymagań na system wynagrodzeń jako współpracę z tymi, którzy:
- używają ten system bezpośrednio,
- znają procesy biznesowe firmy oraz mają doświadczenie w obsłudze podobnych (poprzednich) rozwiązań - wiedzą, co należałoby zmienić,
- wiedzą, jak ma współpracować z innymi systemami w firmie (niekoniecznie od strony technicznej),
- wiedzą, ile firma może zapłacić za system,
- pracobiorcy, ci, którzy pobierają wypłaty (oczywiście nie wszyscy :o) - oni także mają coś do powiedzenia.

a gdzie tu wiedza o tym jak naliczać wynagrodzenia, czyli sedno istnienia tego systemu? Bez tego taki system nie ma sensu... tu liczy się tylko to jak nalicza się wynagrodzenia, kto ma na to wpływ oraz źródła i odbiorcy danych (np. inne systemu: lista płac do FK). Kwestie ergonomii, kolorków, rozwijanych list itp. to elementy projektowania (inna rola w projekcie) a gdy szukamy gotowego oprogramowania, to co najwyżej prezentacji "jak Wam się podoba"...

Wydaje mi się, że mylisz interesariuszy w danym przedsięwzięciu z jego sponsorami.

dla mnie interesariuszem jest tylko ten (no z reguły), kto realnie może zablokować projekt (sponsor jest jednym z nich), jeżeli firma planuje wdrożenie kart pracy to pracownik nie ma tu nic do gadania jeżeli tylko taka decyzja zapadła - nie jest interesariuszem w myśl takiej definicji.

Jarku, w takim razie nie kontynuuje dyskusji na ten temat. Masz takie podejście do współpracy z Klientem - rozumiem. Ja mam inne. Nie kwestionuję, tylko przedstawiam swój punkt widzenia, oparty na swoim doświadczeniu.
To nie matematyka, i nie ma jedynie właściwych rozwiązań.

Nie jest moim celem ani krytyka cudzego podejścia ani namawianie do mojego. Ja także traktuję te dyskusje jako wymianę podejść, opisuje swoje, bardzo pragmatyczne i faktycznie ocierające się o "matematykę". Podejście które preferuje, restrykcyjnie przestrzegam ról w projekcie, i przede wszystkim zakładam, że przyszły użytkownik nie jest projektantem tego czego będzie używał bo nie ma do tego żadnych kwalifikacji, nie wątpliwie będzie testerem...

także sądzę, że warto ten poboczny wątek "zamknąć" :)Jarek Żeliński edytował(a) ten post dnia 04.02.13 o godzinie 12:01

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Jarek Żeliński:
Moim zdaniem wiele projektów, w których miało powstać oprogramowanie dedykowane poległo, bo dopuszczono do tego, by bardzo szczegółowy opis wymagań wykonał przyszły użytkownik. To nie ma sensu z dwóch podstawowych powodów w tych sytuacjach:
- jeżeli sponsor projektu to pracodawca, jego podwładni mają inny cel niż on: np. zachować status quo

Przekonałem się kilka razy, że da się to pogodzić

- jako "niespecjaliści" mają wymagania oparte na własnym doświadczeniu, jeżeli ma powstać coś nowego to po prostu nie powstanie bo niby dlaczego?

A sponsor na czym opiera swoje potrzeby. Jak dużo firm bazuje na badaniach (słucha) Klienta, nie mówiąc o rozmowie.

Miernik? W 100% przypadków, gdy miałem okazje widzieć pierwotna specyfikacją wymagań jako efekt życzeń użytkowników, ostateczny i na prawdę przydatny produkt (o ile zdołał powstać) nie miał nic wspólnego z pierwotną specyfikacją wymagań, więc po co powstały?

Czym innym jest opis wymagań wykonany przez użytkownika, a czym innym życzenia użytkownika. Zgodzisz się?

Moim klientem nigdy nie jest użytkownik oprogramowania, bo kiedy to przyszły Użytkownik jest sponsorem projektu? Kto ma odnieść korzyści z nowego narzędzia pracy? Pracodawca czy jego podwładny? Wyobrażasz sobie specyfikowanie wymagań na system wynagrodzeń jako listę życzeń pracobiorców? Znamy to ze związków zawodowych...

Jeżeli mówimy o użytkowniku końcowym jako Kliencie firmy a nie jej pracowniku, to uważam że to własnie on jest "sponsorem" projektu. Zawsze podchodziłem do tematu tak, aby wszyscy odnosili korzyść - można to pogodzić
[...]

Niezależnie od tego co tu napiszemy, jest bardzo prosty miernik jakości analizy wymagań i projektowania (niezależnie od tego czy projekt jest informatyczny, organizacyjny czy inny): zgodność pierwotnego projektu z tym co w ostateczności powstanie - to uczy pokory. Wszelkie gadanie, że projekt ma prawo się zmieniać w moich oczach stanowi tyko wytłumaczenie złego projektowania. Zastanów się dlaczego maszyn tokarskich nie projektują tokarze, dlaczego samochodów nie projektują taksówkarze, dlaczego samolotów nie projektują piloci.... to na prawdę ma głęboki sens. Jedyne co projektują użytkownicy to np. garnitur na miarę u krawca ale bardzo często albo jest z szablonu albo bywa tragedią estetyczną.... Owszem należy zapytać pilota czy tokarza o to gdzie dla niego wygodniej będzie umieścić np. prędkościomierz, ale nie dyskutujemy z nimi czy w ogóle go umieścić, narzucamy im to.

Nie wierzę, że to piszesz, serio. Uważam to za fundamentalny błąd. Dlatego tak wiele projektów się nie udaje. Dlatego tak wiele np systemów wspierających CRM jest bezużytecznych a wręcz powodem drwin użytkowników... kurka, mam wymieniać? Oczywiście, złe projektowanie - i oczywiście złe decyzje sponsora.

P.S.
A tak z ciekawości: kto wg. Ciebie powinien opisać wymagania na oprogramowanie do rejestracji czasu pracy? (przypomnę, że aktorami są w tu niemalże w 100% Ci, których czas pracy jest rejestrowany...)

Miałem okazje, jako pracownik, zgłaszać wymagania, definiując je jako pracę, którą ma wykonać za mnie system rejestracji czasu pracy (już to pisałem w jakimś temacie). Kompletnie nie widzę problemu aby uwzględnić potrzeby obu stron. Nam się to udało. Nie uda się wówczas, gdy robi się to w tajemnicy, po cichu, dla kontroli, etc. Budując odpowiednią świadomość potrzeb i "dedykowanych" rozwiązań systemowych dla pracowników firmy można osiągać zaskakujące rezultaty. Bo z Klientami firmy jest już "inaczej"...
Co do zmiany projektu w jego trakcie ... Polecam metodę design thinking, gdzie jedną z cech podejścia jest testowanie produktu/usługi z Klientem, dostosowanie do jego potrzeb, nawet więcej niż raz w procesie wytwórczym. Z autopsji wiem, jaką krzywdę mogliśmy sobie zrobić nie testując jednego z ostatnich projektów z Klientem, który bardzo źle został oceniony - podejście opracowane przez specjalistów - jak mogli :) Po zmianach i to dość istotnych było dobrze. Cały czas słuchamy Klientów i usprawniamy rozwiązanie.

p.s.
"niektórzy" twierdzą, ze dedykować można utwór literacki lub muzyczny, a nie aplikację :)Rafał Kamiński edytował(a) ten post dnia 04.02.13 o godzinie 22:57

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Jarek Żeliński:
Jak się ma tego BOS? Prawdę mówiąc po pierwsze nie znam definicji BOS nie nakładającej się na obecne, znane pojęcia z ekonomii i marketingu (np. nisza rynkowa), po drugie w projektach z obszaru zarządzanie i marketing czyli szeroko pojęte IT w biznesie, nie znam przypadku udanego projektu, w którym wymagania były efektem burzy mózgów przyszłych użytkowników... ale to,
że nie znam, mimo pracy w branży od 1991 roku :) nie znaczy że nie istnieją :)

Chyba popłynęliśmy :) Kto pisał, że na bazie brainstorming'u można zamknąć wymagania produktu?

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Rafał Kamiński:
A sponsor na czym opiera swoje potrzeby.

To pytanie do sponsora.. najczęściej ma jakąś biznesową motywacje... mogą być różne: obniżenie kosztów poprzez automatyzację, podniesienie jakości poprzez eliminację zbędnych prac, eliminację pracy własnych zasobów wprowadzając samoobsługę na stronie WWW, zawsze jednak jest to jakiś cel biznesowy... który nie determinuje rozwiązania problemu.

Odnoszę wrażenie że są tu mieszane różne elementy "dostarczenia oprogramowania";
- logika biznesowa, którą trzeba odkryć, udokumentować i zaimplementować
- oczekiwania w obszarze ergonomii i estetyki,
- ułatwienia pracy dla użytkownika (powiązane z ergonomią)

do tego mieszane są tu chyba:
- strony WWW, których użytkownikiem jest klient sponsora
- aplikacja biznesowa np. zarządzanie finansami, dokumentami czy projektami...

Jeżeli praca nad sklepem internetowy wymaga np. badań focusowych tak opracowanie wymagań nas archiwum dokumentów raczej pracy z ustawami...

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

... jakaś powtórka sie zrobiłaJarek Żeliński edytował(a) ten post dnia 04.02.13 o godzinie 23:36

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Jarek Żeliński:

Rafał Kamiński:
A sponsor na czym opiera swoje potrzeby.

To pytanie do sponsora.. najczęściej ma jakąś biznesową motywacje... mogą być różne: obniżenie kosztów poprzez automatyzację, podniesienie jakości poprzez eliminację zbędnych prac, eliminację pracy własnych zasobów wprowadzając samoobsługę na stronie WWW, zawsze jednak jest to jakiś cel biznesowy... który nie determinuje rozwiązania problemu.

Sorki, źle wyszło. To było pytanie retoryczne.

Odnoszę wrażenie że są tu mieszane różne elementy "dostarczenia oprogramowania";
- logika biznesowa, którą trzeba odkryć, udokumentować i zaimplementować
- oczekiwania w obszarze ergonomii i estetyki,
- ułatwienia pracy dla użytkownika (powiązane z ergonomią)
do tego mieszane są tu chyba:
- strony WWW, których użytkownikiem jest klient sponsora
- aplikacja biznesowa np. zarządzanie finansami, dokumentami czy projektami...
Jeżeli praca nad sklepem internetowy wymaga np. badań focusowych tak opracowanie wymagań nas archiwum dokumentów raczej pracy z ustawami...

kończąc - bo za bardzo zeszło na technologie, a to uważam jest drugorzędne w BOS/innowacji wartości - oprogramowanie na archiwum też ma wykonać pracę za kogoś.

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Rafał Kamiński:
kończąc - bo za bardzo zeszło na technologie, a to uważam jest drugorzędne w BOS/innowacji wartości - oprogramowanie na archiwum też ma wykonać pracę za kogoś.

hm... nowe technologie są bardzo często utożsamiane z innowacjami (albo i odwrotnie wręcz) więc może dlatego... ja osobiście nowinki na rynku utożsamiam z nowymi modelami biznesowymi, IT to jedynie narzędzia :) ja i wszystkie inne... nie demonizuje tej technologii :)

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Jarek Żeliński:

Rafał Kamiński:
kończąc - bo za bardzo zeszło na technologie, a to uważam jest drugorzędne w BOS/innowacji wartości - oprogramowanie na archiwum też ma wykonać pracę za kogoś.

hm... nowe technologie są bardzo często utożsamiane z innowacjami (albo i odwrotnie wręcz) więc może dlatego... ja osobiście nowinki na rynku utożsamiam z nowymi modelami biznesowymi, IT to jedynie narzędzia :) ja i wszystkie inne... nie demonizuje tej technologii :)

technologia jest bardzo często istotną częścią innowacji, ale nie jest nią samą w sobie, zawsze czemuś służy :)

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Rafał Kamiński:
technologia jest bardzo często istotną częścią innowacji, ale nie jest nią samą w sobie, zawsze czemuś służy :)

no to tu chyba jesteśmy zgodni: skoro technologia zawsze czemuś służy, to jako narzędzie, sama z siebie świata nie czyni :) (ale ja nie jestem technokratś więc mam prawo tak sądzić ;)))

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Jarek Żeliński:

Jarek, co myślisz na temat MVP (minimum viable product)? Uważasz, że może być skuteczną metodą dostarczania oprogramowania (nie tylko dla startup'ów)?

Temat: Czyżby Strategia Błękitnego Oceanu umarła?

Rafał Kamiński:

Jarek Żeliński:

Jarek, co myślisz na temat MVP (minimum viable product)? Uważasz, że może być skuteczną metodą dostarczania oprogramowania (nie tylko dla startup'ów)?

Wydaje mi się, że to dobra strategia dostarczania produktów o relatywnie krótkim cyklu życia. Można uznać, że skoro nie wiemy jak "długie życie" będzie miał nasz produkt (dostarczone oprogramowanie) to zakładamy na użytek liczenia jego ROI (NPV), że czas życia jest krótki. To bardzo obniża ryzyko wpadek finansowych ale podnosi ryzyko, że wylejemy jakies projekty jak dziecko z kąpielą. Takie podejście - krótki czas zwrotu - powoduje, że odsetek pomysłów zakwalifikowanych jako nierentowne jest znacznie większy. Zabezpiecza to przed nadmiernym optymizmem ale zmusza do odrzucania wielu pomysłów. Ma to jednak sens chyba, bo życie pokazuje, że autorzy pomysłów są strasznymi optymistami :)

Podejście takie można spotkać np. w bankach, gdzie pisze się dedykowaną aplikację pod nowy produkt i wyrzucą ją gdy produkt już nie jest oferowany. To jest znacznie efektywniejsze niż próby tworzenia oprogramowania uniwersalnego.

Faktycznie jest ono stosowane w start-upach internetowych ale jak widzisz nie tylko. Moim zdaniem to bardzo słuszna koncepcja :), chyba nawet rodem z Kaizen. Bywa, że stosuję wpisując w wymaganiach, że to efemeryda :). Jeżeli pomysł wypali, takie oprogramowanie (z reguły jest to szybko tworzone niskiej jakości software) należy konsekwentnie potraktować jak prototyp odrzucany a nie materiał na refaktoryzację.