Jak poradzić sobie z niestety nie hipotetyczną sytuacją użytkowników końcowych?

22

Pracuję w średniej wielkości firmie, ale z bardzo małą siłą informatyczną.

W zeszłym roku (2011) napisałem aplikację, która jest bardzo popularna wśród dużej grupy użytkowników końcowych. Dotarliśmy do terminu pod koniec ubiegłego roku i pewna funkcjonalność (od tej pory nazywam funcA) nie została dodana do aplikacji, która była pożądana na samym końcu. Tak więc, ta aplikacja działa na żywo / produkcji od końca 2011 roku, mogę dodać bez problemu.

Wczoraj cała grupa użytkowników końcowych zaczęła narzekać, że funcA, którego nigdy nie było w aplikacji, już nie działa. Naszym priorytetem w tej firmie jest to, że jeśli aplikacja zostanie zerwana, musi zostać najpierw naprawiona przed priorytetowymi projektami.

Porównałem kod i zapytania i od 2011 roku nie ma różnicy, co jest dowodem A. Byłem wtedy w stanie skłonić jednego z użytkowników końcowych do przyznania, że nigdy nie działał proofB, ale od tego czasu ten użytkownik końcowy powrócił i powiedział, że działał wcześniej ... Wierzę, że horda użytkowników końcowych zasymilowała się jej. Przejrzałem także moje notatki do tego projektu, który ma wymagania i codzienne aktualizacje dotyczące projektu, który wyraźnie stwierdza, że „funcA nie osiągnięto z powodu ograniczeń czasowych”, proofC.

Rozmawiałem z wieloma z nich i widzę, gdzie mogą być zdezorientowani, ponieważ są bardzo daleko od tła programistycznego, ale wiem też, że są wystarczająco inteligentni, aby działać w grupie, aby ominąć zlecenia priorytetów projektu, aby uzyskać funkcje, które chcą ułatwić im pracę.

Najgorsze jest to, że teraz zaczyna się grupowe myślenie, a mój szef i szef IT tak naprawdę w to wierzą, mimo że nie ma zmian w kodzie ani zapytaniach. Jeśli chodzi o sprawdzenie stanu logiki, jest ona bardzo wycięta i sucha do tego stopnia, że 1 = 1, funcA nie będzie działać.

To jest koniec opisu mojego scenariusza, ale staram się nie pogarszać moich mierników wydajności z powodu tego, co w zasadzie zmusiłoby mnie do rozwiązania problemu z produkcją, który nie istnieje i który prawdopodobnie przejmie kontrolę 1 miesiąc.

project-management requirements maintenance

— Użytkownik Smith
źródło

1

Nie jesteśmy forum w tradycyjnym tego słowa znaczeniu, jesteśmy witryną pytań i odpowiedzi, która szuka odpowiedzi na pytania. Ranty, ankiety i dyskusje na ogół nie pasują do naszego formatu.

— wałek klonowy

12

@maple_shaft: Nie zgadzam się. To poważne pytanie, które poszukuje sposobu na rozwiązanie prawdziwego problemu, który pojawia się, gdy mamy do czynienia z, powiedzmy, mniej przekonującymi użytkownikami końcowymi. Wszyscy to widzieliśmy i byliśmy sfrustrowani, prawda? Pomysły dotyczące radzenia sobie z takimi scenariuszami są więc bardzo odpowiednie dla formatu tej witryny.

— Mason Wheeler,

1

Czy nie jest możliwe, aby istniała odpowiedź na to pytanie? Kto będzie obserwował obserwatorów?

— Użytkownik Smith

2

Z korzyścią dla innych, którzy to czytają, ta sprawa stanowi kolejną lekcję dla tych z nas, którzy uważają, że dokumentacja jest drugorzędna i że wymagania dotyczące śpiewu nie są ważne.

— NoChance,

1

słynne ostatnie słowa „nic się nie zmieniło”.

— JeffO

18

Spory dotyczące łatwo zauważalnych faktów są w rzeczywistości dość łatwe do rozwiązania: wystarczy obserwować fakty. Jeśli powiem „przed moim domem jest drzewo z fioletowym drewnem”, każdy, kto może przyjść do mojego domu, może sam sprawdzić prawdę lub fałsz mojego oświadczenia.

