Качество технических руководств

Эффективное техническое руководство

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

Все компании разные, но между лучшими техническими руководителями, с которыми мне довелось работать, существует кое-что общее. Снимаю шляпу перед Брайаном Столером, Натаном Хантом, Эваном Гилбертом и Ричем Бердоном за то, что послужили мне хорошим примером.

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

Качества

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

1. Компетентность
Технические знания дают вам понимание и уверенность для принятия правильных обоснованных решений. Сильный технический руководитель обладает широкими и глубокими знаниями. Если какой-либо член команды спрашивает, как работает определенный компонент или система, вы должны уметь объяснить это достаточно подробно или направить к тому, кто может это сделать.

Чтобы оставаться компетентным, я делаю три вещи в следующем порядке:

1. Оцениваю код
2. Читаю проектную документацию
3. Пишу код (см. статью ABC: Always Be Coding)

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

Технический руководитель должен владеть несколькими технологиями. Например: Java, JavaScript, C++, распределенные системы хранения данных и веб-разработка на стороне клиента позволяют занять должность технического руководителя серьезного веб-приложения (подробнее о том, кто такой Full Stack специалист)

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

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

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

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

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

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

Функции

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

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

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

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

2. Разблокировка
Противоположная блокировке разблокировка не менее важна. Дорога в ад выстлана бездействующими разработчиками. Если у кого-то есть вопрос, вы должны быть в состоянии или дать ответ или привести для этого правильного человека.
Мне помогло развить этот навык наличие практикантов. Лучшие практиканты задают очень много вопросов. И если они не получают ответы, они часто могут застрять или, еще хуже, опустить руки. Мне пришлось научиться давать правильные ответы или приводить их к людям, которые будут вести их вперед.

3. Перенаправление
Независимо от того, насколько вы хороши, вы не знаете всего. И вы не можете ответить на любой вопрос. И даже если бы технически вы могли это делать, практически все ваше время уходило бы на ответы на вопросы. Чтобы заполнить эти пробелы (и иметь возможность выполнять собственную работу), вы должны в уме составить список экспертов, чтобы всегда знать, где найти ответ. Изначальное и частое перенаправление – чрезвычайно полезная практика. Технический руководитель часто «человек 302» (или человек-переадресация), который соединяет людей. Если разработчик в вашей команде в чем-то не уверен или задает вопрос, на который вы не знаете точный ответ, понимание, к кому его нужно отправить, чрезвычайно ценно и экономит много времени.

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

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

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

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

1. Уменьшаю количество вариантов до 2. Сложность любой проблемы экспоненциально возрастает с каждым вариантом.
2. Быстро определяю, можно ли сделать оптимальный выбор на основании опыта или данных.
3. Если правильный ответ на этом этапе не является очевидным, можно ли перенаправить вопрос кому-то, кто больше подходит для принятия решения?
4. Если все еще нельзя сделать оптимальный выбор, тогда возможно недостаточно данных или задан неправильный вопрос. Я или блокирую принятие решения или разблокирую его, следуя инстинкту.

Вышеуказанные шаги необходимо мгновенно проходить в уме.

Качество решения подобно налету сокола в удачный момент, позволяющий ему сбить и убить свою жертву. – Сунь-Цзы

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

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

Действия

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

