Pytanie:
Lider zespołu współpracowników chce wprowadzić do naszego rozwoju okropne oprogramowanie swojego przyjaciela. Co mam powiedzieć naszemu wspólnemu szefowi?
Gray Sheep
2019-03-13 17:56:40 UTC
view on stackexchange narkive permalink

Teoretycznie jest na tym samym poziomie co ja. W praktyce jest nade mną (jako de facto lider zespołu). Pracuję nad rozwojem / devopsem, częściowo pokrywając się z jego projektami.

Właśnie mieliśmy spotkanie z firmą, która chciała nam sprzedać to gówniane oprogramowanie. Zaprosił mnie na to spotkanie, mimo że miał wystarczająco dużo informacji o moich preferencjach, aby wiedzieć, że prawdopodobnie bardzo mi się nie spodoba ten pomysł.

Zacząłem pisać e-maila do naszego szefa, w którym po prostu mówię prawdę , jak to widze. Problem w tym, że po przeczytaniu własnej poczty stało się jasne, że w przeciętnej firmie zagroziłoby to mojej pracy. W ten sposób usunąłem tę wiadomość bez jej wysyłania.

Generalnie w firmie panuje ponadprzeciętna przyjazna atmosfera, co uważam za dużą wartość i nie chcę jej zatruwać. Opinia podwładnych ma również ponadprzeciętny wpływ na decyzje wyższego szczebla, też uważam to za dużą wartość. W zamian nasze zarobki są nieco poniżej średniej.

Problem w tym, że lider zespołu prawdopodobnie wykorzysta teraz swój „wpływ” na programistów, aby wesprzeć pomysł, a tym samym wpłynąć na decyzję naszego wspólny szef. W ten „pośredni” sposób prawdopodobnie będzie w stanie wstrzyknąć oprogramowanie do tworzenia.

Nie mam takiego samego wpływu.

Ale muszę coś zrobić . Ale co?

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/91006/discussion-on-question-by-gray-sheep-co-worker-team-leader-wants-to-inject-the-c).
Co to za „gówniane oprogramowanie”?czy mówimy o bibliotece, aby zaspokoić potrzebę biznesową?IE: Masz zamiar przetwarzać dokumenty programu Word?Czy jest to oprogramowanie typu junkware, które jest instalowane na mahinach klientów?IE: „oferty bonusowe” dostarczane z programem Adobe Reader?Czy jest to oprogramowanie pośrednie, które robi takie rzeczy jak Source Safe?Różne podejścia do różnych typów „badziewnego oprogramowania” ...
@WernerCD Chociaż cieszę się z Waszej ciekawości i chętnie podzielę się szczegółami kryjącymi się za butelką piwa, w naszym obecnym kontekście nie są to potrzebne informacje, aby odpowiedzieć na pytanie.
Wzruszając ramionami, myślę, że są… Ustalą uzasadnienie dla oprogramowania i argumenty przeciwko wspomnianym „oprogramowaniu” zarówno z perspektywy programisty, jak i biznesowego.
@WernerCD Tak.Ten punkt jest częścią większości już napisanych odpowiedzi, które możemy przeczytać tutaj.
Jesteś lepszy w pisaniu - i nie wysyłaniu - e-maili niż ja.Dobra robota!
Dwanaście odpowiedzi:
Sourav Ghosh
2019-03-13 17:59:37 UTC
view on stackexchange narkive permalink

Ale muszę coś zrobić. Ale co?

Przekaż swoją opinię w „konstruktywny sposób” i zakończ ją. Nie twoje miejsce do podejmowania decyzji.

Wspomnij o czymś w rodzaju

„Dobrze było mieć szansę na ocenę produktu X. Jak widzę it:

- Zalety: 1, 2, 3

- Wady: 1, 2, 3, 4, 5 , 6, 7, 8, 9, ......

Jak wynika z powyższej analizy, lista wad przeważa ogólnie nad listą zalet, Nie byłbym skłonny tego używać.

Mogłaby istnieć lepsza alternatywa, która mogłaby dać odwrotny wynik danej oceny, proszę daj mi znać, jeśli będziesz mnie potrzebować żeby nad tym popracować. ”

Zostałeś zaproszony na spotkanie (i chyba na demo) i masz rzetelne pojęcie o wzlotach i upadkach. Zgłaszasz je wyłącznie na podstawie zalet i wad. Pozostaw część decyzyjną osobom, które je podejmują.

W późniejszym czasie, jeśli powróci w formie, że „nawet po wprowadzeniu nowego narzędzia, dlaczego produktywność spadła „kłótnia, cóż, będziesz miał swój„ dowód ”.

