Jak wycenić projekt IT?

• 1. Wstęp
• 2. Do kogo kierowany jest artykuł?
• 3. Przed wyceną
• 4. Doprecyzowanie specyfikacji
• 4.1. Budowa zestawienia interpretacji i pytań
• 4.2. Rozmowy z klientem
• 5. Podejścia do wycen
• 5.1. Top-down
• 5.2. Bottom-up
• 5.3. Podsumowanie podejść do wyceny
• 6. Metody wycen
• 6.1. Problemy z metodami wycen
• 7. Wycena
• 7.1. Rozpisanie specyfikacji
• 7.2. Ustalenie priorytetów
• 7.3. Analiza historyczna
• 7.4. Ustalenie wielkości velocity
• 7.5. Estymowanie zadań
• 7.6. Doliczenie buforów i premii
• 7.7. Wyliczenie czasu i kosztów realizacji
• 7.8. Doliczenie lub odliczenie kosztów komunikacji i nauki
• 7.9. Doliczenie innych kosztów i marży
• 8. Wycena a realizacja
• 9. Podsumowanie

1. Wstęp

Wycena projektów IT zwana również wymiarowaniem i szacowaniem jest jednym z pierwszych procesów wykonywanych po stronie Dostawcy. W mojej pracy korzystałem z różnych metod wycen dostępnych na rynku i dokonując ich analizy, wybrałem praktyki, które moim zdaniem są najbardziej skuteczne w przygotowaniu wyceny.

2. Do kogo kierowany jest artykuł?

• Dostawcy, Właściciele firm IT – Jeśli przymierzasz się do wyceny projektu IT możesz poznać zastosowanie różnych metod wycen w praktyce. Sposób wyceniania opieram na własnych doświadczeniach.
• Osoby i firmy zlecające projekt IT – Jeśli chcesz zlecić wykonanie projektu IT możesz poznać proces wyceny po stronie Dostawcy. Podczas zamówienia i rozmów z Dostawcą jesteś w stanie wpłynąć na ostateczną cenę jaką otrzymasz.

3. Przed wyceną

Kluczowym warunkiem do wykonania wyceny jest specyfikacja przedmiotu, który będziemy wyceniać. Podczas mojej pracy spotkałem się z sytuacją, w której Klient prezentował głównie wizję oprogramowania, często jeszcze nie skończoną. W takich sytuacjach konieczne jest doprecyzowanie specyfikacji, o którym piszę w następnym rozdziale.

Elementy jakie powinna zawierać specyfikacja po krótce opisałem przy okazji wpisu Jak zlecić i przeprowadzić projekt IT?

Przed wykonaniem wyceny powinniśmy wstępnie zastanowić się czy czas poświęcony na wycenę będzie zasadny względem projektu, który wyceniamy? Wycenę można przeprowadzić z różną dokładnością, która pociąga za sobą czas i koszty takiego procesu. W przypadku mniejszych projektów IT długofalowy proces wyceny może być nieopłacalny.

Powinniśmy również zdawać sobie sprawę z ryzyka jakie niesie za sobą wykonanie wyceny. Głównym celem Klienta, który przesłał zapytanie może być tylko zebranie ofert z rynku (tzw. benchmark). Z uwagi na to, że wykonanie wyceny dla Klienta nie jest płatne, Klient może poprosić o nią szereg firm tak, aby dowiedzieć się jakie są różne stawki rynkowe. W takim przypadku praca poświęcona na wycenę nie przyniesie przychodu.

4. Doprecyzowanie specyfikacji

Kiedy spotykamy się z sytuacją, w której Klient przedstawia nam wizję projektu lub jego specyfikacja nie jest dopracowana, najlepszym rozwiązaniem na tym etapie jest przekonanie go do projektu dwuetapowego, który składa się z analizy i opracowania specyfikacji oraz realizacji.

4.1. Budowa zestawienia interpretacji i pytań

Przed rozpoczęciem rozmów z Klientem możemy przygotować zestawienie interpretacji i pytań, które będzie zawierać określone kolumny przedstawione w przykładzie poniżej:

