TheTarPit

kryptonim: polmos

Produkcja oprogramowania kategorii środkowej pociąga za sobą jeszcze jedną komplikację, której wcześniej nie byłem świadom — wersjonowanie programu okazuje się nie całkiem banalne.

wersjonowanie

Po pierwsze wersja produktu staje się bardzo ważna. Klienci zapłacili wystarczająco dużo, żeby sobie zapewnić Twoją uwagę, a jednocześnie jest ich wystarczająco wielu, żebyś ich nie pamiętał imiennie „z kontraktu”. Stąd numer wersji oprogramowania, o której jest mowa, stanowi podstawę każdego kontaktu z klientem. I bynajmniej nie jest to „ta nasza wersja, pan wie, z tym, że pan Janek robił jeszcze jakieś poprawki wczoraj w nocy, a pani Ania zrobiła nam takie specjalne ustawienia”, jak to nagminnie się zdarza w przypadku systemów pisanych na konkretne zamówienie.

Po drugie, kiedy usiłujesz wyprodukować i sprzedać oprogramowanie dla wielu niezależnych klientów, stajesz czasami przed koniecznością zaprezentowania wersji prototypowych i/lub wykonania demonstracji produktu w fazie „bardzo nie gotowej”. Klienta trzeba przecież czymś przyciągnąć i przekonać. Niby tak samo jak w każdym innym modelu sprzedaży oprogramowania — wiadomo. Niestety trudność polega tutaj na tym, że klient, któremu to prezentujesz, jest jednym z wielu. Każdego z nich będziesz usiłował przekonać być może innym fragmentem nowej funkcjonalności nowej wersji produktu. Przy ilości klientów liczonej w setkach lub tysiącach nie jest możliwe utrzymywanie jakiejś proporcjonalnie dużej ilości wersji demonstracyjnych. Trzeba zatem założyć, że demo prezentowane klientowi zawiera jeszcze inną funkcjonalność, która mimo iż dla tego klienta jest mniej lub bardziej nieważna, wpływa na całokształt wersji końcowej. W tym oczywiście na moment jej wydania.

To wszystko jednak jest jeszcze całkiem proste do przewidzenia. Problem, który mnie trochę zaskoczył to nazewnictwo takiej wersji...

odliczanie

Zazwyczaj jest tak, że produkując nową wersję oprogramowania umieszczamy w niej B poprawek do istniejących błędów, I poprawek funkcjonalności małego kalibru oraz E elementów nowej funkcjonalności. Oczywiście B < I < E.

Kiedy mamy na rynku wersję V.R produktu, a E jest sporą liczbą, to pewnie wydamy nowy produkt jako V+1.0. Jednak jeśli E jest niewielkie w stosunku do B i I to raczej będzie to V.R+1. Jednak co w sytuacji, kiedy implementacja funkcjonalności z zakresu E przeciąga się ponad miarę, a my już wykonaliśmy wiele prezentacji i wersji demonstracyjnych produktu nazywanego przez cały ten czas jako V+1.0? Czy wydać to jako V+1.0 mimo niepełnej funkcjonalności (następuje rozmycie znaczenia wersji głównych) czy może jako V.R+1 (czyli nie to, co było dotychczas prezentowane)? Możliwa jest też sytuacja odwrotna — coś, co było cały czas wersją V.R+1, nagle jest promowane do V+1.0 tylko dlatego, że minęło już „naprawdę sporo czasu” od wydania wersji poprzedniej.

Tak czy inaczej, powstaje sytuacja, której z marketingowego punktu widzenia wolelibyśmy uniknąć. Czyli klasyczne nazewnictwo V.R bierze w łeb.

nazywanie

Dlatego znacznie lepszym pomysłem okazuje się stosowanie nazw kodowych — bez ujawniania numeru wersji, czy nawet oficjalnej nazwy produktu, tak długo, jak to tylko możliwe.

Sposób wyboru takiej nazwy jest problemem samym w sobie i właściwie stanowi element lokalnego folkloru danej organizacji. Niektóre firmy, jak np. Microsoft, mają całkiem pokaźną historię takich nazw. Myślę, że im więcej dużych programów dana firma produkuje, tym bardziej wyraźne są opisane powyżej problemy i tym bardziej rozbudowana historia nazw kodowych.

Niestety, jak to często bywa z folklorem, znaczna jego część nie nadaje się do upublicznienia. Ja na przykład wątpię, żeby ktokolwiek usłyszał o fakcie, iż dla jednego z naszych produktów powstała w wyniku pewnego niefortunnego przesłyszenia nazwa „polmos edition”, zamiast (wcale nie bardziej oficjalnego) „almost”... ;-)

...ponieważ jesteś kretynem, który łatwo daje się zagadać

Są takie książki, których warto się uczyć na pamięć. I są takie cytaty, które po prostu trzeba zapisać...

Jak przeżyć pod naporem zadań i nie zwariować do końca

Disclaimer: znowu będzie marudzenie o sprawach, które nikogo nie obchodzą. Za to będzie długo. Ale co mi tam. Czasem trzeba po prostu napisać coś dla przekonania samego siebie, że pewne działania wbrew pozorom mają sens... ;-) Charakter mojej pracy uległ w czasie ostatniego pół roku tak znacznej zmianie, że właściwie nie spodziewałem się, że to kiedykolwiek nastąpi. Słowem wpadłem po uszy w środowisko rzeczywiście sterowane zadaniami. Nie dziwne zatem, że starając się przeżyć (efektywnie) w pracy i równocześnie wyspać (również efektywnie) nie myśląc o pracy po nocy, opracowałem sobie pewien zestaw zachowań i zebrałem pewien zbiór maksymalnie prostych narzędzi umożliwiających funkcjonowanie w środowisku sterowanym zadaniami. Garść przemyśleń poniżej. Wszelkie komentarze i propozycje jak zwykle mile widziane...

Ja nic nie wiem, ja tu tylko programuję...

Po ponad 8 latach pracy zawodowej z systemami o zbliżonym i względnie ograniczonym zakresie biznesowym, dokonałem ostatnio całkowitej zmiany branży... Stąd narasta we mnie od jakiegoś czasu pytanie, którego nie miałem potrzeby zadawać właściwie nigdy wcześniej: na ile ważne jest zrozumienie procesu biznesowego klienta i sposobu w jaki używa on naszego oprogramowania?

Rzeczywistość tu jak nieczynne neony

Zapewne tego nie widać, ale sporo się u mnie dzieje. Niestety(?) nie w zakresie tematów, które mogłyby zainteresować potencjalnych czytelników tego bloga. Z waszego punktu widzenia można założyć, że mam coś w rodzaju wakacji. A w ramach zapchajdziury wrzucam tu kilka luźnych przemyśleń zainspirowanych miejscem, w którym się w międzyczasie znalazłem...

poniedziałek — czas zapolować na demony

Kiedy System Informatyczny staje się Dużym Systemem Informatycznym?

Starszych wpisów szukaj w archiwum tematu lub ogólnym.