• Создает и поддерживает планы по разработке, тестированию и выпуску.
• Проводит эффективные совещания команды разработчиков.
• По необходимости обеспечивает полезность и лаконичность совещаний.
• Помогает обозначить и расставить приоритеты по проекту.
• Часто говорит «нет» новым излишним функциям.
• Определяет лучшие способы отслеживания решения проблем.
• Организует хакатоны и исправление ошибок.
• Поддерживает межфункциональные отношения.
• Определяет контрольные сроки.
• Следит за появлением полезных инструментов.
• Инструктирует других разработчиков.
• Нанимает разработчиков из других команд.
• Принимает практикантов, делает их успешными.
• Подробно оценивает код и оставляет полезные комментарии.
• Читает, пишет и комментирует проектную документацию.
• Пишет правильный код в правильное время.
• Защищает разработчиков от руководства, если необходимо.
• Работает с другими командами разработчиков, особенно зависимыми.
• Определяет технический долг.
• Объясняет, почему принимаются решения.
• Борется за правильные решения.
• Находит время на работу с техническим долгом.
• Распределяет нагрузку в команде.
• Принимает новых разработчиков и назначает разработчиков в качестве наставников.
• Корректирует курс и целевые даты по необходимости.
• Поддерживает определение минимальных жизнеспособных продуктов проекта.
• Оценивает архитектурные решения и их последствия.
• Обеспечивает написание тестов для основных функций.
• Поддерживает процессы по требованию и дежурные процессы.
• По необходимости поднимает блокирующие проблемы.
• Изучает проблемы конфиденциальности и безопасности продукта.
• Часто генерирует новые идеи и превосходные решения.
• Решает сложные производственные вопросы.
• … и так далее.

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

Будьте уверенны в себе, продолжайте двигаться и постоянно совершенствуйтесь!

Перевод выполнен в рамках летней школы стартапов Tolstoy Summer Camp.

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

Все компании разные, но между лучшими техническими руководителями, с которыми мне довелось работать, существует кое-что общее. Снимаю шляпу перед Брайаном Столером, Натаном Хантом, Эваном Гилбертом и Ричем Бердоном за то, что послужили мне хорошим примером.

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

Качества

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

1. Компетентность
Технические знания дают вам понимание и уверенность для принятия правильных обоснованных решений. Сильный технический руководитель обладает широкими и глубокими знаниями. Если какой-либо член команды спрашивает, как работает определенный компонент или система, вы должны уметь объяснить это достаточно подробно или направить к тому, кто может это сделать.

Чтобы оставаться компетентным, я делаю три вещи в следующем порядке:

1. Оцениваю код
2. Читаю проектную документацию
3. Пишу код (см. статью ABC: Always Be Coding)

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

Технический руководитель должен владеть несколькими технологиями. Например: Java, JavaScript, C++, распределенные системы хранения данных и веб-разработка на стороне клиента позволяют занять должность технического руководителя серьезного веб-приложения (подробнее о том, кто такой Full Stack специалист)

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

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

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

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

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

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

Функции

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

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

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

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

2. Разблокировка
Противоположная блокировке разблокировка не менее важна. Дорога в ад выстлана бездействующими разработчиками. Если у кого-то есть вопрос, вы должны быть в состоянии или дать ответ или привести для этого правильного человека.
Мне помогло развить этот навык наличие практикантов. Лучшие практиканты задают очень много вопросов. И если они не получают ответы, они часто могут застрять или, еще хуже, опустить руки. Мне пришлось научиться давать правильные ответы или приводить их к людям, которые будут вести их вперед.

3. Перенаправление
Независимо от того, насколько вы хороши, вы не знаете всего. И вы не можете ответить на любой вопрос. И даже если бы технически вы могли это делать, практически все ваше время уходило бы на ответы на вопросы. Чтобы заполнить эти пробелы (и иметь возможность выполнять собственную работу), вы должны в уме составить список экспертов, чтобы всегда знать, где найти ответ. Изначальное и частое перенаправление – чрезвычайно полезная практика. Технический руководитель часто «человек 302» (или человек-переадресация), который соединяет людей. Если разработчик в вашей команде в чем-то не уверен или задает вопрос, на который вы не знаете точный ответ, понимание, к кому его нужно отправить, чрезвычайно ценно и экономит много времени.

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

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

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

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

1. Уменьшаю количество вариантов до 2. Сложность любой проблемы экспоненциально возрастает с каждым вариантом.
2. Быстро определяю, можно ли сделать оптимальный выбор на основании опыта или данных.
3. Если правильный ответ на этом этапе не является очевидным, можно ли перенаправить вопрос кому-то, кто больше подходит для принятия решения?
4. Если все еще нельзя сделать оптимальный выбор, тогда возможно недостаточно данных или задан неправильный вопрос. Я или блокирую принятие решения или разблокирую его, следуя инстинкту.

