11/11/2006 ·
Link
Widzieliście zapewne film "Przeminęło z wiatrem". W pewnym momencie Scarlett zbiega ze schodów wypowiadając zdanie
Pomartwię się tym jutro (przynajmniej tak to zapamiętałem -
w wersji oryginalnej jak się okazuje brzmi to:
I can't think about that right now. If I do, I'll go crazy. I'll think about that tomorrow. )
Zapewne nie będąc tego świadomą Scarlett udzieliła nam doskonałej rady dotyczącej planowania działań w projektach informatycznych.
Zasada Scarlett O'Hara to podstawowa zasada optymalizacji działania. Mówiąc wprost polega ona na tym, że rozwiązywanie problemów odkładamy tak późno, jak to tylko możliwe.
Przykład - napisany kod obsługujący wyświetlanie informacji na stronie internetowej będzie wymagał refaktoryzacji. Na razie jest ok, ale jeśli wzrośnie obciążenie - nie podoła. Wydaje nam się, że mamy ze trzy miesiące czasu, ale pada argument "i tak trzeba to będzie zrobić, więc zróbmy to teraz". Jeśli zdecydujemy się stosować zasadę Scarlett, to odkładamy to zadanie. Monitorujemy ruch, by wrócić do niego, gdy pojawi się potrzeba.
Inny przykład - pojawia się nowa wersja platformy bazodanowej. W ogólności warto na nią zmigrować (i prędzej czy później będzie to konieczne, choćby ze względu na kończący się support dla starszych wersji), ale w tej chwili nie przyniesie nam to żadnych istotnych korzyści. Zgodnie z zasadą - nie migrujemy, dopóki zmiana sytuacji nie spowoduje, że zaniechanie migracji oznaczać będzie kłopoty (brak supportu, trudności z opracowaniem nowych modułów etc).
Jeszcze inny przykład - w projekcie pisanym na zamówienie, w umowie jest zapisane wymaganie wykonania modułu archiwizującego stare dane. Ponieważ system jest dopiero wdrażany, więc moduł archiwizacji będzie potrzebny dopiero za dwa lata. Aplikujemy zasadę: robimy inne moduły, które będą potrzebne wcześniej.
Albo tak: system będzie trzeba zintegrować z innym z wykorzystaniem JMS na JBossie. Nikt z naszego zespołu nie zna tej technologii. Skądinąd jednak wiadomo, że system z którym mamy się integrować nie będzie uruchomiony przez najbliższe pół roku. Co robimy? Nic! Czekamy. Pomartwimy się tym jak przyjdzie czas.
Dlaczego to działa? Otóż z następujących powodów:
- Jest to optymalizacja wykorzystania zasobów. W każdym momencie projektu powinniśmy mieć aktualną priorytetową listę zadań do zrobienia i kierować siły tam, gdzie mogą przynieść największą korzyść (czyli do najważniejszych zadań). Uwaga - priorytety zmieniają się w czasie, coś co w ogólności jest super ważne (integracja) może być dziś jeszcze nieistotne (niewdrożony system, z którym mamy się integrować).
- Unikanie niepewności. Póki nie ma fizycznie systemu z którym mamy się realnie integrować, to musimy polegać na dokumentacji. A przecież może zostanie wdrożony w innej wersji? Może dokumentacja jest niedokładna? Może życie pokaże, że użytkownicy zmienią zdanie i będą chcieli wymieniać inne dane? Im dłuższy czas między opracowaniem modułu a jego rzeczywistym wdrożeniem, tym mniej polegamy na rzeczywistych wymaganiach, potrzebach, faktach a bardziej na naszym wyobrażeniu. A delta pomiędzy faktami a wyobrażeniem jest proporcjonalna do tego odstępu czasu.
- Unikanie ryzyka zmarnowania wysiłku. Widziałem to wiele razy: moduł, który miał być potrzebny za rok, okazywał się w końcu w ogóle nie potrzebny. Projekt wdrożenia systemu, z którym trzeba się było integrować, był anulowany. Zmieniały się założenia co do technologii. Zmieniali się ludzie. Zmieniały się założenia biznesowe. Koniec końców, całe połacie kodu szły do kosza.
Zasada ta ma jeszcze jedno zastosowanie. W złożonych projektach nie jesteśmy w stanie przewidzieć wszystkiego, więc nieuniknione jest, że w pewnym momencie uświadomimy sobie, że w przyszłości czeka nas duży problem (np. platforma systemowa w ogóle nie umożliwi wykonania pewnej niezbędnej operacji). Na dziś nie jesteśmy w stanie nic w tej sprawie przedsięwziąć ze względu na ograniczenia czasowe, budżetowe, polityczne... Na razie jest ok, ale w przyszłości problem nas uderzy. No cóż - martwić się w takiej sytuacji, jest tylko marnowaniem wysiłku - a więc pomartwmy się tym jutro!
Z drugiej strony, zasada Scarlett wiąże się z pewnymi problemami:
- Czasem rozwiązać dany problem dziś może być łatwiej, taniej, szybciej.
- Problem może zostać zapomniany i wrócić w niedobrym momencie.
- Rozwiązanie zajmuje dużo czasu i później może już być za późno.
Jakie jest Wasze podejście? Gdzie jest złoty środek pomiędzy ślepym optymizmem a przesadną zapobiegliwością? Na ile możliwe jest modyfikowanie podejścia, a na ile wynika ono z charakteru danej osoby?
Podyskutujmy... (4)
21/09/2006 ·
Link
Słyszeliście o
Joel Test? Dla tych co nie słyszeli, szybki skrót: test Joela, to krótka ankieta, która pozwala ocenić sposób wytwarzania oprogramowania w danej firmie. Choć niektóre z jej założeń mogą być dyskusyjne, to zaletą w porównaniu do innych technik (np. modelu
CMM) jest to, że wynik można mieć w ciągu trzech minut (np. już podczas rozmowy o pracę :) ).
Z ciekawości rozesłałem tę ankietkę do kilku niereprezentatywnie wybranych firm w których pracują moi znajomi. Są wśród nich małe, są średnie, jest jeden kolos. Większość koncentrujące się na produkcji oprogramowania na zamówienie (dla klientów biznesowych). Część z nich odpowiedziała i oto rezultaty.
Poniżej zamieszczam wyniki z poszczególnych firm:
No coż, nie jest to badanie naukowe, więc nie ma sensu snuć wielkich wniosków. Na kilka refleksji i zdziwień jednak sobie pozwolę:
- Żadna z firm nie wypadła rewelacyjne dobrze, a większość z nich dobrze sobie radzi na rynku. Ciekawe jaka byłaby jakość ich produktów i sukcesy rynkowe, gdyby się podciągnęły? Wdrożenie większości z tych punktów nie wymaga ani dużego nakładu finansowego ani wielkich zmian organizacyjnych.
- Zdziwiło mnie, że niewiele z firm prosi o napisanie kodu podczas rozmowy kwalifikacyjnej. Jak wobec tego oceniają one kandydatów do pracy? Tylko na podstawie deklaracji? Opinii z poprzedniej pracy bądź innych osób? Jak wiele osób nie sprawdza się w trakcie okresu próbnego?
- Mało firm robi cokolwiek, by przetestować interfejs użytkownika. Dlaczego? Czy to jest uważane za mało ważne? Nawiasem w USA są kierunki studiów/specjalizacje poświęcone usability; czy gdzieś tego uczą w Polsce?
- Oszczędność na narzędziach sugeruje, że koszty pracy informatyków w Polsce są jednak wciąż znacznie niższe niż na zachodzie.
Jak to wygląda u Was w firmie? Jesteście liderem? Stosujecie totalną partyzantkę? Jak to się przekłada na rezultaty? Dajcie znać.
(Jeśli wolicie zachować anonimowość, to proszę o
kontakt tą drogą, wyniki, bez informacji pozwalającej zidentyfikować firmę, dołączę do powyższej tabeli)
Podyskutujmy... (9)
27/04/2006 ·
Link
Pod
tym adresem można znaleźć kilkustronicowe podsumowanie raportu, opracowanego przez Standish Group, na temat czynników mających wpływ na sukces projektów informatycznych (to właśnie ten, z którego wiadomo, że sukcesem kończy się tylko 28% projektów). Raport dotyczy Stanów Zjednoczonych i pochodzi sprzed kilku lat, mimo to jest inspirującą lekturą.
Ciekawe jest również zawarte w tym dokumencie zestawienie, jakie umiejętności powinien posiadać, w opinii autorów raportu, idealny kierownik projektu. Może to być dobra wskazówka generalnego kierunku rozwoju dla początkujących menedżerów.
Na pewno wartościowe byłoby móc obejrzeć wyniki podobnych badań dla projektów prowadzonych w Polsce - na moją wiedzę niestety się takich nie prowadzi. Ciekaw jestem Waszych opinii, czy mamy swoją polską specyfikę problemów w projektach? Czy są jakieś czynniki grożące projektom, występujące u nas w większym nasileniu? A może w czymś jesteśmy istotnie lepsi od Amerykanów? Czekam na Wasze opinie.
Podyskutujmy... (1)
22/04/2006 ·
Link
Zaczynam pracę nad serią artykułów o przyczynach porażek projektów informatycznych. W pierwszym z nich chciałbym opisać typowe będy występujące w fazie analizy wymagań. Wstępna lista zidentyfikowana przeze mnie wygląda tak:
- Błędnie zidentyfikuj udziałowców projektu
- Unikaj jasnego określenia celów projektu
- Ignoruj cele biznesowe i skup się na funkcjonalności
- Zrezygnuj z zapisania wizji
- Pozwól decydować użytkownikom
- Pozwól decydować deweloperom
- Pozwól na grupowe podejmowanie decyzji
- Zgódź się na wszystkie wymagania
- Uznaj wszystkie wymagania za niezbędne
- Zignoruj koszty i ograniczenia technologiczne (np. wydajnościowe)
- Ogranicz czas na analizę
- Pozwól na zmianę wymagań w trakcie (lepiej - na zmianę celów)
- Zrezygnuj z use-case'ów i prototypów
- W rozmowach z użytkownikami używaj informatycznego żargonu
- Pozwól dominować papierom i formalizmom
- Ugrzęźnij w detalach
Spotkałeś się z innymi problemami dotyczącymi zbierania wymagań? Uczestniczyłeś w projektach, gdzie takie błędy skutkowały problemami w dalszej fazie projektu lub wręcz jego porażką? Będę wdzięczny za wszelkie sugestie - można je przesłać na przykład za pomocą
tego anonimowego formularza.
Podyskutujmy...
