Поэтому все функции системы в ТЗ должны быть описаны на русском языке. Хотят внедренцы сделать формализованное описание в терминах базового программного продукта – их право. Но при разрешении конфликтов определяющим должно быть словесное описание.
Готовность к созданию рабочей документации. Технический писатель. Сейчас для систем, которые продаются, какую-то эксплуатационную документацию худо-бедно делают. То есть документы, на титульном листе которых написано «Руководство пользователя» или «Руководство администратора», вам покажут. Только вам нужно сразу разобраться, не рекламные ли буклеты у вас в руках. Я однажды на рекламацию, что режим, описанный в руководстве, не работает, получил «тиражный» ответ разработчика: «Данная функциональность в системе предусмотрена, но еще не реализована».
Но все это верно именно для типовой, коробочной версии. Если систему дорабатывали по вашему заказу, то неплохо понять, есть ли надежда получить документацию, в точности соответствующую вашему релизу. Конечно, вы запишете это требование в договор или ТЗ, но будет неплохо, если вам еще покажут пальцем того сотрудника компании-внедренца, которому будет назначена роль технического писателя, а вы сможете убедиться, что этот человек в состоянии понятно писать на русском языке.
Я понимаю, что эффект от хорошего технического писателя у разработчика обычно смазывается отсутствием хорошего технического читателя у заказчика. Пусть так, но если сам разработчик поймет, что именно он сделал, то технический писатель свою миссию выполнил.
Кстати, помощь технического писателя в доводке системы бесценна. Мало того, что ему приходится пройтись по всему интерфейсу и выловить всех блох, пропущенных тестировщиками, он ведь еще выявляет все неописуемые элементы системы.
И вроде должно быть понятно: когда что-то работает так, что ни в сказке сказать, ни пером описать, это что-то надо переделать. Но объяснить это руководителю проекта, истекающему слюной по бонусу за закрытие этапа, удается чрезвычайно редко.
Личность демонстратора. Тестирование системы можно считать успешным, если человек, который показывает систему, вам совершенно несимпатичен, но система тем не менее вам нравится: бойтесь харизматиков, системы приносящих.
Как пытать разработчиков и внедренцев
Перечисленные ниже вопросы были сформулированы при поиске системы для торгового холдинга. Сформулированы давно, так что некоторые из них уже смотрятся диковато. Но менять я ничего не стал: все равно вы должны написать собственный список – я объект вашей автоматизации не изучал. Сделать это нужно заранее, до начала общения с продавцами программного обеспечения, так как каждый из них будет вешать вам на уши свою лапшу, а поскольку продают софт сейчас тоже профессионалы, очень может статься, что после квалифицированного общения вы «сами» решите, что перечень ваших требований совпадает с перечнем функций предлагаемой вам разработки. По той же причине посмотреть нужно существенно более одной системы.
Ответ на любой вопрос можно считать достоверным, если заявление представителей фирмы-разработчика подтверждается вашим тестированием системы или информацией независимых специалистов, которые эту систему эксплуатировали.
При общении с разработчиком нужно прежде всего определить уровень его понимания предметной области. Иногда у меня складывалось впечатление, что мы смотрим в одном направлении через очки с поляризованными в разных направлениях стеклами: там, где я видел стену, для них было чистое поле. Обращайте внимание на фразы типа «Ничего страшного, что в нашей системе товары считаются разными, если у них разные штриховые коды». Такие фразы показывают, что вместо подробного изучения реальной предметной области перед началом проектирования системы разработчики в основном ориентировались на придуманную ими модель, никак не связанную с реальной жизнью.
Если не очень понятно про штрихкоды.
Сигареты LM (красные) выпускаются по лицензии в сотне стран. Количество производителей в каждой стране может тоже измеряться десятками. Вся эта информация заложена в штрихкод (он же бар-код) стандарта EAN-13. Таким образом, количество различных штрихкодов для этого товара может доходить до нескольких тысяч. Но покупателя не волнует, какой штрихкод стоит на пачке сигарет. Как следствие, это не волнует ни мерчендайзера, который отвечает за наличие товара в зале, ни менеджеров, отвечающих за закупку этого товара и его доставку до магазина. Они все хотят видеть в информационной системе ровно одну строку, показывающую наличие товара в зале, на складе, в магазине и в пути. И цена продажи этого товара должна быть задана ровно одна. И если всех этих людей заставить работать с сотней строк вместо одной, то можно услышать о себе очень много интересного.
Достаточно много сил и времени при изучении каждой новой системы у вас уйдет на овладение языком, который в ней и вокруг нее используется. Я не про язык программирования. Я про ту версию русского языка, которая использовалась разработчиками. Как я уже написал, словарь разработчика меняется гораздо быстрее, чем его коды.
Однажды я даже получил официальное письмо на бланке с подписью и печатью, текст которого достоин опубликования:
«Доводим до вашего сведения, что с 01.01.2001 модуль Бухгалтерия называется Главная книга».
Без комментариев.
Ниже приводятся варианты толкования разработчиком некоторых терминов.
Логистика. Читаем в словаре: «Логистика – теория и практика управления материальными и информационными потоками в процессе товародвижения». Как дисциплина логистика занимается вопросами оптимизации при оформлении, перемещении и хранении товаров. В большинстве же систем модуль «Логистика» раньше назывался «Склад». Он считает складские остатки и ничего не оптимизирует. Но вам может встретиться и система, в которой модуль «Логистика» занимается учетом перевозок. И тоже ничего не оптимизирует.
Контрагент – лицо или учреждение, берущее на себя известные обязательства по договору. Это по словарю. Но в зависимости от системы справочником контрагентов будет называться либо справочник организаций, либо справочник (набор справочников), который используется в бухгалтерских и/или складских карточках и включающий как организации, так и физические лица, подразделения, темы и даже товары. Когда я попытался не так давно сам описать проект тиражируемой информационной системы, я обнаружил, что очень тяжело подобрать общее название для всех объектов и субъектов, фигурирующих, например, в договоре, накладной, платежном поручении (отправители, получатели, плательщики и т. п.) и в разрезе которых ведется материальный и аналитический бухгалтерский учет. Я бы назвал такие объекты фигурантами, но понимаю, что систему, где используется такая терминология, никто в России не купит.
Что интересно, в отечественных системах часто один справочник – «контрагенты», а в большинстве зарубежных – и «поставщики», и «подрядчики, и „перевозчики“, и т. п. Как следствие, ответ на вопрос „«кто сколько нам должен?“«получается не совсем очевидным… – Д. К.
Бухгалтерский учет—термин используется как для метода учета, описанного еще Пачоли и использующего двойную запись, так и для части учета, предназначенной для демонстрации налоговой службе, в противоположность управленческому учету. Как разработчики используют последний термин, тоже нужно разбирать особо. Во всяком случае фраза «Управленческий учет построен по принципам бухгалтерского учета» оказалась для некоторых разработчиков не такой ясной, какой представлялось мне.
А вот это исключительно наше изобретение. Во всех остальных странах управленческий учет – это не «черная касса», а просто более детализированный учет (в основном учет затрат и доходов). Управленческий учет в западном его понимании совсем не противоречит финансовому. – Д. К.
Кроме отдельных понятий оказывается смазанным также и смысл целых предложений. Высказывание «В системе поддерживаются стандарты бухгалтерского учета РСУ, IAS, GAAP» может означать:
1) что учет возможно организовать по любому из стандартов, но ровно по одному;
2) что, используя счета и проводки, сделанные по российским правилам, можно сваять отчет по IAS или какому-нибудь из GAAP;
3) что для одного из GAAP или для IAS используются свои счета и свои типовые хозяйственные операции.
Нет такого стандарта, как GAAP. То есть совсем нет. Многие страны именуют свои правила учета «общепринятыми» (то есть generally accepted, или GAAP), поэтому аббревиатура бессмысленна без указания страны, откуда родом стандарт (например, US GAAP). – Д. К.