Вышеуказанные шаги необходимо мгновенно проходить в уме.

Качество решения подобно налету сокола в удачный момент, позволяющий ему сбить и убить свою жертву. – Сунь-Цзы

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

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

Действия

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

• Создает и поддерживает планы по разработке, тестированию и выпуску.
• Проводит эффективные совещания команды разработчиков.
• По необходимости обеспечивает полезность и лаконичность совещаний.
• Помогает обозначить и расставить приоритеты по проекту.
• Часто говорит «нет» новым излишним функциям.
• Определяет лучшие способы отслеживания решения проблем.
• Организует хакатоны и исправление ошибок.
• Поддерживает межфункциональные отношения.
• Определяет контрольные сроки.
• Следит за появлением полезных инструментов.
• Инструктирует других разработчиков.
• Нанимает разработчиков из других команд.
• Принимает практикантов, делает их успешными.
• Подробно оценивает код и оставляет полезные комментарии.
• Читает, пишет и комментирует проектную документацию.
• Пишет правильный код в правильное время.
• Защищает разработчиков от руководства, если необходимо.
• Работает с другими командами разработчиков, особенно зависимыми.
• Определяет технический долг.
• Объясняет, почему принимаются решения.
• Борется за правильные решения.
• Находит время на работу с техническим долгом.
• Распределяет нагрузку в команде.
• Принимает новых разработчиков и назначает разработчиков в качестве наставников.
• Корректирует курс и целевые даты по необходимости.
• Поддерживает определение минимальных жизнеспособных продуктов проекта.
• Оценивает архитектурные решения и их последствия.
• Обеспечивает написание тестов для основных функций.
• Поддерживает процессы по требованию и дежурные процессы.
• По необходимости поднимает блокирующие проблемы.
• Изучает проблемы конфиденциальности и безопасности продукта.
• Часто генерирует новые идеи и превосходные решения.
• Решает сложные производственные вопросы.
• … и так далее.

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

Будьте уверенны в себе, продолжайте двигаться и постоянно совершенствуйтесь!

Перевод выполнен в рамках летней школы стартапов Tolstoy Summer Camp.

Автор: tomshinsky

Источник

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

Плохое качество технической документации и организация работы с документами подобного типа

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

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

Иногда с этой документацией приходилось работать в полумраке заводского цеха. Ничего не видно, я всматриваюсь и пытаюсь что-то разобрать. Вдобавок оригинальные схемы были А2, а их распечатали на листах формата А4. При этом необходимо устранять неисправность, а я ничего не могу разобрать, глаза начинают болеть. У меня даже сейчас при воспоминаниях той документации начинают болеть глаза. Организация работы с документами подобного качества была затруднительна.

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

Требования к качеству технической документации

Сейчас на шахте столкнулся с аналогичной ситуацией. Были кальки. Их отсканировали в плохом качестве, распечатали и в таком виде поставили на шахту. Читать тяжело. Нужно заново делать схему, т.к. схема предоставлялась «для галочки». Теперь обслуживающий персонал шахты мучается, стараясь работать по ней.

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

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

1. Она должна быть читабельной;
2. Формат листа должен быть пропорциональный напечатанному;
3. Она не должна содержать ошибок, чтобы люди не тратили время на разборки;
4. Она должна быть максимально полной;

Итого

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

---

Первая статья цикла, посвященного оценке качества техдокументации. Цикл статей будет полезен:

• специалистам подрядных организаций, в чьи задачи входит разработка изделий, программных средств, автоматизированных систем и документации, сопровождающей стадии и этапы разработки, при приемосдаточных испытаниях, конкурсной разработке, если, конечно, важна победа, а не просто «техническое» участие в конкурсе;
• экспертам предприятий-заказчиков при приемке работ у подрядчиков;
• участникам конкурсных комиссий, готовящим экспертные заключения по документам, представленным участниками конкурса. Редакция от 29.04.2021.

Создан 17.12.2011 10:13:46

