В долгах как в шелках. Рост рынка потребительского кредитования. Правила денег от Уоррена Баффета, инвестора №1 в мире.

Если вы еще не документируете свои программы...

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

Если Вы хотите держать ситуацию под контролем, то заинтересуйте пользователей хорошей документацией (ее написание — отдельная тема). В банке отдел автоматизации не может заниматься только тем, что ему самому кажется правильным, а должен делать то, что нужно банку. Политически важно убедить пользователей, что появление документации решит их проблемы, связанные с эксплуатацией программ.

Как заинтересовать пользователей в документации? Для начала можно сделать несколько небольших (8—10 страниц) документов, описывающих наиболее используемые функции программ (например, ввод и печать платежного поручения, контроль платежных поручений и т. д.). Помните, что чем длиннее документ, тем меньше вероятность, что его дочитают до конца. Старайтесь создать прежде всего краткий, ясный и точный документ и, конечно, полезный пользователям. Раздайте его сотрудникам бизнес-подразделений. Покажите, что лучше потратить полчаса на чтение документа, чем без конца звонить. Постарайтесь получить от этих сотрудников критические замечания на документы. Потребуйте, чтобы в отделе автоматизации в ответ на звонки пользователей звучали слова: «А об этом написано в таком-то документе». Другими словами, создайте прецедент успешного применения документации. Не отделывайтесь формальными отписками, постарайтесь встать на место пользователя и дайте ему необходимые сведения. Если Вы все сделали правильно, то в скором времени от отдела автоматизации могут потребовать документацию на новые программы. В дальнейшем заказы на разработку документации должны исходить от бизнес-подразделений.

Инициатива наказуема исполнением

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

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

Замечено, что хорошие программисты, разрабатывающие свои программы аккуратно и тщательно, как правило, хорошо (ясно, просто, полно) описывают возможности программ. Еще раз убеждаешься: кто ясно мыслит, тот ясно излагает. При чтении бестолковых документов, создается впечатление, что и программа написана в аналогичном стиле (это часто подтверждается на практике). Объяснение данного явления заключается, мне кажется, в уровне общей культуры человека. Один думает о других, ставит себя на место пользователя и пишет программы и документы так, что испытываешь радость от их использования и чтения. Другой возгорается страстью к написанию кода и творит вещь в себе, да еще и составляет описание, в котором понять что-либо очень трудно («мои мысли — мои скакуны»).

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

Документирование — это учет и контроль

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

На этапе выверки сотрудник, ответственный за ведение документации, должен добиться, чтобы документ был прочитан людьми, компетентными и способными высказать замечания, а автор внес изменения в документ по их замечаниям. Для особенно важных (системообразующих) документов в выверке могут принять участие руководители бизнес-подразделений. Обычно показателем хорошей выверки может служить число передач редакций документа автором на проверку экспертам. Если была всего одна итерация, то, возможно, эксперты формально отнеслись к проверке. Если число итераций превысило пять, то следует разобраться, почему процесс не становится сходящимся: то ли автор не понимает сути предъявляемых замечаний, то ли эксперты (или автор) хотят совершенствовать документ до бесконечности. Последняя ситуация может возникнуть, когда разработка пользовательской документации стала привычным делом и у авторов появляется желание выпустить «выдающийся» документ. Такое желание похвально, но не следует перегибать палку. Исключение подобных ситуаций также входит в компетенцию сотрудника, занимающегося документацией. Практика показывает, что «нормальным» можно считать число итераций от двух до четырех. В течение такой выверки документ успевает лишиться явных ляпов и приобретает черты полноценного завершенного продукта.

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

Порядок выпуска (утверждения) документов также определяется в каждом банке самостоятельно. Полезно привлекать сотрудников подразделений-пользователей к выпуску документов (например, требовать подпись на листе утверждения). Во-первых, руководство подразделений банка увидит, что отдел автоматизации занят работой, в которой заинтересованы бизнес-подразделения, во-вторых, участие пользователей дает уверенность, что разрабатываются действительно нужные документы.

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

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

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

Автора, автора!

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

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

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

Лучше мало и сейчас, чем много, но потом

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

...И опыт — сын ошибок трудных...

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

Искусство ради искусства или...

Пользователи читать документацию не любят. Это факт. Многим действительно легче позвонить и сделать что скажут.

Если, разрабатывая пользовательскую документацию, вы не добьетесь того, чтобы ее читали, то вся работа бессмысленна. Если есть документ, в котором находятся необходимые сведения, то следует его читать. Контакты бухгалтеров и экономистов с программистами ничем не должны отличаться от контактов пользователей «коробочных» продуктов с их производителями. Сотрудников банка, думающих, что вокруг них будет суетиться весь отдел автоматизации только потому, что им «некогда» (а скорее всего лень) прочитать документ, следует просвещать и объяснять некорректность занимаемой ими позиции. «Написать легко, а сделать...» — скажете вы. Поверьте, со временем подобный ликбез принесет свои плоды. То, что отдел автоматизации работает только для банка, не является основанием для развития «свойских» отношений с подразделениями-пользователями. Банк заинтересован в ситуации, когда пользователи будут воспринимать отдел автоматизации как «внешнего» поставщика со всеми вытекающими последствиями (документация, техническая поддержка и т. д.). От него можно и должно потребовать всего того, что бы сделал сторонний поставщик, и пользователи должны это понимать. Добейтесь, чтобы документация стала для пользователей естественным источником информации о программе.

Если на клетке со львом написано тигр...

В условиях ограниченных ресурсов непросто наладить выпуск документов, но еще сложнее обеспечить их обновление, особенно если документов со временем накапливается много. Сопровождение документации — трудоемкий процесс. Порой обновление документа сравнимо по времени с разработкой нового. Удобным способом является выпуск дополнений к документам, в которых описываются новые возможности. Со временем, когда таких дополнений соберется много, целесообразно выпустить новую редакцию основного документа.

При подготовке и обновлении пользовательских документов не следует забывать и о ведении версий (редакций) документов. Использование программных средств ведения версий облегчает эту задачу. Не обязательно вести версии программ и документации с помощью одного инструмента. Для файлов с пользовательскими документами можно выбрать несложное эффективное программное средство стоимостью в несколько десятков долларов. Его использование поможет на всех этапах подготовки и выпуска документов, начиная от учета и заканчивая утверждением. Выпуск документа «в свет» также удобно выполнять, если используется программное средство ведения версий. Например, авторы документов имеют права на извлечение (check out) файлов документов из базы данных программы, а правом на включение (check in) файлов обладает только сотрудник, ответственный за ведение документации. Выпуском «в свет» документа является добавление его в базу данных. Сотрудники бизнес-подразделений, имеющие права на чтение документов, могут быть уверены, что получают официальную информацию отдела автоматизации об использовании того или иного программного средства.

А напоследок я скажу...

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



Официальную бесплатную доставку от компании De Dietrich Это предприятие более века было официальным королевским поставщиком пушек и пушечных ядер, а затем добилось еще больших успехов под руководством Жана Дитриша, которому Людовик XV пожаловал дворянский титул. Позднее компанию возглавила Амели де Дитриш (Amélie de Dietrich), впервые в истории промышленности уделившая пристальное внимание дизайну и эстетическому облику индустриальной продукции. ДАЛЬНОВИДНАЯ ДИНАСТИЯ: С 1806 года эта одаренная бизнес-леди решила открыть...

НОВОСТИ

20 сентября 201719 сентября 201718 сентября 201716 сентября 2017

Статьи, интервью, публикации