Распорядок задач в работе

[ЗадающийВопросы]

Тема касается способы выполнения длительных проектов. Большие проекты разбиваются на более маленькие задачи, и те в свою очередь разбиваются на под задачи. Можно и дальше делить всё вплоть до атомов

 

Способов выполнения задач может быть много, я все их не знаю. Знаю лишь два:

 

1) - "Водопад". Вы видели водопад, как вода льётся сверху, ударяется о верхние камни, с них на тех, что под ними, и так далее всё ниже и ниже? В проекте это выражается в том, что сначала выполняется первый этап, потом второй, потом третий. Работа переходит с одного камня на другой, пока не достигается финиша. При этом должен быть точный план действий, расчёт, и порядок.

 

2) - "Паззл". Паззл можно начать с любой стороны, с любого угла, хоть даже с середины. И можно постоянно прыгать от одной точки к другой. В проекте это выражается тем, что человек постоянно мечется между разными задачами, делая чуть чуть отсюда, чуть чуть оттуда. Чёткий план действий здесь не нужен, нужна лишь конечная цель. Все части паззла надо собрать в единое целое.

 

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

 

Как вы думаете, какой метод является наиболее эффективным для коммандной работы. Или, если это возможно, как совместить труды людей, которые работают такими вот разными методами?

[Red forever]

Это зависит от вида задачи и от состава команды.

[ЗадающийВопросы]

Это зависит от вида задачи и от состава команды.

 

Я понимаю что это зависит от вида задачи и состава команды. В команде разные люди. Одни любят порядок и чёткий план, другие любят "паззлы" и отсутствие распорядка действий.

[Red forever]

Я понимаю что это зависит от вида задачи и состава команды. В команде разные люди. Одни любят порядок и чёткий план, другие любят "паззлы" и отсутствие распорялка действий.

Это только в салат чего только не пихают.

А команду, если это команда , нужно отбирать под конкретную задачу.

 

Впихивать человека под задачу - это идиотизм.

Под задачу выбирают людей.

 

Вначале цель - потом средства.

Человек , конкретный специалист - это средство решения задачи.

 

А у тебя все с ног на голову.

Нашел деталь и думаешь куда бы ее впихнуть.

В будильник или в сковородку.

 

По теме.

Людей ''пазлов'' можно использовать в проекте ''водопад'', если они решают ОБОСОБЛЕННЫЕ не связанные между собой микрозадачи.

Отдельные узлы, которые на данный этап в проекте ни на что не влияют.

[ЗадающийВопросы]

Это только в салат чего только не пихают.

А команду, если это команда , нужно отбирать под конкретную задачу.

 

Впихивать человека под задачу - это идиотизм.

Под задачу выбирают людей.

 

Вначале цель - потом средства.

Человек , конкретный специалист - это средство решения задачи.

 

А у тебя все с ног на голову.

Нашел деталь и думаешь куда бы ее впихнуть.

В будильник или в сковородку.

 

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

 

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

[Red forever]

Я дописала предыдущий пост , как использовать людей ''пазлов''.

Последний абзац.

[ЗадающийВопросы]

По теме.

Людей ''пазлов'' можно использовать в проекте ''водопад'', если они решают ОБОСОБЛЕННЫЕ не связанные между собой микрозадачи.

Отдельные узлы, которые на данный этап в проекте ни на что не влияют.

 

мм... А это идея. Я только надеюсь что таких задач будет достаточно.

[weaselman]

Есть третий способ, который сейчас используется, практически повсеместно, в мире софта. По-английски это называется Agile, a по-русски такого слова вообще нет, насколько мне известно.

Суть в том, что разработка делается итерациями. Задачи должны быть выполнимы в тепение короткого времени (3-5 дней в "классике") и при этом быть функционально законченными. То есть, выполнение каждой задачи, приносит какое-то видимое улучшение в продукт.

 

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

[ЗадающийВопросы]

Есть третий способ, который сейчас используется, практически повсеместно, в мире софта. По-английски это называется Agile, a по-русски такого слова вообще нет, насколько мне известно.

Суть в том, что разработка делается итерациями. Задачи должны быть выполнимы в тепение короткого времени (3-5 дней в "классике") и при этом быть функционально законченными. То есть, выполнение каждой задачи, приносит какое-то видимое улучшение в продукт.

 

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

 

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

[weaselman]

Это, может, и похоже на "паззл", в принципе, в чем угодно можно найти сходство, если присмотреться.

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

 

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