Наиболее подходящими для решения задачи оценки качества технической документации являются, с нашей точки зрения, ГОСТ 2.105, ГОСТ 19.106-78 и ГОСТ 28195-89. Вызывает интерес и ГОСТ 8.417-2002 Государственная система обеспечения единства измерений. Единицы физических величин.

Если почтенной публике известны какие-либо иные нормативные документы — просьба не стесняться и делиться познаниями.

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

«Семейная лодка разбилась о быт…»

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

«Языки пламени безжалостно лизали всю посуду, категорически оставляя на их пустом содержимом некрасивые пятна кондиционной влаги …» Комментарии, как говорится, излишни, а «за пунктуацию таки и вовсе не имею шо сказать». Как будто бы и не существует п. 4.2.3 ГОСТ 2.105…

В тексте документа не допускается:

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

[из 4.2.3 ГОСТ 2.105-95]

Но быт остается бытом, поэтому никаких чувств(-с), кроме легкой брезгливости по отношению к автору этикетки, не возникает. «Инновационный» пример более показателен.

Инновационный подход к проведению и документированию опытно-конструкторских работ (ОКР)

Цельнотянуто из Постановления Правительства РФ от 24 июля 1998 г. № 832 «О Концепции инновационной политики Российской Федерации на 1998 — 2000 годы». В словарь Ожегова, конечно же, авторы концепции не заглянули…

НОВОВВЕДЕНИЕ, -я, ср. Новое правило, вновь установленный порядок… [Ожегов С. И. и Шведова Н. Ю. Толковый словарь русского языка: 80 000 слов и фразеологических выражений/ Российская академия наук. Институт русского языка им. В. В. Виноградова. — 4-е изд., дополненное. — М.: Азбуковник, 1999. — 944 стр.]

Определение инновации почему-то напомнило знаменитое «бой есть единственное средство достижения победы в бою» (из Полевого Устава РККА) или «я – командир первой эскадрильи, которой командую я!». Инновация раскрывается через инновационную деятельность, определение которой дано в следующем абзаце концепции. Но радует, что хоть не через самое себя…

Но это все лирика. Осенью нынешнего года автору этих строк посчастливилось ознакомиться с несколькими техническими заданиями на ОКР, разработанными различными компаниями, довольно интересными в части тематики разработок. С превеликим изумлением автор обнаружил, что технические задания и календарные планы, подготовленные этими компаниями — близнецы-братья (за исключением функциональных требований). Выяснилось, что общим для всех заказчиком является самое грамотное и образованное министерство — угадайте с трех раз, какое именно 😂

По авторитетному мнению уважаемой г-жи З., канд. биол. наук и внештатного консультанта компании «Техническая документация», скрестить ужа с гадюкой невозможно генетически. Но героическому министерству сам черт не брат — плюнули на авторитеты и таки сумели, решили вопрос со всей своей инновационной ответственностью, ибо нет для них задач нерешаемых! И организовали и исполнителю, и себе бег в мешках, вместо того чтобы работать легко, слаженно и свободно…

В рамках указанных ОКР проводятся разработки комплексов программ, что, в идеале, подразумевает проведение работ согласно стадиям разработки по ГОСТ 19.102-77 Единая система программной документации. Министерские же мастера-умельцы потребовали разработку технических заданий по ГОСТам 15-й системы (что логично для ОКР), в технические задания заставили втиснуть структуру разделов ГОСТ 19.201-78 (что тоже логично), но этапы ОКР призвали выполнять по Единой системе конструкторской(!!!) документации — ГОСТ 2.119 для эскизного и ГОСТ 2.120 для технического проекта! Кстати, эскизные проекты отродясь никто не делал — наверное, это их маленький и милый министерский каприз… Да и технический проект принято объединять с рабочей документацией в одну стадию — технорабочий проект.

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

И на десерт несколько перлов из технических заданий и календарных планов:

• «…обоснование характеристик сторонних программных средств…» — ласкает слух! Берем какую-нибудь стороннюю софтинку типа ворда и обосновываем ее характеристики 😎
• «…унификация функциональных задач…» — см., уважаемые, определения функций и задач, хотя бы применительно к автоматизированным системам;
• «…графических элементов интерфейсов…» — вероятно, имеются в виду элементы графического интерфейса пользователя;
• «…графического интерфейса модулей…» — это уже придирка, конечно, но далеко не все программные модули оснащены графическим интерфейсом;
• «…сторонних систем…» — очевидно, речь идет о внешних системах;
• «…Технический акт…» — тут впору задумчиво почесать в затылке… Наверное, это что-то вроде загадочного зоологического термина «свинская собака» по Ярославу Гашеку;
• «…Документ «Обоснование необходимости закупки технических средств, программного обеспечения и лицензий на него»…» — косноязычие и полное непонимание сути проблемы… Обосновывать следует закупку технических средств с конкретными характеристиками, обеспечивающими конкретный вычислительный ресурс, требуемый для нормального (штатного) функционирования комплекса программ. Программное же обеспечение, если не приобретать пиратское, всегда продается совместно с лицензией. Но дорого, однако 🧐
• «…контролем входной и выходной информации, основанной на методике кодирования объектов…» — входная информация (или данные), вводимая пользователем вручную в диалоговом (или интерактивном) режиме с помощью элементов графического интерфейса в поля ввода данных, подвергается форматно-логическому контролю, проверке неких граничных условий. Чтобы сильно не грузить читателя, приведем простой пример: форматно-логический контроль не позволит ввести, допустим, дату смерти более раннюю, чем дату рождения индивида;
• «…Критерием предельного состояния Комплекса XYZ является превышение времени выполнения функций…» — уважаемые господа, посмотрите, пожалуйста, в ГОСТ 27.002, что есть предельное состояние…;
• «…с возможностью «горячего резервирования» и перехода на резервное оборудование…» — налицо нарушение п. 4.2.3 ГОСТ 2.105 и явное невладение терминологией. Горячего резервирования не существует в природе, есть постоянное резервирование, которое, как известно (немногим), не требует никаких переходов (переключений). Слово «оборудование» в рамках стандартов по информационным технологиям и системам обработки информации не применяется, есть понятие «технические средства», «техническое обеспечение» и т.д.;
• и, наконец, самое забавное — «…должна соответствовать требованиям эргономики и профессиональной медицины…»… Есть подозрение, что под профессиональной медициной подразумеваются СанПиНы — санитарные правила и нормы 😄

Ради справедливости следует отметить, что все исполнители добросовестно и детально расписывают функционал комплексов программ, а также включают в свои ТЗ отдельные разделы статьи «Как писать техническое задание на программу по ГОСТ 19.201-78?», опубликованной автором лет семь-восемь тому назад еще на сайте authorit.ru, на котором сейчас обитают только онлайновая версия книги Автоматизация разработки технической документации с применением AuthorIT. Учебное пособие и несколько десятков полезнейших статей об AuthorIT и <D>.

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

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

Экспертиза технической документации при проведении конкурсных разработок

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

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

В данном конкретном случае технический уровень определялся прозрачностью и полнотой развернутого функционала, владением терминологией и оформлением документации, т.е. проводилась техническая экспертиза (по существу функционала), а затем что-то схожее с нормоконтролем и метрологической экспертизой. Как было указано выше, все экспертные процедуры проводились согласно ГОСТ 2.105, ГОСТ 19.106-78, ГОСТ 28195-89 и ГОСТ 8.417-2002.

Почему ГОСТ 28195-89?

Почему же выбран ГОСТ 28195-89 Оценка качества программных средств. Общие положения? С ГОСТ 2.105 ЕСКД Общие требования к текстовым документам все прозрачно, поскольку он и содержит общие требования к текстовым документам, как и ГОСТ 19.106-78 к программным, выполненным печатным способом. С ГОСТ 8.417-2002 тоже все прозрачно — чистая метрология, а в данном случае — контроль корректности сокращения единиц физических величин…

Все дело в том, что программное средство, равно как и программное обеспечение, включают в свой состав, помимо собственно программы, еще и программную документацию. Т.е. помимо качества самой программы оценивается качество и программной документации. И, как показала практика, не только программной.

