Внедрение решений

Я для себя задачу разбиваю на несколько частей.

1. Проектирование.
Правильное построение структуры базы данных обеспечит вас тишиной и спокойствием на долгие месяцы. Не говоря о том, что сильно сократит размер базы и обеспечит такие реляции, с которыми вам не придется вычищать базу вручную после месяца непрерывной работы.
2. Базовый ввод, математика.
Нельзя начать задачу с отчетов. Нужно сделать формы ввода, построить расчетные алгоритмы (если нужны). На этом этапе интерфейс еще не нужен, нужна рыба, которую вы потом будете зачищать.
3. Отчеты, вылизывание форм.
Отработка интерфейса под пользователя.
4. Навороты.
Иногда пользователь просит сделать ему систему безопасности, некие аналитические материалы, поиск ошибок ввода. Также контроль ввода, инсталляционную версию, репликацию данных на другие компьютеры и пр. Здесь фантазия ничем не сдерживается, но не стоит и увлекаться.
5. Обучение персонала.
Спать в офисе еще ни разу не приходилось. Максимум полдня. В большинстве случаев удавалось создать такой интерфейс, что называется "сел и поехал". Тем более, что большинство задач все равно оставалось в руках более опытных пользователей (не рядовых юзеров).
6. Тестовый (боевой) запуск.
Отказ от старой программы и переход на новую или внедрение новой сразу. Иногда весьма болезненная процедура.

С чего следует начать? С поддержки руководства. Везде, где мои программы внедрены и работают, они были
а) Востребованы.
б) Поддержаны непосредственным руководством.
Где было а), но не было б) внедрения не будет. Опытом доказано, что среднее звено (собственно, кто осуществляет базовый ввод) всегда против. Любая попытка заставить работать их с чем-то сложнее Excel наткнется на откровенное противодействие, переходящее в ненависть и "на фиг оно мне надо". Единственный способ сломить сопротивление, это грозное лицо директора и фраза из его уст, обращенная к данному работнику "Вам придется с этим работать". Только тогда начинается взаимодействие и взаимопонимание.

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

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

Вернемся к внедрению. Программа, написана, отчасти вылизана. Начинается этап тестинга. НИКОГДА вы не сможете найти и устранить все глупости и недостатки сами. Просто вы смотрите с одной стороны, а заказчик с  другой. Вам удобно переключать раскладку, а заказчик путается. Вам легко двигаться по полям с помощью Tab, а пользователь переходит с помощью мышки или Enter... Вы по-разному смотрите на программу и так будет всегда. Решение: у вас есть тестер - дайте программу ему. У меня тестера нет, мои программы тестируются в боевом режиме и часто доставляют немало неприятных минут пользователям. Иногда они даже привыкают к проблемам и считают, что танцы с бубном (нажать туда-сюда) надо делать даже тогда, когда проблема устранена.

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

Если хотите до конца довести внедрение программы, она должна обладать некоторыми особенностями: доведенный до конца интерфейс для пользователей и несколько отчетов для руководителей. Зачем нужно последнее: вы должны показать директору, что программа ему нужна, что с ее помощью он получает доступ к информации, что у него на экране РЕАЛЬНАЯ ситуация и ему не нужно просить секретаря или бухгалтера подготовить отчет. Отсюда увеличивается востребованность в программе со стороны руководства.

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

Первый месяц вы только и будете, что исправлять свои огрехи. То, как быстро вы будете это делать решит исход в вашу пользу. Делайте программу с запасом прочности:
- создавайте такой интерфейс, переходы по которому можно объяснить по телефону;
- резервные копии, минимум раз в сутки, лучше если копии будут иметь комбинированные имена "имя-время-дата.mdb";
- решение одной и той же проблемы двумя и более путями, заблокирован/развалился один, переключить пользователя на другой;
- установка на более чем один компьютер может принести положительный результат, если одному пришел конец, то можно быстро решить проблему доступа пересадкой юзера на другой компьютер, а утром придете вы и исправите все.)

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

Умейте одернуть слишком ретивого клиента. Часть проблем НЕ ИМЕЕТ ПРОСТОГО решения. И создавать решения, ведущие к усложнению хорошо работающей структуры - хуже некуда. Лучше обойти проблему другим путем, чем создать сложную надстройку, которая будет банить весь проект. К таким проблемам относится: безопасность данных, разделение доступа, вывод и чтение данных в другие приложения (Word, Excel, 1C) и др. Почему я их туда отношу, когда есть стандартные подходы (группы, макросы, слияние). Да потому что зачастую в рамках стандартного подхода не получить нужного результата. Значит над группами придется построить свою надстройку, которая будет контролировать не формы, а, например, кнопки. Или написать функцию, которая будет выводить таблицу в Word. В общем и целом неоправданный расход времени, потому что пароли одного все равно будет знать весь отдел, а таблицы в Word выводят только для того, чтобы раз в месяц их отпечатать и сохранить в папке. В первом случае можно сделать просто пароль на вход, а во втором хранить снимки snp.