#NoEstimate – wyceniać czy nie wyceniać?

Chciałem jedynie odnieść się do koncepcji #NoEstimates, ale wyszedł mi głęboki artykuł poruszający sedno konfliktu wyceniania.

Możesz potraktować ten artykuł jako pewnego rodzaju mój manifest na temat wycen.

Wpis jest obszerny, dlatego polecam ci przed czytaniem zaparzyć sobie kawę – miłej lektury!

O co chodzi w #NoEstimates?

Jest to „ruch”, którego koncepcja opiera się o to, że nie warto wyceniać czasu jaki jest nam potrzebny do wykonania zadania bo…

• tak, czy siak mylimy się w wycenach bo trudno je zrobić dokładnie;
• przygotowanie wycen zajmuje dużo czasu (a i tak bywają niedokładne).

To tak w skrócie. Pewnie powodów można wymienić więcej, ale te są najistotniejsze.

---

Czy wycena wpływa na termin wykonania?

Według mnie nie. To czy wycenimy zadanie (i nie dotrzymamy terminu) czy nie wycenimy go wcale to i tak musimy wykonać taką samą robotę. Tyle, że bez deklaracji w postaci wyceny.

Oczywiście można tutaj powiedzieć, że zadania wycenione wywołują presję i większą mobilizację, ale to według mnie ma takie same znaczenie jak to czy mamy dziś dobry dzień czy gorszy.

Czasami jesteśmy bardziej produktywni, czasami jesteśmy przeziębieni przez co mniej wydajni.

Tak samo jest z wyceną (deklaracją programisty) – jedni będą czuli presję i będą zmobilizowani, na innych to nie wpływa. Inni zostaną przytłoczeni i ich to spowolni.

Ja osobiście samego faktu, że programista wyceni zadanie nie rozpatruję jako czynnik, który miałby przyśpieszyć lub spowolnić wykonanie zadania.

Pewnie ma to wpływ, ale na tyle nieprzewidywalny i unikalny dla każdego pracownika i organizacji, że na dzień dzisiejszy jest to „nie do ogarnięcia” na mój łeb, więc to świadomie ignoruję 🙂

---

Skoro wycena nie ma znaczenia, to po co wyceniać?

Powyższe pytanie jest tendencyjne i źle zadane, ale właśnie w takiej formie zazwyczaj słyszę je od programistów.

Z punktu widzenia programisty wycena nie ma znaczenia i nie warto wyceniać. Koniec i kropka.

Programista ma wykonać zadanie, napisać jakiś feature. Czy go wyceni… czy nie, to ten feature i tak musi być zrobiony, więc z punktu widzenia programisty – różnicy nie ma. Jest jedynie jedna niedogodność – „zamiast” pracować, musi poświęcić czas na wycenę. W przypadku niektórych typów osobowości jest to dodatkowy stres, bo coś trzeba zadeklarować 🙂

Wcześniej wspomniałem, że pytanie: „skoro wycena nie ma znaczenia, to po co wyceniać?” – jest źle sformułowane.

Pytanie jest błędnie zadane, bo wszystko zależy gdzie się siedzi – dla programisty jest bez znaczenia, ale dla biznesu ma ogromne znaczenie. Więc tylko oczami programisty „wycena nie ma znaczenia, ale tak czy siak trzeba ją zrobić”.

Wielokrotnie powtarzałem, że…

… IT jest dla biznesu, a nie biznes dla IT

Większość komercyjnych projektów toczy się dlatego, że potrzebują wsparcia IT. Gdyby to wsparcie nie było potrzebne to… wyceny również nie byłyby potrzebne, bo programiści nie mieliby pracy.

Firmy nie zatrudniają programistów po to, żeby dać im zajęcie, tylko po to, żeby przy ich pomocy zrealizować cele klientów. Według mnie dobro klienta powinno być priorytetem – oczywiście nie naginając komfortu pracy programistów, bo gdy przestaniemy szanować i respektować potrzeby programistów, to nie uda nam się spełnić oczekiwań klientów.

Temat rzeka – jeśli ktoś się uprze, to powyższe może źle zinterpretować. Oczywiście nie chodzi o to, że powinno się osiągać rezultaty sprzedażowe kosztem ludzi – zdecydowanie neguję takie podejście.

Podstawową sprawą jest to, że wyceny nie są dla programistów tylko dla biznesu. Kwestionowanie przez programistę tego czy wycenianie ma sens jest tożsame z tym, jakby programista kwestionował zasadność feature, który tworzy.

