14.09.2010 19:03, sharpcoder пишет:
>
> Выгоды регламентированного рабочего дня:
> 1. хорошо для команд, работающих над одним проектом. Когда разные
> участники команды приходят в разное время — усложняются коммуникации,
> снижается эффективность.
Это ваш самообман. В таком варианте часто эффективность наоборот
повышается — не мешают друг другу.
> 2. хорошо для сотрудников, которые могут контактировать с клиентами.
> Когда звонит клиент в рабочее время (допустим в 10), а нужный сотрудник
> еще не пришел — клиент не доволен.
> 3. не нужно считать рабочее время.
> 4. часть сотрудников, если им предоставить свободу, начинают приходить
> позже и позже. Обычно со временем начинают приходить к часу, и
> откровенно не дорабатывать.
Не дорабатывать часы или задачи?
Если задачи, нафига вы их держите?

>
> Критичные, как правило, пункты 1 и 2.
ИМХО, критичный только п. 2

Здравствуйте, genre, Вы писали:

G>Здравствуйте, k.o., Вы писали:

KO>>А зачем их столько? Микроменеджментом увлекаемся?

KO>>А можно пример из жизни, когда постоянно нужно задавать порядок выполнения всех задач? Редкие, исключительные ситуации не интересуют.

G>Всех конечно не надо, но постоянно надо на один больше чем есть.
G>Пример был выше по ветке. Допустим у девелопера 20 задач. Отсортированных по трем приоритетам: высокий, средний, низкий. Нужная тебе задача в списке задач с высоким приоритетом. Но, там таких 5 штук, а тебе надо чтобы твоя была сделана до завтра. Тогда приходиться либо заводить еще один приоритет, либо пинать разработчика.

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

G>Но вообще мы удаляемся от темы. Речь шла про то, когда тестер (а вообще неважно и девелопер тоже) начнет работать над срочным тикетом. Утверждается, что в случае если он уже на месте, то при наличии пинка все закрутиться быстрее чем без него.

Речь шла о том, что разработчик не смог отдать результат тестеру, потому, что его уже не было на работе и утром тестер не знал, что ему делать, потому что разработчика в это время ещё не было. Я утверждал, что использование e-mail/issue-tracker решило бы эту проблему, на что мне пытались возразить, что только личное присутсвие разработчика возле тестера может заставить последнего начать работу.

Здравствуйте, k.o., Вы писали:

KO>Это абстрактный пример, я хочу пример из жизни, когда в течение работы над проектом нужно всегда иметь строго определённый порядок для всех задач.

Зачем? Я выше написал, что дело не в этом. Но если хочешь — при разработке нового проекта с нуля это вообще нормальная ситуация когда процесс параллелиться не на 100 несвязных задач, а на несколько групп последовательных.
Так же бывает и с багами, когда например бага распределена по разным подсистемам и надо начинать фиксить в строгом порядке.

KO>Вобще наличие кучи задач с самым большим приоритетом выглядит очень странно, как правило, это уже задачи, которые "нужно завтра, а ещё лучше вчера".

это называется нашел к чему придраться
ну пусть в моем примере будет 10000 тикетов со средним приоритетом и 10 с высоким.

G>>Но вообще мы удаляемся от темы. Речь шла про то, когда тестер (а вообще неважно и девелопер тоже) начнет работать над срочным тикетом. Утверждается, что в случае если он уже на месте, то при наличии пинка все закрутиться быстрее чем без него.

KO>Речь шла о том, что разработчик не смог отдать результат тестеру, потому, что его уже не было на работе и утром тестер не знал, что ему делать, потому что разработчика в это время ещё не было. Я утверждал, что использование e-mail/issue-tracker решило бы эту проблему, на что мне пытались возразить, что только личное присутсвие разработчика возле тестера может заставить последнего начать работу.

Решило бы, и конечно решает, кроме того случая когда проблема с приоритетами.

Здравствуйте, Armadilio, Вы писали:

A>Здравствуйте, sharpcoder, Вы писали:


