Изменился мир клиента - как мы справимся с этим?

Некоторое время назад нам было поручено войти в проект и заменить старую систему Mainframe клиента новым решением ASP.NET для интрасети, использующим SQL Server в качестве серверной части. Частично это было реинжинирингом бизнеса - по сути, когда мы меняли систему, мы должны были думать о том, как мы можем лучше вести бизнес.

Итак, первая задача состояла в том, чтобы прийти и выполнить логические, а затем физические модели данных. Заказчик участвовал в этих высказываниях и получил полную подпись. Следующим этапом было фактически сделать проектирование и сборку каждого модуля. Короче говоря, программирование завершено, и сейчас мы приступаем к параллельному тестированию системы. Пока что дела идут отлично для большинства модулей - кроме одного.

У нас есть одна система, где - если бы вы только позволили бизнес-пользователям видеть приложение и отчеты, все было бы хорошо. Он работает с новым интегрированным рабочим процессом, автоматизирует ранее ручные процессы и отлично работает в соответствии со спецификациями. Параллельное тестирование выявило несколько проблем, связанных с перенесенными устаревшими данными. Разработчикам унаследованной системы очень трудно понять новую схему и бизнес-процесс, поэтому им очень трудно понять, как взять устаревшие данные и поместить их в новую схему. Из-за этого они созывают встречи бизнес-пользователей и заинтересованных лиц и говорят им, что новая система не предоставляет данные, которые старая система предоставляла (когда это действительно происходит) - это действительно делает новую систему плохой.

Это расстраивает, если не сказать больше. Новая система прекрасно работает и предоставляет все, что им нужно и нужно, и если бы не неспособность ИТ-персонала заполнить новые таблицы старыми данными, бизнес-пользователи были бы довольны новыми функциями и функциями.

Я прошу предложения о том, как справиться с этим. Из-за некоторых политических шагов новый «архитектор» не имеет представления о том, как работает система, и не может полностью понять последствия изменений, которые запрашивает ИТ-персонал. ИТ-персонал хочет фундаментальных изменений в системе, которые по сути не нужны и на самом деле являются плохим дизайном, но они являются заказчиком.

Какие-нибудь мысли?

Ваша команда должна сделать преобразование данных для них. Вы действительно должны были сделать это для них в первую очередь.

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

Некоторые компании могут иметь блестящих ИТ-специалистов, которые могут сделать это сами. Другие могут утверждать, что могут сделать это сами, но на самом деле не могут. В последнем случае вы должны быть достаточно скромными, чтобы сидеть сложа руки, а также быть готовыми подойти, если и когда руководство решит, что внутренняя команда не выполняет достаточно хорошую работу.

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

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

Дело в том, что, как вы говорите, они являются клиентами, а это значит, что они не работают на вас. На самом деле, если вы такой же циник, как я, вы можете заподозрить, что некоторые из них активно работают против вас, чтобы сохранить безопасность своей работы. Довериться клиенту выполнить любую часть вашего внедрения - ошибка.

Если вам нужно нанять пару подчиненных для ввода данных с минимальной заработной платой, чтобы выполнить преобразование данных вручную - сделайте это. Что угодно, чтобы вернуть результат в ваши руки.

Именно они оплачивают счета, поэтому в конце концов вы должны дать им то, о чем они просят, даже если это не будет лучшим решением и шагом назад.

Однако вы должны учитывать, что, возможно, люди, которые использовали мэйнфрейм, имеют смысл. Моя жена работала в банке, где она использовала какую-то систему мэйнфреймов для ввода различных финансовых транзакций, используя сотни различных типов кодов. По сути, это был собственный мини-язык. Когда банк потратил миллионы долларов на внедрение системы на основе графического интерфейса, которая значительно уменьшила сложность и связанные с этим шаги, позже они обнаружили, что производительность упала и больше не поднималась.

Дело в том, что, хотя система мэйнфреймов была излишне сложной и имела высокую кривую обучения, они были НАМНОГО быстрее с ней, чем система с графическим интерфейсом, потому что они стали искусными при вводе сотен транзакций в час, просто набирая текст быстро на клавиатуре. Это привело к массовому отказу со стороны пользователей, и проект был свернут как полный провал. Производительность вернулась.

Мораль в том, что не стоит полностью игнорировать проблемы клиентов. Относитесь серьезно к их соображениям и спросите себя, соответствует ли решение, которое вы предлагаете, потребностям ВСЕХ заинтересованных сторон.

им, что новая система не предоставляет данные, которые старая система сделала (когда это действительно делает).

Вы должны принять это очень серьезно ..

Затем:

1) Убедить руководство, что вы работаете с парнями из Legacy, чтобы решить все возникающие проблемы.

2) Убедитесь, что вы полностью понимаете, чего они говорят, чего не хватает и зачем это нужно. Работайте с прежними парнями, чтобы застраховать это. Затем восстановите проблему и попросите их сказать: «Да, это наша забота».

Если вы согласны с этими проблемами, то:

3) Затем предложите решение, получите входные данные \ проверки старых команд для решения.

4) Приступить к корректирующим мерам.

Если вы полностью не согласны с ребятами из Legacy и считаете, что их опасения недействительны, то:

3) Выразить обеспокоенность руководства, используя тот же язык, который, по словам Наследников, был верным. И пусть руководство решит, где вы должны быть обеспокоены этим.

«Старые парни боятся, что XXX, я не уверен, что это проблема из-за YYY. Они правы в этом вопросе?»

Я предлагаю большую душераздирающую электронную почту, поражающую всех, кто связан не только с их управлением. Держите это коротким и к сути.
2 балла:

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

2) У нас есть полная уверенность в системе , как это без хлопот и расходов дополнительных изменений

Похоже, у вас есть список их проблем, и вы можете обсудить их по пунктам на собрании. Вам просто нужно остановить панику, дать им немного остыть, а затем ударить их правдой. Даже предлагают прийти и помочь с отображением старых данных в новые. Если они все еще требуют изменений ... ну, это их деньги.

Во-первых, я хочу отметить, что, хотя раздел ИТ может быть вашим интерфейсом, реальный клиент - это НЕ раздел ИТ, а бизнес, для которого работает раздел ИТ. Делать что-то, чтобы повредить бизнесу, чтобы успокоить ИТ, не будет хорошим обслуживанием.

Сядьте с ЭТОМ, неофициально. Купи им пончики. Отнесите роль ученика своему учителю и спросите: «Что плохого в разработке нашего программного обеспечения?» Послушайте, что они говорят и что не говорят. У них может быть пункт, который был упущен в исходных спецификациях или проблемы, основанные на прошлых проблемах. С другой стороны, они могут реагировать из-за страха перед чем-то новым. Но дело в том, что если вы хорошо знаете их возражения, вы в лучшем положении, чтобы добиться положительного результата и ответить на их возражения.

Вы упомянули, что проблема заключалась в переносе данных из прежней системы в новую. Если в ИТ-отделе возникли проблемы при переносе данных, я бы подумал о том, чтобы создать их как небольшой инструмент для быстрой и аккуратной работы.

Проконсультируйтесь с ИТ-персоналом вашего клиента, чтобы поддержать перенос старых данных в новую систему. Кто-то из вашей фирмы, который понимает новый формат данных, должен физически просто пойти туда и помочь ИТ-специалистам выполнить миграцию.

Таким образом, мы надеемся, что они смогут рассказать ИТ-специалистам о новой системе, данные будут перенесены правильно, и ваша реализация пройдет более гладко.