Jeśli narzekają, że FuncA był w produkcie i działał we wcześniejszej wersji, a teraz nie działa, a nie uważasz, że kiedykolwiek był w produkcie, poproś go, aby to udowodnił. (Lub, łagodniejszymi słowami, powiedz coś takiego: „mamy problem z odtworzeniem problemu. Czy możesz nam pomóc tutaj?”)

Daj im kopię wcześniejszej wersji, jeśli jeszcze jej nie ma, i weź ją na LiveMeeting, i pokaż im, jak korzystali z FuncA. Jeśli nie są w stanie tego zrobić, to (miejmy nadzieję) zdają sobie sprawę, że nie było go w ogóle, i odejdą od twojej sprawy lub przynajmniej spróbują zastosować inną taktykę, aby ją wdrożyć. (I pamiętaj, aby poprosić kogoś z kierownictwa lub PM o udział w LiveMeeting.)

— Mason Wheeler
źródło

Pokazali zrzut ekranu dowodu, który mogę wyjaśnić, ale jest to tylko częściowy, więc szczegóły scenariusza są tym, co mówią, że nie są tak naprawdę zdefiniowane za pomocą zrzutu ekranu. Zasadniczo sprowadza się to do tego, że MGMT nie bardzo zdaje sobie sprawę z logiki i w tym momencie jest to słowo całej depresji przeciwko jednemu skromnemu programistowi. (Również poprzednia wersja jest taka sama, jak początkowe wdrożenie, które miało miejsce w 2011 r.)

— Użytkownik Smith

3

@UserSmith: Właśnie dlatego powiedziałem, aby użyć LiveMeeting. Trudniej jest pomylić to, co się dzieje, gdy trzeba to zrobić z obserwującymi ludzi.

— Mason Wheeler,

1

Ta odpowiedź zapewnia znacznie lepszą definicję dowodu niż „użytkownik końcowy tak mówi” lub „czytam kod”. Zatrzymaj się i pamiętaj 10 ostatnich razy, że jako programista byłeś całkowicie oszołomiony, możesz się mylić, mimo że wpatrujesz się w 1 = 1 w kodzie (np. Kiedy tak naprawdę powinno być 1 == 1). Jeśli myślisz o dowodach w kategoriach „odczytu kodu” jako osoby podatnej na błędy, to szczerze mówiąc, twoje wskaźniki wydajności powinny zostać trafione. @MasonWheeler zaproponował ci dokładniejszą i bardziej atrakcyjną epistemologię, wolałbyś postępować zgodnie z nią.

— djechlin

Podczas negocjacji mówi się: „Jeśli musisz się bronić, już przegrałeś”. Dowodzenie faktów jest ostateczną formą obrony - z reguły najlepiej tego nie robić, chyba że zostaniesz o to poproszony, nawet jeśli to krótkie - mniej znaczy więcej.

— mattnz

1

Oznaczone jako odpowiedź prawdopodobnie najbardziej konkretna. Chociaż przed opublikowaniem tego pytania odbyłem już spotkania na żywo. I jeszcze kilka innych, które były częściowo dobrymi odpowiedziami. Szczerze mówiąc, w tym momencie nie dbam o swoje wskaźniki, bardziej faktem jest, że podstawowa struktura naszej organizacji IT jest w takim stanie chaosu, że to nawet mnie martwi.

— Użytkownik Smith

13

Nie jest to kwestia, którą można rozwiązać na podstawie faktów - jeśli spróbujesz, stracisz wiarygodność.

Po pierwsze, zaakceptuj, że oprogramowanie jest „zepsute” - ponieważ nie robi tego, co chcą użytkownicy. Teraz zaakceptuj, że użytkownicy mają prawo, aby oprogramowanie robiło to, co chcą - to właśnie dlatego oprogramowanie. Mamy więc wadliwe oprogramowanie i inżynier odmawiający naprawy .....

W rezultacie, jeśli system, który uruchamiasz, aby ustawić priorytety, użytkownicy ci nie mogą naprawić swojego oprogramowania, przechodząc przez normalne kanały, więc używają kanałów bocznych i eskalują pół prawdy wyżej w łańcuchu pokarmowym, aby spróbować manewrować systemem, w w międzyczasie, sprawiając, że twój KPI wygląda źle (Twoim głównym zmartwieniem powinni być klienci, a nie KPI) - Twoje KPI są uważane za „szkody dodatkowe”, jeśli ci się podobają, lub korzystny efekt uboczny, jeśli nie. Mają jednak pewną kontrolę nad tym, co się dzieje - najlepiej, jak cię lubią.

