Projekt z uśmiechem

Projekt z uśmiechem—brzmi pozytywnie, ale jest jeszcze gorszy niż zwykły projekt z niesmakiem (jeśli ktoś nie wie co to, polecam dowcip).

To jeden z tych projektów, kiedy już na początku wiadomo, że się widowiskowo nie uda. Oraz że góra tego do wiadomości nie przyjmuje. Na pewno coaching (więcej pozytywnego nastawienia), praca w weekendy i damy radę... pardon, dacie radę. Siadamy w zespole, patrzymy po sobie i jest wesoło. Wesołość to ostatnia faza rozpaczy, po prostu nic już innego nie pozostało jak się chociaż pośmiać. :-) Potem trzeba tylko uważać na odłamki.

Zapytanie ofertowe o żółty, zakrzywiony, jadalny produkt

Wessał mnie korpowir i nie miałem ostatnio czasu na aktualizowanie blogaska. Mam w zanadrzu kilka wpisów, ale wymagają dopracowania.

Tymczasem zaserwuję cudzy zestaw złotych myśli nt. RFP, zwanego także Zapytaniem Ofertowym wraz z SIWZ-em. ;)

• A few notes on procurement — na przykładzie banana
• What Does Your Storage RFP Say About You? — nieco bardziej poważnie

Jak wiemy, przezroczyste postępowanie tego typu prowadzi do wyłonienia najlepszej oferty. ;-) Polecam artykuły jak i komentarze.

They later informed us that despite the fact that this "required" operating system didn't actually exist, none of the other vendors had asked about it, and none had taken any exception to fully supporting it in their RFP responses.

Next up, how about a full year? No says the farmer, no way. Ah, but the legal eagle of the bidding team has discovered that the matrix does not provide for who the 'product' should be edible! Would a rat eat a one year old banana? Definitely! COMPLIANT!

Terytoria IT

Kilka dni temu wysłałem IT do psychiatry. Dziś serwuję (za Just Enough Developed Infrastructure) IT wraz z otoczeniem zobrazowane na mapie - The Map is not the Territory: The IT-World Anno 2010. Klienci, użytkownicy, wielka czapa wszelkich form zarządzania, rozwój, testowanie i utrzymanie, bezpiecznicy, service desk oraz infrastruktura.
Ładnie to wygląda, ale co to oznacza w praktyce? W realnym świecie mamy np.:

1. Podział na biednych i bogatych. Jeden dział ma lepsze "przełożenie" i konsumuje pieniądze potrzebne innym działom.
2. Strefy skażenia. Nikt nie chce ich nawet dotykać (syndrom "to nie moje").
3. Wojenki. Jeden lokalny kacyk robi na złość drugiemu za nie swoje pieniądze i trzeba go jakoś obchodzić, żeby dopiąć celu.
4. Każdy sobie rzepkę skrobie. Brak zdolności współpracy w obliczu nadciągającej katastrofy.

Brzmi znajomo?

Obgryzanie Wymagań

Pracuje sobie człowiek (nie)spokojnie, a tu nagle trach! - wpada nowy projekt. Trzeba coś zrobić.

W odróżnieniu od życia, kiedy pewne fundamentalne pytania człowiek zadaje sobie raczej u kresu ;) w projekcie zdecydowanie warto postawić te pytania od razu: "Dlaczego?", "Jak?", "Kiedy?", "Co?", "Gdzie?", "Kto?". Inaczej coś może przeobrazić się w skrzyżowanie meduzy z kameleonem - projekt o bardzo bardzo płynnym zakresie. ;)

Stawianie tych pytań to element zarządzania wymaganiami, a same pytania pożyczyłem z bloga "O wymaganiach". Stwierdziłem, że pomarudzę o tym, bo prześladuje mnie Potwór Zmiany Zakresu, a szczególnie jego odmiana bezkapuchowiec objawiająca się obgryzaniem zakresu do kości. Brr!

