Достаточно часто приходится читать различную документацию на различные проектируемые/внедряемые/поддерживаемые системы. Хочется думать, что мне просто не везло, но постоянно попадается документация, которая ужасна, и причины я бы выделил две: а) проблемы у авторов с формальной логикой, б) непонимание цели разрабатываемого документа. Не берусь лечить проблемы с логикой, буду оптимистично надеяться, что эволюция это исправит, но постараюсь посражаться со второй причиной.
Сразу оговорюсь, что я здесь не буду цитировать какие-то ГОСТ-ы, ISO и т.п., а покажу минимальный набор документов, полезный с практической точки зрения и попытаюсь объяснить свое мнение. Касательно контента документов и их детализации, понятно, что все здесь примерно, возможны перекрытия и углубления в детали, однако я пишу о минимальных потребностях, чтобы вся эта история с проектами вообще работала, понятно, что если где-то будет больше конкретики, чем необходимо - это, скорее, не повредит, и ничего страшного, если будут повторы (хотя копи-пейста, из документа в документ, конечно же, надо избегать!)
Все начинается с того, что Бизнес хочет что-то автоматизировать (опустим тот факт, что необходимость этой автоматизации ему долго доказывали ИТшники - это тема отдельного поста). Свое желание он излагает в Функциональных и технических требованиях (ФТТ). Основными особенностями этого документа являются следующие:
- написан на бизнес-языке;
- объясняется бизнес-процесс, что в нем плохо и что надо улучшить;
- предъявляются требования к результату;
- степень детализации - небольшая, но достаточная, чтобы с точки зрения бизнеса понять что же должно получиться в итоге;
- ФТТ обычно пишет Заказчик, все остальные - Подрядчик.
При разработки ФТТ нужно понимать, что этот документ будет использоваться Подрядчиком для оценки трудозатрат, поэтому Заказчику нужно приложить все усилия, чтобы детализация ФТТ была достаточной для этого - ошибочные оценки трудоемкости как в меньшую, так и в большую сторону отразятся проблемами на Заказчике, а кому нужны лишние проблемы?
Пришел Подрядчик, и уже в рамках проекта на основании потребности, изложенной в ФТТ, он разрабатывает Техническое задание (ТЗ). В целом, под ТЗ нормально понимать детализированное ФТТ, поэтому особенности следующие:
- более технический документ;
- определяет уже из чего будет делаться целевая Система (исходные материалы);
- скорее всего (так и надо делать - это правильная практика!), было проведено какое-то обследование (~понимание среды/условий, уточнение требований из ФТТ), поэтому помимо требований к результату указываются требования к проектированию, причем уже с учетом выбранных исходных материалов;
- степень детализации - максимально возможная - результат и важные моменты в рамках проектирования должны быть учтены до мельчайших потребностей.
Важно: Поскольку ТЗ полностью определяет что должно получиться в результате, а, при грамотном подходе (со стороны Подрядчика), может определить и ключевые моменты проектирования, чтобы не иметь проблем с возможными изменениями потребностей Заказчика по ходу проекта (ведущим к изменению объема) - проектирование следует начинать только после полного согласования ТЗ.
ТЗ является исходным материалом для процесса проектирования, в рамках которого разрабатывается Технический проект (ТПр). ТПр:
- полностью технический документ;
- определяет КАК мы будем делать нашу Систему из выбранных исходных материалов;
- степень детализации ТПр должна быть достаточной для того, чтобы превратить исходные материалы в Систему, полностью соответствующую ТЗ и ФТТ; Фактически под ТПр можно понимать детальный план такого приведения - действительно сначала дешевле поупражняться "на бумаге", а уже потом, все 7 раз отмерив, пойти работать ручищами "на железе".
Будучи результатом раздумий "на бумаге" ТПр - это то, "что хотели" получить. Еще важно, что ТПр - во всех подробностях описывает процесс перевода исходных материалов в желаемую Систему.
Закончив проектирование и написав максимально подробный ТПр можно переходить к разворачиванию\внедрению\настройке Системы, т.е. превращению исходных материалов в нашу Систему, соответствующую ТЗ и ФТТ уже в полях.
Если вы - мудрый гений или данный проект для вас далеко не первое упражнение то ваша пусконаладка пройдет в полном соответствии с ТПр, но, к сожалению (а может и к счастью, ибо без приключений наша жизнь скучна) по ходу могут возникать особенности, поэтому, вполне возможно, что получится не совсем то, что планировалось. Ну, конечно, не так, ибо по-любому надо соответствовать ФТТ и ТЗ, но что касается требований к реализации проекта, частенько "все не так на этот раз...".
Поэтому, помимо Проектной документации, которую можно заканчивать на ТПр, есть еще и эксплуатационная, которая описывать "что в итоге получилось" и как это поддерживать\обслуживать\сопровождать. Важными особенностями эксплуатационной документации являются:
- она динамична, т.е. в процессе своего жизненного цикла Система изменяется, - должна изменяться и эксплуатационная документация, чтобы всегда соответствовать актуальной конфигурации. На практике лучше апдейт необходимых разделов документации производить в рамках процесса управления изменениями (как можно организовать документацию, чтобы ее удобнее и дешевле было апдейтить я как-нибудь напишу);
- она не описывает процесс, она характеризует результат, т.е. Систему.
Как правило, в эксплуатационной документации полезно иметь следующие документы:
- Технический паспорт (ТПс);
- Инструкция пользователя (ИП);
- Инструкция администратора (ИА) - если администраторов несколько может быть несколько ИА для всех возможных групп сопровождения, можно и совместить все эти инструкции в одном документе - тут как удобнее организовать использование этих документов;
- Регламент обеспечения непрерывности бизнеса (РОНБ или BCP-DRP).
ТПс содержит полное техническое описание Системы. Его детализация должна быть достаточной для выполнения всего комплекса работ по сопровождению от планового сервисного обслуживания до "мелкого ремонта" и устранения инцидентов.
ИП - понятно, наглядный документ (кстати, совсем не обязательно, чтобы это была бумага (хотя ее наличие не повредит!) - это может быть совокупность видео-роликов на типовые задачи (не больше 3-х минут, опыт показывает - это около предела терпения), набор красивых презентаций (мы красочное воспринимаем\усваиваем лучше) и любая другая форма, удобная для пользователя ), рассчитанный на потенциального потребителя сервисов Системы, с детализацией, достаточной для использования этих сервисов.
ИА, помимо всего прочего, должна содержать описание всех плановых сервисных работ, полезно включать информацию по трабшутингу и решениям типовых ситуаций. Дальновидные руководители обяжут своих админов актуализировать раздел по траблшутингу в рамках процессов "Lessons learned" после каждого инцидента, что позволит ИА превратить в некую элементарную базу знаний для грядущих поколений админов, а также снизить зависимость от конкретных исполнителей.
РОНБ должен содержать подробненькое описание процедур восстановления из резервных копий и всяческих других применяемых механизмов обеспечения непрерывности. Из РОНБ должно быть однозначно понятно к каким типам несчастья мы (вся группа эксплуатации) готовы и что в этих случаях мы делаем применительно к нашей системы.
На заметку: при приемка подобного документа полезно проводить упражнение по полной симуляции наиболее страшного несчастья - "... а ну-ка давайте грохнем файлы данных БД из-под СУБД и попросим наших админов восстановиться по вашей эксплуатационной документации в заявленные вами 3 часа..." - всегда лучше поупражняться сейчас, почти еще в проекте, чем потом, когда беда придет "на боевом дежурстве".
Еще: если сервис супер-критечен и его падение смерти подобно, то полезно не только заниматься тренировкой админов, но и пользователей (вообще, конечно, BCP-DRP тема обширная и даже не отдельного поста, а целой книги (!), тем более не рассказать ее в абзаце). Например, если у вас есть трейдеры которые должны постоянно торговать вашими продуктами на всяких биржах через Интернет, можно подумать о том, что на период недоступности нужной им ИТ-инфраструктуры их можно отправить домой с ноутом и быстрым мобильным Интернетом или посадить в автобус с теми же ноутами и хорошим wi-fi-ем в салоне и прочими минимальными ИТ-сервисами, и увезти туда, где пока еще спокойно и откуда можно продолжать крутить колеса корпорации (причем, куда везти также должно быть хорошо продумано заранее, чтобы минимизировать необходимость придумывания решения по ходу).
Да, еще момент, можно, в принципе, размазывать РОНБ по инструкциям администраторов и пользователей, но, я вас уверяю, лучше, чтобы в час Х все было под рукой, в одном месте, причем, наличие единого Плана придумали задолго до этого поста (возьмите любой гайд для подготовки, например, к CISSP).
Какие следствия приходят на ум (пора уже завершать, очень много букв, прости, читатель, если твое терпение иссякает):
- если вы пришли в поле где ничего нет, но надо что-то поддерживать - разработайте эксплуатационную документацию и обеспечьте ее постоянную актуальность, старые версии также полезно хранить, - по ним тоже можно отлеживать изменения;
- не надо делать ТПр - это статичный документ, который устаревает после первого же изменения в Системе, к тому же, все еще проще: нет проектирования, - нет и ТПр;
- документация - не сама цель, а средство достижения определенной цели, понимайте эту цель для каждого документа, поскольку это позволит вам определиться с необходимой детализацией описания - она должна быть достаточной для достижения цели.
И последнее - простой пример.
ФТТ: Бизнес: "Нужна деревянная кукла!"
ТЗ: мы должны получить Буратино из сосны, он должен передвигаться, издавать звуки, "думать", в меру возможности.
ТПр: идем в лес, находим говорящую сосну, вырубаем из нее полено, несем в столяную мастерскую, обрабатываем топором, рубанком, наждаком.... рисуем лицо и все остальное... одеваем на "голову" носок.... отдаем в школу....
ТПс: Буратино, сделан из говорящей сосны, полные ТТХ и т.п.
ИП: играть на шарманке, подпевать....
ИА: царапины зачищать наждаком, глубокие - рубанком, сколы красить, подрисовывать лицо по мере истирания, кормить луком раз в месяц....
РОНБ: утерянные конечности восстанавливаются так-то с использованием остатков говорящей сосны, в случае тяжелых потерь - есть 17 братьев-близнецов, полностью обученных и упакованных аналогичным образом, приводимых в рабочее состояние так-то...
Сразу оговорюсь, что я здесь не буду цитировать какие-то ГОСТ-ы, ISO и т.п., а покажу минимальный набор документов, полезный с практической точки зрения и попытаюсь объяснить свое мнение. Касательно контента документов и их детализации, понятно, что все здесь примерно, возможны перекрытия и углубления в детали, однако я пишу о минимальных потребностях, чтобы вся эта история с проектами вообще работала, понятно, что если где-то будет больше конкретики, чем необходимо - это, скорее, не повредит, и ничего страшного, если будут повторы (хотя копи-пейста, из документа в документ, конечно же, надо избегать!)
Все начинается с того, что Бизнес хочет что-то автоматизировать (опустим тот факт, что необходимость этой автоматизации ему долго доказывали ИТшники - это тема отдельного поста). Свое желание он излагает в Функциональных и технических требованиях (ФТТ). Основными особенностями этого документа являются следующие:
- написан на бизнес-языке;
- объясняется бизнес-процесс, что в нем плохо и что надо улучшить;
- предъявляются требования к результату;
- степень детализации - небольшая, но достаточная, чтобы с точки зрения бизнеса понять что же должно получиться в итоге;
- ФТТ обычно пишет Заказчик, все остальные - Подрядчик.
При разработки ФТТ нужно понимать, что этот документ будет использоваться Подрядчиком для оценки трудозатрат, поэтому Заказчику нужно приложить все усилия, чтобы детализация ФТТ была достаточной для этого - ошибочные оценки трудоемкости как в меньшую, так и в большую сторону отразятся проблемами на Заказчике, а кому нужны лишние проблемы?
Пришел Подрядчик, и уже в рамках проекта на основании потребности, изложенной в ФТТ, он разрабатывает Техническое задание (ТЗ). В целом, под ТЗ нормально понимать детализированное ФТТ, поэтому особенности следующие:
- более технический документ;
- определяет уже из чего будет делаться целевая Система (исходные материалы);
- скорее всего (так и надо делать - это правильная практика!), было проведено какое-то обследование (~понимание среды/условий, уточнение требований из ФТТ), поэтому помимо требований к результату указываются требования к проектированию, причем уже с учетом выбранных исходных материалов;
- степень детализации - максимально возможная - результат и важные моменты в рамках проектирования должны быть учтены до мельчайших потребностей.
Важно: Поскольку ТЗ полностью определяет что должно получиться в результате, а, при грамотном подходе (со стороны Подрядчика), может определить и ключевые моменты проектирования, чтобы не иметь проблем с возможными изменениями потребностей Заказчика по ходу проекта (ведущим к изменению объема) - проектирование следует начинать только после полного согласования ТЗ.
ТЗ является исходным материалом для процесса проектирования, в рамках которого разрабатывается Технический проект (ТПр). ТПр:
- полностью технический документ;
- определяет КАК мы будем делать нашу Систему из выбранных исходных материалов;
- степень детализации ТПр должна быть достаточной для того, чтобы превратить исходные материалы в Систему, полностью соответствующую ТЗ и ФТТ; Фактически под ТПр можно понимать детальный план такого приведения - действительно сначала дешевле поупражняться "на бумаге", а уже потом, все 7 раз отмерив, пойти работать ручищами "на железе".
Будучи результатом раздумий "на бумаге" ТПр - это то, "что хотели" получить. Еще важно, что ТПр - во всех подробностях описывает процесс перевода исходных материалов в желаемую Систему.
Закончив проектирование и написав максимально подробный ТПр можно переходить к разворачиванию\внедрению\настройке Системы, т.е. превращению исходных материалов в нашу Систему, соответствующую ТЗ и ФТТ уже в полях.
Если вы - мудрый гений или данный проект для вас далеко не первое упражнение то ваша пусконаладка пройдет в полном соответствии с ТПр, но, к сожалению (а может и к счастью, ибо без приключений наша жизнь скучна) по ходу могут возникать особенности, поэтому, вполне возможно, что получится не совсем то, что планировалось. Ну, конечно, не так, ибо по-любому надо соответствовать ФТТ и ТЗ, но что касается требований к реализации проекта, частенько "все не так на этот раз...".
Поэтому, помимо Проектной документации, которую можно заканчивать на ТПр, есть еще и эксплуатационная, которая описывать "что в итоге получилось" и как это поддерживать\обслуживать\сопровождать. Важными особенностями эксплуатационной документации являются:
- она динамична, т.е. в процессе своего жизненного цикла Система изменяется, - должна изменяться и эксплуатационная документация, чтобы всегда соответствовать актуальной конфигурации. На практике лучше апдейт необходимых разделов документации производить в рамках процесса управления изменениями (как можно организовать документацию, чтобы ее удобнее и дешевле было апдейтить я как-нибудь напишу);
- она не описывает процесс, она характеризует результат, т.е. Систему.
Как правило, в эксплуатационной документации полезно иметь следующие документы:
- Технический паспорт (ТПс);
- Инструкция пользователя (ИП);
- Инструкция администратора (ИА) - если администраторов несколько может быть несколько ИА для всех возможных групп сопровождения, можно и совместить все эти инструкции в одном документе - тут как удобнее организовать использование этих документов;
- Регламент обеспечения непрерывности бизнеса (РОНБ или BCP-DRP).
ТПс содержит полное техническое описание Системы. Его детализация должна быть достаточной для выполнения всего комплекса работ по сопровождению от планового сервисного обслуживания до "мелкого ремонта" и устранения инцидентов.
ИП - понятно, наглядный документ (кстати, совсем не обязательно, чтобы это была бумага (хотя ее наличие не повредит!) - это может быть совокупность видео-роликов на типовые задачи (не больше 3-х минут, опыт показывает - это около предела терпения), набор красивых презентаций (мы красочное воспринимаем\усваиваем лучше) и любая другая форма, удобная для пользователя ), рассчитанный на потенциального потребителя сервисов Системы, с детализацией, достаточной для использования этих сервисов.
ИА, помимо всего прочего, должна содержать описание всех плановых сервисных работ, полезно включать информацию по трабшутингу и решениям типовых ситуаций. Дальновидные руководители обяжут своих админов актуализировать раздел по траблшутингу в рамках процессов "Lessons learned" после каждого инцидента, что позволит ИА превратить в некую элементарную базу знаний для грядущих поколений админов, а также снизить зависимость от конкретных исполнителей.
РОНБ должен содержать подробненькое описание процедур восстановления из резервных копий и всяческих других применяемых механизмов обеспечения непрерывности. Из РОНБ должно быть однозначно понятно к каким типам несчастья мы (вся группа эксплуатации) готовы и что в этих случаях мы делаем применительно к нашей системы.
На заметку: при приемка подобного документа полезно проводить упражнение по полной симуляции наиболее страшного несчастья - "... а ну-ка давайте грохнем файлы данных БД из-под СУБД и попросим наших админов восстановиться по вашей эксплуатационной документации в заявленные вами 3 часа..." - всегда лучше поупражняться сейчас, почти еще в проекте, чем потом, когда беда придет "на боевом дежурстве".
Еще: если сервис супер-критечен и его падение смерти подобно, то полезно не только заниматься тренировкой админов, но и пользователей (вообще, конечно, BCP-DRP тема обширная и даже не отдельного поста, а целой книги (!), тем более не рассказать ее в абзаце). Например, если у вас есть трейдеры которые должны постоянно торговать вашими продуктами на всяких биржах через Интернет, можно подумать о том, что на период недоступности нужной им ИТ-инфраструктуры их можно отправить домой с ноутом и быстрым мобильным Интернетом или посадить в автобус с теми же ноутами и хорошим wi-fi-ем в салоне и прочими минимальными ИТ-сервисами, и увезти туда, где пока еще спокойно и откуда можно продолжать крутить колеса корпорации (причем, куда везти также должно быть хорошо продумано заранее, чтобы минимизировать необходимость придумывания решения по ходу).
Да, еще момент, можно, в принципе, размазывать РОНБ по инструкциям администраторов и пользователей, но, я вас уверяю, лучше, чтобы в час Х все было под рукой, в одном месте, причем, наличие единого Плана придумали задолго до этого поста (возьмите любой гайд для подготовки, например, к CISSP).
Какие следствия приходят на ум (пора уже завершать, очень много букв, прости, читатель, если твое терпение иссякает):
- если вы пришли в поле где ничего нет, но надо что-то поддерживать - разработайте эксплуатационную документацию и обеспечьте ее постоянную актуальность, старые версии также полезно хранить, - по ним тоже можно отлеживать изменения;
- не надо делать ТПр - это статичный документ, который устаревает после первого же изменения в Системе, к тому же, все еще проще: нет проектирования, - нет и ТПр;
- документация - не сама цель, а средство достижения определенной цели, понимайте эту цель для каждого документа, поскольку это позволит вам определиться с необходимой детализацией описания - она должна быть достаточной для достижения цели.
И последнее - простой пример.
ФТТ: Бизнес: "Нужна деревянная кукла!"
ТЗ: мы должны получить Буратино из сосны, он должен передвигаться, издавать звуки, "думать", в меру возможности.
ТПр: идем в лес, находим говорящую сосну, вырубаем из нее полено, несем в столяную мастерскую, обрабатываем топором, рубанком, наждаком.... рисуем лицо и все остальное... одеваем на "голову" носок.... отдаем в школу....
ТПс: Буратино, сделан из говорящей сосны, полные ТТХ и т.п.
ИП: играть на шарманке, подпевать....
ИА: царапины зачищать наждаком, глубокие - рубанком, сколы красить, подрисовывать лицо по мере истирания, кормить луком раз в месяц....
РОНБ: утерянные конечности восстанавливаются так-то с использованием остатков говорящей сосны, в случае тяжелых потерь - есть 17 братьев-близнецов, полностью обученных и упакованных аналогичным образом, приводимых в рабочее состояние так-то...
No comments:
Post a Comment