Форум Сообщества Аналитиков
Дисциплины => Управление Проектом => Тема начата: Pawelgronsky от 11 Апреля 2015, 20:50:53
-
Всем добрый день. Чтобы не писать целую поэму, сразу приступлю к делу. Я начинающий TeamLeader + Manager Project в небольшой команде энтузиастов, которая в скоро перерастет в более серьезную команду на более серьезном уровне. Конечно сразу бросается в глаза смесь TeamLeader и Manager Project в одном лице, но пока только так можем. Наша отрасль: Игры и приложения на мобильные телефоны, планшеты и другие носители. Имеется один проект на стадии релиза и уже подумываю над другим проектом. Идея есть, люди есть но как ними правильно управлять - я не знаю. Интересует несколько вопросов к знающим людям по поводу управления командой (проектом), по поводу написания настоящего качественного ТЗ, написание всего жизненного цикла приложения с помощью UML и самое главное - Возможность совместить UML+ ТЗ+ управление проектом и командой вместе. Сильно извиняюсь за распространение дубликата темы, может есть такая информация здесь на форуме, но увы я не нашел ничего подобного. Итак, приступим к вопросам:
1. Подскажите ссылки и ресурсы на тему "Как управлять командой, которая работает в направлении игростроения". Спрашиваю это, потому что специфика управления простой командой, которая разрабатывает серверный проект, программное обеспечивание немного отличается от игростроения, особенно на мобильные платформы. Как начать управлять, ставить задания и рассчитывать время выполнения данного задания, кк управлять весь жизненый цыкл и не отставать от графиков?
2. Где достать пример написание технической документации от начала до конца. Без воды в тексте а только конкретика. Хочется описать приложение от начала до конца и тогда приступить к реализации и управления работы в проекте.
3. Конечно чтобы управлять командой, в которой есть программисты, дизайнеры, художники, аниматоры, звуковые дизайнеры, нужно под каждого писать конкретное ТЗ. Интересует как интерпретировать информацию из главного документа в ТЗ для конкретного человека с конкретными заданиями на конкретной должности.
4. Если использовать UML, то где можно почитать информацию о процессе создания всего жизненного цикла с помощью UML, но на примере. Чтобы я видел с чего начали, что дальше описали, когда описывать архитектуру, когда функциональные возможности и так далее.
5. Наверное самое главное: Как можно совместить техническую документацию с диаграммами и использовать их в качестве задания для конкретного человека. Насколько важны диаграммы или может быть лучше акцентировать внимание на текстовой технической документацией?
P.S: Знаю что написал все и сразу, но лучше держать все в одном топике чем создавать разные. Хочется конкретики: Что, где, куда, для чего и где взять. Потому что о таких делах можно часами писать и говорить.
-
Так как людей, которые интересуются данной темой очень много, взял на себя смелости начать дискуссию на эту тему. Думаю модераторы разрешать делится ссылками на ресурсы и ПО для всех нужд менеджера и лидера игрового проекта и не только. В раздумьях я понял что помимо игровых проектов, обязательно будет разработка простых приложений. И хочется конечно найти метод управления не в зависимости игровой проект это или нет.
Начну пожалуй с первого вопроса. "Как управлять командой, которая работает в направлении игростроения и не только". Мы все знаем, что основными задачами лидера и руководителя являются:
- Координация взаимодействия функциональных подразделений команды ( отделов дизайна, программирования и графики );
- Мотивирование участников команды на достижение результата;
- Общая организация труда, распределение задач и контроль их выполнения, составление планов и документации.
С точки зрения управления версиями проекта, задачами для программистов, нам поможет Средства Управления версиями на подобии Team Foundation Server (https://msdn.microsoft.com/en-us/library/ms364061.aspx) и других. Конечно в зависимости от движка создания игр, языка программирования или технологии для приложенийили. Давайте сначала не будем прикрепляться к конкретной технологии или языку. Главное понять основы управления. Как управлять версиями проекта и исходного кода мы знаем. Это безопасно, в таких системах можно задавать задания и следить за историей работы программистов. Но меня интересует вопрос: Как начать все планировать, запустить разработку проекта? Ведь чтобы запустить разработку - нужно техническое задание (ТЗ) для для команды. И причем для разных видов работ в проекте - разные ТЗ. Нужно описать функциональные возможности проекта, чтобы работники поняли что нужно делать для них в будущем и какой продукт выйдет в конце. У просторах интернета я не могу найти НОРМАЛЬНЫЙ пример написания ТЗ, главного документа еще и с использование UML. Но сейчас вопрос не стоит в UML описании приложения или игры. Это заставляет перейти к другому и третьему вопросу:
Где найти примеры написания документации. Именно шаг за шагом, какой документ идет первым, какой вторым и так далее. Тут я не могу рассказать ничего об этом. Здесь надеюсь на Вашу поддержку.
На этом я пока все, потому что четвертый вопрос уже наступит тогда, когда будет UML проект и все техническая документация. Тогда и сможем поговорить за слияния двух видов документации.
-
Вот эту ссылку уже изучили? http://games.1c.ru/4_files/desdocpack.zip
-
Всем добрый день.
Здравствуйте, Павел.
Интересует несколько вопросов к знающим людям по поводу управления командой (проектом), по поводу написания настоящего качественного ТЗ, написание всего жизненного цикла приложения с помощью UML и самое главное - Возможность совместить UML+ ТЗ+ управление проектом и командой вместе.
С ходу начинаете мешать теплое с мягким. Вам управлять людьми надо или ТЗ научится писать?
1. Подскажите ссылки и ресурсы на тему "Как управлять командой, которая работает в направлении игростроения". Спрашиваю это, потому что специфика управления простой командой, которая разрабатывает серверный проект, программное обеспечивание немного отличается от игростроения, особенно на мобильные платформы.
И чем, по вашему отличается разработка игр от всего остального? С точки зрения управления, конечно.
Что касается ресурсов, могу посоветовать Стратоплан, мои коллеги и знакомые проходившие программы по управлению проектами остались все довольны.
Как начать управлять, ставить задания и рассчитывать время выполнения данного задания, кк управлять весь жизненый цыкл и не отставать от графиков?
Разбить работу на задачи, оценить их, оценить риски, распределить задачи по исполнителям, поставить им сроки и следить за выполнением. Все просто:)
3. Конечно чтобы управлять командой, в которой есть программисты, дизайнеры, художники, аниматоры, звуковые дизайнеры, нужно под каждого писать конкретное ТЗ. Интересует как интерпретировать информацию из главного документа в ТЗ для конкретного человека с конкретными заданиями на конкретной должности.
Написание ТЗ не связано с управлением. У вас в команде есть аналитик? Или и ТЗ писать будете тоже вы?
4. Если использовать UML, то где можно почитать информацию о процессе создания всего жизненного цикла с помощью UML, но на примере. Чтобы я видел с чего начали, что дальше описали, когда описывать архитектуру, когда функциональные возможности и так далее.
UML это всего лишь нотация. Она никоим образом не связана ни с жизненным циклом разработки ни с архитектурой ни с управлением командой.
5. Наверное самое главное: Как можно совместить техническую документацию с диаграммами и использовать их в качестве задания для конкретного человека. Насколько важны диаграммы или может быть лучше акцентировать внимание на текстовой технической документацией?
Обычно, диаграммы это часть ТЗ, которые наглядно поясняют сопровождающий текст. Картинки понятнее чем тонна текста, по этому их и используют:)
Павел, у меня сложилось впечатление что вы зациклились на UML (по большому счету не имеет значения, использовать его или нет) не решив по настоящему важных вопросов.
В вашем сообщении я не увидел является ли ваша разработка коробочной или заказной (кто является источником требований к продукту)?
Какую методологию разработки вы планируете использовать?
Является ли ваша команда действительно командой или это просто некий набор специалистов, возможно, даже территориально разобщенный?
Кто формирует видение и цели проекта?
Кто занимается выделением и оценкой трудоемкости задач?
Пока эти вопросы без ответа, нет смысла обсуждать такие мелочи как картинки в ТЗ.
-
Здравствуйте. Спасибо что ответили. Ух, много чего нужно обсудить. Так начну по порядку.
С ходу начинаете мешать теплое с мягким. Вам управлять людьми надо или ТЗ научится писать?
И чем, по вашему отличается разработка игр от всего остального? С точки зрения управления, конечно.
Сложилось так, что я собрал пол года назад команду, и мы просто занимались проектами как OpenSourse на уровни хобби. Но со временем все переросло в более серьезный масштаб. И сейчас у нас релиз игры. И в скорейшем времени мы приступим к следующему проекту. И для этого я хочу быть готовый и "напичканым" знаниями ;D
Что касается ресурсов, могу посоветовать Стратоплан, мои коллеги и знакомые проходившие программы по управлению проектами остались все довольны.
Спасибо. Посмотрю и оценю.
Написание ТЗ не связано с управлением. У вас в команде есть аналитик? Или и ТЗ писать будете тоже вы?
Аналитика нет, пока я решил взять на себя это все. Выходит я аналитик, менеджер проекта, и TeamLeader. Понимаю что смешно, но доверять самый важный кусок начала работы кому-то пока я не хочу. Во первых я хочу научиться понимать весь процесс управления проектом, весь процесс работы проекта от начала и до конца. У меня есть два сценариста, но как я понимаю это не их работа писать ТЗ. ТЗ должен писать менеджер по работе с клиентами, но пока нет такого человека, значит работа висит на мне. Я думаю что если я буду писать ТЗ и управлять проектом, то буду видеть всю картину жизненного цикла проекта.
Обычно, диаграммы это часть ТЗ, которые наглядно поясняют сопровождающий текст. Картинки понятнее чем тонна текста, по этому их и используют:)
Это и меня интересовало. Спасибо. Просто я сейчас думаю как все совместить красиво.
Павел, у меня сложилось впечатление что вы зациклились на UML (по большому счету не имеет значения, использовать его или нет) не решив по настоящему важных вопросов.
Да. Вы наверное правы. Просто я первый раз столкнулся с потребностью серьезно браться за такой кусок работы. Сам я учился на Архитектора ПО. Имею представление о управлении проектами и о нотациях и о UML но только на уровни так сказать дипломной работы или курсовой, в которой ты разработчик, ты аналитик, ты менеджер, ты бухгалтер ;D ;D
В вашем сообщении я не увидел является ли ваша разработка коробочной или заказной (кто является источником требований к продукту)?
Скажем разработка коробочная и нет. Источник требований к продукту мы сами. Идеи мои, сроки расставляю я сам, требования мои. Выходит что заказчика нет. Команда работает сама на себя. Из за этого у мне не понятно со всем. Потому что если брать статьи и литературу по управлением проектами, все опираются на заказчика и это понятно. А мне как поступать если заказчика нет, ресурсы будут браться от предыдущего проекта который сейчас в релизе.
Какую методологию разработки вы планируете использовать?
Является ли ваша команда действительно командой или это просто некий набор специалистов, возможно, даже территориально разобщенный?
На счет методологии я растерян. Я не знаю какую лучше взять. Команда - это набор специалистов, "которые перерастают" в команду. Территориально мы раскиданы. Я в Польше, программисты в России, сценарист в Украине. Работа только через интернет и только общаемся по скайпу. Но это пока. В будущем хочу открыть небольшой офис и понемножку начинать расти дальше. ИЗ-за этого я хочу подготовиться к настоящему управлению. Чтобы знать что к чему. Как управлять и вжаться в сроки.
Кто формирует видение и цели проекта?
Кто занимается выделением и оценкой трудоемкости задач?
Видение и цели проекта формирую я. Мне кажется это лучше пока, потому что от себя легче оттолкнуться на счет всех требований. На счет выделением и оценкой трудоемкости задач я не знаю ничего. С этим увы не работал в таком реальном проекта и бес понятия.
Я понимаю что стразу в первом посте и сделал кашу, но Вы только направьте меня, в какую сторону мне начать развиваться и искать информацию. Чтобы как-то по шагу делать по ступеньки. А то у меня самого каша капитальная на счет этого Время конечно есть но лучше начать раньше чем потому ночами сидеть.
-
Вот эту ссылку уже изучили? http://games.1c.ru/4_files/desdocpack.zip
Да смотрел эти файлы. Есть что взят из них. Я так понимаю что при процессе написания ТЗ уже буду лучше видеть что нужно.
-
"Выходит я аналитик, менеджер проекта, и TeamLeader."
Не обижайтесь, но пока Вы ни то, ни другое, ни третье. Не морочьте себе голову.
Зато у Вас уже получается что-то делать, и вот отсюда и надо плясать.
Учитывая Ваши амбиции - стать всем сразу, в т.ч. "директором по развитию", я бы посоветовал следующее:
1. Работаете интуитивно и пока получается - вот и славно. Так и продолжайте, не надо делать резких движений.
2. Начинайте читать книги управленцев от ИТ. Мемуары, мысли, опыт. Только не конкретные методологии. Это позволит Вам как-то определиться, что Вам требуется и расставить приоритеты в получении необходимого.
3. Бросьте попытки объять необъятное. Если видите, что зашиваетесь на каком-то участке - наймите специально обученного человека.
-
Не обижайтесь, но пока Вы ни то, ни другое, ни третье. Не морочьте себе голову.
Так и есть. Из-за этого написал сюда. Как бы не могу сформулировать все в голове. Что делать, с чего начать, как делать лучше. Сегодня одно, завтра другое, каждый день появляются костыли, которые нужно решать решать и еще раз решать. Вот и думаю взяться за все.
И как не крути рано или поздно нужно научиться контролировать людей в какой то мере. Как не крути, лучше узнать весь процесс работы, только поучаствовав в нем.
Начну пожалуй с литературы, по куску буду пытаться сформировать временные рамки проекта и разбивать их на "подзадания".
Ну хорошо а что на счет литературы по управлению? Я искал книги конкретно по моим вопросам, но никогда не могу наткнуться на книгу или статью, где бы была выбрана тема для создания ПО, задачи и от начала до конца расписано действие менеджера по проекту. Всегда одна вода. От что что а в этом деле мне не нравиться что ничего конкретного нет по такому поводу. Все настолько размыто что не могу. Я понимаю что из-за разновидности заданий и нужд заказчика очень много, из-за этого такая литературе не конкретна а это как бы "основы для того,чтобы повернуть мозг менеджера на правильный шаг в работе" это очень хорошо, но в какой то мене плохо. Нет конкретики.
Постараюсь по куску узнавать, почитаю форум, посмотрю мнение людей. Как я говорил что я в растерянности с чего то начать. Пожалуй начну с простых ТЗ для проекта, которые посоветовал Denis Beskov. Спасибо ему. И тогда уже наткнувшись по мере поступления проблем, буду и решать.
-
Сегодня одно, завтра другое, каждый день появляются костыли, которые нужно решать решать и еще раз решать.
У дипломированных аналитиков-менеджеров-[вставить свое] - все точно так же.
Вот и думаю взяться за все.
Так Вы уже. Только если начнете забивать себе голову всей научной и псевдонаучной фигней сразу - с высокой вероятностью угробите текущую работу. Как та сороконожка, которая задумалась, в каком порядке ей нужно ноги переставлять.
-
Ну хорошо а что на счет литературы по управлению? Я искал книги конкретно по моим вопросам, но никогда не могу наткнуться на книгу или статью, где бы была выбрана тема для создания ПО, задачи и от начала до конца расписано действие менеджера по проекту.
Вы видели статьи Архипенкова и Селиховкина?
http://citforum.ru/SE/project/arkhipenkov_lectures/
http://citforum.ru/SE/project/selikhovkin/
Чего в них не хватает для работы?
-
Сложилось так, что я собрал пол года назад команду, и мы просто занимались проектами как OpenSourse на уровни хобби. Но со временем все переросло в более серьезный масштаб. И сейчас у нас релиз игры. И в скорейшем времени мы приступим к следующему проекту. И для этого я хочу быть готовый и "напичканым" знаниями
Ну тогда надо было сразу писать суть, типа "Помогите научиться управлять проектами", не теребя UML без надобности:)
ТЗ должен писать менеджер по работе с клиентами, но пока нет такого человека, значит работа висит на мне.
Это еще что за зверь? Менеджеры по работе с клиентами в колл центрах сидят на телефонах:) Может кого другого имели в виду?
А мне как поступать если заказчика нет, ресурсы будут браться от предыдущего проекта который сейчас в релизе
Заказчик всегда есть. Просто в этом случае это вы сами. И как любой заказчик, должны четко понимать что хотите. Записать это в Vision документ и уже плясать от него.
На счет выделением и оценкой трудоемкости задач я не знаю ничего.
Ну, если вы определитесь что хотите, выделение задач проблем не составит. Оценивать задачи должны их исполнители. Потом вы приложите риски и посмотрите на сроки. Они сразу разойдутся с желаемыми и тут можно будет сделать три вещи:
1. Уменьшить scope проекта.
2. Сдвинуть сроки.
3. Вешать лапшу на уши заказчику что вы успеваете, а когда сроки будут сорваны, просто скажете что "ну вот так получилось, но осталось же чуть-чуть, потерпите":)
По поводу рисков почитайте "Вальсируя с медведями" ДеМарко и Листера. Там на пальцах рассказывают что такое риски в разработке ПО и почему их надо учитывать.
-
Вы видели статьи Архипенкова и Селиховкина?
http://citforum.ru/SE/project/arkhipenkov_lectures/
http://citforum.ru/SE/project/selikhovkin/
Чего в них не хватает для работы?
Большое спасибо за литературу. Я искал в интернете много раз но на такое никогда не находил. Пробежался быстренько по заголовкам Архипенкова. Очень порадовало. Есть та суть которую я ищу. Есть процессуальность работы поэтапно. Радует очень. СПАСИБО.
Ну тогда надо было сразу писать суть, типа "Помогите научиться управлять проектами", не теребя UML без надобности:)
Хотелось подойти научно, так сказать на хорошем уровне. У меня есть опыт описания ПО в UML, но как я говорил на уровне курсовых.
Это еще что за зверь? Менеджеры по работе с клиентами в колл центрах сидят на телефонах:) Может кого другого имели в виду?
Я не знаю как он называется точно, из-за этого я говорил что есть разница между проектом разработки ПО и игростроением. Игростроение уже так отдалилось от стандартных проектом приложений что нужно отдельно узнавать детали даже на уровне набора кадров. Я так понимаю что есть такой человек, по идеи, который занимается суто техническими документами. Эти документы он пишет для дизайнеров, программистов, программистов шейдеров, звуковых дизайнеров, арт-дизайнеров, левел-дизайнеров и тд. отдельно. Иными словами для каждого человека в команде есть документ в котором расписано что делать отдельно. Но это пишется без сроков выполнения, без делайнов или "поддедлайной". А бы хотел совместить такое.
1. Уменьшить scope проекта.
2. Сдвинуть сроки.
3. Вешать лапшу на уши заказчику что вы успеваете, а когда сроки будут сорваны, просто скажете что "ну вот так получилось, но осталось же чуть-чуть, потерпите":)
По поводу рисков почитайте "Вальсируя с медведями" ДеМарко и Листера. Там на пальцах рассказывают что такое риски в разработке ПО и почему их надо учитывать.
Спасибо за ответ. Почитаю литературку, которую подкинул Denis Beskov. И буду понемногу описывать все что нужно и как нужно.
-
Я не знаю как он называется точно, из-за этого я говорил что есть разница между проектом разработки ПО и игростроением. Игростроение уже так отдалилось от стандартных проектом приложений что нужно отдельно узнавать детали даже на уровне набора кадров.
Не усложняйте себе жизнь на пустом месте. Ничем оно в производстве не отличается. Игра - такое же ПО как и 1С или Антивирус Касперского.
Я так понимаю что есть такой человек, по идеи, который занимается суто техническими документами. Эти документы он пишет для дизайнеров, программистов, программистов шейдеров, звуковых дизайнеров, арт-дизайнеров, левел-дизайнеров и тд. отдельно. Иными словами для каждого человека в команде есть документ в котором расписано что делать отдельно. Но это пишется без сроков выполнения, без делайнов или "поддедлайной". А бы хотел совместить такое.
Сначала я подумал что вы о коммьюнити менеджерах, такие чуваки которые окучивают игровые тусовки на общественных площадках типа соц. сетей.
А так, речь идет о простом аналитике, который зная уже scope проекта и верхнеуровненые требования детализирует задачи для каждого исполнителя.
-
...И как любой заказчик, должны четко понимать что хотите...
Вот тут улыбнулся. :)
-
Ну а для начала пролистайте эту презентацию:
http://www.slideshare.net/SlavaPankratov/ss-535501
-
Вот тут улыбнулся. :)
:)
-
Я так понимаю что есть такой человек, по идеи, который занимается суто техническими документами.
Такой человек называется игровым дизайнером или продюсером. Пишет он не технические документы, а концепцию игры и дизайн-документ.
Эти документы он пишет для дизайнеров, программистов, программистов шейдеров, звуковых дизайнеров, арт-дизайнеров, левел-дизайнеров и тд. отдельно. Иными словами для каждого человека в команде есть документ в котором расписано что делать отдельно.
Документы для специалистов пишут ведущие специалисты. Технический руководитель или просто опытный инженер описывает технический дизайн. Художники рисуют скетчи, пишут руководства по созданию моделей и требования к ним (после согласования с инженерами, т.к. могут предъявляться и технические требования к арту).
Но это пишется без сроков выполнения, без делайнов или "поддедлайной".
На подготовку и написание документов тоже есть сроки.
-
Павел, приветствую.
Попробую дать парочку "своих" откровений на Вашу ситуацию.
Совмещать в себе кучу ролей можно, но как говорится "лишь бы было". Ибо по каждому направлению частенько и целого человека на полный рабочий день мало. Это надо понимать.
Теперь что относится к роли аналитика. Заказчик (как уже ранее говорилось) конечно есть и это Вы. По идее это прекрасно, ибо во всех компромиссных ситуациях сами с собой вы быстрее договоритесь (в связке заказчик-аналитик-тимлид-продактменеджер). Ну и знания для принятия решения в одной голове, это приятный бонус.
Перейдем к требованиям. Можно разделять два процесса: процесс сбора/создания решения и процесс описания/документирования решения. Вы частенько упоминали про UML и тд, но это всего-лишь нотация оформления (для кого-то и мышления. но не суть). Т.е. для начала Вы должны представлять себе решение, а уже потом оформлять его. У меня бывало, что на поиск решения могли уходить недели (грязного времени), а на документирование 10 минут. За 5 лет работы мне так и не пришлось оформлять требования в UML-нотациях. Это я к тому, что совсем не в обязательном порядке чему-либо следовать (хотя UML/IDEFx/BPMN наверное ближе всех к стандартам отрасли).
Мы работаем с коробочным продуктом, где мои ТЗ это добавление/изменение/удаление некой части возможностей продукта.
Я передаю команде разработчиков документ (MS Word), внутри которого:
1. Тема и идентификатор задачи.
2. Исходная ситуация. Описание как мы докатились до того, что требуется что то программировать.
3. Цель. Описание цели, к чему стремимся на высоком уровне (ответ на вопросы "почему/зачем", а не "что/как"). Желательно, что бы цель не ограничивала решение. Решение - это лишь конкретный вариант достижения цели.
4. Требования. Тут у меня нумерованный список, где чем выше уровень тем в более общем смысле описана задача. Ну, например, "1. Добавить отчет "Показатель АБВ". 1.1 Параметры/настройки построения. 1.2 Выборка данных. 1.3 Макеты представления" и тд. Чем глубже - тем больше деталей. Там могут встречаться таблицы, схемы, макеты (рисую в пейнте ^^, моделирую в Visio, Excel-е и тд). Т.е. нумерованный иерархический список + материалы. Было время, начальник не принимал ТЗ "без картинок" =)
5. Миграция БД. Как обновлять БД имеющихся клиентов после обновления программы.
6. Сценарии использования/Приемочные критерии. В помощь QA-инженерам.
7. История изменений. Табличка, где вписаны жизненные вехи документа (создание, правки и т.д.).
Некоторые пункты можно пропускать в тех или иных случаях. Я привел пример "своей рыбы", думаю на её базе Вы уже сейчас сможете начать оформлять свои мысли. Разумеется "рыба" у каждой команды и продукта своя, Вы со временем придете к своему варианту, надо только сделать первый шаг.
Предварительно необходимо составить vision (главный концепт) вашей игры. Не забывайте ключевые принципы, типа "Разделяй и властвуй". Не можете оценить задачу - дробите на составляющие. Ну и в этом духе, от общего к частному и наоборот. А так же ознакомиться с азами системного подхода. Удачи!
-
По поводу
Интересует как интерпретировать информацию из главного документа в ТЗ для конкретного человека с конкретными заданиями на конкретной должности.
- я бы порекомендовал автору ознакомиться с ГОСТ34.602.89, не использовать целиком, а именно ознакомиться. Очень хорошо прочищает, позволяет понять сколько может быть неучтенного если подходить к этому вопросу "нахрапом".
Опять же, творчески переработав перечень требований ГОСТ (что самим ГОСТ не возбраняется) - можно получить неплохой базовый шаблон для основного документа. Выделяйте только те Требования, которые нужны конкретно для Вашего проекта, добавляйте собственные и .. вперёд.
Для конкретных же заданий конкретным специалистам - просто пишите спецификации прямо по пунктам Требований.
... безусловно нужно понимать, что разработка по ГОСТ34 - это реально прошлый век и на данный момент используется только в Гос.структурах, однако использование Scrum и прочих модных технологий неподготовленными людьми может привести к очень даже былинному фэйлу
-
У автора ИГРОВОЙ проект, какой ГОСТ 34??
-
Denis Beskov
Я же прямо написал, что рекомендую "ознакомиться". Что именно в этом ГОСТе хорошо - так это избыточный для любого проекта, но очень полный набор типов требований.
Из личного опыта - в свое время перегнал этот ГОСТ в стилистически приятный Вордовский вид. С тех пор, несколько раз ознакомив наиболее понятливых ключевых пользователей с этим документом, я начинал получать гораздо более качественные первичные требования. Просто потому что, человек начинает думать чуть шире своей первичной задачи. Сразу - без дополнительных вопросов на совещаниях.
Приведенный же Вами комплект документов глянул по диагонали - реально хороший пример.
-
Denis Beskov
На тему "игрового проекта" и Требований к нему.
Некоторое время назад качнул я на телефон Тетрис. Первый попавшийся. Просто вспомнить захотелось.
Так вот, половину батареи телефона эта игрушка высадила за 5 минут. При этом собственно игрушка крутилась нормально, то есть все предписанные ей функции (генерация фигур, повороты, очистка) выполняла.
Стремительное развитие железа в последние 2 десятилетия всё чаще приводит к тому, что разработчики просто перестают думать например о том, на чем будет работать конечный продукт. Таких примеров можно массу привести.
Почему и был рекомендован 34-й - прочитав его человек осознает, что на любом этапе работы с требованиями нужно сесть и подумать "а всё ли я учел". Очень уж наглядный пример, сколько не пишут об этом в умных книжках, но без конкретики пролетает мимо.
-
Так вот, половину батареи телефона эта игрушка высадила за 5 минут. При этом собственно игрушка крутилась нормально, то есть все предписанные ей функции (генерация фигур, повороты, очистка) выполняла.
Как использование ГОСТ 34 помогло бы избежать такой нежелательной (по всей видимости, для вас) ситуации?
-
Стремительное развитие железа в последние 2 десятилетия всё чаще приводит к тому, что разработчики просто перестают думать например о том, на чем будет работать конечный продукт. Таких примеров можно массу привести.
А должны ли разработчики тетрисов об этом думать? Может, это забота разработчиков железа и операционной системы?
-
А должны ли разработчики тетрисов об этом думать? Может, это забота разработчиков железа и операционной системы?
Таки да!
-
Как использование ГОСТ 34 помогло бы избежать такой нежелательной (по всей видимости, для вас) ситуации?
Денис, еще раз. Не "использование", а "знакомство". Ок, давайте через аналогии.
Сколотить собачью будку может практически любой человек. Чего там сложного ? Но только человек, хотя бы понаслышке знакомый со строительством, задумается о вентиляции и водоотводе.
ГОСТ34 в качестве системы документирования проекта - тяжел и избыточен для подавляющего большинства современных прикладных задач. Мне например не доводилось не то, что использовать его в работе, но даже и готовых примеров документации не видел ни разу.
Но это не уменьшает его ценности в качестве шаблона. Можно очень долго рассуждать о том, что существуют требования "функциональные" и "нефункциональные", приводя при этом пару-тройку простеньких кейсов, но это не отразит всей палитры требований, в первую очередь - нефункциональных. ГОСТ же - отражает. И просто заставляет помнить о них.
ИМХО.
-
А должны ли разработчики тетрисов об этом думать? Может, это забота разработчиков железа и операционной системы?
Таки да!
Таки нет :)
Уж сколько раз призывы "поставить сервер помощнее" счастливо заканчивались простой оптимизацией кода.
-
Денис, еще раз. Не "использование", а "знакомство". Ок, давайте через аналогии.
Ну так как именно помогло бы знакомство? Вы привели конкретный кейс и конкретную группу стандартов, к чему теперь эти аллегории с собачьими будками? Давайте ваш конкретный кейс и рассматривать.
Зачем знакомиться с ГОСТом на АС, если есть стандарты на работу с качеством ПО?
Что сказано в ГОСТ 34.602 про качество ПО и ограничения (о которых речь в приведённом вами кейсе)?
2.6.3.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:
1) к независимости программных средств от используемых СВТ и операционной среды;
2) к качеству программных средств, а также к способам его обеспечения и контроля;
Всё.
Что сказано в «ГОСТ 28195-89. Оценка качества программных средств. Общие положения» (того же года, между прочим)?
Там приведены около 20 показателей качества ПО, включая, например:
4.3. Ресурсоемкость. Минимально необходимые вычислительные ресурсы и число обслуживающего персонала для эксплуатации ПС
Что сказано в «IEEE 830-1998. Методика составления спецификаций требований к программному обеспечению»?
5.2.1.6 Ограничения памяти
Этот подраздел должен определять любые применимые характеристики и ограничения первичной и вторичной памяти.
Что сказано в ГОСТ Р ИСО/МЭК 9126 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению»?
Там выделено 6 характеристик качества ПО и 30 подхарактеристик, включая:
4.4 Эффективность (Efficiences)
Набор атрибутов, относящихся к соотношению между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях.
…
А.2.4.2 Характер изменения ресурсов (Resource behavior)
Атрибуты программного обеспечения, относящиеся к объему используемых ресурсов и продолжительности такого использования при выполнении функции.
Что сказано в «ISO 25010 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models» ?
Там приведено уже 8 групп характеристик качества и около 50 конкретных атрибутов качества ПО, среди которых:
4.2.2
performance efficiency
performance relative to the amount of resources used under stated conditions
…
4.2.2.2
resource utilization
degree to which the amounts and types of resources used by a product or system, when performing its functions, meet requirements
Возвращаясь к вашему метафорическому/аллегорическому языку — зачем советовать людям документацию по лошади, если у них свинья и есть документация на свинью?
Можно очень долго рассуждать о том, что существуют требования "функциональные" и "нефункциональные", приводя при этом пару-тройку простеньких кейсов, но это не отразит всей палитры требований, в первую очередь - нефункциональных. ГОСТ же - отражает. И просто заставляет помнить о них.
ИМХО.
Он отражает НФТ к ИС. Причём это ГОСТ 89-го года. Стандарты на качество ПО и систем серии 250X0 — 2007-2011-го годов, причём, как я показал выше, дают около 50 атрибутов качества ПО против одного абстрактного «качества ПО» в ГОСТ 34.602.
-
По поводу - я бы порекомендовал автору ознакомиться с ГОСТ34.602.89, не использовать целиком, а именно ознакомиться. Очень хорошо прочищает, позволяет понять сколько может быть неучтенного если подходить к этому вопросу "нахрапом".
ГОСТ как шаблон для требований гораздо лучше, чем отсутствие всякого шаблона, но при разработке игры он мало поможет. Потому что создание всякой игры начинается с идеи (а лучше - системы идей), которые затем формализовано излагаются в виде концепт-документа. А вот ГОСТа для изложения концепции игры не существует.
-
Таки да!
Разработчики игры должны следовать руководствам по разработке игр от держателя платформы. Но самостоятельно на низком уровне думать о зарядке/разрядке аккумулятора они не должны.
Т.е. то что я хочу сказать - разработчики должны следовать советам из руководства о том, как сохранить заряд батареи. Если эти рекомендации не нарушались, то, следовательно, игра была написана правильно.
-
***
Вот ведь зайдешь книжку спросить ....
***
Denis Beskov
Денис, благодарю Вас за потраченное время :) Мне даже стыдно несколько ...
но, верну Вас в свою "аллегорию".
1. Парень колотит свою первую в жизни будку для собаки.
2. Колотит не один, а с группой единомышленников.
3. Часть единомышленников уже взялась за забивание гвоздей и раскрашивание крыши под хохлому.
4. Всё остальное - обмер собаки, чертеж будки, закупка досок и инструмента, установка будки и поселение в ней собаки - парень берет на себя (звезду пока не выписываем, но в виду имеем)
"возникает попендопль."
5. Парень абсолютно справедливо сомневается в том, что осилит всё, что на себя взвалил.
6. Парень приходит и вполне адекватно просит посоветовать - что сделать чтобы уж если облажаться, то по минимуму.
"входят двое"
7. Первый говорит - "Парень, почитай вот этот документ по строительству, там например сказано, что стоит предусмотреть вентиляцию"
8. Второй говорит (не Парню, а Первому) - "А вот нифига, есть поновее документ и там сказано, что вентиляцию нужно не просто сверлить, а под углом с учетом розы ветров и диаметром так чтобы подлый шершень не пролез"
"внимание, правильный вопрос":
Это как-то отменило совет про то, что стоит почитать документ, в котором сказано, что нужна вентиляция в принципе ?
Кирилл Лебедев
Кирилл, обратите внимание на основной момент. У автора (по его словам) первый боевой проект.
ГОСТа на игровые проекты конечно нет, но ... опыта у автора - тоже если и есть, то по минимуму.
И кто сказал, что "игровой" проект у автора - последний ? Может в следующий раз он решит написать тарификатор для таксистов ?
Системные то знания нужно иметь.
-
Андрей, ещё раз — мобильная игра не является автоматизированной системой. Она является программным обеспечением, программным продуктом со своими существенными особенностями, отличающими её от других категорий программных продуктов.
Вся смысловая риторика автоматизации как процесса замены участков человеческой деятельности автоматизированными и автоматическими функциями с сокращением затрат (времени, усилий и/или стоимости) совершенно не применима к игре. Игра наоборот стремится увеличить время и затраты в целом, проводимые в игре, что делает её более похожей на медиапродукцию.
Показатели назначения игры (количество игроков, увлекательность геймплея, доходность с одного участника и т.д.) не достигаются правильным определением состава функций, автоматизирующих деятельность и атрибутов её качества. Успех игры зависит не от правильного функционально-технического проектирования, а в большей степени от устройства «объекта автоматизации» — сценария игровой деятельности, который создаётся практически одновременно с самим приложением.
Игра гораздо ближе к стартапу, где важно как можно быстрее проверить идею, довести её до успешного роста и потом уже заниматься вопросами оптимизации, масштабирования и качества. Поэтому допустимо сделать прототип из говна и палок, а потом уже переписать его на «правильной» архитектуре, если игра полетит.
Единственное место, где может быть полезен ГОСТ 34 — при разработке бэкенда для системы, который будет представлять собой полноценную автоматизированную систему. И который опять же не нужен в полноценном объёме, если мы говорим про пилотирование новой игры, а не поддержку линейки игр, продуктового портфеля.
Давайте, в конце концов, посмотрим, что из основного состава ГОСТ 34.602 может хоть в принципе иметь какое-то отношение к мобильной игре:
2.6.1. В подразделе «Требования к системе в целом» указывают:
1. требования к структуре и функционированию системы; — в лучшем случае это геймплей + карта навигации + структура игрового мира. но как именно называние их таким образом поможет — не ясно
2. требования к численности и квалификации персонала системы и режиму его работы; — не применимо, у самой игры персонала нет
3. показатели назначения; — ну да, игра должна затягивать и приносить миллион долларов в месяц. но это не задание для программиста
4. требования к надежности; — хорошо описано в стандартах на софт
5. требования безопасности; — не применимо, если не считать ограничения на использование мельтешаших цветов и недопущение развития нервных расстройств, припадков эпилепсии и депривации сна. но чтобы это правильно сформулировать, нужно знать хоть что-то из эргономики, когнитивной психологии и социологии
6. требования к эргономике и технической эстетике; — даже ISO 9241/9126/25010 практически ничего не говорят о том, как задавать требования к графическому дизайну. я тоже не знаю
7. требования к транспортабельности для подвижных АС; — не применимо
8. требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; — не применимо
9. требования к защите информации от несанкционированного доступа; — любой продакт с минимальным опытом игры не забудет, что аккаунт должен быть с паролем
10. требования по сохранности информации при авариях; — важный момент для промышленной версии игры
11. требования к защите от влияния внешних воздействий; — не применимо или нужно подходить очень творчески
12. требования к патентной чистоте; — важный момент в ряде случаев
13. требования по стандартизации и унификации; — есть в стандарте на софт
дополнительные требования.
Итого, из 13 основных разделов требований:
5 — не применимы
2 — типовые категории из серии капитана очевидность (да, должны быть функции. да, должен быть пароль)
4 — требуют недюжинного кругозора за рамками программной инженерии чтобы быть использованными
2 — хорошие подсказки
-
Смотрим дальше,
2.6.2. В подразделе «Требование к функциям (задачам)», выполняемым системой, приводят:
1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;
при создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;
2) временной регламент реализации каждой функции, задачи (или комплекса задач);
3) требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов;
4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.
Как это маппировать на игру? Я не понимаю.
-
2.6.3. В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.
Технического, метрологического, организационного и методического обеспечения у игры не существует.
Математическое, информационное и лингвистическое обеспечение раскрываются в геймплее. Творческая раскладка геймплея на эти 3 категории скорее всего ничего не даст.
-
Разработчики игры должны следовать руководствам по разработке игр от держателя платформы. Но самостоятельно на низком уровне думать о зарядке/разрядке аккумулятора они не должны.
Т.е. то что я хочу сказать - разработчики должны следовать советам из руководства о том, как сохранить заряд батареи. Если эти рекомендации не нарушались, то, следовательно, игра была написана правильно.
Может оказаться что советы в руководстве не помогают достичь цели, т.е. максимально снизить потребление энергии. В таком случае часть пользователей откажется от игры и доход от продажи уменьшится. Помимо следования руководству хорошо бы ещё убедиться что советы достаточно полезны.
-
Denis Beskov
Денис, всё.
Уже стойкое ощущение, что я Вас просто троллю.
Предлагаю остановиться на том, что я действительно имея в виду одно, привел очень неудачный пример другого.
Автору рекомендуем не читать мой бред.
-
ГОСТ как шаблон для требований гораздо лучше, чем отсутствие всякого шаблона, но при разработке игры он мало поможет. Потому что создание всякой игры начинается с идеи (а лучше - системы идей), которые затем формализовано излагаются в виде концепт-документа. А вот ГОСТа для изложения концепции игры не существует.
ГОСТ 34 - для автоматизированных систем, а игра под определение АС не подходит.
-
В итоге обсуждение свелось к фундаментальному вопросу:
Что лучше, строить баню по проекту аэропорта или без проекта вообще?:)
-
В итоге обсуждение свелось к фундаментальному вопросу:
Что лучше, строить баню по проекту аэропорта или без проекта вообще?:)
Не,
Где уж нам уж до аэропортов то с банями. Курилку бы к аэропорту пристроить - и то хлеб.
Остановились на том, что проектируя детский велик, нужно брать ТУ на детский велик, и не в коемь случае не смотреть на ГОСТ на двухколесные средства передвижения очень лохматого года потому что есть другой ГОСТ на двухколесные средства передвижения чуть менее лохматого года, ибо только там про ксеноновые фары сказано.
В целом, резон в этом конечно же есть, я ж согласился. Причем без капли иронии.
Denis Beskov
Денис,
данный постинг написан в хорошем настроении и исключительно в качестве шутки (имеющей по определению долю шутки).
Очень прошу не принимать близко к сердцу :)
-
Андрей, ещё раз — мобильная игра не является автоматизированной системой. Она является программным обеспечением, программным продуктом со своими существенными особенностями, отличающими её от других категорий программных продуктов.
Я мало знаком с мобильными играми. Но разве сейчас не популярно мериться достижениями в них с приятелями? Или покупать какие-то внутриигровые ништяки за реальные деньги?
Если так, то вышеупомянутая "мобильная игра" по сути будет мощной и совершенно аутентичной автоматизированной системой с серьезной проработкой вопросов производительности (дабы на всех хватило), надежности (достижения, сохраненки) и информационной безопасностью (антифрод, платежи). Само приложение для мобильного устройства в масштабах такой АС будет разве что "приложением к".
Вся смысловая риторика автоматизации как процесса замены участков человеческой деятельности автоматизированными и автоматическими функциями...
Применима. В данном случае имеет место замена экзистенциально досуга ("во поле березу заломати") досугом автоматизированным, виртуальным.
...с сокращением затрат (времени, усилий и/или стоимости) совершенно не применима к игре.
Сокращения затрат, к примеру, это совершенно необязательный атрибут автоматизации. Вместо него может фигурировать существенное увеличение обрабатываемых объемов данных, и/или же получение каких-то принципиально новых возможностей. Порой по принципу "мы за ценой не постоим".
Что касается применимости перечисленного к игре, склонен не согласиться. Виртуальное катание в танке обойдется дешевле, быстрее и легче, чем реальное.
Игра наоборот стремится увеличить время и затраты в целом, проводимые в игре, что делает её более похожей на медиапродукцию.
А это никак к сути автоматизации не относится. Это уже ближе к маркетингу.
Единственное место, где может быть полезен ГОСТ 34 — при разработке бэкенда для системы, который будет представлять собой полноценную автоматизированную систему.
Именно. Если наша игра не имеет "бэкэнда" и является лишь загружаемым автономным приложением, тогда да - использовать 34 ГОСТ там полезно разве что тем, кто к нему привык. Насиловать непричастных не стоит. Но много ли сейчас таких (за исключением инди-энтузиастов)? Сомневаюсь. Все хотят копеечку.
Давайте, в конце концов, посмотрим, что из основного состава ГОСТ 34.602 может хоть в принципе иметь какое-то отношение к мобильной игре:
Давайте.
2.6.1. В подразделе «Требования к системе в целом» указывают:
1. требования к структуре и функционированию системы; — в лучшем случае это геймплей + карта навигации + структура игрового мира. но как именно называние их таким образом поможет — не ясно
Или же:
1. Подсистема управления навыками персонажа
2. Подсистема навигации на глобальной карте
3. Подсистема внебоевого перемещения на локальной карте
4. Подсистема боестолкновения
5. Подсистема НСИ (характеристики видов вооружения, брони, моделей техники и т.п.)
6. Подсистема расчета урона
И взаимосвязи этих подсистем - что и зачем передается из одной в другую.
2. требования к численности и квалификации персонала системы и режиму его работы; — не применимо, у самой игры персонала нет
При наличии бэкэнда будет полный штат с начальниками, инженерами (включая дежурных), программистами, техподдержкой, пиаром и прочими.
3. показатели назначения; — ну да, игра должна затягивать и приносить миллион долларов в месяц. но это не задание для программиста
Скорее, это снова про бэкэнд. Предельное количество пользователей, пиковые нагрузки, сроки хранения данных и т.п.
5. требования безопасности; — не применимо, если не считать ограничения на использование мельтешаших цветов и недопущение развития нервных расстройств, припадков эпилепсии и депривации сна. но чтобы это правильно сформулировать, нужно знать хоть что-то из эргономики, когнитивной психологии и социологии
Это про бэкэнд. Чтобы инженера током не ударило, сервером не зашибло, в кондиционер не затянуло.
6. требования к эргономике и технической эстетике; — даже ISO 9241/9126/25010 практически ничего не говорят о том, как задавать требования к графическому дизайну. я тоже не знаю
А вот сюда уже про эпилепсию игроков. Как именно про нее писать - разумеется, ГОСТ 34 не указ.
И много про эргономику бэкэнда. У нас же вроде и по юзабилити недавно какой-то переводной ГОСТ вышел. Им можно воспользоваться, при желании.
7. требования к транспортабельности для подвижных АС; — не применимо
Да. Пункт достаточно редко используется. Не так уж часто встречаются мобильные АС . По крайней мере, в мирной сфере.
8. требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; — не применимо
Бэкэнд в полный рост.
9. требования к защите информации от несанкционированного доступа; — любой продакт с минимальным опытом игры не забудет, что аккаунт должен быть с паролем
Если есть аккаунт с паролем - значит, это уже не просто автономное приложение (за исключением редких случаев). Значит, есть бэкэнд. А любой продакт с такой АС не забудет, что там в информационной безопасности гораздо больше, нежели защита паролей. Да хоть отлов читеров - он тоже может быть включен в этот раздел.
11. требования к защите от влияния внешних воздействий; — не применимо или нужно подходить очень творчески
Просто считается, что в этом деле все по умолчанию хорошо. И не надо думать про возможное подтопление серверной, задымление помещений персонала и т.п. Потому на практике применяется редко.
13. требования по стандартизации и унификации; — есть в стандарте на софт
Да, можно взять оттуда, дабы не изобретать велосипед.
-
Смотрим дальше,
Как это маппировать на игру? Я не понимаю.
Например, функции:
1. Управления инвентарем персонажа
2. Вооружения персональным оружием (например, взятие наизготовку штурмовой винтовки)
3. Вооружения тяжелым оружием (за зенитное орудие усесться, например)
и т.п.
Там будет и качество, и время выполнения, и одновременность выполнения (нельзя одновременно приготовиться использовать АК47 и зенитку). В "перечень и критерии отказов" можно поместить возможные варианты недопустимого с точки зрения игровой механики поведения игрока и реакцию АС на него. Например, сообщение "Зачем ты схватился за АК внутри танка?" - и отказ функции "вооружение персональным оружием".
-
Технического, метрологического, организационного и методического обеспечения у игры не существует.
Математическое, информационное и лингвистическое обеспечение раскрываются в геймплее. Творческая раскладка геймплея на эти 3 категории скорее всего ничего не даст.
Смотря что мы называем "игрой". В том контексте, в котором я писал выше (с бэкэндом) - всё будет.
Не совсем понятно, что подразумевалось под "раскрываются в геймплее" например, по отношению к математическому обеспечению. На примере алгоритмов расчета урона при попадании различными видами боеприпасов в различные игровые объекты. Алгоритмы в ТЗ могут быть достаточно сложные (или наоборот), а до игрока в геймплее или мануалах может доводиться их аппроксимация в тех форме и объеме, которые задуманы игровым дизайнером для того, чтобы игрокам было интересно.
-
Алгоритмы в ТЗ могут быть достаточно сложные (или наоборот), а до игрока в геймплее или мануалах может доводиться их аппроксимация в тех форме и объеме, которые задуманы игровым дизайнером для того, чтобы игрокам было интересно.
При разработке игры ТЗ (в том понимании, в котором оно есть в ГОСТ) не пишется. А пишутся: CDD (Concept Design Document) -> GDD (Game Design Document) -> TDD (Technical Design Document). Алгоритмы никогда не пишутся в CDD и GDD - вместо этого геймдизайнер может описать конкретные ситуации, на примере которых видно, как должна себя вести игра в целом или конкретный ИИ. Т.е. описываются характерные ситуации. Алгоритмы могут быть описаны в TDD, но и то - вряд ли детально. По большей части, TDD служит в качестве перечня технических задач с указанием их оценки.
-
При разработке игры ТЗ (в том понимании, в котором оно есть в ГОСТ) не пишется. А пишутся...
Не понял, что Вы хотели сказать. Что разработку игры можно сопровождать разным набором документов (например, перечисленных), в зависимости от личных/отраслевых привязанностей и предпочтений? Даже не сомневаюсь. :)
-
Не понял, что Вы хотели сказать. Что разработку игры можно сопровождать разным набором документов (например, перечисленных), в зависимости от личных/отраслевых привязанностей и предпочтений? Даже не сомневаюсь. :)
Личные привязанности я бы здесь исключил. Более правильно, на мой взгляд, использовать словосочетание "отраслевые стандарты". Но дело не только в названии, но и в содержании документов, в их авторах (а они - разные) и тем, кому эти документы адресованы.