beskov


Программные продукты и проекты

Методы, Подходы, Новости, Объявления, Заметки


Previous Entry Share Next Entry
Категории документации и типовые роли её авторов
beskov
Грубо можно выделить 3 категории документации, окружающих обычную IT-систему/продукт:
  1. Предпроектная — создаётся на этапах, предшествующих детальному определению внешних свойств и внутреннего устройства системы.
  2. Проектная — содержит основной пакет проектных решений
  3. Эксплуатационная — используется для развёртывания, использования и модернизации системы
Какие документы можно отнести к этим категориям?

Предпроектная документация
  1. Постановка проблемы
  2. Отчёт об обследовании деятельности
  3. Концепция системы
  4. Бизнес-план
  5. BRD / MRD / PRD / FSD
  6. Пользовательские требования
  7. Техническое задание
  8. Технико-экономическое обоснование
Проектная документация
  1. Функциональная спецификация
  2. Эскизный проект
  3. Документ архитектуры системы
  4. Технический проект
  5. Техническая спецификация
Эксплуатационная документация
  1. Руководство администратора
  2. Руководство пользователя
  3. Руководство разработчика
Кто должен выступать основным автором этих документов при инженерном (а не халтурном) подходе к организации ведения проектов?
  • Предпроект — маркетологи, бизнес-аналитики, процессные технологи, менеджеры продукта, системные аналитики.
  • Проект — системные аналитики, системные архитекторы, проектировщики подсистем, инженеры-конструкторы.
  • Эксплуатация — инженеры-разработчики, технические писатели, инженеры-администраторы, процессные технологи.
Почему это важно?
Это понимание важно потому, что в настоящее время у многих участников малых и средних IT-проектов, зачастую попавших в индустрию «случайно», что особенно характерно для веб-проектов, наблюдается устойчивый стереотип, что документацию перечисленных категорий и видов документов должны создавать технические писатели, прежде всего, и только.

На самом деле это не так, технические писатели могут быть отличными ОФОРМИТЕЛЯМИ документации и могут достаточно неплохо почти самостоятельно справляться с 3-й — эксплуатационной категорией документации, но для того, чтобы создавать документы 1-й и 2-й категорий (а документы сами по себе не являются самоцелью, а являются лишь форматом коммуникации результатов работ), нужно обладать соответствующей квалификацией, согласно перечисленным выше ролям.

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

Если страдает оформление — наймите техписа.

Если страдает содержание — организуйте обучение или наймите профессионалов.

  • 1
Отлично разжёвано! Но, с моей точки зрения, недостаточно злобно :)))

UI-Тестировщиков и прочих, кажется, забыл. Они в разрез между проектной, и эксплуатационной документацией попадают.

Кстати, видел случаи, когда на основе тестировочных кейсов писали эксплуатационную докментацию. Изучить результат, к сожалению, не довелось.

То, что проектные планы пишут менеджеры проектов, а тест-кейсы — тестировщики, большинство понимает.

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

я бы отдельно выделил бизнес-требования. эти да, почти всегда предпроектные, поскольку выявляются на пресейле, а за это денег с Заказчика как правило не берут :)

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

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

ТЗ как правило делается после эскизного проекта, поскольку одной из целей ЭП является предложить Заказчику варианты реализации системы. Писать требования к системе до выбора варианта даже не смешно :)

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

для полноты картины я бы еще оттрасировал все это на ЕКС АС, поскольку федералы и бизнес, IT в котором ведет выходцы из федералов, эти стандарты очень любят. а сейчас фередалы в IT с большим удовольствием вкладываются, чем коммерсанты. т.е. описанная картина была бы более актуальной :) да и с терминологией путаницы было бы меньше.

есть еще множество вопросов относительно того, что Вы видите в содержании этих документов.

содержание документов, формирование из них полного непересекающегося комплекта и порядок создания — это тема отдельных разговоров

Ключевые слова здесь — КАТЕГОРИИ и ПРОФЕССИОНАЛЬНЫЕ РОЛИ

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

если надо было привязать категории и проектные роли, то проще было пойти от этапов создания ИС. Типа адекватно расписать цепочку: Этапы -> Результаты -> Исполнители.

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

дайте пожалуйста расшифровку по ролям.

Этот пост писался как ликбез для людей, которые считают, что ТЗ пишет техпис, не более. Когда у них возникнут вопросы, а что же входит в содержание документов, я найду, что ответить — но только тогда, когда они возникнут.

У меня нет цели, чтобы кто-то третий приходил и проверял правильность привязки ролей :)

Переименование в техническую интересно, тогда остаётся вопрос с первой категорией.

Очень правильно написано.

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

Очень жаль. Как раз такие мне на пути только и попадались. не там ищите :)

Редко встречала невменяемых техписов - работа такая, что в голове должен быть порядок. Хотя попадались, бывало... :)))
Кстати, при всем уважении с автору блога - удел техписов не есть только оформительская работа, ну, или это уж для совсем начинающих техрайтеров. Зачастую приходится именно после "на пальцах" объясненных концепций и отрывочных исходных документов ваять прототипы для документов проектных. Да, они потом будут еще доводиться аналитиками, это так, но основу для их дальнейшей работы часто создает именно техпис.

Кира.


  • 1
?

Log in

No account? Create an account