Zapisy ze specyfikacji	Interpretacje i pytania
WF 01.001 – System musi pozwalać na obsługę zgłoszeń telefonicznych.	Czy zgłoszenie otrzymane drogą telefoniczną ma zostać zanotowane w systemie?
WF 01.002 – System musi pozwalać na obsługę zgłoszeń mailowych.	Rozumiemy, że po otrzymaniu wiadomości ma ona zostać zarejestrowana w systemie i ma zostać nadany numer identyfikacyjny zgłoszenia. Prosimy o szczegółowe informację w jaki sposób obsługa zgłoszeń mailowych ma zostać zrealizowana?
WF 01.003 – System musi posiadać opracowane skrypty, zgodnie z którymi będą obsługiwane zgłoszenia.	Czy system ma pozwalać na stworzenie skryptu na podstawie udzielonej odpowiedzi? Rozumiemy, że podczas wysyłania odpowiedzi na zgłoszenie operator będzie mógł wyszukać odpowiedni skrypt i wysłać wiadomość ręcznie.

Z uwagi na powtórzenie w lewej kolumnie treści specyfikacji taka forma jest wygodna dla osób, które przygotowują zestawienie oraz dla Klienta, ponieważ w trakcie sporządzania i czytania nie trzeba szukać określonych punktów.

Jeśli zestawienie jest przesyłane do Klienta w wersji elektronicznej warto wstawić trzecią kolumnę na odpowiedzi.

Przygotowanie powyższego zestawienia może również otworzyć Ci drogę do konstruktywnych rozmów z Klientem na temat projektu dwuetapowego. Klient widząc szereg pytań do poszczególnych punktów specyfikacji sam zauważy, że koniczne jest przeprowadzenie dokładniejszej analizy.

W przypadku zapytań przetargowych również możesz zadawać pytania do Klienta, jednak muszą być one wysłane do połowy wyznaczonego terminu składania ofert. Do tego terminu Klient musi udzielić Ci odpowiedzi, po tym terminie nie ma już takiego obowiązku.

4.2. Rozmowy z klientem

Niezależnie od jakości specyfikacji bardzo dobrym rozwiązaniem jest nawiązanie relacji z Klientem. Prawdopodobnie podczas rozmowy będziesz mógł uzyskać informacje, które nie są podane w specyfikacji.

Jeśli wysłaliśmy do Klienta zestawienie interpretacji i pytań to powinieneś dążyć do umówienia spotkania roboczego, podczas którego będziesz mógł omówić poszczególne punkty.

Podczas rozmów z Klientem będziesz mógł rozwiać jego obawy związane z projektem dwuetapowym (analiza i opracowanie specyfikacji oraz realizacja).

Warto podkreślić, że w przypadku projektu dwuetapowego Klient tak naprawdę nie ryzykuje, ponieważ opracowana i rozliczona analiza wraz ze specyfikacją wykonana w pierwszym etapie pozostaje jego własnością i może zostać wykorzystana na potrzeby realizacji z innym Dostawcą.

Trzeba zwrócić uwagę, że pierwszy etap projektu obejmujący przeprowadzenie analizy i opracowanie specyfikacji pozwala Ci również na wykonanie szczegółowej wyceny oprogramowania.

Odpowiednia realizacja pierwszego etapu wiąże się również z mniejszym ryzykiem jakie niesie za sobą dalsze kontynuowanie projektu przez Klienta.

5. Podejścia do wycen

Posiadając już specyfikacje umożliwiającą wycenę możemy przejść do wyceny. Poniżej prezentuję dwa podejścia do wyceny: top-down (wycena rynkowa) oraz botom-up (wycena oparta na kosztach dostarczenia rezultatu).

5.1. Top-down

Jest to podejście, które opiera się na wyliczeniu ostatecznej ceny w oparciu o wartość rynkową oprogramowania.

Wartość rynkową oprogramowania możemy oprzeć na innych cenach, dostępnych publicznie w rozstrzygniętych przetargach. W celu uzyskania cen innych oferentów możemy wystartować w postępowaniu przetargowym z własną ofertą.

Dodatkowym sposobem jest również pozyskanie informacji rynkowych poprzez zapytania kierowane do porównywalnej konkurencji.

Wycenę top-down możemy również wyliczać na podstawie wcześniejszych zamówień danego Klienta oraz wielkości gwarancji jaka jest wymagana w ramach postępowania przetargowego.

Podejście top-down bardzo dobrze sprawdza się w przypadku oprogramowań specjalistycznych, w których jest mniejsza konkurencja na rynku.