Отличие agile в том, что ты  с самого начала работаешь с "продуктом", а не разрозрозненными кусочками неизвестно чего, как в паззле, и "продукт" - это нечто реально существующее и работающее, а не туманное обещание чего-то, что можно будет поиметь через полгода, как в "водопаде".

[ЗадающийВопросы]

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

[weaselman]

Нет, это не водопад. Это противоположность водопада. На самом деле, термин "водопад", возник после изобретения agile, для того, чтобы оттенить разительное отличие старого от нового.

 

Ты же читаешь по-английски? Погули "waterfall vs. agile" или что-то в таком духе. Это сейчас везде применяется, среди-разработчиков софта, и, если ты хочешь делать бизнес в этой области, то это обязательно надо знать.

[Мarinka]

А почему обязательно нужно весь этот процесс как-то назвать? И чтобы все работали по одному и тому же принципу?

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

[ЗадающийВопросы]

А почему обязательно нужно весь этот процесс как-то назвать? И чтобы все работали по одному и тому же принципу?

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

 

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

 

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

 

А что бы удобнее было синхронно работать, я считаю что должен быть чёткий план действий. Мне легче работать по прнципу "водопад", кому то "паззлом", weaselman предложил вариант "Agile". Названия есть для того, что бы можно было одним словом обьяснить то, что обьясняется целым предложением.  

[Телефон]

 

Как вы думаете, какой метод является наиболее эффективным для коммандной работы. Или, если это возможно, как совместить труды людей, которые работают такими вот разными методами?

Второй метод не работает никогда. Из  воторго метода выходит куча мусора.

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

[weaselman]

Я еще хотел пояснить, "водопад" и "agile" (про паззл я нбе слушал никогда) - это методологии работы команды, а не отдельного человека (у тебя там про "паззл" так написано "человек мечется от одной задачи к другой").

 

Если в команде разные члены работают по разной методологии, то гнать надо менеджера

[ЗадающийВопросы]

Я еще хотел пояснить, "водопад" и "agile" (про паззл я нбе слушал никогда) - это методологии работы команды, а не отдельного человека (у тебя там про "паззл" так написано "человек мечется от одной задачи к другой").

 

Если в команде разные члены работают по разной методологии, то гнать надо менеджера

 

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

 

То есть если мы начнём работать методом "agile", то все члены комманды будут работать методом "agile". За исключением возможно того чела, который как посоветовала Барбара, будет выполнять задачи, которые никак не влияет на работу остальной комманды. Ну например Лого продукта или иконки рисовать. 

 

Второй метод не работает никогда. Из  воторго метода выходит куча мусора.

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

 

Кстати не согласен. Арт-дизайнеры обычно так и работают. И сценаристы очень часто тоже. "Паззл" - это для тех видов деятельности где надо очень сильно напрягать воображение. 

[Телефон]

 

 

Кстати не согласен. Арт-дизайнеры обычно так и работают. И сценаристы очень часто тоже. "Паззл" - это для тех видов деятельности где надо очень сильно напрягать воображение. 

Это не работа - это чет из творческой мазни.

[weaselman]

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

 

Речь идет о методологии работы команды. Помнишь Крылова: "Пока в товарищах согласья нет,на лад их дело не пойдет".

Этот, как раз про такие команды, где каждый работает как он "привык".

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

[ЗадающийВопросы]

Это не работа - это чет из творческой мазни.

 

"Творческая мазня" это очень важный элемент в игрострое

 

менеджмент - это не твое. 

 

Если не я, то кто?

Я уже пробовал передать "менеджмент" своему партнёру (которого я уже упомянал). Так там начинается много умных разговоров о том, "как надо"/"как правильно" делать, но при этом ноль действий. И вообще, среди всех своих знакомых у меня нету тех, кто был бы серьёзно настроен что бы сделать этот проект. Люди что то умеют, но без ясности, фокуса и цели прогресса не бывает. А поскольку я этим заинтересован больше остальных, то именно мне и следует возглавить процесс.

 

А так, "менеджмент" в его традиционном значении - это действительно не моё. 

 

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

[weaselman]

Менеджера тоже можно нанять, как и любого другого работника. В нормальных бизнеса, так, обычно, и происходит.

[Телефон]

"Творческая мазня" это очень важный элемент в игрострое

Ну и раз мазня в тему в игрострое, ни тогда спроси срок когда намажет, то че надо и не парься.