Nie jest ważne co programista uważa o zasadności projektu, może uważać, że projekt, który realizuje jest bez sensu i nieprzydatny. Ma prawo do opinii, ale on nie robi go dla siebie, tylko dla klienta.

Analogicznie jest z wycenianiem. Programista może twierdzić, że wycena jest bez znaczenia, bo nie jest mu potrzebna.

Głównym powodem zatrudnienia programisty jest dowiezienie rezultatów sprzedażowych (nie samo programowanie dla programowania). Można się na wyceny obrażać, można być niechętnym… ale często trzeba je robić, bo są potrzebne klientowi.

---

---

Dlaczego biznes potrzebuje wycen?

Przechodzimy do sedna. Ja nie jestem zaskoczony tym, że programiści nie rozumieją zasadności wyceniania. Tutaj nie chodzi mi konkretnie o programistów, a bardziej o sposób myślenia „pracownika etatowego”.

Do zrozumienia potrzeby posiadania wycen, trzeba wyjść z perspektywy myślenia pracownika etatowego – co jest bardzo trudne.

Powiem teraz swoją subiektywną opinię na temat prowadzenia biznesu – Ty być może masz inną, ale według mnie nie jest możliwe prowadzenie biznesu odpowiedzialnie bez planowania, harmonogramowania i starań by przewidzieć przyszłość.

Ja inaczej nie potrafię. Staram się dostrzegać ryzyka zanim wystąpią, żeby przygotować plan A, B i C. Taki sposób myślenia powoduje u mnie to, że rozumiem zasadność wycen przez programistów.

Wyceny są biznesowi potrzebne właśnie do planowania. Bez wyceny nie jesteśmy w stanie oszacować kosztów danego projektu/zadania.

W myśleniu „etatowym” ciężko złapać tę zależność, ale jeśli ktoś wyceni zadanie na 80 rbh to generalizując i upraszczając koszt tego feature to połowa pensji programisty. Analogicznie (choć nie wprost) biznes przelicza wyceny godzinne na pieniądze.

Więc biznes chce mieć możliwość podjęcia decyzji czy projekt/feature jest warty realizacji. Być może jest, a być może nie, ale bez wyceny się tego nie dowiemy. Tutaj podałem przykład pojedynczego zadania.

Biznes prosi o wyceny programistów bo są najodpowiedniejszymi osobami do jej wykonania. Kto miałby wycenić, jeśli nie oni? Osoby prowadzące biznes nie muszą być techniczne, zatrudniają specjalistów technicznych (programistów), którzy posiadają dużo większe umiejętności techniczne, niż właściciele firm. Dlatego zasadne jest, że to programista wycenia daną funkcjonalność, bo dlaczego miałby to robić ktoś inny?

W przypadku nowych projektów sprawa jest jeszcze bardziej złożona. Prawdopodobnie żaden z klientów nie przełknąłby oferty na relizację projektu w stylu:

Panie kochany, nie przesyłam wyceny pracochłonności bo tak czy siak zrobimy wszystko co opisałeś. Robota czy z wyceną czy bez będzie przecież taka sama.

Powyższa odpowiedź to mój jaskrawy żart, żeby lepiej zobrazować co mam na myśli. To by po prostu nie przeszło. Nawet jeśli sens tej wypowiedzi ubralibyśmy w rozsądne, sprzedażowe słowa.

---

Możesz to sobie odnieść do tego jak robisz zakupy. Idąc kupić telewizor i mając w kieszeni 1500 zł (budżet na projekt) nastawiasz się, że kupisz sprzęt, który kosztuje poniżej 1500 zł. Trochę kiepsko gdyby przy kasie okazało się, że chcesz kupić telewizor za 2000 zł (cena projektu) mając jedynie 1500 zł. Dlatego przed zakupem telewizora patrzysz na cenę telewizora (wycena projektu), żeby sprawdzić, czy cię na niego stać.

---

Ja osobiście prowadząc Fresh Apps, najbardziej rentowne projekty pozyskałem (w dużej mierze) właśnie dzięki wycenom.

Zazwyczaj projekty dla korporacji, różnego rodzaju przetargi nie obejdą się bez wyceny. Klient potrzebuje zabudżetować projekt (bo tak działa jego organizacja). My możemy się z tym zgadzać lub nie, ale mamy niewielki wpływ na zmianę tego. Szczególnie jeśli klient jest „większym graczem”.

Należy zrozumieć, że „to wszystko” jest tylko małym elementem większej układanki:

Klient (chce wyceny) -> Firma 1 (potrzebuje wyceny) -> Firma 2 (potrzebuje wyceny) -> Programista (twierdzi, że wycena nie ma znaczenia).

Tutaj zdarzają się różne konfiguracje łańcuszków. Czasami robi się projekty bezpośrednio dla klienta, czasami jest się którymś podwykonawcą, ale to nie ma znaczenia. Znaczenie ma to, czy „sponsor” – czyli klient – chce znać koszt projektu. Klient chce wiedzieć czy go na niego stać i czy projekt będzie rentowny.

---

---

Po co biznesowi niedokładne wyceny?

Ustaliliśmy, że wycenianie jest pracochłonne i trudne. Często wyceniamy i nie dotrzymujemy estymat. Można zadać (zasadne) pytanie: po co wyceniać, lepiej zróbmy generator liczb losowych do wycen zadań 🙂

Makro management to w moim zrozumieniu zarządzanie firmą, portfelem projektów, a micro management to zarządzanie poszczególnym projektem i jego zadaniami – to duże uproszczenie na potrzeby tego artykułu.

Często w makro zarządzaniu chodzi o koszt wielkości wyceny. Jeśli zespół programistów wycenił projekt na 1000 RBH, to w większości przypadków nie ma znaczenia czy wyrobią się w 800 RBH czy zajmie to 1200 RBH.
(Nie ma znaczenia w kontekście makro zarządzania).

Biznes zakłada pewne ryzyko i bufory i w ofercie prosi o budżet na 2000 RBH (przykład, żeby zobrazować co mam na myśli).

Wycena nie ma znaczenia do tego momentu, dopóki nie wykraczamy poza zaplanowane „widełki”.

FYI: byłem wielokrotnie świadkiem sytuacji gdzie oferty były przygotowywane na zasadzie „dopiszmy trzy zera i będzie OK”. W takim przypadku niedotrzymanie wycen o +20% (względem szacunków programistów) nie powoduje ryzyka dla budżetu, a jedynie dla harmonogramu.

Wyceny w makro zarządzaniu są biznesowi głównie potrzebne do oszacowania rzędu wielkości kosztów i rozpatrzeniu na to ryzyka (w postaci na przykład dodania buforu wyceny).

Moim zdaniem więc w sytuacji gdy nie ma dużo czasu na zrobienie wyceny, zakres dla programisty ma dużo niewiadomych to jak najbardziej w porządku są wyceny na zasadzie: pesymistyczna, realistyczna i optymistyczna.

Gdzie optymistyczna to wariant gdzie wszystko idzie jak zaplanowaliśmy, pesymistyczna to wariant w którym nic nie idzie jak zaplanowaliśmy, a realistyczna to scenariusz oczekiwany na bazie naszych doświadczeń.

To jest bardzo cenna wskazówka dla makro zarządzania bo można podjąć ryzyko, którą z „wycen” weźmiemy pod uwagę. Czy bliżej optymistycznej czy pesymistycznej? – tu decyduje biznes, nie programista.

To po części zdejmuje z programisty „odpowiedzialność” – zrobił co mógł. Dał najbardziej precyzyjną odpowiedź, jaką był w stanie dać. Pomimo tego, że wciąż nie wiadomo ile czasu zajmie realizacja.

Ale to jest OK – bo to biznes powinien wziąć ryzyko za tę sytuację. Wyceny są biznesowi potrzebne do tego, żeby móc oszacować ryzyko i świadomie do niego podejść.

---

Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯

---

Skąd konflikty na temat wycen?

Konflikt jest objawem. Powodem konfliktu są:

• ze strony programistów brak zrozumienia do czego biznes wykorzystuje wyceny,
• ze strony biznesu brak zrozumienia, że wyceny programistów to nie cyrograf tylko szacunek/przewidywania (myślenie życzeniowe).

Tu chcę zaznaczyć, że dużo winy całego „konfliktu” leży też po stronie biznesu. Głównie w micro managemencie.

Makro management to w moim rozumieniu zarządzanie firmą, portfelem projektów, a micro management to zarządzanie poszczególnym projektem i jego zadaniami. – to duże uproszczenie na potrzeby tego artykułu.

Często (niestety) zdarza się, że kierownicy projektu nie rozumieją tematu wyceny – podobnie jak programiści.

Tacy kierownicy projektów traktują wyceny programistów jako deklaracje 100% pewne. Kiedy tylko programiście podwinie się noga to pytają – a dlaczego to się opóźniło, przecież mówiłeś, że to zajmie dwa dni?