Tak się dzieje, że system jest zepsuty i wszyscy próbują manipulować rzeczami, aby uzyskać to, czego chcą. Potrzebują funkcji, a Ty chcesz zachować swoje nieskazitelne KPI.

Chyba że możesz naprawić system lub nauczyć się grać w politykę biurową naprawdę szybko, koniec gry: przegrasz.

Uwaga: Żadna z tych dyskusji nie obejmuje martwych linii, dyskusji o błędach w porównaniu z funkcjami, kto płaci itp. To są fakty - i fakty nie mają znaczenia (no cóż, robią to, ale można nimi manipulować na wiele sposobów ... ) w polityce biurowej.

— mattnz
źródło

1

Jak można stracić crediblity jeśli można OKAZAŁ go?

— Thomas Eding,

3

@ThomasEding Wiarygodność w świecie biznesu polega bardziej na tym, jak postrzegają cię inni niż na faktach. Jeśli staniesz się celem, żadna liczba faktów cię nie ochroni. Ilu twórców gwiazd rocka spotkałeś, którzy byli kompletnymi oszustami? Spotkałem więcej niż chciałbym przyznać.

— wałek klonowy

2

Zgodziłbym się z dużą częścią tego, jest to zdecydowanie forma polityki biurowej. Kiedy spotkałem się z jakąkolwiek sytuacją, pomyślałem, że pierwszym działaniem byłoby poradzenie sobie z faktami, więc jakbyś mnie tam zgubił, ale zgodziłbym się z klientami, którzy przychodzą od pierwszego do drugiego, dopóki oczywiście nie zostaniesz zwolniony. +1 za inne podejście do sytuacji. +1

— Użytkownik Smith

2

Nigdy nie narzekaj, nigdy nie tłumacz. Dyskutowanie sprawia, że wyglądasz słabo. Słuchanie uprzejmych próśb jest dobre. Mówienie, że przedyskutujesz ich prośbę z szefem o priorytet, jest dobre. Jeśli się kłócisz, rób to, o czym krzyczą, to wzmacnia ich nieprzyjemne zachowanie. Jeśli eskalują, siła pozycji twojego szefa wymusza uprzejmość. Twój szef może dyplomatycznie wyjaśnić swój wybór na twój czas. Pokazuje również, że nie są tobą szefem. Kiedy po cichu rozwiązujesz ten problem z szefem, możesz usłyszeć takie słowa, jak „nie martw się, dostałem twoje plecy”. Skoncentruj się, stwórz produkt, przestaniesz mówić.

— DeveloperDon

@ thomas Zapytaj niewinnych oskarżonych, czy uczestniczą w niemoralnej zbrodni ....

— Mattnz

9

Organizacyjnie wyczuwam problem.

Istnieje hierarchia obejmująca szefa IT i twojego szefa. Jeśli Twoja organizacja jest tradycyjna (nie brzmi, jakby była zwinna), jesteś zasobem i to oni są menedżerami zasobów. Masz pełnoetatową pracę zwaną programowaniem. Jeśli użytkownicy końcowi bezpośrednio żądają funkcji, ustalają priorytety i próbują zarządzać czasem, menedżerowie są zbędni. Mogą być odpowiedzialni przed użytkownikami końcowymi, ale jeśli wykonują swoją pracę, jesteś odpowiedzialny przed nimi i muszą chronić cię przed wyjściem z trybu skoncentrowanego programisty do defensywnego trybu programistycznego .

Kilka punktów, aby ustawić kontekst mojej odpowiedzi:

Twórcy oprogramowania nie są podróżnikami w czasie, więc wyniki należy oceniać po tym, kim są, a nie tym, czym mogły być.
Jeśli funkcja była zgodna ze specyfikacją wymagań, harmonogramem i nadano jej priorytet nad ukończonymi pracami, może być uzasadniona skarga. W przeciwnym razie, jakie jest uzasadnienie pociągnięcia cię do odpowiedzialności?
Wasza kara, jeśli jest zasłużona, musi pochodzić z waszego łańcucha dowodzenia. Podobnie jak marketing i sprzedaż nie spodobałyby się, gdyby klienci skarcili rozwój produktu, większość organizacji ma menedżerów produktu, którzy otrzymują gniew klientów (i pochwały) i przekazują go kanałami.
Menedżerowie produktu mogą tworzyć niezwykle trudne relacje, jeśli pławią się w cieple udanych części projektów, ale złamią bicz tylko wtedy, gdy zmierzą się z programistami.
Jeśli dostarczyłeś funkcjonalny produkt z roczną pracą, a dodanie żądanej funkcji zajmuje miesiąc (lub dwa), z tego, co widziałem w naszej branży, twoje oszacowanie było powyżej średniej.
Rozwiązanie problemu w sposób uczciwy i produktywny wymaga, aby ludzie wrzucili winę z powrotem do kieszeni i opracowali plan.

