Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

3696
Требования пользователей – это та основа, при грамотном обобщении и структурировании которой может быть построена нужная организации СЭД. Что такое управление требованиями? Обработка требований. По каким критериям можно выделить наиболее актуальные из них? Что понимается под анализом требований и как использовать их результаты? Документирование требований

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

© О.А. Галкина,

ведущий аналитик департамента разработки тиражных программных продуктов «БОСС-Референт» компании «Логика бизнеса 2.0»

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

• Что такое управление требованиями?

• Как обрабатывать поступающие требования?

• По каким критериям можно выделить наиболее актуальные из них?

• Как определиться, какие из требований необхо­димо в первую очередь принять в разработку, а какие можно отложить?

• Что мы понимаем под анализом требований и как использовать их результаты?


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

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

Чтобы обработать и использовать требования с максималь­ной выгодой, необходимо их:

• выявить;

• собрать;

• зафиксировать;

• проанализировать;

• максимально полезно использовать при подготовке до­кументов.

Виды требований, порядок их поступления

Первые пожелания к функционалу системы начинают возникать еще на этапе подготовки к началу проекта или на этапе пре-сейла (presale - предпродажная активность). Поступают эти запросы обычно от руководителей, инициирующих внедрение СЭД, и владельцев процессов. Такие потребности верхнего уровня помогают определить скоуп (англ. scope - сфера при­менения) - рамки будущей системы.

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

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

Функциональные требования (англ. FEAT-Functional Requirements) - определяют функциональность (поведение) программной системы, которая должна быть создана раз­работчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требо­ваний и в контексте пользовательских требований.

Нефункциональные требования (англ. BR-Business Rules) -определяют критерии работы системы в целом, а не отдель­ные сценарии использования. Нефункциональные требования описывают цели и атрибуты качества, ограничения. Содержат или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоратив­ными инициативами, учетными практиками, алгоритмами вычислений и т. д. Они могут определять такие свойства системы в целом, как производительность, удобство сопро­вождения, расширяемость, надежность, условия эксплуата­ции.


Функциональные требования можно описывать в виде сценариев использования (Use Case).

Сценарий использования, вариант использования, пре­цедент или же пользовательский сценарий (англ. Use Case) -в разработке программного обеспечения и системном про­ектировании это описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рас­сматриваемой системой.

Функциональные требования могут дополняться графиче­скими моделями. Визуальное моделирование облегчает вос­приятие сложных технических документов. Обычно диаграммы разрабатываются в соответствии с общепринятыми нотация­ми - комплексом условных обозначений и правил их исполь­зования (например, UML, BPMN, IDEF0). Однако вполне до­пустимо и использование своих правил и условных обозначений, которые должны быть описаны и приложены к диаграммам.

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

Далее требования детализируются и используются при написании таких документов, как техническое задание и тех­нический проект.

Словарь

UML (англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использую­щий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документиро­вания, в основном, программных систем.

BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов) - си­стема условных обозначений (нотация) для моделирования бизнес-процессов. Последняя версия - 2.0.

IDEF0 (англ. Integrated DEFinition) - методология функционального моделирования. С по­мощью наглядного графического языка IDEF0 изучаемая система предстает перед разработ­чиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков -в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы.


Другой вариант фиксирования требований, получивший популярность в последнее время в связи с использованием методологии SCRUM, - это User Story.

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

User Story - это краткие описания требований к раз­рабатываемой системе, сформулированных как одно или более предложений на бизнес-языке пользователя.

При применении западных стандартов требования ис­пользуются при подготовке такой документации, как специ­фикация требований, концепция, комплексная модель ва­риантов использования, пользовательские истории (user story).

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

Параллельно на первом этапе сбора требований необхо­димо разработать словарь терминов (Glossary). Он позволит обеспечить одно из важнейших качеств требований - понят­ность. А главное, позволит говорить разработчикам и пользо­вателям на одном языке и избежать множества недоразумений. Зачастую под одним и тем же термином специалисты в разных областях подразумевают совершенно разное.

Таким образом, можно выделить следующие виды требо­ваний (рис. 1):

Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

• Запросы пользователей (STRQ - Stake Holder Request) -первичное описание запросов, поступивших от бизнес-пользователей.

• Требования к системе (FEAT) - функциональные тре­бования к системе.

• Сценарий использования (BUC - Busyness Use Case) -описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем.

• Элементы словаря (GLS - Glossary) - определение тер­минов, используемых при описании требований.

• Нефункциональные требования (BR - Business Rules) -требования к работе системы в целом: цели и атрибуты качества, ограничения.

При сборе и формулировании требований к системе не­обходимо соблюдать основные критерии их качества:

Понятность (недвусмысленность) - требование долж­но быть понятно сформулировано (исключать неодно­значное толкование).

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

Завершенность - требование полностью определено в одном месте и вся необходимая информация при­сутствует.

