Всем добрый день. Чтобы не писать целую поэму, сразу приступлю к делу. Я начинающий TeamLeader + Manager Project в небольшой команде энтузиастов,  которая в скоро перерастет в более серьезную команду на более серьезном уровне. Конечно сразу бросается в глаза смесь TeamLeader и Manager Project в одном лице, но пока только так можем. Наша отрасль: Игры  и приложения на мобильные телефоны, планшеты и другие носители. Имеется один проект на стадии релиза и уже подумываю над другим проектом. Идея есть, люди есть но как ними правильно управлять - я не знаю.  Интересует несколько вопросов к знающим людям  по поводу управления командой (проектом), по поводу написания настоящего качественного ТЗ, написание всего жизненного цикла приложения с помощью UML и самое главное - Возможность совместить UML+ ТЗ+ управление проектом и командой вместе.  Сильно извиняюсь за распространение дубликата темы, может есть такая информация здесь на форуме, но увы я не нашел ничего подобного. Итак, приступим к вопросам:
1.  Подскажите ссылки и ресурсы на тему "Как управлять командой, которая работает в направлении игростроения". Спрашиваю это, потому что  специфика управления простой командой, которая разрабатывает серверный проект, программное обеспечивание немного отличается от игростроения, особенно на мобильные платформы. Как начать управлять, ставить задания и рассчитывать время выполнения данного задания, кк управлять весь жизненый цыкл и не отставать от графиков?
2. Где достать пример написание технической документации от начала до конца.  Без воды в тексте а только конкретика. Хочется описать приложение от начала до конца и тогда приступить к реализации и управления работы в проекте.
3. Конечно чтобы управлять командой, в которой есть программисты, дизайнеры, художники, аниматоры, звуковые дизайнеры, нужно под каждого писать конкретное ТЗ. Интересует как интерпретировать информацию из главного документа в ТЗ для конкретного человека с конкретными заданиями на конкретной должности.
4. Если использовать UML, то где можно почитать информацию о процессе создания всего жизненного цикла с помощью UML, но на примере.  Чтобы я видел с чего начали, что дальше описали, когда описывать архитектуру, когда функциональные возможности и так далее.
5. Наверное самое главное:  Как можно совместить техническую документацию с диаграммами и использовать их  в качестве задания для конкретного человека.  Насколько важны диаграммы или может быть лучше акцентировать внимание на текстовой технической документацией?

P.S: Знаю что написал все и сразу, но лучше держать все в одном топике чем создавать разные. Хочется конкретики: Что, где, куда, для чего и где взять. Потому что о таких делах можно часами писать и говорить.

Так как людей, которые интересуются данной темой очень много, взял на себя смелости начать дискуссию на эту тему. Думаю модераторы разрешать делится ссылками на ресурсы и ПО для всех нужд менеджера и лидера игрового проекта и не только. В раздумьях я понял что помимо игровых проектов, обязательно   будет разработка  простых приложений. И хочется конечно найти метод управления не в зависимости игровой проект это или нет.
Начну пожалуй с первого вопроса.  "Как управлять командой, которая работает в направлении игростроения и не только". Мы все знаем, что основными задачами лидера и руководителя являются:

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

 
С точки зрения управления версиями проекта, задачами для программистов, нам поможет Средства Управления версиями на подобии Team Foundation Server и других. Конечно в зависимости от движка создания игр, языка программирования или технологии для приложенийили. Давайте сначала не будем прикрепляться к конкретной технологии или языку. Главное понять основы управления. Как управлять версиями проекта и исходного кода мы знаем. Это безопасно, в таких системах можно задавать задания и следить за историей работы программистов. Но меня интересует вопрос: Как начать все планировать, запустить разработку проекта? Ведь чтобы запустить разработку - нужно техническое задание (ТЗ) для для команды. И причем для разных видов работ в проекте  - разные ТЗ. Нужно описать функциональные возможности проекта, чтобы работники поняли что нужно делать для них в будущем и какой продукт выйдет в конце. У просторах интернета я не могу  найти НОРМАЛЬНЫЙ пример написания ТЗ, главного документа еще и с использование UML. Но сейчас вопрос не стоит в UML описании приложения или игры. Это заставляет перейти к другому и третьему вопросу:
Где найти примеры написания документации. Именно шаг за шагом, какой документ идет первым, какой вторым и так далее. Тут я не могу рассказать ничего об этом.  Здесь надеюсь на Вашу поддержку.
На этом я пока все, потому что четвертый вопрос уже наступит тогда, когда будет UML проект и все техническая документация. Тогда и сможем поговорить за слияния двух видов документации.