W przypadku podejścia top-down ma znaczenie nasza pozycja specjalisty w danej dziedzinie. Jeśli nasza specjalizacja w określonej dziedzinie jest wysoko oceniana, to tym samym Klient jest w stanie zapłacić wyższą cenę, ponieważ gwarantujemy mu dostarczenie wyników wyższej jakości.

Zalety podejścia top-down

1. Możliwość uzyskania zdecydowanie wyższej marży. W przypadku wyceny top-down dla określonego typu oprogramowania możemy podać cenę przewyższającą nasze koszty trzy/czterokrotnie (lub więcej). Jest to uzależnione specjalizacją określonego rozwiązania i możliwościami finansowymi po stronie klienta.
2. Szybki proces wyceny. Wycena w podejściu top-down może być bardzo rozbudowana i długotrwała, jednak w większości przypadków jest szybsza niż podejście bottom-up.

Wady podejścia top-down

1. Zbyt wysoka wycena dla Klienta. Ten przykład można bardzo wyraźnie zaobserwować w ofertach przetargowych, w których ceny oferentów przekraczają kwoty, jakie Klient przeznaczył na realizację przedmiotu zamówienia. Jednym słowem stosując podejście top-down możemy przestrzelić cenę.
2. Ryzyko zbyt niskiej ceny. Wycena opierająca się tylko na podejściu bottom-up może pociągać za sobą ryzyko zbyt niskiej ceny, która może być poniżej kosztów realizacji. Rozwiązaniem w takiej sytuacji jest możliwość wykonania wyceny w dwóch podejściach.

5.2. Bottom-up

Większość metod wycen w przypadku projektów IT odnosi się do modelu bottom-up, czyli wyceny liczonej na podstawie zakresu oraz kosztów dostarczenia rozwiązania.

W dalszych rozdziałach przestawię Ci mój model wyceny bottom-up, który opiera się na istniejących modelach wyceny na rynku.

Zalety podejścia bottom-up

1. Zaangażowanie zespołu w mojej ocenie jest ważnym czynnikiem podejścia bottom-up. Członkowie zespołu są zdecydowanie bardziej przekonani do szacunków jakie zostały wykonane, co przekłada się na inne elementy projektu (opisuję to niżej).
2. Zmniejszenie ryzyka przekroczenia kosztów. Podejście bottom-up opiera się na analizie kosztów realizacji. Jeśli wycena zostanie przeprowadzona poprawnie (także pod względem ryzyka) nie powinno mieć miejsca przekroczenie kosztów.

Wady podejścia bottom-up

1. Długi czas realizacji wyceny. W metodzie jaką prezentuję poniżej należy zaangażować członków zespołu. Analiza, rozpisanie zadań, estymacja mogą trwać zbyt długo i w przypadku mniejszych projektów IT ta metoda może być zbyt droga.
2. Brak możliwości skorzystania w możliwości rynkowych. Oferty składane w ramach ofert przetargowych pokazują, że część z firm proponując rażąco niskie ceny traci możliwości rynkowe ustalenia wyższej ceny. Dodatkowo ich oferta może zostać odrzucona przez Klienta.

5.3. Podsumowanie podejść do wyceny

W przypadku wycen jakie wykonujemy możemy zastosować jedno podejście lub dwa podejścia jednocześnie (top-down i bottom-up). Wykonanie wycen wg dwóch podejść pokazuje nam jak bardzo nasza wycena oparta na kosztach odbiega od wyceny rynkowej.

Poniżej prezentuję przykładowe wyceny w dwóch podejściach wykonane dla dwóch różnych projektów.

Przykład z projektu 1

Jeśli jesteśmy przekonani co do wyceny top-down możemy ją zastosować uzyskując w ten sposób większą marżę w danym projekcie. Przy okazji możemy większą kwotę przeznaczyć na premie dla zespołu (które opisuję niżej).

Przykład z projektu 2

W przypadku, jeśli cena top-down jest niższa możemy ją zastosować obniżając marżę lub też oprzeć się na wycenie składającej się z bottom-up, premii i marży.

6. Metody wycen

Na rynku istnieje szereg metod wycen takich jak:

