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

Обычно документацию делают по одному из двух путей – либо используют стандарты, описывающие требования к составу, структуре и содержанию документов (например, ГОСТ 19-й и 34-й серий – ЕСПД и КСАС), либо самостоятельно разрабатывают документ, создавая его на основе собственного опыта или по существующим образцам, в т.ч. взятых из интернета.

Но как же её правильно сделать?

Мой ответ - начинать надо с синопсиса документов.

Все мы рано или поздно (а кто-то и регулярно) сталкиваемся с собеседованиями. Кто-то их проходит, кто-то проводит. Так что тема эта хотя бы иногда для каждого из нас бывает актуальна.

Но что такое «собеседование», и как оно должно проходить?

Разработка любого ИТ-продукта, если она ведётся осознанно и целенаправленно, а не спонтанно и хаотически, требует чёткой постановки задачи – что должно быть получено в результате. Соответственно, необходимо описание требований к создаваемому продукту, которое и принято называть «ТЗ» – Техническим заданием.

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

Однако, возникает логичный вопрос – ДЛЯ КОГО должно быть написано ТЗ.

Из этого уже вытечет следующий вопрос – ЧТО должно быть включено в ТЗ, т.е. какие требования составляют спецификацию (как, собственно, в иностранных языках ТЗ обычно и называется – «спецификация требований»).

Конечно, можно (и, в большинстве случаев, нужно) использовать существующие стандарты – например, отечественные ГОСТ 19.201 для программы и ГОСТ Р 34.602 для автоматизированной системы. Есть и другие стандарты, которые достаточно хорошо описывают структуру и содержания таких документов. Но увы, в большинстве случаев эти стандарты описывают спецификации «внешних» требований заказчика к целевому продукту (что, в сущности, верно), т.е. продукт рассматривается как «чёрный ящик», который что-то и как-то делает, и вот эти «что-то» и «как-то» в их внешнем проявлении в ТЗ как спецификации требований и описываются. А вот вопрос о том, может ли быть ТЗ «для разработчика», остаётся открытым.

Наверняка вы заметили, что в последнее время стало модно говорить о вовлечённости. «Высокая вовлечённость – хорошо, низкая – плохо, давайте вовлекать, повышать» и т.д.

А что же такое «вовлечённость», когда и где её надо повышать?

И надо ли?..

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

В статье рассматриваются вопросы управления техническим состоянием объектов путевого хозяйства с применением информационных технологий.

Вряд ли найдётся кто-либо, кто в здравом уме и ясной памяти будет отрицать необходимость документации. Любой продукт имеет (или должен иметь) свою документацию. Как минимум – инструкцию о том, как этим продуктом пользоваться. Производители почти всегда указывают – «прежде чем начать пользоваться нашим продуктом, внимательно ознакомьтесь с инструкцией».  

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

Но ЧТО же должен создавать автор документации? Что должна в себя включать документация, когда, на каком этапе и в каком объёме она должна создаваться, ЧТО она должна содержать, когда, кому и при каких обстоятельствах она может потребоваться?

В данной статье мы и поразмышляем об этом...

В этой статье мне хотелось бы порассуждать о такой области ИТ-бизнеса, как документирование ИТ-продуктов – автоматизированных/информационных систем (АС, ИС, АИС и т.п.), а также о том, как применение стандартов отражается на качестве разрабатываемой документации и её восприятии целевой аудиторией читателей.

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

Но при этом неизбежно возникает вопрос – а как создать эту документацию?

Много лет назад мне потребовалось для собственных нужд создать индивидуальный лист учёта рабочего времени — TimeSheet. Для этого я использовал таблицу Microsoft Excel.

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