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

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.

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.)

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.

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.

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.

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.