Атомарность (неделимость) - требование нельзя раз­делить на более мелкие без потери завершенности.

Единичность - требование описывает одну и только одну вещь.

Уникальность - каждое требование должно однознач­но идентифицироваться (должен использоваться уни­кальный идентификатор требования).

Полнота - требование должно быть определено для всех возможных ситуаций.

Непротиворечивость (последовательность) - требо­вание не противоречит другим требованиям и докумен­тации в целом.

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

Прослеживаемость - требование соответствует деловым нуждам, как заявлено заинтересованными лицами и задокументировано.

Проверяемость - реализация требования может быть проверена (протестирована).

Источники требований

Принимая требования, следует в обязательном порядке фик­сировать источник требований. Для адекватности требований также важно, чтобы источником требования являлся компе­тентный сотрудник - руководитель или владелец продукта, владелец процесса, ключевой специалист.

Владелец продукта (англ. Product Owner) - это человек, отвечающий за разработку продукта при работе по методо­логии SCRUM. Как правило, это менеджер продукта для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разра­ботки. Владелец продукта - это единая точка принятия окон­чательных решений для команды в проекте.

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

Определиться с требованиями к системе помогут и регла­менты организации, если они актуальны.

Таким образом, источниками требований являются:

• руководство (или владелец продукта);

• владельцы процессов;

• ключевые пользователи;

• документы.

Кто принимает требования

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

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

Дальнейший сбор требований происходит на этапе обсле­дования аналитиком. На основании собранных требований аналитик готовит документацию по системе.

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

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

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

Инструменты для управления требованиями

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

Можно, например, использовать для сбора требований файл, созданный в MS Excel или MS Word. Выглядеть это будет примерно, как на рис. 2:

Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

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

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

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

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

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

Таким образом, инструмент для управления требованиями должен обеспечивать:

• коллективный доступ разного уровня к запросам и требованиям;

• информационный обмен между сотрудниками при смене членов команды;

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

• связывание отдельных требований между собой;

• документирование;

• использование частей документов в качестве источ­ников требований;

• отслеживание статуса каждого требования.

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

Однако максимально удобное управление требованиями обеспечивают специализированные системы, для этого и пред­назначенные: например, специальные программные продукты для управления требованиями компании IBM - Requisite Pro или более функциональный Rational DOORS.

Также для управления требованиями можно использовать такие продукты, как HP Requirements Management, RequirementsWin, BorlandCaliber RM, SybasePowerDesigner и другие.

Ниже на рисунке показан пример представления данных в специализированном инструменте для управления требова­ниями (рис. 3).

Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

В специализированных системах автоматически обеспечи­вается: сохранение истории изменения требования (автор, дата, время изменения), версионность и присвоение уникального идентификатора, коллективное управление требованиями на различных уровнях доступа, централизованное хранение ин­формации, возможность анализа и построения различных пред­ставлений данных, связывания требований, автоматического формирования документации в заданном формате, «нарезания» документов на отдельные требования, трассировка исполнения.

Атрибуты требований. Сортировка требований, анализ

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

Помимо этого, нужно указывать для каждого требования уникальный идентификатор (номер запроса), дату поступле­ния требования, кто зафиксировал требование, статус, важ­ность, трудоемкость, дату рассмотрения рабочей группой проекта, принятое решение по требованию, связанные тре­бования, категорию.

В специализированных системах для управления требо­ваниями атрибуты «уникальный номер» и «автор записи» присваиваются требованиям автоматически.

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

Удобно категорировать требования по видам автоматизи­руемых процессов. Такая группировка требований позволяет увидеть структуру всей системы более ясно, чтобы использовать ее в процессе разработки.

Словарь

Трассировка - отслеживание последовательности исполнения инструкций программы; используется как метод отладки программного кода при разработке компьютерных про­грамм.

На заметку!

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

Например, можно подразделять требования по катего­риям: «процесс работы с входящими документами», «раз­работка нового интерфейса», «администрирование и на­стройка» и т. д.

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

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

Если проект планируется развивать, то вам стоит подумать о приобретении таких инструментов.

Формализация требований

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

С одним пользовательским запросом может быть связано несколько требований. А иногда требование определяется на основании сразу нескольких запросов. Все эти связи также не­обходимо отображать в атрибутах запросов и требований.

Изменение требований. Корректировка целей

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

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

И не всегда то, что пользователи ожидали увидеть, совпа­дет с тем, что создали по их требованиям.

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

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

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

Изменение требований - естественный процесс, и связано это с рядом причин.

Субъективными причинами изменения требований могут быть:

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

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

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

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

• Незнание руководством конкретики внутренних про­цессов, которые они планируют автоматизировать.

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

• Неготовность потенциальных пользователей к автома­тизации или изменению процессов.

Справиться с этой проблемой помогает обучение.

Объективные причины заключаются в том, что:

• Заказчик начинает по-другому понимать и видеть про­блему в результате общения с аналитиком и обдумыва­ния требований к системе.

