WYCIĘTE Z MEJLI (AD ABSURDUM): Rozumiem
Od jakiegoś czasu śledzę blog WYCIĘTE Z MEJLI (AD ABSURDUM) (gorąco polecam). Dzisiaj przeczytałem to: "Rozumiem, że lubi Pan pracować w photoshopie, ale uważamy że ten program jest za mało…
Od jakiegoś czasu śledzę blog WYCIĘTE Z MEJLI (AD ABSURDUM) (gorąco polecam). Dzisiaj przeczytałem to: "Rozumiem, że lubi Pan pracować w photoshopie, ale uważamy że ten program jest za mało…
Jak widać próba wyceny całego projektu już na samym jego początku to wróżenie z fusów, wykonawca przyjmie wartość bezpieczna dla siebie, a tak określony budżet i tak zostanie skonsumowany (co pokazuje praktyka, tak się składa oferty w przetargach publicznych, taka jest jakość większości zapytań przetargowych!). Wystarczy wydzielić etap projektowania (analiza i projektowanie to ok. 20% kosztu developmentu) i zawrzeć umowę na etapie co najmniej wstępnego projektu, wtedy "zawyżanie" (narzucanie zapasu na niewiedzę) spada dwukrotnie. Opracowanie kompletnego projektu przed wyceną prac developmentu to obszar bliski prawej części: estymacja kosztu z bardzo małym błędem.
Wpadła mi niedawno w ręce książka: How to survive in the jungle of Enterpice Architecture Frameworks (autor Jaap Schekkerman, na Amazon.com dostępny fragment w tym spis treści). Dla mnie po lekturze tej książki nasuwa się jeden wniosek: moda na TOGAF to marketing The Open Group. Są inne, moim zdaniem ani gorsze ani lepsze, "ramy" architektoniczne (książka opisuje ich wiele). Podtytuł książki mówi wiele: Creating or choosing an Enterprise Architecture Framework (Tworzenie lub wybór ram architektury korporacyjnej). W zasadzie wystarczy wziąć przytaczaną powyżej definicję AE i podjąć powyższą decyzję: stworzyć lub wybrać. Nie jest to - tworzenie - łatwe, większość więc wybiera gotowe, jednak to jedynie ramy dlatego i tak nie da się tu niczego zastosować jak recepty.
Pierwszym etapem analizy, bardzo trudnym, jest opracowanie modelu pojęciowego. Celem budowy tego modelu jest zrozumienie na poziomie komunikacji (tak zwany biznes z developerem -> zagwarantowanie jednoznaczności) oraz zrozumienie tego co jest przedmiotem projektu (modelując magazyn raczej planujemy oprogramowanie symulujące kartoteki magazynowe a nie produkty w magazynie). Ważne jest by na oprogramowanie patrzeć jak na narzędzie, bo ono nim jest. Oprogramowanie wspomagające zarządzanie magazynem, nie zastępuje tego magazynu i towarów w nim... Tak więc oprogramowanie, nazwy w nim używane, muszą spełnić warunek zgodności ze "słownikiem biznesowym": biznesowy słownik pojęć (zgodność z nim) to jest wymaganie.
Na prawdę uważam, że ukrywanie treści ofert to sygnał: "jestem kanciarzem" (podobnie jak niepodpisywanie ich imieniem i nazwiskiem autora). Nie widzę nawet jednego powodu by np. cena była "know-how" firmy... jeżeli ktoś tak uważa to ... współczuję. Prawdziwe know-how spokojnie chroni prawo autorskie czy patentowe, tajemnica firmy - a np. szczegóły organizacyjne firmy (tajemnica), to raczej nie jest przedmiot oferty ani zapytania.