Записки автоматизатора. Профессиональная исповедь
Шрифт:
Как истинный ретроград, я предпочитаю смотреть на модель «сущность-связь» (ER-модель), но годится и любая другая общеизвестная модель, лишь бы она была описана в литературе, а не придумана самими разработчиками.
Документы внедренца: стандарты предприятия на предпроектное обследование организации и внедрение информационной системы. Как и в предыдущих случаях, главное, чтобы документы были. Думаю, по их прочтении вы легко поймете и интеллектуальный уровень компании, с которой вы собираетесь связаться, и ее багаж, накопленный при предыдущих внедрениях. А вот отсутствие типового плана внедрения иногда приводит к интересным последствиям: я сам столкнулся с ситуацией, в которой внедренцы забыли, что «нарезка» 80
Многие западные системы поставляются с «готовой» методологией внедрения (фактически это перечень шагов развертывания системы в идеальном мире, некий «сферический конь в вакууме»). Частью таковой обычно является и типовой план, выглядящий примерно так:
1. Продажа лицензий и установка системы (конечно же, самый главный и своевременный этап);
2. Обучение;
3. Концептуальное понимание;
4. Функциональное описание;
5. Разработка;
6. Внедрение;
7. До свидания.
Конечно же, хорошо, что типовой план существует, но про время на настройку восьмидесяти видов рабочих мест я бы уточнил дополнительно…
Также в методологиях поставщика никак не предполагается то, что система будет внедряться на месте старой, что потребуется переносить данные, что данные эти в различных модулях не должны противоречить друг другу и что система должна как-то жить в переходный период… Ну, собственно, поэтому нас и нанимают… – Д.К.
«У нас свои средства описания проекта». На первый взгляд, ничего особо страшного. Только в этом случае вы сами уже не сможете понять, что же при обследовании поняли внедренцы, использовавшие эти средства. Еще хуже, когда это описание попало в ТЗ: когда вы при приемке системы начнете возмущаться, что система не делает половину того, что было обещано, а вторую половину делает, но не так, как это принято в вашей организации, вам покажут ТЗ и скажут, что сделано ровно то, что заказано.
Поэтому все функции системы в ТЗ должны быть описаны на русском языке. Хотят внедренцы сделать формализованное описание в терминах базового программного продукта – их право. Но при разрешении конфликтов определяющим должно быть словесное описание.
Готовность к созданию рабочей документации. Технический писатель. Сейчас для систем, которые продаются, какую-то эксплуатационную документацию худо-бедно делают. То есть документы, на титульном листе которых написано «Руководство пользователя» или «Руководство администратора», вам покажут. Только вам нужно сразу разобраться, не рекламные ли буклеты у вас в руках. Я однажды на рекламацию, что режим, описанный в руководстве, не работает, получил «тиражный» ответ разработчика: «Данная функциональность в системе предусмотрена, но еще не реализована».
Но все это верно именно для типовой, коробочной версии. Если систему дорабатывали по вашему заказу, то неплохо понять, есть ли надежда получить документацию, в точности соответствующую вашему релизу. Конечно, вы запишете это требование в договор или ТЗ, но будет неплохо, если вам еще покажут пальцем того сотрудника компании-внедренца, которому будет назначена роль технического писателя, а вы сможете убедиться, что этот человек в состоянии понятно писать на русском языке.
Я понимаю, что эффект от хорошего технического писателя у разработчика обычно смазывается отсутствием хорошего технического читателя у заказчика. Пусть так, но если сам разработчик поймет, что именно он сделал, то технический писатель свою миссию выполнил.
Кстати, помощь технического писателя в доводке системы бесценна. Мало того, что ему приходится пройтись по всему интерфейсу и выловить всех блох, пропущенных тестировщиками, он ведь еще выявляет все неописуемые элементы системы.
И вроде должно
Личность демонстратора. Тестирование системы можно считать успешным, если человек, который показывает систему, вам совершенно несимпатичен, но система тем не менее вам нравится: бойтесь харизматиков, системы приносящих.
Перечисленные ниже вопросы были сформулированы при поиске системы для торгового холдинга. Сформулированы давно, так что некоторые из них уже смотрятся диковато. Но менять я ничего не стал: все равно вы должны написать собственный список – я объект вашей автоматизации не изучал. Сделать это нужно заранее, до начала общения с продавцами программного обеспечения, так как каждый из них будет вешать вам на уши свою лапшу, а поскольку продают софт сейчас тоже профессионалы, очень может статься, что после квалифицированного общения вы «сами» решите, что перечень ваших требований совпадает с перечнем функций предлагаемой вам разработки. По той же причине посмотреть нужно существенно более одной системы.
Ответ на любой вопрос можно считать достоверным, если заявление представителей фирмы-разработчика подтверждается вашим тестированием системы или информацией независимых специалистов, которые эту систему эксплуатировали.
При общении с разработчиком нужно прежде всего определить уровень его понимания предметной области. Иногда у меня складывалось впечатление, что мы смотрим в одном направлении через очки с поляризованными в разных направлениях стеклами: там, где я видел стену, для них было чистое поле. Обращайте внимание на фразы типа «Ничего страшного, что в нашей системе товары считаются разными, если у них разные штриховые коды». Такие фразы показывают, что вместо подробного изучения реальной предметной области перед началом проектирования системы разработчики в основном ориентировались на придуманную ими модель, никак не связанную с реальной жизнью.
Если не очень понятно про штрихкоды.
Сигареты LM (красные) выпускаются по лицензии в сотне стран. Количество производителей в каждой стране может тоже измеряться десятками. Вся эта информация заложена в штрихкод (он же бар-код) стандарта EAN-13. Таким образом, количество различных штрихкодов для этого товара может доходить до нескольких тысяч. Но покупателя не волнует, какой штрихкод стоит на пачке сигарет. Как следствие, это не волнует ни мерчендайзера, который отвечает за наличие товара в зале, ни менеджеров, отвечающих за закупку этого товара и его доставку до магазина. Они все хотят видеть в информационной системе ровно одну строку, показывающую наличие товара в зале, на складе, в магазине и в пути. И цена продажи этого товара должна быть задана ровно одна. И если всех этих людей заставить работать с сотней строк вместо одной, то можно услышать о себе очень много интересного.
Достаточно много сил и времени при изучении каждой новой системы у вас уйдет на овладение языком, который в ней и вокруг нее используется. Я не про язык программирования. Я про ту версию русского языка, которая использовалась разработчиками. Как я уже написал, словарь разработчика меняется гораздо быстрее, чем его коды.
Однажды я даже получил официальное письмо на бланке с подписью и печатью, текст которого достоин опубликования:
«Доводим до вашего сведения, что с 01.01.2001 модуль Бухгалтерия называется Главная книга».
Без комментариев.