Змінено світ клієнта - як ми з цим справляємося?

Деякий час тому перед нами було поставлено завдання прийти і замінити стару систему клієнта Mainframe на нове рішення для внутрішньої мережі ASP.NET, використовуючи SQL Server в якості зворотного кінця. Частиною цього було також перепрофілювання бізнесу - по суті, коли ми змінюємо систему, ми повинні були думати про те, як ми можемо краще вести бізнес.

Отже, першим завданням було зайти і зробити логічну, а потім фізичну модель даних. Замовник був у цих дискусіях і мав повний вихід. Наступним етапом було власне проектування та побудова кожного модуля. Ну, якщо коротко сказати, програмування було зроблено, і ми зараз проводимо паралельне тестування системи. На сьогоднішній день у більшості модулів - крім одного.

У нас є одна система, де - якби ви дозволяли лише діловим користувачам бачити додаток та звіти, все було б добре. Він працює з новим інтегрованим робочим процесом і автоматизує раніше ручні процеси та чудово відповідає технічним умовам. Паралельне тестування виявило декілька проблем, хоча і з перенесеними застарілими даними. Будівельникам застарілої системи дуже важко зрозуміти нову схему та бізнес-процес, тому їм дуже важко зрозуміти, як приймати застарілі дані та вносити їх у нову схему. Через це вони викликають зустрічі ділових користувачів та зацікавлених сторін і кажуть їм, що нова система не надає даних, які мала стара система (коли це дійсно так) - це робить нову систему поганою.

Це, найменше, засмучує. Нова система працює чудово і забезпечує все необхідне та бажане, і якби не неможливість працівників ІТ заповнити нові таблиці старими даними, ділові користувачі були б задоволені новими можливостями та функціональністю.

Я прошу пропозиції, як з цим впоратися. Через деякі політичні кроки новий "архітектор" не має уявлення про те, як працює система, і не може повністю зрозуміти наслідки змін, про які вимагає ІТ-персонал. ІТ-персонал бажає кардинальних змін у системі, які по суті є непотрібними і насправді є поганою конструкцією - але вони є замовником.

Будь-які думки?

Вашій команді необхідно здійснити перетворення даних для них. Ви дійсно повинні були зробити це для них в першу чергу.

Я брав участь в ряді дорогих міграції платформи і постачальника завжди, завжди має свою власну команду перетворення даних , які відповідають за розуміння успадкованої системи, записуючи все сценарії міграції, роблячи все випробування, і , як правило , переконавшись , що все робить те, що належить.

У деяких компаніях може бути блискучий ІТ-персонал, який може це зробити самостійно. Інші можуть стверджувати, що можуть це зробити самі, але насправді не можуть. В останньому випадку вам потрібно бути досить покірними, щоб сидіти, а також бути готовим активізувати, якщо і коли керівництво вирішило, що внутрішня команда не виконує достатньо хорошої роботи.

Це ваша система та ваша реалізація. Ви і ви самі несете відповідальність за те, щоб переконатися, що це успішно. Не сподівайтеся, що замовник зможе зробити будь-яку частину цього самостійно. Тільки якщо вони абсолютно наполягають на виконанні цієї частини самі, якщо ви навіть розглядаєте цей варіант, і в такому випадку вам потрібно прикрити свої недопалки - у договорі повинно бути щось, що говорить, що якщо вони вирішать це зробити самі, то вони несуть відповідальність для її результату.

Вони можуть заплатити вам за няню своєї команди, якщо вони захочуть, і вони можуть вам заплатити, щоб почати все спочатку, якщо вони захочуть, але не витрачайте зайві цикли без будь-якої згоди. Особливо, якщо ви укладаєте контракт із обмеженим часом або фіксованою вартістю, ця ситуація є смертю.

Справа в тому, що, як ви кажете, вони є замовником, а це означає, що вони не працюють на вас. Насправді, якщо ви такий цинік, як я, ви можете підозрювати, що деякі з них активно працюють проти вас, щоб утримувати свою безпеку на роботі. Покладатися на замовника, щоб виконати будь-яку частину вашої реалізації - це помилка.

Якщо вам потрібно найняти пару рабів введення даних з мінімальною заробітною платою, щоб зробити перетворення даних вручну - зробіть це. Все, щоб повернути результат у ваші руки.

Вони платять рахунки, тож, зрештою, ви повинні дати їм те, що вони просять, навіть якщо це не буде найкращим рішенням і кроком назад.

