Антуан де Сент-Экзюпери
Многое в разработке руководства пользователя регламентировано и описано ГОСТами. Но при создании больших гетерогенных систем могут возникать вопросы, не до конца освещенные этими документами.
Отношение к руководству пользователя бывает разным. Многие совсем не задаются вопросом, каковы место и роль документа в процессе разработки больших гетерогенных информационных систем, для других же все и так ясно. Не спешите. В статье мы рассмотрим подходы к организации процесса создания и поддержания в актуальном состоянии этого важного документа, оценим значимость руководства пользователя для всей информационной системы в целом и придем к некоторым неожиданным выводам.
Статья будет полезна для тестировщиков, технических писателей, аналитиков и даже для руководителей проектов.
Описание проблемы
Некоторое время назад я в качестве аналитика начала работу на проекте по разработке информационной системы федерального масштаба. Для быстрого погружения в предметную область мне было предложено заняться руководством пользователя: провести аудит и организовать процесс доработки документа под стремительно расширяющийся функционал системы.
Отдельно остановлюсь на особенностях проекта, поскольку подходы и принципы, о которых пойдет речь, разработаны и адаптированы специально для следующих условий.
1. Масштаб.
Большая гетерогенная распределенная информационная система, которая включает десятки взаимодействующих между собой подсистем.
2. Параллельная разработка.
Из-за масштаба системы над ней работают изолированные команды аналитиков, разработчиков и тестировщиков.
3. Частые изменения.
Опять же следствие масштаба — постоянный поток изменений и доработок.
4. Относительно универсальный и стандартизированный набор бизнес-процессов в рамках проекта.
БОльшая часть процессов имеет постоянную сходную с другими бизнес-процессами часть.
Даже поверхностный взгляд на актуальную на тот момент версию руководства пользователя позволил сделать вывод о невысоком качестве документа. Основных проблем было две: неактуальность и отсутствие единообразия при описании сходных функций и процессов.
Низкое качество руководства пользователя может привести к ряду негативных последствий для всего проекта. Выделю основные:
- рост расходов на эксплуатацию из-за неправильного использования системы и, как следствие, увеличение нагрузки на службу поддержки;
- недовольство пользователей и заказчика;
- увеличение затрат на разработку и сопровождение системы.
Нужно было срочно исправлять ситуацию. Причем сделать это с минимальными затратами.
Поиск решения
Для каждой проблемы был разработан собственный подход. Рассмотрим каждую проблему и каждый подход более подробно.
Неактуальность документа
Неактуальность документа содержит два класса проблем: устаревшее описание имеющегося функционала и отсутствие описания новых возможностей системы. Алгоритм устранения проблемы был выбран такой.
- Составить описание модели «AS IS» (т.е. что у нас есть сейчас, какие функции и бизнес-процессы описаны).
- Описать модель «TO BE» (в качестве консультантов привлекались ведущие аналитики по каждой подсистеме).
- Сравнить «AS IS» и «TO BE» с помощью индикатора «Светофор» и составить план действий.
Для удобства данные заносились в таблицу (см. Рисунок 1), в строках которой указывались автоматизируемые процессы и функции, а в столбцах – существующие описания из руководства пользователя. Последние дополнительно группировались в блоки для каждой подсистемы. В итоге получилась наглядная картина соответствия процессов/функций и их описаний. Кроме того, удалось выделить похожие описания для дальнейшей группировки.
После этого была проведена каталогизация всех описаний (актуальная проблема, поскольку общее количество описаний превышало 100 шт.). Если процесс был описан в руководстве пользователя, то в ячейке на пересечении соответствующих строки и столбца проставлялся номер пункта (раздела).
Далее наглядным индикатором «Светофор» были отмечены результаты сравнения:
- Зеленый цвет – процесс есть в руководстве и нужен в бизнесе.
- Красный – процесс есть, но не нужен (удалить!).
- Желтый – процесс отсутствует, но нужен (добавить!).
- Серый – процесс отсутствует и не нужен.
Использование цветовых индикаторов позволило выявить общую картину: руководство пользователя нужно править… и существенно.
Рисунок 1
Началась работа над документом. Подспорьем на данном этапе опять же стала таблица: если процесс редактируется в одном блоке, то и в другом он создается схожим процентов на 80 образом.
Общее количество описаний функций в руководстве пользователя – более сотни, типовых – 25.
Дальнейшая обработка описаний потребовала дополнительной градации: ярко-зелёный — для сценариев, в которых всё хорошо и правки не требуются; светло-зеленый – для сценариев, которые в целом описаны правильно и нуждаются только в исправлении некоторых моментов; оранжевый – для тех, которые принципиально неправильно описаны и которые необходимо править в первую очередь.
Рисунок 2
В итоге общая картина предстала в цвете: были видны обширные оранжевые пятна проблемных областей, много светло-зеленого и практически отсутствие ярко-зеленого.
Таблица соответствия в ходе работы над документом:
Рисунок 3
По завершении «покрасочных» работ обозначились приоритеты:
- убрать оранжевый цвет – все должно быть описано корректно;
- cделать светло-зеленые поля ярко-зелеными.
На этом моменте важно вспомнить про закон Парето (принцип 20/80): мы относительно быстро исправили наиболее проблемные оранжевые области и долго работали над светло-зелеными. Ведь в них, собственно, вся суть, если мы стремимся к тому, чтобы пользователь действительно мог работать с руководством.
Отсутствие единообразия
При решении этой проблемы ставилась задача обеспечить единообразие при описании сходных процессов (кейсов) и существенно сократить трудозатраты на обновление и поддержание документа. Был выбран подход, в соответствии с которым описание каждого процесса представляется в виде строительного блока (1), а сам документ – их комбинации (3). Все строительные блоки должны располагаться в репозитории (Wiki) с обязательным контролем изменений и поддержкой версионности (2).
Рисунок 4
Основное преимущество данного подхода заключается в существенном сокращении трудозатрат: при создании и редактировании общей части строительного блока правки вносятся только один раз. Сборка руководства пользователя из строительных блоков происходит также гораздо быстрее по сравнению с традиционным вариантом.
Принципиально важный момент: доступ к репозиторию должен быть обеспечен всем командам, работающим над проектом, согласно сформированному регламенту его использования.
Используя такой подход для актуализации и метод «строительных блоков» для сборки, документ удалось за короткий срок привести в надлежащее состояние. Трудозатраты сократились более чем на 30%, по сравнению с традиционным методом формирования документа. Казалось бы, на этом месте можно было бы обозначить happy end, но мне бы хотелось продолжить. Будет интересно.
Место руководства пользователя в цикле управления требованиями
Качественное руководство пользователя получило новые функции, отлично встроилось в систему управления требованиями и общий цикл разработки (независимо от того, последовательная она или итеративная) информационной системы.
В классический цикл разработки от анализа требований (1) до тестирования (4) добавляется этап подготовки документов, среди которых особое место занимает руководство пользователя. Почему же так важен этот документ? По нескольким причинам. В случае параллельной независимой разработки отдельных подсистем возможна потеря унификации (например, расположение управляющих элементов, наименования и т.д.). Именно при подготовке руководства пользователя становятся видны неувязки/несоответствия, как в функциональной плоскости, так и на уровне пользовательских интерфейсов.
Рисунок 5
Только на уровне руководства пользователя система видна целиком, а не как набор отдельных подсистем. Концепция строительных блоков позволяет решить проблему неувязок, но только в случае использования репозитория при разработке постановочной части в качестве справочных материалов. Таким образом, у руководства появляется новая категория пользователей – аналитики и тестировщики. И, конечно, документ должен быть синхронизирован и полностью соответствовать пользовательским требованиям. На этом этапе проводится дополнительная верификация на предмет соответствия пользовательских требований разработанным функциям (руководство пользователя, фактически, содержит бизнес-описание системы).
Из рисунка 5 хорошо видно, что процесс разработки финализируется созданием руководства. Этот документ также активно используется на других этапах разработки.
Рисунок 6
Выводы
Качественно и грамотно составленное руководство, которое содержит актуальное описание автоматизируемых функций, становится важным и востребованным у конечных пользователей и разработчиков документом и приобретает некоторые новые функции:
- компонент базы знаний;
- дополнительный рубеж тестирования и верификации функций, инструмент контроля;
- средство общего повышения качества информационной системы.
Использование описанных подходов при формировании руководства пользователя позволяет:
- существенно сократить затраты на создание документа и поддержание его в актуальном состоянии;
- автоматизировать процесс формирования документа;
- глубоко интегрировать и синхронизировать процесс подготовки руководства пользователя с остальными процессами разработки информационной системы;
- повысить качество информационной системы в целом.
Я надеюсь, что прочитав эту статью, некоторые из вас по-новому посмотрят на этот вроде бы нехитрый, но, как оказалось, очень важный документ и возьмут на вооружение рассмотренные подходы к его формированию.
P.S. В статью не вошли вопросы содержательности элементов и разделов руководства пользователя. Подробно это рассмотрено и регламентировано подразделом 3.4 документа РД 50-34.698-9 и стандартом IEEE 1063-2001.
Структура и содержание документов Руководство оператора, Руководство программиста, Руководство системного программиста регламентированы ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 соответственно.
Обобщенная структура руководства пользователя, построенная на основе анализа перечисленных стандартов, приведена здесь. Общую методологию можно посмотреть в этой статье.
Комментарии (26)
OlegZH
24.05.2017 16:13+2«Качественно и грамотно составленное руководство, которое содержит актуальное описание автоматизируемых функций» — это в пределе суть литературное программирование по Дональду Кнуту. Оно же: представление конечного продукта в виде текста. Тот же текст можно рассматривать и как презентацию, когда отдельные иллюстрации превращаются в слайды, а основной текст — в подсказки читателю/пользователю, что можно/нужно делать в каждой конкретной ситуации. А если представить, что конечный продукт всегда можно перевести в демонстрационный режим, когда каждая операция может быть проделана, сопровождаемая подробным рассказом и показом всех действий, то…
Одним словом, довольно трудно представить себе, как можно делать большие системы без соответствующего программного обеспечения. Даже, если представить себе 1С-подобную систему, то можно сделать аналог Плана счетов бухгалтерского учёта, содержащий «счета» для отдельных аспектов создания и функционирования проектируемой системы. Например, с появлением нового модуля в проектируемой системе можно связать некий Документ, проведение которого должно отразиться на содержимом определённых регистров. Регистры, в свою очередь, составляются так, чтобы оптимальнее всего создавать всевозможные отчёты (например, упоминаемые в статье разрисованные таблицы). Но руководство — это тоже вот такой отчёт, но исходные данные для этого отчёта должны создаваться реальными живыми документами.
Самая большая проблема, здесь, заключается в том, что программисты торопятся писать конечный код. Отсюда и проблема с отслеживанием изменений, и с поиском ошибок, и с постоянной необходимостью править руководство. Если допустить, что проектируемая система должна существовать в виде именно макета, а не в виде какой-то конфигурации готовых к использованию модулей, то общая организация работы может быть и такой: сначала создаётся руководство, содержащее описание общей схемы взаимодействия пользователя с системой; потом, под это руководство создаются избыточные макеты, содержащие различные варианты применения (система расширяющегося меню для перехода из одного режима работы в другой и для выбора последующих действий); затем и заказчики, и разработчики работают с этими макетами, что приводит, фактически, к созданию новых Документов и движениям соответствующих им регистров; наконец, когда все движения выполнены (когда определены все взаимосвязи, все типовые операции и последовательности выполнения типовых операций), можно генерировать программный код, но и этот код должен быть избыточным, чтобы оставить такие вопросы как, например, выбор типов данных, выбор реализации базовых алгоритмов, на потом, когда уже будут проверены все потоки данных и все потоки управления (здесь всё должно иметь текстовое представление); наконец, когда всё уже определено и проверено, можно запускать процесс генерации конечного кода, но и здесь возможно (было бы) реализовывать некоторую избыточность (чтобы заказчик, например, придя к выводу о необходимости изменить систему, смог бы самостоятельно извлечь исходный код системы и построить новую версию системы).
Тут, главное, то, что конечный код системы — это такой же отчёт, построенный на основании заданного заранее Плана счетов, а это значит, что его генерация — это самый последний шаг при создании системы, и что основной источник проблемы создания «больших гетерогенных информационных систем» (как и, вообще, любых программных приложений) это то, что код пытаются писать раньше, чем определены многие вещи. В результате очень много времени и сил может тратиться на кодирование и тестирование того, что, вообще, рискует не попасть в окончательный релиз. То, есть, если сильно утрировать, релиз у системы должен быть один, но, на этапе проектирования, система должна находиться в особом виде (например, можно представить себе базу данных, в таблицах которой находятся фрагменты программного кода, а специальные справочники позволяют описывать назначение этих фрагментов) и в особом состоянии (в состоянии живого макета, когда можно на лету создавать новые операции, вставлять новые варианты взаимодействия и менять пользовательский интерфейс).
(Это всё — моё частное мнение. Если я пишу «должна/должен», то я, лишь, предполагаю наличие такой возможности.)
Leonid76
24.05.2017 18:06+1Только на уровне руководства пользователя система видна целиком, а не как набор отдельных подсистем.
Не соглашусь. На уровне руководства пользователя ни одна система целиком не видна. Хотя бы потому, что руководство пользователя — это система глазами пользователя, который в идеале имеет дело с фронтом и чуть-чуть представляет себе бэк (но чаще не представляет). Кроме того, для снижения требований к квалификации пользователя в РП может применяться намеренно упрощенное и/или адаптированное описание системы и ее процессов, которое нельзя применять в серьезной работе, например, аналитикам.
Подход со строительными блоками хорош по-своему, особенно если на систему оформляется масса руководств с дублирующимися материалами. Например, если в системе с кучей ролей РП по ГОСТ пишется на каждую роль (а некоторые роли разнятся лишь на операцию-другую).
К вопросу о качестве и практической применимости РП. Вы используете в работе документ «Технологическая инструкция» из ГОСТ 34? В нем обычно приводят пошаговые инструкции каких-то ролей пользователей для выполнения их бизнес-функций. Утрировано это выглядит так:
1. Войди в систему 1
2. Введи цифру и нажми зеленую кнопку.
3. Выйди из системы 1.
4. Войди в систему 2.
5. Протяни бегунок до упора вправо.
6. Выйди из системы 2.
7. Войди в систему 3.
8. Открой «отчеты».
9. Распечатай третий сверху отчет.
10. Молодец, неси на подпись начальнику.
Как входить/выходить в систему 1 и где там зеленая кнопка — см. раздел 1 и раздел 3.2 РП Системы 1.
Где бегунок во второй системе — см. раздел 3.5 РП Системы 2.
Как открыть «отчеты» в Системе 3 — см. раздел 4.8 РП Системы 3.
Технологические инструкции в совокупности с РП образуют своего рода матричную структуру, которая во-первых помогает избежать дублирования одних и тех же массивных описаний, а во-вторых позволяет избежать РП-химер, сочетающих в себе куски разных систем.
Ekaterina_Podolina
24.05.2017 18:48Да, РП — это один из инструментов, который не отменяет использование других (спеки и т.д.). В моей практике именно на РП удобно быстро «прокликать» систему по use case и просмотреть ее, ведь при самостоятельном тестировании возникают проблемы в сложности получения нужных данных. Т.о. некоторые моменты просто не видны разным людям или их получение весьма трудоемко.
Большой поток изменений меняет достаточно сильно систему, всё «собрать» в одном месте, конечно, сложно. РП ориентировано, конечно, на фронт и всегда несколько упрощено, как и любая модель отличается от моделируемого объекта.
DanikoBas
24.05.2017 18:25-8Не соглашусь. На уровне руководства пользователя ни одна система целиком не видна. Хотя бы потому, что руководство пользователя — это система глазами пользователя, который в идеале имеет дело с фронтом и чуть-чуть представляет себе бэк (но чаще не представляет). Кроме того, для снижения требований к квалификации пользователя в РП может применяться намеренно упрощенное и/или адаптированное описание системы и ее процессов, которое нельзя применять в серьезной работе, например, аналитикам.
Зря не соглашаешься, там же МГУ, парень.
Тут не до концепции продукта, не до руководства администратора/системного программиста, не до принципиальных схем и чертежей, не до дизайн-гайдов. Это ж руководство пользователя! Главный системный документ после ведомости держателей подлинников=)
На самом деле я не злой, просто это скорее всего первая сколь-нибудь серьезная работа человека, и ему естественно захотелось похвастаться достижением. Можно и похвалить, но лучше не стоит, а то и так много статей про воздух да про пересказ школьного курса
Subrisk
24.05.2017 18:55+5Что, сильно бомбит, что девушка взяла и круто сделала?
Руководство пользователя — важнейший документ для крупных информационных систем, который в том числе админа избавляет от части вопросов и головной боли. И чем оно лучше, тем лучше всем — и вендору, и ТП, и пользователю, и админу. И, кстати, описанную методику можно применять абсолютно к любой документации.
А вам также поспешу напомнить, что подготовка качественной документации — отдельный процесс внутри разработки, ага. Вместе с верификацией этой документации и её внедрением или не-внедрением в само ПО. А то вы, видать, со своим образованием только о школьном курсе и можете судить, вузовский-то не проходили…DanikoBas
24.05.2017 19:21-8Бомбит? Круто сделала?
Когда рассказы о еженедельной рутине стали чем-то крутым? Или лишь бы свой минус обосновать да защитить. Такое ощущение, как будто никогда никакой (абсолютно) критики быть не должно, только одни радостные выкрики.
Никто не спорил, что РП важен, но заявлять об этом так, что это едва ли не основной системный документ как минимум опрометчиво. Не знаю, почему вы начали очевидные вещи рассказывать. Для объема сообщения?
KorP
24.05.2017 20:12+5Зря не соглашаешься, там же МГУ, парень.
Писать в таком ключе, человеку с
среднее и неполное высшее
который на данном ресурсе проявил себя ровно как 0, очень не красиво.
Может вы конечно и очень умный, но мы об этом не в курсе. А упоминание о неполном, высшем образовании, для незнакомых с вами намекает на обратное. Так что придержите коней.
и так много статей про воздух да про пересказ школьного курса
Может быть вы своим гением до нас снизойдёте?
как будто никогда никакой (абсолютно) критики быть не должно
Критики так и не увидел, один «воздух», как вы выражаетесь.
Leonid76
24.05.2017 21:32+2На самом деле я не злой
Нет, злой. Девушка нигде не утверждала, что остальная документация не нужна. Разве что высказалась излишне максималистично. Сама статья вполне жизнеутверждающая и основательная. У меня коллеги на разных местах работы в рангах вплоть до начальника отдела техписов до подобных вещей не доходили (впрочем, в таком виде оно и не требовалось, но сам подход!).
Можно и похвалить, но лучше не стоит
Почему это не стоит? Это явно не школьный курс.
Так что лично я похвалю. Наша девушка не только стройна, кудрями чернява и ланитами краше лепестков, что рассыпает по небосклону Аврора, но и умна. Настолько, что даже МГУ ее не испортит.
nick_volynkin
25.05.2017 05:37Спасибо за интересную статью.
Все строительные блоки должны располагаться в репозитории (Wiki)
Расскажите подробнее, пожалуйста, что такое репозиторий Wiki и в каком формате вы разрабатываете эти блоки?
Именно при подготовке руководства пользователя становятся видны неувязки/несоответствия, как в функциональной плоскости, так и на уровне пользовательских интерфейсов
А почему не гораздо раньше, при проектировании UX? Обнаруживать ошибки до начала разработки гораздо дешевле, чем после её окончания.
автоматизировать процесс формирования документа
Не нашёл в статье ничего про автоматизацию. Вы имели в виду, что ручного труда стало меньше, потому что вы используете шаблоны? Или вы действительно автоматизировали формирование документов?
DanikoBas
25.05.2017 07:13+1Тут такое дело. Я бы может и написал о наших достижениях, тем более часть из них нигде еще не используется и здорово ускоряет и упрощает работу. Однако я что-то впал в немилость у людей, которые вдруг стали защищать банальную методику сверки целостности и актуальности данных (которая в других областях уже давно не используется), а когда человеку захотелось похвастаться образованием МГУ (настолько качественным, что позволило с нуля разработать давно устаревшую методику) и я намекнул что образование в этом деле особо роли не играет, тут важно просто думать головой уметь.
Ладно, оставим эту тему. Вы писали:А почему не гораздо раньше, при проектировании UX? Обнаруживать ошибки до начала разработки гораздо дешевле, чем после её окончания.
Так и должно быть. Должен быть системный и концептуальный документ, и в них (их бывает до 4-5 разных) как-раз таки производятся функции контроля за единообразием, целостностью и тд и тп. Грамотный менеджер проектов об этом подумает еще задолго до того, как аналитика или техписа привлекут к работе.
Про нашу автосборку и другие подходы к документации я возможно еще расскажу. Могу пока что дать спойлер что помогает в этом небольшая программка, написанная за 4 часа на коленке, и ее особенность в том, что она может не только выполнять задачи, но и сохранять при этом нужное форматирование (даже по ГОСТ ЕСКД, с рамками)
Leonid76
25.05.2017 10:22А почему не гораздо раньше, при проектировании UX? Обнаруживать ошибки до начала разработки гораздо дешевле, чем после её окончания.
А UX всё хорошо было. )
Ekaterina_Podolina
25.05.2017 11:34Про репозиторий — это коллекция объектов, в данном случае «строительных блоков». Поддерживается и обновляется в wiki, это достаточно удобный инструмент для команды.
Статья касается в основном методологических вопросов. Средства автоматизации данной методологии выходят за рамки этой статьи. В настоящее время функции автоматизированы частично.
TiesP
25.05.2017 19:20А можно краткий примерчик "строительного блока"? Чтобы понять, что имеется в виду
Ekaterina_Podolina
25.05.2017 19:30Строительный блок — это 1 фраза или несколько, которые можно переиспользовать, немного меня переменные (предметные по тематике) части.
Например
OlegZH
28.05.2017 23:24Пресловутый интуитивно понятный интерфейс может быть описан в виде простого руководства, содержащего только две главы: глава №1 — основные термины и типовые операции; глава №2 — каталог реальных объектов, обрабатываемых в системе. Плюс Введение с описанием того, для чего именно предназначена система и какие задачи в ней можно решать. В противном случае, возникает неимоверное дублирование информации, вроде бесконечных переходов на очередные вкладки и бесконечных нажатий на очередные кнопки. (А то ещё придётся указывать на необходимость «отжатия» кнопки, чтобы пользователь, случайно, не «залип» на какой-то кнопке.)
Leonid76
29.05.2017 10:28Это не будет описанием интерфейса. Интерфейс — это взаимодействие, а не кнопочки.
OlegZH
29.05.2017 15:59Разве, я написал что-то иное?
Leonid76
29.05.2017 16:421. Основные термины и типовые операции.
2. Каталог объектов.
3. Назначение системы (на уровне детализации «Введение»).
Я отметил, что из этого набора описания интерфейса не получится. Вернее получится (бумага всё стерпит), но очень «неочень».
Cerium
Очень серьёзная и проработанная идея, это круто, уже тащу себе идеи. Вы этому где-то обучались или делали чисто по интуиции? Сколько времени заняла разработка всей это системы и её имплементация в реальную жизнь?
Ekaterina_Podolina
У меня базовое образование МГУ + магистратура Физтеха по специальности «Аналитик больших систем» факультета информационных бизнес-систем. Так что да, я этому обучалась + практика проектов, конечно.
Анализ требований (составление таблицы) занял 2-3 дня. Работа над таблицей до ее «зеленого» внешнего вида заняла примерно полтора месяца.
Далее при каждом релизе идет итерация, очень удобно. Важно понимать, что это — «живая» система, для которой характерен постоянный поток новых требований и изменений.
DanikoBas
Не хочу никого обидеть, но у меня среднее профессиональное образование и до этой идеи я дошел давно, более того — у меня часть документации автособирается и автоверифицируется.
А руководство оператора (пользователя) немного уступает другим документам, и вообще удобнее когда вместо такого гигантского документа с типовыми задачами существует модульная справочная система, встроенная в продукт=)
Cerium
И где же пост о вашем изобретении? :-)
А вот модульные системы в продукте — в топку, потому что они неудобны для использования и занимают место в ПО. Прошлый век. Я за отдельную документацию или за веб-версии типа wiki.
DanikoBas
То есть мне о каждом своем проекте предлагаете пост писать? Сомнительно это.
Насчет второго тезиса я бы засомневался, ибо это вкусовщина. Кому-то неудобно, а кому-то удобно. У нас например справка открывается через браузер, а устанавливается с продуктом только при нажатии соответствующего чекбокса. Там хорошо реализован поиск, удобная верстка и крупный читаемый шрифт. Это вам не chm какие-нибудь. Можно сказать, что та же wiki, только чуть поумнее, переносная и автособираемая
Cerium
Ну так и будем тогда сомневаться) Вы — в моих тезисах, я в ваших. Свистеть — не мешки ворочать, на слово верить вам тоже как-то… Я вон может главный инженер Фалькона, а рассказывать не буду — сомнительно, чё.
А Екатерина взяла и рассказала — и принесла пользу. Не знаю, как сообществу, а я своих техписов уже поимел.
Subrisk
Да вы как бы ни об одном не написали. Или я что-то не разглядел?
nick_volynkin
Это интересно. Статью напишете?