• В процессе реализации проекта меняются владелец продукта или владельцы процессов.

• На длительных проектах могут меняться сами процес­сы компании.

Это нормально, так как любая компания развивается, может расти и менять свою структуру и бизнес-процессы.

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

Итак, требования поступают как на этапе пресейла, так и на всем протяжении проекта разработки СЭД, а также ее эксплуатации.

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

Изменение требований является одним из основных рисков проекта. Однако изменения - это неизбежный процесс. Поэто­му нужно не бояться его, а подготовиться к нему заранее и пра­вильно организовать управление требованиями.

Верификация изменений требований

Для минимизации рисков проекта все изменения требований должны проходить верификацию (позднелат. verificatio - до­казательство, подтверждение, от лат. verus - истинный и facio -делаю), так как они влияют на функции системы, которые уже были обозначены в утвержденной ответственными лицами документации.

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

Документирование требований

Требования к системе служат основой для следующих видов документов, разрабатываемых в соответствии с российскими стандартами:

Техническое задание.

Техническое задание определяет назначение разрабатыва­емого объекта, функциональные требования к системе, пока­затели качества и технико-экономические требования, требо­вания к составу работ по созданию системы, требования к документации и ее состав, а также специальные требования. Является основным документом, определяющим требования к системе при разработке автоматизированных систем у нас в стране.

Технический проект.

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

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

Спецификация требований (Requirements Specification).

Спецификация программных требований определяет функ­циональные характеристики системы, обязательные для вы­полнения.

Use Case Model (Модели прецедентов (вариантов использования)).

Это комплексная графическая модель вариантов исполь­зования с описанием.

User Story (Пользовательская история).

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

На заметку!

В случае работы по SCRUM ответственность за верифи­кацию (отбор требований) берет на себя владелец про­дукта (product owner).

Концепция (Vision).

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

Итак, в этой статье мы попытались подробно рассказать, что такое управление требованиями, как их удобнее фиксиро­вать, обрабатывать и использовать.

Для того чтобы правильно построить процесс управления требованиями, рекомендую вам предпринять следующие под­готовительные мероприятия:

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

• Сформировать рабочую группу проекта и распределить обязанности в команде проекта: кто будет отвечать за управление требованиями, кто будет их принимать, фиксировать и верифицировать.

• Определиться с критериями анализа и порядком реа­лизации требований.

• Решить, каким образом будет происходить верификация требований и их изменений, а также их документиро­вание.

• Описать вышеуказанные правила в документе «План управления требованиями» и согласовать его с заинте­ресованными лицами.

Организация, внедряющая СЭД, может и должна участвовать в управлении своими требованиями, даже если сам продукт раз­рабатывает специально приглашенная для этого ИТ-компания.

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



Подписка на статьи

Чтобы не пропустить ни одной важной или интересной статьи, подпишитесь на рассылку. Это бесплатно.

Мероприятия

Мероприятия

Проверь свои знания и приобрети новые

Посмотреть

Самое выгодное предложение

Самое выгодное предложение

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

Живое общение с редакцией

Вебинар «Секретарь в соцсетях. Правила поведения»
Журнал «Справочник секретаря и офис-менеджера»

Рассылка




Вопрос - ответ

Отвечаем на Ваши вопросы

Какие реквизиты используются при оформлении приказов по основной деятельности?
Проекты приказов по основной деятельности готовятся по поручению руководителя организации в структурных подразделениях организации, оформляются на специальном бланке и содержат следующие реквизиты
Недавно устроилась секретарем в компанию, где передо мной встала задача наладить документооборот
Подскажите, как правильно начать формировать локальную нормативную базу и какие нормативные документы мне в этом помогут? Читайте ответ на вопрос
Задайте свой вопрос здесь>>> www.sekretariat.ru/pk

PRO Делопроизводство
Портал для руководителей служб ДОУ и секретарей всех уровней

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

E-mail: document@sekretariat.ru


  • Мы в соцсетях
Вы - делопроизводитель? Зарегистрируйтесь!

Регистрация бесплатная и займет всего 1 минуту!
После регистрации вы сможете:

  • читать любые статьи по делопроизводству на нашем сайте!
  • бесплатно подписаться на ежедневные новости по делопроизводству
  • участвовать в вебинарах
  • задавать вопросы экспертам

Оставайтесь с нами!
с заботой о Вас, портал PRO - делопроизводство

У меня есть пароль
напомнить
Пароль отправлен на почту
Ввести
Я тут впервые
И получить доступ на сайт
Займет минуту!
Введите эл. почту или логин
Неверный логин или пароль
Неверный пароль
Введите пароль
Всего один шаг - и документ Ваш!

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

У меня есть пароль
напомнить
Пароль отправлен на почту
Ввести
Я тут впервые
И получить доступ на сайт
Займет минуту!
Введите эл. почту или логин
Неверный логин или пароль
Неверный пароль
Введите пароль