Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Pawelgronsky

Страницы: 1
1
Вы видели статьи Архипенкова и Селиховкина?
http://citforum.ru/SE/project/arkhipenkov_lectures/
http://citforum.ru/SE/project/selikhovkin/
Чего в них не хватает для работы?
Большое спасибо за литературу. Я искал в интернете много раз но на такое никогда не находил. Пробежался быстренько по заголовкам Архипенкова. Очень порадовало. Есть та суть которую я ищу. Есть процессуальность работы  поэтапно. Радует очень. СПАСИБО.

Ну тогда надо было сразу писать суть, типа "Помогите научиться управлять проектами", не теребя UML без надобности:)
Хотелось подойти научно, так сказать на хорошем уровне. У меня есть опыт описания ПО в UML, но как я говорил на уровне курсовых.

Это еще что за зверь? Менеджеры по работе с клиентами в колл центрах сидят на телефонах:) Может кого другого имели в виду?
Я не знаю как он называется точно, из-за этого я говорил что есть разница между проектом разработки ПО и игростроением. Игростроение уже так отдалилось от стандартных проектом приложений что нужно отдельно узнавать детали даже на уровне набора кадров. Я так понимаю что есть такой человек, по идеи, который занимается суто техническими документами. Эти документы он пишет для дизайнеров, программистов, программистов шейдеров, звуковых дизайнеров, арт-дизайнеров, левел-дизайнеров и тд. отдельно. Иными словами для каждого человека в команде есть документ в котором расписано что делать отдельно.  Но это пишется без сроков выполнения, без делайнов или "поддедлайной". А бы хотел совместить такое.

1. Уменьшить scope проекта.
2. Сдвинуть сроки.
3. Вешать лапшу на уши заказчику что вы успеваете, а когда сроки будут сорваны, просто скажете что "ну вот так получилось, но осталось же чуть-чуть, потерпите":)
По поводу рисков почитайте "Вальсируя с медведями" ДеМарко и Листера. Там на пальцах рассказывают что такое риски в разработке ПО и почему их надо учитывать.
Спасибо за ответ. Почитаю литературку, которую подкинул Denis Beskov. И буду понемногу описывать все что нужно и как нужно.

2
Не обижайтесь, но пока Вы ни то, ни другое, ни третье. Не морочьте себе голову.

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

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

Ну хорошо а что на счет литературы по управлению? Я искал книги конкретно по моим вопросам, но никогда не могу наткнуться на книгу или статью, где бы была выбрана тема для создания ПО, задачи  и от начала до конца расписано действие менеджера по проекту. Всегда одна вода. От что что а в этом деле мне не нравиться что ничего конкретного нет по такому поводу. Все настолько размыто что не могу.  Я понимаю что из-за разновидности заданий и нужд заказчика очень много, из-за этого такая литературе не конкретна а это как бы "основы для того,чтобы повернуть мозг менеджера на правильный шаг в работе" это очень хорошо, но в какой то мене плохо. Нет конкретики.

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

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

Да смотрел эти файлы. Есть что взят из них. Я так понимаю что при процессе написания ТЗ уже буду лучше видеть что нужно.

4
Здравствуйте. Спасибо что ответили. Ух, много чего нужно обсудить.  Так начну по порядку.
С ходу начинаете мешать теплое с мягким. Вам управлять людьми надо или ТЗ научится писать?
И чем, по вашему отличается разработка игр от всего остального? С точки зрения управления, конечно.
Сложилось так, что я собрал пол года назад команду, и мы просто занимались проектами как OpenSourse на уровни хобби.  Но со временем все переросло в более серьезный масштаб. И сейчас у нас релиз игры.  И в скорейшем времени  мы приступим к следующему проекту. И для этого я хочу быть готовый и "напичканым"  знаниями  ;D
Что касается ресурсов, могу посоветовать Стратоплан, мои коллеги и знакомые проходившие программы по управлению проектами остались все довольны.
Спасибо. Посмотрю и оценю.
Написание ТЗ не связано с управлением. У вас в команде есть аналитик? Или и ТЗ писать будете тоже вы?
Аналитика нет, пока я решил взять на себя это все. Выходит я аналитик, менеджер проекта, и TeamLeader. Понимаю что смешно, но доверять самый важный кусок начала работы кому-то пока я не хочу. Во первых я хочу научиться понимать весь процесс управления проектом, весь процесс работы проекта от начала и до конца. У меня есть два сценариста, но как я понимаю это не их работа писать ТЗ. ТЗ должен писать менеджер по работе с клиентами, но пока нет такого человека, значит работа висит на мне. Я думаю что если я буду писать ТЗ и управлять проектом, то буду видеть всю картину жизненного цикла проекта.
Обычно, диаграммы это часть ТЗ, которые наглядно поясняют сопровождающий  текст. Картинки  понятнее чем тонна текста, по этому их и используют:)
Это и меня интересовало. Спасибо. Просто я сейчас думаю как все совместить красиво.
Павел, у меня сложилось впечатление что вы зациклились на UML (по большому счету не имеет значения, использовать его или нет) не решив по настоящему важных вопросов.
Да. Вы наверное правы. Просто я первый раз столкнулся с потребностью серьезно браться за такой кусок работы. Сам я учился на Архитектора ПО. Имею представление о управлении проектами и о нотациях и о UML но только на уровни так сказать дипломной работы или курсовой, в которой ты разработчик, ты аналитик, ты менеджер, ты бухгалтер  ;D ;D
В вашем сообщении я не увидел является ли ваша разработка коробочной или заказной (кто является источником требований к продукту)?
Скажем разработка коробочная и нет. Источник требований к продукту мы сами. Идеи мои, сроки расставляю я сам, требования мои. Выходит что заказчика нет. Команда работает сама на себя. Из за этого у мне не понятно со всем. Потому что если брать статьи и литературу по управлением проектами, все опираются на заказчика и это понятно. А мне как поступать если заказчика нет, ресурсы будут браться от предыдущего проекта который сейчас в релизе.
Какую методологию разработки вы планируете использовать?
Является ли ваша команда действительно командой или это просто некий набор специалистов, возможно, даже территориально разобщенный?
На счет методологии я растерян. Я не знаю  какую лучше взять. Команда - это набор специалистов, "которые перерастают" в команду. Территориально мы раскиданы. Я в Польше, программисты в России, сценарист в Украине. Работа только через интернет и только общаемся по скайпу. Но это пока. В будущем хочу открыть небольшой офис и понемножку начинать расти дальше. ИЗ-за этого я хочу подготовиться к настоящему управлению. Чтобы знать что к чему. Как управлять и вжаться в сроки.
Кто формирует видение и цели проекта?
Кто занимается выделением и оценкой трудоемкости задач?
Видение и цели проекта формирую я. Мне кажется это лучше пока, потому что от себя легче оттолкнуться на счет всех требований.  На счет выделением и оценкой трудоемкости задач я не знаю ничего. С этим увы не работал в таком реальном проекта и бес понятия.
Я понимаю что стразу в первом посте и сделал кашу, но Вы только направьте меня, в какую сторону мне начать развиваться и искать информацию. Чтобы как-то по шагу делать по ступеньки. А то у меня самого каша капитальная на счет этого Время конечно есть но лучше начать раньше чем потому ночами сидеть.

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



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

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

Страницы: 1