Firma tworzy produkt. Produkt ma grupę docelową, jasno określony przedział zastosowań. Czasami ma również misję, cel swojego istnienia.
Tak było, kiedy zaczynałem pracę nad swoim autorskim narzędziem CMS, wego cms. Wego nie miało nazwy, tytułowało się zwyczajnie, Panelem Administracyjnym, wersja 1.0.
Działało lepiej niż większość popularnych systemów, o niebo lepiej niż siermiężne paneliki pisane przed moim zatrudnieniem, pod każdego z klientów z osobna. Miało jeszcze jedną zaletę, było dobrze zaplanowane na poziomie kodu, zbudowane obiektowo, modularne i — co bardzo ważne — w żaden sposób nie ingerowało w wygląd serwisu, którym miało zarządzać.
Przez rok od momentu napisania pierwszej linii kodu, w projekcie wiele się zmieniło. Pojawiały się nowe funkcje, usprawnialiśmy poprzednie, poprawialiśmy czytelność kodu. Refaktoryzacje przechodziły falami, zmiany dotyczyły wszystkiego, od sposobu przekazywania danych pomiędzy poszczególnymi komponentami, przez zmiany w kodzie widgetów (panel — ze względu na szybkość rozwoju — nie operuje na kodzie HTML, zamiast tego budując interfejs za pomocą mechanizmu zagnieżdżanych kontrolek i kontenerów, wzorowanego na GTK+), aż do zmiany sposobu, w jaki serwis końcowy uzyskuje dostęp do danych. Ten ostatni element został doprowadzony do poziomu, gdzie całość strony powstaje z użyciem tylko i wyłącznie szablonów Smarty:
Przykład szablonu strony produktu w serwisie Dolnośląski Skarb
Przez cały czas, moim — jako początkowo autora, a później głównego programisty i Managera Projektu — celem było zbudowanie produktu, który coś wniesie na rynek podobnych rozwiązań. Wego jest jednym z najnowocześniejszych systemów zarządzania treścią, ale jednocześnie jest jednym z najprostszych i najwygodniejszych w obsłudze. Właśnie na tej prostocie mi szczególnie zależało i to ona do dzisiaj jest celem większości zmian w systemie. Wego miało być najlepszym sposobem na zarządzanie małym lub średnim serwisem.
Z drugiej strony, mój szef w wego dopatruje się tylko metody zarabiania pieniędzy. Zdaje się nie dostrzegać tego, że o sile produktu stanowi jego pozorne nieskomplikowanie. Moja kreatywna rola managerska sprowadza się więc ostatnimi czasy do dysponowania ticketami zgłaszanymi przez szefa. A są to głównie prośby o wstawienie więcej informacji, ograniczenie pustego miejsca, które można przecież jakoś zagospodarować i dodanie funkcjonalności, która — cytując nbw — pozwoli nam na sprzedaż małym firmom narzędzia, które z powodzeniem mogłoby obsługiwać Bibliotekę Narodową.
Nie lubię sytuacji, kiedy ktoś jawnie mówi mi, że interes użytkownika stoi w konflikcie z interesem firmy, a my powinniśmy mieć narzędzie do wszystkiego. Paradoksalnie, niedawno zawitała do nas przedstawicielka handlowa jednego z konkurencyjnych systemów CMS i, zapytana o możliwości systemu, bez skrępowania powiedziała, że do większych wdrożeń polecają produkt konkurencji, z którą mają podpisaną umowę partnerską. Jak widać można, jeśli się tylko chce.
Pozostaje się tylko cieszyć, że podobnej wizji rozwoju produktu nie podzielają producenci samochodów, bo wtedy mielibyśmy do czynienia z terenowymi limo-busami rajdowymi na gąsienicach, które co prawda palą 100 litrów benzyny na 100 kilometrów, ale w razie powodzi świetnie radzą sobie jako amfibie.