S>> 4. часть сотрудников, если им предоставить свободу, начинают приходить позже и позже. Обычно со временем начинают приходить к часу, и откровенно не дорабатывать.

A>платить за результат не пробовали?

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

Но, я почти не видел тех, кто хочет так работать...

Здравствуйте, Vzhyk, Вы писали:

V>14.09.2010 19:03, sharpcoder пишет:
>>
>> Выгоды регламентированного рабочего дня:
>> 1. хорошо для команд, работающих над одним проектом. Когда разные
>> участники команды приходят в разное время — усложняются коммуникации,
>> снижается эффективность.
V>Это ваш самообман. В таком варианте часто эффективность наоборот
V>повышается — не мешают друг другу.

Что за уровень культуры у вас такой, что мнение другого человека сразу назвать самообманом?

Да, то, что люди не мешают друг другу это "бегунок эффективности" двигает в сторону повышения. То, что ломаются коммуникации — двигает его в сторону снижения. Для наших проектов коммуникации важнее.

>> 2. хорошо для сотрудников, которые могут контактировать с клиентами.
>> Когда звонит клиент в рабочее время (допустим в 10), а нужный сотрудник
>> еще не пришел — клиент не доволен.
>> 3. не нужно считать рабочее время.
>> 4. часть сотрудников, если им предоставить свободу, начинают приходить
>> позже и позже. Обычно со временем начинают приходить к часу, и
>> откровенно не дорабатывать.
V>Не дорабатывать часы или задачи?

С чем вы спорите? С тем, что средний работник за 8 часов работы выполняет больший объем, чем за 5?

V>Если задачи, нафига вы их держите?

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

>>
>> Критичные, как правило, пункты 1 и 2.
V>ИМХО, критичный только п. 2
Сразу видно, что у вас огромный опыт организации команд и руковосдтва коллективами

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

Здравствуйте, genre, Вы писали:

G>Если бага у клиента вылезет в 2:38 то ему скажут, извини чувак, ночь, будет рабочее время — будем фиксить. И это намного более вменяемо чем, извини чувак, наши девелоперы болтаются хз где, как придут так будем фиксить.

Ему скажут — что наши инженеры уже разбираются с проблемой. Как придут — исправят.
Если ошибка у него вылезет не в 11 утра, а в 7 вечера, то есть вероятность, что люди не разбежались по домам, а только с обеда пришли и рабочий день в самом разгаре, просто немного смещён.

Здравствуйте, genre, Вы писали:

G>Могут конечно исправляться в том порядке который устраивает того, кто над ними работает. Но это в идеальном мире. А в реальном мире среди этих 10 high тикетов тоже нужно расставлять приоритеты. И вместо заведения десятков градаций приоритетов (что очевидно не работает) используется метод "Вась, глянь мой тикет первым", что вполне работает в подавляющем большинстве случаев, а исключительные ситуации обрабатываются отдельно уровнем выше.

Значит приоритеты выставляются неверно. Не бывает такого, что все задачи срочные. Если я должен сегодня сделать 10 срочных задач по 5 часов каждая, то это значит, что мне нужно несколько помощников.
И какая разница как я выберу из срочных задач более приоритетную. Если у меня есть срочные задачи — то я работаю. Выбираю их в произвольном порядке. Что изменится, если придёт Вася, даст мне пенделей и скажет, что его задача более срочная? А потом придёт Петя и скажет, что его задача не менее срочная? Мне что в таких случаях сразу к директору бежать и просить его расставить приоритеты?

Здравствуйте, genre, Вы писали:

KO>>Увы, всё-таки, оказалось, что приоритеты реальности не соответсвуют, может основная проблема в этом? И да, в реальном мире, нужно правильно расставлять приоритеты, реальный мир он такой.

G>Невозможно завести приоритетов столько сколько всего есть задач.