Potwora wywołuje zwykle sponsor, kiedy jego wybujałe oczekiwania zderzą się ze ścianą realnych kosztów projektu. Wywoływanie zachodzi np. na rytualnym, tajnym spotkaniu ważnych osób na szczycie, podczas którego rysuje się markerem tajemne znaki na białej tablicy. Zwykle łatwiej jest obciąć zakres projektu niż załatwić dodatkowe finansowanie. Rozpoczyna się polowanie, atmosfera absurdu tężeje jak w Misiu: "A gdyby tu było nagle przedszkole"?

Oczywiście, zakres nie jest cięty z chirurgiczną prezycją, powstają rany projektowe gryzione (choć niekoniecznie widać je w PowerPoincie). W efekcie powstaje wtórna fala nowych wymagań, kompensujących braki powstałe po cięciu zakresu. Tak, właśnie w środku projektu (albo nawet na końcu) nastąpiła zmiana wymagań. Wypełzają wszelkiej maści ohydne obejścia, których normalnie nikt nie odważyłby się nawet zaproponować.

Budżetowo wygląda to tak: klient chciał jaguara, ale nie było go stać więc zapłacił za mercedesa, tyle że funkcjonalnie dostał malucha. Ale mamy sukces, budżet został dotrzymany. ;)

Wracając do wymagań - po co nimi zarządzać? Cóż, warto wiedzieć, co właściwie robimy, jak i na kiedy ;) ale też trzeba mieć listę, którą można będzie rzucić Potworowi Zmian Zakresu na pożarcie. On na pewno kiedyś się pojawi i nie będzie z Tobą dykutował.

Slajdologia

Podejmujesz dużo ważnych decyzji i nie masz czasu wnikać w ich materię? Nic trudnego, wystarczy poprosić interesariuszy o prezentacje w postaci slajdów.

Slajdy są jak papier - zniosą wszystko. Ba, są nawet lepsze, jeśli plik źródłowy nie zostanie rozpowszechniony - nie zostawiają śladów. Dobre slajdy mogą uzasadnić niejeden pokrętny Business Case. Slajdy są proste więc nawet dziecku łatwo je zrozumieć. Na slajdach można się też uprawiać korpoślizg - prezentujący sprzedaje się szerokiemu i ważnemu gremium jako kumaty gość, podczas gdy wsad do slajdów powstaje w mało widowiskowej, żmudnej pracy wielu szarych ludzi.

Oczywiście, nie chodzi o slajdy same w sobie (one są bardzo przydatnym narzędziem), lecz o to, jak wpływają na kulturę podejmowania decyzji.

Natknąłem się ostatnio w sieci na kilka niepochlebnych opinii nt. stosowania PowerPointa. Co prawda pochodzą one ze środowisk wojskowych, ale procesy decyzyjne zachodzą również w organizacjach cywilnych - zatem pozwolę sobie zacytować i polecić lekturę. ;)

We Have Met the Enemy and He Is PowerPoint

• PowerPoint makes us stupid
• It's dangerous because it can create the illusion of understanding and the illusion of control

Dumb-dumb bullets

Unfortunately, as soon as they graduate, our people return to a world driven by a tool that is the antithesis of thinking: PowerPoint. Make no mistake, PowerPoint is not a neutral tool - it is actively hostile to thoughtful decision-making. It has fundamentally changed our culture by altering the expectations of who makes decisions, what decisions they make and how they make them.

DevOps - utopia czy źródło przewagi konkurencyjnej?

Czy deweloperzy powinni mieć dostęp do systemów produkcyjnych?
Odpowiedź na to pytanie wydaje się prosta. Oczywiście, że tak/nie! (zależnie, kto odpowiada). ;-)

 