1. Wycena przez analogię
2. Wycena ekspercka (indywidualna i grupowa)
3. Wycena metodą COCOMO
4. Wycena oparta na dekompozycji i rekonstrukcji
5. Wycena oparta na zastępstwie
6. Wycena metodą punktów funkcyjnych (IFPUG)
7. Wycena metodą przypadków użycia (Use Case Point)
8. Wycena metodą COSMIC
9. i inne

W niniejszym wpisie chciałbym podzielić się techniką, która wynika z mojego własnego doświadczenia i czerpie z wyższej wymienionych metod.

Napisz proszę w komentarzu poniżej lub wyślij wiadomość jeśli chcesz, abym opisał dla Ciebie poszczególne metody wycen.

6.1. Problemy z metodami wycen

Główny problem z metodami wycen przedstawionymi powyżej (poza Use Case Point – opisuję to poniżej) polega na tym, że nie biorą one pod uwagę kosztów komunikacji i nauki. Z mojego doświadczenia jest to jeden z głównych kosztów podczas realizacji.

Dobrym potwierdzeniem dla wielkości takiego kosztu jest prezentacja, jaką przeprowadził Sławomir Sobótka (link do minuty nagrania), który opowiedział historię i zadał pytanie do zgromadzonych na sali:

„Jeżeli piszemy kodzik przez 2 tygodnie powiedzmy i jakoś magicznie, nie wnikam dlaczego się nie scommitowaliśmy. To ten sam kodzik, jeśli ukradną wam laptopa w ile czasu napiszecie?”

Z sali padła odpowiedź: „w 2 dni”.

Na prezentacji główną przyczyną takiej różnicy jest proces uczenia. Z mojego doświadczenia uważam, że główna przyczyna to komunikacja z klientem, komunikacja w zespole i proces uczenia się.

Podczas analizy innych projektów powinniśmy zdawać sobie sprawę z tego, że rezultat projektów może być podobny ale koszt komunikacji i nauki jest zazwyczaj zupełnie inny.

Dla przykładu prezentuję Ci poniżej dwa projekty w czasie, których rezultaty były do siebie bardzo zbliżone, jednak koszty komunikacji i nauki wyglądały już zupełnie inaczej.

Zwróć uwagę, mimo tego, że rezultat projektu był bardzo zbliżony to ostatecznie Projekt 1 jest droższy od Projektu 2 o 143 tys. zł.

7. Wycena

Opisane poniżej punkty dotyczące wyceny powinny być realizowane z zespołem, który będzie wykonywał projekt. Nie musi być to pełen zespół, ale np. dwie doświadczone osoby z zespołu.

Co z tego, że opracujemy najlepszą wycenę, zgodną ze standardami i metodologiami, jeśli nie będziemy w stanie zrealizować projektu w tej wycenie 😮

Dlatego uważam, że wycena prowadzona z zespołem jest bardzo ważna nie tylko ze względu na dokładność wyceny, ale również ze względu na późniejszą realizację projektu.

Zespół, który brał udział w procesie wyceny jest zdecydowanie bardziej przekonany do jej wiarygodności. Odpowiedzialność zespołu za taką wycenę jest zdecydowanie większa, co przekłada się również na zachowanie terminowości.

7.1. Rozpisanie specyfikacji

Pierwszym krokiem jest rozpisanie wymagań specyfikacji na user stores zgodnie ze specyfiką Scrum. Podczas rozpisywania poszczególnych wymagań należy również grupować stworzone user stores w epiki.

Po wykonanym zadaniu powstanie product backlog zgodny z frameworkiem Scrum. Poza samą wyceną stworzony backlog ułatwi również uruchomienie projektu po ewentualnym podpisaniu umowy z Klientem.

7.2. Ustalenie priorytetów

Jeśli istnieje taka możliwość to warto przeprowadzić ten krok z Klientem. Jeśli Klient zaproponował etapy lub harmonogram to również można go wykorzystać w zakresie ustalania priorytetów.

W innym przypadku ustalenie priorytetów powinno odbywać się na podstawie doświadczenia zespołu.

7.3. Analiza historyczna

Przegląd wraz z zespołem podobnych projektów pod względem rezultatu, zrealizowanych iteracji, wielkości velocity i wykresów spalania.

Na podstawie tej analizy można określić najbardziej zbliżony projekt i na jego podstawie będzie można oszacować dalsze kroki.

7.4. Ustalenie wielkości velocity

