Comments 26
Очень серьёзная и проработанная идея, это круто, уже тащу себе идеи. Вы этому где-то обучались или делали чисто по интуиции? Сколько времени заняла разработка всей это системы и её имплементация в реальную жизнь?
У меня базовое образование МГУ + магистратура Физтеха по специальности «Аналитик больших систем» факультета информационных бизнес-систем. Так что да, я этому обучалась + практика проектов, конечно.
Анализ требований (составление таблицы) занял 2-3 дня. Работа над таблицей до ее «зеленого» внешнего вида заняла примерно полтора месяца.
Далее при каждом релизе идет итерация, очень удобно. Важно понимать, что это — «живая» система, для которой характерен постоянный поток новых требований и изменений.
Анализ требований (составление таблицы) занял 2-3 дня. Работа над таблицей до ее «зеленого» внешнего вида заняла примерно полтора месяца.
Далее при каждом релизе идет итерация, очень удобно. Важно понимать, что это — «живая» система, для которой характерен постоянный поток новых требований и изменений.
Не хочу никого обидеть, но у меня среднее профессиональное образование и до этой идеи я дошел давно, более того — у меня часть документации автособирается и автоверифицируется.
А руководство оператора (пользователя) немного уступает другим документам, и вообще удобнее когда вместо такого гигантского документа с типовыми задачами существует модульная справочная система, встроенная в продукт=)
А руководство оператора (пользователя) немного уступает другим документам, и вообще удобнее когда вместо такого гигантского документа с типовыми задачами существует модульная справочная система, встроенная в продукт=)
И где же пост о вашем изобретении? :-)
А вот модульные системы в продукте — в топку, потому что они неудобны для использования и занимают место в ПО. Прошлый век. Я за отдельную документацию или за веб-версии типа wiki.
А вот модульные системы в продукте — в топку, потому что они неудобны для использования и занимают место в ПО. Прошлый век. Я за отдельную документацию или за веб-версии типа wiki.
То есть мне о каждом своем проекте предлагаете пост писать? Сомнительно это.
Насчет второго тезиса я бы засомневался, ибо это вкусовщина. Кому-то неудобно, а кому-то удобно. У нас например справка открывается через браузер, а устанавливается с продуктом только при нажатии соответствующего чекбокса. Там хорошо реализован поиск, удобная верстка и крупный читаемый шрифт. Это вам не chm какие-нибудь. Можно сказать, что та же wiki, только чуть поумнее, переносная и автособираемая
Насчет второго тезиса я бы засомневался, ибо это вкусовщина. Кому-то неудобно, а кому-то удобно. У нас например справка открывается через браузер, а устанавливается с продуктом только при нажатии соответствующего чекбокса. Там хорошо реализован поиск, удобная верстка и крупный читаемый шрифт. Это вам не chm какие-нибудь. Можно сказать, что та же wiki, только чуть поумнее, переносная и автособираемая
Ну так и будем тогда сомневаться) Вы — в моих тезисах, я в ваших. Свистеть — не мешки ворочать, на слово верить вам тоже как-то… Я вон может главный инженер Фалькона, а рассказывать не буду — сомнительно, чё.
А Екатерина взяла и рассказала — и принесла пользу. Не знаю, как сообществу, а я своих техписов уже поимел.
А Екатерина взяла и рассказала — и принесла пользу. Не знаю, как сообществу, а я своих техписов уже поимел.
Да вы как бы ни об одном не написали. Или я что-то не разглядел?
часть документации автособирается и автоверифицируется
Это интересно. Статью напишете?
«Качественно и грамотно составленное руководство, которое содержит актуальное описание автоматизируемых функций» — это в пределе суть литературное программирование по Дональду Кнуту. Оно же: представление конечного продукта в виде текста. Тот же текст можно рассматривать и как презентацию, когда отдельные иллюстрации превращаются в слайды, а основной текст — в подсказки читателю/пользователю, что можно/нужно делать в каждой конкретной ситуации. А если представить, что конечный продукт всегда можно перевести в демонстрационный режим, когда каждая операция может быть проделана, сопровождаемая подробным рассказом и показом всех действий, то…
Одним словом, довольно трудно представить себе, как можно делать большие системы без соответствующего программного обеспечения. Даже, если представить себе 1С-подобную систему, то можно сделать аналог Плана счетов бухгалтерского учёта, содержащий «счета» для отдельных аспектов создания и функционирования проектируемой системы. Например, с появлением нового модуля в проектируемой системе можно связать некий Документ, проведение которого должно отразиться на содержимом определённых регистров. Регистры, в свою очередь, составляются так, чтобы оптимальнее всего создавать всевозможные отчёты (например, упоминаемые в статье разрисованные таблицы). Но руководство — это тоже вот такой отчёт, но исходные данные для этого отчёта должны создаваться реальными живыми документами.
Самая большая проблема, здесь, заключается в том, что программисты торопятся писать конечный код. Отсюда и проблема с отслеживанием изменений, и с поиском ошибок, и с постоянной необходимостью править руководство. Если допустить, что проектируемая система должна существовать в виде именно макета, а не в виде какой-то конфигурации готовых к использованию модулей, то общая организация работы может быть и такой: сначала создаётся руководство, содержащее описание общей схемы взаимодействия пользователя с системой; потом, под это руководство создаются избыточные макеты, содержащие различные варианты применения (система расширяющегося меню для перехода из одного режима работы в другой и для выбора последующих действий); затем и заказчики, и разработчики работают с этими макетами, что приводит, фактически, к созданию новых Документов и движениям соответствующих им регистров; наконец, когда все движения выполнены (когда определены все взаимосвязи, все типовые операции и последовательности выполнения типовых операций), можно генерировать программный код, но и этот код должен быть избыточным, чтобы оставить такие вопросы как, например, выбор типов данных, выбор реализации базовых алгоритмов, на потом, когда уже будут проверены все потоки данных и все потоки управления (здесь всё должно иметь текстовое представление); наконец, когда всё уже определено и проверено, можно запускать процесс генерации конечного кода, но и здесь возможно (было бы) реализовывать некоторую избыточность (чтобы заказчик, например, придя к выводу о необходимости изменить систему, смог бы самостоятельно извлечь исходный код системы и построить новую версию системы).
Тут, главное, то, что конечный код системы — это такой же отчёт, построенный на основании заданного заранее Плана счетов, а это значит, что его генерация — это самый последний шаг при создании системы, и что основной источник проблемы создания «больших гетерогенных информационных систем» (как и, вообще, любых программных приложений) это то, что код пытаются писать раньше, чем определены многие вещи. В результате очень много времени и сил может тратиться на кодирование и тестирование того, что, вообще, рискует не попасть в окончательный релиз. То, есть, если сильно утрировать, релиз у системы должен быть один, но, на этапе проектирования, система должна находиться в особом виде (например, можно представить себе базу данных, в таблицах которой находятся фрагменты программного кода, а специальные справочники позволяют описывать назначение этих фрагментов) и в особом состоянии (в состоянии живого макета, когда можно на лету создавать новые операции, вставлять новые варианты взаимодействия и менять пользовательский интерфейс).
(Это всё — моё частное мнение. Если я пишу «должна/должен», то я, лишь, предполагаю наличие такой возможности.)
Одним словом, довольно трудно представить себе, как можно делать большие системы без соответствующего программного обеспечения. Даже, если представить себе 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.
Технологические инструкции в совокупности с РП образуют своего рода матричную структуру, которая во-первых помогает избежать дублирования одних и тех же массивных описаний, а во-вторых позволяет избежать РП-химер, сочетающих в себе куски разных систем.
Да, РП — это один из инструментов, который не отменяет использование других (спеки и т.д.). В моей практике именно на РП удобно быстро «прокликать» систему по use case и просмотреть ее, ведь при самостоятельном тестировании возникают проблемы в сложности получения нужных данных. Т.о. некоторые моменты просто не видны разным людям или их получение весьма трудоемко.
Большой поток изменений меняет достаточно сильно систему, всё «собрать» в одном месте, конечно, сложно. РП ориентировано, конечно, на фронт и всегда несколько упрощено, как и любая модель отличается от моделируемого объекта.
Большой поток изменений меняет достаточно сильно систему, всё «собрать» в одном месте, конечно, сложно. РП ориентировано, конечно, на фронт и всегда несколько упрощено, как и любая модель отличается от моделируемого объекта.
Не соглашусь. На уровне руководства пользователя ни одна система целиком не видна. Хотя бы потому, что руководство пользователя — это система глазами пользователя, который в идеале имеет дело с фронтом и чуть-чуть представляет себе бэк (но чаще не представляет). Кроме того, для снижения требований к квалификации пользователя в РП может применяться намеренно упрощенное и/или адаптированное описание системы и ее процессов, которое нельзя применять в серьезной работе, например, аналитикам.
Зря не соглашаешься, там же МГУ, парень.
Тут не до концепции продукта, не до руководства администратора/системного программиста, не до принципиальных схем и чертежей, не до дизайн-гайдов. Это ж руководство пользователя! Главный системный документ после ведомости держателей подлинников=)
На самом деле я не злой, просто это скорее всего первая сколь-нибудь серьезная работа человека, и ему естественно захотелось похвастаться достижением. Можно и похвалить, но лучше не стоит, а то и так много статей про воздух да про пересказ школьного курса
Что, сильно бомбит, что девушка взяла и круто сделала?
Руководство пользователя — важнейший документ для крупных информационных систем, который в том числе админа избавляет от части вопросов и головной боли. И чем оно лучше, тем лучше всем — и вендору, и ТП, и пользователю, и админу. И, кстати, описанную методику можно применять абсолютно к любой документации.
А вам также поспешу напомнить, что подготовка качественной документации — отдельный процесс внутри разработки, ага. Вместе с верификацией этой документации и её внедрением или не-внедрением в само ПО. А то вы, видать, со своим образованием только о школьном курсе и можете судить, вузовский-то не проходили…
Руководство пользователя — важнейший документ для крупных информационных систем, который в том числе админа избавляет от части вопросов и головной боли. И чем оно лучше, тем лучше всем — и вендору, и ТП, и пользователю, и админу. И, кстати, описанную методику можно применять абсолютно к любой документации.
А вам также поспешу напомнить, что подготовка качественной документации — отдельный процесс внутри разработки, ага. Вместе с верификацией этой документации и её внедрением или не-внедрением в само ПО. А то вы, видать, со своим образованием только о школьном курсе и можете судить, вузовский-то не проходили…
Бомбит? Круто сделала?
Когда рассказы о еженедельной рутине стали чем-то крутым? Или лишь бы свой минус обосновать да защитить. Такое ощущение, как будто никогда никакой (абсолютно) критики быть не должно, только одни радостные выкрики.
Никто не спорил, что РП важен, но заявлять об этом так, что это едва ли не основной системный документ как минимум опрометчиво. Не знаю, почему вы начали очевидные вещи рассказывать. Для объема сообщения?
Когда рассказы о еженедельной рутине стали чем-то крутым? Или лишь бы свой минус обосновать да защитить. Такое ощущение, как будто никогда никакой (абсолютно) критики быть не должно, только одни радостные выкрики.
Никто не спорил, что РП важен, но заявлять об этом так, что это едва ли не основной системный документ как минимум опрометчиво. Не знаю, почему вы начали очевидные вещи рассказывать. Для объема сообщения?
Зря не соглашаешься, там же МГУ, парень.
Писать в таком ключе, человеку с
среднее и неполное высшее
который на данном ресурсе проявил себя ровно как 0, очень не красиво.
Может вы конечно и очень умный, но мы об этом не в курсе. А упоминание о неполном, высшем образовании, для незнакомых с вами намекает на обратное. Так что придержите коней.
и так много статей про воздух да про пересказ школьного курса
Может быть вы своим гением до нас снизойдёте?
как будто никогда никакой (абсолютно) критики быть не должно
Критики так и не увидел, один «воздух», как вы выражаетесь.
На самом деле я не злой
Нет, злой. Девушка нигде не утверждала, что остальная документация не нужна. Разве что высказалась излишне максималистично. Сама статья вполне жизнеутверждающая и основательная. У меня коллеги на разных местах работы в рангах вплоть до начальника отдела техписов до подобных вещей не доходили (впрочем, в таком виде оно и не требовалось, но сам подход!).
Можно и похвалить, но лучше не стоит
Почему это не стоит? Это явно не школьный курс.
Так что лично я похвалю. Наша девушка не только стройна, кудрями чернява и ланитами краше лепестков, что рассыпает по небосклону Аврора, но и умна. Настолько, что даже МГУ ее не испортит.
Спасибо за интересную статью.
Все строительные блоки должны располагаться в репозитории (Wiki)
Расскажите подробнее, пожалуйста, что такое репозиторий Wiki и в каком формате вы разрабатываете эти блоки?
Именно при подготовке руководства пользователя становятся видны неувязки/несоответствия, как в функциональной плоскости, так и на уровне пользовательских интерфейсов
А почему не гораздо раньше, при проектировании UX? Обнаруживать ошибки до начала разработки гораздо дешевле, чем после её окончания.
автоматизировать процесс формирования документа
Не нашёл в статье ничего про автоматизацию. Вы имели в виду, что ручного труда стало меньше, потому что вы используете шаблоны? Или вы действительно автоматизировали формирование документов?
Тут такое дело. Я бы может и написал о наших достижениях, тем более часть из них нигде еще не используется и здорово ускоряет и упрощает работу. Однако я что-то впал в немилость у людей, которые вдруг стали защищать банальную методику сверки целостности и актуальности данных (которая в других областях уже давно не используется), а когда человеку захотелось похвастаться образованием МГУ (настолько качественным, что позволило с нуля разработать давно устаревшую методику) и я намекнул что образование в этом деле особо роли не играет, тут важно просто думать головой уметь.
Ладно, оставим эту тему. Вы писали:
Так и должно быть. Должен быть системный и концептуальный документ, и в них (их бывает до 4-5 разных) как-раз таки производятся функции контроля за единообразием, целостностью и тд и тп. Грамотный менеджер проектов об этом подумает еще задолго до того, как аналитика или техписа привлекут к работе.
Про нашу автосборку и другие подходы к документации я возможно еще расскажу. Могу пока что дать спойлер что помогает в этом небольшая программка, написанная за 4 часа на коленке, и ее особенность в том, что она может не только выполнять задачи, но и сохранять при этом нужное форматирование (даже по ГОСТ ЕСКД, с рамками)
Ладно, оставим эту тему. Вы писали:
А почему не гораздо раньше, при проектировании UX? Обнаруживать ошибки до начала разработки гораздо дешевле, чем после её окончания.
Так и должно быть. Должен быть системный и концептуальный документ, и в них (их бывает до 4-5 разных) как-раз таки производятся функции контроля за единообразием, целостностью и тд и тп. Грамотный менеджер проектов об этом подумает еще задолго до того, как аналитика или техписа привлекут к работе.
Про нашу автосборку и другие подходы к документации я возможно еще расскажу. Могу пока что дать спойлер что помогает в этом небольшая программка, написанная за 4 часа на коленке, и ее особенность в том, что она может не только выполнять задачи, но и сохранять при этом нужное форматирование (даже по ГОСТ ЕСКД, с рамками)
А почему не гораздо раньше, при проектировании UX? Обнаруживать ошибки до начала разработки гораздо дешевле, чем после её окончания.
А UX всё хорошо было. )
Про репозиторий — это коллекция объектов, в данном случае «строительных блоков». Поддерживается и обновляется в wiki, это достаточно удобный инструмент для команды.
Статья касается в основном методологических вопросов. Средства автоматизации данной методологии выходят за рамки этой статьи. В настоящее время функции автоматизированы частично.
Статья касается в основном методологических вопросов. Средства автоматизации данной методологии выходят за рамки этой статьи. В настоящее время функции автоматизированы частично.
UFO just landed and posted this here
Строительный блок — это 1 фраза или несколько, которые можно переиспользовать, немного меня переменные (предметные по тематике) части.
Например
Например
Пресловутый интуитивно понятный интерфейс может быть описан в виде простого руководства, содержащего только две главы: глава №1 — основные термины и типовые операции; глава №2 — каталог реальных объектов, обрабатываемых в системе. Плюс Введение с описанием того, для чего именно предназначена система и какие задачи в ней можно решать. В противном случае, возникает неимоверное дублирование информации, вроде бесконечных переходов на очередные вкладки и бесконечных нажатий на очередные кнопки. (А то ещё придётся указывать на необходимость «отжатия» кнопки, чтобы пользователь, случайно, не «залип» на какой-то кнопке.)
Sign up to leave a comment.
Как с помощью руководства пользователя повысить качество информационной системы