Вот эту ссылку уже изучили? http://games.1c.ru/4_files/desdocpack.zip

Всем добрый день.

Здравствуйте, Павел.

Интересует несколько вопросов к знающим людям  по поводу управления командой (проектом), по поводу написания настоящего качественного ТЗ, написание всего жизненного цикла приложения с помощью UML и самое главное - Возможность совместить UML+ ТЗ+ управление проектом и командой вместе. 

С ходу начинаете мешать теплое с мягким. Вам управлять людьми надо или ТЗ научится писать?

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

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

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

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

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

Написание ТЗ не связано с управлением. У вас в команде есть аналитик? Или и ТЗ писать будете тоже вы?

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

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

5. Наверное самое главное:  Как можно совместить техническую документацию с диаграммами и использовать их  в качестве задания для конкретного человека.  Насколько важны диаграммы или может быть лучше акцентировать внимание на текстовой технической документацией?

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


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

Пока эти вопросы без ответа, нет смысла обсуждать такие мелочи как картинки в ТЗ.

Здравствуйте. Спасибо что ответили. Ух, много чего нужно обсудить.  Так начну по порядку.

С ходу начинаете мешать теплое с мягким. Вам управлять людьми надо или ТЗ научится писать?
И чем, по вашему отличается разработка игр от всего остального? С точки зрения управления, конечно.

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

Что касается ресурсов, могу посоветовать Стратоплан, мои коллеги и знакомые проходившие программы по управлению проектами остались все довольны.

Спасибо. Посмотрю и оценю.

Написание ТЗ не связано с управлением. У вас в команде есть аналитик? Или и ТЗ писать будете тоже вы?

Аналитика нет, пока я решил взять на себя это все. Выходит я аналитик, менеджер проекта, и TeamLeader. Понимаю что смешно, но доверять самый важный кусок начала работы кому-то пока я не хочу. Во первых я хочу научиться понимать весь процесс управления проектом, весь процесс работы проекта от начала и до конца. У меня есть два сценариста, но как я понимаю это не их работа писать ТЗ. ТЗ должен писать менеджер по работе с клиентами, но пока нет такого человека, значит работа висит на мне. Я думаю что если я буду писать ТЗ и управлять проектом, то буду видеть всю картину жизненного цикла проекта.

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

Это и меня интересовало. Спасибо. Просто я сейчас думаю как все совместить красиво.

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

Да. Вы наверное правы. Просто я первый раз столкнулся с потребностью серьезно браться за такой кусок работы. Сам я учился на Архитектора ПО. Имею представление о управлении проектами и о нотациях и о UML но только на уровни так сказать дипломной работы или курсовой, в которой ты разработчик, ты аналитик, ты менеджер, ты бухгалтер 

В вашем сообщении я не увидел является ли ваша разработка коробочной или заказной (кто является источником требований к продукту)?

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

Какую методологию разработки вы планируете использовать?
Является ли ваша команда действительно командой или это просто некий набор специалистов, возможно, даже территориально разобщенный?

На счет методологии я растерян. Я не знаю  какую лучше взять. Команда - это набор специалистов, "которые перерастают" в команду. Территориально мы раскиданы. Я в Польше, программисты в России, сценарист в Украине. Работа только через интернет и только общаемся по скайпу. Но это пока. В будущем хочу открыть небольшой офис и понемножку начинать расти дальше. ИЗ-за этого я хочу подготовиться к настоящему управлению. Чтобы знать что к чему. Как управлять и вжаться в сроки.

Кто формирует видение и цели проекта?
Кто занимается выделением и оценкой трудоемкости задач?

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

Вот эту ссылку уже изучили? 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