Wspólnie z zespołem na podstawie danych historycznych określamy wielkość velocity dla szacowanej iteracji, która uwzględnia podstawowy zespół wymagany do realizacji projektu. Dodatkowym szacunkiem, który ustalamy to velocity osoby, która może ewentualnie powiększyć skład zespołu.

Wartość ta będzie potrzeba do obliczenia czasu realizacji projektu.

7.5. Estymowanie zadań

Estymowanie może odbywać się elektronicznie (np. w arkuszu Google gdzie każdy estymujący ma swoją kolumnę) lub też za pomocą Scrum pokera. Zgodnie z szacowaniem Scrum wszyscy członkowie zespołu powinni się zgodzić co do estymacji danego user stories.

Scrum poker jest ciekawym rozwiązaniem, ponieważ dodatkowo integruje zespół i zachęca do rozmów o poszczególnych zadaniach. Z mojego doświadczenia wynika, że elektroniczne estymacje powodują mniejsze zaangażowanie członków zespołu.

Szacowanie może odbywać się za pomocą punktów 1/2, 1, 2, 3, 4 lub za pomocą ciągu Fibonacciego (1, 2, 3, 5, 8, 13, 21). Osobiście bardzo polecam szacowanie za pomocą ciągu Fibonacciego, w mojej ocenie zdecydowanie lepiej oddaje realia pracy.

Odnośnie samego ciągu Fibonacciego polecam również ten film.

7.6. Doliczenie buforów i premii

Bufory

W zależności od specyfiki danego projektu możesz doliczyć bufory czasowe. Bufory stosuje się zazwyczaj przed zakończeniem jakiegoś określonego etapu w projekcie. Zgodnie z własnym doświadczeniem – na bufory doliczam dodatkowo do szacowanego czasu od 10% do 30%.

Premie

Premie dla pracowników są wypłacane za dotrzymanie ustalonych terminów w projekcie. Wpływają one pozytywnie na zaangażowanie i motywację pracowników. Pracownicy czują się w większym stopniu właścicielami projektu jaki prowadzą.

W projektach bardzo często pojawiają się kary dla Dostawcy za niedotrzymanie terminu. W projektach przetargowych mogą dotyczyć każdego dnia opóźnienia. W celu obniżenia tego ryzyka lepszym rozwiązaniem jest ustalenie premii dla pracowników. Pracownicy będą mieli świadomość, że jeśli się spóźnią to nie otrzymają premii a środki finansowe będą przekazane na pokrycie kar.

7.7. Wyliczenie czasu i kosztów realizacji

Na podstawie szacowanego velocity iteracji oraz estymacji zadań jestem w stanie obliczyć czas realizacji projektu.

Przykładowo:

Planowana iteracja trwa tydzień czasu, w ciągu iteracji trzyosobowy zespół jest w stanie zrealizować zadania o łącznej wartości 46 punktów. Łączna liczba zadań oszacowanych w projekcie to 318 punktów.

Dzieląc 318 przez 46 otrzymujemy liczbę tygodni jaka jest potrzeba do przeprowadzenia projektu. W tym przykładzie wynosi ona 6,91.

Do wyliczonej liczby tygodni dodajemy nasz bufor czasowy w wysokości 20% i otrzymujemy w zaokrągleniu wartość 8,3 tygodnia.

Następnie uzyskany wynik mnożę przez liczbę członków zespołu i ich wynagrodzenia w skali tygodnia.

Otrzymuję w ten sposób kwotę kosztów realizacji wraz z buforem czasowym.

7.8. Doliczenie lub odliczenie kosztów komunikacji i nauki

W tym kroku doliczam, odliczam lub pozostawiam bez zmian szacowaną wartość projektu biorąc pod uwagę czynniki zewnętrzne, koszty komunikacji i nauki.

Kwota obliczona w poprzednim kroku zawiera już w sobie koszty czynników zewnętrznych, komunikacji oraz nauki, dlatego zadaniem na tym kroku jest określenie jakie są różnice pomiędzy projektem analogicznym a aktualnie wycenianym.

W zależności od różnic doliczam, odliczam lub pozostawiam bez zmian szacowaną wartość projektu. Działanie to wykonuję poprzez ustanie wartości procentowej.

Wyżej napisałem „poza metodą Use Case Point”. Jest to podyktowane tym, że metoda ta zakłada szacowanie złożoności środowiska. Wykorzystuję punkty z tej metody aby ocenić złożoność środowiska.

