Zmieniamy świat klienta - jak sobie z tym poradzić?

Jakiś czas temu zlecono nam projekt polegający na zastąpieniu starego systemu mainframe klienta nowym intranetowym rozwiązaniem ASP.NET z wykorzystaniem SQL Server jako zaplecza. Częściowo było to również przeprojektowanie biznesu - w zasadzie, gdy zmieniamy system, mieliśmy myśleć o tym, jak lepiej prowadzić biznes.

Tak więc pierwszym zadaniem było przyjście i wykonanie logicznych, a następnie fizycznych modeli danych. Klient był w tych dyskusjach i całkowicie się podpisał. Następnym etapem było zaprojektowanie i zbudowanie każdego modułu. Krótko mówiąc, programowanie zostało zakończone i jesteśmy teraz w trakcie równoległych testów systemu. Jak dotąd wszystko układa się cudownie - z wyjątkiem jednego.

Mamy jeden system, w którym - gdybyś tylko pozwolił użytkownikom biznesowym zobaczyć aplikację i raporty, wszystko byłoby dobrze. Współpracuje z nowym zintegrowanym przepływem pracy i automatyzuje wcześniej ręczne procesy i działa doskonale zgodnie ze specyfikacjami. Testy równoległe ujawniły kilka problemów z migrowanymi starszymi danymi. Konstruktorom starszego systemu bardzo trudno jest zrozumieć nowy schemat i proces biznesowy, dlatego bardzo trudno jest im zrozumieć, w jaki sposób pobrać starsze dane i umieścić je w nowym schemacie. Z tego powodu dzwonią na spotkania użytkowników biznesowych i interesariuszy i mówią im, że nowy system nie zapewnia danych, które zrobił stary system (kiedy naprawdę to robi) - to sprawia, że ​​nowy system wygląda źle.

Jest to co najmniej frustrujące. Nowy system działa świetnie i zapewnia wszystko, czego potrzebują i czego potrzebują, a gdyby nie niezdolność personelu IT do wypełnienia nowych tabel starymi danymi, użytkownicy biznesowi byliby zadowoleni z nowych funkcji i funkcjonalności.

Proszę o sugestie, jak sobie z tym poradzić. Z powodu pewnych posunięć politycznych nowy „architekt” nie ma pojęcia o tym, jak działa system, i nie może w pełni zrozumieć konsekwencji zmian, o które prosi personel IT. Personel IT chce pewnych fundamentalnych zmian w systemie, które są w zasadzie niepotrzebne i faktycznie są złym projektem - ale są klientem.

jakieś pomysły?

Twój zespół musi dla nich przeprowadzić konwersję danych. Naprawdę powinieneś był to dla nich zrobić.

Byłem zaangażowany w wiele drogich migracje platformie i sprzedawca zawsze, zawsze ma swój własny zespół konwersji danych, którzy są odpowiedzialni za zrozumienie systemu starszego typu, pisząc wszystkie skrypty migracji, robi wszystkie testy i ogólnie upewniając się, że wszystko robi to, co powinien.

Niektóre firmy mogą mieć świetnych pracowników IT, którzy mogą to zrobić sami. Inni mogą twierdzić, że potrafią to zrobić sami, ale tak naprawdę nie mogą. W tym drugim przypadku musisz być na tyle pokorny, aby usiąść, ale także być przygotowany na zwiększenie sił, jeśli i kiedy zarząd zdecyduje, że wewnętrzny zespół nie wykonuje wystarczająco dobrej pracy.

To jest twój system i twoje wdrożenie. Ty i ty sam jesteś odpowiedzialny za upewnienie się, że się uda. Nie oczekuj, że klient będzie w stanie zrobić dowolną część tego samodzielnie. Tylko jeśli absolutnie nalegają na samodzielne wykonanie tej części, powinieneś nawet rozważyć tę opcję, a w takim przypadku musisz zakryć swoje tyłki - w umowie powinno być coś, co mówi, że jeśli zdecydują się to zrobić sami, są odpowiedzialni za wynik.

Mogą płacić za opiekę nad swoim zespołem, jeśli chcą, i mogą płacić za rozpoczęcie od nowa, jeśli chcą, ale nie marnuj niepotrzebnych cykli bez jakiejś umowy. Zwłaszcza jeśli masz umowę na czas określony lub umowę o stałych kosztach, ta sytuacja to śmierć.

Chodzi o to, jak mówisz, są oni klientem, co oznacza, że nie działają dla Ciebie. W rzeczywistości, jeśli jesteś cynikiem takim jak ja, możesz podejrzewać, że niektórzy z nich aktywnie działają przeciwko tobie, aby zachować bezpieczeństwo pracy. Powołując się na klienta, aby wykonać dowolną część swojej realizacji jest błędem.

Jeśli musisz zatrudnić kilku niewolników do wprowadzania danych za minimalną płacę, aby ręcznie przeprowadzić konwersję danych - zrób to. Wszystko, by oddać wynik z powrotem w twoje ręce.

To oni płacą rachunki, więc ostatecznie musisz dać im to, o co proszą, nawet jeśli nie byłoby to najlepsze rozwiązanie i krok wstecz.