Pytanie wkurzające dla każdego programisty, bo trzeba się tłumaczyć. Jest to poniekąd nieformalna kara dla programisty. Opisywałem już jak kary wpływają na wyceny wiec zachęcam do przeczytania. Nie chce się powtarzać.

Takie podejście ze strony kierowników projektów, którzy błędnie zakładają pewność na niepewność wycen rodzi szereg konfliktów, bo oczekiwania są nierealne względem możliwości programistów.

Podejrzewam, że dużą rolę całego „konfliktu” o wyceny powodują osoby zarządzające projektami tzw. micro management, którzy nie widzą szerszego obrazka. Ich nastawienie i reakcja przekłada się w dół na programistów, którzy niechętnie podchodzą do wycen i stresują się nimi.

Kierownicy projektu często nie potrafią zarządzić ryzykiem związanym z wyceną więc obarczają tym programistów. Szalone rzeczy, ale często spotykane.

---

Pssst… mam dla Ciebie prezent 🙂

Prześlij mi więcej wskazówek o wycenach projektów IT

---

Wycena to nie termin ukończenia!

Kolejna rzecz, której nie rozumie spora liczba kierowników projektów. Powoduje to szereg konfliktów.

Wycena – czyli oszacowana pracochłonność zadania mówi o objętości prac, a nie o terminie wykonania.

Oczywiście często jest to zbieżne (jeśli założymy pewność na wycenę). W momencie gdy pracujemy nad zadaniem nieprzerwanie i ciągiem.

Często się jednak zdarza, że priorytety zadań się zmieniają, dochodzą nowe tematy, które trzeba obsłużyć i programiści manewrują między nimi.

Więc przykładowo, zadanie wycenione na 10 rbh, jeśli będzie robione po 2 rbh dziennie zajmie w teorii 5 dni. Zamiast jednego dnia z kawałkiem.

Bo 10 rbh to jedynie objętość prac. Możemy je wykonać jednego dnia, lub rozłożyć na tydzień.

Tutaj dochodzi temat wielozadaniowości i zmiany kontekstu. W pracy takim trybem nad zadaniem podejrzewam, że czas realizacji będzie bliższy 15 rbh lub nawet 20 rbh (mimo, że planowaliśmy 10 rbh).

Nie chcę się tu rozwodzić na temat produktywności. Chcę tylko zwrócić uwagę, że wielu kierowników projektów błędnie traktuje wycenę jako termin ukończenia, nie uwzględniając trybu pracy nad zadaniem.

To powoduje konflikty i konieczność tłumaczenia się. Programista żeby to wytłumaczyć musi podać listę zadań, które wykonywał i czuje kompletny brak zaufania ze strony kierownika projektu (co nie musi być prawdą).

Takie sytuacje jedynie zaogniają konflikt i zniechęcają programistów do wyceniania zadań.

---

Skończyłem zadanie wcześniej i nie pochwalili 🙁

Skończenie zadania wcześniej to „pomyłka” w wycenie. Słowo pomyłka jest w cudzysłowie. W większości przypadków działa to na korzyść projektu – z dwojga złego lepiej skończyć wcześniej niż później.

Czy fakt, że skończyliśmy wcześniej jest godny pochwały? Według mnie nie.

Tak samo jak uważam, że karanie za przekroczenie wycen szkodzi, tak samo pochwalenie za skończenie zadania przed czasem nie pomaga.

Jeśli chcesz być pochwalony za to, że skończyłeś zadanie przed czasem to mam dla ciebie wskazówkę: Pomnóż swoją wycenę x 10 i oddaj jak najszybciej zadanie bez względu na jakość.

Powyższa wskazówka jest jaskrawa, ale mam nadzieję, że nakreśli Ci do czego prowadzi chwalenie za skończenie wcześniej (przed wyceną).

Jest takie powiedzenie: „Powiedz mi po czym cię oceniają, a powiem ci jak będziesz się zachowywał”.

Ludzie są z natury dobrzy i chcą pracować tak jak od nich tego oczekujesz. Jeśli więc powiesz im, że chodzi tylko o skończenie przed czasem bez względu na jakość to masz gotowy dług technologiczny do odebrania. Enjoy.

Jestem wielkim zwolennikiem chwalenia – uważam, że powinniśmy chwalić ludzi za profesjonalną i rzetelną pracę. Nawet jeśli zadanie opóźniło się o 20%, ale jest wykonane zgodnie ze sztuką to według mnie pochwała jest jak najbardziej zasadna. Oczywiście, taka osoba powinna popracować nad „sztuką wyceniania”, ale samo niedotrzymanie wyceny nie przekreśla pochwały.

