Dostawca "oszukuje", ale nie chcę ujawniać, jak dowiedziałem się o

To, co powinieneś zrobić, to niezależnie zweryfikować to, co powiedział ci ten młodszy deweloper. Po pierwsze, nie wiesz, że to, co powiedział, jest dokładne. Mogło gdzieś dojść do nieporozumienia, może nie ma całego obrazu z technicznego punktu widzenia i przekazuje niekompletne dane, itp. Jak to mówią, “Zaufaj, ale sprawdź._”

Z innego powodu, weryfikacja tego, co ci powiedziano, chroni twoje źródło. Nikt nie musi wiedzieć, że coś ci powiedział, bo możesz zatrzymać dane jako dowód na to, co się stało, i całkowicie pominąć fakt, że ktoś cię o tym poinformował. Nie podałeś wystarczająco dużo szczegółów technicznych, by doradzić, w jaki sposób możesz to zweryfikować, ale nie brzmi to tak, jakby przyzwoity sysadmin czy inżynier systemowy w ogóle był w stanie to zrobić.

Oczywiście, zawsze istnieje możliwość po prostu stwierdzić, co powiedziało ci źródło i powiedzieć, że aby zapobiec odwetowi, wolałbyś nie podawać/nie podawać/nie podawać swojego źródła. Ale zweryfikowanie siebie, tak aby nawet posiadanie źródła nie miało znaczenia, jest lepszym podejściem.

Chociaż twoja troska o młodszego programistę w tym przypadku jest godna podziwu, pamiętaj, że jest to sytuacja, w której twoim prawnym obowiązkiem jest wobec twojego klienta. To powiedziawszy …

Mój klient nie złożyłby pozwu, ale z pewnością wyrzuciłby tego dostawcę. Jesteśmy jednym z ich najważniejszych klientów.

Skoro Twój klient zrzuciłby dostawcę i skoro dostawca jest nieuczciwy, dlaczego miałbyś zrobić cokolwiek innego, niż polecić zrzucenie dostawcy?

Prawdopodobnie nie musisz ujawniać swojego źródła. W rzeczywistości, można po prostu powiedzieć swojemu klientowi, że skoro wydajność dostawcy nie spełnia tego, za co płaci, to czas odejść. Jeśli naciskasz, możesz powiedzieć, że skoro usługodawca wiedział o testach z góry, że podejrzewasz, iż przeznaczył dodatkowe środki na test, którego normalnie nie zapewniają.

Jeśli really chcesz chronić młodszego programistę i mieć slot, który mógłby wypełnić, możesz go zatrudnić sam, lub Twój klient mógłby go zatrudnić. W ten sposób na pewno uniknie on zwolnienia przez usługodawcę. Ponadto, w przypadku, gdy dostawca usług próbuje pozwać Twojego klienta za naruszenie umowy, na pewno będziesz miał go w pobliżu jako świadka.

Trochę do tego

Z tego co wiesz dostawca dodał serwery do farmy podczas testów. Jeśli Twój klient zapłacił ogromną sumę za benchmark, powinieneś mieć nadzieję, że firma wynajęta do przeprowadzenia benchmarku to odbierze.

Czy benchmark jest płaski i przekracza teoretyczną wydajność farmy? Czy możesz pokazać, że wyniki są po prostu nierealistyczne?

Czy możesz jakoś uruchomić kilka niezależnych benchmarków, które wprowadzają doctored benchmark w wątpliwość?

Czy dostawca nie ma jakieś monitorowanie w czasie rzeczywistym podstawowych wskaźników wydajności, takich jak CPU, IO, przepustowość …? Powinieneś był uruchomić niektóre z nich podczas ujawniania benchmarku. Wiem, hindsight jest 20/20 ale nadal.

Nie szukasz problemu. Znasz problem, a teraz musisz go tylko udowodnić. Twoje źródło zrobiło ci świetną przysługę, ujawniając problem. Możesz udowodnić problem bez ujawniania źródła?

Może po prostu iść z:

Te benchmarki są po prostu nie pasują do wydajności aplikacji. Albo aplikacja powoduje większe obciążenie niż się spodziewam, serwery nie powodują takiego obciążenia, albo po prostu czegoś mi brakuje. Tutaj są pozycje do zbadania… Na liście elementów do zbadania znajduje się benchmark niespodzianek.

Outing the person that provided the information is a tough one. Prawdopodobnie zostałby zwolniony. I najprawdopodobniej zostałby zwolniony w bardzo zły sposób w tak trudnym do znalezienia innym miejscu pracy. Trudno byłoby mi znaleźć sposób na ujawnienie tego bez ujawnienia tej osoby. Osobiście bym ich nie ujawnił. Bez niezależnej weryfikacji i tak prawdopodobnie nie wytrzymałby.

Jeśli wydajność w rzeczywistości nie odpowiada wydajności podczas testu (i masz dane, które to udowodnią), rozwiązanie powinno być proste: powiadom dostawcę, a jeśli wydajność nie poprawi się, anuluj umowę.

Nie musisz mówić, w jaki sposób odkryłeś, że test został sfałszowany, a jedynie, że codziennie wydajność nie odpowiada benchmarkowi testu (możesz nawet “niewinnie” zapytać: czy jakaś konfiguracja sprzętu/oprogramowania zmieniła się od czasu testu?) Ale Twoi prawnicy mogą być zainteresowani rozmową z firmą, której zapłaciłeś za kosztowny benchmark - czy był on taki sam jak dostawcy usług, czy inny?

