Pine Script Wskaźnik TradingView

Na etapie wyboru wykonawcy kilku kandydatom zaproponowałem wykonanie zadania testowego, z którym ten wykonawca poradził sobie bardzo szybko. Możliwe, że rozwiązanie zostało opracowane nie bez pomocy ChatGPT, aby wyprzedzić konkurencję i wziąć zadanie dla siebie.

Wykonawca ocenił czas realizacji zadania na 7-10 dni. Tutaj "uścisnęliśmy sobie ręce". W dziesiątym dniu wykonawca kontaktuje się ze mną i prosi o udział w procesie, ponieważ trzeba sprawdzić logikę podstawowej funkcji wyświetlania tej strefy na wykresie, od której zależy w ogóle wszystko inne, co jest w TZ.
1. Spóźnili się z oddaniem,
2. nie powiedzieli, że są problemy, i
3. nie ostrzegli o opóźnieniu.

Następnie. Bardzo ważne jest podkreślenie, że wykonawca jest zbyt pewny swoich sił w Pine Script na platformie tradingview i tworzy wrażenie, że łatwo poradzi sobie z każdym zadaniem. To nieprawda. W miarę lepszego poznawania się stało się jasne, że komunikacja odbywa się z doświadczonym menedżerem projektów, ale w żadnym wypadku z programistą. Do programisty informacje docierają, wyobrażam sobie, jakby w hieroglifach, które z kolei programista musi zdeszyfrować. Przekaz dociera już jako inne zadanie. Powód tkwi w złej komunikacji między działami, braku doświadczenia specjalisty lub całego zespołu.

Jeśli chodzi o wskaźnik UI, to programista nie miał mojego zadania na biurku i dlatego zaczął tu i tam wynajdować koło na nowo. Niejednokrotnie podkreślano ważność zmiany języka interfejsu, aby był intuicyjny i logicznie zorganizowany. W efekcie otrzymuję do testów nieprzetłumaczony wskaźnik z nazwami funkcji, od których robi się źle. Oto jedna z nich „triger wewnątrz baru (inaczej po zamknięciu)”.

Programista nie ma wizualnego przedstawienia podstawowego narzędzia tradingview "Korekta według Fibonacciego". Nie widział go na oczy. Mimo że istnieje TZ, nawet po osobistych prośbach o zrobienie pól i checkboxów tak, jak potrzebuję, wciąż kilka razy otrzymywałem "wynik" z nieprzetłumaczonym interfejsem i JEDNYM polem wejściowym bez zmian (z poprawkami niepotrzebnego interfejsu). Programista postanowił, że trzeba wprowadzać wartości w jedno pole przez przecinek.

W dwudziestym pierwszym dniu podjęto decyzję o wstrzymaniu rozwoju wskaźnika.

Złożyliśmy wniosek na ten projekt i od razu otrzymaliśmy zadanie testowe, które pomyślnie wykonaliśmy, ale nie bez pewnych podejrzeń, ponieważ zleceniodawca chciał "upewnić się, że możemy zrealizować jego projekt. Po wykonaniu i otrzymaniu specyfikacji technicznej, "uścisnęliśmy sobie ręce". Drugiego dnia zaczęły się propozycje typu "zróbcie tak", możliwe również "będzie potrzebne to i to", przy tym zleceniodawca sam odrzucił swoją specyfikację, powołując się na to, że rzekomo została sporządzona przez sieć neuronową. To znaczy, w pierwszej wersji wskaźnika, który został wysłany, odpowiadał on w 80% wszystkiemu z specyfikacji technicznej, ale zleceniodawca potrzebował dodatkowych poprawek dotyczących zupełnie nowych funkcji i designu, który nie był opisany w specyfikacji technicznej na początku, ponieważ specyfikacja (jeszcze raz) - została sporządzona przez sieć neuronową, nie została odpowiednio sprawdzona pod kątem kompletności.

Dodatkowo poza specyfikacją zaproponowano więcej niż połowę objętości samej specyfikacji, takie ustawienia jak alerty typu, fibo (ustawienia wizualne, strefy, osobno dla każdego poziomu) oraz interfejs, który nie był opisany, zauważyliśmy również sformułowania "dzisiaj robimy tak" i "jutro robimy po nowemu" od zleceniodawcy. W ten sposób projekt naturalnie się wydłużył z powodu ciągłej chęci poprawy interfejsu, chociaż wykraczało to poza ramy zadania i nie odpowiadało pierwotnym celom.

Zleceniodawca przedłużał projekt dwa razy, ponieważ dodatkowe poprawki, na które zgodziliśmy się, wymagały czasu, ale ostatecznie po otrzymaniu działającego wskaźnika z większą częścią (oprócz interfejsu) zrealizowanej funkcjonalności - postanowił zakończyć.