Ponieważ OP już podkreślił, że mieli uprzedzenia jeszcze przed rozpoczęciem spotkania;może to pomóc im w ustaleniu, czy produkt naprawdę jest tak zły, jak im się wydaje.
+1, ale chciałbym móc zagłosować więcej - mianowicie dlatego, że ta odpowiedź obejmuje dwa najważniejsze aspekty: Zawsze przedstawiaj swoją ocenę w konstruktywny, nie lekceważący sposób i zachowaj papier (błąd, elektron. Błąd, masz pomysł) ślad.
Zastąpiłbym „Widzę” słowem „Znalazłem” i dodałbym gdzieś zdanie mówiące coś w rodzaju „Ta lista nie jest zamknięta.Zaktualizuję go o wszelkie nowe informacje, które zgromadzę.Wszelkie uwagi są mile widziane. ”Chodzi o to, aby uzyskać więcej informacji od współpracowników i pokazać, że masz otwarty umysł.
Upewnij się, że czujesz się komfortowo, gdy ktoś w firmie widzi wszystko, co piszesz.Jest bardzo prawdopodobne, że lider drugiego zespołu zobaczy to, co napisałeś, więc napisz to bezstronnym głosem, przedstawiając fakty, a nie opinie.
Po prostu skopiuj wiadomość do innego leadu, a właściwie dodaj wszystkich, którzy byli na tym spotkaniu.W ten sposób będzie się wydawać bardziej bezstronne.
Sugerowanie, aby firma dokonała przeglądu konkurencyjnych produktów przed podjęciem decyzji, jest zawsze dobrym posunięciem.Umieść listę kandydatów w notatce dla szefa.
Myślę, że dodatkowo w Cons w PO można wymienić wpływ gospodarczy, na który firmy zwykle reagują.Podobnie jak w tym systemie operacja ta potrwa średnio 15 minut dłużej.To normalne oszustwo, ale mógł obliczyć, ile razy w tygodniu jest to robione i ile pieniędzy zostanie straconych itd.
@Dzyann Tak, bardzo ważny punkt, powinien zostać uwzględniony, jeśli to możliwe.
Gregory Currie
2019-03-13 18:11:17 UTC
view on stackexchange narkive permalink

Jeśli uważasz, że współpracownik działa w sposób kumoterski i gra szybko i luźno z funduszami firmy, tak, to jest coś, co powinieneś zebrać ze swoim przełożonym.

Mówienie, że oprogramowanie jest „gówniane”, jest raczej nie zapewni ci dużej przyczepności. Musisz określić ilościowo, w jakim stopniu jest on poniżej standardu i jak firma nie uzyska odpowiedniego stosunku wartości do ceny. Tak jak denerwujesz się, że lider twojego zespołu nie jest obiektywny, tak samo musisz być obiektywny.

Na przykład, możesz porównać to "gówniane" oprogramowanie z ofertami konkurencji. Możesz również oszacować wartość kodu bazowego w zaoszczędzonych roboczogodzinach.

Możliwe, że zostałeś zaproszony, aby dać iluzję obiektywizmu. Jeśli Twój „lider zespołu” wybrał Cię, ponieważ wiedział, że możesz być „ostrożny”, aby poruszyć tę kwestię ze swoim menedżerem, a zatem uzyska on pośrednie potwierdzenie Twojej obecności.

„@GraySheep był tam i nie zrobił tego Nie zgłaszaj żadnych obaw ”

Nie chcesz milczeć i mieć prawdy na jaw.