W odniesieniu do Twojego lejka: nie ujawniaj jego nazwiska, który wrzuciłby go pod autobus bez powodu i bez korzyści dla własnej firmy. Ale możesz chcieć pozostać w kontakcie i ewentualnie odwzajemnić przysługę: ostrzeż go o potrzebie szukania innej pracy przed wypadkiem (gdy anulowanie umowy jest informacją publiczną, nie wcześniej). Rozumiem dylemat, że nie możesz zapewnić mu dobrej referencji (a może możesz - mówiąc, że był pomocny i przeszedłby dodatkową milę, aby porozumieć się z klientem).

Najprostszym sposobem na zwrot przysługi byłoby zabranie go kiedyś na kawę (poza lokalem obu firm, i powiedzenie mu, że spotkanie jest ściśle nieoficjalne ). Mogłoby to nastąpić wkrótce po odwołaniu projektu, a nie wcześniej, i wyjaśnić mu, w jaki rodzaj polityki korporacyjnej się wplątał, i jaki skomplikowany dylemat etyczny jest tam wolny do wzięcia (dla was obu). Tak więc następnym razem będzie mógł się z tym lepiej uporać. Wydaje się być uczciwym i pomocnym facetem, być może jeszcze nie wtajemniczonym w zawiłości życia - a wy macie doskonałą okazję pomóc mu wtajemniczyć go; pomóc mu wyciągnąć z tego lekcję bez szkody dla jego kariery.

Nie wiecie jak zareaguje następnym razem: nie mówiąc wam, czy nie oszukując klientów? :-)

Inne odpowiedzi są naprawdę dobre, ale nie widziałem tego wyraźnie w żadnej z nich -

Dlaczego nie miałbyś po prostu zarekomendować swojemu zewnętrznemu dostawcy benchmarków wykonania kolejnego testu, ponieważ ich metoda testowania była wadliwa. Jeśli wiesz, że informacje te zostały opublikowane i usługi zostały wyłączone, jestem pewien, że możesz znaleźć normę NIST lub ISO określającą właściwą procedurę dla tego typu testów. Możesz nawet szukać informacji o najlepszych praktykach w ISACA.

Nie ma znaczenia, co wiesz, tylko to, że publikując informacje o czasie i zmienionym środowisku, nie jest to ważny test. Nawet wtedy mógłbym pójść do zewnętrznej firmy testującej i zapytać ich, co myślą.

Wygląda na to, że zarówno firma testująca, jak i dostawca byli zaangażowani w tworzenie sytuacji z powodu niedokładnych wyników i byli IMO co najmniej niedbałymi i co najwyżej * zmową **.

Znowu nie wiem, do jakiej pracy zostałeś zatrudniony, ale jeśli coś z tego jest w zakresie, to jest to dobry sposób, aby uniknąć ujawnienia jakichkolwiek poufnych informacji.

Ujawnij wszystko swojemu klientowi i powiedz mu o tym, co masz. Masz zawodowy obowiązek zapewnić mu najlepszą możliwą obsługę i nie masz zawodowego obowiązku wobec młodszego programisty centrum danych. Twój klient dosłownie zapłacił Ci, abyś odkrył takie rzeczy.

Po ujawnieniu informacji, które zdobyłeś (za które Twój klient Ci płaci). Przedyskutuj weryfikację tego, co powiedział junior developer.

Jeśli się sprawdzi - zdecydowanie współpracuj z innym dostawcą.

Jako ludzie staramy się być mili i uczciwi i to jest godne podziwu. Jako profesjonalista masz obowiązek zapewnić swojemu klientowi jak najlepszą obsługę.

Zwykły fakt, że rzeczywista aplikacja ma “straszną wydajność oprogramowania”, podczas gdy w testach “wyniki były w porządku” powinien zadzwonić do każdego i może być wykorzystany jako punkt wyjścia do dyskusji lub zakwestionowania testów. Mógłbyś/powinnaś wzbudzić podejrzenia na farmie testowej u klienta co do tej rozbieżności, szczególnie biorąc pod uwagę, że jesteś za nią “odpowiedzialny”.

Dodatkowo, oryginalny problem pozostaje nierozwiązany i otwarty do dalszej analizy, z udziałem lub bez udziału wysoko opłacanej firmy zewnętrznej. Dla wielu technologii dostępne są narzędzia do monitorowania wydajności produkcji bez rzeczywistego wpływu na nią; możesz użyć tego do ilościowego określenia “strasznej”. Dodając do HopelessN00b’s reply , byłby to kolejny sposób na weryfikację.

Twoim źródłem jest “młodszy programista zatrudniony przez hosta serwera, który się o to spierał”. Innymi słowy, jeśli chodzi o Ciebie, nie zrobiłeś absolutnie nic złego, aby uzyskać te informacje.

Twoim obowiązkiem nie jest wobec dostawcy usług internetowych, ani młodszego programisty w ISP, ale wobec Twojego klienta. Dlatego uważam, że powinien pan poinformować swojego klienta. Możecie wspomnieć jakie mieliście źródło, nie wspominając o rzeczywistym źródle. Co się stanie: Twój klient przestanie oszukiwać ISP, dostawca straci klienta, którego oszukuje, a junior deweloper, miejmy nadzieję, że nie będzie już o tym mówił, będzie w niebezpieczeństwie.