Однак ви повинні врахувати, що, можливо, люди, які використовували мейнфрейм, мають своє значення. Моя дружина працювала в банку, де вона використовувала певну систему мейнфреймів для введення різних фінансових операцій, використовуючи сотні різних типів кодів. По суті це була своя міні-мова. Коли банк витратив мільйони доларів на впровадження системи на основі графічного інтерфейсу, яка значно знизила складність та пов'язані кроки, пізніше вони виявили, що продуктивність РОЗВ'ЯЗАНА і ніколи не знижується.

Справа в тому, що в той час як система мейнфреймів була надмірно складною і мала високу криву навчання, вони були МНОГО швидше, ніж система GUI, тому що вони стали майстерними при введенні сотень транзакцій на годину, просто набравши швидко клавіатуру. Це призвело до масового відмови від користувальницької бази, і проект був скреслений як повний провал. Продуктивність повернулася.

Мораль полягає в тому, що не повністю відкидайте проблеми клієнтів. Поставтеся до їх серйозних міркувань і запитайте себе, чи пропонується вами рішення відповідає потребам ВСІХ зацікавлених сторін.

їм, що нова система не надає даних, які мала стара система (коли це дійсно є).

Ви повинні сприймати це ДУЖЕ серйозно ..

Тоді:

1) Запевняйте, що керівництво працює з хлопцями Legacy, щоб вирішити всі проблеми.

2) Будьте впевнені, що ви повністю розумієте, чого вони говорять, чого немає, і чому це потрібно. Попрацюйте зі спадщинами, щоб забезпечити це. Потім ВИДАЛИТИ Випуск, і скажіть їм: Так, це наше питання.

Якщо ви погоджуєтесь з проблемами, то:

3) Потім запропонуйте рішення, отримайте застарілі команди введення \ перевірку на \ рішення.

4) Приступайте до виправних заходів.

Якщо ви повністю не погоджуєтесь із хлопцями Legacy, і вважаєте, що вони викликають занепокоєння, тоді не вірно:

3) Висловіть, що стосується менеджменту, використовуючи ту саму мову, про яку сказали хлопці зі спадщини, що вона правильна. І попросіть менеджмент вирішити, чи не слід цим займатися.

"Хлопці, які пережили спадщину, бояться, що XXX, я не впевнений, що це проблема через YYY. Чи правильно вони турбуються?"

Я пропоную великий електронний лист з панікою, що вражає всіх, хто пов'язаний не лише з їх управлінням. Тримайте його коротко і до суті.
2 бали:

1) Ми можемо вирішити ваші проблеми під час зустрічі / телефонного дзвінка (запропонувати час)

2) Ми маємо повну довіру до системи, як вона без клопоту та витрат на додаткові зміни

Здається, у вас є перелік їх проблем, і ви можете опустити їх по пункту на засіданні. Вам просто потрібно припинити паніку, дати їм трохи охолонути, а потім вдарити їх правдою. Навіть пропонують зайти і допомогти зіставлення старих даних на нові. Якщо вони все-таки вимагають змін ... ну це їх гроші.

По-перше, хочу зазначити, що хоча ІТ-розділ може бути вашим інтерфейсом, справжній клієнт - це не ІТ-розділ, а бізнес, над яким працює ІТ-секція. Робити щось, щоб зашкодити бізнесу, щоб заспокоїти ІТ, не було б гарною послугою.

Сідайте з ІТ, неофіційно. Купуйте їм пончики. Візьміть роль учня у свого викладача і запитайте "Що не так у нашій розробці програмного забезпечення?" Послухайте і те, що вони говорять, і те, що вони не говорять. Вони можуть мати точку, яка була пропущена в оригінальних технічних характеристиках, або має занепокоєння на основі минулих питань. Потім знову вони можуть реагувати через страх перед чимось новим. Але суть полягає в тому, що якщо ви глибоко знаєте їх заперечення, ви в кращому положенні зробити позитивний результат та відповісти на їх заперечення.

Ви згадали, що проблема полягала в міграції даних із застарілої системи до нової. Якщо в ІТ-секції виникають проблеми з переміщенням даних, я б розглядав можливість створення їх невеликим інструментом, щоб зробити це швидко та чисто.

Зверніться до ІТ-персоналу свого клієнта, щоб підтримати міграцію старих даних до нової системи. Хтось із вашої фірми, який розуміє новий формат даних, повинен фізично просто зайти туди і допомогти ІТ-хлопцям зробити міграцію.

Таким чином, сподіваємось, вони зможуть навчити ІТ-хлопців про нову систему, дані мігруються правильно, а ваша реалізація проходить більш плавно.