Dziękuję Ci bardzo!Jednak powiedzenie, że za plecami lidera zespołu wyglądałoby dla mnie jak machinacja.Powiedzenie tego ze świadomością lidera zespołu (tj. DW: -wysłanie mu poczty) byłoby otwartym konfliktem.Co jest lepsze?
Jeśli nie chcesz iść za plecami lub nie możesz zaufać zarządzaniu, drugą opcją nie jest konflikt.Prawdopodobnie skierowałbym e-mail do Twojego „lidera zespołu” i CC Twojego menedżera i zacząłbym od: „Dziękuję za umożliwienie mi pomocy firmie w ocenie odpowiedniości rozwiązania Y firmy Z. Poniżej podsumowałem moją ocenę, a także krótką ocenę innych opcji. Jeśli chcesz, zawsze mogę omówić dowolne punkty ”.Następnie przedstaw analizę zalet / wad rozwiązania i omów wady / zalety konkurencyjnych rozwiązań.(Może nie tak głęboko).
W ogóle bym nie wspomniał, że przyjaźnią się z „liderem zespołu”, a nawet traktują ich specjalnie.Bądź obiektywny.Jeśli chciałeś znaleźć się za plecami lidera zespołu, możesz zgłosić swoje wątpliwości menedżerowi, ale prawdopodobnie poprosi Cię on o przygotowanie listy zalet / wad, więc może powyższy list jest punktem wyjścia.
Komentarz Gregory'ego na temat „stwierdzenia, że to bzdury, nie zaprowadzi cię daleko” pozostaje prawdziwy * nawet jeśli oprogramowanie jest rzeczywiście kupą bzdur *
Niestety, często trudno jest oszacować, w jakim stopniu oprogramowanie jest gówniane, bez poświęcania nadmiernej ilości czasu na gromadzenie dowodów i dokumentowanie najdrobniejszych szczegółów oraz dostarczanie długiego wyjaśnienia, w jaki sposób problemy faktycznie wpłyną na cokolwiek.Czy masz jakąś radę, jak to przezwyciężyć?
@GregroyCurrie Wyjaśniłem fakty w krótkim mailu do szefa.Nie użyłem słowa „bzdury” i żadnych negatywów.Właśnie wyjaśniłem, że to by nie pomogło i nadal powinniśmy używać technologii X, po pierwsze dlatego, że jest to, czego chce klient, a po drugie, ponieważ jest to powszechna technologia w branży i twórcy po prostu powinni się jej nauczyć.Odpowiedź nie nadeszła, ale jestem pewien, że szef ją przeczytał.
@GraySheep Już odpowiedziałeś;ale jedną z kluczowych kwestii jest kwestia „za jego plecami”.W inżynierii nie powinno być czegoś takiego.Chcemy najlepszego rozwiązania, a to wymaga otwartej dyskusji z więcej niż jednym punktem widzenia.Więc ten e-mail nie powinien po prostu trafić do twojego szefa.Powinien trafić do twojego szefa, współpracownika, kogokolwiek innego z Twojej firmy na spotkaniu i wszystkich innych współpracowników, którzy będą używać tego oprogramowania.Lub powinieneś odbyć spotkanie ze wszystkimi tymi osobami, podczas których możesz przedstawić swoje opinie na temat zalet i wad tego oprogramowania.
@jpmc26 To zależy od * jak * to bzdury.:) Jeśli OP zajmuje się najdrobniejszymi szczegółami, prawdopodobnie nie jest to takie bzdury, jak się wydaje.Ale jeśli możesz powiedzieć, że nie działa na platformach, do których go potrzebujesz, nie ma kluczowych funkcji A, B i C, których używamy bardzo szeroko, czas przetwarzania wynosi X, gdy potrzebujemy co najmniej Y, instrukcjesą trzy nieaktualne wersje - są to problemy z szerszej perspektywy, które naprawdę * sprawiłyby *, że jest to „crapware”, by zapożyczyć wyrażenie OP.Są to wszystkie fakty, które osoby nie będące ekspertami mogą łatwo zrozumieć.
@Graham Nie było otwartej dyskusji.Po prostu zostałem zaproszony na spotkanie.Nikt nie zapytał mnie o zdanie.Mimo to napisałem to do szefa.Tak, za plecami.W przyszłości zignoruję cały temat.
@Graham Rozwiązuje problem polegający na tym, że programiści nie nauczą się podstawowej technologii X w niestandardowy sposób, co prawdopodobnie spowoduje niezadowolenie klientów.
@Graham Minute szczegóły mają znaczenie.Jeśli API nie jest zgodne ze standardami językowymi, praca z nim będzie kosztowna, ponieważ będziesz musiał samodzielnie wdrożyć standardowe funkcje językowe.Jeśli wybuchnie w 1 skrzynce na tysiąc i masz 100 000 rekordów, automatyzacja będzie kosztowna.Nie można po prostu odpisać „najdrobniejszych szczegółów” w oprogramowaniu, ponieważ oprogramowanie musi działać bez nadzoru.
Z mojego doświadczenia wynika, że spotkanie będzie miało łańcuch e-maili i prawdopodobnie dyskusję przed i po spotkaniu.Czy nie ma takiego forum, na którym można by odpowiedzieć wszystkim zaangażowanym w swoje przemyślenia na temat produktu?
@jpmc26 Nie znam nikogo, kto wziąłby pod uwagę te „minuty”, może z wyjątkiem sprzedawców.Więc tak, oczywiście możesz odpisać drobne szczegóły, jeśli są naprawdę drobne, a to oznacza albo problemy niefunkcjonalne, problemy, które nie będą widoczne dla klienta, albo problemy, które nie wpłyną znacząco na programistów.Nie obchodzi mnie, że niektóre funkcje nie mają wyczerpujących komentarzy Doxygen, o ile jest jasne, jak ich używać.Jeśli nie działają zgodnie z reklamą, to inna sprawa.
@GraySheep Jeśli jesteś zaproszony na spotkanie dotyczące czegoś, domyślnie oczekuje się, że będziesz zaangażowany w wynik tego spotkania.* Nie * zrobienie tego zagroziłoby twojej pracy w przeciętnej firmie.To absolutnie w porządku * i oczekuje się *, że czasami nie zgadzasz się z kimś wyższym niż ty.Jeśli mają prawo zdecydować inaczej lub jeśli twój szef wybierze swoją opcję, po prostu musisz się z tym zgodzić.To jest sens posiadania łańcucha dowodzenia.Ale wszyscy oczekują, że będziesz mieć ważną opinię techniczną, w przeciwnym razie nie zatrudniłby cię.
@Graham Osoby, które nie piszą oprogramowania, prawdopodobnie uznają je za znikome.
@Graham Masz rację w przypadku oficjalnego, ale nie oficjalnego.
@jpmc26 Tak jak powiedziałem, inżynier jest odpowiedzialny za opisanie, dlaczego jest to ważne.Każdy inżynier, który nie potrafi wyjaśnić, dlaczego nadmuch 1 na 1000 jest złą rzeczą przy przetwarzaniu 100 000 rekordów, i tak nie jest wystarczająco kompetentny, aby mieć przydatne informacje techniczne.Oczywiście kierownictwo może nadal je omijać i w takim przypadku grosza zatrzymuje się na nich, ale informacje nadal muszą zostać przekazane.Niezaprezentowanie kierownictwu znanych krytycznych problemów jest rażącym zaniedbaniem, podobnie jak każde inne ukrywanie się, iw zależności od tego, jak bardzo coś pójdzie nie tak, może spowodować zwolnienie z pracy.
@GraySheep Jeśli stało się to w czasie pracy, to oficjalne.Nie ma czegoś takiego jak „nieoficjalny” czas pracy.
@Graham Tak, tak jest - ale tylko oficjalnie.:-)
Ertai87
2019-03-13 20:52:33 UTC
view on stackexchange narkive permalink