W dużych firmach o strukturze silosowej zwykle podział ten jest "naturalny". Z kolei w małych firmach, gdzie wszyscy zajmują się wszystkim, podziału takiego nie ma. Rozdzielenie rozwoju systemów od ich utrzymania ma niewątpliwie pewne zalety, ale wydaje się, że zyskuje ostatnio na popularności trend odwrotny - nazwany DevOps.

Aby dobrać właściwy model, należy przeanalizować potrzeby i ograniczenia konkretnej organizacji. Osobiście skupiłbym się przede wszystkim na następujących czynnikach:

• niezawodność/dostępność - deweloperzy bez doświadczenia utrzymaniowego mogą zwyczajnie zagrozić stabilności środowiska produkcyjnego
• integralność - deweloper majstrując przy wnętrzu aplikacji na produkcji może np. rozspójnić dane
• poufność - deweloper z dostępem do produkcji to dodatkowe potencjalne źródło wycieku danych
• wymogi formalne - przepisy prawa mogą wymuszać na danej organizacji wyraźne odseparowanie rozwoju systemów od środowiska produkcyjnego
• generyczność aplikacji - system może być rozwijany pod to jedno, konkretne wdrożenie i wymaga głębokiej wiedzy o zachowaniu systemu na produkcji
• zmienność - systemy bywają modyfikowane bardzo często lub np. raz na kilka lat
• skuteczność - rozwiązywanie problemów bez dostępu do produkcji może być trudne, długotrwałe, a przez to kosztowne
• procedury i struktura firmy - procedury bywają stosowane bezmyślnie, dodatkowo rozdział rozwoju od utrzymania generuje więcej stanowisk dla menedżerów, którzy mogą mieć słabą komunikację lub wręcz konkurować

Tak więc należy ustalić, czy w danej sytuacji deweloper na produkcji bardziej szkodzi czy pomaga? I jeśli nie ma naprawdę dobrych powodów uzasadniających ścisłą separację rozwoju od eksploatacji, tej separacji warto po prostu unikać jako szkodliwego narzutu. :)

Niektórzy idą dalej i łączą obie funkcje: rozwój i eksploatację (we code and run). Wydaje mi się, że to nie zawsze ma sens, np. w przypadku aplikacji biznesowych, gdzie duży wysiłek dewelopmentu to prace analityczne. Ale w przypadku aplikacji webowych, tolerujących krótkotrwałe przestoje i zdolnych testować nowe funkcjonalności na końcowych użytkownikach - jak najbardziej.

Sporo ciekawych uwag na ten temat można przeczytać we wpisie Should Developers have Access to Production? oraz jego komentarzach.

 

Tematyka zaszczepiania DevOps nie tylko przy utrzymaniu środowisk web, ale w organizacjach typowo biznesowych (w tym przekonywania menedżerów do tego podejścia), jest także tematem niniejszych paneli InfoQ:

• DevOps outside of Web Operations
• Making the Business Case

Uczestnicy zwracają w nich uwagę m.in. na:

• model DevOps to nie zwykła zmiana organizacyjna lecz zmiana kultury (rozbijanie silosów) i nie należy jej wprowadzać odgórnie, raczej przez dobry przykład
• można pokazać DevOps jako podejście ułatwiające osiągnięcie celów biznesowych organizacji
• istotne jest wcześniejsze ustalenie dobrych metryk (KPI) - bez tego nie da się menedżerom pokazać, czy zmiana cokolwiek poprawiła (np. skrócony TTM)
• metryki należy monitorować i stopniowo doskonalić organizację
• dla menedżerów wyższego szczebla często nie liczą się już liczby, lecz zaszczepienie wizji

 

Podsumuję cytatem z posta What Is This Devops Thing, Anyway?

Devop requires a certain state of mind. It's an attitude which says: I'm going to make a difference, I'm going to cooperate and communicate, and I'm going to understand that in the business of delivering great software, we're all in it together. If you're a sysadmin, this means spending time with the developers. (...) If you're a developer, go and make friends with your sysadmins. Don't view them as lower life forms, or as people to lob problems to. Go and join in - pair with them.

