Nasze projekty nieraz przypominają taki worek do którego się wrzuca wszystko. W szczególności, gdy chcemy się czegoś nauczyć.Niedawno pisałem o nie szacowywaniu projektów. Dzisiaj chciałem się zastanowić nad drugim warunkiem granicznym.Projekt ma przecież na celu realizację konkretnego celu, a nie przybranie choinki językami, technologiami i technikami… To jest bardzo dobre, ale tylko do momentu, gdy spomiędzy technicznych cudów widać idee projektu, jego cel, i funkcjonalość założoną w Design Doc’u. A teraz pytanie – ile razy chciałem projekt wykorzystać do pokazania zaplecza technicznego w postaci mnogości technik i narzędzi na raz?
Jak się okazuje, nie jest taką prostą rzeczą stwierdzić, że nie wykorzystywałem projektów do takiego celu. Sam, gdy sobie to pytanie zadałem, musiałem się przyznać przed sobą do takiej praktyki.
Skąd to się bierze? Życie pokazuje, że w ten sposób prościej sprzedać produkt, albo siebie. Potencjalny kontrahent w natłoku nazw i terminów często się gubi, a obiecywane cuda wynikające z użycia tylu technologii przekonują. W końcu też, każdy zwieńczony sukcesem projekt, to jest konkretna reklama, namacalny punkt portfolio.
Tylko czy takie podejście jest uczciwe? Moim zdaniem nie bardzo, gdyż jeśli można zrobić coś mniejszym kosztem, to należy to zrobić, niezależnie od tego, że nie zgadza się to z naszym krótko terminowym interesem. Dlaczego? Po pierwsze, to jest nasz wizerunek. Gdy przychodzi ktoś, i mówi że potrzebuje taki, a taki produkt, i przeznacza na niego tyle, a tyle w związku z zastosowaniem ogromu technologii, to o ileż bardziej będziemy cenieni, gdy powiemy że można to prościej (bo mamy już przećwiczone takie rozwiązanie wcześniej), niż gdy sztucznie skomplikujemy sprawę chcąc jednorazowo zarobić trochę więcej. A drugie, to taki utkany projekt ciężko jest konserwować. To jest problem dla nas.
Ale co zrobić, gdy na myśl przychodzi rozwiązanie uniwersalne, a przez to użyteczne w wielu sytuacjach? Nie zastanawiać się, tylko implementować. Byle faktycznie dało się je potem wykorzystać. 🙂 I się nie pogubić w tym projekcie (tak jak ja to właśnie zrobiłem 😐 )
Mnie się nie jeden raz przydarzyło (i wciąż przydarza) pisanie projektów bardziej skomplikowanych (i ambitnych), niż trzeba. Piszę je jednak dla siebie, więc mogę pozwolić sobie na nich poćwiczyć nowe technologie i wypróbować wiele własnych pomysłów.
Sprawa zmienia znaczenie, kiedy zaczynamy pisać w jakimś określonym, konkretnym, celu – w szczególności, gdy piszemy na jakieś zlecenie. Tutaj przede wszystkim liczy się, żeby działało, i to działało dobrze. Dlatego trzeba zachować równowagę między pięknymi, ogólnymi rozwiązaniami a kodem trochę mniej uniwersalnym, ale działającym. Bo kod, który ma wartość artystyczną, ale nie robi nic pożytecznego, nie będzie wartościowy dla odbiorcy naszego projektu :).
Pozdrawiam!