(Na dobre) zarządzanie ma wpływ logika, a nie wyzwiska. Czytając swój OP, wspomniałeś, że uważasz to oprogramowanie za bzdury, ale nie powiedziałeś, jak i dlaczego. Gdybym był menadżerem i czytał twoje OP, pomyślałbym, że jesteś tylko wichrzycielem i straciłbyś ze mną twarz. Jeśli tak napisałeś e-mail do kierownictwa, to dobrze, że go nie wysłałeś.

To, co chcesz zrobić, to jasno i obiektywnie przedstawić swoje zastrzeżenia. Może masz przypadek użycia, którego to oprogramowanie nie spełnia? Może oprogramowanie jest zbyt wolne lub nie spełnia innych testów? Może nie ma dla niego wsparcia, więc pojawiające się problemy techniczne byłyby trudne do rozwiązania? Może to po prostu zwykły buggy? Niezależnie od problemów, wyjaśnij je w jasny i szczegółowy sposób kierownictwu. Nie używaj słów takich jak „bzdury”, „okropne” czy cokolwiek; to są łajdackie słowa i nic nie znaczą. Przedstaw swoje obawy i pozwól, aby przemówiły one same za siebie.

Dzięki.To właśnie zrobiłem.Prawdopodobnie nie przyniesie to żadnego efektu, na dłuższą metę zobaczymy, co się stanie.
Kilisi
2019-03-13 18:07:14 UTC
view on stackexchange narkive permalink

Ale muszę coś zrobić. Ale co?

Pierwszą konstruktywną rzeczą do zrobienia jest dokładne sprawdzenie motywacji, dlaczego musisz coś zrobić? Dlaczego chcesz zaangażować się w spór, który Twoim zdaniem przegrasz.

Jeśli zostaniesz poproszony o przeanalizowanie narzędzia, zrób to, bez uprzedzeń o zaletach i wadach. Nie twórz problemów bez pełnej analizy lub podania przyczyny.