Достаточно разделить их на группы:
1. Желательные. Если будет возможность, то сделать. Если не сделать, то ничего страшного не случится.
2. Мелкие улучшения к релизу.
3. Регрессии, появившиеся после последнего комита.
4. Ошибки, найденные нашими тестерами.
5. Ошибки, найденные не нашими тестерами.
6. Ошибки, без которых наша система бесполезна(главная функция работает неверно).
7. Программа вообще не запускается, падает, портит данные.

Здравствуйте, sharpcoder, Вы писали:

S>Я был бы рад платить на 50% больше при условии достижения запланированного самим же сотрудником результата, и при его согласии не получть деньги пока не будет достигнут запланированный рузультат.

S>Но, я почти не видел тех, кто хочет так работать...

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

Плюс тут возникает задача планирования и оценки времени. Не все это умеют и не всегда можно быстро оценить. Иногда на оценку времени может уйти до 50% всего проекта.

A>Так ты хочешь, чтобы человек на себя взял риски, что не успеет что-то сделать, а платить за это готов только 50%. Это стоит значительно дороже.

Сколько это стоит?

A>Не все это умеют и не всегда можно быстро оценить.

Это точно. Во всяком случае намного больше людей утверждают, что они за 6 часов делают столько, сколько "обычный" человек делает за 8 часов Но вот сделать за 8 часов то, что они сами были готовы сделать за 8, почему-то не выходит. И удивляются потом, почему никто не стремится сделать им свободный график.

Здравствуйте, k.o., Вы писали:

KO>Речь шла о том, что разработчик не смог отдать результат тестеру, потому, что его уже не было на работе и утром тестер не знал, что ему делать, потому что разработчика в это время ещё не было.

Тестер без разработчика не знает, что ему делать?
Бардак и есть.

Здравствуйте, Donz, Вы писали:

D>Просьба ответить работодателям.

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

Здравствуйте, genre, Вы писали:

G>Если бага у клиента вылезет в 2:38 то ему скажут, извини чувак, ночь, будет рабочее время — будем фиксить. И это намного более вменяемо чем, извини чувак, наши девелоперы болтаются хз где, как придут так будем фиксить.

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

Здравствуйте, Она На Нас Ий, Вы писали:

ОНН>Работодатель — это юрлицо

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

Здравствуйте, sharpcoder, Вы писали:

S>Я был бы рад платить на 50% больше при условии достижения запланированного самим же сотрудником результата, и при его согласии не получть деньги пока не будет достигнут запланированный рузультат.

S>Но, я почти не видел тех, кто хочет так работать...

фрилансеры именно так работают. но очень серьёзно встаёт вопрос о контроле качества — сделать вроде одно и то же можно совершенно по разному

Здравствуйте, alzt, Вы писали:

A>Так ты хочешь, чтобы человек на себя взял риски, что не успеет что-то сделать, а платить за это готов только 50%. Это стоит значительно дороже.

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

Здравствуйте, Она На Нас Ий, Вы писали:

ОНН>Здравствуйте, Donz, Вы писали:

ОНН>Работодатель — это юрлицо (т.е. не хомо сапиенс) с почтовым адресом,
ОНН>куда нельзя доставить почту и нет ни звонка, ни интеркоммуникатора, ни почтового ящика у двери,а зачастую и самой двери нет

що, и сайта с контактной информацией тоже нет?

Здравствуйте, Eudjinn, Вы писали:

E>Окей, проехали. Развивать тему не вижу смысла, мнение работников мне и так известно.

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

Здравствуйте, Она На Нас Ий, Вы писали:

D>>Просьба ответить работодателям.

ОНН>Вы у кого спрашиваете?
ОНН>Работодатель — это юрлицо (т.е. не хомо сапиенс) с почтовым адресом,
ОНН>куда нельзя доставить почту и нет ни звонка, ни интеркоммуникатора, ни почтового ящика у двери,
ОНН>а зачастую и самой двери нет

А если вдуматься в контекст вопроса?
Очевидно, что вопрос тем, кто нанимает и руководит персоналом и имеет влияние на распорядок рабочего дня.