Теперь детально о ГОСТ 28195-89 с использованием аутентичного текста самого стандарта.

Согласно п. 1.1 ГОСТ 28195-89 оценка качества осуществляется на всех этапах жизненного цикла ПС при:

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

Вообще-то согласно ГОСТов 19 и 34 техническое задание, технический проект и рабочий проект трактуются как стадии, см. Стадии разработки по ГОСТ 19.102-77 или Наименования документов, разрабатываемых при проектировании системы по ГОСТ 34.201-89. Неувязочка вышла… Также в тексте стандарта упоминаются невесть откуда взявшиеся фазы и этапы, а не стадии жизненного цикла… По несоответствиям в ГОСТ 28195-89 здесь и далее мы пройдемся весьма основательно.

Согласно п. 1.2 ГОСТ 28195-89 оценка качества ПС представляет собой совокупность операций, включающих выбор номенклатуры показателей качества оцениваемого ПС, определение значений этих показателей и сравнение их с базовыми значениями.

Согласно п. 1.5 ГОСТ 28195-89 методы определения показателей качества ПС различаются:

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

Согласно п. 1.5.5 ГОСТ 28195-89 определение значений показателей качества ПС экспертным методом осуществляется группой экспертов-специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции.

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

В ГОСТ 28195-89 применяются преимущественно экспертные оценки. Но, как будет показано в последующих статьях, по ряду оценочных факторов целесообразно применять не экспертный, а расчетный метод оценки. Теперь немного о методике оценки качества, предусмотренной в данном стандарте.

Для обеспечения возможности получения интегральной оценки по группам показателей качества используют факторы качества (1-й уровень): надежность ПС, сопровождаемость, удобство применения, эффективность, универсальность (гибкость) и корректность [из 2.1 прил. 2 ГОСТ 28195-89]

Если пройти по ссылкам, то можно убедиться в том, что в ГОСТ 28806-90 и ГОСТ 28195-89 с терминологическим единством дело обстоит неважно… Вероятно, это обусловлено годичной разницей в возрасте, но как-то странно все: сначала проводится оценка качества, а только год спустя формулируются комплексные показатели качества… 😗 Но если подойти с другой стороны, то сначала всегда отрабатывается технология, а потом уже определяется и гармонизируется терминология.

Каждому фактору качества соответствует определенный набор критериев качества (комплексные показатели — 2-й уровень): устойчивость функционирования, работоспособность, структурность, простота конструкции, наглядность, повторяемость, легкость освоения, доступность эксплуатационных программных документов, удобство эксплуатации и обслуживания, уровень автоматизации, временная эффективность, ресурсоемкость, гибкость, мобильность, модифицируемость, полнота реализации, согласованность, логическая корректность, проверенность [из 2.2 прил. 2 ГОСТ 28195-89]

Критерии качества определяют одной или несколькими метриками (3-й уровень). Если критерий качества определяется одной метрикой, то уровень метрики опускается [из 2.3 Прил. 2 ГОСТ 28195-89]

Метрики составляются из оценочных элементов (единичных показателей — 4-й уровень), определяющих заданное в метрике свойство. Число оценочных элементов, входящих в метрику не ограничено. Взаимосвязь факторов, критериев и метрик с фазами жизненного цикла ПС приведена на черт. 1 — 20 [из 2.4 Прил. 2 ГОСТ 28195-89]

Первые выводы

Настоящая статья корректировалась 30.01.2012, к этой дате уже были опубликованы вторая и третья части статьи, на подходе выход в свет и четвертой. На основании перечисленного материал ГОСТ 28195-89 можно считать проработанным достаточно глубоко для того, чтобы сделать первые выводы. А выводы такие:

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

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

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

В связи с соображениями, изложенными выше, в цикле статей будет сделан акцент именно на оценочные элементы, включая:

• их толкование;
• пояснения (с примерами);
• целесообразность их применения (возможность исключения из состава метрик);
• целесообразность замены методов оценки;
• применимость оценочных элементов к конкретным видам документов.