Bo jeśli bzdury zostaną wprowadzone do rozwoju, moja praca będzie znacznie trudniejsza.Drugorzędnym efektem tego narzędzia może być eksterminacja devopsów, gdy to robię.
Myślisz jednak, że wszystkim innym programistom będzie to dobrze?Tworzysz przeszkody, zanim do nich dojdziesz.
@GraySheep To są dwa osobiste powody.Musisz to zrobić o biznesie.
Twórcy nie są zbyt dobrzy w działaniach z własnej inicjatywy, robią to, co im się mówi.
@GregroyCurrie To również powód biznesowy, devops robię w standardowy sposób, a to narzędzie jest niestandardowe.Jest to 1) poważnie zależne od platformy, 2) zamknięte źródło 3) crapware.
@GraySheep 1) Czy korzystanie z wielu platform jest ważne dla Twojej firmy?2) Czy wolne oprogramowanie jest ważne dla Twojej firmy?3) Co to w ogóle oznacza?
@GregroyCurrie Tak, ponieważ programowanie przebiega w środowisku mieszanym (windows + mac + linux), serwery to głównie systemy Linux.W większości naszych projektów klienci uzyskują dostęp również do kodu źródłowego.
@GraySheep To są doskonałe powody.Powinieneś wtedy zamienić termin „gówno” na „nieodpowiedni” :) A takie rzeczy powinieneś zawrzeć w swoim liście.
@GregroyCurrie Na spotkaniu zobaczyłem w oczach firmy, że oni wiedzą, jestem dla nich wrogiem.A także widzieli to w moich oczach.Oczywiście wszystko poszło bardzo grzecznie (i profesjonalnie) na widocznym poziomie, prawdopodobnie nawet lider zespołu niczego nie widział.
@GraySheep To wszystko wydaje się dla Ciebie bardzo osobiste.Musisz zmienić swoją mentalność i przejść do działania (lub przynajmniej postrzegania go jako działającego) w najlepszym interesie swojego pracodawcy.
@GregroyCurrie Tak, to bardzo osobiste, jeśli widzę siły znacznie silniejsze ode mnie, chcące zmarnować moją pracę.
@GregroyCurrie To także powody biznesowe i powiem mu, że te powody biznesowe.Powody osobiste są znane każdemu, ale wspominanie o nich byłoby nieprofesjonalne.Wystarczy, że wiedzą (opinia podwładnych jest tu bardziej niż powszechna).
To najlepsza opublikowana rada, nawet jeśli nie jest tym, czego chce usłyszeć OP.Oświadczenie, że oprogramowanie nie powinno być używane, nie zależy od OP.Wszystko, co mogą zrobić, to wymienić problemy, aby firma mogła zażądać poprawek oprogramowania dostawcy, zaplanować je lub ponownie rozważyć.Kwestie należy przedstawiać bez uprzedzeń, w przeciwnym razie wątpliwości zostaną zdyskontowane.
@NathanHughes Nie, słyszę to i prawdopodobnie za tym pójdę.
-1
@jpmc26 Z grubsza to wyjaśniłem.Żadna reakcja nie nadeszła.Zobaczymy co się wydarzy.Najbardziej prawdopodobny wynik jest taki: 1) narzędzie zostanie wprowadzone do projektów, 2) twórcy nadal będą unikać nauki (bardzo podstawowej i bardzo standardowej) technologii, której wyeliminowanie jest jedynym celem tego „narzędzia” 3) Inie będzie już działać jako devops.4) Możliwe, że produkt zakończy się w dłuższej perspektywie, ale nie nastąpi to jutro.5) Kiedy już powiem „dość” i znajdę inną pracę, albo zostanę zwolniony
Wydaje mi się, że po prostu osobiście przyjmujesz propozycję współpracownika, ponieważ może to spowodować, że staniesz się zbędny.Być może firma po prostu ceni pozbycie się zasobów DevOps bardziej niż inne problemy, które sugeruje propozycja.
Dark Matter
2019-03-13 18:17:43 UTC
view on stackexchange narkive permalink

Przepisz list, który miałeś wysłać szefowi.

Nie zakładaj złych intencji od współpracownika.

Bądź uprzejmy. Być specyficznym. Upuść słowo „bzdury”. Dokonaj uczciwej, ale szczegółowej oceny i zrób kopię zapasową każdego poruszonego przez siebie punktu, a najlepiej umieść przykład każdego punktu w liście.

Szefie,
Sprawdziłem kod jest oferowany i uważam to za poniżej standardu z następujących powodów ...
1) Powód nr 1. Powód do myślenia, że ​​to problem. Przykład.

(Przykład) 1) W kodzie nie ma komentarzy. Mają X linii kodu. Wyszukałem grep i znalazłem w sumie Y linii komentarzy. Z perspektywy naszej obecnej bazy kodu ...

