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”... ;-)

Komentarze