61

Управление Проектом / Re: TeamLeader + Manager Project для управления проектом, командой и графиком работы

« : 13 Апреля 2015, 16:16:08 »

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

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

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

Это еще что за зверь? Менеджеры по работе с клиентами в колл центрах сидят на телефонах:) Может кого другого имели в виду?

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

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

На счет выделением и оценкой трудоемкости задач я не знаю ничего.

Ну, если вы определитесь что хотите, выделение задач проблем не составит. Оценивать задачи должны их исполнители. Потом вы приложите риски и посмотрите на сроки. Они сразу разойдутся с желаемыми и тут можно будет сделать три вещи:
1. Уменьшить scope проекта.
2. Сдвинуть сроки.
3. Вешать лапшу на уши заказчику что вы успеваете, а когда сроки будут сорваны, просто скажете что "ну вот так получилось, но осталось же чуть-чуть, потерпите"

По поводу рисков почитайте "Вальсируя с медведями" ДеМарко и Листера. Там на пальцах рассказывают что такое риски в разработке ПО и почему их надо учитывать.

62

Управление Проектом / Re: TeamLeader + Manager Project для управления проектом, командой и графиком работы

« : 13 Апреля 2015, 11:03:13 »

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

63

Для всех / Re: Периоды разработки бизнес приложения и соответствующие типы проектной документац

« : 24 Марта 2015, 18:09:55 »

зато все уверены, что применяется одно из базовых принципов Agile: "Working software over comprehensive documentation" - Работающая программа важнее, чем подробное документирование.

Жаль только, что куча людей понимает этот принцип как "Нахрен документацию, мы же крутые и работаем по Agile/Scrum/XP/Kanban!"

64

О Сайте и Форуме / Re: А у нас новый сайт!

« : 25 Февраля 2015, 16:21:31 »

Красивый, мне нравится!

65

О Сайте и Форуме / Re: Что Вам не хватает на сайте?

« : 27 Января 2015, 16:45:46 »

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

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

ЗЗЫ: Лично мне, ссылки "Новые сообщения с последнего визита" более чем достаточно. Не помню случаев чтобы за сутки появились сообщения более чем в десяти тредах.

А на дату треда-то я и не посмотрел:))))

66

IDEF ARIS BPMN и пр. / Re: BPMN диаграмма туристического похода

« : 14 Января 2015, 12:43:49 »

-

67

IDEF ARIS BPMN и пр. / Re: BPMN диаграмма туристического похода

« : 14 Января 2015, 12:36:49 »

Спасибо за критику!
Я пытался смоделировать общую концепцию походов, в которые я ходил. И в недолгие - подмосковные, и в дальние - Хибины, Карелия.

Тут одна большая стратегическая ошибка, как я вижу.
Понятно о чем диаграмма (пусть и с ошибками), но не понятно для кого.
Например, "согласовать маршрут" - подразумевает что его читающий диаграмму должен согласовать с кем-то.
С кем? Кто должен это делать? Каждый участник? Не ясно из схемы.
Дальше, кто определяет силу и слабость? Какой оценочный критерий?
Кто занимается выдачей снаряжения? Все подряд или один человек?
И так далее.

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

А потом бы уже исправлял ошибки из разряда "почему мы постоянно собираем рюкзак, но ни разу не разбираем"

68

IDEF ARIS BPMN и пр. / Re: BPMN диаграмма туристического похода

« : 12 Января 2015, 09:59:55 »

Добрый день!

Когда вы рисовали схему для парикмахерской - это имело практический смысл.
Но зачем рисовать в этой нотации туристический поход?
Зачем описывать это как бизнес-процесс?

69

Идеи и мозговой штурм / Re: Требования к будущему бизнес-аналитику

« : 29 Декабря 2014, 11:33:38 »

davvol, а Вас послушать, что болтавня - это и есть выявление требований.

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

Например, я послушав конечную цель Заказчика, сама пытаюсь предложить два-три варианта решения. Либо он добавляет/поправляет, либо выбирает. Поэтому особо общаться нет необходимости.

Ну, это и есть общение, в общем-то

Для меня коммуникации - это последнее качество на которое я обращу внимании при приеме аналитика на работу. 

Дело хозяйское 

70

Проектирование / Re: Помогите в Visio

« : 29 Декабря 2014, 09:10:40 »

если бы он мне помог я не написал бы сюда

Думаю вот эта ссылка вам пригодится!
http://lmgtfy.com/?q=diagram+dfd+visio

71

Идеи и мозговой штурм / Re: Требования к будущему бизнес-аналитику

« : 29 Декабря 2014, 09:07:03 »

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

Не любимая всеми это кем? А если я ее люблю? Получается уже не всеми:)
Ну и мне непонятно, почему общение с заказчиком, высокомерно сводится к негативному слову "болтовня"?
Как будто он вам уже денег должен заранее, а вы "так и быть" согласны помочь этому никчемному человечишке с его жалкими просьбами

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

Не "не верны", а "неверно выявлены"

72

Идеи и мозговой штурм / Re: Требования к будущему бизнес-аналитику

« : 26 Декабря 2014, 15:59:01 »

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

Я от этого и не уходил:)
А вот интересно, у каждого аналитика свой "самый главный вопрос"?

73

Идеи и мозговой штурм / Re: С чего начать трудовой путь аналитика?

« : 26 Декабря 2014, 15:31:34 »

Неделя диванной психологии на юмл2.ру
 

74

Идеи и мозговой штурм / Re: Требования к будущему бизнес-аналитику

« : 26 Декабря 2014, 15:29:30 »

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

А по мне так лучше сразу прийти к заказчику и спросить самый важный вопрос: "А зачем?"
И внезапно может оказаться что ему не нужно копать Марианскую впадину, а хватит и бассейна в котором он на надувном матрасе будет плавать

75

Идеи и мозговой штурм / Re: С чего начать трудовой путь аналитика?

« : 26 Декабря 2014, 09:02:23 »

Странный вопрос... я думал тут серьезный форум.

Аналитики тоже люди!