Uwaga podjęta, chociaż niektórzy nie uważają wiersza komentarza% za świetny wskaźnik jakości kodu :)
@GregroyCurrie Przejąłem bazę kodu, która miała ponad 100 tys. Linii kodu, które miały łącznie 7 linii komentarzy.Te 7 linijek komentarzy było bezwartościowych.W ogóle nie było żadnej zewnętrznej dokumentacji.Ma mocne opinie, miejmy nadzieję, że są mocne powody.
Gdyby 7 linijek komentarzy było bezwartościowych, 99 tys. Komentarzy nie mogło być bezwartościowych :) Zgadzam się, że dobry kod ma sensowne komentarze.
@TimB Brak argumentów z mojej strony.(Chociaż niektóre języki ułatwiają pisanie czystego kodu w porównaniu z innymi).
@Dark Matter: Po drugiej stronie skali widziałem obficie skomentowany kod (często robiony za pomocą automatycznych generatorów "dokumentacji"), w którym większość komentarzy jest typu "i ++; / * inkrementacja i * /".
Po prostu być tutaj po bezpiecznej stronie.Czy chcesz, aby OP porzucił słowo „bzdury” na spotkaniu z przełożonymi?
paw88789
2019-03-14 04:22:38 UTC
view on stackexchange narkive permalink

Zaprosił mnie na to spotkanie, mimo że miał wystarczająco dużo informacji z moich preferencji, aby wiedzieć, że prawdopodobnie bardzo mi się nie spodoba ten pomysł.

Być może odczuwa presję swoim przyjaciołom, aby przedstawili swoje oprogramowanie, nawet jeśli on sam może go nie lubić. Mógłby mieć nadzieję, że ktoś inny zauważy jego wady.

Mogę porozmawiać z nim bezpośrednio (w zależności od naszego związku) i spróbować ustalić, co naprawdę myśli. Chciałbym również zwrócić uwagę na wady w bardziej neutralnym języku niż „gówniane” oprogramowanie.

Bardzo prawdziwe.Jednym z najlepszych sposobów grzecznego powiedzenia „nie” jest przerzucenie odpowiedzialności na kogoś innego.
AndreiROM
2019-03-13 18:14:18 UTC
view on stackexchange narkive permalink

Kilka razy nazywasz to oprogramowanie „bzdurą”, więc wyraźnie wiesz co nieco o tym, czym ono się zajmuje i czego tak naprawdę potrzebuje Twoja firma. Napisz dokument (e-mail) opisujący swoje obawy dotyczące funkcji / funkcjonalności i wyślij go do swojego szefa.

Sugerowałbym również zaoferowanie alternatywnych rozwiązań, takich, że nie jesteś po prostu zazdrosny lub negatywny. Zrób tabelę analizującą funkcje, ceny itp.

Niektóre opcje, które nie mają takiego samego ryzyka to X i Y. Cena dla X jest nieco wyższa niż opcja zaproponowana przez Johna , ale ma następujące zalety: ...

Na samym końcu e-maila możesz umieścić wyrażenie w następujący sposób:

Jak możesz Widzisz, istnieją solidne powody, dla których powinniśmy nadal szukać produktu, który wypełni tę niszę. Ponadto obawiam się, że na decyzję Johna o poleceniu tego oprogramowania może wpłynąć fakt, że stworzył je jego bliski przyjaciel.

Możesz zachować tę ciekawostkę w rezerwie tylko w przypadku trzeba jednak eskalować.

Tak, wiem o wiele więcej z tego oprogramowania, aby nazwać to gównem.Jego jedyną zaletą jest to, że pomaga programistom uniknąć uczenia się technologii X, co jest dość powszechną technologią w branży, ale w jakiś sposób udało im się tego uniknąć.Teraz szef zespołu przyszedł z tym oprogramowaniem, które pozwala im się go nauczyć, jako efekt uboczny 1) pomaga mu w eksterminacji mnie 2) doprowadzi to do nadużyć w dłuższej perspektywie.Widzę to, ale teraz słowo lidera zespołu + stojących z nim deweloperów jest przeciwko mnie.Z pewnością mój będzie słabszy.
GittingGud
2019-03-13 18:19:13 UTC
view on stackexchange narkive permalink

Porozmawiaj o tym ze swoim kolegą / nieoficjalnym liderem zespołu.

Myślisz, że zna Twoją opinię na ten temat, ale może tak nie być.

Zaprosił Cię na spotkanie, co oznacza, że ​​ceni Twoją opinię. (Zakładam tutaj, że nie zaprosił Cię do drwin z powodu Twojej wysokiej opinii na temat dobrego klimatu w pracy)

Powiedz mu bezpośrednio, że oprogramowanie, które chce wprowadzić, będzie w Twoją opinię , utrudniają dalszy rozwój projektu. Przyczyną jego wsparcia dla omawianego oprogramowania może być kwestia osobista, nad czym powinien się zastanowić. Jeśli tak nie jest, poproś go o wyjaśnienie dlaczego uważa, że ​​oprogramowanie usprawni rozwój.

Normalna dyskusja na temat związany z pracą, który ma wpływ na Twoją pracę, nie powinna stanowić zagrożenia dla Twojego zatrudnienia lub statusu społecznego w Twojej firmie. okazuj współczucie dla swojej pracy.