Brzmi jak utopia? ;-)

Kaszmirowy sweterek informatyka

Kiedy na spotkaniu projektowym nie jesteś w stanie rozróżnić po ubiorze szeregowych przedstawicieli IT od eleganckich Kierownika Produktu i Kierownika Projektu, to może być sygnał, że z firmą coś jest nie tak. Kiedy firma ma za dużo pieniędzy, manifestuje się to nie tylko rozdętymi systemami, ale także przesiąkaniem świata menedżerów do świata informatyków.

Idziesz do kuchni i nie słyszysz rozmowy o optymalizacji wydajności albo użytecznych bibliotekach, tylko np. o quick winach, challengowaniu, celach premiowych i wdrażaniu inicjatyw polepszających komunikację. Na spotkaniu projektowym grupa średnio zorientowanych osób debatuje nad niezbyt złożonym technologicznie problemem. Grupa nie dochodzi do konsensusu więc zaprasza się jeszcze więcej osób i dyrektorów.

Paul Graham, znany popularyzator idei start-upów, w felietonie "What Happened to Yahoo" opisuje wynaturzenia, jakie zrodziły dla tej spółki łatwe pieniądze. Zwraca szczególną uwagę na odpływ kompetencji technicznych i zestawia to z przykładami firm takich jak Google czy Facebook, które potrafią kultywować "kulturę hakerską". Ostatecznie Yahoo oddał walkowerem rynek reklam w wynikach wyszukiwania Googlowi.

Pozwolę sobie podprowadzić fragment felietonu na zachętę:

In technology, once you have bad programmers, you're doomed. (...) Most technology companies eventually get taken over by suits and middle managers. At Yahoo it felt as if they'd deliberately accelerated this process. They didn't want to be a bunch of hackers. They wanted to be suits. (...) Why would great programmers want to work for a company that didn't have a hacker-centric culture, as long as there were others that did? I can imagine two reasons: if they were paid a huge amount, or if the domain was interesting and none of the companies in it were hacker-centric. Otherwise you can't attract good programmers to work in a suit-centric culture. And without good programmers you won't get good software, no matter how many people you put on a task, or how many procedures you establish to ensure "quality".

Aplikacje jak krzyże

Nowe aplikacje w organizacji są jak krzyże - łatwo się je stawia, a trudno usuwa.

W gruncie rzeczy to zrozumiałe i zasadne. Komplikacja świata rośnie i znajduje odbicie w komplikacji i mnogości systemów w danej organizacji. Ale czy to jedyny powód mnożenia systemów? Wydaje mi się, że nie.

Czasem nowa aplikacja pojawia się, bo ktoś dał się przekonać slajdom na prezentacji Bardzo Drogiego Produktu, że taki produkt jest naprawdę dobry i profesjonalny. Umożliwi naszej firmie podążanie w kierunku, w którym podążają już inni. Rzeczywiście, znajomy prezes innej firmy podczas gry w golfa wspomniał, że właśnie go wdrażają. Nie możemy być gorsi - wdrażamy i my. (Charakterystyczne dla firm, które mają za dużo pieniędzy).

Kiedy indziej okazuje się, że pewien obszar działalności organizacji powinien zostać wsparty systemami IT, ale niestety kilka dotychczas wdrożonych systemów jakimś cudem nie nadaje się do tego celu. Kupujemy więc kolejny i spokój. Albo lepiej, dewelopujemy jakieś własne rozwiązanie, które ukrywa braki produktów komercyjnych.

Z czasem może się okazać, że takie własne rozwiązanie nieco się rozrosło i bez niego firma nie może funkcjonować. Co by nie mówić, rozwój własnych aplikacji daje niemal nieograniczoną elastyczność w reagowaniu na zmiany potrzeb biznesowych. Nie ma jednak wsparcia producenta - na kogo dyrekcja zwali ewentualne problemy? (Jakie problemy? - zastawia się deweloper aplikacji znający ją na wskroś i usuwający błędy "od ręki"). Doskonały powód, by wymienić je na jakieś nowe, komercyjne rozwiązanie ze wsparciem. Drogim wsparciem. W praktyce może się okazać, że co prawda wdrożono nowe, ale z jakiegoś powodu wciąż nie można wyłączyć tego starego...