Będziesz mógł wykonywać dużo lepszą pracę z lepszą motywacją, jeśli zostaniesz doceniony zamiast być kozłem w procesie, który powinien posiadać szef działu IT. To jest sprawiedliwy i produktywny sposób. Mam nadzieję, że będziesz zarządzany w ten sposób, a kiedyś w przyszłości, mam nadzieję, że będziesz zarządzał innymi w ten sposób.

— DeveloperDon
źródło

DevDon, chciałbym, żeby to była odpowiedź nr 1, ponieważ uważam, że jest to duża część naszego problemu ... nasza struktura IT dla tego scenariusza jest wyjątkowo przypadkowa. +1

— Użytkownik Smith

1

W przypadku takiej awarii rzeczywistości najlepiej jest iść naprzód. Zamiast kłócić się o przeszłość, porozmawiaj o tym, jak to działa i jak będzie to łatwe lub trudne. Naprawdę nie ma znaczenia, czy problem to naprawia, czy wdraża po raz pierwszy. Jeśli kierownictwo chce zrobić A przed B.

— ddyer
źródło

Oczywiście jest to prawda, ale gdy użytkownik końcowy dowie się, że może manipulować systemem w ten sposób, moja firma będzie miała poważne tendencje spadkowe, jeśli będzie to kontynuowane, ponieważ zasoby zostaną wykorzystane w ten sposób w porównaniu do ogólnego wykorzystania strategii firmy dyrektywy, które naprawdę napędzają wyniki firm.

— Użytkownik Smith

0

Czy jesteś jedynym twórcą, który pracował nad tym projektem? Wygląda na to, że odpowiedziałeś komuś podczas tworzenia projektu. Gdzie w tym wszystkim jest ta osoba? Gdzie jest dokumentacja projektu mówiąca, co zostało dostarczone?

Powinien istnieć ślad papieru dokumentowego. Dokument szkoleniowy pokazujący, jak korzystać z aplikacji. Funkcjonalna specyfikacja opisująca, co zostało opracowane. Jeśli funkcja nie została uwzględniona, powinna również zawierać dokumentację. Ktoś powinien był podpisać się, mówiąc, że to akceptuje.

To nie powinno być twoje słowo przeciwko ich, powinno to być wszystko w dokumentacji.

Jeśli nie masz tej dokumentacji ... obawiam się, że będziesz musiał ją ugryźć. Rozważ to jako lekcję życia. Ostatecznie użytkownicy są Twoimi klientami i jak mówi przysłowie: klient ma zawsze rację. Sprawdź, jak dodać tę funkcję i jak długo to potrwa. Spotkaj się i powiedz coś w stylu „Nasze dane wskazują, że ta funkcja nigdy nie została wdrożona, ale możemy ją uruchomić w ciągu x tygodni. Powinniśmy iść na głowę?

I z miłości do wszystkiego, co święte ... zdobądź dokumentację, której potrzebujesz, aby pokazać, że została zatwierdzona.

— Tyanna
źródło

Tak, byłem jedynym, który pracował nad tym projektem. Istnieje dokumentacja z codziennymi aktualizacjami, które nazwałem proofC w moim pytaniu.

— Użytkownik Smith

@UserSmith ~ Zrozumiałem to bardziej jako codzienną aktualizację statusu. To nie jest tak naprawdę dokumentacja, o której mówiłem. Czy ktoś podpisał się na produkcie końcowym? Czy istnieje szkolenie lub dokumentacja aplikacyjna, którą przekazałeś użytkownikowi końcowemu lub interesariuszowi?

— Tyanna,

Niestety nie. Był trening, ale bardzo krótki okres treningu. Istnieje dokumentacja aplikacji, ale nie obejmuje ona braku tej funkcji. Codzienne aktualizacje są w zasadzie narzędziem do dziennika, którego używamy do opisywania początkowych, codziennych i końcowych opisów tego, co stało się z projektem.

— Użytkownik Smith