Ale co najważniejsze: Robisz to profesjonalnie.

EDIT1: Jeśli Twój kolega nie pokazuje żadnego dobrego uzasadnienia o tym później ze swoim przełożonym. Może zaproponuj trójstronną dyskusję, aby szybko zająć się tematem.

Mógł też zostać zaproszony, aby dać złudzenie obiektywizmu.
Niemniej jednak fakt, że PO został zaproszony na spotkanie, oznacza, że PO posiada kompetencje w temacie i tym samym ma kwalifikacje / uprawnienia do brania udziału w decyzji. A ponieważ współpracownik nie może teraz zakończyć iluzji, oznacza to, że nie może nic zrobić, aby OP wyraził swoją uczciwą i profesjonalną opinię.
Nie wydaje mi się, żeby to było prawdą, chociaż prawdopodobnie tak jest w tym przypadku.Ale zgadzam się w pełni, że powinien jak najlepiej wykorzystać tę „iluzję”.
MattH
2019-03-13 20:53:03 UTC
view on stackexchange narkive permalink

Twój współpracownik ma konflikt interesów. Powinieneś omówić to z innymi członkami swojej organizacji i upewnić się, że oprogramowanie zostało właściwie ocenione przez jakąś stronę, która nie ma żadnego interesu i nie podlega niepożądanym wpływom.

Ewentualny konflikt interesów nie jest problemem, jeśli narzędzie jest dobre, i tak mówi teraz cały zespół oprócz mnie.
user53651
2019-03-13 21:22:14 UTC
view on stackexchange narkive permalink

Jeśli jego przyjaciel nie pracuje w firmie, wstrzyknięcie oprogramowania jego pączków do przepływu pracy firmy jest po prostu konfliktem interesów. Zwrócenie na to uwagi bardzo by pomogło.

Wytłumaczyłbym również swojemu szefowi, dlaczego to oprogramowanie jest beznadziejne i spróbuję przedstawić analizę korzyści związanych z jego użyciem. Posunąłbym się nawet do próby pokazania, ile pieniędzy straci firma z powodu straconego czasu na rozwój, zajmując się nie do utrzymania się puszką robaków, które przyjaciel szefa zespołu próbuje udawać jako kod. To też powinno pomóc.

Jednak wychodzisz ponad głowy swojego zespołu, więc prawdopodobnie nie będzie to miało większego wpływu na Twoją karierę w obecnej firmie. Jesteś jednak deweloperem; zawsze możesz znaleźć inną pracę, która prawdopodobnie będzie wiązała się z podwyżką, więc nie powinieneś się bać w takich sytuacjach.

Jestem tutaj, ponieważ atmosfera jest ładna, a szefowie nas słyszą.Są to ogromne ulepszenia w stosunku do moich poprzednich doświadczeń i warte dla mnie nieco niższej pensji.Nie chcę ponownie zostać niewolnikiem tylko za + 10%.Jeśli przestawię się na inną pracę, stracę te.
Dobrze.Istnieje technologia zwana „technologią X”, która jest dość powszechna w branży i zna ją praktycznie każdy przydatny programista.Do tej pory naszym twórcom jakoś udało się tego uniknąć.Narzędzie, nazwij je „narzędziem Y”, które lider zespołu chce wstrzyknąć, ma trzy efekty: 1) pozwala programistom na naukę „technologii X” 2) doprowadzi do różnych nadużyć / niezadowolenia klienta w perspektywie długoterminowej 3) wyrzuca mniejako devops z projektów wykorzystujących „technologię X”.|To są fakty.Jakie są motywy, te wciąż są mi nieznane.
@GraySheep całkowicie pomylił to pytanie z innym lolem.Mój błąd.Jest jeszcze jedno pytanie, w którym udzieliłem podobnej rady, ponieważ ta osoba ma do czynienia z fizyczną walką podczas spotkań.
@GraySheep, dlaczego Twoje zaangażowanie w projekt ma kluczowe znaczenie dla jego sukcesu?Jakie inne korzyści przyniosłaby Twojemu zespołowi nauka technologii X?Musisz oszacować, ile czasu / pieniędzy spowodują błędy w sztuce.Czy jest też dobry powód, dla którego Twój zespół nalega, aby nie używać technologii X?
To nie jest kluczowe.Deweloper może być odnoszącym sukcesy programistą bez znajomości kluczowej technologii w swojej dziedzinie, a zespół takich programistów może być dobrym zespołem.Rozwój projektu bez devopsa może być pomyślnym rozwojem projektu (przy okazji, nigdy nie chciałem zostać tutaj devopsem, po prostu stało się to w wielu małych krokach).Szanse są tylko mniejsze.
Nie mogę oszacować.Jednak większość naszych klientów chce funkcji Z, która nie jest niezbędna do skutecznego korzystania z naszego oprogramowania, ale chcą jej, co jest sprzeczne z „narzędziem Y”.Klient będzie wiedział, że jego wymagania są spełnione tylko częściowo, dopiero po zapłaceniu za produkt.
Jeśli chodzi o twoją odpowiedź: nie mogę wskazać na konflikt interesów, ponieważ jestem pewien na 99%, ale nie mam dowodów.Nie będę nikogo fałszywie oskarżać.Ostateczna decyzja nie należy do kierownika zespołu, ale do szefa.Wyjaśniłem to w mailu, tak profesjonalnie, jak tylko mogłem.Moje słowo będzie prawdopodobnie dużo słabsze niż całe zespoły.
@GraySheep solidna etyka.Czy na pewno nie dostaniesz podwyżki o + 40%?Znam wielu ludzi, którzy to zrobili.
Nie. Mógłbym dostać około + 10%, gdybym ciężko pracował, aby znaleźć inną pracę.Ludzie w tym regionie są w pewnym sensie bardzo wrażliwi, nawet na niewielkie różnice płac, dlatego niewielki zysk wymaga ciężkiej pracy.W zamian zostałbym niewolnikiem Wielkiej Kompanii.Mógłbym mniej więcej podwoić się, przechodząc na freelancera, tego prawdopodobnie spróbuję, jeśli moja praca w jakiś sposób się skończy.
@GraySheep Musisz być w Londynie.Uważaj na sprawy freelancerów.Możesz zarabiać podwójnie, ale musisz też płacić za wszystkie swoje rzeczy, opiekę zdrowotną, podatki itp.
Dzięki.Wiem.Nie chcę wyjeżdżać, jeszcze to zaakceptuję.
Paolo
2019-03-14 02:32:54 UTC
view on stackexchange narkive permalink