Powinniśmy nagradzać postawę, a nie samo zmieszczenie się w wycenie lub jej przekroczenie.

Poza tym, musimy pamiętać, że w zdecydowanej większości programista jest zatrudniony na pensję ryczałtową, więc płacimy poniekąd za poświęcony czas.

Nie rozumiem więc oburzenia ludzi, którzy nie chcą kończyć zadań wcześniej „bo dostaną kolejne”. No właśnie na tym polega ta praca

Chcę być zrozumiany jasno: nie jestem zwolennikiem „tyrania” jak dziki osioł, bez ustanku rozwiązując zadania z podkrążonymi oczami.

Ale nie rozumiem też postawy oczekującej pochwały, że ktoś wykonał zadanie w terminie i w związku z tym chce czas rezerwy spożytkować na fejsie.

---

Czy Time&Materials jest lekarstwem?

W rozliczeniu T&M chodzi o to, że klient płaci za przepracowany czas nad zadaniami, a nie za ich efekt. Jaskrawo rzecz ujmując, klient płaci za próbę rozwiązania problemów programistycznych, a nie za finalny rezultat ich rozwiązania.

Nawet jeśli zadanie jest nieukończone, to należy rozliczyć czas spędzony nad zadaniem. Tak jaskrawo można zdefiniować T&M.

Na pierwszy rzut oka mogłoby to się wydawać lekarstwem na cały konflikt spowodowany wycenami. Jednak uważam, że nie do końca tak jest. Polecam przeczytać ci wpis rozliczenie godzinowe czy projektowe – co się bardziej opłaca?

Bo pomimo tego, że nie jesteśmy rozliczani za efekt zadania to w żaden sposób nie zmienia to finalnego modelu biznesowego klienta, który potrzebuje wiedzieć czy stać go na projekt, czy nie.

Sposób rozliczania T&M znaczy tyle, że ten kto płaci (klient) ufa wykonawcy, że ten zrobi to optymalnymi metodami.

T&M przestaje być korzystne jeśli wykonawca jest niekompetentny i klient płaci za naukę fachu. Natomiast T&M jest korzystne jeśli wykonawca jest profesjonalny i kompetentny.

Zaufanie i pewność co do wykonawcy to jedno, ale to czy nas stać na dany projekt/feature to drugie.

Dla mnie osobiście T&M nie znaczy bez estymat. T&M znaczy z estymatami, za które biznes bierze całkowite ryzyko i akceptuje je poniekąd z góry.

Pracowałem w wielu projektach w modelu T&M i prawie zawsze dokonywaliśmy wycen, bo bez względu na zaufanie do wykonawcy klient chce wiedzieć czy stać go na dany feature/projekt.

W razie poślizgu klient bierze „na klatę” odpowiedzialność za pomyłkę, ale wyceny i wstępny kosztorys jest mu potrzebny żeby oszacować czy go stać na dany ruch.

Podejrzewam, że większość klientów chce mieć zasygnalizowane czy zlecone zadanie to godzina, dzień, miesiąc czy rok pracy. Potrzebne jest im to, żeby nie być zaskoczonym jak będzie wystawiona faktura.

W T&M pomiędzy klientem a firmą jest analogiczna relacja, jak w firmie pomiędzy pracownikiem a zarządem. Ufają sobie na tyle, że biorą odpowiedzialność za ewentualnie poślizgi terminowe.

Uważam więc, że T&M nie jest „lekarstwem” na wyceny. Nie zmienia to w żaden sposób tego, że ten kto płaci chce mieć szanse przygotować się na koszta.

---

Karol, jak żyć w takim razie?

Proponuję zaakceptować rzeczywistość wycen. Możesz się na to obrażać, możesz się z tym nie zgadzać ale większość firm wymaga wycen bo jest to potrzebne do makro zarządzania.

Im cały łańcuch jest bardziej świadomy: klient -> szefostwo -> kierownicy tym programiści mają „lżej”. Bo mają zrozumienie i fair traktowanie w kontekście wycen.

Jako programista możesz zrobić niewiele. Prawdopodobnie możesz zmienić pracę na firmę, która rozumie mechanizm wyceniania (lub nie wymaga estymat w ogóle).

Jako przedsiębiorca możesz zawsze zmienić klienta, który ma inne podejście do wycen. Osobiście uważam, że nie jest to takie łatwe.