Mamy więc systemy, które nie były przeznaczone do likwidacji, takie, które chciano zlikwidować, ale się nie udało, i oczywiście te nowe, które były mniej lub bardziej potrzebne.

Tych nowych nie będziemy przecież likwidować - tyle pieniędzy na to wydaliśmy... już lepiej wydać drugie tyle, by je "udrożnić" i zacząć stosować.

Tych starych nie będziemy przecież likwidować - są filarem naszej firmy, za duża rewolucja. Czasem nawet upgrade jest zbyt ryzykowny - a że utracimy wsparcie? Cóż, korzystamy z tego X lat i ile tych zgłoszeń do supportu poszło? Trzy? I rozwiązywali je ile? Dwa... tygodnie? To o całe 13 dni dłużej niż robili to nasi administratorzy.

Można spróbować zlikwidować te już raz przeznaczone do likwidacji, a co się dotąd nie udało. Pozostaje życzyć powodzenia. :-)

Dyktat Business Case

Przeczytałem niedawno artykuł Zasada skautów. Nie jestem programistą, ale obserwuję takowych oraz całą otoczkę związaną z wprowadzaniem zmian w systemach. Artykuł proponuje, aby programiści stosowali zasadę zawsze zostawiaj kod czystszym niż go zastałeś. Udoskonalenia mogą być drobne, ale tak jak skumulowane przez lata drobne niedoskonałości doprowadzają do erozji kodu, tak skumulowane przez lata drobne usprawnienia mogą wydźwignąć kod z bagna.

Do umieszczenia tego wpisu zainspirowały mnie komentarze pod artykułem, że tego typu podejście w realnym świecie bywa niemożliwe do zastosowania. Zupełnie się z tym zgadzam albowiem obserwuję zjawisko, które nazwałem roboczo dyktatem business case'u (BC).

W firmach skupionych na działalności biznesowej, dla których IT pełni rolę służebną, nie dewelopuje się dla przyjemności, tylko do zaspokojenia określonych potrzeb biznesowych organizacji. Decyzja o wykonaniu lub nie określonej zmiany podejmowana jest po analizie BC przez zarządzających, bywa że najwyższego szczebla (zależnie od budżetu). Na tym poziomie nikt nie wnika, czy kod jest ładny. Na słupku w arkuszu kalkulacyjnym widzimy, że wydamy kwotę X i uzyskamy z tego tytułu przychody albo oszczędności na kwotę Y w horyzoncie k-letnim - to jest coś, co przemawia.

Problem jest taki, że istnieją rzeczy, które inżynier uważa za stosowne by je wykonać, ale bardzo trudno biznesowo uzasadnić związane z tym koszty. Dokumentacja, refaktoryzacja pewnych części, przeprojektowanie API, lepsze walidacje, większa uniwersalność, lepsza integracja z systemem operacyjnym, czytelniejsze logi, itd. - z punktu widzenia użytkownika biznesowego to mogą być rzeczy "mało ważne", "ryzykowne dla harmonogramu", "możliwe do realizacji w terminie późniejszym", "na inny projekt".