Отдельно будет отмечена некоторая несогласованность ГОСТ 28195-89 со стандартами ЕСПД и ЕСКД — обратите внимание на слово черт в п. 2.4 прил. 2 стандарта — 😗

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

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

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

Рассмотрим, в каких случаях производитель использует вышеописанные документы:

• В случае необходимости отправить документ заказчику;
• Когда на подходе производство нового оборудования;
• Обеспечение сертификата, который необходим для оборудования;
• Для того чтобы ввозить оборудование или для таможенных процедур.

Принципы разработки руководства по эксплуатации (РЭ)

Руководство по эксплуатации в большинстве случаях разрабатывается на основе положений Государственного стандарта Р 2.601-2019. В ГОСТе представлено подробное описание документа, а также особенности его разработки и правильного оформления.

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

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

В ГОСТе указано, что РЭ может быть доступно в электронном варианте. А это в свою очередь даёт возможность производителям добавить документ на сайт, дополнив его анимацией для более лёгкого восприятия пользователями. Согласно ГОСТу технический паспорт можно объединить с руководством по эксплуатации. А всё по причине минимальных отличий в содержаниях. Если компания-изготовитель  объединяет эти два документа в один, то и названием соответственно меняется на «Паспорт и руководство по эксплуатации».

Какие правила используются для разработки документа

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

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

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

Инструкция по эксплуатации

1. Вводная часть;
2. Отличительные особенности функционирования;
3. Использование по назначению;
4. Техническое обслуживание;
5. Работы по ремонту в текущее время;
6. Правила хранения;
7. Транспортировка;
8. Особенности утилизации.

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

Документы, необходимые для руководства

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

Руководство по использованию состоит из следующей документации:

• Технические документы рабочего плана;
• Схемы;
• Чертежи;
• Информация о техническом состоянии;
• Протоколы приёмки с итогами испытаний, которые были проведены;
• Сведения об уровнях мощности производства.
• Документы, необходимые для определённой техники в зависимости от особенностей.

Согласно требованиям государственного стандарта 2.601-2006 составление руководства по эксплуатации не является обязательным критерием для всех видов продукции. Нужна ли разработка документа определяет сам производитель изделий исходя из особенностей технического применения, наличия дополнительной информации для правильной настройки и других критериев. Однако в ГОСТе оговаривается, что в случае, если составление руководства по эксплуатации заказано со стороны Министерства обороны Российской Федерации, то именно данный орган и будет решать, необходимо ли разрабатывать соответствующий документ.

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

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

Более того, документ пригодится для того чтобы получить некоторые разрешительные документы:

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

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

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

Плохое качество технической документации и организация работы с документами подобного типа

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

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

Иногда с этой документацией приходилось работать в полумраке заводского цеха. Ничего не видно, я всматриваюсь и пытаюсь что-то разобрать. Вдобавок оригинальные схемы были А2, а их распечатали на листах формата А4. При этом необходимо устранять неисправность, а я ничего не могу разобрать, глаза начинают болеть. У меня даже сейчас при воспоминаниях той документации начинают болеть глаза. Организация работы с документами подобного качества была затруднительна.

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

Требования к качеству технической документации

Сейчас на шахте столкнулся с аналогичной ситуацией. Были кальки. Их отсканировали в плохом качестве, распечатали и в таком виде поставили на шахту. Читать тяжело. Нужно заново делать схему, т.к. схема предоставлялась «для галочки». Теперь обслуживающий персонал шахты мучается, стараясь работать по ней.

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

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

1. Она должна быть читабельной;
2. Формат листа должен быть пропорциональный напечатанному;
3. Она не должна содержать ошибок, чтобы люди не тратили время на разборки;
4. Она должна быть максимально полной;

Итого

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

---

disserCat — электронная библиотека диссертаций работаем для вас с 2009 года

• Корзина пуста

Вход
|
Регистрация

Вы робот?

Мы заметили, что с вашего адреса поступает очень много запросов.

Подтвердите, что вы не робот