Trzeba jednak wziąć pod uwagę, że być może ludzie, którzy używali komputera mainframe, mają rację. Moja żona pracowała w banku, w którym korzystała z systemu mainframe do przeprowadzania różnych transakcji finansowych przy użyciu setek różnych rodzajów kodów. Był to w zasadzie własny mini-język. Kiedy bank wydał miliony dolarów na wdrożenie systemu opartego na graficznym interfejsie użytkownika, co znacznie zmniejszyło złożoność i związane z tym kroki, odkrył później, że wydajność PLUMMETED i nigdy nie wróciła.

Faktem było, że chociaż system mainframe był niepotrzebnie skomplikowany i miał wysoką krzywą uczenia się, byli o wiele szybsi z nim niż system GUI, ponieważ byli biegli w dokonywaniu setek transakcji na godzinę, po prostu szybko wpisując na klawiaturze. Doprowadziło to do masowego odrzucenia przez bazę użytkowników, a projekt został złomowany jako kompletna porażka. Wydajność wróciła.

Morał polega na tym, aby nie lekceważyć obaw klientów. Potraktuj ich przemyślenia poważnie i zadaj sobie pytanie, czy oferowane rozwiązanie spełnia potrzeby WSZYSTKICH interesariuszy.

im, że nowy system nie dostarcza danych, które zrobił stary system (kiedy to naprawdę robi).

Powinieneś wziąć to BARDZO poważnie ...

Następnie:

1) Zapewnij kierownictwo, że współpracujesz ze starszymi facetami, aby rozwiązać wszystkie obawy.

2) Upewnij się, że w pełni rozumiesz, co ich zdaniem brakuje i dlaczego jest to potrzebne. Współpracuj ze starszymi facetami, aby to zapewnić. Następnie PONOWNIE WYDAJ problem i poproś, aby powiedzieli „Tak, to jest nasz problem”.

Jeśli zgadzasz się z tymi obawami, to:

3) Następnie zaproponuj rozwiązanie, poproś starsze zespoły o wprowadzenie \ sprawdzenie poprawności \ rozwiązania.

4) Postępuj zgodnie ze środkami zaradczymi.

Jeśli całkowicie nie zgadzasz się ze starszymi facetami i uważasz, że ich obawy są nieważne, to:

3) Wyraź swoje obawy związane z zarządzaniem w tym samym języku, który, jak twierdzili starsze osoby, był poprawny. I niech kierownictwo zdecyduje, gdzie powinieneś się tym zająć.

„Starsze chłopaki obawiają się, że XXX, nie jestem pewien, czy to problem z powodu YYY. Czy mają rację, jeśli chodzi o obawy?”

Sugeruję duży, paniczny e-mail, trafiający do wszystkich osób związanych nie tylko z zarządzaniem. Mów krótko i do rzeczy.
2 punkty:

1) Możemy zająć się twoimi obawami podczas spotkania / rozmowy telefonicznej (zaproponować czas)

2) Mamy pełne zaufanie do systemu, ponieważ jest on bez kłopotów i kosztów dodatkowych zmian

Wygląda na to, że masz listę ich problemów i możesz je omawiać punkt po punkcie na spotkaniu. Musisz tylko powstrzymać panikę, pozwolić im trochę ostygnąć, a następnie uderzyć ich prawdą. Nawet zaoferować przyjście i pomóc w mapowaniu starych danych na nowe. Jeśli nadal żądają zmian ... to ich pieniądze.

Po pierwsze, chcę podkreślić, że chociaż sekcja IT może być twoim interfejsem, prawdziwym klientem NIE JEST sekcja IT, ale firma, dla której sekcja IT działa. Robienie czegoś, co mogłoby zaszkodzić firmie, by uspokoić IT, nie byłoby dobrą usługą.

Nieformalnie usiądź przy IT. Kup im pączki. Weź rolę ucznia do nauczyciela i zapytaj: „Co jest nie tak z naszym oprogramowaniem?” Słuchaj zarówno tego, co mówią, jak i tego, czego nie mówią. Mogą mieć punkt, który został pominięty w oryginalnych specyfikacjach lub mieć obawy związane z przeszłymi problemami. Z drugiej strony mogą reagować ze strachu przed czymś nowym. Chodzi o to, że jeśli dokładnie znasz ich zarzuty, jesteś w lepszej pozycji, aby osiągnąć pozytywny wynik i odpowiedzieć na ich zastrzeżenia.

Wspomniałeś, że problemem była migracja danych ze starszego systemu do nowego systemu. Jeśli w dziale IT występuje problem z migracją danych, rozważę zbudowanie małego narzędzia do szybkiego i czystego działania.

Skonsultuj się z personelem IT twojego klienta w celu wsparcia migracji starych danych do nowego systemu. Ktoś z Twojej firmy, który rozumie nowy format danych, powinien po prostu tam pójść i pomóc pracownikom IT w migracji.

W ten sposób mamy nadzieję, że mogą nauczyć informatyków o nowym systemie, dane są migrowane poprawnie, a wdrożenie przebiega sprawniej.