Punkty oceny złożoności środowiska z metody Use Case Point:

• E1 – Znajomość przez zespół dziedziny problemu, technicznych aspektów i metodyki w jakiej jest realizowany projekt.
• E2 – Doświadczenie zespołu (szeroko pojęte).
• E3 – Doświadczenie zespołu w projektowaniu aplikacji obiektowych i znajomość standardów projektowania.
• E4 – Doświadczenie i umiejętności analityka.
• E5 – Motywacja zespołu.
• E6 – Stabilność wymagań tworzonego systemu.
• E7 – Pracownicy nieetatowi zaangażowani w projekcie.
• E8 – Trudność języka programowania.

Dodatkowo oceniam również punkty:

• Relacja z Klientem, możliwości negocjacji i egzekucji odbiorów.
• Struktura organizacyjna Klienta:
  Czy klient posiada rozbudowaną hierarchię, która ma wpływ na komunikację i odbiory w projekcie? Jest to ważny punkt w przypadku projektów realizowanych dla instytucji rządowych.
• Wiedza technologiczna Klienta:
  Czy klient po swojej stronie posiada kompetentną osobę w zakresie wytwarzania oprogramowania?
• Forma i jakość komunikacji z Klientem:
  Np. czy jest możliwa komunikacja za pomocą wideokonferencji. Wiem, że to standard, jednak są klienci, którzy nadal preferują klasyczne formy komunikacji (np. korespondencja listowna).

Przykładowo po sumarycznej analizie punktów wynik może wskazać, że w danym projekcie muszę zwiększyć wartość szacowanej wyceny o 30%.

7.9. Doliczenie innych kosztów i marży

Ostatnim z kroków jest doliczenie innych kosztów oraz marży. Inne koszty mogą wynikać z oceny ryzyka (np. projekt posiada wysoki poziom kar i krótkie terminy realizacji).

Do innych kosztów możemy również zaliczyć koszty pośrednie, takie jak: wynajmy, dojazdy, delegacje, koszty zarządu, księgowości i obsługi prawnej, itp.

Ostatnim punktem jest marża, która może być jednoznacznie ustalona przez firmę (np. 30-70% wartości szacowanego projektu) lub może być wyliczana indywidualnie dla projektu. W przypadku indywidualnego wyliczenia marży pomocne jest również przeprowadzenie wyceny podejściem top-down, którą opisałem powyżej.

8. Wycena a realizacja

Naturalne jest to, że wycena będzie odbiegać od realizacji i twarde trzymanie się jej może być szkodliwe dla rezultatów projektu.

Warto jednak posiadać wycenę, która jest spójna z frameworkiem Scrum, ponieważ podczas prowadzenia retrospektywy w zespole będziesz mógł wspólnie przeanalizować, jakie elementy wpłynęły na różnicę pomiędzy wyceną a realizacją.

Na podstawie realizacji można co pewien okres aktualizować dane szacunkowe (wprowadzać rzeczywistą wielkość velocity oraz wartość punktową poszczególnych zadań). W ten sposób będziesz mógł uzyskiwać coraz dokładniejszy plan oparty na rzeczywistym działaniu.

9. Podsumowanie

Opisana przeze mnie metoda nie jest najtańszą i najszybszą metodą wyceny, jednak bardzo dobrze się sprawdza. Z uwagi na koszy jej przeprowadzenia jest dedykowana dla projektów powyżej 100 tys. zł. Poniżej takiej wartości projektu koszt angażowania całego zespołu do wyceny może być zbyt wysoki.

Projekt w dolnym przedziale powinien zająć ok. 8 godzin wyceny w zespole. Biorąc pod uwagę 3 osobowy zespół (PM + dwie doświadczonych developerów) to otrzymujemy koszt wyceny na poziomie od 2 do 3 tys. zł.

W przypadku mniejszych projektów optymalnym rozwiązaniem jest indywidualna wycena eksperta. Jeśli dany ekspert będący na stanowisku Analityka lub PMa brał udział w wielu wycenach zespołowych będzie w stanie coraz lepiej oceniać koszty realizacji projektu.

Jeśli prowadziłeś już wycenę projektu IT podziel się proszę w komentarzu Twoimi doświadczeniami.

Zapraszam Cię również do subskrypcji bloga.