Закономерный результат (А. Секачев, "Расчет", N 5, май 2005 г.)

Закономерный результат

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

Качественный обман...

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

Желание написать эту статью появилось после близкого знакомства с работой одной московской фирмы, поддерживающей популярную бухгалтерскую программу. Руководство этой компании на словах уделяет большое внимание качеству. Для этого даже был куплен сертификат соответствия международным стандартам ISO 9000 (подробнее об этом стандарте читайте в примечании "ISO 9000").

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

...В трех действиях

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

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

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

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

Весь этот процесс при поверхностном рассмотрении выглядит заманчиво. Однако на деле эта "технология" вопиюще безграмотна! Она ведет к созданию некачественных программ, а также получению бесконечных проектов: когда, начав работы по улучшению программы, вы не знаете, будут ли они завершены.

Тест на профпригодность

Невозможно переоценить первую встречу с потенциальным исполнителем. Пока у вас еще есть возможность безболезненно отказать поставщикам некачественных услуг.

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

Вас слушают, но не слышат? Собеседники намерены произвести дешевое впечатление непонятными терминами? Немедленно прекратите встречу и вежливо попрощайтесь с пришедшими!

Обязательно спросите, какие документы будут предоставлены вам по итогам первого этапа "обследования". Если в ответе будет упомянуто лишь техническое задание, то гоните таких горе-работников прочь. И забудьте название их фирмы минимум на пять лет!

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

Почему? Что?

Планирование масштабных изменений бухгалтерской программы вы начинаете с определения финансовой выгоды от улучшений организации бухучета. Этот расчет отвечает на первый вопрос - "Почему?"

Определение цели грядущих улучшений служит ответом на второй вопрос - "Что?" Пример: "Построить и успешно запустить систему для внутреннего управленческого учета в срок до 2007 года". Здесь четко сформулированы действия, область применения и, что немаловажно, срок. При этом каждая цель должна быть еще и реально достижима.

На вопрос "Что?" более детально отвечает рабочий план, который определяет рабочую область проекта. При разработке этого документа существует эффективная и простая в реализации методика "Будет - не будет". На одном листе вы записываете то, что планируете получить в результате улучшений программы, на другом - то, что не планируете.

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

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

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

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

Как?

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

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

Среди прочего они, конечно, обратят ваше внимание на четыре критерия, которым соответствует каждое "хорошее требование": обоснованность, непротиворечивость, однозначность и возможность проверки.

Для больших проектов существенен еще и приоритет (важность) требования, так как именно это позволяет реализовать изготовление программы по версиям, ускоряя ее запуск в жизнь.

После сбора требований происходит их анализ. Результаты этой работы находят отражение в спецификации требований. Пример строки: "3.4.1.2.1 При просмотре списка документов пользователь должен видеть только те, которые создал сам".

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

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

Большинство из них основано на структуре пооперационного перечня работ. Это "сердце" проекта! В иерархическом списке там представлены все действия, необходимые для завершения проекта.

Структура пооперационного перечня работ отвечает на вопрос "Как будет сделано то, что описывает спецификация требований?" Пример строки: "1.2.3.1 Разработка документа "Обналичка"".

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

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

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

Результаты такого "планирования" всегда непредсказуемы!

/-----------------------\              /------------\

|Спецификация требований|-------------|            |

\-----------------------/              |            |

                                       |            |

/-----------------------\              |Техническое |

|Рабочий график         |-------------|  задание   |------------ ?

\-----------------------/              |            |

                                       |            |

/-----------------------\              |            |

|Бюджет                 |-------------|            |

\-----------------------/              \------------/

Планирование, ведущее к намеченной цели

                                                                   /--------------\

                                                          /-------|Рабочий график|

/---------------\       /---------\                       |        \--------------/

|Прибыль        |------|         |                       |                |

\---------------/       |         |   /----------\    /--------\           |            /--------\

                        |         |   |Специфика |    |        |           |            |  .   . |

/---------------\       |         |--|требований|---|        |           |-----------|        |

|Цель           |------|         |   |(SRS)     |    |        |           |            |   ---  |

\---------------/       |         |   \----------/    \--------/           |            \--------/

                        |         |                       |        /--------------\

/---------------\       |         |                       \-------|    Бюджет    |

|Рабочая область|------|         |                                \--------------/

\---------------/       \---------/

Словарик

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

Рабочий план - Statement of work, SOW

Техническое задание - Project initiation document, PID

Спецификация требований - Software requirements specification, SRS

Структура пооперационного перечня работ - Work breakdown structure, WBS ISO 9000

Стандарт ISO 9000 - это набор требований по обеспечению управления качеством продукции и услуг. Первая версия разработана в 1987 году Международной организацией по стандартизации (International Organization for Standardization, или ISO). За основу приняты стандарты, применяемые Минобороны США. Сейчас серия стандартов ISO 9000 признана практически всеми странами мира. В России также действует отечественная версия этих стандартов - ГОСТ Р ИСО серии 9000.

А. Секачев,

программист

"Расчет", N 5, май 2005 г.