I rzeczywiście jest tak, że nie powstają rozwiązania dobre, tylko wystarczająco dobre. Nie obsługują niektórych specyficznych przypadków i trzeba dane poprawiać ręcznie (tańsze to niż poprawka aplikacji). Wymagają restartu co noc (akceptowalne, w nocy nie pracujemy). Mają SQL injection (ale używają ją tylko zaufani pracownicy, którzy prawdopodobnie tego nigdy nie odkryją). Działa przy zbyt dużych uprawnieniach (ale działa, a mogłaby nie działać). Ma bardzo niestandardowe skrypty uruchamiające (uczulimy administratorów). Loguje pełno śmieci i rzuca wyjątkami na lewo i prawo (dyski są tanie). Konsumuje duże zasoby (RAM jest tani). Ale za to było połowę tańsze, dzięki czemu BC w ogóle się spiął. Z punktu widzenia klienta biznesowego to może być wręcz pełny sukces.

Te drobiazgi kumulują się w czasie, a niesmak z pracy z kodem rośnie. Rośnie również kulka hacków i workaroundów, ale póki to jakoś istotnie finansowo nie uderzy w organizację (system stanie się krwiobiegiem organizacji i zacznie być blokerem jej rozwoju ze względu na trudność wprowadzania zmian), wszyscy będą z tym żyli pchając całość do przodu. Może to trwać wiele, wiele lat...

Update - w pewien sposób ilustracja tego o czym piszę ;) Brytyjski rząd: Internet Explorer 6 jest wystarczająco bezpieczny.

Ile może kosztować prosty skrypt powłoki?

Wyobraźmy sobie, że mamy sieć rozległą, złożoną z wielu elementów aktywnych IP. Elementy oraz łącza podkładowe ulegają czasem awarii. Postanawiamy stworzyć proste narzędzie monitorujące - skrypt powłoki:

• pobierający z bazy danych wykaz urządzeń,
• testujący pingiem ich dostępność,
• wysyłający e-mail do administratorów w przypadku, gdy któreś urządzenie jest nieosiągalne.

Zaniedbajmy fakt, że jest to klasyczne wynajdywanie koła. Ile może kosztować napisanie czegoś takiego?

Sprytna odpowiedź brzmi: to zależy. ;)

Zwinny administrator, posługujący się biegle powłoką i językami skryptowymi, popełni w tzw. międzyczasie jednolinijkowca. Jest to bezkosztowe lub bardzo tanie - powiedzmy 0,1 tys. PLN.

Jeśli zrobi to pracownik zewnętrzny, dojdzie jeszcze prowizja handlowca, krótka dokumentacja dla klienta, prezentacja "jak to działa" - powiedzmy że do 2 tys. PLN.

Co jednak, gdy rzecz dzieje się w środowisku objętym zarządzaniem zmianami? Warsztaty wymagań z użytkownikami, dokument analizy, kodowanie, dokumentacja i testy odbiorcze. Całkowity koszt może wynieść bez problemu 10 tys. PLN.

A gdyby to nie było w kraju PLN-ów lecz w którymś zamożnych krajów Europy Zachodniej... ;-)


Do czego zmierzam? Czy zarządzanie zmianami to źródło zła? Odpowiem: to zależy! ;)

Można wysnuć z tego różne wnioski:

1. Rzeczy, które są proste i tanie w realiach małej firmy, niekoniecznie są takie w realiach dużej firmy.
2. Uwzględniając powyższe, w realiach dużej firmy zakup bardzo drogiego, ale gotowego oprogramowania może być i tak tańszy, niż wdrażanie i wsparcie (TCO) dla oprogramowania darmowego.
3. Narzut wprowadzany przez różne standardy i metodyki może podnieść koszty rozwiązania np. o 2 rzędy wielkości, nie zawsze poprawiając jakość rozwiązania.
4. W realiach dużej firmy te podwyższone koszty mogą być wciąż zaniedbywalne, a bardziej zwinne firmy zyskują dzięki temu szansę zarobkowania (brutalnie rzecz umując, pasożytują na bezwładnej korporacji sprzedając jej prosty software za wielkie pieniądze).
5. Mnóstwo pieniędzy może zostać zmarnotrawionych na wszelkie formy zarządzania i pośrednictwa, a nie na samo rozwiązanie - jest to więc dobre miejsce na szukanie oszczędności.