zadawaj pytania.

zidentyfikuj problem, który wystąpi podczas korzystania z tego oprogramowania i zapytaj, jak zostanie on rozwiązany.

obsługujemy wiele platform, ale to narzędzie nie: jak to zostanie rozwiązane? pozostawiamy rozwój na platformie X, która jest podstawą naszej bazy klientów?

to nowe narzędzie jest objęte licencją X, która nie jest kompatybilna z naszym produktem: może być wymagane przepisanie naszej licencji?

automatyzujemy zadanie X, Y i Z, obniżając koszty o 15%, ale to nowe narzędzie nie jest kompatybilne z obecnym oprogramowaniem do automatyzacji: które rozwiązanie automatyzacji musimy nabyć, aby osiągnąć ten sam cel?

kierownictwo zwraca uwagę na koszty, ale zwykle nie dba o szczegóły techniczne; jeśli możesz zadać kilka trudnych pytań z widocznymi kosztami, Twój punkt widzenia może być łatwo zrozumiały.

Zadaj zbyt wiele lub zbyt głupich / wybrednych pytań, a od tej pory stracisz jakąkolwiek przyczepność i zostaniesz oznaczony jako kłopot .

Dominique
2019-03-15 01:31:01 UTC
view on stackexchange narkive permalink

Wspomniałeś, że to oprogramowanie jest okropne, bzdury, jak je nazywasz.

Udowodnij to!

Bzdury są:

  • bardzo niestabilne ( co jeśli pozwolisz mu działać z wieloma żądaniami w tym samym czasie) => przeprowadzaj testy obciążenia
  • bardzo wybredne jeśli chodzi o dane wejściowe / parametry (kiedy wprowadzisz ciąg, w którym oczekiwana jest liczba, całość awarie).
  • z punktu widzenia programisty, bardzo trudne w utrzymaniu: wyobraź sobie, że ktoś żąda zmiany, ile czasu potrzeba na opracowanie oczywistej modyfikacji?
  • nieprzyjazny dla użytkownika ( jak to powinno wyglądać?)
  • marnowanie zasobów (ile czasu zajmuje wykonanie najłatwiejszych obliczeń, ile pamięci zużywa, ...?)

Rozumiem: skonfigurowanie środowiska do udowodnienia złej jakości tego oprogramowania może zająć trochę czasu, więc aby przekonać kierownictwo, możesz poinformować kierownictwo o swoich wątpliwościach i poprosić o trochę czasu na przygotowanie środowiska testowego (w przypadku to jeszcze nie jest dostępne).

To właśnie zrobiłem.Udowodniłem to.Niestety, moje argumenty prawdopodobnie nie były wystarczająco przekonujące w tych okolicznościach, ale to było wszystko, co mogłem zrobić.


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...