Brak nacisku na wyceny będzie wtedy, gdy klient nam jako wykonawcom zaufa. Do tego często potrzebna jest relacja, której zbudowanie wymaga czasu. Dlatego uważam, że zmiana klienta nie będzie ani prosta, ani szybka.

Poza tym trudno sprawdzić jakie jest stanowisko klienta w sprawie wycen zanim zaczniemy pracować, bo deklaracje przed współpracą to jedno, a sprawdzenie się „w boju” to drugie.

Uważam, że klient, który rozumie mechanizm wycen to skarb i niełatwo takiego znaleźć. Jeszcze trudniej edukować klientów. Jest to możliwe ale uważam, że bardzo pracochłonne by zmienić czyjąś koncepcję na biznes i światopogląd.

Tym wpisem zrobiłem sobie idealne środowisko do product placement, aż samo ciśnie mi się na usta żeby powiedzieć o moim kursie Dokładna Wycena Projektów IT.

Właśnie z powodów opisanych w tym artykule:

• niezrozumienie potrzeby wycen przez programistów
• niezrozumienie mechanizmu wycen przez kierowników projektów
• nieumiejętne branie ryzyka przez CEO/CTO z wycen

stworzyłem kurs o tym, jak te problemy rozwiązywać. Więc kontynuując pytanie – jak żyć?

Proponuję zaakceptować stan rzeczy związany z wycenami, ale podejść do tego z odpowiednim nastawieniem. Możesz edukować się w temacie wycen, żeby być w tym lepszy. Jestem przekonany, że każdy pracodawca to doceni, bo potrzeba wyceniania nie zniknie. Zawsze lepiej mieć programistę, który potrafi wyceniać, niż tego, który nie potrafi.

---

Podsumowanie

Wycenianie powoduje konflikty bo brakuje zrozumienia tego mechanizmu.

Programiści nie chcą wyceniać bo z ich punktu widzenia taka deklaracja niczego nie zmieni – tak czy siak muszą zrobić robotę.

Kierownicy nie rozumieją, że wyceny programistów są często myśleniem życzeniowym, które błędnie traktują jako obietnicę podpisaną krwią.

Uważam, że potrzeba wyceniania i szacowania się prędko nie zmieni. Bo to IT jest dla biznesu, a nie biznes dla IT. To końcowy klient potrzebuje wyceny, a firmy się będą dostosowywały.

Niestety mało klientów jest świadomych na tyle, by całkowicie odrzucić wyceny. Zwłaszcza, że zazwyczaj płatnikiem jest firma NIETECHNOLOGICZNA, która oczekuje od nas technologicznych rozwiązań. Powtórzę: twierdzę, że to IT jest dla biznesu, a nie biznes dla IT.

Czy da się pracować bez estymat? Oczywiście, że się da. Najlepszym tego przykładem jest Andrzej Krzywda z Arkency. Polecam ci rzucić okiem na jego instagram, gdzie mówi o #NoEstimates. Porusza też wiele innych tematów – dużo wartościowej wiedzy, naprawdę warto zajrzeć.

Czy ruch #NoEstimates jest słuszny? Uważam, że nie jest ani słuszny, ani niesłuszny. Gdybym miał możliwość zrezygnowania z wycen w swoim biznesie (carpe diem) to bym to zrobił, ale nie mam takiej możliwości. Podobnie jak ja – setki firm też nie ma tej możliwości 🙁

Staram się więc odnaleźć w rzeczywistości z wycenami nie rozsądzając czy wyceny są potrzebne czy nie, bo to według mnie to źle zadane pytanie. Punkt widzenia zależy od miejsca siedzenia.

Skoro już udało mi się utrzymać twoją uwagę na tak długo mam gorącą prośbę – udostępnij ten wpis na swoich mediach społecznościowych. Nie zdajesz sobie sprawy jak takie rzeczy motywują mnie do dalszego pisania 🙂

Jako ciąg dalszy moich rozmyśleń o wycenach polecam ci przeczytać wpis cała prawda o wycenach projektów IT – dlaczego jest, jak jest? w którym wchodzę w temat dlaczego wyceny, które wykonujemy, są niedokładne.

Jeśli podobnie jak ja chcesz odnaleźć się w rzeczywistości wycen, to rzuć okiem na mój kurs WycenaProjektów.pl 😉 (blink, blink).

Dzięki za uwagę!

---

Dziękuję, że przeczytałeś ❤️

Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍

Pobierz prezenty >>