Re[4]: Вопрос работодателям. Насколько вам важен строгий раб - О работе

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

Достаточно важно, по ряду причин.

1. Спонтанная необходимость обсуждения технических деталей. Возникли вопросы, хочется обсудить, а на рабочем месте нет то одного, то другого. Тот пришел, другой ушел на обед. Другой вернулся с обеда, тот ушел на обед и в таком духе. А теперь представим, что разработчиков, с которыми надо обсуждать что-то (не одновременно, а в разных комбинациях) не двое, а два десятка и все любят гибкий график и не регламентированный обед.

2. Приходят пара сотрудников, сначала к 10, потом начинают приходить к 10:20, потом к 10:45, потом в 11:15. Сначала раз в две недели, потом два раза в неделю, потом 3 дня из 5. Глядя на них, остальные тоже начинают позволять себе вольности. Через несколько месяцев получаем отдел разработки, где все приходят когда хотят, уходят когда хотят и ходят на обед когда хотят. Хочешь собрать совещание с 3 участниками, и см. пункт 1. Окей, думаете вы, а почему бы не запланировать совещание заранее? На 10 не запланируешь — некоторые приходят к 11. Планируем на 11 — а такая же ерунда, люди отучились приходить вовремя.

Прелесть работы в одном офисе в том, чтобы упростить и ускорить коммуникации, тем самым ускорить решение вопросов, а с таким подходом, когда нужных людей не соберешь быстро, в чем тогда смысл?

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

В общем, как-то так.

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

E>1. Спонтанная необходимость обсуждения технических деталей. Возникли вопросы, хочется обсудить, а на рабочем месте нет то одного, то другого. Тот пришел, другой ушел на обед. Другой вернулся с обеда, тот ушел на обед и в таком духе. А теперь представим, что разработчиков, с которыми надо обсуждать что-то (не одновременно, а в разных комбинациях) не двое, а два десятка и все любят гибкий график и не регламентированный обед.

Никакой спонтанной необходимости обсуждения технических деталей не бывает. Бывает плохой менеджмент, способный убить эффективность на корню.
Все обсуждения, для которых требуется присутствие более чем одного человека, необходимо планировать, причем совсем не по той причине, что народ когда хочет, тогда и приходит.

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

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

G>На stand up митингах каждый программист рассказывает, что он сделал вчера и что собирается сделать сегодня. Что это как не контроль сотрудника?

Черт, как хреново жить с развитым воображением. Мне живо представилась сцена(все имена вымышлены, совпадения случайны):

- Так господа, уже 9.00, подходим, становимся в кружочек. Сегодня, как и всегда, мы будем говорить о ваших задачах. Вот ты, Сашенька, что за вчера сделал?
— Я, ~~Марьванна~~ Сергей Петрович, вчера добавил в формочку "Клиенты" кнопочку "изменить имя домашней собачки друга". Теперь у нас есть невероятно полезный, и точно отсутствующий у конкурентов функционал!
— Молодец, Сашенька, завтра исправишь баг, из-за которого вводимою клиентами информация о воинской повинности попадает в "семейное положение", и люди нервничают, полагая, что это проделки спецслужб. А вот ты, Танечка, что вчера сделала?
— А я, Сергей Петрович, ~~откомментила три сотни фоток вконтактике и подняла себе рейтинг и ЧСВ~~ написала запросик к базе данных, теперь у нас есть отчетик, позволяющий узнать среднее количество лет наших клиентов, а также среднюю температуру у них дома. А еще Тимур мне непристойности по аське слал, ходил 12 раз в туалет, и каждый раз, проходя туда, внимательно смотрел на мою грудь!
— Молодец, Танечка, завтра напишешь отчетик, выясняющий средний рост клиентов. Тимур! ~~Даа, на такие сиськи попробуй не посмотри... А вот дрочить в туалете можно только мне!~~ Как ты мог? Чем ты занимался вчера на рабочем месте?
— А я, Сергей Петрович... ~~Вот пристал, мне в отпуск через 3 дня, ничерта я не делал~~ Весь день систематизировал все, что я сделал раньше, читал книги по технологии "программирование через жопу: советы професси#налов", писал документацию к написанному ранее коду.
— Ладно, Тимур, продолжай в том же духе, документация и саморазвивающиеся люди нам нужны.

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

хочу добавить что я лично фанат сдвинутого графика, можно сказать, жизни

например раньше, когда я в одной конторе работал, у нас до 11 была давка в маршрутку. приходишь в 11 — она пустая
идешь на обед в час — народу море — полчаса простоишь и еще не поешь спокойно
приходишь в два часа — пусто
аналогично со всем остальным

если делать полностью сдвинутый график работы относительно жизни города, тогда везде, куда ты ни приходишь, по какой дороге ни поедешь, везде пусто и спокойно, нет ни потери времени, ни нервов.

GIV>>2) должен отработать Х*8 часов в месяц, где Х количество рабочих дней в этом месяце.

8>Вот это меня всегда удивляло. Типа не меньше 40 часов в неделю.
8>В итоге люди зачастую просто сидят, насижывают эти часы и ничего при этом все равно не делают.
8>Лучше пусть пойдет своими делами займется, главное что бы поставленные задачи успевал сделать
8>к сроку. Тут конечно много нюансов, но все же.

Многие сотрудники с удовольствием укажут на КЗОТ, если вдруг потребуется в сложной ситуации поработать больше 40 часов, но вот почему-то желание работодателя, чтобы с пользой было потрачено все положенное по закону, оплачиваемое, замечу, время, вызывает такое искреннее удивление

Ну ладно, мы не наивные, мало кто реально работает 8 часов в день, но стоит допустить это отклонение в меньшую сторону официально, сразу получатся много нюансов:
— на сколько меньше можно, а сколько уже нельзя? на 2 часа? на 5? на 10? вообще все равно, лишь бы задача была решена? А может задач можно больше сделать просто за это время?
— допустим, если задачи выполнены вовремя, то можно прогулять, а что если они выполнены не настолько качественно, как могли бы, если потратить эти прогулянные часы, например, на комментирование кода? Или на лишний тест? А почему бы именно это и не сделать, раз появилось время?

И многое другое

Где-то должна быть проведена формальная черта, а неформально допускать отклонения — это уже на усмотрение руководителя. Причем, руководитель будет ожидать, что если он допускает отклонения в пользу сотрудника, то и сотрудник в трудные периоды об этом не забудет. Иначе получится игра в одни ворота.

14.09.2010 13:57, Donz пишет:

> Просьба ответить работодателям.
> Насколько вам важно, что работник находится на работе строго по часам
> без плавающего прихода и ухода и с регламентированным обедом?

Любой начальник хочет руководить коллективом удалых молодцов, а не
коллективом печальных задротов. При этом необходимо ещё как-то
реализовывать производственные планы.

Поскольку я не встречал ещё программистов, желающих приходить на работу
в 7 утра, то резонно предположить, что за стыдливой формулировкой
"плавающий приход" прячется приход часикам к 11 (и позже). Что при
условии отработки 8 часов + час на обед означает уход примерно в 20.00
(и позже). Регулярная жизнь в таком режиме чаще всего означает (не в
100% случаев, всего лишь в 90%), что работник, по меткому выражению
кого-то из уже отписавшихся в этой теме, скоро останется наедине "с
компьютером, котом и линуксом". Таким образом, поощрение "плавающего
графика прихода и ухода" ведёт к деградации личного состава или (если
независимо от времени прихода в 18.30 офис пустеет) — к финансовой погибели.

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

--
WBR,
Serge.

Posted via RSDN NNTP Server 2.1 beta

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>

Здравствуйте, landerhigh, Вы писали:
E>>1. Спонтанная необходимость обсуждения технических деталей. Возникли вопросы, хочется обсудить, а на рабочем месте нет то одного, то другого. Тот пришел, другой ушел на обед. Другой вернулся с обеда, тот ушел на обед и в таком духе. А теперь представим, что разработчиков, с которыми надо обсуждать что-то (не одновременно, а в разных комбинациях) не двое, а два десятка и все любят гибкий график и не регламентированный обед.
госсподи, вы будто не работали никогда
вот приходите вы на работу. бац — глюк — приложение падает у кого-то, подтвердились какие-то опасения насчет сырой технологии. нужно принять решение -переписывать на другую или ставить костыли.
идем с этим вопросом к начальнику.
а его нет. ага
потом обед
потом приходит начальник, куда-то уходит
потом опять приходит, ты ему — вот, значит, есть такая ситуация, либо делаем так — тогда такие минусы, либо так — тогда такие.
он тебе — давай менять технологию, значит, посоветуйся с тем чуваком по такому вопросу, он уже делал подобное
ищем того чувака
его нет
пишем, идем домой

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

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

L>Никакой спонтанной необходимости обсуждения технических деталей не бывает. Бывает плохой менеджмент, способный убить эффективность на корню.
L>Все обсуждения, для которых требуется присутствие более чем одного человека, необходимо планировать, причем совсем не по той причине, что народ когда хочет, тогда и приходит.

Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

E__>>Ну честно, не могу я серьезно себе представлять это. У вас там системы документооборота/багофичетрекера нету, что-ли? Зачем этот цирк по утрам?

G>Речь шла про scrum daily meeting

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

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

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

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

__>вот приходите вы на работу. бац — глюк — приложение падает у кого-то, подтвердились какие-то опасения насчет сырой технологии. нужно принять решение -переписывать на другую или ставить костыли.

и два дня решение о смене технологии не подождёт? это называется пожар в борделе при сумасшедшем доме

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

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

G>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

Если этот человек в отпуске/заболел/ушел в монастырь, будете делать всей компанией харакири?

Кстати, всего тысячи долларов в минуту? Дай угадаю, CD-эректор пишете?

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

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

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

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

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

Ну и соответственно есть компании, предпочитающие как людей первого типа, так и второго.

Сам с жестким графиком работал только в самой первой фирме, когда был на 5 курсе, потом слушать "ты почему сегодня на 15 минут опоздал, как ты относишься к своей работе!" надоело и оттуда ушел. Во всех остальных график был и есть только гибкий. Где-то надо было приходить не позже 12, где-то не позже 2. Сейчас не позже 2. Только в одной (LiveGames) считали часы, прикрутив автоматический подсчет к электронному замку на двери (график гибкий, но часы считали). В остальных время прихода-ухода никак не отмечали и часы не считали.

Что интересно (для некоторые сейчас будет сюрприз), чем успешнее фирма, тем с более высоким уровнем развития туда набирают сотрудников, и тем меньше заморачиваются над временем прихода-ухода. По крайней мере, это из моих наблюдений.

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

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

L>>Никакой спонтанной необходимости обсуждения технических деталей не бывает. Бывает плохой менеджмент, способный убить эффективность на корню.

L>>Исключение — это обсуждения, не выходящие за рамки самоорганизующихся команд, сиречь scrum, но они на то и самоорганизующиеся.

E>Как Вы категоричны. Даже интересно как наша компания с таким плохим менеджментом развивается, растет, генерирует прибыль и в отделе разработки нулевая текучка

У вашей компании все еще впереди. Сейчас у Вас, скорее всего, имеется устоявшаяся команда, которая сама все и разруливает, о чем я и написал.

E>Даже спорить не хочется

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

21.09.2010 19:18, Eugeny__ пишет:

> E__>>Ну честно, не могу я серьезно себе представлять это. У вас там
> системы документооборота/багофичетрекера нету, что-ли? Зачем этот цирк
> по утрам?
>
> G>Речь шла про scrum daily meeting
>
> Все подобные системы, своды правил и прочие инструкции сделаны для
> обезьян

Осторожнее со scrum, несчастный, жрецы Agile уже мастерят твою куклу,
чтобы проткнуть её иголками

--
WBR,
Serge.

Posted via RSDN NNTP Server 2.1 beta

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

GIV>2) должен отработать Х*8 часов в месяц, где Х количество рабочих дней в этом месяце.

Вот это меня всегда удивляло. Типа не меньше 40 часов в неделю.
В итоге люди зачастую просто сидят, насижывают эти часы и ничего при этом все равно не делают.
Лучше пусть пойдет своими делами займется, главное что бы поставленные задачи успевал сделать
к сроку. Тут конечно много нюансов, но все же.

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

IID>А если нашли в 20 вечера, а человек ушёл 2 часа назад ? В чём отличие, не пойму

...
В том, что те, кто находят в 20 вечера не работают. А если и работают, то это еще один пример бардака, устроенного излишне свободным рабочим графиком.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

21.09.2010 12:45, genre пишет:
>
> Хотелось бы мне пожить в этом идеальном мире.
Да кто ж тебе мешает.
Ты просто пойми, что основная масса програмеров — люди "тронутые" по
определению (ну какой нормальный человек в эту область сунется и еще
програмить будет хотеть, а не руководить).
Им нравится то, что они делают. Задача менеджера не мешать и чуть
корректировать их направление движения — все остальное они сами сделают.

Posted via RSDN NNTP Server 2.1 beta

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

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

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

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

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

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

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

G>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

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

А представим, что человек пришёл ровно в 10, как и положено. Это значит, что он в 11 должен сразуже с голой грудью бросаться на исправление бага. Причём исправить надо быстро. Минута простоя — тысячи долларов. Баг оказался не очень сложным. На исправление ушёл час. Решение сырова-то. Неплохо бы проверить. А есть ли на это время? Проверка (программистом) займёт ещё час. Потом нужно тесты погонять, затем тестеры посмотрят, что функция работает, и больше ничего не отвалилось. Т.е. получается 2 альтернативы:
а) Сделать по хорошему. Это может занять от нескольких часов до пары дней.
В этом случае вероятность новых багов низкая, но заказчик теряет какую-то немыслимую сумму денег.

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

Так что как ни крути, а программист — это не диспетчер в аэропорте и принимать быстро решения ему не нужно.

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

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

L>>Никакой спонтанной необходимости обсуждения технических деталей не бывает. Бывает плохой менеджмент, способный убить эффективность на корню.
L>>Все обсуждения, для которых требуется присутствие более чем одного человека, необходимо планировать, причем совсем не по той причине, что народ когда хочет, тогда и приходит.

G>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

А если нашли в 20 вечера, а человек ушёл 2 часа назад ? В чём отличие, не пойму

...

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

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

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

__>Здравствуйте, landerhigh, Вы писали:
E>>>1. Спонтанная необходимость обсуждения технических деталей. Возникли вопросы, хочется обсудить, а на рабочем месте нет то одного, то другого. Тот пришел, другой ушел на обед. Другой вернулся с обеда, тот ушел на обед и в таком духе. А теперь представим, что разработчиков, с которыми надо обсуждать что-то (не одновременно, а в разных комбинациях) не двое, а два десятка и все любят гибкий график и не регламентированный обед.
__>госсподи, вы будто не работали никогда
__>вот приходите вы на работу. бац — глюк — приложение падает у кого-то, подтвердились какие-то опасения насчет сырой технологии. нужно принять решение -переписывать на другую или ставить костыли.
__>идем с этим вопросом к начальнику.
__>а его нет. ага
__>потом обед
__>потом приходит начальник, куда-то уходит
__>потом опять приходит, ты ему — вот, значит, есть такая ситуация, либо делаем так — тогда такие минусы, либо так — тогда такие.
__>он тебе — давай менять технологию, значит, посоветуйся с тем чуваком по такому вопросу, он уже делал подобное
__>ищем того чувака
__>его нет
__>пишем, идем домой

__>приходим с утра, начинаем писать, приходит чувак, разговариваем с ним, оказывается нужно было лучше по-другому начинать писать, переписываем заново
__>готово, сами проверяем, — отдаем тестеру
__>а тестера нет — свалил уже
__>на след день приходите на два часа позже тестера, он сидит фигней страдает, пинаете его, он начинает работать, потом обед, он опять убегает, потом че-то поделает — все он уже собирается уходить.
__>несем приложение начальнику — вот, можно выкладывать. а начальника нет. он свалил куда-то уже.

Бардак, одним словом. Первое, что приходит в голову, прокладка локальной сети, потом можете провести интернет и завести себе почту на том же gmail'е, сразу пропадёт необходимость лично относить изменённые версии тестерам и начальнику и можно будет консультироваться с начальником и пинать тестера, даже когда их нет на рабочем месте (до чего техника дошла!). Ну и дальше там уже по мелочи: VCS, issue-tracker, wiki, и т.д.

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

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

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

Здравствуйте, Eudjinn, Вы писали:
E>По моему мнению, гибкий график не должен противопоставляться дисциплине. Она должна быть и при гибком графике.

За дисциплиной эт вам в армию, а не R&D процессом управлять.

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

G>>>ну да. просто исключительные ситуации в разных проектах возникают с разной частотой.

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

G>Я тут выше описывал как банальный баг может затормозить работу над конкретной веткой кода на пару дней. Это исключительная ситуация?

В описанной тобою там ситуации всем на баг насрать. Потому так и получается. Реально свободный/гибкий график хорошо работает там, где людям по разным причинам небезразлично то, что они делают. Потому что телефон, аську, мыло и прочие коммуникационные инструменты никто не отменял. А у тебя там все действовали по принципу "на от#бись": отфутболил кому-то, и забыл.

Я, например, не растаю, если в выходные по телефону проконсультирую кого-то(бывает частенько, ибо многие, с кем мы сотрудничаем, работают по выходным). И даже что-то подправлю по удаленке, если это возможно. Я не стану отмазываться, мол, пошли вы все. Но и никто не станет у меня спрашивать, где я был, и почему я на всего пару часов сегодня забежал. У меня есть работа, и мне выгодно ее делать. Меня не надо подгонять и контролировать.

D>Или наоборот, в чем видите выгоду в ненормированном и нерегламентированном рабочем дне?

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

У нас в итоге используется схема, когда ты сам определяешь удобный график (8 часов рабочих) и следуешь ему

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

A>>но по твоей модели разработчик постоянно должен отвлекаться: то его на совещание неожиданно позовут, то кто-то пенделей для профилактики даст.

G>почему постоянно? я где-то говорил, что каждые 5 минут его дергают?
G>Да и на самом деле раз-другой в день (даже если это так часто случается)отвлечься не страшно.

Тогда мне совершенно не понятно зачем он должен постоянно находится в офисе. Если его отвлекают раз в день, то можно и предупредить об этом. Причём не встиле — "когда вам всем завтра будет удобно собраться на совещание". А сообщить время совещания. И уже не важно какой у кого график — все придут, даже если это неудобно.

A>какой к черту экватор? у нас время сдвинуто! "декретное", летнее и так далее.

Про экватор

1. Чем ближе экватор, тем меньше разница между самым длинным днём и самым коротким. В Вашингтоне самый длинный день длится 14 часов, а в Новосибирске — 17 часов, зато самый короткий день длится 9,5 часов, а в Новосибирске 7. Короче говоря, время захода солнца в течение года в Вашингтоне более равномерное.
2. Чем ближе экватор, тем короче зори, т.е. темнеет быстрее — солнце зашло и сразу стемнело. В Новосибирске темнота наступает летом через 3-4 часа после захода солнца.

Солнце в Вашингтоне заходит в семь летом и в пять — зимой, поэтому чтобы заставать светлое время суток, нужно уходить с работы в 4-5 часов вечера. Поэтому и график жизни там сдвинут.

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

Свободный ненормированный график с обязательным присутствием в определенные часы (11-15 например).

1) Позволяет людям приходить\уходить в достаточно вольной форме.
2) Есть время для командной работы.
3) "ненормированный" позволяет в авральных ситуациях заставить поработать до упора.

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

G>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

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

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

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

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

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

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

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

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

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

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

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

N_>>За дисциплиной эт вам в армию, а не R&D процессом управлять.
E>Спасибо за ваше ценное мнение, даже не знаю как мне это удавалось на протяжении довольно многих последних лет. А вы-то сами как, давно управляете?

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

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

L>У вашей компании все еще впереди. Сейчас у Вас, скорее всего, имеется устоявшаяся команда, которая сама все и разруливает, о чем я и написал.

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

E>>Даже спорить не хочется

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

А кто говорил про раз в полчаса-час? Даже если это раз в неделю надо, когда нужных людей нет — не удобно. Если в крайности бросаться — так можно и с вашим планированием всю эффективность перечеркнуть на корню

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

8>Вот это меня всегда удивляло. Типа не меньше 40 часов в неделю.
8>В итоге люди зачастую просто сидят, насижывают эти часы и ничего при этом все равно не делают.
8>Лучше пусть пойдет своими делами займется, главное что бы поставленные задачи успевал сделать
8>к сроку. Тут конечно много нюансов, но все же.

Тут действительно есть нюанс. И не один.
А кто определяет сроки на решение задач?
А как бороться с видимым неравноправием в команде?
А как определить, что человек действительно работы делает не меньше чем другие?
итд.
так что проще чтобы все работали по 8 часов в день и все.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

B>За строчки кода что ли?
B>Или за пофиксенные баги?
B>Не работает это.

(понятливо)
а!!!!

ну, тогда пусть отбывают урок.
хехехе

PS Дикие понятия рашкованчиков о мотивации меня уже даже не забавляют.

G>3 приоритета это ровно столько, сколько реально способен освоить человек. Как показывает практика большинство клиентов и служб поддержки не способны мыслить большим количеством приоритетов. Иногда добавляется еще два — "суперсрочно" (ASAP ) и "вообще нафиг не надо "

Я в своё время пытался внедрить схему с двумя приоритетами (но рук-во не оценило)

1) Must be — должно войти в релиз
2) Optional — войдёт в релиз, если будет свободное время

Нет смысла в 3х или даже 5ти приоритетах — если что-то должно войти, то не важно в каком порядке делать. Если есть свободное время на Optional — ну тут можно и обсудить, обычно свободного времени нет.

Очень часто путают Priority и Severity и пытаются с помощью приоритета (== порядок выполнения) оценивать важность (необходимость для кастомера) что неправильно.

Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, __kot2, Вы писали:
__>>Здравствуйте, k.o., Вы писали:
KO>>>В общем, ты только усиливаешь моё мнение о творящемся у вас бардаке.
__>>бардак творится везде. он творился везде где только я работал. я не верю в компании без бардака. это пиар, когда некая компания рассказывает сказки о том, как у них все замечательно. 8 лет назад я начал работать в первом коллективе и много раз уже разочаровался в сказки о том, что бывают все такие правильные и просто суперотличные компании. не бывает их. бардак везде.
KO>Между полным бардаком и абсолютным порядком есть ещё куча промежуточных состояний. Везде есть свои проблемы, но то, что ты описал как обычную рабочую ситуацию, иначе как полным бардаком назвать нельзя.
у всех программистких контор одинаковые проблемы, возникающие из-за особенности психологии ИТшников.
например, среди программистов очень высокий процент наркоманов — почти в каждой конторе во многих отделах сидят люди которые регулярно чем-то ширяется по тихой грусти. как следствие — раздражжительность, апатия и асоциальность.
почему? да потому что ИТшники по сути замкнуты в себе — в мире компутера — в пустой хате с линуксом и котом. но люди без общения, без близкого человека, несчастливы. и как следствие, чтобы хотя бы кратковременно чувствовать себя счастливым, принимают наркоту. которая вызывает уже ну полный капец с личностью. и таких людей мнооого в ИТ.

Здравствуйте, Eudjinn, Вы писали:
E>Если они все вместе проводят не менее пяти часов в _определенных рамках_, то проблемы как таковой нет (без учета обеда). Как только рамки плавают, люди вынуждены ждать, когда появится коллега. Да и элементарное правило, руководитель должен знать где его сотрудники в рабочее время(кстати, по ТК, рабочее время определяется и в договоре прописывается).
E>Приплюсуем, что плавает вместе с рамками пересечения еще и рамки обеда, причем в широком таком диапазоне, например, кто-то в 12:30 идет на обед, а кто-то в 15:00. Что мы получаем? Из 5-часового якобы "проведения вместе на работе", кого-то нет в 12:30, кого-то в 13:00, кого-то в 14:30, а кто-то в 15 ушел на обед и вернется через час. Итого, из 5 часов вычитаем 2,5 и остается 2-2,5 часа _гарантированного_ пересечения. И получается, что вместо решения вопросов в 11:00, обсуждение произойдет в 16:00 (по своему опыту говорю, кстати). Да, это не каждый день происходит, конечно, и не между всеми сотрудниками — некоторые неплохо кореллируют в своих подгруппах. Но когда НУЖНО, а НЕТУ — понимаешь, что теряешь время. Здесь потерял, там потерял, ты потерял, коллега потерял, заказчик потерял...ну просто НЕУДОБНО.

Чтобы было гарантированное пересечение в 5 часов — достаточно время прихода сделать фиксированным в интервале 4-х часов, а не 2-х

Приэтом это не мешает одному и тому же сотруднику сегодня прийти в 9 часов, а завта в 11, общее время пересечения отсюда не изменится

E>Возникает необходимость в автоматизированной учитывалке времени. Не бог весть какая проблема, во многих компаниях она есть, но тем не менее.
Опятьтаки — а нафига?? Если человек будет меньше работать( по времени) — это будет заметно через некоторое время, для этого не обязательно бдить постоянно. Но если менеджер ниской квалификации и неможет уследить за колективом, то можно конечно и по турникетам на входе в офис считать время.
E>Ну и формальная сторона вопроса есть, для любителей "чтобы все по ТК было": если с человеком что-то случилось в рабочее время, но не на работе — это одна ситуация, а если случилось на работе во внерабочее — другая.
Т.е. ради этой надуманной исключительно редкой ситуации готовы снизить продуктивность работы, мотивацию и лояльность сотрудников компании?

E__>Стопстопстоп.
E__>Что-то я не могу понять, какая связь между графиком 11.00-20.00 и "наедине с
E__>компьютером, котом и линуксом".

Здесь как бы предполагается, что у очень многих взрослых людей есть дети. Дети имеют обыкновение ходить в садик-школу, которые начинают работу в 7-9 утра. А это значит, что дети должны ложиться спать в 9-10 вечера. Плюс у очень многих взрослых мужчин есть жёны, которые работают не в IT и у которых с вероятностью 90% жёсткий график работы. Вот у работодателя и возникает вопрос, если человек работает в режиме с 11 до 8 или с 12 до 9, то как у него устроена семейная жизнь...

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

AV>>>Если исключительные ситуации на проекте возникают каждый день, то на проекте творится банальный бардак. А если исключительная ситуация возникает раз в пару месяцев, то не вижу проблем в том, чтобы договориться на пару дней.
G>>Я тут выше описывал как банальный баг может затормозить работу над конкретной веткой кода на пару дней. Это исключительная ситуация?
DM>Конечно исключительные.
DM>В этом случае — команде дается отгулы на пару дней, а когда баг чинится — вся команда работает и субботу, и воскресенье.
DM>Также бонус свободного графика — днем работать надо на полчаса меньше. Свободный же график! Поэтому максимум раз в неделю, не чаще! работодатель звонит в 02:38 и просит по быстрому исправить такой же баг.
DM>Вот читаю описание работы от AV — прямо слеза по щекам стекает, как все грамотно придумано, да еще замотивировано.

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

Зато когда мне что-то надо то все вопросы решаются на ура. Банальный пример. Вот в следующую пятницу мне надо ехать в другой город (километров за 300) делать МРТ. В результате выпадает целый день. Больничного на это мне никто не даст. Так что надо брать отпуск. Меня же спокойно отпускают без всяких там отпусков и прочего. Потом надо будет идти на платную консультацию к травматологу. Опять, без проблем, в любое удобное мне время. Надо было дочку в школу на 1 сентября отвести. Без проблем. Отвел, потом пару часов из дому поработал. Точно такой же подход использует и работодатель. Мелочи? Да, мелочи. Но из таких мелочей и складываются нормальные отношения. В результате, даже если мне когда-то придется покинуть эту компанию, то у меня о ней останутся только хорошие воспоминания.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E__>>Знаешь, у меня серьезное недоверие всем расписанным по полочкам, шагам и красиво иллюстрированным диаграммками систем управления людьми.

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

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

G>Ты вроде говоришь все правильно. Люди не винтики и всё такое. Индивидуальный подход. А между тем именно своды правил и прочие инструкции, то есть то, что называется "процессом разработки" позволяет этот процесс упорядочить, сделать предсказуемым и управляемым. Избавиться от бардака в котором тут все горазды друг друга обвинять.
G>Без процесса возникает именно что бардак.
G>Процесс даёт разработчику ответы на очень важные вопросы.
G>- Как его контролируют и что считается хорошо выполненной работой, а что плохо выполненой.
G>- Что делать в случае исключительных ситуаций.
G>- В конце-концов, что же вообще надо делать

G> Все те правила которые по-твоему "для роботов" созданы в первую очередь чтобы отвечать на эти вопросы. Иначе придеться делать "незнамо что незнамо для чего".
G>Тебя ведь не смутит правило "раз в неделю собрать билд и отдать тестерам"? Оно не делает из людей роботов? А почему тогда "раз в день отчитаться о своей работе" тебя смущает? Одна из задач этих пресловутых ежедневных митингов это максимально быстро сообщить о проблемах (например о недооценке сроков) менеджеру. Что в этом такого уж плохого?

G>Ну и как-то всё очень общо у тебя получается. Правила — плохо.

Не правила плохо. Плохо, когда шаблонные правила пытаются бездумно применять где ни попадя и как не попадя. Правила должны быть. Но они должны быть составлены менеджером исходя кучи факторов: специфика задачи, бюджет, команда, да тысячи их. А когда берется кем-то написанная простыня с "супер-пупер технологией ХХХ", и минуя мозг внедрятеся в компании как Закон Божий — вот это беда.

G>Но тут как раз важна конкретика. Именно конкретные задачи создают конкретные решения. Каждая методология создана не просто так, а чтобы решать конкретные проблемы. Например требование поспеть к сроку создает необходимость контроля выполнения задач. С какой частотой нужно контролировать? Это зависит от многих факторов. Но думаю если в средней команде занимающейся и разработкой и поддержкой продукта взять срок в один-два дня, то это окажется оптимальным. Повторюсь, возможны варианты. Но если задаться этими вопросами, то и необходимость в ежедневных митингах может оказаться не столь забавной.

Контроль — не единственная схема мотивации. Если сотрудник получает процент с каждого подпроекта, (но при этом не получает ничего за багфиксинг, и не может разрабатывать новое, пока есть баги), то контроль ему и нахрен не нужен. Сам будет делать, и с минимумом багов — это ему выгодно. Это очень грубо, но идея, думаю, понятна. Хотя такая схема в некоторых случаях не применима, но таких случаев, если вдуматься, не так много.
И да, таки процент дожен быть значительным. Только наши менеджеры часто паталогически жадные, им проще ~~стоять с палкой~~ контролировать каждую секунду разработчика, чем мотивировать его. Заодно и ЧСВ растет, как же без него.

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

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

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

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

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

Не важен, за одно отвечу на Предложи рабочую схему

Все очень просто:

Берем продукт — отделом маркетинга составляется набор features (фич), далее с отделом маркетинга составляем план реализации этих фич на ближайшией 3 года, на год, на полгода, квартал — короче типичный roadmap. Разбиваем продукт на версии, исходя из функционала, приоритетов, состава и размера команды, рисков и устанавливаем сроки сдач release, beta, alfa-версий. Не забываем, что при оценках сроков надо учитывать время на отладку, тестироание и bugfix. Обычно разработка занимает 1/3 времени, 1/3 веремени на выявление дефектов и 1/3 на их устранение.

Собственно разработка:
Процесс должен быть построен на итеративном сценарии, к примеру выделяем период — обычно 1-2 недели (для отдельных объемных работ — 4 недели). С разработчиком согласуем план и объем работ требуемых для исполнения в указанный отчетный периолд. Не забываем учитывать, что время названное разработчиком следует умножить на PI (3.141592) — так как разработчик называет время, которое он потратит на разработку (это 1/3) времени, 1/3 времени у него займет отладка и 1/3 — исправление дефектов + 0.141592 (туалет, чай, кофе, покурить), итак в начале периода согласуется план (1-2 часа в понедельник 12-00), в конце периода (примерно 1-2 часа в пятницу 17-00) — сдача (т.е. показ той или иной функциональности). Исправление дефектов — можно ставить как одну из задач при планировании. Так же в понедельник можно устраивать мозговой штурм по дефектам, которые не понятно разработику как воспроизвести или устранить. Время подобных мероприятий должно быть жеско регламентировано и явка обязательна, причем каждый разработчик должен понимать зачем это делается.

Дальше в течении этого периода идет работа по плану, без всяких требований приходить в 8-9 утра или еще что... Главное, что бы человек отработал свои 45 часов в недель (из них 5 часов обед) — а как он их спланирует, в один день просидит 12 часов, а в другой 4 — мне все равно... В конце каждой недели каждый пишет краткий отчет (report) о том, что сделано за неделю, проблемы и планы на следующий отчетный период.

Дальше смотрится на результат работы и объективно оцениваается — что успевается, что нет и почему... что не успелось, переносится на следующий отчетный период. Если не успевается по причине, что человек не дорабатывает, вполне можно провести аккуратно беседу... Если все успевается — тогда взятки гладки... Так же надо здраво оценивать, сколько будет стоить замена одного специалиста на другого, риски с поиском и прочее... Если нанять и обучить будет стоит дешевле, чем содержать текущего — тогда вполне допустим разговор о служебном соответствии, если нет — тогда и не стоит затевать подобный разговор.

Собственно в этом и заключается работа ПM... ПМ — это такой же член команды, который осуществяет координацию и взаимодествие между разработчиками и заказчиками (в частности — отдел маркетинга и продавцы) и ПМу думать что он выше команды, ПМ — часть команды, как и маркетологи и продавцы — никто не выше не ниже... — все часть... там где начинается разговор о том, что кто-то выше, а кто-то ниже — тем кто так говорит — надо жестко бить по рукам и губам...

p.s. А не сидеть тупо и кричать — надо приходить в 9 — потому что мне так хочется — это не ПМ. В свое время меня во дворе приучили к одному правилу — сказал что-то заявил — обоснуй — за слова ответь... не ответил — получи по морде... или молчи...

D>И даже я поставил оценку. Я спорить не собирался, просто решил уточнить некоторые фразы, которые выглядели очень категорично.
D>Собственно, я до сих пор не пойму проблемы коммуникации хоть с сотней работников, если они все вместе на работе проводят не менее пяти часов.

Если они все вместе проводят не менее пяти часов в _определенных рамках_, то проблемы как таковой нет (без учета обеда). Как только рамки плавают, люди вынуждены ждать, когда появится коллега. Да и элементарное правило, руководитель должен знать где его сотрудники в рабочее время(кстати, по ТК, рабочее время определяется и в договоре прописывается).
Приплюсуем, что плавает вместе с рамками пересечения еще и рамки обеда, причем в широком таком диапазоне, например, кто-то в 12:30 идет на обед, а кто-то в 15:00. Что мы получаем? Из 5-часового якобы "проведения вместе на работе", кого-то нет в 12:30, кого-то в 13:00, кого-то в 14:30, а кто-то в 15 ушел на обед и вернется через час. Итого, из 5 часов вычитаем 2,5 и остается 2-2,5 часа _гарантированного_ пересечения. И получается, что вместо решения вопросов в 11:00, обсуждение произойдет в 16:00 (по своему опыту говорю, кстати). Да, это не каждый день происходит, конечно, и не между всеми сотрудниками — некоторые неплохо кореллируют в своих подгруппах. Но когда НУЖНО, а НЕТУ — понимаешь, что теряешь время. Здесь потерял, там потерял, ты потерял, коллега потерял, заказчик потерял...ну просто НЕУДОБНО.

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

E>>Строка выше гласит "мало кто реально работает 8 часов в день", как можно подумать что "мало кто" это "менее 100%, то есть 80-99%" — я не понимаю. "Мало кто" это как раз от 0% заход. Разве нет?

D>В том контексте мне показалось именно так, как я написал.

Окей, бывает, не будем цепляться.

D>Видимо, теперь моя очередь намекать на невнимательность при прочтении

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

Да, я заметил свою невнимательность после отправки сообщения

Сорри.

http://www.rsdn.ru/forum/job/3958799.1.aspx — тут я об этом прямо написал, когда зашла речь о моем понимании нестрогого графика.

Окей, я понял. Я собственно тоже за то, чтобы гарантированно с 11 были все, а пересечение уже определяется самими ранними сотрудниками — если это 9 утра, то и уходят они в районе 17:30-18:00 (с учетом времени на обед), так и получается, что поздние с ранними пересекаются с 11 до 17. Только в моих требованиях добавляется _стабильность_ графика. Гибкость в том, чтобы модифицировать стандартный график в удобную тебе сторону, а не в том, чтобы приходить в любое время до 11. Возникает необходимость в автоматизированной учитывалке времени. Не бог весть какая проблема, во многих компаниях она есть, но тем не менее. Ну и формальная сторона вопроса есть, для любителей "чтобы все по ТК было": если с человеком что-то случилось в рабочее время, но не на работе — это одна ситуация, а если случилось на работе во внерабочее — другая.

А служебки зачем пишут? Вот Вы выше расстраивались, что это достает — так это тоже чтобы ТК соблюдать, между прочим, а не чтобы Вам жизнь испортить.

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

V>Как бы тебя не обидеть... постараюсь.
V>Вот смотри.
V>Компания — получила деньги от инвестора.
V>Программисты отсиживают присутственные часы и получают за это деньги —
V>это расходы.
V>Продукта на выходе нет никакого, потому что программистам нет смысла его
V>делать.

А как ты сделал из написанного мной вывод, что продукта на выходе нет? Я где-то упоминал, что надо платить просто по факту того, что человек провел 8 часов в офисе, не проверяя, что он делает? Если упоминал ссылку плиз.

Если нет то не надо за меня додумывать, дискуссия на таком уровне мне не интересна.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Так при чтении топика вспомнилось.

Норманн и Сакс

Норманн, умирая, напутствовал сына: "В наследство прими
Феод, мне дарованный некогда Вильямом — земли с людьми —
За доблесть при Гастингсе, полчища саксов повергшую в прах.
Земля и народ недурны, но держи их покрепче в руках.

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

Гасконских стрелков, пикардийских копейщиков чаще секи,
А саксов не вздумай: взъярятся, взбунтуются эти быки.
Повадки у них таковы, что хоть князь, хоть последний бедняк
Считает себя королем. Не внушай им, что это не так.

Настолько язык их узнай, чтобы каждый постигнуть намек.
Толмач не поймет, чего просят, — им часто самим невдомек,
Чего они просят, а ты сделай вид, что их просьбу постиг.
Знай: даже охота не повод, чтоб бросить, не выслушав, их.

Они будут пьянствовать днем и стрелять твоих ланей во тьме,
А ты не лови их, не трогай — ни в темном лесу, ни в корчме.
Не мучай, не вешай на сучьях и рук у них не отрубай:
Ручищи у них в самый раз, чтоб никто не оттяпал твой край.

С женой и детьми приходи к ним на свадьбы, поминки, пиры.
Епископ их крут — будь с ним крут, а отцы приходские добры.
Тверди им о "нас" и о "нашем", когда угрожают враги
Поля не топчи, на людей не кричи и смотри им не лги!"

Р.Киплинг

a> Согласен, что не всем подойдёт.

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

Я сформулировал только что эмпирические правила

1) если у работника свободный график, то в 99% случаев (оставлю 1% на всякий случай) работодателя устраивает его производительность, самомотивация и самодисциплина.
2) если у работника нет свободного графика и он недоумевает, то в 90% случаев он себя переоценивает (10% приходится на работодателей, которым религиозные мотивы не позволяют разрешить свободный график).

Так что 9 из 10 утверждающих, как классно они бы работали при свободном графике, себя переоценивают.

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

G>>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

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

Может быть не новая версия, а уже сто лет работающая. Просто увеличилась нагрузка, включили новую функциональность и т.д. и вылез баг.

B>ИМХО, правильная модель — 6 часов в день быть на связи. С 12 до 20, например.Обед — 1 час с 13 до 15. Т.е. человек гарантированно на месте с 12 до 13 и с 15 до 20. Ну и появление на заранее запланированный событиях никто не отменял.

Мне надо чтобы не человек был в гарантированное время, а команда. И чтобы пересекались так красиво все между собой, а не только я с одним из них.
И с какой стати всем будет удобно быть с 12 до 20? Мы тут не про удаленную работу разговариваем.

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

G>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

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

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

A>Так ведь свободный график это не отсутствие контроля. Просто контролируются несколько другие вещи.
A>Согласен, что не всем подойдёт.

Вопрос какие вещи надо контролировать.

A>Знаю примеры, когда начинают оценивать людей по формальным признакам (во сколько на работу пришёл, сколько отсидел), то люди начинают работать не на результат, а на видимость результата. Проконтролировать всё-равно очень сложно, но при этом у многих людей пропадает мотивация именно работать.

Фокус в том, что когда людей начинают оценивать, то они начинают работать на эту оценку. А когда людей не оценивают, то подавляющее большинство совершенно расслабляется. Так что оценивать хоть как-то надо. Другое дело, что серебрянной пули в этом вопросе еще не найдено.

A>Сегодня я планирую поработать побольше, голова свежая, мыслей много, какую-то часть лучше сегодня доделать чем откладывать на завтра. Причём дома по серьёзному делать нечего, можно задержаться. А вот завтра как раз неплохо бы пораньше уйти с работы — есть какие-то дела.

Поэтому надо считать суммарное время за месяц. Тогда остается возможность сегодня уйти пораньше, а завтра компенсировать это.

A>Когда все приходят в одно время — конечно проще. Но во-первых график работы не всегда совпадает с оптимальным временем работы именно для меня. Это уже обсуждалось выше.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

20.09.2010 14:33, Гоги пишет:

> Например, в городе Москве приезд на работу к 9-00 или 10-00 обеспечиват
> работнику отличную возможность иметь регулярную жизнь в пробке или в
> давке в метро, что отрицательно сказывается на мироощущении.

Что сказать? Ну, работайте дома тогда. Сам я в свой московский офис
добираюсь примерно к 9.00 без особых затруднений. Когда работал в других
конторах тоже как-то справлялся, вовремя на работу приходил. Практика
показывает, что кому трудно приходить к 10 — будет трудно приходить и к
11 и к 12.

--
WBR,
Serge.

Posted via RSDN NNTP Server 2.1 beta

21.09.2010 12:11, BulatZiganshin пишет:
>
>> > Не бывает такой абстрактной мотивации "хочу работать".
> V>Да. Не везет вам с сотрудниками...
>
> вы полагаете, что *большинство* наёмников просто тупо хотят работать?
Про наемников не знаю, дела не имел, а программисты обычно хотят,
главное, чтобы не "эффективные менеджеры" мешали.

Posted via RSDN NNTP Server 2.1 beta

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

>> Хотелось бы мне пожить в этом идеальном мире.
V>Да кто ж тебе мешает.
V>Ты просто пойми, что основная масса програмеров — люди "тронутые" по
V>определению (ну какой нормальный человек в эту область сунется и еще
V>програмить будет хотеть, а не руководить).

Перебрал в голове фамилии коллег и друзей-знакомых. Вспомнил пару действительно "тронутых" и работающих за идею. Еще пяток людей получающих искреннее удовольствие от работы — ну повезло им с направлением деятельности.
И еще сотни две людей просто приходящих на работу работать и получать зарплату, не потому что они фанатики, а потому что так уж получилось, что они это умеют делать и им за это неплохо платят. Кто-то из них получает удовольствие от процесса, кто-то не получает, разное бывает.
И в среднем — они бы и рады делать то, что им интересно, да только 80% времени приходиться фиксить баги, разрабатывать формочки, заниматься прочей неинтересной рутиной и лишь 20% времени придумывать дизайн, архитектуру, решать сложные и интересные задачи.
И вот получается, что 80% времени они занимаются не самыми интересными вещами.А мотивации это не добавляет ни разу. А соответственно и продуктивности.
Вот и приходиться следить и контролировать.

V>Им нравится то, что они делают. Задача менеджера не мешать и чуть
V>корректировать их направление движения — все остальное они сами сделают.

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

PS кстати, каждый второй опен-сорс проект сделан программистами без менеджеров. Как бы показательно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

L>>Каким таким магическим образом наличие менеджера исправляет архитектуру и дизайн гуя?

G>Например тем, что девелопер магически получает по рукам если гуя кривая.

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

L>Никакой спонтанной необходимости обсуждения технических деталей не бывает. Бывает плохой менеджмент, способный убить эффективность на корню.
L>Все обсуждения, для которых требуется присутствие более чем одного человека, необходимо планировать, причем совсем не по той причине, что народ когда хочет, тогда и приходит.

L>Исключение — это обсуждения, не выходящие за рамки самоорганизующихся команд, сиречь scrum, но они на то и самоорганизующиеся.

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

Даже спорить не хочется

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

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

S>>как то я слабо представляю как можно все 40 часов работаь без перерыва.
S>>Я бы сказал находишься в офисе 40 часвов в неделю

S>>у меня тоже оплата почасовая, но
S>>анекдоты почитать хочется

S>>почту почитать
S>>с коллегой поговорить как выходные прошли
S>>... и тому подобные нерабочие моменты
S>>реально работать я думаю часов 5-6 можно, а может и меньше

UVV>Я не нахожусь в офисе, я работаю дома.
UVV>Мне не платят за "поговорить как выходные прошли".
UVV>Мне платят за работу.

Круче только Яйца. Вы и когда отлить ходите секундомер останавливаете?

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

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

L>>Никакой спонтанной необходимости обсуждения технических деталей не бывает. Бывает плохой менеджмент, способный убить эффективность на корню.
L>>Все обсуждения, для которых требуется присутствие более чем одного человека, необходимо планировать, причем совсем не по той причине, что народ когда хочет, тогда и приходит.

G>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

Нашли багу в 3 дня, но по NY. А девелопер, сволочь, в Европе спит. А там минута простоя — тысячи баксов.
Наймите QA нормальных

Здравствуйте, sharpcoder, Вы писали:
S>Но, в нашей компании часть отделов работают с 9, часть — с гибким графиком. Потому, что у гибкого графика есть свои преимущества для компании:
S> 1. в целом гибкий график повышает лояльность сотрудников

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

S>Поэтому выгоды и право на жизнь имеет каждый подход.

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

B>>ИМХО, правильная модель — 6 часов в день быть на связи. С 12 до 20, например.Обед — 1 час с 13 до 15. Т.е. человек гарантированно на месте с 12 до 13 и с 15 до 20. Ну и появление на заранее запланированный событиях никто не отменял.

E>Мне надо чтобы не человек был в гарантированное время, а команда. И чтобы пересекались так красиво все между собой, а не только я с одним из них.
E>И с какой стати всем будет удобно быть с 12 до 20? Мы тут не про удаленную работу разговариваем.

ща заминусят...

ещё один мэнэджэришко?

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

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

E>А кто говорил про раз в полчаса-час? Даже если это раз в неделю надо, когда нужных людей нет — не удобно. Если в крайности бросаться — так можно и с вашим планированием всю эффективность перечеркнуть на корню

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

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

B>Наймите QA нормальных

Какие все тут умные люди собрались. Никто никогда не ошибается и не багает, а уже если багает, то тестеры гарантированно вылавливают все баги и все фиксится идеально.
Завидую вам, коллеги.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, мыщъх, Вы писали:

B>>За рабочим столом у нас никто не ест.
М>а почему у вас не едят? странный какой-то запрет...

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

и т.д. могут действовать на нервы другим сотрудникам находящимся в помещении.

L>Если окажется, что один член команды в это время на другой встрече, а ее мозг вообще у заказчика, что делать будешь?

L>Системы планирования рабочего времени уже изобрели.

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

E>>Я теряю веру в свой дар изложения мыслей...Я разве написал, что с девяти до десяти? Я разве написал, что со всеми двадцатью в течение дня? Если мне с _любыми_ двумя (из этих 20-ти) 2-3 раза в неделю надо пересечься в заданном промежутке времени, без необходимости ожидания когда они появятся одновременно.

L>Откройте уже для себя Гугль Календарь, что ли. Для начала.

Вы меня ничему новому и полезному не научите, мне этот диалог не интересен, спасибо за участие.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>

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

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

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

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

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

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

L>Кроме того, следить за time to market — это тоже задача менеджмента, а не тестеров с программистами.

Это именно что задача менеджмента. Который может решить эту задачу простейшим из доступных методов — нормированным рабочим временем.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

в той компании где я сейчас работаю весьма свободный график.

Но там, где он был жестким, он был жестким для всех, что собственно и логично, я бы, например, обиделся если бы такая дискриминация была

E>>По моему мнению, гибкий график не должен противопоставляться дисциплине. Она должна быть и при гибком графике.

N_>За дисциплиной эт вам в армию, а не R&D процессом управлять.

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

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

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

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

L>Ваше желание построить программистов в шеренгу и заставить маршировать на очередной митинг — типичный образчик микроменеджмента. То, что Вам с таким подходом в течение многих лет что-то удается делать, скорее всего, заслуга исключительно Вашей команды, ну плюс Ваша недоработка. Плохо заставляете.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

L>Ваше желание построить программистов в шеренгу и заставить маршировать на очередной митинг — типичный образчик микроменеджмента. То, что Вам с таким подходом в течение многих лет что-то удается делать, скорее всего, заслуга исключительно Вашей команды, ну плюс Ваша недоработка. Плохо заставляете.

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

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

H>Ну, вроде вопрос был к работодателям. Я и ответил, как работодатель.
H>Если кого обидел — извиняюсь.

Меня лично не обидел, а просто удивил. Какой свежести можно ждать от людей в 7-8 утра(это же когда встать-то нужно)? Это нужно специально команду жаворонков набирать(впрочем, по-другому и не выйдет: я, если услышу про такой график на собеседовании, покручу у выска и занесу контору в черный список), иначе будет команда сонных овощей, потребляющих кофе тоннами, но работающих процентов на 10 от возможной производительности.

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

GIV>>>2) должен отработать Х*8 часов в месяц, где Х количество рабочих дней в этом месяце.

8>>Вот это меня всегда удивляло. Типа не меньше 40 часов в неделю.
8>>В итоге люди зачастую просто сидят, насижывают эти часы и ничего при этом все равно не делают.
8>>Лучше пусть пойдет своими делами займется, главное что бы поставленные задачи успевал сделать
8>>к сроку. Тут конечно много нюансов, но все же.

E>

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>>ходить. по 15-20 часов в неделю например.

AV>>Даже на секунду положим что так хотят. Что в этом плохого, если они выполняют все поставленные задачи?

FR>Кстати не факт, что даже отрабатывая и не халтуря 40 часов они будут делать в два раза больше работы.
FR>У меня например максимальная производительность при отработке 4 — 6 часов в день.

Согласен.

Я вообще и считаю, что ориентироваться надо на требуемый результат, а не на то, сколько часов надо отработать.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

24.09.2010 16:42, ambel-vlad пишет:
>
> O>Да хоть как поставлена. Неудобно.
>
> Да ты шо? Образумь нас. А то мы уже более года на проекте где между
> нашей командой и командой заказчика 10 часов разбежки.
А вы genre на работу возьмите и менеджером поставьте.

Posted via RSDN NNTP Server 2.1 beta

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

AV>>Ну, есть сомнения что в таком случае именно затраты на коммуникации являются критическим моментом. Что-то сильно изменится если обе стороны будут пересекаться в течении длительного времени? Просто надо рассматривать на промежуток чуть более чем один день работы.

G>Крайний случай: все работают в одно время — лаг на коммуникации стремиться к нулю. Теперь раздвигаем рабочее время — лаг начинает увеличиваться до максимального значения в одни сутки.

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

G>Для команд работающих в стиле "как сделаем, так и отдадим клиенту" работает и суточный лаг.

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

G>Ну и для большинства приемлимый лаг где-то в середине. А срок не важен, потому что лаг копится.

Если нормально работать, то лаг не копится.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>Аааа, ты это про фиксированный график. Не удивлен. В случае гибкого графика — максимум день потеряем
G>Я как раз про свободный.
Скоро третий круг пойдет.
Обсуждать бессмысленно, не доходит.
Когда будет семья и дети — возможно, что-то поменяется. Иначе очень жаль семью.

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

G>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

отлично, КЭП, очень классная организация процесса у вас, когда критичная часть висит на одном (sic!) человеке.

Страшно даже подумать, что будет, если он в отпуск уйдёт или заболеет

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

Жесткость графика работы сотрудника зависит от его функциональных обязанностей и особенностей задач в решении которых он задействован.

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

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

BZ>>исправление ошибки — это одна операция, здесь важна latency. создание продукта — это множество операций, здесь важен общий throughput

G>Однако исправление ошибок напрямую влияет на time-to-market. Наблюдение из реальной жизни: затраты на коммуникации между отделом разработки и отделом тестирования в случае ненормированного рабочего времени дают до 4-5 дней задержки на интервале в месяц. Это конечно худший случай, но вот такая вот реальная статистика из практики.

но по твоей модели разработчик постоянно должен отвлекаться: то его на совещание неожиданно позовут, то кто-то пенделей для профилактики даст.

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

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

D>Насколько вам важно, что работник находится на работе строго по часам без плавающего прихода и ухода и с регламентированным обедом? Какие в этом плюсы? Можете дать четкий расчет выгоды компании от этого?
Вообще не важно. Главное, чтобы на daily scrum meeting присутствовал, или хотя бы своевременно уведомил об отсутствии.

D>Или наоборот, в чем видите выгоду в ненормированном и нерегламентированном рабочем дне?
Программист с ненормированным рабочим днем работает больше и в свое удовольствие.

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

AV>>Да ты шо? Образумь нас. А то мы уже более года на проекте где между нашей командой и командой заказчика 10 часов разбежки.
O>Проблема в том, что лаг в один день — обычное дело. Для вас может и некритично, может вы и привыкли к такому лагу.

А если сделать примерно так. Есть команда А и команда Б. Команда А своим вечером говорит команде Б, что ей завтра нужно будет вот та вот загогулина. Пока команда А спит, другая сторона делает эту загогулину. И в свою очередь говорит, что ей в свою очередь надо будет что-то другое. И меняются местами. Где здесь будет лаг?

Но это если жить только одним днем. Если же оперировать несколько более крупными объемами, то вклад этих лагов еще меньшим становится.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

L>Если Вам так интересно — на совещания, назначенные мной, приходят все, кто требуется и в строго означенное время и место.

Нет, мне не интересно. Я указал Вам на Вашу непоследовательность.

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

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

L>Отнюдь. Вы о себе как менеджере и о своей команде рассказали гораздо больше, чем Вы думаете.

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

24.09.2010 17:34, genre пишет:
>
> V>А вы genre на работу возьмите и менеджером поставьте.
>
> А ты бы вместо того, чтобы чувство юмора проявлять на вопросы бы
> отвечал. Например тут <http://rsdn.ru/Forum/Message.aspx?mid=3967986&only=1>
Уже раз 100 писал тут на форуме. Не надо придумывать себе проблемы, а
потом не успешно их преодолевать.

1. Вы ставите задачу программисту. Лучше письменно. И это не для того,
чтобы кто не отвертелся, а чтобы четко сформулировать, что надо сделать.
2. Программист оценивает ее срок и отображает его в диаграмме Ганта.
Сам. Вы квалифицированный менеджер и понимаете, что программист должен
сделать и зная уровень вашего подчиненного, соглашаетесь со сроком или
нет (требуется обсуждение с подчиненным).
3. Программист делает разбивку задачи на подзадачи сроками по 2-3 дня,
но не дальше, чем на 2 недели вперед.
5. У вас тоже есть диагарма Ганта, достаточно приближенная, где отражен
roadmap проекта и ваша задача, чтобы ваша диаграмма соответствовала
диаграмма ваших подчиненных.
4. Программист, по мере выполнения отмечает, что задача сделана
(возможно с уменьшением срока) или как видит, что не укладывается
увеличивает срок. После второго увеличения срока — начинаете
использовать все ваши умения, как руководителя, чтобы решить проблему
(это чрезвычайная и редкая ситуация).
5. Как руководитель вы имеете полностью управляемый процесс разработки и
никого не достаете бессмысленным контролем всякого говна.
6. Как опытный руководитель вы видите как и кто работает и выделяете
премии, повышения зарплаты или увольняете нафиг (не понимаю зачем
держать бездельников).

Posted via RSDN NNTP Server 2.1 beta

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

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

G>>>Однако исправление ошибок напрямую влияет на time-to-market. Наблюдение из реальной жизни: затраты на коммуникации между отделом разработки и отделом тестирования в случае ненормированного рабочего времени дают до 4-5 дней задержки на интервале в месяц.

BZ>>они бездельничают, пока другие не исправят одну ошибку???

G>Нет, они конечно не бездельничают, но вот этот конкретный билд они не тестируют.

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

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

H>Поскольку я не встречал ещё программистов, желающих приходить на работу
H>в 7 утра, то резонно предположить, что за стыдливой формулировкой
H>"плавающий приход" прячется приход часикам к 11 (и позже). Что при
H>условии отработки 8 часов + час на обед означает уход примерно в 20.00
H>(и позже). Регулярная жизнь в таком режиме чаще всего означает (не в
H>100% случаев, всего лишь в 90%), что работник, по меткому выражению
H>кого-то из уже отписавшихся в этой теме, скоро останется наедине "с
H>компьютером, котом и линуксом".

Стопстопстоп.

Что-то я не могу понять, какая связь между графиком 11.00-20.00 и "наедине с
компьютером, котом и линуксом".

Имхо, в большом городе как раз сильно выгоднее ездить как можно дальше от "часа пик" — время на дорогу, а также нервозность сокращается в разы. Да и высыпаешься отлично. Сам так езжу, и с ужасом и инстинктивной дрожью вспоминаю времена, когда приходилось вставать часов в 7, а то и раньше(хорошо, оочень давно было). Вечный недосып, целый день трясет, нервный как чёрт, все из рук валится, нихрена не выходит. Нет уж, избавьте. Я лучше высплюсь, приду к 11 веслый и довольный жизнью, спокойно выполню работу(не забыв и в рсдн отписаться: мне на все хватит, я не куняю носом), и уеду домой опять же в неполном метро или по уже пустым дорогам.

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

AV>И правильно скажет. Кто сказал, что при увеличении пользы от человека з.п. ему не надо подымать?

У нас часто думают иначе.

История из далекой от программерства деятельности, но показательная. Абсолютно реальная, достоверность около 99%, ибо рассказанная доверенными людьми. Подробности я опущу.

Итак, была-жила себе строительная компания. Продавала себе стройматериалы, да и неплохо продавала.
Но вот беда. Залежался на складе металл. По рынку — неликвид полный, да еще и коррозией пошел. Руководство сказало: кто продаст за цену Х(примерно по номиналу(не, чутка дороже таки), что логично, идаче сгниет оно там быстро), тому 30% от заказа лично в зп. А металла было хорошо.
Кто-то таки умудрился продать, и даже выше цены. И что? Письмо всем сотрудникам со всеми почестями и... С фундаментальной фразой во всей ее тупости: "богатство развращает, потому премия выдается в размере У(стандартная премия продажника)". И да, еще и на полмесяца задержали. А то, КАКИЕ усилия человек приложил, чтобы сбагрить неликвид(не исключены и откаты, и пр., то есть тупо в минус в надежде на те самые деньги) — пох.
Вот вам и все лицо нашего менеджмента. Самое плохое, что я такое и в IT среде видел. Типа, копай-не копай, а выше некоторой планки своего не получишь, даже если заработал компании очень много.

Но есть и другой менеджмент. Его просто нужно найти. Я нашел, и рад. И да, жопочасы — не мера. Это тупость ограниченных руководителей.

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

N7>тогда не вижу проблемы — пишешь в комменте мол присутствие обязательно. И усе — кто не пришёл и не представил уважительную причину — санкции.

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

E>>Ну ладно, мы не наивные, мало кто реально работает 8 часов в день...

UVV>Я работаю 40 часов в неделю. Именно работаю, поскольку оплата у меня почасовая.

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

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

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

E>>Ну ладно, мы не наивные, мало кто реально работает 8 часов в день...

UVV>Я работаю 40 часов в неделю. Именно работаю, поскольку оплата у меня почасовая.
как то я слабо представляю как можно все 40 часов работаь без перерыва.
Я бы сказал находишься в офисе 40 часвов в неделю

у меня тоже оплата почасовая, но
анекдоты почитать хочется

почту почитать
с коллегой поговорить как выходные прошли
... и тому подобные нерабочие моменты
реально работать я думаю часов 5-6 можно, а может и меньше

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

D>>Вопрос в том, насколько оправданно заставлять работников приходить ровно к девяти или ровно к десяти и вынуждать писать служебные записки, если надо прийти в 10:15.

E>Если говорить про разработчиков, чаще всего вообще не оправданно, поэтому, как я написал в первом ответе, в целом я за гибкий график. Но гибкий график в моем понимании немного не то же самое, что приходить во сколько получилось (вздумалось). Комфортно приходить в 11 — окей, но тогда пусть это будет 10:50, 10:55, 10:59, 11:00, но не 11:15? Я тогда спокойно буду приходить в 11, и сразу решать вопросы, если есть, с сотрудниками, которые уже на месте, а не буду ждать еще 15-20 минут, пока они подтянутся.

Пока они "подтягиваются" можно делать что-то другое. Или у вас ночью critical'ы постоянно всплывают и нужно их срочно фиксить в 11 утра?

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

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

IID>>А если нашли в 20 вечера, а человек ушёл 2 часа назад ? В чём отличие, не пойму

...
O>В том, что те, кто находят в 20 вечера не работают. А если и работают, то это еще один пример бардака, устроенного излишне свободным рабочим графиком.

Т.е. не работают? А если заказчик в 7-8 часах? И у него on-site тоже есть QA? Или вы такой возможности не представляете?

B>ща заминусят...

B>ещё один мэнэджэришко?

У меня сертификат несколько лет назад, как у тебя в подписи был и оценка хорошая там. Ты бы не хамил, чести тебе это не делает.

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

B>>За строчки кода что ли?
B>>Или за пофиксенные баги?
B>>Не работает это.

A>(понятливо)
A>а!!!!

A>ну, тогда пусть отбывают урок.
A>хехехе

A>PS Дикие понятия рашкованчиков о мотивации меня уже даже не забавляют.

А за какой результат надо платить? Просвети, повелитель доширака)

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

G>>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

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

Ну то есть обкатка гарантирует нам отсутствие багов?

Ясно дело, что нужно. Но отсутствие багов это не гарантирует.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

D>>Просьба ответить работодателям.
E>В общем, как-то так.
ИМХО, ты путаешь дисциплину и свободный график.

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

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

Ну вроде более менее поняли друг друга, это хорошо.

E>А служебки зачем пишут? Вот Вы выше расстраивались, что это достает — так это тоже чтобы ТК соблюдать, между прочим, а не чтобы Вам жизнь испортить.

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

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

Здравствуйте, k.o., Вы писали:
KO>В общем, ты только усиливаешь моё мнение о творящемся у вас бардаке.
бардак творится везде. он творился везде где только я работал. я не верю в компании без бардака. это пиар, когда некая компания рассказывает сказки о том, как у них все замечательно. 8 лет назад я начал работать в первом коллективе и много раз уже разочаровался в сказки о том, что бывают все такие правильные и просто суперотличные компании. не бывает их. бардак везде.
нельзя просто уволить людей и набрать "правильных". люди везде одинаковые работают.
есть даже такой старый опыт — взяли поток студентов и выделили оттуда две группы — 15% лучших и 15% худших и стали соревновать их друг с другом, так вот в 1ой группе появлись раздолбаи, а во второй возникли таланты. любая группа людей самоорганизуется аналогичным образом. в любой компании всегда будут работать раздолбаи. и в любой компании организация работы примерно одинакова. сказки о радостной и счастливой жизни, об отборе лучших сотрудников — всегда голый пиар.

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

).

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

D>Мне интересно, сколько работодателей и почему считают, что жизнь исключительно по ТК (точнее изначально был строгий график, как наиболее явное проявление) принесет компании больший доход. Интерес настоящий с возможным изменением моего мнения по этому вопросу, а не с целью разбомбить менеджеров, показав какие они ущербные.

Да, я так и понял изначальный вопрос.

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

B>>ИМХО, правильная модель — 6 часов в день быть на связи. С 12 до 20, например.Обед — 1 час с 13 до 15. Т.е. человек гарантированно на месте с 12 до 13 и с 15 до 20. Ну и появление на заранее запланированный событиях никто не отменял.

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

Если окажется, что один член команды в это время на другой встрече, а ее мозг вообще у заказчика, что делать будешь?

Системы планирования рабочего времени уже изобрели.

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

E>Я теряю веру в свой дар изложения мыслей...Я разве написал, что с девяти до десяти? Я разве написал, что со всеми двадцатью в течение дня? Если мне с _любыми_ двумя (из этих 20-ти) 2-3 раза в неделю надо пересечься в заданном промежутке времени, без необходимости ожидания когда они появятся одновременно.

Откройте уже для себя Гугль Календарь, что ли. Для начала.

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

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

KO>>Порядок выполнения задач, обычно, определяется приоритетом выставленным в соответсвующем тикете. Если с этим есть проблемы, то это один из верных признаков бардака и неэффективного использования ресурсов.

G>Ага. 10 тикетов High 10 Normal, что делать будем?

Очевидно, все тикеты с одинаковым приоритетом равноправны и могут исправляться в любом порядке, который устраивает того, кто над ними работает. Ты как-нибудь более внятно проблему сформулируй. Например: "10 тикетов High 10 Normal, но эти приоритеты нифига не соответствуют реальным, что делать будем?" Но ты ведь не это имел в виду?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

G>>Однако исправление ошибок напрямую влияет на time-to-market. Наблюдение из реальной жизни: затраты на коммуникации между отделом разработки и отделом тестирования в случае ненормированного рабочего времени дают до 4-5 дней задержки на интервале в месяц.

BZ>они бездельничают, пока другие не исправят одну ошибку???

Нет, они конечно не бездельничают, но вот этот конкретный билд они не тестируют.

Вот у нас есть билд, который должен через месяц пойти на продакшн. Мы отдаём его тестерам часиков в 5 вечера и спокойно уходим домой. Тестер находит шоустоппер и довольный уходит домой в 6.
На следующий день тестер приходит с утра пораньше, а девелопер приходит после обеда. На фикс баги уходит 3 часа. К тому моменту тестер уже ушел домой.
На следующий день уже программер прибегает пораньше, а тестер приходит попозже. В итоге если в фиксе не все в порядке, то к этому моменту уже программер ушел домой.
Итого вроде бы все работают как надо, а в календарных днях получается, что два дня над этим билдом никто не работал.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

A>Если кто-то гарантирует что-то сделать в готовом виде, то это уже продажа услуги, некоторого продукта. За это получают не зарплату, а прибыль (либо убыток, если не вышло).

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

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

A>Некоторые могут сильно себя переоценивать, при этом работают они действительно лучше, чем остальые.

О том и речь, некоторые лучше, а остальное большинство "эФФективных" разработчиков только языком трепать горазды.

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

Речь не идёт о крайних случаях (лентяи/бездельники), есть просто люди, которые в отсутствие контроля начинают давать себе поблажки, и когда они на виду, то легче проконтролировать прогресс.

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

L>>>Кроме того, следить за time to market — это тоже задача менеджмента, а не тестеров с программистами.
G>>Это именно что задача менеджмента. Который может решить эту задачу простейшим из доступных методов — нормированным рабочим временем.

L>Сегодня обязательно нашим менеджерам расскажу. А то они не знают.

видимо, менеджеры тебе в ответ расскажут что может!=должен. и посетуют, что не все программисты знакомы зотя бы с основами логики

17.09.2010 13:32, avpavlov пишет:
>
> G>3 приоритета это ровно столько, сколько реально способен освоить
> человек. Как показывает практика большинство клиентов и служб поддержки
> не способны мыслить большим количеством приоритетов. Иногда добавляется
> еще два — "суперсрочно" (ASAP ) и "вообще нафиг не надо "
>
> Я в своё время пытался внедрить схему с двумя приоритетами (но рук-во не
> оценило)
Слушай свое руководство и учись, пока не уволили.

Posted via RSDN NNTP Server 2.1 beta

17.09.2010 14:22, genre пишет:
>
> Извини, я не поспеваю за твоей логикой. Где я говорил про ничего не
> продающие компании?
Как бы тебя не обидеть... постараюсь.
Вот смотри.
Компания — получила деньги от инвестора.
Программисты отсиживают присутственные часы и получают за это деньги —
это расходы.
Продукта на выходе нет никакого, потому что программистам нет смысла его
делать.
Раз продукта нет, то продавать нечего.
Если ничего не продаете, то денег нет.

Итого, такая фирма живет, до тех пор пока инвестор на что-то надеется.

З.Ы. Фирмы, которые пилят государственное бабло мы не рассматриваем —
там нужны именно присутственные часы.

Posted via RSDN NNTP Server 2.1 beta

A>Я сформулировал только что эмпирические правила
A>1) если у работника свободный график, то в 99% случаев (оставлю 1% на всякий случай) работодателя устраивает его производительность, самомотивация и самодисциплина.
A>2) если у работника нет свободного графика и он недоумевает, то в 90% случаев он себя переоценивает (10% приходится на работодателей, которым религиозные мотивы не позволяют разрешить свободный график).

непоняятно(с)
В моей реальности свободный или жесткий график -- это зависит от компании, а не от программиста. Может быть компании со свободным и компании с жестким графиком тяготеют к найму разных людей?

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

Оффтопик.
Как забавно сократилось название темы...

Re[3]: Вопрос работодателям. Насколько вам важен строгий раб

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Z_>Здравствуйте, мыщъх, Вы писали:

Z_>Наверняка вас задолбали такими вопросами, но рискну спросить.
Z_>В книге "отладка без исходных текстов" вы сказали, что отладочные средства
Z_>под юниксом(в частности gdb) по-своему очень удобны даже в сравнении с виндовыми.
Z_>Что случилось, мнение поменялось?)
поменялись задачи. и основной цикл разработки был выполнен без отладчика вообще (только с отладочной печатью). потом все-таки установил ms vs 6 и даже несколько раз запустил отладчик

Z_>И еще такой вопрос — как на ваш взгляд, VisualStudio 6 надежнее
Z_>ближе_к_стандартам/безглючнее чем, скажем, та же VisualStudio 2005?
не пользовался VS 2005, потому сравнивать их не могу. ms vc 6 не поддерживает C99. не знаю как на этот счет у более поздних версий.

Z_> Или, если дело не(только) в этом, то почему вы предпочитаете шестерку?
Z_> Вопрос конечно касается компилятора командной строки.
"оно работает" (с). с шестеркой я работаю давно, знаю как ставить максимально урезанный вариант на нетбук, знаю что она не хавает ресурсов, etc. короче полностью меня устраивает. а если все устраивает, то зачем переходить на что-то новое? тем более маркетоиды так и не объяснили (внятно) что поменялось в компиляторе за это время. и нужно ли оно мне?

N_>Чтобы было гарантированное пересечение в 5 часов — достаточно время прихода сделать фиксированным в интервале 4-х часов, а не 2-х

Мсье либо не умеет читать, либо считать. Просьба вдуматься еще раз, потом можно будет общаться, если просветление наступит. Как из 8-часового дня, с временем прихода в пределах первых 4-х часов получить пересечение в 5 часов, лично для меня — загадка. Надо бы учесть, что пересечение в обед меня не очень-то интересует. Ну и уже написанное выше прочитать не мешало бы, чтобы мне не повторяться.

N_>Опятьтаки — а нафига?? Если человек будет меньше работать( по времени) — это будет заметно через некоторое время, для этого не обязательно бдить постоянно. Но если менеджер ниской квалификации и неможет уследить за колективом, то можно конечно и по турникетам на входе в офис считать время.

Мсье имеет богатый опыт менеджмента? Простите, не похоже. Умение "уследить за коллективом" и контроль рабочего времени это несколько разные задачи. Выше в ветке это уже обсуждалось — почитайте.

N_>Т.е. ради этой надуманной исключительно редкой ситуации готовы снизить продуктивность работы, мотивацию и лояльность сотрудников компании?

Я где-то написал, что я так делаю?

Здравствуйте, dZentle_man, Вы писали:
BZ>>я начинал во времена когда персоналок было всего с сотню на весь город. тогда я тщательно отлаживал программу на бумаге прежде чем нести её на компутер. с тех пор всё только ухудшалось

Z_>Я начинал пользоваться(только пользоваться) кампутером с 98-й винды. После 2000-й все только ухудшалось)
отладка под 3ый, 95ый и 98ой виндовоз, очень часто сопровождалась полной перезагрузкой компа после запуска проги, когда можно было сходить и чаю налить, пока комп снова загружается. тот факт с 2000ого виндовоза можно действительно завершить сдохший процесс и повисшее приложение не весит весь комп целиком это был прямо гиганский прорыв того времени.

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

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

Z_>>>Я начинал пользоваться(только пользоваться) кампутером с 98-й винды. После 2000-й все только ухудшалось)
__>>отладка под 3ый, 95ый и 98ой виндовоз, очень часто сопровождалась полной перезагрузкой компа после запуска проги, когда можно было сходить и чаю налить, пока комп снова загружается. тот факт с 2000ого виндовоза можно действительно завершить сдохший процесс и повисшее приложение не весит весь комп целиком это был прямо гиганский прорыв того времени.

BZ>вообще-то начиная с os/2 и nt

ну да, но ни первая ни вторая большой популярности, по крайней мере среди моих знакмых не получила. первая была малораспространена хотя бы потому что ее было не достать — не было интернета и все ходили друг к другу в гости со своим j3qq4-h7h2v-m3hk8-..., windows nt достать было можно, но там была еще сырая технология — появились сначала проблемы с ntfs, по-моему при большой занятости диска, они его формат даже в одном из сервис паков сменили, ну и самое главное конечно что на него directx больше 3его по-моему не вставал, поэтому домой nt не ставили и дома мучались часто с отладкой именно в "неправильной ос".
ntfs — которая не забивала мусором открытые файлы как fat32 в случае резкой перезагрузки и технология nt — нормальное разделение процессов и реальный такс менеджер это, действительно, единственные две нормальные технологии, которые были сделали в windows для человеческой жизни девелоперу за последние лет 15

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

A>Тогда мне совершенно не понятно зачем он должен постоянно находится в офисе. Если его отвлекают раз в день, то можно и предупредить об этом. Причём не встиле — "когда вам всем завтра будет удобно собраться на совещание". А сообщить время совещания. И уже не важно какой у кого график — все придут, даже если это неудобно.

Если бы тестеры всегда предупреждали "завтра в 14:20 найдем шоустоппер, приходи", то конечно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>Насчет созитательной спорить не хочу. Тонкая материя эта созидательная деятельность. Но практика такова, что отсутствие контроля убивает на корню совершенно любой проект. От сидии инжектора до чего угодно.
G>Ну не работает большинство людей без контроля.

Возьмите армию как пример организации, где контроль возведен в абсолют. Сможете припомнить, чего такого армия (любая) создала за всю историю человечества? Да, может копать, может не копать. Но вот даже оружие для себя самой разработать не может.

L>>Ваше желание построить программистов в шеренгу и заставить маршировать на очередной митинг — типичный образчик микроменеджмента. То, что Вам с таким подходом в течение многих лет что-то удается делать, скорее всего, заслуга исключительно Вашей команды, ну плюс Ваша недоработка. Плохо заставляете.

G>Мне вообще было бы очень интересно, как по-твоему выглядит процесс контроля команды хотя бы в 10 человек.

Контролировать команду не надо. Нужно контролировать процесс. А уж сам процесс может диктовать необходимость контроля команды или же отстутсвие оной необходимости.

В последнее время я склонен думать, что когда речь идет о проектной работе, чем разработка ПО и является, то существует либо иллюзия контроля процесса в виде waterfall и к нему примкнувшим прадигм, являющимеся по сути завуалированными методами контроля сотрудников, либо структуры вроде scum, где контролируется именно процесс.

20.09.2010 12:16, genre пишет:
>
> Не бывает такой абстрактной мотивации "хочу работать".
Да. Не везет вам с сотрудниками...

Posted via RSDN NNTP Server 2.1 beta

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

G>>Ну не работает большинство людей без контроля.

L>Возьмите армию как пример организации, где контроль возведен в абсолют. Сможете припомнить, чего такого армия (любая) создала за всю историю человечества? Да, может копать, может не копать. Но вот даже оружие для себя самой разработать не может.

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

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

G>>Мне вообще было бы очень интересно, как по-твоему выглядит процесс контроля команды хотя бы в 10 человек.

L>Контролировать команду не надо. Нужно контролировать процесс. А уж сам процесс может диктовать необходимость контроля команды или же отстутсвие оной необходимости.

Что значит контролировать процесс?

L>В последнее время я склонен думать, что когда речь идет о проектной работе, чем разработка ПО и является, то существует либо иллюзия контроля процесса в виде waterfall и к нему примкнувшим прадигм, являющимеся по сути завуалированными методами контроля сотрудников, либо структуры вроде scum, где контролируется именно процесс.

В scrum контролируется именно работа каждого конкретного сотрудника.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

L>Если Вам так интересно — на совещания, назначенные мной, приходят все, кто требуется и в строго означенное время и место.

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

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

А если за жопочасы платить, то понятно, что все будут только из-под палки работать: мотивации-то нету никакой.

L>>>Ваше желание построить программистов в шеренгу и заставить маршировать на очередной митинг — типичный образчик микроменеджмента. То, что Вам с таким подходом в течение многих лет что-то удается делать, скорее всего, заслуга исключительно Вашей команды, ну плюс Ваша недоработка. Плохо заставляете.

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

L>Отнюдь. Вы о себе как менеджере и о своей команде рассказали гораздо больше, чем Вы думаете.

+

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

L>Каким таким магическим образом наличие менеджера исправляет архитектуру и дизайн гуя?

Например тем, что девелопер магически получает по рукам если гуя кривая.

G>>PS кстати, каждый второй опен-сорс проект сделан программистами без менеджеров. Как бы показательно.
L>Samba, например. Apache там. Очень показательно, в самом деле

Ну ты выбрал для примера те, которые не подходят в выделенное. И чего?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

L>>Каким таким магическим образом наличие менеджера исправляет архитектуру и дизайн гуя?

G>Например тем, что девелопер магически получает по рукам если гуя кривая.

Каким таким образом? Менеджер у нас — Гудини и проблемы юзабилити и баги в гуе видит как рентген в аэропорту?

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

G>>>PS кстати, каждый второй опен-сорс проект сделан программистами без менеджеров. Как бы показательно.
L>>Samba, например. Apache там. Очень показательно, в самом деле

G>Ну ты выбрал для примера те, которые не подходят в выделенное. И чего?
А то, что тоже могу ляпнуть что-нибудь подобное про коммерческие проекты, наляпанные под руководством эффективных менеджеров.

Задача менеджера — управлять, а не командовать. Доходит, к сожалению, не до всех.

Здравствуйте, Eugeny__, Вы писали:
E__>Свое видение сего действа я описал, с удовольствием послушаю, как оно у крутых дядек

.

Да примерно так и есть у подобных эффективных как ты опясал. Еще часто встречается : " А вот тут вчера в одной умной книжке вычитал про виртуальный диструктор, оказывается классная штука! Саша и Таня, срочно перепишите ваши запросы с использование виртуальных деструкторов.".

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

L>Сможете припомнить, чего такого армия (любая) создала за всю историю человечества?
Дач понастроила немало

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

G>>>Ну и как-то всё очень общо у тебя получается. Правила — плохо.

E__>>Не правила плохо. Плохо, когда шаблонные правила пытаются бездумно применять где ни попадя и как не попадя. Правила должны быть. Но они должны быть составлены менеджером исходя кучи факторов: специфика задачи, бюджет, команда, да тысячи их. А когда берется кем-то написанная простыня с "супер-пупер технологией ХХХ", и минуя мозг внедрятеся в компании как Закон Божий — вот это беда.

G>Ну тут мы вроде пришли к согласию.
G>За одним пунктом. Очень часто лучше уж пусть бездумно внедряют "супер-пупер технологией ХХХ", чем вообще бардак. Технология худо-бедно проверена общественностью и в среднем будет работать лучше чем перманентный бардак.

Для больших компаний — да. Там лучше дебилкуватый свод правил и тотальная бюрократия, чем неконтролируемый бардак. Но в небольших средах разработчиков, которым выгодно развивать компанию(в том числе и финансово, причем профит виден незамедлительно), чрезмерная бюрократизация и армейская дисциплина ни к чему, она наоборот все затормозит. Слыхили байку про процесс покупки принтера в огромной корпорации и стартапе?

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

E__>Ну честно, не могу я серьезно себе представлять это. У вас там системы документооборота/багофичетрекера нету, что-ли? Зачем этот цирк по утрам?

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

L>>Сможете припомнить, чего такого армия (любая) создала за всю историю человечества?
O>Дач понастроила немало

По крайней мере часть знаменитых римских дорог была построена римскими же легионерами

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

L>Возьмите армию как пример организации, где контроль возведен в абсолют.

Не контроль, а выполнение приказа (боевой задачи).

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

E__>>Слыхили байку про процесс покупки принтера в огромной корпорации и стартапе?

G>Нет

	Скрытый текст
	Покупка принтера в небольшой компании и транснациональной корпорации Небольшая компания: в четверг в 15:00 подписывают счет у директора, в 16:00 счет оплачивают, в пятницу поставщик привозит и устанавливает принтер прямо в офис. Транснациональная корпорация: 1. Мы понимаем, что нам нужен принтер. 2. Идем к начальнику, спрашиваем, есть ли деньги в бюджете. 3. Денег на новый принтер нет, придумываем с начальником, как бы этот принтер замаскировать. 4. Решаем, что принтер будет у нас называться "чайник", т.к. на чайник деньги есть. 5. Выписываем счет у продавца, слезно просим его в счете написать "чайник", а не принтер. 6. Продавец после долгих споров со своей бухгалтерией все-таки выставляет счет на принтер. 7. Оформляем к этому счету кучу внутренних бумажек, причем, как в электронном варианте (у нас система электронного документооборота), так и в бумажном. Сочиняем служебную записку: "без чайника жить не можем", иначе ход счету не дадут. 8. Подписываем счет и записку у начальника. 9. Подписываем у начальника начальника. 10. Подписываем у начальника по финансам. 11. Подписываем у начальника по закупкам. 12. Тот не подписывает, говорит, что чайники мы покупаем только у компании Х и нигде больше, это корпоративная политика. 13. Звоним в компанию Х, узнаем, что принтер под видом чайника они нам продать не могут. 14. Наш начальник убалтывает начальника по закупкам закрыть глаза на правила закупок. 15. Счет теряется где-то. 16. Выписываем новый, проходим шаги 7-14. 17. Подписываем у генерального директора. 18. Отдаем в бухгалтерию на оплату. 19. Выясняется, что при оформлении внутренних документов мы неправильно указали статью бюджета, чайники проходят по административному департаменту, соответственно, на счете должны расписаться все начальники этого департамента. 20. Переделываем счет на "чайник с управлением по USB", проходим шаги 5-11, теперь это проходит по нашему департаменту. 21. Начальник по закупкам не подписывает, т.к. такие "чайники с USB-портом" являются стандартным оборудованием и поставляются всем филиалам компании централизовано раз в месяц. 22. Понимаем, что стройную систему не обмануть, оформляем заявку в отдел закупок с просьбой приобрести "копировальный аппарат с USB-портом" (он еще и печатать умеет), на него деньги в бюджете есть, как оказалось. 23. Подписываем у начальника. 24. Подписываем у начальника начальника. 25. Подписываем у начальника по финансам. 26. Подписываем у начальника по закупкам. 27. Не успеваем провести заявку до 25 числа текущего месяца (уже 26-ое), ждем месяц до следующего срока подачи заявок. 28. Заявка уходит в центральный филиал компании. 29. Про заявку ничего не слышно 2 месяца. 30. Выясняется, что заявка потерялась в центре, отдел закупок просят оформить ее заново, проходим шаги 22-29. 31. Заявка возвращается из центра с пометкой не являются стандартным оборудованием, т.к. уже устарели, стандартны только с сетевыми картами. 32. Переделываем заявку на "копировальный аппарат с сетевой картой", проходим шаги 22-29. 33. Статус заявки становится совсем непонятным, полное молчание со стороны центрального филиала. 34. Пишем письма начальнику: "срочно нужен принтер, а то работа стоит". 35. Начальник пытается узнать статус заявки "копировальный аппарат с сетевой картой" в центре, ему говорят, что копир уже давно выслали. 36. Ждем месяц. 37. Изменяем бизнес-процесс так, чтобы принтер не был нужен совсем. Печатаем документы, послав их самим себе на факс через электронную систему отправки факсов. 38. Забываем про заказ, рвем отношения с первоначальными поставщиками, которые нам выставили счет с таким трудом (кстати, они были нашими хорошими партнерами на протяжении многих лет), ругаемся со всеми, кто требует от нас печатные документы (факс печатает из рук вон плохо). ... 39. Через год в кабинет вваливаются какие-то грузчики и загромождают помещение какими-то коробками. 40. Вскрываем их и обнаруживаем 5 кофеварок с портами FireWire и PS/2, софт, лицензии к софту на 500 пользователей, дополнительные модули, все это стоимостью 350 тысяч долларов... Ба! Да это ж наш заказ!........ А принтера нет...

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

AV>>У нас на проекте нет жесткого требования отработать сколько-то там часов. Главное, чтобы работа была выполнена в срок. Причем, опять же, сроки практически никогда не спускаются сверху.

G>А теперь давай представим, что ты директор компании в которой работает 100 программистов. Каждый назначает себе сроки сам. И регулярно (это такое свойство человеческое переоценивать свои способности и недооценивать риски) половина из них промахивается в своих оценках. При этом работая кто 30, а кто 50 часов в неделю.

G>Степень твоего доверия этим срокам?

В целом фигово. Но стоит разобраться в причинах таких промахов. Вот только я сомневаюсь в том, что причиной будет именно гибкость в рабочем расписании.

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

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

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

Смысл такой работы от звонка до звонка?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

AV>>Одним из факторов может оказаться. Осталось только оценить насколько сильно этот фактор влияет.

G>И оценить негативные последствия такого фактора.

Да. Вот только пока что с этим большой напряг.

AV>>А насчет перенапрягаться, то не нужно так делать. Это вредно сказывается на работе. Нужно чтобы работа была выполнена в срок.

G>Опять возникает это магическое словосочетание "в срок". Тебе разве платят сдельно?
G>Сомневаюсь, скорее всего твой трудовой договор в сочетании с ТК подразумевает, что ты продаешь работодателю 40 часов в неделю за определенную плату, так?

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

G>>>Эта ситуация более прозрачна для руководства. Один источник проблем, то что люди тупо не ходят на работу, уже устранен.
AV>>Осталось только разобраться является ли это источником проблем. К тому же, если ты не заметил, то нико не предлагал не ходить на работу.

G>ходить. по 15-20 часов в неделю например.

Даже на секунду положим что так хотят. Что в этом плохого, если они выполняют все поставленные задачи?

G>>>Осталось разобраться, где проблема — сроки невменяемые или люди халявят уже в офисе.
G>>>В первом же случае — либо все забили ходить на работу, либо халявят в офисе, либо называют неадкватные сроки.
AV>>Полагаешь, что в первом случае так сложно проверить забил человек ходить на работу или нет?

G>так если начнешь проверять ты и придешь к тому варианту, где считают сколько часов человек отработал.

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

G>>>Причем если представить что я руководитель, то мне лично проверить, что я занижаю сроки будет проще, чем то, что сотрудники их завышают.
AV>>Очень опасное заблуждение.

G>Правда проще. РУководитель мотивирован ставить реальные сроки. Работник мотивирован завышать сроки.

Точно так же руководитель мотивирован занижать сроки. Проходили через такое уже.

G>>>Есть две грани на этой шкале. СОвершенно свободный график — совершенно жесткое расписание. Истина как обычно где-то посередине. Большинство устроит график с фиксированными 4-5 часами присутствия в день.

AV>>А примерно такое пересечение в среднем и получится при свободном графике.

G>Ну вот у меня перед глазами два человека которые при свободном графике практически не пересекаются в офисе. Это хорошо, что они друг от друга не зависят. А если бы зависили?

Пробовали?

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

G>Бывают задачи когда человека можно вообще на месяц дома запереть и пусть работает. А бывает обратное.
G>Например задачи багфикса часто требуют большого количества коммуникаций. И тогда скорость работы из дома сильно падает.

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

У нас даже еще веселее. Фактически, наша здешняя команда является частью команды заказчика. При этом у нас 10 часов разбежки. И нет никаких проблем с коммуникациями и скорость работы отличная. А все потому что тамошние ребята тоже на первое место ставят результат, а не просиживание штанов.

AV>>А было бы у меня требование отработать 8 часов (как ты ратуешь), то мои задачи пришлось бы работодателю сдвигать на неделю.

G>Я не ратую за жесткий рабочий график. Я как и любой вменяемый человек люблю приходить на работу когда мне удобно. Я лишь пытаюсь объяснить почему у руководства могут быть причины требовать детерминированного графика в некоторых случаях.

В некоторых случаях и постоянно — это две большие разницы.

AV>>Ибо сейчас при свободном графике я плачу добром за добро. А при жестком расписании нафиг не это не впало.

G>Это слишком категоричное утверждение

Да нет, просто это мой подход.

G>А если жесткий график и необходимость сделать дело в срок, но денег в два раза больше?

Да хоть в десять раз больше. Деньги это еще далеко не все. Три года назад я сменил работу несмотря на как раз примерно двоекратное уменьшение денег. Хотя по факту оказалось, что я практически ничего не потерял. Но об этом я узнал несколько позже.

G>>>ВОт кстати, не довелось сталкиваться с банками, кто в курсе как там, фиксированный график или свободный?
AV>>Сталкивался, но не работал там. И уж тем более, что я не считаю банки эталоном в этом вопросе.

G>Однако софт пишут. И неплохой. А если верить некоторым местным персонажам не должны ну никак.

В банках? Ну не знаю, не знаю. Как когда. А насчет того, что пишут, то с чего бы не должны.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

24.09.2010 10:03, Glоbus пишет:
> E>1. Спонтанная необходимость обсуждения технических деталей. Возникли
...
>
> E>В общем, как-то так.
>
> +100! Особенно по пункту 2 — +200! У нас в конторе такая хрень
> практикуется — полнейший бардак.
Русские менеджеры ну почитайте вы хоть немного книжки по управлению (и
не только обложку).

Posted via RSDN NNTP Server 2.1 beta

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

AV>Да ты шо? Образумь нас. А то мы уже более года на проекте где между нашей командой и командой заказчика 10 часов разбежки.

У меня тоже с заказчиком разница во времени. Работа конечно движется. Но реально неудобно. Коммуникации были бы удобнее и быстрее если бы разницы не было.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

24.09.2010 18:00, Glоbus пишет:
>
> Я украинский тимлид , и именно потому что читаю многа-многа книшкафф, а
Ну тогда "мифический человеко-месяц" читал и понимаешь, что избыток
коммуникации затормаживает работу очень сильно.
> также работаю в конторе с мегагибким графиком посещений (которым многие
> девы очень любят злоупотреблять) отвественно заявляю — реально бардак:
> пока не введешь минимальную дисциплину (приходит на работу к
> определенному времени, постоянная отчетность по работе и т.п.) и тому
> подобное бардак только нарастает
А я сколько работал видел всегда одну и туже картинку, как только вводят
(приходит на работу к определенному времени, постоянная отчетность по
работе и т.п.) качество и скорость разработки падает очень сильно.
Пример: RESIF SA (сейчас новая жизнь, контора обанкротилась — просто не
сделали заказ очень большой с превышением срока в 2 раза, была продана с
молотка, торговую марку не сменили).

P.S. Думаешь, вы "эффективные украинские менеджеры" чем-то отличаетесь
от "эффективных русских менеджеров". "Эффективные" — они и в америке
"эффективные", только они там не выживают в конкуренции с просто
менеджерами.

Posted via RSDN NNTP Server 2.1 beta

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

>> Проблема в том, что лаг в один день — обычное дело. Для вас может и
>> некритично, может вы и привыкли к такому лагу.
V>Я как сторонний уже чел, но хорошо знаю, эту контору. Ты не поверишь, но
V>лаг у них и в 5 мин бывает, если это критично, ну а если не критично, то
V>смысл бегать, как ужаленным.

Это да, особенно если работать с боссом.

Но сейчас у нас на проекте проще. Босс нас не трогает.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>А какая разница за сколько человек сделал необходимый объем работ? Вот просидели два человека 5 дней по 8 часов. Каждый выполнил те задачи, что стояли перед ними. И что дальше? Какая разница, если то же самое они сделали за те же 5 дней, но один при этом тратил на это 8 часов в день, а другой — всего лишь по 6?

G>Разница в том, что "необходимый объем работ" для каждого из них разный.

И что? Как в этом поможет 8 часов? Только не говори

AV>>>> Гораздо продуктивнее анализировать результаты деятельности программиста, и на их основании делать выводы.
G>>>ТАк одно другому не мешает, а помогает.
AV>>И как же помогает знание "просиженного времени"?

G>Я уже писал об этом. Как ты будешь сравнивать людей делающих разное количество разных задач за разное время? Надо какие-то показатели уметь приводить к общему знаменателю.

И толку? Вот Вася за 8 часов сделал один модуль. Петя — 5 модулей. Как будем приводить к общему знаменателю? Будем рассматривать сложности модулей? ОК. Если я удовлетворен тем, что Вася делает всего лишь один, но гораздо более важный модуль, то буду платить ту з.п. о которой мы договорились. И если я считаю, что его модули более важны для проекта, то предложу Васе з.п. большую, чем Пете.

G>Если ты умеешь формально померять сложность задач — то можно уравнивать это. А если не умеешь?

То в этом случае общий знаменатель ничем не поможет

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>5. У вас тоже есть диагарма Ганта, достаточно приближенная, где отражен
V>roadmap проекта и ваша задача, чтобы ваша диаграмма соответствовала
V>диаграмма ваших подчиненных.

Вот на этом месте у меня возникают серьезные сомнения.
Любой человек кто пытался мало мальски сложный проект вести с помощью диаграмм Ганта иначе как матом о них не вспоминает.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>именно сложности. если мы знаем, что васин модуль сложнее всех петиных, то ясно что вася работает лучше чем петя.

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

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

AV>Нефиксированный рабочий день тоже вполне может давать прекрасную определенность. Нефиксированный график не означает что каждый творит что хочет.

Не означает. Но и определенности не добавляет. Тем более прекрасной.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>>Да, может так случиться, что по хожу работы выясниться, что мне надо у них что-то уточнить, а там уже спят. Ничего страшного. Отложу это до вечера, а сам продолжу работать над другими частями. Такие затыки ничем не отличаются от подобных проблем при работе внутри команды.

G>Это верно для достаточно больших сроков и хорошего параллелизма. А если срок допустим 2-3 недели и нужно сделать вот конкретно эту часть?

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Почему ты считаешь, что затыки являются постоянным явлением и что за компом надо сидать чуть ли не каждый день до середины ночи?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

А то мне сегодня придется за всех вас отдуваться.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>Вот на этом месте у меня возникают серьезные сомнения.
G>>Любой человек кто пытался мало мальски сложный проект вести с помощью диаграмм Ганта иначе как матом о них не вспоминает.
CC>На моей прошлой фирме пытались внедрить.
CC>Получился полный отстой.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>И вообще, сидишь в отпусте, то сиди и не чирикай.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

E>Достаточно важно, по ряду причин.

E>1. Спонтанная необходимость обсуждения технических деталей. Возникли вопросы, хочется обсудить, а на рабочем месте нет то одного, то другого. Тот пришел, другой ушел на обед. Другой вернулся с обеда, тот ушел на обед и в таком духе. А теперь представим, что разработчиков, с которыми надо обсуждать что-то (не одновременно, а в разных комбинациях) не двое, а два десятка и все любят гибкий график и не регламентированный обед.

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

E>2. Приходят пара сотрудников, сначала к 10, потом начинают приходить к 10:20, потом к 10:45, потом в 11:15. Сначала раз в две недели, потом два раза в неделю, потом 3 дня из 5. Глядя на них, остальные тоже начинают позволять себе вольности. Через несколько месяцев получаем отдел разработки, где все приходят когда хотят, уходят когда хотят и ходят на обед когда хотят. Хочешь собрать совещание с 3 участниками, и см. пункт 1. Окей, думаете вы, а почему бы не запланировать совещание заранее? На 10 не запланируешь — некоторые приходят к 11. Планируем на 11 — а такая же ерунда, люди отучились приходить вовремя.

Зачем устраивать совещание с 3мя сотрудниками? Я вообще совещания считаю бессмысленным времяпровождением...

E>Прелесть работы в одном офисе в том, чтобы упростить и ускорить коммуникации, тем самым ускорить решение вопросов, а с таким подходом, когда нужных людей не соберешь быстро, в чем тогда смысл?

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

14.09.2010 12:57, Donz пишет:
>
> Насколько вам важно, что работник находится на работе строго по часам
> без плавающего прихода и ухода и с регламентированным обедом? Какие в
> этом плюсы? Можете дать четкий расчет выгоды компании от этого?
Ну как же, заходишь в коровник (тьфу. в офис размеров так 20x100 м, где
програмеры сидят). Смотришь на эти торчащие макушки и понимаешь, как
много у тебя коров (тьфу, програмеров).

> Или наоборот, в чем видите выгоду в ненормированном и
> нерегламентированном рабочем дне?
А это у капиталистов спрашивай.

Posted via RSDN NNTP Server 2.1 beta

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

D>Насколько вам важно, что работник находится на работе строго по часам без плавающего прихода и ухода и с регламентированным обедом? Какие в этом плюсы? Можете дать четкий расчет выгоды компании от этого?

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

С другой стороны, на свободный график народ охотнее идет, и работает эффективнее, поэтому каждый сам выбирает, что ему важнее.

8>Свободный ненормированный график с обязательным присутствием в определенные часы (11-15 например).

8>1) Позволяет людям приходить\уходить в достаточно вольной форме.
8>2) Есть время для командной работы.
8>3) "ненормированный" позволяет в авральных ситуациях заставить поработать до упора.

Это уже не такой уж свободный и ненормированный график — на обед в этом промежутке не сходить? И в 11:30, например, не прийти

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

В целом, это и есть один из компромиссных вариантов.

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

8>Свободный ненормированный график с обязательным присутствием в определенные часы (11-15 например).

8>1) Позволяет людям приходить\уходить в достаточно вольной форме.
8>2) Есть время для командной работы.
8>3) "ненормированный" позволяет в авральных ситуациях заставить поработать до упора.

Угу. Унас именно так.
1) обязательное присутствие с 12 до 17.
2) должен отработать Х*8 часов в месяц, где Х количество рабочих дней в этом месяце.

Кто не справился не получает премии

GIV>Угу. Унас именно так.
GIV>1) обязательное присутствие с 12 до 17.
GIV>2) должен отработать Х*8 часов в месяц, где Х количество рабочих дней в этом месяце.

GIV>Кто не справился не получает премии

Как с обедом у вас обстоит дело? Перерыв в конкретное время или в любое из этого широкого диапазона?

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

E>Достаточно важно, по ряду причин.

E>1. Спонтанная необходимость обсуждения технических деталей. Возникли вопросы, хочется обсудить, а на рабочем месте нет то одного, то другого. Тот пришел, другой ушел на обед. Другой вернулся с обеда, тот ушел на обед и в таком духе. А теперь представим, что разработчиков, с которыми надо обсуждать что-то (не одновременно, а в разных комбинациях) не двое, а два десятка и все любят гибкий график и не регламентированный обед.

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

E>2. Приходят пара сотрудников, сначала к 10, потом начинают приходить к 10:20, потом к 10:45, потом в 11:15. Сначала раз в две недели, потом два раза в неделю, потом 3 дня из 5. Глядя на них, остальные тоже начинают позволять себе вольности.

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

E>Через несколько месяцев получаем отдел разработки, где все приходят когда хотят, уходят когда хотят и ходят на обед когда хотят. Хочешь собрать совещание с 3 участниками, и см. пункт 1. Окей, думаете вы, а почему бы не запланировать совещание заранее? На 10 не запланируешь — некоторые приходят к 11. Планируем на 11 — а такая же ерунда, люди отучились приходить вовремя.

Не надо путать раздолбаев и гибкий срок прихода на работу. Не явился на совещание по неуважительной причине — получи полноценный втык. И естественно, что должны быть обозначены часы, когда работник гарантировано должен быть на работе (или доступен по телефону, если вдруг ушел на обед).
Вопрос в том, насколько оправданно заставлять работников приходить ровно к девяти или ровно к десяти и вынуждать писать служебные записки, если надо прийти в 10:15.

E>Прелесть работы в одном офисе в том, чтобы упростить и ускорить коммуникации, тем самым ускорить решение вопросов, а с таким подходом, когда нужных людей не соберешь быстро, в чем тогда смысл?

Смысл в том, чтобы не писать служебки на каждый чих.

E>В целом, я за гибкий график в разумных пределах (у нас эти разумные пределы обозначены). Проблема в том, что привыкнув к удобству в этих разумных пределах, каждому сотруднику хочется эти пределы расширить, просто потому что удобно вставать не по будильнику, а потому что выспался. И ведь правда, если не выспался — какая эффективность работы будет? А лечь спать вовремя — это скучно, ведь вечером хочется весело провести время.

Гибкие пределы — это какие? Судя по ответу про двух сотрудников, гибкости не очень видно.

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

G>Тут действительно есть нюанс. И не один.
G>А кто определяет сроки на решение задач?
G>А как бороться с видимым неравноправием в команде?
G>А как определить, что человек действительно работы делает не меньше чем другие?
G>итд.

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

G>так что проще чтобы все работали по 8 часов в день и все.

Дык не работают. Я работал по схеме 40 в неделю, частенько видел людей которые по 1-2 часа в день,
просто сидят и ничего не делают, но уйти не могут ибо часы. Только мучают себя, что не прибавляет эффективности.

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

E>Ну ладно, мы не наивные, мало кто реально работает 8 часов в день...

Я работаю 40 часов в неделю. Именно работаю, поскольку оплата у меня почасовая.

D>Два десятка, с которыми надо обсудить технические детали по одному проекту? Что-то слабо верится. В любом случае, обсуждение с двумя десятками — это широкомасштабное совещание, на которое надо рассылать приглашения.

Я специально написал, что не одновременно и нигде не писал что по одному проекту. Читаем внимательно, иначе диалога не получится

D>Сам был грешен, когда пытались заставить приходить к десяти

Дык, некоторые и к 11 не в состоянии...тут не в абсолютном времени дело даже, а в принципе в способности прийти к определенному времени.

D>Не надо путать раздолбаев и гибкий срок прихода на работу. Не явился на совещание по неуважительной причине — получи полноценный втык. И естественно, что должны быть обозначены часы, когда работник гарантировано должен быть на работе (или доступен по телефону, если вдруг ушел на обед).

А кто ж их путает

Я в целом про тенденцию к расслаблению, когда есть гибкость, говорю.

D>Вопрос в том, насколько оправданно заставлять работников приходить ровно к девяти или ровно к десяти и вынуждать писать служебные записки, если надо прийти в 10:15.

Если говорить про разработчиков, чаще всего вообще не оправданно, поэтому, как я написал в первом ответе, в целом я за гибкий график. Но гибкий график в моем понимании немного не то же самое, что приходить во сколько получилось (вздумалось). Комфортно приходить в 11 — окей, но тогда пусть это будет 10:50, 10:55, 10:59, 11:00, но не 11:15? Я тогда спокойно буду приходить в 11, и сразу решать вопросы, если есть, с сотрудниками, которые уже на месте, а не буду ждать еще 15-20 минут, пока они подтянутся.

D>Смысл в том, чтобы не писать служебки на каждый чих.

Ну это само собой, если про мой опыт говорить, у нас ни одной служебки по этому поводу за много лет не написано и не требовал

D>Гибкие пределы — это какие? Судя по ответу про двух сотрудников, гибкости не очень видно.

Время прихода устанавливаешь себе сам удобное в диапазоне +/- 1 час от 10. Удобно к 9 — ходи к 9, удобно к 11 — ходи к 11, 10:45 — не вопрос.
Если форсмажор — информируешь и все. Если задерживаешься на больше чем пол часа вследствие каких-то обстоятельств — информируешь и никаких санкций.

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

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

Да, конечно, тут много вопросов возникает.
И от конкретного работника тут многое зависит, от его отношения к работе.

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

S>как то я слабо представляю как можно все 40 часов работаь без перерыва.
S>Я бы сказал находишься в офисе 40 часвов в неделю

S>у меня тоже оплата почасовая, но
S>анекдоты почитать хочется

S>почту почитать
S>с коллегой поговорить как выходные прошли
S>... и тому подобные нерабочие моменты
S>реально работать я думаю часов 5-6 можно, а может и меньше

Я не нахожусь в офисе, я работаю дома.
Мне не платят за "поговорить как выходные прошли".
Мне платят за работу.

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

B>Круче только Яйца. Вы и когда отлить ходите секундомер останавливаете?

А смысл, одна-две минуты роли не сыграют.
А вот 10 минут значение имеют.

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

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

B>>Круче только Яйца. Вы и когда отлить ходите секундомер останавливаете?

UVV>А смысл, одна-две минуты роли не сыграют.
UVV>А вот 10 минут значение имеют.

т.е. тупо 8 часов втыка в работу без отрыва (обед не считаем)? Герой.

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

B>

т.е. тупо 8 часов втыка в работу без отрыва (обед не считаем)? Герой.

Я где-то написал, что работаю "без отрыва"?
Я написал, что работаю 40 часов в неделю, а когда я это делаю — я решаю сам.

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

B>Наймите QA нормальных

В Индии

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

B>Или у вас ночью critical'ы постоянно всплывают и нужно их срочно фиксить в 11 утра?
У нас, если всплывет критикал, то фиксить будешь ночью (такого со мной пока не было, ттт). Если менее срочное, то досыпаешь до 7, и по дороге на работу начинаешь фиксить.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

B>>Или у вас ночью critical'ы постоянно всплывают и нужно их срочно фиксить в 11 утра?
O>У нас, если всплывет критикал, то фиксить будешь ночью (такого со мной пока не было, ттт). Если менее срочное, то досыпаешь до 7, и по дороге на работу начинаешь фиксить.

Что, прям так, поднимут в 3 ночи и заставят ехать на работу? Жестяк.

B>Пока они "подтягиваются" можно делать что-то другое. Или у вас ночью critical'ы постоянно всплывают и нужно их срочно фиксить в 11 утра

Спасибо за ценный совет, даже не знал как быть.

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

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

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

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

GIV>>2) должен отработать Х*8 часов в месяц, где Х количество рабочих дней в этом месяце.

8>Вот это меня всегда удивляло. Типа не меньше 40 часов в неделю.

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

или всё же предпочитаешь работать по 8 часов и получать за это соответственно?

8>В итоге люди зачастую просто сидят, насижывают эти часы и ничего при этом все равно не делают.

8 часов программить действительно нереально. но можно думать или учиться. а может программитсам действительно надо сократить рабочий день и з/п заодно тоже, фиг его знает

8>Лучше пусть пойдет своими делами займется, главное что бы поставленные задачи успевал сделать
8>к сроку. Тут конечно много нюансов, но все же.

становись фрилансером — тут можно вообще из дома не выходить

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

A>PS Дикие понятия рашкованчиков о мотивации меня уже даже не забавляют.

А...
Не заметил кому отвечал.
Извини. Больше не повториться (в смысле не буду отвечать).

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

B>Т.е. не работают? А если заказчик в 7-8 часах? И у него on-site тоже есть QA? Или вы такой возможности не представляете?
Тестить на заказчике? Хммм....

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

B>Что, прям так, поднимут в 3 ночи
Ага, звонят поганцы.

B>заставят ехать на работу? Жестяк.
Из дома будешь корячиться.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

B>Т.е. не работают? А если заказчик в 7-8 часах?
Кстати, из-за таймзоны оффшорное программирование — зло

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

GIV>>Угу. Унас именно так.
GIV>>1) обязательное присутствие с 12 до 17.
GIV>>2) должен отработать Х*8 часов в месяц, где Х количество рабочих дней в этом месяце.

GIV>>Кто не справился не получает премии

E>Как с обедом у вас обстоит дело? Перерыв в конкретное время или в любое из этого широкого диапазона?

В любое. Можно и не из этого диапазона

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

B>Важна прежде всего пресказуемость.
согласен. у нас можно не являться на работу, если идет снег. снег -- это отмаз убедительный. но в таком случае сотрудник просто посылает письмо, типа не ждите. буду (не буду) в онлайне. ловите (не беспокойне) по телефону. ну и так далее. причем, когда ему пишешь письмо, а его нет на рабочем месте, то у него сразу настроен автоответ. и он сразу сообщает как когда и что.

отсюда — вольности в отношении работы допускаются, поскольку никого сильно не напрягают.

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

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

B>Мне самому так проще планировать свободное время и я точно знаю,
B>когда я на работе и когда я свободен от работы.
это да. но если у вас ланч с 12 часов, а в этом момент вы чем-то заняты (особенно совместной работой с коллегами). что вы сделаете? будете работать до победы (возможно, оставшись без ланча) или в 12:01 вас на рабочем месте уже можно и не искать?

Здравствуйте, мыщъх, Вы писали:

М>это да. но если у вас ланч с 12 часов, а в этом момент вы чем-то заняты (особенно совместной работой с коллегами). что вы сделаете? будете работать до победы (возможно, оставшись без ланча) или в 12:01 вас на рабочем месте уже можно и не искать?

Буду работать дальше, но без обеда оставаться не намерян

Т.е. самое позднее за 15 минут до того, как закрывается столовка, будет сделан перерыв.
Коллега в общем человек и тоже скорей всего хочет есть.
Кстати, обед работе не помеха.
Можно обсуждать вещи и сидя за обеденным столом

Для работы как раз весьма полезно взять паузу и сбавить пар.

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

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

B>Здравствуйте, мыщъх, Вы писали:

B>Буду работать дальше, но без обеда оставаться не намерян

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

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

B>Коллега в общем человек и тоже скорей всего хочет есть.
B>Кстати, обед работе не помеха.
ну да. коллега принес ланч с собой и уже жадно ест на рабочем месте, громко чавкая. а мы работаем. а до ланча идти метров 50 будет. или даже все 100.

B>Можно обсуждать вещи и сидя за обеденным столом

такое тоже бывает. но вот мне неприятно обуждать что-то за едой.

B>Для работы как раз весьма полезно взять паузу и сбавить пар.
смотря что за работа...

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

B>Это скорей всего не потому что реально так нужно,
B>а потому что ты для себя так решил.
все так и есть. решил -- вот доделаю (уже чуть-чуть осталось) и пойду. а это "чуть-чуть" кончается когда коллеги уже по домам расходятся.

Здравствуйте, мыщъх, Вы писали:

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

B>>Здравствуйте, мыщъх, Вы писали:

B>>Буду работать дальше, но без обеда оставаться не намерян

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

B>>Т.е. самое позднее за 15 минут до того, как закрывается столовка, будет сделан перерыв.
М>у нас столовки нет. у нас с этим легче. мы по кафе. благо их куча. а если прийти сильно после ланча, то можно еще и хорошую скидку получить.

У нас столовка с 12.00 до 13.00. После 13.00 еды нету.
Кормят там вкусно, потому пропускать никто не хочет.

B>>Коллега в общем человек и тоже скорей всего хочет есть.
B>>Кстати, обед работе не помеха.
М>ну да. коллега принес ланч с собой и уже жадно ест на рабочем месте, громко чавкая. а мы работаем. а до ланча идти метров 50 будет. или даже все 100.

За рабочим столом у нас никто не ест.
Хочешь есть, иди в столовку. Она открыта всегда. Правда еда там по расписанию.
За рабочим столом только кофе, чай и другие напитки ( исключая алкоголь

)

B>>Можно обсуждать вещи и сидя за обеденным столом

М>такое тоже бывает. но вот мне неприятно обуждать что-то за едой.

Ну мы говорим о том что заботит в данный момент
Это может быть и работа и политика и красивые девушки на улице и вообще все что угодно.
Правил на этот счет нету. Уверен, что и у вас так же

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

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

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

B>Здравствуйте, мыщъх, Вы писали:

B>У нас столовка с 12.00 до 13.00. После 13.00 еды нету.
B>Кормят там вкусно, потому пропускать никто не хочет.
тогда понятно. у нас с 12 до 13 во всех кафе жуткая давка. иногда приходится обходить все кафе от мексиканских до вьетнамских и все равно ждать в очереди 20 пока не освободиться столик. потому на ланч мы коллегами выдвигаемся после 13:30. и еда вкуснее, т.к. повара не такие запыханные и готовят с умом

B>За рабочим столом у нас никто не ест.
а у нас едят. причем многие. мой коллега (с которым сидим в одном кабинете) носит ланч с собой через день. а почему у вас не едят? странный какой-то запрет...

B>Хочешь есть, иди в столовку. Она открыта всегда. Правда еда там по расписанию.
в столоку со своей едой что ли? а пустят?

B>За рабочим столом только кофе, чай и другие напитки ( исключая алкоголь

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

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

B>Это может быть и работа и политика и красивые девушки на улице и вообще все что угодно.
политикой у нас к счастью никто не интересуется. чуть-чуть говорили о футболе когда аргентина играла. о девушках говторит только мыщъх. остальные только завидут, ибо женатые не один год.

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

B>Исключение — друдновоспроизводимые баги, когда чуешь, что еще чуток и ты его поймаешь,
B>а пауза отбросит все назад и придется все повторять еще раз.
у меня к счастью такого нет, т.к. мой код работает в такой среде, что там чисто архитектурно все воспроизводимо и без проблем сделать реплей по факту сбоя. правда поскольку это линь, то основной отладчик — printf

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

A>А представим, что человек пришёл ровно в 10, как и положено. Это значит, что он в 11 должен сразуже с голой грудью бросаться на исправление бага. Причём исправить надо быстро. Минута простоя — тысячи долларов. Баг оказался не очень сложным. На исправление ушёл час. Решение сырова-то.

Вообще-то программеру нужно быстро понять причину баги и соответственно найти способ как клиент эту багу может обойти. Быстрый фикс обычно не требуется, т.к. все равно невозможен по административным причинам.

Здравствуйте, мыщъх, Вы писали:

B>>За рабочим столом у нас никто не ест.
М>а у нас едят. причем многие. мой коллега (с которым сидим в одном кабинете) носит ланч с собой через день. а почему у вас не едят? странный какой-то запрет...

Запрета нету. Просто не едят.

B>>Хочешь есть, иди в столовку. Она открыта всегда. Правда еда там по расписанию.
М>в столоку со своей едой что ли? а пустят?

Пустят. Столовка типа наша. Можешь делать там что хочешь, в пределах разумного.

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

E>

Прямо таки многие? Я вот вижу обратную ситуацию. О ТК работодатель вспоминает, когда ему удобно.

E>Ну ладно, мы не наивные, мало кто реально работает 8 часов в день
Не хочу разбивать сердце или спровоцировать инфаркт, но: http://www.rsdn.ru/poll/1846.aspx

Но это так, оффтоп.

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

D>>Два десятка, с которыми надо обсудить технические детали по одному проекту? Что-то слабо верится. В любом случае, обсуждение с двумя десятками — это широкомасштабное совещание, на которое надо рассылать приглашения.
E>Я специально написал, что не одновременно и нигде не писал что по одному проекту. Читаем внимательно, иначе диалога не получится

То есть, двадцать человек по разным вопросам и проектам, но именно с девяти до десяти и со всеми двадцатью? Тоже не верю.

E>Время прихода устанавливаешь себе сам удобное в диапазоне +/- 1 час от 10. Удобно к 9 — ходи к 9, удобно к 11 — ходи к 11, 10:45 — не вопрос.
E>Если форсмажор — информируешь и все. Если задерживаешься на больше чем пол часа вследствие каких-то обстоятельств — информируешь и никаких санкций.
E>Неужели не гибко? А про двух сотрудников — это как раз то что мне не нравится. Я уже написал, гибкость все понимают по-разному. Я понимаю это как возможность поменять стандартный график работы на удобный тебе, а Вы, по-видимому, понимаете это как приходить когда захочется. Ну последнее очень одобно любому сотруднику, ведь вообще не надо париться о времени прихода на работу, но с точки зрения работы и необходимых коммуникаций, я выше уже написал.

Не угадали про мое понимание. Хотя этот спор офттоп, и изначальный вопрос был про другое, но выскажу свое понимание гибкости. Это работа восемь часов в день плюс время на обед с обязательным нахождением в офисе с 12 до 18 или с 11 до 17. Если позиция настолько ответственная, то договариваетесь, чтобы сотрудник на обеде был доступен по мобильнику (хотя за десять лет я такого не встречал).

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

D>Хоть и не работодатель, но обсуждал этот вопрос с ними.
D>Необходимость регламентированного дня есть там, где кроме чисто разработки, приходится много контактировать с другими людьми, на производстве, с представителями заказчика, и т.д., чтобы, если возникает какой-то вопрос к программисту, не приходилось ждать, когда он появится на работе.

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

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

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

B>>

т.е. тупо 8 часов втыка в работу без отрыва (обед не считаем)? Герой.

UVV>Я где-то написал, что работаю "без отрыва"?
UVV>Я написал, что работаю 40 часов в неделю, а когда я это делаю — я решаю сам.
Ещё важный вопрос, сколько за это платят...

E>>Я специально написал, что не одновременно и нигде не писал что по одному проекту. Читаем внимательно, иначе диалога не получится

D>То есть, двадцать человек по разным вопросам и проектам, но именно с девяти до десяти и со всеми двадцатью? Тоже не верю.

Я теряю веру в свой дар изложения мыслей...Я разве написал, что с девяти до десяти? Я разве написал, что со всеми двадцатью в течение дня? Если мне с _любыми_ двумя (из этих 20-ти) 2-3 раза в неделю надо пересечься в заданном промежутке времени, без необходимости ожидания когда они появятся одновременно. Прошу, перечитайте сначала, и подумайте, иначе диалог уже не получается.

D>Не угадали про мое понимание. Хотя этот спор офттоп, и изначальный вопрос был про другое, но выскажу свое понимание гибкости. Это работа восемь часов в день плюс время на обед с обязательным нахождением в офисе с 12 до 18 или с 11 до 17. Если позиция настолько ответственная, то договариваетесь, чтобы сотрудник на обеде был доступен по мобильнику (хотя за десять лет я такого не встречал).

Ну все равно отличается от моего понимания. Для меня важна предсказуемость появления в офисе, а не только время нахождения в офисе. Оффтоп, ладно. По основному вопросу я уже написал, главное прочитать внимательно

E>>

D>Прямо таки многие? Я вот вижу обратную ситуацию. О ТК работодатель вспоминает, когда ему удобно.

У нас не многие, а вообще, если форум почитать — такое создается впечатление. Вы, похоже, очень обижены на работодателей

E>>Ну ладно, мы не наивные, мало кто реально работает 8 часов в день
D>Не хочу разбивать сердце или спровоцировать инфаркт, но: http://www.rsdn.ru/poll/1846.aspx

Эээ, либо Вы, по-прежнему, не читаете то, что я пишу, либо я не понял, о каком разбитии сердца речь

Читаем строку выше.

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

UVV>Я где-то написал, что работаю "без отрыва"?
UVV>Я написал, что работаю 40 часов в неделю, а когда я это делаю — я решаю сам.
а объем выполненной работы влияет на размер выплачеваемой вам суммы?

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

D>>Прямо таки многие? Я вот вижу обратную ситуацию. О ТК работодатель вспоминает, когда ему удобно.
E>У нас не многие, а вообще, если форум почитать — такое создается впечатление. Вы, похоже, очень обижены на работодателей

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

E>>>Ну ладно, мы не наивные, мало кто реально работает 8 часов в день
D>>Не хочу разбивать сердце или спровоцировать инфаркт, но: http://www.rsdn.ru/poll/1846.aspx

E>Эээ, либо Вы, по-прежнему, не читаете то, что я пишу, либо я не понял, о каком разбитии сердца речь

E>Читаем строку выше.

Строка выше, как кажется после прочтения, все-таки предполагает, что речь идет о том, что большинство работает меньше восьми часов, но не настолько. Проще говоря, фраза "менее 100%" нормальным человеком воспримется как "80-99%", но не как "50%". Хотя если представить, что участники обсуждения математические автоматы, то да, даже 1% менее 100%.

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

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

8>Я и говорю что есть много нюансов, но есть и методики которые помогают их решить.
8>Например Вы ведь сможете понять что человек бьет баклуши, хоть и честно находится на
8>рабочем месте по 8 часов в день?

Смогу. Но вот понять работает человек на 50% своих возможностей или на 100 уже не так просто.

G>>так что проще чтобы все работали по 8 часов в день и все.

8>Дык не работают. Я работал по схеме 40 в неделю, частенько видел людей которые по 1-2 часа в день,
8>просто сидят и ничего не делают, но уйти не могут ибо часы. Только мучают себя, что не прибавляет эффективности.

Да есть подобные минусы. Но минусы перечисленные выше выглядят похуже, не так ли?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

IID>А если нашли в 20 вечера, а человек ушёл 2 часа назад ? В чём отличие, не пойму

...

Отличие в том, что сидеть по 24 часа народ не заставишь. Но хотя бы в течении рабочего дня — вполне можно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

L>Если этот человек в отпуске/заболел/ушел в монастырь, будете делать всей компанией харакири?

Это отдельные ситуации которые предусмотрены отдельными процессами.

L>Кстати, всего тысячи долларов в минуту? Дай угадаю, CD-эректор пишете?

Ха-ха. Смешно.

L>А если серьезно, то налицо некомпетентность менеджмента. Для систем, ушедших в продакшен, где простой грозит многомиллионными убытками, вендор должен обеспечивать все три уровня техподдержки. Включая специально обученных инженеров и программистов техподдержки, заточенных на поиск багов и уполномоченных их фиксить, работающих посменно и доступных по телефону 24/7.

Как же я люблю эти диагнозы выслушивать.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

A>Значит клиент потеряет много денег.
A>Вообще-то прежде, чем что-то отдавать клиенту неплохо бы протестировать программу. Соответственно подобная ситуацию станет маловероятной.

Ага

A>А представим, что человек пришёл ровно в 10, как и положено. Это значит, что он в 11 должен сразуже с голой грудью бросаться на исправление бага. Причём исправить надо быстро. Минута простоя — тысячи долларов. Баг оказался не очень сложным. На исправление ушёл час. Решение сырова-то. Неплохо бы проверить. А есть ли на это время? Проверка (программистом) займёт ещё час. Потом нужно тесты погонять, затем тестеры посмотрят, что функция работает, и больше ничего не отвалилось. Т.е. получается 2 альтернативы:
A>а) Сделать по хорошему. Это может занять от нескольких часов до пары дней.
A>В этом случае вероятность новых багов низкая, но заказчик теряет какую-то немыслимую сумму денег.
A>б) Побыстрому дать, что получилось. В этом случае заказчик потеряет много денег, но в разумных пределах. Но есть опасность, что новая версия содержит ещё более критичный баг.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

D>Вам, похоже, очень так хотелось бы.

Не похоже, по-моему

D>Я пытаюсь понять некоторые действия работодателей, реально ли их поведение может помочь в бизнесе, или это просто самодурство и еще одно средство давления.

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

D>Строка выше, как кажется после прочтения, все-таки предполагает, что речь идет о том, что большинство работает меньше восьми часов, но не настолько. Проще говоря, фраза "менее 100%" нормальным человеком воспримется как "80-99%", но не как "50%". Хотя если представить, что участники обсуждения математические автоматы, то да, даже 1% менее 100%.

Строка выше гласит "мало кто реально работает 8 часов в день", как можно подумать что "мало кто" это "менее 100%, то есть 80-99%" — я не понимаю. "Мало кто" это как раз от 0% заход. Разве нет?

D>Изъясняетесь действительно сложновато. Как и в случае с общением с двадцатью людьми, у вас какие-то радикальные взгляды на гибкий график.
Большинство участников обсуждения понимают под этим значением необходимость присутствия в офисе всех сотрудников не менее пяти-шести часов в день. Из ваших ответов можно представить, что с гибким графиком половина чуть ли не ночью будет приходить.

Не понимаю, чего радикального в моих взглядах на гибкий график. Приходить в предсказуемое, но удобное сотруднику время, в пределах разумного (+/- 1 час) отклонения от нормы, причем, в случае необходимости, оповестив об этом, можно прийти и в другое время.
Необходимость присутствия в офисе, любые нормальные сотрудники понимают как 8 часов в день, припоминая то, что мы тут ТК вспоминали недавно

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

Я рассматривал простой юз-кейс. Прихожу в 11 и ожидаю, что все сотрудники на месте, ибо гибкий график в плане прихода — в диапазоне от 9 до 11, не считая случаев форсмажора. То есть моя мечта, чтобы уж в 11-то, все кто решил ходить к 11 на работу будут на месте, а не будут сползать к 11:15, 11:30, 12 и т.д. потому что "проспал", "пробки" и т.п.

D>>>Просьба ответить работодателям.
E>>В общем, как-то так.
K>ИМХО, ты путаешь дисциплину и свободный график.

Имхо это не я путаю дисциплину и свободный график

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

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

E>Ну я свои мысли по теме написал, кажется даже некоторые коллеги согласны.

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

E>Строка выше гласит "мало кто реально работает 8 часов в день", как можно подумать что "мало кто" это "менее 100%, то есть 80-99%" — я не понимаю. "Мало кто" это как раз от 0% заход. Разве нет?

В том контексте мне показалось именно так, как я написал.

E>Не понимаю, чего радикального в моих взглядах на гибкий график. Приходить в предсказуемое, но удобное сотруднику время, в пределах разумного (+/- 1 час) отклонения от нормы, причем, в случае необходимости, оповестив об этом, можно прийти и в другое время.
E>Необходимость присутствия в офисе, любые нормальные сотрудники понимают как 8 часов в день, припоминая то, что мы тут ТК вспоминали недавно

Видимо, теперь моя очередь намекать на невнимательность при прочтении

Во фразе "необходимость присутствия в офисе всех сотрудников не менее пяти-шести часов в день" ключевое слово "всех", то есть любой сотрудник в это время должен быть доступен. То, что каждый конкретный сотрудник обязан присутствовать восемь часов, или сколько прописано в договоре, плюс обед — это само собой разумеющееся. http://www.rsdn.ru/forum/job/3958799.1.aspx — тут я об этом прямо написал, когда зашла речь о моем понимании нестрогого графика.

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

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

B>>Наймите QA нормальных

G>Какие все тут умные люди собрались. Никто никогда не ошибается и не багает, а уже если багает, то тестеры гарантированно вылавливают все баги и все фиксится идеально.
G>Завидую вам, коллеги.

Никто об этом не говорит. Но фиксить баги ночью — это перебор.

Здравствуйте, k.o., Вы писали:
KO>Бардак, одним словом. Первое, что приходит в голову, прокладка локальной сети, потом можете провести интернет и завести себе почту на том же gmail'е, сразу пропадёт необходимость лично относить изменённые версии тестерам и начальнику и можно будет консультироваться с начальником и пинать тестера, даже когда их нет на рабочем месте (до чего техника дошла!). Ну и дальше там уже по мелочи: VCS, issue-tracker, wiki, и т.д.
вот приходит письмо тестеру. он его когда прочтет? когда чай попьет, когда башорг почитает, когда сходит покурит, когда прочитает еше 5 писем пришедших ему, когда походит поищет по офису что-то..
когда он его прочтет, он насколько быстро примется за задачу? а кто его знает? может у него другие задачи скопились и он их захочет сделать сначала? но сначала он еще раз чай попьет, потом пообедать сходит, потом обсудит в коридое что-то с кем-то
а когда ты пришел и на месте ему тут же дал все в руки и сказал — это надо сделать сейчас, он тебе дал свое согласие, назвал сроки и тут же приступил, ты тогда можешь расчитывать на определенный результат.

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

G>>Какие все тут умные люди собрались. Никто никогда не ошибается и не багает, а уже если багает, то тестеры гарантированно вылавливают все баги и все фиксится идеально.
G>>Завидую вам, коллеги.

B>Никто об этом не говорит. Но фиксить баги ночью — это перебор.

При чем тут ночью? Про это речи не было, перечитай ветку.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

K>Еще один плюс формального обозначения времени — это некоторый anchor, который заставляет людей помнить о том как "надо", и даже если они в него не укладываются, то они воспринимают это не как само собой разумеющееся, а как проявление к нему гибкости со стороны компании, соответственно он понимает что компания от него ждет того же.

на мой взгляд, сказанное выше больше похоже на желание начальника видеть это в своих подчиненных

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

__>Здравствуйте, k.o., Вы писали:
KO>>Бардак, одним словом. Первое, что приходит в голову, прокладка локальной сети, потом можете провести интернет и завести себе почту на том же gmail'е, сразу пропадёт необходимость лично относить изменённые версии тестерам и начальнику и можно будет консультироваться с начальником и пинать тестера, даже когда их нет на рабочем месте (до чего техника дошла!). Ну и дальше там уже по мелочи: VCS, issue-tracker, wiki, и т.д.
__>вот приходит письмо тестеру. он его когда прочтет? когда чай попьет, когда башорг почитает, когда сходит покурит, когда прочитает еше 5 писем пришедших ему, когда походит поищет по офису что-то..

Если у вас работать не начинают без ежеутреннего персонального пенделя, то это уже не бардак а, я даже не знаю как назвать (госконтора?

). Если же это особенность отношения к работе данного конкретного человека, то, не лучше-ли найти более адекватного сотрудника?

__>когда он его прочтет, он насколько быстро примется за задачу? а кто его знает? может у него другие задачи скопились и он их захочет сделать сначала? но сначала он еще раз чай попьет, потом пообедать сходит, потом обсудит в коридое что-то с кем-то

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

__>а когда ты пришел и на месте ему тут же дал все в руки и сказал — это надо сделать сейчас, он тебе дал свое согласие, назвал сроки и тут же приступил, ты тогда можешь расчитывать на определенный результат.

В общем, ты только усиливаешь моё мнение о творящемся у вас бардаке.

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

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

G>>>Какие все тут умные люди собрались. Никто никогда не ошибается и не багает, а уже если багает, то тестеры гарантированно вылавливают все баги и все фиксится идеально.
G>>>Завидую вам, коллеги.

B>>Никто об этом не говорит. Но фиксить баги ночью — это перебор.

G>При чем тут ночью? Про это речи не было, перечитай ветку.

Перечитай пост, на который ты отвечаешь.
Речь о том, что фиксить баги в нерабочее время — это не правильно. И нет разницы 3 ночи это или 8 утра.
Никто не утверждает, что критикалов не делает, но нужно хоть какой-то контроль иметь, а не выкатывать на прод перед уходом с работы свеженький билд хотя бы без regression тестирования.

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

L>>Если этот человек в отпуске/заболел/ушел в монастырь, будете делать всей компанией харакири?
G>Это отдельные ситуации которые предусмотрены отдельными процессами.

Неужели и ножи специальные закупили?

L>>Кстати, всего тысячи долларов в минуту? Дай угадаю, CD-эректор пишете?

G>Ха-ха. Смешно.

Обхохочешься!

L>>А если серьезно, то налицо некомпетентность менеджмента. Для систем, ушедших в продакшен, где простой грозит многомиллионными убытками, вендор должен обеспечивать все три уровня техподдержки. Включая специально обученных инженеров и программистов техподдержки, заточенных на поиск багов и уполномоченных их фиксить, работающих посменно и доступных по телефону 24/7.

G>Как же я люблю эти диагнозы выслушивать.

G>Одно другому совершенно не мешает. Все зависит от огромного количества факторов. И бывает, что, да, нужны три уровня поддержки итд.

Всякое бывает, да.

G>А бывает, что самый простой и дешевый способ — это чтобы все приходили на работу вовремя.

Только не надо тогда сказки придумывать про тысячи неустойки за минуту простоя. А то у Вас неувязочка в показаниях получается — что будет, если бага у клиента вылезет в 2:38 ночи?

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

B>Перечитай пост, на который ты отвечаешь.
B>Речь о том, что фиксить баги в нерабочее время — это не правильно. И нет разницы 3 ночи это или 8 утра.
B>Никто не утверждает, что критикалов не делает, но нужно хоть какой-то контроль иметь, а не выкатывать на прод перед уходом с работы свеженький билд хотя бы без regression тестирования.

конкретно в этой ветке я отвечал на это

По сути: фиксить баги в нерабочее время неправильно. Это факт. ДЛя этого есть рабочие процессы. Один из которых (это нужно отнюдь не всегда, но бывает что нужно, а в среднем случае средней программерской конторы как минимум не вредит) это детерменированность рабочего времени.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>А бывает, что самый простой и дешевый способ — это чтобы все приходили на работу вовремя.

L>Только не надо тогда сказки придумывать про тысячи неустойки за минуту простоя. А то у Вас неувязочка в показаниях получается — что будет, если бага у клиента вылезет в 2:38 ночи?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

KO>Порядок выполнения задач, обычно, определяется приоритетом выставленным в соответсвующем тикете. Если с этим есть проблемы, то это один из верных признаков бардака и неэффективного использования ресурсов.

Ага. 10 тикетов High 10 Normal, что делать будем?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Ага. 10 тикетов High 10 Normal, что делать будем?

KO>Очевидно, все тикеты с одинаковым приоритетом равноправны и могут исправляться в любом порядке, который устраивает того, кто над ними работает. Ты как-нибудь более внятно проблему сформулируй. Например: "10 тикетов High 10 Normal, но эти приоритеты нифига не соответствуют реальным, что делать будем?" Но ты ведь не это имел в виду?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

__>Здравствуйте, k.o., Вы писали:
KO>>В общем, ты только усиливаешь моё мнение о творящемся у вас бардаке.
__>бардак творится везде. он творился везде где только я работал. я не верю в компании без бардака. это пиар, когда некая компания рассказывает сказки о том, как у них все замечательно. 8 лет назад я начал работать в первом коллективе и много раз уже разочаровался в сказки о том, что бывают все такие правильные и просто суперотличные компании. не бывает их. бардак везде.

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

__>нельзя просто уволить людей и набрать "правильных". люди везде одинаковые работают.

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

__>есть даже такой старый опыт — взяли поток студентов и выделили оттуда две группы — 15% лучших и 15% худших и стали соревновать их друг с другом, так вот в 1ой группе появлись раздолбаи, а во второй возникли таланты. любая группа людей самоорганизуется аналогичным образом. в любой компании всегда будут работать раздолбаи. и в любой компании организация работы примерно одинакова. сказки о радостной и счастливой жизни, об отборе лучших сотрудников — всегда голый пиар.

Опыт вобще не в тему. Всё-таки мотивация у студентов к учёбе и работающих людей к работе совершенно несопоставимые вещи.

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

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

G>>>Ага. 10 тикетов High 10 Normal, что делать будем?

KO>>Очевидно, все тикеты с одинаковым приоритетом равноправны и могут исправляться в любом порядке, который устраивает того, кто над ними работает. Ты как-нибудь более внятно проблему сформулируй. Например: "10 тикетов High 10 Normal, но эти приоритеты нифига не соответствуют реальным, что делать будем?" Но ты ведь не это имел в виду?

G>Могут конечно исправляться в том порядке который устраивает того, кто над ними работает. Но это в идеальном мире. А в реальном мире среди этих 10 high тикетов тоже нужно расставлять приоритеты.

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

И да, в реальном мире, нужно правильно расставлять приоритеты, реальный мир он такой.

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

Зачем десятки градаций?

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

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

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

И да, в реальном мире, нужно правильно расставлять приоритеты, реальный мир он такой.

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

KO>Зачем десятки градаций?

Нескольких штук более чем достаточно.

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

KO>Я, прежде всего, недоумевал зачем для этого нужно ловить Васю и давать ему волшебных пенделей, вместо того, чтобы написать письмо и/или повысить приоритет тикету.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

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

И да, в реальном мире, нужно правильно расставлять приоритеты, реальный мир он такой.

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

А зачем их столько?

Микроменеджментом увлекаемся?

KO>>Зачем десятки градаций?

Нескольких штук более чем достаточно.

G>Ну вот двух оказалось недостаточно. И вообще как только среди тикетов одного ранга надо будет расставлять приоритеты захочется увеличить число приоритетов на 1. Эта проблема решается самыми разными способами, один из которых очень прост:
KO>>Впрочем метод "Вась, глянь мой тикет первым", тоже иногда удобен.

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

KO>>Я, прежде всего, недоумевал зачем для этого нужно ловить Васю и давать ему волшебных пенделей, вместо того, чтобы написать письмо и/или повысить приоритет тикету.

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

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

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

KO>А зачем их столько?

Микроменеджментом увлекаемся?

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, 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 решило бы эту проблему, на что мне пытались возразить, что только личное присутсвие разработчика возле тестера может заставить последнего начать работу.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, 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>Но, я почти не видел тех, кто хочет так работать...

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

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

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

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

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

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

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

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

15.09.2010 19:26, sharpcoder пишет:
>
> Сразу видно, что у вас огромный опыт организации команд и руковосдтва
> коллективами
Вот что прикалывает. Так это то, что ни один из "работодателей" не
называет своих успешных фирм.

Posted via RSDN NNTP Server 2.1 beta

14.09.2010 22:30, Armadilio пишет:
>
> PS Дикие понятия рашкованчиков о мотивации меня уже даже не забавляют.
Они пугают.

Posted via RSDN NNTP Server 2.1 beta

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

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

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

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

в "о жизни" luciferarh недавно приводил пример — за 4 дня работы над проектом по монтажу сетей в банке работяги получили по 8 тыщ, организатор — 600 тыщ

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

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

Если бы я тебе написал про увеличение time-to-market то на другой какой-нибудь диагноз бы нарвался, так что какая разница?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

Верно. Если они все на работе. А не в разнобой. Проблема-то именно в этом.
По сути совершенно все равно днем или ночью люди работают — лишь бы все одновременно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

Это вообще не список приоритетов

На практике оказывается, что достаточно трех приоритетов — низкий, средний, высокий. И возможность указать, что вот эта задача ровнее чем другие с таким же приоритетом.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

A>Значит приоритеты выставляются неверно. Не бывает такого, что все задачи срочные. Если я должен сегодня сделать 10 срочных задач по 5 часов каждая, то это значит, что мне нужно несколько помощников.

Ещё как бывает. КОгда есть договоренность по срокам выполнения — тогда, да, либо мало ресурсов либо еще что. Но обычно приоритет задачи не гарантирует времени выполнения задачи. И тогда конечно может быть очень много задач с высоким приоритетом.

A>И какая разница как я выберу из срочных задач более приоритетную. Если у меня есть срочные задачи — то я работаю. Выбираю их в произвольном порядке.

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

A>Что изменится, если придёт Вася, даст мне пенделей и скажет, что его задача более срочная? А потом придёт Петя и скажет, что его задача не менее срочная? Мне что в таких случаях сразу к директору бежать и просить его расставить приоритеты?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

G>Если бы я тебе написал про увеличение time-to-market то на другой какой-нибудь диагноз бы нарвался, так что какая разница?

разницу между latency и throughput не видишь? а она есть

V>Вот что прикалывает. Так это то, что ни один из "работодателей" не
V>называет своих успешных фирм.

sharpcoder называл. http://solutions.wss-consulting.ru/

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

V>Вот что прикалывает. Так это то, что ни один из "работодателей" не
V>называет своих успешных фирм.

а тебе слабо себе палец откусить?

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Если бы я тебе написал про увеличение time-to-market то на другой какой-нибудь диагноз бы нарвался, так что какая разница?

BZ>разницу между latency и throughput не видишь? а она есть

и где же она тут?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>>Если бы я тебе написал про увеличение time-to-market то на другой какой-нибудь диагноз бы нарвался, так что какая разница?

BZ>>разницу между latency и throughput не видишь? а она есть

G>и где же она тут?

исправление ошибки — это одна операция, здесь важна latency. создание продукта — это множество операций, здесь важен общий throughput

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

G>>>>Если бы я тебе написал про увеличение time-to-market то на другой какой-нибудь диагноз бы нарвался, так что какая разница?

BZ>исправление ошибки — это одна операция, здесь важна latency. создание продукта — это множество операций, здесь важен общий throughput

Однако исправление ошибок напрямую влияет на time-to-market. Наблюдение из реальной жизни: затраты на коммуникации между отделом разработки и отделом тестирования в случае ненормированного рабочего времени дают до 4-5 дней задержки на интервале в месяц. Это конечно худший случай, но вот такая вот реальная статистика из практики.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

16.09.2010 12:06, BulatZiganshin пишет:
>
> а тебе слабо себе палец откусить?
Да. Именно потому я и не пишу "на нашей успешной ...".
А ответившему мое персональное спасибо. Он вполне четко описал процесс
разработки на их конторе — это позволит тем, кому такой процесс
нравиться стараться к ним попасть, кому не нравиться вообще не слать
резюме и потом не плакаться здесь про "плохих" работодателей..

Posted via RSDN NNTP Server 2.1 beta

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

>> а тебе слабо себе палец откусить?
V>Да. Именно потому я и не пишу "на нашей успешной ...".

не понял, значит. на слабо ловятся только в твоём возрасте

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

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

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

G>Если бы я тебе написал про увеличение time-to-market то на другой какой-нибудь диагноз бы нарвался, так что какая разница?

Ну то есть ляпнул не подумав, да?

Кроме того, следить за time to market — это тоже задача менеджмента, а не тестеров с программистами.

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

BZ>а у программистов больше никаких дел нет?

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

BZ>и тестеры не умеют проверять ошибки по одной, им обязательно билд подавай?

Если это шоустоппер, то конечно. Например прога крэшится при старте — дальнейшее тестирование невозможно.

Лирическое отступление, чтобы избежать обвинений меня и моих коллег в криворукости — такое случается даже если на всех девелоперских машинах все работает идеально. Например проблема с серверной частью. Проблема с конфигурацией тестировочного окружения итд.

Причем если это объединить с вышеприведенным примером, то может оказаться, что на фикс этого шоустоппера ушло 5 рабочих минут — поправить какой-нибудь параметр на сервере. А в календарных днях ушло почти два рабочих дня.

BZ>у тебя просто однобокое представление о процессе разработки
естественно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

G>Это вообще не список приоритетов

Это простой шаблон по выбору приоритетов. 3-х приоритетов мало.
Важно, чтобы приоритеты не ставились от балды.

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

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

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

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

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

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

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

"Готовы делать" и "делают" это разные вещи. Некоторые могут сильно себя переоценивать, при этом работают они действительно лучше, чем остальые. Получается неприятно, что обещал выдать 10 тонн угля, а дал только 5. но другие при этом и 3 не всегда выдают.

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

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

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

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

Это стоит ещё дороже. Но это несколько ортогональные понятия: решить проблему тоже можно в разные сроки.

BZ>забыл добавить: чтобы понять разницу между фрилансерами и предпринимателем, достаточно посмотреть "криминальное чтиво"

Смотрел, но не помню, чтобы там прояснялась какие-то различия между фрилансерами и предпринимателями.

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

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

G>A как иначе платить за результат? Все хотят чтобы им платили за результат, но хоть кто-нибудь может предложить рабочую схему?

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

Если не устраивать, то нужно понять причину и подумать об увольнении.

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

L>>Кроме того, следить за time to market — это тоже задача менеджмента, а не тестеров с программистами.
G>Это именно что задача менеджмента. Который может решить эту задачу простейшим из доступных методов — нормированным рабочим временем.

Сегодня обязательно нашим менеджерам расскажу. А то они не знают.

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

E>>>Я теряю веру в свой дар изложения мыслей...Я разве написал, что с девяти до десяти? Я разве написал, что со всеми двадцатью в течение дня? Если мне с _любыми_ двумя (из этих 20-ти) 2-3 раза в неделю надо пересечься в заданном промежутке времени, без необходимости ожидания когда они появятся одновременно.

L>>Откройте уже для себя Гугль Календарь, что ли. Для начала.

E>Вы меня ничему новому и полезному не научите, мне этот диалог не интересен, спасибо за участие.

А мне вот очень интересен. А Вы, позвольте спросить, в какой должности работаете?

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

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

A>Речь не идёт о крайних случаях (лентяи/бездельники), есть просто люди, которые в отсутствие контроля начинают давать себе поблажки, и когда они на виду, то легче проконтролировать прогресс.

Так ведь свободный график это не отсутствие контроля. Просто контролируются несколько другие вещи.
Согласен, что не всем подойдёт.

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

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

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

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

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

BZ>>>исправление ошибки — это одна операция, здесь важна latency. создание продукта — это множество операций, здесь важен общий throughput

G>>Однако исправление ошибок напрямую влияет на time-to-market. Наблюдение из реальной жизни: затраты на коммуникации между отделом разработки и отделом тестирования в случае ненормированного рабочего времени дают до 4-5 дней задержки на интервале в месяц. Это конечно худший случай, но вот такая вот реальная статистика из практики.

A>но по твоей модели разработчик постоянно должен отвлекаться: то его на совещание неожиданно позовут, то кто-то пенделей для профилактики даст.

почему постоянно? я где-то говорил, что каждые 5 минут его дергают?
Да и на самом деле раз-другой в день (даже если это так часто случается)отвлечься не страшно.

A>Да, мне выгодно подойти к кому-то, отвлечь от работы, и сообщить, что моё задание самое-самое важное и сделать нужно побыстрее. Но производительность при это падает, человек отвлекается. Причём нет гарантии, что при выполнении моей работы его не отвлечёт кто-то другой.

A>В итоге простые задания, вроде переименования кнопки делаются на ура и быстро. А сложные долговременные изменения в архитектуре программы нормально вообще не производятся.

Это очень спорное утверждение, требующее доказательства. Если человека дергают каждые 5 минут — бесспорно это бардак. Но если раз в день, не вижу причин почему это сильно мешает работе.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Это вообще не список приоритетов

A>Это простой шаблон по выбору приоритетов. 3-х приоритетов мало.
A>Важно, чтобы приоритеты не ставились от балды.

3 приоритета это ровно столько, сколько реально способен освоить человек. Как показывает практика большинство клиентов и служб поддержки не способны мыслить большим количеством приоритетов. Иногда добавляется еще два — "суперсрочно" (ASAP ) и "вообще нафиг не надо "

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Это именно что задача менеджмента. Который может решить эту задачу простейшим из доступных методов — нормированным рабочим временем.

L>Сегодня обязательно нашим менеджерам расскажу. А то они не знают.

Не исключаю кстати такого варианта, что не знают. Уж очень устоявшееся в программерском комьюнити мнение, что программист птица вольная. А оказывается — пока не пнешь, не полетит

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

Чем-то мне это феминизм напоминает. "Право делать так как мы хотим дайте нам, а обязанности оставьте себе"

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

16.09.2010 21:46, alzt пишет:
>
> "Готовы делать" и "делают" это разные вещи. Некоторые могут сильно себя
> переоценивать, при этом работают они действительно лучше, чем остальые.
> Получается неприятно, что обещал выдать 10 тонн угля, а дал только 5. но
> другие при этом и 3 не всегда выдают.
Хорошо сказано. Но вот только как вы програмерский уголь меряете?

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, мыщъх, Вы писали:

М>у меня к счастью такого нет, т.к. мой код работает в такой среде, что там чисто архитектурно все воспроизводимо и без проблем сделать реплей по факту сбоя. правда поскольку это линь, то основной отладчик — printf

Хм, а вот таких штук, какие эти компании предлагают не используете?

http://www.totalviewtech.com/

http://www.allinea.com/

17.09.2010 12:10, genre пишет:
>
> Но многие утверждают, что мол "платите мне не за время присутствия, а за
> сделанные задачи", но предложить рабочей схемы никто не может.
Это ты про свои фантазии. Когда платят за время присутствия — это очень
хорошо. Жаль, что такие конторы не живут долго.

Posted via RSDN NNTP Server 2.1 beta

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

A>Я в своё время пытался внедрить схему с двумя приоритетами (но рук-во не оценило)

A>1) Must be — должно войти в релиз
A>2) Optional — войдёт в релиз, если будет свободное время

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

A>Нет смысла в 3х или даже 5ти приоритетах — если что-то должно войти, то не важно в каком порядке делать. Если есть свободное время на Optional — ну тут можно и обсудить, обычно свободного времени нет.

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

A>Очень часто путают Priority и Severity и пытаются с помощью приоритета (== порядок выполнения) оценивать важность (необходимость для кастомера) что неправильно.

Это да. Часто путают, но часто и нет смысла их различать.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

Какие мои фантазии? Предложи рабочую схему, как платить сдельно.

V>Когда платят за время присутствия — это очень
V>хорошо. Жаль, что такие конторы не живут долго.

Владеешь статистикой?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

17.09.2010 13:43, genre пишет:
>
>> > Но многие утверждают, что мол "платите мне не за время присутствия, а за
>> > сделанные задачи", но предложить рабочей схемы никто не может.
> V>Это ты про свои фантазии.
>
> Какие мои фантазии? Предложи рабочую схему, как платить сдельно.
Я такого тебе и не предлагаю. Я наоборот утверждаю что для программиста
плата за присутственные часы лучше.

>
>
> V>Когда платят за время присутствия — это очень
> V>хорошо. Жаль, что такие конторы не живут долго.
>
> Владеешь статистикой?
А причем тут статика, если ты ничего не продаешь, то за счет чего жить
будешь?

Posted via RSDN NNTP Server 2.1 beta

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

>>
>>
>> V>Когда платят за время присутствия — это очень
>> V>хорошо. Жаль, что такие конторы не живут долго.
>>
>> Владеешь статистикой?
V>А причем тут статика, если ты ничего не продаешь, то за счет чего жить
V>будешь?

Извини, я не поспеваю за твоей логикой. Где я говорил про ничего не продающие компании?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

M>Здравствуйте, мыщъх, Вы писали:

М>>у меня к счастью такого нет, т.к. мой код работает в такой среде, что там чисто архитектурно все воспроизводимо и без проблем сделать реплей по факту сбоя. правда поскольку это линь, то основной отладчик — printf

M>Хм, а вот таких штук, какие эти компании предлагают не используете?
нет, не использую. в принципе, отладочной печати вполне достаточно. ну еще можно в gdb загрузить и в случае крэша посмотреть стек вызовов.

G>Если говорить, про девелопмент то этого достаточно. Но поскольку еще есть и поддержка и багфиксинг, то обязательно нужен третий приоритет "все бросили и побежали фиксить бегом".

Вообще-то для этого у нас создают внеочередной релиз

G>Есть еще зависимости между задачами. Часто добавление еще одного-двух рангов приоритетов отлично решает задачу донесения до девелопера последовательности выполнения.

А зачем эта последовательность? Всё что должно быть сделано — должно быть сделано. У нас правда короткие итерации, в районе месяца.

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

G>>Если говорить, про девелопмент то этого достаточно. Но поскольку еще есть и поддержка и багфиксинг, то обязательно нужен третий приоритет "все бросили и побежали фиксить бегом".
A>Вообще-то для этого у нас создают внеочередной релиз

В смысле?

G>>Есть еще зависимости между задачами. Часто добавление еще одного-двух рангов приоритетов отлично решает задачу донесения до девелопера последовательности выполнения.
A>А зачем эта последовательность? Всё что должно быть сделано — должно быть сделано. У нас правда короткие итерации, в районе месяца.

Ну например бывают зависимости между задачами или между командами. Типа в этом месяце надо сделать 10 фич, но фичу А надо сделать первой чтобы соседняя команда начала свой девелопмент.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, мыщъх, Вы писали:

М>>>у меня к счастью такого нет, т.к. мой код работает в такой среде, что там чисто архитектурно все воспроизводимо и без проблем сделать реплей по факту сбоя. правда поскольку это линь, то основной отладчик — printf

M>>Хм, а вот таких штук, какие эти компании предлагают не используете?
М>нет, не использую. в принципе, отладочной печати вполне достаточно. ну еще можно в gdb загрузить и в случае крэша посмотреть стек вызовов.
Наверняка вас задолбали такими вопросами, но рискну спросить. В книге "отладка без исходных текстов" вы сказали, что отладочные средства под юниксом(в частности gdb) по-своему очень удобны даже в сравнении с виндовыми. Что случилось, мнение поменялось?)

И еще такой вопрос — как на ваш взгляд, VisualStudio 6 надежнее/ближе_к_стандартам/безглючнее чем, скажем, та же VisualStudio 2005? Или, если дело не(только) в этом, то почему вы предпочитаете шестерку? Вопрос конечно касается компилятора командной строки.

D>В моей реальности свободный или жесткий график -- это зависит от компании, а не от программиста. Может быть компании со свободным и компании с жестким графиком тяготеют к найму разных людей?

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

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

A>1) если у работника свободный график, то в 99% случаев (оставлю 1% на всякий случай) работодателя устраивает его производительность, самомотивация и самодисциплина.
A>2) если у работника нет свободного графика и он недоумевает, то в 90% случаев он себя переоценивает (10% приходится на работодателей, которым религиозные мотивы не позволяют разрешить свободный график).

A>Так что 9 из 10 утверждающих, как классно они бы работали при свободном графике, себя переоценивают.

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

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

G>Вопрос какие вещи надо контролировать.

Справляется ли человек со своей работой или нет. Чтобы оценить его работу у оценивающего должна быть не ниже квалификация.

A>>Сегодня я планирую поработать побольше, голова свежая, мыслей много, какую-то часть лучше сегодня доделать чем откладывать на завтра. Причём дома по серьёзному делать нечего, можно задержаться. А вот завтра как раз неплохо бы пораньше уйти с работы — есть какие-то дела.

G>Поэтому надо считать суммарное время за месяц. Тогда остается возможность сегодня уйти пораньше, а завтра компенсировать это.

В том то и дело, что в моём примере можно списать это на то, что сайт в тот момент завис.
Мотивация работать заменяется мотивацией нарабатывать часы.

G>Ну идеальной выглядит ситуация не когда все приходят одновременно, а когда время прихода сотрудника заранее известно. Например каждую пятницу сотрудник составляет себе расписание на неделю вперед и оно всем доступно.

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

Здравствуйте, мыщъх, Вы писали:

М>основной цикл разработки был выполнен без отладчика вообще (только с отладочной печатью). потом все-таки установил ms vs 6 и даже несколько раз запустил отладчик

Согласен с вами) Даже удивительно, насколько долго можно обходиться без отладчика при разработке. Особенно когда используемые средства изучены вдоль и поперек, и знаешь их характерные баги.

М>"оно работает" (с). с шестеркой я работаю давно, знаю как ставить максимально урезанный вариант на нетбук, знаю что она не хавает ресурсов, etc. короче полностью меня устраивает. а если все устраивает, то зачем переходить на что-то новое? тем более маркетоиды так и не объяснили (внятно) что поменялось в компиляторе за это время. и нужно ли оно мне?
Ну да, мне просто интересно было, стоит ли дауншифтнуться с 2005-й на шестерку... Обоснованных доводов привести не могу, но есть подозрение, что шестерка работает гораздо ближе к канонам, а баги задавлены на порядок лучше. Ну типа как если сравнивать 2000 винду и 2003.

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

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

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

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

Z_> Ну типа как если сравнивать 2000 винду и 2003.
в смысле сервер с рабочей станцией?

Здравствуйте, мыщъх, Вы писали:

Z_>> удивительно, насколько долго можно обходиться без отладчика при разработке.
М>зачем отладчик-то? очень даже просто без него обходится.
Ну а если какой-нибудь баг непонятный выскакивает? Без сообщений, судов и следствия программа выбрасывает ошибку и все? Какой первый рефлекс?) Ну хорошо, может даже не первый, но второй)

Z_>> стоит ли дауншифтнуться с 2005-й на шестерку...
М>не думаю. особенно если писать под вынь. в последних версиях есть поддержка новомодных фич. защита от переполнения появилась. да и много чего по мелочи.
Ну может быть и правда не стоит... С другой стороны, как можно полагаться на эти фичи — например на защиту от переполнения? Ее вообще-то вроде по-хорошему надо предусматривать самому.

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

Z_>> Ну типа как если сравнивать 2000 винду и 2003.
М>в смысле сервер с рабочей станцией?
В данном случае как программный продукт, выполняющий свои функции, безотносительно того, какие цели перед ним стоят — насколько качественно, т.е. полно и безглючно, он делает свою работу.

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

М>>зачем отладчик-то? очень даже просто без него обходится.
Z_>Ну а если какой-нибудь баг непонятный выскакивает?
выводим через отладочную печать значения всех интересующих нас переменых и курим

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

Здравствуйте, мыщъх, Вы писали:

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

М>>>зачем отладчик-то? очень даже просто без него обходится.
Z_>>Ну а если какой-нибудь баг непонятный выскакивает?
М>выводим через отладочную печать значения всех интересующих нас переменых и курим

А если мы не знаем в какой переменной может быть дело?

Z_>> Без сообщений, судов и следствия программа выбрасывает ошибку и все?
М>а это как? по последнему отладочному сообщению локализуем место ошибки. если надо уточнить где именно оно падает -- добавляем еще отладочной печати. отладчик требует как минимум воспроизведения ошибки. ну вот, допустим, мы пишем фаер. иногда (очень редко) фаер падает. почему падает неясно. может ошибка синхронизации, может какой-то хакер послал пакет сильно нестандартный. если у нас есть лог отладочной печати, то по нему можно сузить район поиска. а что вы будете делать с отладчиком?
Ну фактически получается этакий профилированный под задачу отладчик) В отладчике мы же тоже не на все смотрим, а только на то, что интересует. В данном случае мы просто запрашиваем всю интересующую информацию через отладочную печать. А лог — это просто как фича, в stand-alone-отладчике тоже можно задать сбор нужной информации. Хотя, конечно, я не спец, и с отладочной печатью не работал и по большому гамбургскому счету для меня само ее существование новость, так что со мной тут вообще-то не о чем разговаривать)

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

Z_>Здравствуйте, мыщъх, Вы писали:

М>>>>зачем отладчик-то? очень даже просто без него обходится.
Z_>>>Ну а если какой-нибудь баг непонятный выскакивает?
М>>выводим через отладочную печать значения всех интересующих нас переменых и курим

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

Z_>Ну фактически получается этакий профилированный под задачу отладчик)
отладочная печать не есть отладчик. отладчик это все же орудие пошагового исполнения программы.

Z_> Хотя, конечно, я не спец, и с отладочной печатью не работал и по большому
Z_> гамбургскому счету для меня само ее существование новость,
с этого и было нужно начинать

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

Здравствуйте, мыщъх, Вы писали:

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

М>когда знаешь как работать, то потребности в отладчике просто не возникает. и мысль установить его приходит очень не сразу.
На самом деле когда я сказал, что удивительно сколько времени можно обходиться без отладчика, я подразумевал, что раз без отладчика, то и совсем без всего, т.е. и без отладочной печати в том числе. Чтобы проверить на выполнение — GetLastError, чтобы посмотреть на содержимое текстового буфера(и даже числовой переменной после преобразования в текст) — MessageBox. На самом деле наверное я просто делаю вручную то, что позволяет автоматизировать отладочная печать, но за все сразу не ухватишься, поэтому приходится как-то расставлять приоритеты, чтобы они лучше соответствовали цели.

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

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

Z_>Но самое же интересное — в ментальном поиске бага. Когда пошагово трассируешь отладчиком, то просматриваешь физическое выполнение программы, а когда размышляешь над тем, из-за чего же такое может быть, то на удивление просветляющие ответы в голову приходят порой, особенно когда бьешься над багом недели три. А сама программа после этого кажется в тысячу раз проще, чем казалась до этого.

Вот те раз. Оказывается — думать лучше, чем не думать...

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

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

Z_>>Но самое же интересное — в ментальном поиске бага. Когда пошагово трассируешь отладчиком, то просматриваешь физическое выполнение программы, а когда размышляешь над тем, из-за чего же такое может быть, то на удивление просветляющие ответы в голову приходят порой, особенно когда бьешься над багом недели три. А сама программа после этого кажется в тысячу раз проще, чем казалась до этого.

K>Вот те раз. Оказывается — думать лучше, чем не думать...
А прогнать код под отладчиком и найти за 20 минут в чем именно косяк иногда проще, чем три недели думать. А следовательно, эффективней.

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

K>>Вот те раз. Оказывается — думать лучше, чем не думать...
Z_>А прогнать код под отладчиком и найти за 20 минут в чем именно косяк иногда проще, чем три недели думать. А следовательно, эффективней.

Не скрою — ошарашен.

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

GIV>Угу. Унас именно так.
GIV>1) обязательное присутствие с 12 до 17.
GIV>2) должен отработать Х*8 часов в месяц, где Х количество рабочих дней в этом месяце.

GIV>Кто не справился не получает премии

Т.е. можно отработать только один час в месяц и всего лишь не получить премии?

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

Z_>Здравствуйте, мыщъх, Вы писали:

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

Z_> Чтобы проверить на выполнение — GetLastError,

Z_> чтобы посмотреть на содержимое текстового буфера
Z_>(и даже числовой переменной после преобразования в текст)
Z_> MessageBox.
ужос. а printf не вариант? ну fprintf если нет желания создавать новую консоль в гуй.

Z_> особенно когда бьешься над багом недели три.
может, стоит смениить тактуку борьбы?

Здравствуйте, Vzhyk, Вы писали:
V>17.09.2010 14:22, genre пишет:
>>
>> Извини, я не поспеваю за твоей логикой. Где я говорил про ничего не
>> продающие компании?
V>Как бы тебя не обидеть... постараюсь.
V>Вот смотри.
V>Компания — получила деньги от инвестора.
V>Программисты отсиживают присутственные часы и получают за это деньги —
V>это расходы.
V>Продукта на выходе нет никакого, потому что программистам нет смысла его
V>делать.
V>Раз продукта нет, то продавать нечего.
V>Если ничего не продаете, то денег нет.
многие компании живут лишь вялым саппортом своих старых успешных продуктов

не буду показывать пальцем

Здравствуйте, мыщъх, Вы писали:

Z_>> чтобы посмотреть на содержимое текстового буфера
Z_>>(и даже числовой переменной после преобразования в текст)
Z_>> MessageBox.
М>ужос. а printf не вариант? ну fprintf если нет желания создавать новую консоль в гуй.
Не совсем понятно как совместить печать в командной строке с гуевой прогой.

Z_>> особенно когда бьешься над багом недели три.
М>может, стоит смениить тактуку борьбы?

Например?)

Здравствуйте, dZentle_man, Вы писали:
Z_>Не совсем понятно как совместить печать в командной строке с гуевой прогой.
очень часто гуеые приложения в дебаге запускают с консолью.
например, Qt в консоль пишет свои варнинги.

Z_>Не совсем понятно как совместить печать в командной строке с гуевой прогой.

stderr у X11-приложений обычно session-manager направляет в свой лог.

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

Z_>Здравствуйте, мыщъх, Вы писали:

Z_>>> чтобы посмотреть на содержимое текстового буфера
Z_>>>(и даже числовой переменной после преобразования в текст)
Z_>>> MessageBox.
М>>ужос. а printf не вариант? ну fprintf если нет желания создавать новую консоль в гуй.
Z_>Не совсем понятно как совместить печать в командной строке с гуевой прогой.

Я тебя умоляю

.

Сделать редирект отладочного вывода это не так сложно. Я как-то отладку j2me приложения делал через сеть, т.е. приложение по жпрс коннектилось к доморощенному отладочному серверу(время написания — 3 минуты), который и показывал всю отладочную инфу(делалось это потому, что труб много, а я один, и юзать для каждой ихний собственный отладочный тулкит, если он вообще есть, да пусть этим негры страдают).

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

__>Здравствуйте, dZentle_man, Вы писали:
Z_>>Не совсем понятно как совместить печать в командной строке с гуевой прогой.
__>очень часто гуеые приложения в дебаге запускают с консолью.
__>например, Qt в консоль пишет свои варнинги.

В жабе консоль вообще перехватывается IDE по умолчанию. Что не мешает настроить еще 10500 отладочных destinations при необходимости со своими блекджеками и шлюхами. Собственно, в любом не embedded приложении это реализуемо на чем угодно и как угодно.

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

М>>ужос. а printf не вариант? ну fprintf если нет желания создавать новую консоль в гуй.
Z_>Не совсем понятно как совместить печать в командной строке с гуевой прогой.

всего лишь собирать без -mwindows

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

Z_>>> чтобы посмотреть на содержимое текстового буфера
Z_>>>(и даже числовой переменной после преобразования в текст)
Z_>>> MessageBox.
М>>ужос. а printf не вариант? ну fprintf если нет желания создавать новую консоль в гуй.
Z_>Не совсем понятно как совместить печать в командной строке с гуевой прогой.
создать консоль и валить туда весь отладочный вывод

Z_>>> особенно когда бьешься над багом недели три.
М>>может, стоит смениить тактуку борьбы?

Z_>Например?)
зависит от бага. это же может быть и спонтанный крэш и утечки памяти... но три недели на баг это очень много.

Здравствуйте, мыщъх, Вы писали:

Z_>>>> чтобы посмотреть на содержимое текстового буфера
Z_>>>>(и даже числовой переменной после преобразования в текст)
Z_>>>> MessageBox.
М>>>ужос. а printf не вариант? ну fprintf если нет желания создавать новую консоль в гуй.
Z_>>Не совсем понятно как совместить печать в командной строке с гуевой прогой.
М>создать консоль и валить туда весь отладочный вывод
Ну вот это то и не особо понятно как сделать) Со временем да, станет ясно, а пока просто нет возможности изучать все и сразу. Нет, консольные приложения я конечно писал, с них собственно и начинал, но чтоб совместить гуевое приложение с консолью нужно иметь более-менее вменяемую теоретическую базу.

М>>>может, стоит смениить тактуку борьбы?

Z_>>Например?)
М>зависит от бага. это же может быть и спонтанный крэш и утечки памяти... но три недели на баг это очень много.
Ну и что конкретно можно предпринять?) На самом деле проблема-то в том, что я таким образом самообучаюсь. И далеко не на каждый баг у меня уходило столько времени. Такие случаи вообще исключительны, у меня было таких всего 3(ну может с половиной), и это при том что я до этого совсем не имел навыков в программировании. Абыдно, да, тратить столько времени, но что тут можно поделать... Время потраченное на поиск таких багов имхо с лихвой компенсируется подтянутыми попутно теоретическими и прикладными знаниями и навыками, после получения которых проект переходит на новый уровень качества и скорости написания. А так на средний баг уходит от минуты до полутора дней, в зависимости от сложности)

__kot2, Eugeny__, dilmah, BulatZiganshin,

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

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

__>например, среди программистов очень высокий процент наркоманов — почти в каждой конторе во многих отделах сидят люди которые регулярно чем-то ширяется по тихой грусти. как следствие — раздражжительность, апатия и асоциальность.
Ёй!
Шота как то не замечалось за всё время сколько работаю.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

М>>"оно работает" (с). с шестеркой я работаю давно, знаю как ставить максимально урезанный вариант на нетбук, знаю что она не хавает ресурсов, etc. короче полностью меня устраивает. а если все устраивает, то зачем переходить на что-то новое? тем более маркетоиды так и не объяснили (внятно) что поменялось в компиляторе за это время. и нужно ли оно мне?
Z_>Ну да, мне просто интересно было, стоит ли дауншифтнуться с 2005-й на шестерку...
ИМХО нет. На 2003 ещё можно, но только как на среду разработки со сторонним компилятором.

Z_>что шестерка работает гораздо ближе к канонам, а баги задавлены на порядок лучше.
В компиляторе VC6 багов море, насколько я помню.

Z_> Ну типа как если сравнивать 2000 винду и 2003.
2003 лучше ИМХО

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:
Z_>> Ну типа как если сравнивать 2000 винду и 2003.
CC>2003 лучше ИМХО

самая глючная студия начиная с 6ой — 2005ая — она у меня на пловине шаблонов грохалась, вылетать могла просто на пустом месте и если ее dll ок не было на конечном компе, то программа просто грохалась, а не сообщала что dllок студии не хватает. с другими студиями таких проблем отродясь не видел. ну разве что так же грохаются на компиляции некоторых шаблонов и интеллисенс в половине случаев во многих проектах по go to definition приводит меня к определению макроса _T

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

Z_>Спасибо за инфу конечно, но я не говорил что это невозможно

а мы и не говорили, что средний современный программер должен это уметь

я начинал во времена когда персоналок было всего с сотню на весь город. тогда я тщательно отлаживал программу на бумаге прежде чем нести её на компутер. с тех пор всё только ухудшалось

ps: многопоточные алгоритмы отладживать не доводилось?

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

Z_>>Спасибо за инфу конечно, но я не говорил что это невозможно
BZ>а мы и не говорили, что средний современный программер должен это уметь

Ну эт хорошо, средний — значит не совсем лох) Хотя дело не в том что я не хочу это уметь, а в том что конкретно сейчас на это нет времени. Надеюсь скоро время появится.

BZ>я начинал во времена когда персоналок было всего с сотню на весь город. тогда я тщательно отлаживал программу на бумаге прежде чем нести её на компутер. с тех пор всё только ухудшалось

Я начинал пользоваться(только пользоваться) кампутером с 98-й винды. После 2000-й все только ухудшалось)

BZ>ps: многопоточные алгоритмы отладживать не доводилось?

Нет, но все впереди) Думаю ко времени, когда джентльменский набор будет из 16-ти я до них доберусь во весь рост)

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

Z_>>Я начинал пользоваться(только пользоваться) кампутером с 98-й винды. После 2000-й все только ухудшалось)
__>отладка под 3ый, 95ый и 98ой виндовоз, очень часто сопровождалась полной перезагрузкой компа после запуска проги, когда можно было сходить и чаю налить, пока комп снова загружается. тот факт с 2000ого виндовоза можно действительно завершить сдохший процесс и повисшее приложение не весит весь комп целиком это был прямо гиганский прорыв того времени.

вообще-то начиная с os/2 и nt

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

__>Здравствуйте, dZentle_man, Вы писали:
Z_>>Я начинал пользоваться(только пользоваться) кампутером с 98-й винды. После 2000-й все только ухудшалось)
__>отладка под 3ый, 95ый и 98ой виндовоз, очень часто сопровождалась полной перезагрузкой компа после запуска проги, когда можно было сходить и чаю налить, пока комп снова загружается. тот факт с 2000ого виндовоза можно действительно завершить сдохший процесс и повисшее приложение не весит весь комп целиком это был прямо гиганский прорыв того времени.
Поэтому и был и есть смысл смириться с повысившейся требовательностью к ресурсам в 2000-й винде по сравнению с 90-ми.

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

__>отладка под 3ый, 95ый и 98ой виндовоз, очень часто сопровождалась полной перезагрузкой компа после запуска проги, когда можно было сходить и чаю налить, пока комп снова загружается. тот факт с 2000ого виндовоза можно действительно завершить сдохший процесс и повисшее приложение не весит весь комп целиком это был прямо гиганский прорыв того времени.
98 — W2k реально был офигенный скачок качества ОС
WXP откровенно запороли в начале, к SP3 сделали нормальную работу над ошибками.
Я пересел с W2k сразу на W2k3, который сразу вышел нормальный, так что весь начальный гемор с ХР прошёл мимо меня.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>98 — W2k реально был офигенный скачок качества ОС

Всего-то таки скрестив с горем пополам могучую бизнес ОС NT 4, но безалаберную в домашних развлекательных задачах — с таковой для дома для семьи" 98-й. Я переходил на 2000-ю именно с NT — "офигенного скачка" не особо заметил. На FAT, например, в личных задачах я вообще никогда не жил — не случилось.

И на самом деле вообще пропустил "сцепку" — "98-я + 2000-я", шагая "3.1" (как полноценный работоспособный и применимый в реальных задачах виндоус", "95" (как +/- полноценный 32-битный виндоус), NT4 (как полноценный профессионального применения виндоус), XP (как перекрывший все имеющиеся задачи включая дом-игры-мультимедию-дивайсы виндоус), и теперь вот Vista/Seven, на которые прямой переход все оттягивается, хотя зоопарк "дома пара XP + Unix + Linux + Vista на ноуте, на работе все остальное, включая MAC и — ура!!! — исключая 2000-ю и 98-ю"

уже ничуть не смущает.

Пересаживаясь туда-сюда с Мака на Винду ощущаю офигенный скачок маразма — угадайте где, ага!

— но "офигенного скачка качества" не помню уже давно. Последней "сильной разницей" была, наверное, "связка" Win95 / NT4 VAX VMS, но уже тогда стал иметься опыт и знание, что дало замечать родство третьего и второго.

С тех пор "компутер" ничего "офигенного" не принес.

CC>WXP откровенно запороли в начале, к SP3 сделали нормальную работу над ошибками.
CC>Я пересел с W2k сразу на W2k3, который сразу вышел нормальный, так что весь начальный гемор с ХР прошёл мимо меня.

А я никогда не любил "непосредственно сидеть" на серверных ОС.

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

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

TL>

Всего-то таки скрестив с горем пополам могучую бизнес ОС NT 4, но безалаберную в домашних развлекательных задачах — с таковой для дома для семьи" 98-й. Я переходил на 2000-ю именно с NT — "офигенного скачка" не особо заметил.
Ну мне переход NT4 -> NT5 (когда она ещё так называлась) уже был заметен качественный сдвиг.

TL>Пересаживаясь туда-сюда с Мака на Винду ощущаю офигенный скачок маразма — угадайте где, ага!

— но "офигенного скачка качества" не помню уже давно.
На маке? Ибо "жрите что дают", не?

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

CC>>WXP откровенно запороли в начале, к SP3 сделали нормальную работу над ошибками.
CC>>Я пересел с W2k сразу на W2k3, который сразу вышел нормальный, так что весь начальный гемор с ХР прошёл мимо меня.

TL>

А я никогда не любил "непосредственно сидеть" на серверных ОС.

В винде только серверные ОС работают как надо, без совершенно лишних "свистоперделок".
Работают шустро, на собственные нужды ресурсов оттягивают мало. После установки нуждаются в минимальном тюнинге "под себя". Отличаются повышенной "живучестью", как ни парадоксально: там где юзерская загаживалась и её начинало хомячить сервер жив до сих пор при таком же использовании (как рабочей станции). Ни один патч под сервер ничего не сломал, в отличие от юзерской винды: была проблема в своё время: патч на один и тот же critical bug на серверной винде не сломал ничего, а на юзерских после соответствующего патча перестали у всей конторы работать ряд прог. И т.д и т.п.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>Вопрос какие вещи надо контролировать.
A>Справляется ли человек со своей работой или нет. Чтобы оценить его работу у оценивающего должна быть не ниже квалификация.

Как только ты придумаешь простой и формальный критерий подобной оценки ты сделаешь работу менеджмента простой и удобной.
А пока есть только некое подобие, рабочие часы это одно из комплекса средств оценки производительности.

А пока есть нюансы. Вот есть два программиста, оба выполняют примерно одинаковый объем работы (по мнению менеджера), но один проводит на работе 5 часов, а второй 8. Внимание вопрос, кто из них справляется со своей работой, а кто нет?

G>>Поэтому надо считать суммарное время за месяц. Тогда остается возможность сегодня уйти пораньше, а завтра компенсировать это.
A>В том то и дело, что в моём примере можно списать это на то, что сайт в тот момент завис.

Сайт либо не должен виснуть, либо должен иметь возможность заполнения постфактум.

A>Мотивация работать заменяется мотивацией нарабатывать часы.

Не бывает такой абстрактной мотивации "хочу работать". А уж если учесть что на самом деле весьма мало людей могут похвастаться работой интересной им на 100%, то проблемы с мотивацией возникают процентов у 80 программистов. И что делать в такой ситуации? Ждать пока ему станет интересно или пусть отработает хотя бы часы?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

__>>например, среди программистов очень высокий процент наркоманов — почти в каждой конторе во многих отделах сидят люди которые регулярно чем-то ширяется по тихой грусти. как следствие — раздражжительность, апатия и асоциальность.
CC>Ёй!
CC>Шота как то не замечалось за всё время сколько работаю.

Я вот тоже не особо. Я уж подумал, что в каком-то друом мире живу и работаю. Максимум, что видел — пивко, Но чтобы ширялись

.
Да и где вы таких асоциалов-грустителей пачками находите? Я бы в контору, где не с кем поговорить, просто не пошел бы.

__>>да потому что ИТшники по сути замкнуты в себе — в мире компутера — в пустой хате с линуксом и котом. но люди без общения, без близкого человека, несчастливы.
__>> и как следствие, чтобы хотя бы кратковременно чувствовать себя счастливым, принимают наркоту. которая вызывает уже ну полный капец с личностью. и таких людей мнооого в ИТ.
CC>Ты явно в каком то другом IT работаешь.

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

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

__>отладка под 3ый, 95ый и 98ой виндовоз, очень часто сопровождалась полной перезагрузкой компа после запуска проги, когда можно было сходить и чаю налить, пока комп снова загружается. тот факт с 2000ого виндовоза можно действительно завершить сдохший процесс и повисшее приложение не весит весь комп целиком это был прямо гиганский прорыв того времени.

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

Зато 9х грузились феерически быстро. Если вооще грузились

20.09.2010 15:03, Donz пишет:

> Надо же какое глубокое знание психологии и забота о личной жизни коллектива.
> Сам придумал, сам верю?

Да, именно так и есть. Мы живём в свободной стране, имею право.

--
WBR,
Serge.

Posted via RSDN NNTP Server 2.1 beta

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

>> Надо же какое глубокое знание психологии и забота о личной жизни коллектива.
>> Сам придумал, сам верю?
H>Да, именно так и есть. Мы живём в свободной стране, имею право.

Отлично. Только зачем тему то засорять? И так больше половины ответов — флуд и оффтоп.

E>>А кто говорил про раз в полчаса-час? Даже если это раз в неделю надо, когда нужных людей нет — не удобно. Если в крайности бросаться — так можно и с вашим планированием всю эффективность перечеркнуть на корню

L>Если это надо раз в неделю, то должно быть запланировано. Чтобы в последний момент не выяснилось, что совещание по времени пересекается с визитом заказчиков или что ключевой человек в отпуске/роддоме/у стоматолога/на экзамене в автошколе.

Попытаюсь донести свою мысль еще раз, хотя просто не верю, что удастся.
Речь идет не о совещании как таковом, а о ситуациях, когда возникает вопрос, так или иначе, требующий короткой консультации с коллегами. И чем быстрее будет получен ответ — тем лучше для дела. Планировать ради вопроса на 5-10 минут отдельную встречу на следующий день или еще позже, вместо того, чтобы прямо сейчас решить вопросы, ответить заказчику или коллегам из другого отдела и двигаться дальше?

Поверьте, уважаемый, когда речь идет о реальном совещании с агендой из 10 пунктов, оно планируется. Речь идет о штатных коммуникациях внутри команды. Спросил, получил ответ, идешь дальше.

20.09.2010 15:26, Donz пишет:

>> > Надо же какое глубокое знание психологии и забота о личной жизни
> коллектива.
>> > Сам придумал, сам верю?
> H>Да, именно так и есть. Мы живём в свободной стране, имею право.
>
> Отлично. Только зачем тему то засорять? И так больше половины ответов —
> флуд и оффтоп.

Ну, вроде вопрос был к работодателям. Я и ответил, как работодатель.
Если кого обидел — извиняюсь.

--
WBR,
Serge.

Posted via RSDN NNTP Server 2.1 beta

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

Z_>>>>Я начинал пользоваться(только пользоваться) кампутером с 98-й винды. После 2000-й все только ухудшалось)
__>>>отладка под 3ый, 95ый и 98ой виндовоз, очень часто сопровождалась полной перезагрузкой компа после запуска проги, когда можно было сходить и чаю налить, пока комп снова загружается. тот факт с 2000ого виндовоза можно действительно завершить сдохший процесс и повисшее приложение не весит весь комп целиком это был прямо гиганский прорыв того времени.

BZ>>вообще-то начиная с os/2 и nt

__>ну да, но ни первая ни вторая большой популярности, по крайней мере среди моих знакмых не получила.

У нас в общаге у всех NT стояла в качестве основной. Иногда второй системой 9х для игр. Но для работы/учебы последняя не годилась из-за совершенно кошмарной стабильности, так что только для игрушек и использовалась, и то не всех — в ту же кваку и под NT бегали. А вот для Worms уже надо было перезагружаться.

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

H>Ну, вроде вопрос был к работодателям. Я и ответил, как работодатель.
H>Если кого обидел — извиняюсь.

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

20.09.2010 16:43, Eugeny__ пишет:

> H>Ну, вроде вопрос был к работодателям. Я и ответил, как работодатель.
> H>Если кого обидел — извиняюсь.
>
> Меня лично не обидел, а просто удивил. Какой свежести можно ждать от
> людей в 7-8 утра(это же когда встать-то нужно)?

Я ещё не до такой степени сошёл с ума

Начало рабочего дня у нас в
10, плюс/минус полчаса. Но не в 11-12 и не "когда захочется".

--
WBR,
Serge.

Posted via RSDN NNTP Server 2.1 beta

20.09.2010 15:58, Donz пишет:

> Это или прикол, или мания
> величия.
> Или это непонятные мечты, или тяжелая стадия синдрома бога.

Ну, я же никому не навязываю свою точку зрения. Попросили
прокомментировать зачем да почему — прокомментировал.

Вам в своей команде никто же не запрещает устанавливать те правила,
которые именно вам кажутся разумными и эффективными (покуда они,
конечно, не противоречат действующему законодательству).

--
WBR,
Serge.

Posted via RSDN NNTP Server 2.1 beta

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

H>Ну, я же никому не навязываю свою точку зрения. Попросили
H>прокомментировать зачем да почему — прокомментировал.

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

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

TL>>

Всего-то таки скрестив с горем пополам могучую бизнес ОС NT 4, но безалаберную в домашних развлекательных задачах — с таковой для дома для семьи" 98-й. Я переходил на 2000-ю именно с NT — "офигенного скачка" не особо заметил.
CC>Ну мне переход NT4 -> NT5 (когда она ещё так называлась) уже был заметен качественный сдвиг.

ничо особенного не заметил. книжки по API толще и круче стали.

Везде стал COM/DCOM, а потом приписали и COM+. Вроде как при переходе на новую файловую систему совместимость со старой терялась.

TL>>Пересаживаясь туда-сюда с Мака на Винду ощущаю офигенный скачок маразма — угадайте где, ага!

— но "офигенного скачка качества" не помню уже давно.
CC>На маке? Ибо "жрите что дают", не?

Сегодня перепрошивал маковские клавиатуры. Блютусные. Черным по белому написано: для завершения перепрошивки надо клаву "распарить", а потом "запарить" по-новой. "Распарить" — понты делов! Обратно спарить — хрен поймешь чо именно ему надо.

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

Хорошо хоть там внутрях не сильно покоцанная фря — консоль наше все!

CC>Я поюзал немного мак и понял что это категорически не для меня.

Та то вы не умеете их готовить!

CC>Я не могу в нём настроить всё как мне нужно, по причине того что настройка под себя там попросту не предусмотрена. Наружу торчит лишь куцый сабсет настроек.

Фигня вопрос: для тонких внутренних реально значимых настроек внутре реальная фря — причем это таки работает!

Хоть местами и "неоднозначно"...

CC>А в том виде как оно есть это как W7 со всеми включенными рюшками, которые больше раздражают чем помогают в работе, вот только выключить их нельзя никак.

Никогда не понимал товарищей, при пересадке на Вин ХП тут же выключающих все "визуальные плюшки".

Это я так... люди ж старались, делали...

CC>>>WXP откровенно запороли в начале, к SP3 сделали нормальную работу над ошибками.
CC>>>Я пересел с W2k сразу на W2k3, который сразу вышел нормальный, так что весь начальный гемор с ХР прошёл мимо меня.

TL>>

А я никогда не любил "непосредственно сидеть" на серверных ОС.

CC>В винде только серверные ОС работают как надо, без совершенно лишних "свистоперделок".

"Как кому надо"?

CC>Работают шустро, на собственные нужды ресурсов оттягивают мало. После установки нуждаются в минимальном тюнинге "под себя". Отличаются повышенной "живучестью", как ни парадоксально: там где юзерская загаживалась и её начинало хомячить сервер жив до сих пор при таком же использовании (как рабочей станции). Ни один патч под сервер ничего не сломал, в отличие от юзерской винды: была проблема в своё время: патч на один и тот же critical bug на серверной винде не сломал ничего, а на юзерских после соответствующего патча перестали у всей конторы работать ряд прог. И т.д и т.п.

Вместе с тем — проблемы с драйверами под широкий спектр "не шибко профессиональных" дивайсов от видеокарт и до юсб-драйвов. Что может быть проще юсб-диска?

Ну и вообще... для большинства "домашних" задач больше напоминает классическое "забивание гвоздей микроскопом". Но многим нравится — а я и не против.

Токо в своих я сразу пишу: "серверные версии виндов вы используете на свой страх и риск и поддержка — исключительно по отдельному запросу и за отдельную денежку!"

Ибо нефиг: начитаются на форумах и все становятся такие умные-умные, продвинутые-продвинутые!

А чуть что — "у меня ваша программа/дивайс/сервис не работает!"

Ну это я так, о своем, о женском...

имхо, начиная с NT4 — винда вполне достойная рабочая ОС.

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

H>>Ну, вроде вопрос был к работодателям. Я и ответил, как работодатель.
H>>Если кого обидел — извиняюсь.

E__>Меня лично не обидел, а просто удивил. Какой свежести можно ждать от людей в 7-8 утра(это же когда встать-то нужно)? Это нужно специально команду жаворонков набирать(впрочем, по-другому и не выйдет: я, если услышу про такой график на собеседовании, покручу у выска и занесу контору в черный список), иначе будет команда сонных овощей, потребляющих кофе тоннами, но работающих процентов на 10 от возможной производительности.

Хм... На загнивающем западе, конкретно в его европейской части, жизнь вообще начинается в 7 утра. Зато после работы в 4 ты уже свободен: можно с детями погулять, личную жизнь занять, просто солнце увидеть не в окно офиса.

TL>Хм... На загнивающем западе, конкретно в его европейской части, жизнь вообще начинается в 7 утра. Зато после работы в 4 ты уже свободен: можно с детями погулять, личную жизнь занять, просто солнце увидеть не в окно офиса.

Основная причина, думаю, в том, что очень многие страны расположены ближе к экватору. А это значит, что в 7-8 часов вечера у них гарантированно темно. В России же летом темнее часов в 11.

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

L>Возьмите армию как пример организации, где контроль возведен в абсолют. Сможете припомнить, чего такого армия (любая) создала за всю историю человечества? Да, может копать, может не копать. Но вот даже оружие для себя самой разработать не может.

возьмём общину хиппи как пример организации где свобода возведена в абсолют...

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

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

E>Вам бы поменьше пафосности и побольше уважения к собеседнику. Вы меня не знаете, а говорите тоном учителя. Я сам могу учить и уже это делал в свое время. С Вами сложно строить общение из-за этого. Вот Вы с одной стороны говорите, что совещание надо назначать, а с другой стороны, одобряете высказывание о том, что "за дисциплиной — в армию". Кто к Вам на совещание прийдет в назначенное время? Будете сидеть и ждать пока все будут подтягиваться? У меня не создалось впечатления, что нам с Вами есть что обсуждать.

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

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

L>>Ваше желание построить программистов в шеренгу и заставить маршировать на очередной митинг — типичный образчик микроменеджмента. То, что Вам с таким подходом в течение многих лет что-то удается делать, скорее всего, заслуга исключительно Вашей команды, ну плюс Ваша недоработка. Плохо заставляете.

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

Отнюдь. Вы о себе как менеджере и о своей команде рассказали гораздо больше, чем Вы думаете.

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

BZ>возьмём общину хиппи как пример организации где свобода возведена в абсолют...

Берите, пожалуйста. только зачем?

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

DB>Основная причина, думаю, в том, что очень многие страны расположены ближе к экватору. А это значит, что в 7-8 часов вечера у них гарантированно темно. В России же летом темнее часов в 11.

какой к черту экватор? у нас время сдвинуто! "декретное", летнее и так далее.
в штатах 7 утра — как у нас 9. ( 9 — как у нас 11. Я всегда ходил на работу к 9 и прекрасно высыпался. американцы, приехавшие в россию, мгновенно начинают ходить на работу к 11 по гоблинскому времени (то есть к 9 у нормальных людей)

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

E__>Меня лично не обидел, а просто удивил.
Tervetuloa Suomeen!

E__>иначе будет команда сонных овощей, потребляющих кофе тоннами, но работающих процентов на 10 от возможной производительности.
Как страшно жить

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

>> Не бывает такой абстрактной мотивации "хочу работать".
V>Да. Не везет вам с сотрудниками...

вы полагаете, что большинство наёмников просто тупо хотят работать?

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

CC>>Я не могу в нём настроить всё как мне нужно, по причине того что настройка под себя там попросту не предусмотрена. Наружу торчит лишь куцый сабсет настроек.

TL>Фигня вопрос: для тонких внутренних реально значимых настроек внутре реальная фря — причем это таки работает!

TL>Хоть местами и "неоднозначно"...

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

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

>> вы полагаете, что *большинство* наёмников просто тупо хотят работать?
V>Про наемников не знаю, дела не имел, а программисты обычно хотят,
V>главное, чтобы не "эффективные менеджеры" мешали.

Хотелось бы мне пожить в этом идеальном мире.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

CC>>А в том виде как оно есть это как W7 со всеми включенными рюшками, которые больше раздражают чем помогают в работе, вот только выключить их нельзя никак.

TL>Никогда не понимал товарищей, при пересадке на Вин ХП тут же выключающих все "визуальные плюшки".

Это я так... люди ж старались, делали...

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

А вот вистовые/семерошные понравились настолько, что я на работе сделал себе тему a-la Vista/Win7. Не, ну понятно, что дополнил еще другими свистелками, благо, компиз очень сильная штука.

Кстати, народ, первый раз смотря на мой овистевший гном, впадает в легкий подвисон: вроде как винда, но что-то определенно не так

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

CC>>Работают шустро, на собственные нужды ресурсов оттягивают мало. После установки нуждаются в минимальном тюнинге "под себя". Отличаются повышенной "живучестью", как ни парадоксально: там где юзерская загаживалась и её начинало хомячить сервер жив до сих пор при таком же использовании (как рабочей станции). Ни один патч под сервер ничего не сломал, в отличие от юзерской винды: была проблема в своё время: патч на один и тот же critical bug на серверной винде не сломал ничего, а на юзерских после соответствующего патча перестали у всей конторы работать ряд прог. И т.д и т.п.

TL>Вместе с тем — проблемы с драйверами под широкий спектр "не шибко профессиональных" дивайсов от видеокарт и до юсб-драйвов. Что может быть проще юсб-диска?

Ибо нефиг: начитаются на форумах и все становятся такие умные-умные, продвинутые-продвинутые!

А чуть что — "у меня ваша программа/дивайс/сервис не работает!"

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

TL>имхо, начиная с NT4 — винда вполне достойная рабочая ОС.

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

E__>>Меня лично не обидел, а просто удивил. Какой свежести можно ждать от людей в 7-8 утра(это же когда встать-то нужно)? Это нужно специально команду жаворонков набирать(впрочем, по-другому и не выйдет: я, если услышу про такой график на собеседовании, покручу у выска и занесу контору в черный список), иначе будет команда сонных овощей, потребляющих кофе тоннами, но работающих процентов на 10 от возможной производительности.

TL>Хм... На загнивающем западе, конкретно в его европейской части, жизнь вообще начинается в 7 утра. Зато после работы в 4 ты уже свободен: можно с детями погулять, личную жизнь занять, просто солнце увидеть не в окно офиса.

У всех? Абсолютно всех? А смысл?

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

Кстати, я полагаю, они уже часов в 9 спать тогда ложатся? Ну не, я ночь люблю, мне такое не подойдет

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

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

G>>>Ну не работает большинство людей без контроля.

L>>Возьмите армию как пример организации, где контроль возведен в абсолют. Сможете припомнить, чего такого армия (любая) создала за всю историю человечества? Да, может копать, может не копать. Но вот даже оружие для себя самой разработать не может.

G>Аналогия совершенно не верная. Армия выполняет совершенно другие задачи и со своими задачами в условиях тотального контроля справляется отлично. Вопрос смогла бы армия справляться со своими задачами без абсолютной дисциплины?

Понятия не имею, смогла бы или нет. Мне неинтересно. Что точно известно — армия годится только для разрушительной деятельности. Для чего нужна "дисциплина". Нужна ли она для более полезной, созидательной деятельности?

G>Кстати говоря, на тех предприятиях где создается оружие для этой самой армии (это же более творческая работа, правда) дисциплина тоже что надо.

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

G>>>Мне вообще было бы очень интересно, как по-твоему выглядит процесс контроля команды хотя бы в 10 человек.

L>>Контролировать команду не надо. Нужно контролировать процесс. А уж сам процесс может диктовать необходимость контроля команды или же отстутсвие оной необходимости.

G>Что значит контролировать процесс?

На любом тренинге по scrum доходчиво разъясняют.

L>>В последнее время я склонен думать, что когда речь идет о проектной работе, чем разработка ПО и является, то существует либо иллюзия контроля процесса в виде waterfall и к нему примкнувшим прадигм, являющимеся по сути завуалированными методами контроля сотрудников, либо структуры вроде scum, где контролируется именно процесс.

G>В scrum контролируется именно работа каждого конкретного сотрудника.

Кажется, одного из нас жестко дезимформировали по поводу scrum.

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

L>>Если Вам так интересно — на совещания, назначенные мной, приходят все, кто требуется и в строго означенное время и место.

E>Нет, мне не интересно. Я указал Вам на Вашу непоследовательность.

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

L>>Отнюдь. Вы о себе как менеджере и о своей команде рассказали гораздо больше, чем Вы думаете.

E>Мне, честное слово, абсолютно все равно, что Вы там нафантазировали. Всем, кому нужно, я уже все доказал

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

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

Каким таким магическим образом наличие менеджера исправляет архитектуру и дизайн гуя?

G>PS кстати, каждый второй опен-сорс проект сделан программистами без менеджеров. Как бы показательно.
Samba, например. Apache там. Очень показательно, в самом деле

21.09.2010 14:11, genre пишет:
>
> И еще сотни две людей просто приходящих на работу работать и получать
> зарплату, не потому что они фанатики, а потому что так уж получилось,
> что они это умеют делать и им за это неплохо платят. Кто-то из них
> получает удовольствие от процесса, кто-то не получает, разное бывает.
> И в среднем — они бы и рады делать то, что им интересно, да только 80%
> времени приходиться фиксить баги, разрабатывать формочки, заниматься
> прочей неинтересной рутиной и лишь 20% времени придумывать дизайн,
> архитектуру, решать сложные и интересные задачи.
> И вот получается, что 80% времени они занимаются не самыми интересными
> вещами.А мотивации это не добавляет ни разу. А соответственно и
> продуктивности.
> Вот и приходиться следить и контролировать.
И править баги, и править баги, и править баги, и править баги ...
Лучше, как менеджер посмотри на всю вашу разработку. Где баги в основном
появляются, почему. Возможно подошло время начать большой рефакторинг
продукта. Посоветуйся с разработчиками, выясни, почему багов много, что
по их мнению надо изменить. И т.д.
В общем стань менеджером, а не "эффективным русским манагером".

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

> PS кстати, каждый второй опен-сорс проект сделан программистами без
> менеджеров. Как бы показательно.
На это тебе уже ответили.

Posted via RSDN NNTP Server 2.1 beta

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

L>Понятия не имею, смогла бы или нет. Мне неинтересно. Что точно известно — армия годится только для разрушительной деятельности. Для чего нужна "дисциплина". Нужна ли она для более полезной, созидательной деятельности?

Это неверный логический переход. Из того что дисциплина пригодна для разрушения не следует, что она непригодна для созидания.

G>Что значит контролировать процесс?
L>На любом тренинге по scrum доходчиво разъясняют.

Ну то есть отвечать ты не хочешь?

L>Кажется, одного из нас жестко дезимформировали по поводу scrum.

На stand up митингах каждый программист рассказывает, что он сделал вчера и что собирается сделать сегодня. Что это как не контроль сотрудника?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>И править баги, и править баги, и править баги, и править баги ...

Это почему? Где я такое говорил?

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

Напомню суть: 80% коммерческой разработки это так или иначе рутина. 80% программистов не фанатики, а обычные люди делающие обычную не всегда интересную работу.
Поэтому их надо мотивировать, направлять и обязательно контролировать.
Есть что возразить?

V>Лучше, как менеджер посмотри на всю вашу разработку. Где баги в основном
V>появляются, почему. Возможно подошло время начать большой рефакторинг
V>продукта. Посоветуйся с разработчиками, выясни, почему багов много, что
V>по их мнению надо изменить. И т.д.

Я где-то писал что у нас это не так?

V>В общем стань менеджером, а не "эффективным русским манагером".

Спасибо за совет

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

E__>Меня лично не обидел, а просто удивил. Какой свежести можно ждать от людей в 7-8 утра(это же когда встать-то нужно)? Это нужно специально команду жаворонков набирать(впрочем, по-другому и не выйдет: я, если услышу про такой график на собеседовании, покручу у выска и занесу контору в черный список), иначе будет команда сонных овощей, потребляющих кофе тоннами, но работающих процентов на 10 от возможной производительности.

Трейдеры часто приходят на работу раньше 7.

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

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

L>Знаете, то, что Вы увлекаетесь микроменеджментом не по делу, было очевидно сразу. Доказывать было необязательно

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

Успокойтесь уже, Вы самый крутой менеджер и всем нужно у Вас учиться. Аминь!

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

TL>>Хм... На загнивающем западе, конкретно в его европейской части, жизнь вообще начинается в 7 утра. Зато после работы в 4 ты уже свободен: можно с детями погулять, личную жизнь занять, просто солнце увидеть не в окно офиса.

DB>Основная причина, думаю, в том, что очень многие страны расположены ближе к экватору. А это значит, что в 7-8 часов вечера у них гарантированно темно.

Особенно это применимо к Скандинавии. Я однажды оказался в офисе наших норвежских заказчиков ни много, ни мало в 6:30 утра (забыл перевести часы) и некоторые уже были на работе.

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

>>> Не бывает такой абстрактной мотивации "хочу работать".
V>>Да. Не везет вам с сотрудниками...

BZ>вы полагаете, что большинство наёмников просто тупо хотят работать?

По-умолчанию — нет, конечно. Но в том и состоит задача менеджера: сделать так, чтобы работник захотел. Очевидно, что либо выполнение работы должно приносить профит лично для него, либо невыполнение должно приносить антипрофит. Это древние как мир принципы. Разница в том, что при действии пряником работники, как правило, довольны, а под кнутом — не очень. Те, кто не понимает, какие это приносит последствия для бизнеса, зря пошли в менеджеры. Имеется ввиду, естественно, работа со специалистами.

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

TL>>>

Всего-то таки скрестив с горем пополам могучую бизнес ОС NT 4, но безалаберную в домашних развлекательных задачах — с таковой для дома для семьи" 98-й. Я переходил на 2000-ю именно с NT — "офигенного скачка" не особо заметил.
CC>>Ну мне переход NT4 -> NT5 (когда она ещё так называлась) уже был заметен качественный сдвиг.
TL>

ничо особенного не заметил. книжки по API толще и круче стали.

Какие то системные вещи стали эволюционно получше и удобнее. Я уже не упомню что именно там было.

CC>>Я поюзал немного мак и понял что это категорически не для меня.
TL>Та то вы не умеете их готовить!

Видимо да.

CC>>А в том виде как оно есть это как W7 со всеми включенными рюшками, которые больше раздражают чем помогают в работе, вот только выключить их нельзя никак.
TL>Никогда не понимал товарищей, при пересадке на Вин ХП тут же выключающих все "визуальные плюшки".

Это я так... люди ж старались, делали...

Windows classic theme наше всё!

TL>>>

А я никогда не любил "непосредственно сидеть" на серверных ОС.

CC>>В винде только серверные ОС работают как надо, без совершенно лишних "свистоперделок".
TL>"Как кому надо"?

Мне разумеется

TL>Вместе с тем — проблемы с драйверами под широкий спектр "не шибко профессиональных" дивайсов от видеокарт и до юсб-драйвов.
Честно говоря с 2003го года столкнулся только с дровами под сканер Mustek, в которые какой то дебил зашил FAIL если проверка версии винды сказала что это не WinXP.
Отломал проверку — всё запахало.
Ну так тут случай идиотизма производителя.

TL> Что может быть проще юсб-диска?

А что это за usb storage такой странный который требует дрова?

TL>Ну и вообще... для большинства "домашних" задач больше напоминает классическое "забивание гвоздей микроскопом".
У меня представление такое: на сервера — *nix, для работы — Windows Server, для юзеров, совсем ничего не понимающих в компах — WinXP/W7/Mac
Впрочем я как то сестре на старый комп поставил 2003ю, так она пахала пока не подох старый HDD. Что там только они всем семейством ни делали — инет через IE6, принесённые чёрти откуда флешки, игры для детей, сами дети комп осваивали. Нифига ей не сделалось.
Поставили новый веник и туда WinXP — и началось. Винда дохла в корчах и троянах за месяц-два.
Не так давно ставили туда W7, так вот под неё не завелись принтеры и сканер ибо дрова хоть и были под W7 но работать отказались по неизвестной причине.

TL>Токо в своих я сразу пишу: "серверные версии виндов вы используете на свой страх и риск и поддержка — исключительно по отдельному запросу и за отдельную денежку!"
Это ты зря.

TL>Ибо нефиг: начитаются на форумах и все становятся такие умные-умные, продвинутые-продвинутые!
и много ты таких "начитаных" встречал?

TL>А чуть что — "у меня ваша программа/дивайс/сервис не работает!"
Дык эта, руки ровнять надо значит.
В драйверах между серверной и юзерской виндой различий не сильно много и они локализованы в паре "областей".
И если не замороченный драйвер вдруг на сервере не пашет — что то там явно грязнохакнуто в стиле что "в юзерской винде такая то хрень всегда лежит по такому magic address". Т.е. не соблюдаются driver coding guidelines.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E__>У нас почему куча людей использует серверные мега супер энтерпрайз версии? Да потому что они стоят у нас ровно столько же, сколько десктопные, а именно чуть больше стоимости носителя. Думаю, мало кто покупал лицензионный сервер для того, чтобы сидеть под ним дома.
Мало кто и не-сервер покупает чтоб сидеть дома.
Просто если ОС сравнивать не по "сколько стоит" а при одинаковом паттерне использования (т.е. то, что используем есть во всех версиях ОС) какая из версий ОС ведёт себя наиболее стабильно и надёжно.
В таком сравнении серверные версии просто рвут юзерские.
Т.е. если взять сервер, убрать оттуда все серверные фичи (AD, DNS, IIS, HyperV, Failover Cluster и проч.), не добавлять ничего что есть в юзерской ОС но не было в сервере и поставить ценник как на юзерскую ОС — будет идеальная винда для home/work.
Вот примерно в таком контексте сервера дома народ и пользует. Т.е. всё, что образует дополнительную стоимость "сервера" никому нафиг не надо. А вот нормальная стабильность в отличие от — очень даже нужна.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E__>Какого хрена вообще на девелопере лежит задача дизайна гуя? Для этого есть дизайнеры и проектировщики интерфейса. Девелоперы, обычно, действительно крайне хреново делают гуй (например, мои тулзы для внутреннего использования выглядят как говно, а чаще всего и вообще просто консольные).

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

E__>>Меня лично не обидел, а просто удивил. Какой свежести можно ждать от людей в 7-8 утра(это же когда встать-то нужно)? Это нужно специально команду жаворонков набирать(впрочем, по-другому и не выйдет: я, если услышу про такой график на собеседовании, покручу у выска и занесу контору в черный список), иначе будет команда сонных овощей, потребляющих кофе тоннами, но работающих процентов на 10 от возможной производительности.

K>Трейдеры часто приходят на работу раньше 7.

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

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

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

L>>Понятия не имею, смогла бы или нет. Мне неинтересно. Что точно известно — армия годится только для разрушительной деятельности. Для чего нужна "дисциплина". Нужна ли она для более полезной, созидательной деятельности?

G>Это неверный логический переход. Из того что дисциплина пригодна для разрушения не следует, что она непригодна для созидания.

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

G>>Что значит контролировать процесс?
L>>На любом тренинге по scrum доходчиво разъясняют.
G>Ну то есть отвечать ты не хочешь?

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

L>>Кажется, одного из нас жестко дезимформировали по поводу scrum.

G>На stand up митингах каждый программист рассказывает, что он сделал вчера и что собирается сделать сегодня. Что это как не контроль сотрудника?

Наводящий вопрос — кто на этом митинге вообще присутствует и кому они это все рассказывают и зачем?

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

E__>>Какого хрена вообще на девелопере лежит задача дизайна гуя? Для этого есть дизайнеры и проектировщики интерфейса. Девелоперы, обычно, действительно крайне хреново делают гуй (например, мои тулзы для внутреннего использования выглядят как говно, а чаще всего и вообще просто консольные).

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

Уже криво. Захардкоженный дизайн, имеется ввиду. Программер не дожен ничего располагать. У него должно быть флоу, события внутри флоу, и переходы с одного на другой. И, собственно, движок(движки) интерфейса. Это может быть веб, флеш, гуевая форма, но рисует это все дизайнер/верстальщик, программер максимум прицепляет события к элементам интерфейса. Для веба движок уже готовый(браузер же), для гуевины придется писать нечто, автоматом преобразующее дизайн в собственно форму. Можно тупо встроить браузерный компонент и юхать хтмл, но есть и другие пути. Это позволяет менять интерфейс, скины, и прочее безболезненно, так как логика и отображение разделены настолько, насколько это возможно.

G>Ну и тут есть вот еще какой аспект. Если так как утверждал мой оппонент, дать программисту все делать самому и не контролировать, то и получится, что дизайном гуя занимаются все кому нипопадя. А вот наличие дизайнера, аналитика, тестера, архитектора итд, то есть грамотного разделения ролей — это и есть отличительный признак хорошего менеджмента.

Разделение задач — безусловно. Да и программисты, как правило, не горят желанием делать не свою работу. Я даже не буду пытаться нарисовать гуй — у меня только события, я их при необходимости и из консоли постестирую, с помощью скриптов. А где там те элементы управления реально будут располагаться, и как выглядеть, мне плевать. Это может меняться хоть 3 раза в день автообновлениями, но на мою часть оно не повлияет никак.

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

L>Задача менеджера — управлять, а не командовать. Доходит, к сожалению, не до всех.

+100. И при этом эффективность работы подчиненных всегда выше, чем у "командира" с витающим в небесах ЧСВ.

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

G>>На stand up митингах каждый программист рассказывает, что он сделал вчера и что собирается сделать сегодня. Что это как не контроль сотрудника?

L>Наводящий вопрос — кто на этом митинге вообще присутствует и кому они это все рассказывают и зачем?

*достает поп-корн

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Это неверный логический переход. Из того что дисциплина пригодна для разрушения не следует, что она непригодна для созидания.
L>Это логическая индукция. Некто выдал ничем не подкрепленное утверждение, что без дисциплины ничего сделать нельзя. Возводим дисциплину в абсолют, получаем армию. Которая по определению ничего создавать не может. Получается, что это как раз в условиях абсолютной дисциплины ничего сделать не выходит. Получаем противоречие, из чего следует, что этому некту следовало бы обосновать свое утверждение, а то некий конфликт получается.

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

G>>>Что значит контролировать процесс?
L>>>На любом тренинге по scrum доходчиво разъясняют.
G>>Ну то есть отвечать ты не хочешь?
L>Не хочу. Менеджерам и считающих себя таковыми вообще было бы полезно сходить на такой тренинг или хотя бы лекции в онлайне посмотреть. Мне банально лень и некогда все это сюда переписывать.

Мне больше нравится версия, что ответа ты не знаешь.
А если знаешь, но тебелень писать, то зачем ты пишешь всё остальное? Остальное значит не лень?

L>>>Кажется, одного из нас жестко дезимформировали по поводу scrum.

G>>На stand up митингах каждый программист рассказывает, что он сделал вчера и что собирается сделать сегодня. Что это как не контроль сотрудника?

L>Наводящий вопрос — кто на этом митинге вообще присутствует и кому они это все рассказывают и зачем?

scrum daily meeting :
# What have you done since yesterday?
# What are you planning to do today?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

L>>>Каким таким магическим образом наличие менеджера исправляет архитектуру и дизайн гуя?
G>>Например тем, что девелопер магически получает по рукам если гуя кривая.
L>Каким таким образом? Менеджер у нас — Гудини и проблемы юзабилити и баги в гуе видит как рентген в аэропорту?

Именно.

L>Кстати, я правильно понял, что по поводу архитектуры возражений нет?

Про архитектуру это ты сам придумал, в моем исходном сообщении про архитектуру ни слова нет.

L>Задача менеджера — управлять, а не командовать. Доходит, к сожалению, не до всех.

НАдоели мне твои лозунги. Громкие и бессмысленные, не подтвержденные фактами или хотя бы аргументами.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

E__>Уже криво. Захардкоженный дизайн, имеется ввиду.

Мне бы тоже хотелось жить в идеальном мире.
Ну а пока я в мире реальном, то бывает встречаются проги написанные, например, с использованием MFC и развивающиеся уже лет 5. И приходиться их саппортить и развивать. Дальше рассказывать?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

E__>>Уже криво. Захардкоженный дизайн, имеется ввиду.

G>Мне бы тоже хотелось жить в идеальном мире.
G>Ну а пока я в мире реальном, то бывает встречаются проги написанные, например, с использованием MFC и развивающиеся уже лет 5. И приходиться их саппортить и развивать. Дальше рассказывать?

Я стараюсь выбирать работу так, чтобы жить поближе к идеальному миру. И ведь получается же!

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

>> G>Речь шла про scrum daily meeting
>>
>> Все подобные системы, своды правил и прочие инструкции сделаны для
>> обезьян

H>Осторожнее со scrum, несчастный, жрецы Agile уже мастерят твою куклу,
H>чтобы проткнуть её иголками

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

E__>Я стараюсь выбирать работу так, чтобы жить поближе к идеальному миру. И ведь получается же!

ты же наверно и из рашки почти свалил?

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

E__>>Я стараюсь выбирать работу так, чтобы жить поближе к идеальному миру. И ведь получается же!

D>ты же наверно и из рашки почти свалил?

Я всю жизнь, как-бы, в Украине прожил. Так что даже не знаю, что ответить. Сваливать пока никуда не хочу.

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

E__>Я стараюсь выбирать работу так, чтобы жить поближе к идеальному миру. И ведь получается же!

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

Так что приходится иметь дело и с неидеальными программистами, и с неидеальными менеджерами, и с неидеальными технологиями, и с неидеальным дизайном.
Но мы как-то справляемся вроде

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

E__>Знаешь, у меня серьезное недоверие всем расписанным по полочкам, шагам и красиво иллюстрированным диаграммками систем управления людьми.

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

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

Все те правила которые по-твоему "для роботов" созданы в первую очередь чтобы отвечать на эти вопросы. Иначе придеться делать "незнамо что незнамо для чего".
Тебя ведь не смутит правило "раз в неделю собрать билд и отдать тестерам"? Оно не делает из людей роботов? А почему тогда "раз в день отчитаться о своей работе" тебя смущает? Одна из задач этих пресловутых ежедневных митингов это максимально быстро сообщить о проблемах (например о недооценке сроков) менеджеру. Что в этом такого уж плохого?

Ну и как-то всё очень общо у тебя получается. Правила — плохо.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Ну и как-то всё очень общо у тебя получается. Правила — плохо.

E__>Не правила плохо. Плохо, когда шаблонные правила пытаются бездумно применять где ни попадя и как не попадя. Правила должны быть. Но они должны быть составлены менеджером исходя кучи факторов: специфика задачи, бюджет, команда, да тысячи их. А когда берется кем-то написанная простыня с "супер-пупер технологией ХХХ", и минуя мозг внедрятеся в компании как Закон Божий — вот это беда.

Ну тут мы вроде пришли к согласию.
За одним пунктом. Очень часто лучше уж пусть бездумно внедряют "супер-пупер технологией ХХХ", чем вообще бардак. Технология худо-бедно проверена общественностью и в среднем будет работать лучше чем перманентный бардак.

E__>Контроль — не единственная схема мотивации.

Контроль это лишь косвенно схема мотивации. В первую очередь это именно контроль. Хороший менеджер должен в любой момент времени знать ответ на вопросы: где мы находимся сейчас, сколько сделано, сколько осталось, риски какие сработали/не сработали, какие остались , что получилось, что нет и почему, итд. Знать ответ на эти вопросы помогает именно система контроля.
Если контролировать редко — понимание происходящего у менеджера будет очень сильно запаздывать. Есть проекты где это не страшно, а есть где это очень плохо.
Слишком часто контролировать впрочем тоже бывает бессмысленно.

E__>Если сотрудник получает процент с каждого подпроекта, (но при этом не получает ничего за багфиксинг, и не может разрабатывать новое, пока есть баги), то контроль ему и нахрен не нужен. Сам будет делать, и с минимумом багов — это ему выгодно. Это очень грубо, но идея, думаю, понятна. Хотя такая схема в некоторых случаях не применима, но таких случаев, если вдуматься, не так много.

Лично я уверен в том, что эта схема крайне сложна в реализации. Что подтверждает обсуждение в соседней ветке. Например потому, что очень сложно объективно измерять вклад каждого в общее дело.

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

E__>>Контроль — не единственная схема мотивации.

G>Контроль это лишь косвенно схема мотивации. В первую очередь это именно контроль. Хороший менеджер должен в любой момент времени знать ответ на вопросы: где мы находимся сейчас, сколько сделано, сколько осталось, риски какие сработали/не сработали, какие остались , что получилось, что нет и почему, итд. Знать ответ на эти вопросы помогает именно система контроля.
G>Если контролировать редко — понимание происходящего у менеджера будет очень сильно запаздывать. Есть проекты где это не страшно, а есть где это очень плохо.
G>Слишком часто контролировать впрочем тоже бывает бессмысленно.

E__>>Если сотрудник получает процент с каждого подпроекта, (но при этом не получает ничего за багфиксинг, и не может разрабатывать новое, пока есть баги), то контроль ему и нахрен не нужен. Сам будет делать, и с минимумом багов — это ему выгодно. Это очень грубо, но идея, думаю, понятна. Хотя такая схема в некоторых случаях не применима, но таких случаев, если вдуматься, не так много.

G>Лично я уверен в том, что эта схема крайне сложна в реализации. Что подтверждает обсуждение в соседней ветке. Например потому, что очень сложно объективно измерять вклад каждого в общее дело.

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

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

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

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

G>Это неверная индукция. Переход от "Которая по определению ничего создавать не может" к "условиях абсолютной дисциплины ничего сделать не выходит" неверен. Вот если бы армия не могла ничего создать именно и только по причине абсолютной дисциплины, тогда он был бы верен.
G>Но армия ничего не создает по совершенно другим причинам.

Ну приведи пример другой организации с жесткой дисциплиной, что ли. А то на ум что-то ничего не приходит. Сделаем правильную индукцию.

G>Мне больше нравится версия, что ответа ты не знаешь.

Да ради бога, если нравится. Только можно в лужу сесть ненароком.

G>А если знаешь, но тебелень писать, то зачем ты пишешь всё остальное? Остальное значит не лень?

Потому что влезая в спор о scrum, некотором не помешало бы с предметом ознакомиться несколько более детально.

L>>>>Кажется, одного из нас жестко дезимформировали по поводу scrum.

G>>>На stand up митингах каждый программист рассказывает, что он сделал вчера и что собирается сделать сегодня. Что это как не контроль сотрудника?

L>>Наводящий вопрос — кто на этом митинге вообще присутствует и кому они это все рассказывают и зачем?

G>scrum daily meeting :
G># What have you done since yesterday?
G># What are you planning to do today?

Там еще одна очень интересная строчка есть

All are welcome, but only “pigs” may speak

Понять, что это означает и что из этого следует, предлагаю самостоятельно. Не флейма ради, а продолжения разговора для. Будет интересно, обещаю.

DB>Солнце в Вашингтоне заходит в семь летом и в пять — зимой, поэтому чтобы заставать светлое время суток, нужно уходить с работы в 4-5 часов вечера. Поэтому и график жизни там сдвинут.

Замечательная теория, возьму на вооружение. Правда, не имеет никакого отношения к реальности, там просто "так принято" и все тут.

TL>>Хм... На загнивающем западе, конкретно в его европейской части, жизнь вообще начинается в 7 утра. Зато после работы в 4 ты уже свободен: можно с детями погулять, личную жизнь занять, просто солнце увидеть не в окно офиса.

DB>Основная причина, думаю, в том, что очень многие страны расположены ближе к экватору. А это значит, что в 7-8 часов вечера у них гарантированно темно.

Слушай, ты бы на карту посмотрел или там глобус. Какой еще экватор в Европе? Начинать рабочий день рано — традиция и все.

MP>О, супер, наконец-то появились работодателе, которых интересует не только материальное состояние работников, но и их личная жизнь и половые проблемы. Вот это я понимаю "забота о сотрудниках". Скажите, входит ли временная самка в ваш relocation pack для иногородних?

А у вас не входит?! Скорей обнародуй имя этой отсталой конторы, внесем в черный список

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

Г>Например, в городе Москве приезд на работу к 9-00 или 10-00 обеспечиват работнику отличную возможность иметь регулярную жизнь в пробке или в давке в метро, что отрицательно сказывается на мироощущении. А в качестве бесплатного бонуса либо необходимость приезжать заранее, либо постоянный стрес от риска опоздать.

Ты сам-то пробовал к этому времени приезжать? Я на работу еду к 8-9 обычно, давки в метро, особенно если ехать к 8-ми вообще нет, зато есть куча свободного времени после работы.

TMU>Замечательная теория, возьму на вооружение. Правда, не имеет никакого отношения к реальности, там просто "так принято" и все тут.

Сложный вопрос. Я вот летом немного поработал в Саудовской Аравии, в 3-30 заканчивал работу, в 4 был отеле. Казалось бы, ещё куча времени позагорать возле бассейна, ан нет, через 2 часа свет только от фонарей. Если бы приезжал с работы часов в 6-7, то солнца бы вообще не видел.

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

E__>Завтра напишу здесь свои идеи по поводу модели разработки. Что-то подобное используется у нас, и весьма успешно. Кстати, я своему руководству не завидую, и ни в чем не обвиняю. У нас все весьма адекватны.

Ок

E__>Просто я хочу донести, что модель, когда разработчику самому выгодно работать, и работать хорошо, качественно выгоднее той, в которой в случае падения уровня контроля все начнут бить баклуши.

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

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

Угу.

E__>Вобщем, ждите новых серий, все будет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Ну тут мы вроде пришли к согласию.
G>>За одним пунктом. Очень часто лучше уж пусть бездумно внедряют "супер-пупер технологией ХХХ", чем вообще бардак. Технология худо-бедно проверена общественностью и в среднем будет работать лучше чем перманентный бардак.

E__>Для больших компаний — да. Там лучше дебилкуватый свод правил и тотальная бюрократия, чем неконтролируемый бардак. Но в небольших средах разработчиков, которым выгодно развивать компанию(в том числе и финансово, причем профит виден незамедлительно), чрезмерная бюрократизация и армейская дисциплина ни к чему, она наоборот все затормозит.

Чрезмерная — несомненное зло. Но хоть какая-то должна же быть.

E__>Слыхили байку про процесс покупки принтера в огромной корпорации и стартапе?

Нет

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

L>Потому что влезая в спор о scrum, некотором не помешало бы с предметом ознакомиться несколько более детально.

Я наблюдаю успешное его применение и сам применяю уже не первый год.

L>Понять, что это означает и что из этого следует, предлагаю самостоятельно. Не флейма ради, а продолжения разговора для. Будет интересно, обещаю.

Знаешь, дискуссия в стиле "сам подумай" мне не интересна. Либо у тебя есть аргументы, либо нет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

21.09.2010 15:10, genre пишет:
>
> Напомню суть: 80% коммерческой разработки это так или иначе рутина. 80%
> программистов не фанатики, а обычные люди делающие обычную не всегда
> интересную работу.
Да все просто 80% коммерческой разработки — это вовсе не рутина. И 80%
программистов фанатики — слишком специфическая работа. Это тебе не ямы
копать отсюда и до обеда.
> Поэтому их надо мотивировать, направлять и обязательно контролировать.
Ну и смесь, просто адская.
> Есть что возразить?
Уже возразил.

Posted via RSDN NNTP Server 2.1 beta

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

V>Да все просто 80% коммерческой разработки — это вовсе не рутина. И 80%
V>программистов фанатики — слишком специфическая работа. Это тебе не ямы
V>копать отсюда и до обеда.

Зайду издалека. Что для тебя рутина/не рутина и кого ты считаешь фанатиками/не фанатиками.

>> Поэтому их надо мотивировать, направлять и обязательно контролировать.
V>Ну и смесь, просто адская.

Вот это не возражение.

>> Есть что возразить?
V>Уже возразил.

Аргументированно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

22.09.2010 14:19, genre пишет:
>
> Аргументированно.
Ровно настолько, насколько и ты.
Будем продолжать троллить? И меряться толщиной?

Posted via RSDN NNTP Server 2.1 beta

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

KP>Здравствуйте, Гоги, Вы писали:

Г>>Например, в городе Москве приезд на работу к 9-00 или 10-00 обеспечиват работнику отличную возможность иметь регулярную жизнь в пробке или в давке в метро, что отрицательно сказывается на мироощущении. А в качестве бесплатного бонуса либо необходимость приезжать заранее, либо постоянный стрес от риска опоздать.

KP>Ты сам-то пробовал к этому времени приезжать? Я на работу еду к 8-9 обычно, давки в метро, особенно если ехать к 8-ми вообще нет, зато есть куча свободного времени после работы.

А если к 7 утра, то будет еще свободней, а времени вечером еще больше

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

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

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

Лезть во фрю приходится по простой причине: мак. Хочешь мак — лезешь во фрю и во все эти "никому ничего не гарантировали". А обратной совместимости они и правда никогда не придерживались — даже и не знаю, хорошо это или плохо.

С другой стороны, некоторое время можно было собрать (а сейчас разве нельзя?) приложение, работаещее из одного и того же пакета и на power pc, и на intel. Так что все таки иногда озабачиваются.

Еще раз: при необходимости именно мак выбора "линукс — не линукс" не стоит.

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

TL>>Хм... На загнивающем западе, конкретно в его европейской части, жизнь вообще начинается в 7 утра. Зато после работы в 4 ты уже свободен: можно с детями погулять, личную жизнь занять, просто солнце увидеть не в окно офиса.

E__>У всех? Абсолютно всех? А смысл?

В смысле "а смысл"?

E__>Ну и, я полагаю, с транпортом там все-таки получше будет. А то ведь поездка в набитом метро или стояние в пробках совсем не добавляют счастья в жизни, согласись.

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

Только я не понял связи между поездкой в транспорте и временем работы. Ну и да: наши страны — бывший СССР — впереди мира всего (за исключением, конечно, тех же слаборазвитых) по "незелености". В большинстве мест найти зеленый сквер, парк, и т.п. — причем чистый, ухоженный, незагаженный — в 10-20 минутах пешком от любого места работы или жизни не представляет труда. Не говоря уже о возможности передвижения, например, на велосипеде, и о развитости сети общественного транспорта (и самого транспорта, ага) в сравнении с нашими.

Так что отдохнуть как раз есть где.

В отличие от.

E__>Кстати, я полагаю, они уже часов в 9 спать тогда ложатся? Ну не, я ночь люблю, мне такое не подойдет

.

Да, в 9 жизнь реально вымирает. Ну, есть, конечно, места либо "более молодежные", либо "более курортные", либо "более урбанизированные" — но по Европе в основном именно так: в 9 уже спать. А чего еще делать-то в это время?

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

TL>>Токо в своих я сразу пишу: "серверные версии виндов вы используете на свой страх и риск и поддержка — исключительно по отдельному запросу и за отдельную денежку!"
CC>Это ты зря.

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

TL>>Ибо нефиг: начитаются на форумах и все становятся такие умные-умные, продвинутые-продвинутые!
CC>и много ты таких "начитаных" встречал?

Как минимум, достаточно. История примерно та же: "я читал(-а) что один товарищ поставил своей сестре вин2003 сервер вместо ХП и у нее после этого ни один вирус не завелся! (на компе, в смысле

) — так ты и мне поставь!" (к) Ответ один: "ставь" (к)

TL>>А чуть что — "у меня ваша программа/дивайс/сервис не работает!"
CC>Дык эта, руки ровнять надо значит.

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

Справедливости ради следует признать, что немцы тоже в мелких конторках этим активно страдают.

CC>В драйверах между серверной и юзерской виндой различий не сильно много и они локализованы в паре "областей".

Угу. Всего-то расширенный доступ к памяти и отсутствие прямой поддержки производителем драйвера именно как версии под серверную винду. А так ставить, конечно же, можно — все равно ж все типа бесплатно. Но я давно забил: после того, как приехав к родственникам меня сводили к знакомым родственников дабы я "посмотрел на комп который вдруг стал сильно шуметь"...

— я в этих вопросах начал забивать и на родственников. Точнее помочь могу — поставить-выбрать-настроить — но как только появляется "шаг вправо шаг влево" и "кум посоветовал мне это — как думаешь?" — так сразу же в сад. Ибо все равно себе дороже. Проверено.

CC>И если не замороченный драйвер вдруг на сервере не пашет — что то там явно грязнохакнуто в стиле что "в юзерской винде такая то хрень всегда лежит по такому magic address". Т.е. не соблюдаются driver coding guidelines.

Мне на это в основном класть — я тупо не хочу с этим заморачиваться. Зачем мне это? Если после установки серверной версии по совету "крутого младшего брата-кулхацкера" у них вдруг отпадает любимый сканер, фотик, и видеокамера, а с игрушками тоже непонятки какие творятся, потому как видяха тоже не совсем правильно стала — я посылаю в сад. Ибо нефиг.

К слову следует признать это в основном наша беда: это все от чрезмерной образованности.

Если немец или финн какой и поставит на свой комп линукс или сервер — он при этом знает, что делает. Наши — в 95-99% случаев таки нет. Ни до того, ни после того, ни во время, ни вообще.

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

E__>>Ну честно, не могу я серьезно себе представлять это. У вас там системы документооборота/багофичетрекера нету, что-ли? Зачем этот цирк по утрам?

G>Речь шла про scrum daily meeting

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

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

E__>Для больших компаний — да. Там лучше дебилкуватый свод правил и тотальная бюрократия, чем неконтролируемый бардак. Но в небольших средах разработчиков, которым выгодно развивать компанию(в том числе и финансово, причем профит виден незамедлительно), чрезмерная бюрократизация и армейская дисциплина ни к чему, она наоборот все затормозит. Слыхили байку про процесс покупки принтера в огромной корпорации и стартапе?

Покупка принтера — то фигня. Все равно она нас, простых разработчиков, в основном не касается. Гораздо интереснее в больших компаниях процесс "контроля непрерывного роста сотрудников".

Читай: ежегодные или 2 раза в год "апрувы продвижения по должностям и з.п."

"Что ты, Сидоров, сделал за эти полгода в плане своего продвижения и что планируешь сделать в следующие полгода?"

Йо! А работать и делать дело — этого уже недостаточно?

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

L>>>Сможете припомнить, чего такого армия (любая) создала за всю историю человечества?
O>>Дач понастроила немало

TMU>По крайней мере часть знаменитых римских дорог была построена римскими же легионерами

ссылку на достоверные источники?

22.09.2010 23:13, The Lex пишет:
>
> TMU>По крайней мере часть знаменитых римских дорог была построена
> римскими же легионерами
>
> ссылку на достоверные источники?
Святая вера "ТМУ Первого".

Posted via RSDN NNTP Server 2.1 beta

TMU>>По крайней мере часть знаменитых римских дорог была построена римскими же легионерами

TL>ссылку на достоверные источники?

Прошу прощения? А вы полагали, что все работы в Риме делали исключительно рабы? Насчет источника — постараюсь найти, просто как-то полагал общим местом то, что легионы времен принципата, а затем и домината, особенно находящиеся в удаленных провинциях, широко привлекались к строительству, в том числе дорожному.

>> TMU>По крайней мере часть знаменитых римских дорог была построена
>> римскими же легионерами
>>
>> ссылку на достоверные источники?
V>Святая вера "ТМУ Первого".

А ты, видимо, полагаешь, что все строительные работы в Римской империи выполнялись исключительно рабами?

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

TL>>>Хм... На загнивающем западе, конкретно в его европейской части, жизнь вообще начинается в 7 утра. Зато после работы в 4 ты уже свободен: можно с детями погулять, личную жизнь занять, просто солнце увидеть не в окно офиса.

E__>>У всех? Абсолютно всех? А смысл?

TL>

В смысле "а смысл"?

Если одни ездят к 7, другие к 9, третьи к 11, а четвертые к часу, то это сильно разгружает транспортную систему города по сравнению со случаем, когда все поголовно едут к 7. В Киеве, скажем, к 11 ездить откуда и куда угодно, на чем угодно в разы комфортнее(а если поверху, то и быстрее), чем к 8-9(когда едет большая часть). Я почему и спрашивал про транспорт. В принципе, если все ездят к 7, но при этом нет ни пробок, ни давки в транспорте, это не проблема. Но что-то это кажется мне малореальным.

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

E__>>Для больших компаний — да. Там лучше дебилкуватый свод правил и тотальная бюрократия, чем неконтролируемый бардак. Но в небольших средах разработчиков, которым выгодно развивать компанию(в том числе и финансово, причем профит виден незамедлительно), чрезмерная бюрократизация и армейская дисциплина ни к чему, она наоборот все затормозит. Слыхили байку про процесс покупки принтера в огромной корпорации и стартапе?

TL>Покупка принтера — то фигня. Все равно она нас, простых разработчиков, в основном не касается. Гораздо интереснее в больших компаниях процесс "контроля непрерывного роста сотрудников".

Читай: ежегодные или 2 раза в год "апрувы продвижения по должностям и з.п."

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

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

TL>Йо! А работать и делать дело — этого уже недостаточно?

И снова они неслись со всех ног, так что только ветер свистел у Алисы в ушах. Того и гляди сорвет с головы все волосы, подумалось Алисе.
— А ну, давай! — кричала Королева. — Еще быстрее!
И они помчались так быстро, что, казалось, скользили по воздуху, вовсе не касаясь земли ногами, пока, наконец, когда Алиса совсем уже выбилась из сил, они внезапно не остановились, и Алиса увидела, что сидит на земле и никак не может отдышаться.
Королева прислонила ее к дереву и сказала ласково:
— А теперь можешь немного отдохнуть!
Алиса в изумлении огляделась.
— Что это? — спросила она. — Мы так и остались под этим деревом! Неужели мы не стронулись с места ни на шаг?
— Ну, конечно, нет, — ответила Королева. — А ты чего хотела?
— У _нас_, — сказала Алиса, с трудом переводя дух, — когда долго бежишь со всех ног, непременно попадешь в другое место.
— Какая медлительная страна! — сказала Королева. — Ну, а _здесь_, знаешь ли, приходится бежать _со всех ног_, чтобы только остаться на том же месте! Если же хочешь попасть в другое место, тогда нужно бежать по меньшей мере вдвое быстрее!

Льюис Кэрролл, "Алиса в Зазеркалье"

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

E__>>Меня лично не обидел, а просто удивил.
DM>Tervetuloa Suomeen!

E__>>иначе будет команда сонных овощей, потребляющих кофе тоннами, но работающих процентов на 10 от возможной производительности.
DM>Как страшно жить

Вот мы и выяснили почему Финляндия по потреблению кофе впереди планеты всей.

23.09.2010 10:56, TMU_1 пишет:
>
> А ты, видимо, полагаешь, что все строительные работы в Римской империи
> выполнялись исключительно рабами?
А ты видимо полагаешь, что в Римской империи были только легионеры и рабы?

Posted via RSDN NNTP Server 2.1 beta

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

E__>Здравствуйте, The Lex, Вы писали:

TL>>>>Хм... На загнивающем западе, конкретно в его европейской части, жизнь вообще начинается в 7 утра. Зато после работы в 4 ты уже свободен: можно с детями погулять, личную жизнь занять, просто солнце увидеть не в окно офиса.

E__>>>У всех? Абсолютно всех? А смысл?

TL>>

В смысле "а смысл"?

E__>Если одни ездят к 7, другие к 9, третьи к 11, а четвертые к часу, то это сильно разгружает транспортную систему города по сравнению со случаем, когда все поголовно едут к 7. В Киеве, скажем, к 11 ездить откуда и куда угодно, на чем угодно в разы комфортнее(а если поверху, то и быстрее), чем к 8-9(когда едет большая часть). Я почему и спрашивал про транспорт. В принципе, если все ездят к 7, но при этом нет ни пробок, ни давки в транспорте, это не проблема. Но что-то это кажется мне малореальным.

А... Хм... Не знаю — никогда не задумывался.

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

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

L>>Потому что влезая в спор о scrum, некотором не помешало бы с предметом ознакомиться несколько более детально.

G>Я наблюдаю успешное его применение и сам применяю уже не первый год.

Ты знаешь, учитывая что у тебя то минуты простоя стоят тысячи долларов, то нет, я не удивлюсь, если ты завтра заявишь, что с Йеном Эстергардом в одной школе учился.

L>>Понять, что это означает и что из этого следует, предлагаю самостоятельно. Не флейма ради, а продолжения разговора для. Будет интересно, обещаю.

G>Знаешь, дискуссия в стиле "сам подумай" мне не интересна. Либо у тебя есть аргументы, либо нет.

Аргументы? Если я начну приводить аргументы, это будет избиением младенца. Учитывая, что ты не понимаешь сути и значения daily scrum, я предлагаю тебе для начала ознакомиться с предметом несколько более детально.

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

Попробую рассмотреть сей вопрос с колокольни нашего проекта. Наша группа контачит напрямую с заказчиком. Между нами 10 часов разбежки.

E>2. Приходят пара сотрудников, сначала к 10, потом начинают приходить к 10:20, потом к 10:45, потом в 11:15. Сначала раз в две недели, потом два раза в неделю, потом 3 дня из 5. Глядя на них, остальные тоже начинают позволять себе вольности. Через несколько месяцев получаем отдел разработки, где все приходят когда хотят, уходят когда хотят и ходят на обед когда хотят. Хочешь собрать совещание с 3 участниками, и см. пункт 1. Окей, думаете вы, а почему бы не запланировать совещание заранее? На 10 не запланируешь — некоторые приходят к 11. Планируем на 11 — а такая же ерунда, люди отучились приходить вовремя.

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

E>Прелесть работы в одном офисе в том, чтобы упростить и ускорить коммуникации, тем самым ускорить решение вопросов, а с таким подходом, когда нужных людей не соберешь быстро, в чем тогда смысл?

В принципе существующие средства коммуникации вполне неплохо подходят для решения повседневных задач.

E>В целом, я за гибкий график в разумных пределах (у нас эти разумные пределы обозначены). Проблема в том, что привыкнув к удобству в этих разумных пределах, каждому сотруднику хочется эти пределы расширить, просто потому что удобно вставать не по будильнику, а потому что выспался. И ведь правда, если не выспался — какая эффективность работы будет? А лечь спать вовремя — это скучно, ведь вечером хочется весело провести время.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

8>>Вот это меня всегда удивляло. Типа не меньше 40 часов в неделю.
8>>В итоге люди зачастую просто сидят, насижывают эти часы и ничего при этом все равно не делают.
8>>Лучше пусть пойдет своими делами займется, главное что бы поставленные задачи успевал сделать
8>>к сроку. Тут конечно много нюансов, но все же.

G>Тут действительно есть нюанс. И не один.
G>А кто определяет сроки на решение задач?
G>А как бороться с видимым неравноправием в команде?
G>А как определить, что человек действительно работы делает не меньше чем другие?
G>итд.
G>так что проще чтобы все работали по 8 часов в день и все.

Вот только работа по 8 часов не устраняет ни одного из вышеприведенных нюансов

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>Вот только работа по 8 часов не устраняет ни одного из вышеприведенных нюансов

зато работа "кто как хочет" провоцирует их появление.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

L>Аргументы? Если я начну приводить аргументы, это будет избиением младенца.

Звучит забавно от человека не приведшего ни одного аргумента в споре.

Думаю на этой прекрасной ноте мы и закончим.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>>Вот только работа по 8 часов не устраняет ни одного из вышеприведенных нюансов

G>зато работа "кто как хочет" провоцирует их появление.

В такой же мере как и работа по 8 часов. Все зависит от комплекса работодатель-работник.

У нас на проекте нет жесткого требования отработать сколько-то там часов. Главное, чтобы работа была выполнена в срок. Причем, опять же, сроки практически никогда не спускаются сверху. Я сам прекрасно знаю какой объем работ мне предстоит сделать в ближайшее время и сколько примерно у меня есть времени на это. Раз или два меня спрашивали сколько мне понадобится времени. Но это было в случае, когда части проекта пересекались так, что их никак не распараллелить.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

B>>Т.е. не работают? А если заказчик в 7-8 часах? И у него on-site тоже есть QA? Или вы такой возможности не представляете?
O>Тестить на заказчике? Хммм....

А в чем проблемы? Все зависит от проекта. Я, например, сейчас работаю на проекте в котором девелоперы взаимодействуют непосредственно с заказчиком. Фактически, мы являемся частью команды заказчика. С фирмой, на которой мы работаем, мы фактически связаны тем, что она выплачивает нам з.п.

И тестеры как раз находятся на стороне заказчика.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

B>>Т.е. не работают? А если заказчик в 7-8 часах?
O>Кстати, из-за таймзоны оффшорное программирование — зло

Не был бы так категоричен. Зависит от проекта, от того как поставлена работа над проектом.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>>А бывает, что самый простой и дешевый способ — это чтобы все приходили на работу вовремя.

L>>Только не надо тогда сказки придумывать про тысячи неустойки за минуту простоя. А то у Вас неувязочка в показаниях получается — что будет, если бага у клиента вылезет в 2:38 ночи?

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

Вот только какая разница клиенту ночь или день. Он деньги теряет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

L>>Аргументы? Если я начну приводить аргументы, это будет избиением младенца.

G>Звучит забавно от человека не приведшего ни одного аргумента в споре.

Мой аргумент — аббривеатура CSM.

А теперь можешь продолжать рассказывать мне сказки про scrum.

G>Думаю на этой прекрасной ноте мы и закончим.

Как угодно.

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

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

AV>Вот только какая разница клиенту ночь или день. Он деньги теряет.

Не обращай внимание, человек в показаниях путается. У него уже и daily scrum стал способом контроля подчиненных, и неустойку нужно платить только если система ломается с двух до трех и так далее.

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

TMU>Прошу прощения? А вы полагали, что все работы в Риме делали исключительно рабы? Насчет источника — постараюсь найти, просто как-то полагал общим местом то, что легионы времен принципата, а затем и домината, особенно находящиеся в удаленных провинциях, широко привлекались к строительству, в том числе дорожному.

С тех пор мало что изменилось

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

G>ДА, а теперь представим, что в ситуации а он еще и поздно пришел, и когда он багу отдал тестеру, тот уже ушел домой. И еще пару таких итераций. В итоге набежит задержка в пару дней, которой могло бы не быть.

Что мешает в случае таких архикритических багов временно договорится участникам об общем времени?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

E>Достаточно важно, по ряду причин.

E>1. Спонтанная необходимость обсуждения технических деталей. Возникли вопросы, хочется обсудить, а на рабочем месте нет то одного, то другого. Тот пришел, другой ушел на обед. Другой вернулся с обеда, тот ушел на обед и в таком духе. А теперь представим, что разработчиков, с которыми надо обсуждать что-то (не одновременно, а в разных комбинациях) не двое, а два десятка и все любят гибкий график и не регламентированный обед.

E>2. Приходят пара сотрудников, сначала к 10, потом начинают приходить к 10:20, потом к 10:45, потом в 11:15. Сначала раз в две недели, потом два раза в неделю, потом 3 дня из 5. Глядя на них, остальные тоже начинают позволять себе вольности. Через несколько месяцев получаем отдел разработки, где все приходят когда хотят, уходят когда хотят и ходят на обед когда хотят. Хочешь собрать совещание с 3 участниками, и см. пункт 1. Окей, думаете вы, а почему бы не запланировать совещание заранее? На 10 не запланируешь — некоторые приходят к 11. Планируем на 11 — а такая же ерунда, люди отучились приходить вовремя.

E>Прелесть работы в одном офисе в том, чтобы упростить и ускорить коммуникации, тем самым ускорить решение вопросов, а с таким подходом, когда нужных людей не соберешь быстро, в чем тогда смысл?

E>В целом, я за гибкий график в разумных пределах (у нас эти разумные пределы обозначены). Проблема в том, что привыкнув к удобству в этих разумных пределах, каждому сотруднику хочется эти пределы расширить, просто потому что удобно вставать не по будильнику, а потому что выспался. И ведь правда, если не выспался — какая эффективность работы будет? А лечь спать вовремя — это скучно, ведь вечером хочется весело провести время.

E>В общем, как-то так.

+100! Особенно по пункту 2 — +200! У нас в конторе такая хрень практикуется — полнейший бардак.

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

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

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

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

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

Дык а какие тут риски? Если человек отвечает только за себя самого то и риски у него тольк "набухался вчера — башка разваливается — не могу работать", "хочется поспать подольше — приду попоже — уйду пораньше" — вот и все риски. Он же деньги свои не вкладывает, имуществом не рискует. Плюс ключевой момент — см.выделенное выше. То есть "назвался груздём — полезай в короб".

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

Кто не умеет, тот не получит 50% надбавки — только и всего

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

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

Да, бардак всегда есть. Но есть рабочий, управляемый бардак. А есть просто бардак. Описанная тобой ситуация — второй случай.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>>1. Спонтанная необходимость обсуждения технических деталей. Возникли вопросы, хочется обсудить, а на рабочем месте нет то одного, то другого. Тот пришел, другой ушел на обед. Другой вернулся с обеда, тот ушел на обед и в таком духе. А теперь представим, что разработчиков, с которыми надо обсуждать что-то (не одновременно, а в разных комбинациях) не двое, а два десятка и все любят гибкий график и не регламентированный обед.
__>госсподи, вы будто не работали никогда
__>вот приходите вы на работу. бац — глюк — приложение падает у кого-то, подтвердились какие-то опасения насчет сырой технологии. нужно принять решение -переписывать на другую или ставить костыли.
__>идем с этим вопросом к начальнику.
__>а его нет. ага
__>...
__>несем приложение начальнику — вот, можно выкладывать. а начальника нет. он свалил куда-то уже.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>У нас на проекте нет жесткого требования отработать сколько-то там часов. Главное, чтобы работа была выполнена в срок. Причем, опять же, сроки практически никогда не спускаются сверху.

А теперь давай представим, что ты директор компании в которой работает 100 программистов. Каждый назначает себе сроки сам. И регулярно (это такое свойство человеческое переоценивать свои способности и недооценивать риски) половина из них промахивается в своих оценках. При этом работая кто 30, а кто 50 часов в неделю.

Степень твоего доверия этим срокам?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>ДА, а теперь представим, что в ситуации а он еще и поздно пришел, и когда он багу отдал тестеру, тот уже ушел домой. И еще пару таких итераций. В итоге набежит задержка в пару дней, которой могло бы не быть.

AV>Что мешает в случае таких архикритических багов временно договорится участникам об общем времени?

Так вроде об этом речь и идет. Что надо договариваться о времени.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>>ДА, а теперь представим, что в ситуации а он еще и поздно пришел, и когда он багу отдал тестеру, тот уже ушел домой. И еще пару таких итераций. В итоге набежит задержка в пару дней, которой могло бы не быть.

AV>>Что мешает в случае таких архикритических багов временно договорится участникам об общем времени?

G>Так вроде об этом речь и идет. Что надо договариваться о времени.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

a>> Согласен, что не всем подойдёт.

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

A>Я сформулировал только что эмпирические правила

A>1) если у работника свободный график, то в 99% случаев (оставлю 1% на всякий случай) работодателя устраивает его производительность, самомотивация и самодисциплина.

Согласен.

A>2) если у работника нет свободного графика и он недоумевает, то в 90% случаев он себя переоценивает (10% приходится на работодателей, которым религиозные мотивы не позволяют разрешить свободный график).

А вот тут есть большие сомнения.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>Степень твоего доверия этим срокам?

AV>В целом фигово. Но стоит разобраться в причинах таких промахов. Вот только я сомневаюсь в том, что причиной будет именно гибкость в рабочем расписании.

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

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

Ну то есть сроки называешь не ты?

AV>А теперь давай представим, что ты директор компании в которой работает 100 программистов. В которой они работают по 8 часов в день. И регулярно половина из них не укладывается в те сроки что ты назначаешь.

Эта ситуация более прозрачна для руководства. Один источник проблем, то что люди тупо не ходят на работу, уже устранен. Осталось разобраться, где проблема — сроки невменяемые или люди халявят уже в офисе.
В первом же случае — либо все забили ходить на работу, либо халявят в офисе, либо называют неадкватные сроки.

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

AV>Вот на этой неделе я в очередной раз столкнулся с ситуацией, когда фиксированное расписание пролетело бы.
AV>Смысл такой работы от звонка до звонка?

Есть две грани на этой шкале. СОвершенно свободный график — совершенно жесткое расписание. Истина как обычно где-то посередине. Большинство устроит график с фиксированными 4-5 часами присутствия в день.

ВОт кстати, не довелось сталкиваться с банками, кто в курсе как там, фиксированный график или свободный?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>Если ты не заметил, то я говорил, что о более жестком графике надо договариваться в исключительных ситуациях. В остальное же время не вижу необходимости жесткого графика.

ну да. просто исключительные ситуации в разных проектах возникают с разной частотой.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

G>Кто не умеет, тот не получит 50% надбавки — только и всего

Кто не умеет — не получит вообще ничего до тех пор пока не сделает.

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

G>>>Степень твоего доверия этим срокам?

AV>>В целом фигово. Но стоит разобраться в причинах таких промахов. Вот только я сомневаюсь в том, что причиной будет именно гибкость в рабочем расписании.

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

Одним из факторов может оказаться. Осталось только оценить насколько сильно этот фактор влияет. А насчет перенапрягаться, то не нужно так делать. Это вредно сказывается на работе. Нужно чтобы работа была выполнена в срок.

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

G>Ну то есть сроки называешь не ты?

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

AV>>А теперь давай представим, что ты директор компании в которой работает 100 программистов. В которой они работают по 8 часов в день. И регулярно половина из них не укладывается в те сроки что ты назначаешь.

G>Эта ситуация более прозрачна для руководства. Один источник проблем, то что люди тупо не ходят на работу, уже устранен.

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

G>Осталось разобраться, где проблема — сроки невменяемые или люди халявят уже в офисе.
G>В первом же случае — либо все забили ходить на работу, либо халявят в офисе, либо называют неадкватные сроки.

Полагаешь, что в первом случае так сложно проверить забил человек ходить на работу или нет?

G>Причем если представить что я руководитель, то мне лично проверить, что я занижаю сроки будет проще, чем то, что сотрудники их завышают.

Очень опасное заблуждение.

AV>>Вот на этой неделе я в очередной раз столкнулся с ситуацией, когда фиксированное расписание пролетело бы.
AV>>Смысл такой работы от звонка до звонка?

G>Есть две грани на этой шкале. СОвершенно свободный график — совершенно жесткое расписание. Истина как обычно где-то посередине. Большинство устроит график с фиксированными 4-5 часами присутствия в день.

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

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

А было бы у меня требование отработать 8 часов (как ты ратуешь), то мои задачи пришлось бы работодателю сдвигать на неделю. Ибо сейчас при свободном графике я плачу добром за добро. А при жестком расписании нафиг не это не впало.

G>ВОт кстати, не довелось сталкиваться с банками, кто в курсе как там, фиксированный график или свободный?

Сталкивался, но не работал там. И уж тем более, что я не считаю банки эталоном в этом вопросе.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>Если ты не заметил, то я говорил, что о более жестком графике надо договариваться в исключительных ситуациях. В остальное же время не вижу необходимости жесткого графика.

G>ну да. просто исключительные ситуации в разных проектах возникают с разной частотой.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

AV>Одним из факторов может оказаться. Осталось только оценить насколько сильно этот фактор влияет.

И оценить негативные последствия такого фактора.

AV>А насчет перенапрягаться, то не нужно так делать. Это вредно сказывается на работе. Нужно чтобы работа была выполнена в срок.

Опять возникает это магическое словосочетание "в срок". Тебе разве платят сдельно?
Сомневаюсь, скорее всего твой трудовой договор в сочетании с ТК подразумевает, что ты продаешь работодателю 40 часов в неделю за определенную плату, так?

G>>Эта ситуация более прозрачна для руководства. Один источник проблем, то что люди тупо не ходят на работу, уже устранен.
AV>Осталось только разобраться является ли это источником проблем. К тому же, если ты не заметил, то нико не предлагал не ходить на работу.

ходить. по 15-20 часов в неделю например.

G>>Осталось разобраться, где проблема — сроки невменяемые или люди халявят уже в офисе.
G>>В первом же случае — либо все забили ходить на работу, либо халявят в офисе, либо называют неадкватные сроки.
AV>Полагаешь, что в первом случае так сложно проверить забил человек ходить на работу или нет?

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

G>>Причем если представить что я руководитель, то мне лично проверить, что я занижаю сроки будет проще, чем то, что сотрудники их завышают.
AV>Очень опасное заблуждение.

Правда проще. РУководитель мотивирован ставить реальные сроки. Работник мотивирован завышать сроки.

G>>Есть две грани на этой шкале. СОвершенно свободный график — совершенно жесткое расписание. Истина как обычно где-то посередине. Большинство устроит график с фиксированными 4-5 часами присутствия в день.

AV>А примерно такое пересечение в среднем и получится при свободном графике.

Ну вот у меня перед глазами два человека которые при свободном графике практически не пересекаются в офисе. Это хорошо, что они друг от друга не зависят. А если бы зависили?

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

Бывают задачи когда человека можно вообще на месяц дома запереть и пусть работает. А бывает обратное.
Например задачи багфикса часто требуют большого количества коммуникаций. И тогда скорость работы из дома сильно падает.

AV>А было бы у меня требование отработать 8 часов (как ты ратуешь), то мои задачи пришлось бы работодателю сдвигать на неделю.

Я не ратую за жесткий рабочий график. Я как и любой вменяемый человек люблю приходить на работу когда мне удобно. Я лишь пытаюсь объяснить почему у руководства могут быть причины требовать детерминированного графика в некоторых случаях.

AV>Ибо сейчас при свободном графике я плачу добром за добро. А при жестком расписании нафиг не это не впало.

Это слишком категоричное утверждение

А если жесткий график и необходимость сделать дело в срок, но денег в два раза больше?
Все надо учитывать в комплексе.

G>>ВОт кстати, не довелось сталкиваться с банками, кто в курсе как там, фиксированный график или свободный?
AV>Сталкивался, но не работал там. И уж тем более, что я не считаю банки эталоном в этом вопросе.

Однако софт пишут. И неплохой. А если верить некоторым местным персонажам не должны ну никак.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>ну да. просто исключительные ситуации в разных проектах возникают с разной частотой.

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>>Если исключительные ситуации на проекте возникают каждый день, то на проекте творится банальный бардак. А если исключительная ситуация возникает раз в пару месяцев, то не вижу проблем в том, чтобы договориться на пару дней.
G>Я тут выше описывал как банальный баг может затормозить работу над конкретной веткой кода на пару дней. Это исключительная ситуация?
Конечно исключительные.
В этом случае — команде дается отгулы на пару дней, а когда баг чинится — вся команда работает и субботу, и воскресенье.
Также бонус свободного графика — днем работать надо на полчаса меньше. Свободный же график! Поэтому максимум раз в неделю, не чаще! работодатель звонит в 02:38 и просит по быстрому исправить такой же баг.
Вот читаю описание работы от AV — прямо слеза по щекам стекает, как все грамотно придумано, да еще замотивировано.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>ходить. по 15-20 часов в неделю например.

AV>Даже на секунду положим что так хотят. Что в этом плохого, если они выполняют все поставленные задачи?

Кстати не факт, что даже отрабатывая и не халтуря 40 часов они будут делать в два раза больше работы.
У меня например максимальная производительность при отработке 4 — 6 часов в день.

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

AV>Не был бы так категоричен. Зависит от проекта, от того как поставлена работа над проектом.
Да хоть как поставлена. Неудобно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

AV>>Не был бы так категоричен. Зависит от проекта, от того как поставлена работа над проектом.
O>Да хоть как поставлена. Неудобно.

Да ты шо? Образумь нас. А то мы уже более года на проекте где между нашей командой и командой заказчика 10 часов разбежки.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>Мелочи? Да, мелочи. Но из таких мелочей и складываются нормальные отношения. В результате, даже если мне когда-то придется покинуть эту компанию, то у меня о ней останутся только хорошие воспоминания.
Искренне извиняюсь, видимо, слишком привык к европейской жизни.
Все перечисленное вами, кроме "точно такой же подход использует и работодатель." — самая обыденная вещь у практически любого IT работодателя.

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

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

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

И вот кроме того. Представим себе человека "делающего в срок" и работающего по 4 часа в день. Ты как его руководитель не задумаешь ли что ты ему мало задач ставишь?

G>>Однако софт пишут. И неплохой. А если верить некоторым местным персонажам не должны ну никак.
AV>В банках? Ну не знаю, не знаю. Как когда. А насчет того, что пишут, то с чего бы не должны.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>Скажем так, пример очень натянутый. У нас тестеры сидят в 10 часах от нас. И такого бардака не наблюдается.

Пример из реальной жизни.

AV>Но положим что так уж случилось. Да, это исключительная ситуация. Вот и согласовали на пару дней единое время работы. Исправили баг. И дальше перешли в прежний режим. В чем проблемы?

Так баги не появляются по расписанию. Как договориться-то?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>А вы genre на работу возьмите и менеджером поставьте.

А ты бы вместо того, чтобы чувство юмора проявлять на вопросы бы отвечал. Например тут

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>И вот кроме того. Представим себе человека "делающего в срок" и работающего по 4 часа в день. Ты как его руководитель не задумаешь ли что ты ему мало задач ставишь?

http://www.rsdn.ru/forum/job/3971568.1.aspx

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

>> O>Да хоть как поставлена. Неудобно.
>>
>> Да ты шо? Образумь нас. А то мы уже более года на проекте где между
>> нашей командой и командой заказчика 10 часов разбежки.
V>А вы genre на работу возьмите и менеджером поставьте.

Типун тебе на язык. Уж как-нибудь и дальше будем обходиться без менеджеров на месте. Да и заказчик пошлет такое предложение. К тому же и у нас будет право прокатить его кандидатуру.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>Проблема в подобных обсуждениях в том, что все меряют по себе.
G>Вот ты говоришь — "как ко мне, так и я", "вы мне свободу, я вам качественную работу" итд
G>Хорошо, я верю что это так и все кто утверждает подобное действительно так и делают.
G>Но вот ты лично, готов поручится что все сто человек в компании думают и делают так же?

Посмотрел на нашу компанию. Вроде подход ко всем одинаков. И ни с кем проблем не возникает.

G>Причем даже команды где все так не думают вполне успешно сущесвуют — люди работают на какой-то процент от максимума и все довольны. Менеджмент думает, что это реальные сроки, команда не напрягается, все счастливы.

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

G>И вот кроме того. Представим себе человека "делающего в срок" и работающего по 4 часа в день. Ты как его руководитель не задумаешь ли что ты ему мало задач ставишь?

Задумаюсь. Если человек так успешно работает, то почему бы не предложить ему больше?

G>>>Однако софт пишут. И неплохой. А если верить некоторым местным персонажам не должны ну никак.
AV>>В банках? Ну не знаю, не знаю. Как когда. А насчет того, что пишут, то с чего бы не должны.

G>Ну тут вот в топике звучали фразы типа "дайте программистам свободу и они сами все сделают, а не дадите — ничего не получится".

Ну это уже глупость.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>Скажем так, пример очень натянутый. У нас тестеры сидят в 10 часах от нас. И такого бардака не наблюдается.

G>Пример из реальной жизни.

И? Бардак он и в реальной жизни существует.

AV>>Но положим что так уж случилось. Да, это исключительная ситуация. Вот и согласовали на пару дней единое время работы. Исправили баг. И дальше перешли в прежний режим. В чем проблемы?

G>Так баги не появляются по расписанию. Как договориться-то?

Какие проблемы? Если честно, то я не вижу их. Или мы живем в Средние Века и современные средства коммуникации недоступны?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>Да ты шо? Образумь нас. А то мы уже более года на проекте где между нашей командой и командой заказчика 10 часов разбежки.

G>У меня тоже с заказчиком разница во времени. Работа конечно движется. Но реально неудобно. Коммуникации были бы удобнее и быстрее если бы разницы не было.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>И вот кроме того. Представим себе человека "делающего в срок" и работающего по 4 часа в день. Ты как его руководитель не задумаешь ли что ты ему мало задач ставишь?

FR>http://www.rsdn.ru/forum/job/3971568.1.aspx

Да, я даже хотел ответить туда. В два гарантированно не будет. Принято считать, что программист из 8 рабочих часов реально работает 5-6.
Вопрос, сколько он реально будет работать из 4-х?
Если даже предположить, что все работают по 8, а часть по 4 часа, но делают одинаковый объем работы, то как в этом убедиться?
И не вызвать ощущение неравенства в команде?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>Посмотрел на нашу компанию. Вроде подход ко всем одинаков. И ни с кем проблем не возникает.

То есть ты уверен, что все проделывают одинаковый объем работ? Или ты думаешь что это так?

AV>Ой, как страшно. Думаешь что-то изменится от того, что люди будут отсижывать по 8 часов

Хоть какой-то контроль лучше чем его отсутствие.

G>>И вот кроме того. Представим себе человека "делающего в срок" и работающего по 4 часа в день. Ты как его руководитель не задумаешь ли что ты ему мало задач ставишь?
AV>Задумаюсь. Если человек так успешно работает, то почему бы не предложить ему больше?

Ага. А человек скажет, а чего это вы мне за часы платите, а не за задачи?

G>>Ну тут вот в топике звучали фразы типа "дайте программистам свободу и они сами все сделают, а не дадите — ничего не получится".
AV>Ну это уже глупость.

И на том спасибо

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Пример из реальной жизни.
AV>И? Бардак он и в реальной жизни существует.

ты точно понял про какой пример я говорю? Там пробелемы не из-за бардака.

G>>Так баги не появляются по расписанию. Как договориться-то?
AV>Какие проблемы? Если честно, то я не вижу их. Или мы живем в Средние Века и современные средства коммуникации недоступны?

Ну то есть пришел Вася в 7 утра на работу, в 5 ушел. Едет себе в метро И тут звонит тестер и разворачивает его обратно на работу?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>Какие претензии к средствам коммуникации? У нас на проекте нет никаких затыков по причине разного времени. Да, иногда по ходу работы возникают моменты, когда хочется поговорить с другой стороной, но там уже давно спят. Но такое возникает достаточно редко и не носит критических характер.

К средствам никаких претензий. Телефон, аська, почта и видеоконференции — все работает прекрасно.

Проблема в том, что приходя на работу скажем в 11 утра ты можешь уткнуться в проблему требующую участия клиента. А клиент на работу придет часов в 5 вечера. То есть работа над фичей стоит. А фича, допустим, обещана через неделю. В итоге ты вынужден следующий раз закладывать сроки на вот эти коммуникации.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>Да, я даже хотел ответить туда. В два гарантированно не будет. Принято считать, что программист из 8 рабочих часов реально работает 5-6.
G>Вопрос, сколько он реально будет работать из 4-х?

Из четырех 3 — 4.
Из восьми 3 — 6.

G>Если даже предположить, что все работают по 8, а часть по 4 часа, но делают одинаковый объем работы, то как в этом убедиться?

Во первых зачем уравниловка?
И как мерять одинаковость?

И вообще люди неравны, а программисты сильно неравны, разбежка производительности на порядок вполне реальна:
http://russian.joelonsoftware.com/Articles/HighNotes.html

G>И не вызвать ощущение неравенства в команде?

А вот это задача для хорошего менеджера.

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

V>24.09.2010 10:03, Glоbus пишет:
>> E>1. Спонтанная необходимость обсуждения технических деталей. Возникли
V>...
>>
>> E>В общем, как-то так.
>>
>> +100! Особенно по пункту 2 — +200! У нас в конторе такая хрень
>> практикуется — полнейший бардак.
V>Русские менеджеры ну почитайте вы хоть немного книжки по управлению (и
V>не только обложку).

Я украинский тимлид

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

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

AV>>Посмотрел на нашу компанию. Вроде подход ко всем одинаков. И ни с кем проблем не возникает.

G>То есть ты уверен, что все проделывают одинаковый объем работ? Или ты думаешь что это так?

Нет, уверен что разный объем работы. И что?

AV>>Ой, как страшно. Думаешь что-то изменится от того, что люди будут отсижывать по 8 часов

G>Хоть какой-то контроль лучше чем его отсутствие.

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

G>>>И вот кроме того. Представим себе человека "делающего в срок" и работающего по 4 часа в день. Ты как его руководитель не задумаешь ли что ты ему мало задач ставишь?
AV>>Задумаюсь. Если человек так успешно работает, то почему бы не предложить ему больше?

G>Ага. А человек скажет, а чего это вы мне за часы платите, а не за задачи?

И правильно скажет. Кто сказал, что при увеличении пользы от человека з.п. ему не надо подымать?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>>Пример из реальной жизни.
AV>>И? Бардак он и в реальной жизни существует.

G>ты точно понял про какой пример я говорю? Там пробелемы не из-за бардака.

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

G>>>Так баги не появляются по расписанию. Как договориться-то?
AV>>Какие проблемы? Если честно, то я не вижу их. Или мы живем в Средние Века и современные средства коммуникации недоступны?

G>Ну то есть пришел Вася в 7 утра на работу, в 5 ушел. Едет себе в метро И тут звонит тестер и разворачивает его обратно на работу?

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

G>>Кто не умеет, тот не получит 50% надбавки — только и всего

A>Кто не умеет — не получит вообще ничего до тех пор пока не сделает.

Насколько я понял идею автора, надбавка в 50% дается за то, что вовремя сделал, а если пролетел — то обычная ставка. По-моему, вполне демократично

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

AV>>Какие претензии к средствам коммуникации? У нас на проекте нет никаких затыков по причине разного времени. Да, иногда по ходу работы возникают моменты, когда хочется поговорить с другой стороной, но там уже давно спят. Но такое возникает достаточно редко и не носит критических характер.

G>К средствам никаких претензий. Телефон, аська, почта и видеоконференции — все работает прекрасно.

G>Проблема в том, что приходя на работу скажем в 11 утра ты можешь уткнуться в проблему требующую участия клиента. А клиент на работу придет часов в 5 вечера. То есть работа над фичей стоит. А фича, допустим, обещана через неделю.

Да, такое может быть. Но вся соль и состоит в том, чтобы на самом раннем этапе постараться сделать так, чтобы таких затыков не было. Хотя это и не полная гарантия. Опять же, что мешает маневрировать ресурсами?

G>В итоге ты вынужден следующий раз закладывать сроки на вот эти коммуникации.

И как велики размеры этого дополнительного времени?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>Да ты шо? Образумь нас. А то мы уже более года на проекте где между нашей командой и командой заказчика 10 часов разбежки.
Проблема в том, что лаг в один день — обычное дело. Для вас может и некритично, может вы и привыкли к такому лагу.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

24.09.2010 18:28, olegkr пишет:
>
> Проблема в том, что лаг в один день — обычное дело. Для вас может и
> некритично, может вы и привыкли к такому лагу.
Я как сторонний уже чел, но хорошо знаю, эту контору. Ты не поверишь, но
лаг у них и в 5 мин бывает, если это критично, ну а если не критично, то
смысл бегать, как ужаленным.

Posted via RSDN NNTP Server 2.1 beta

24.09.2010 17:36, ambel-vlad пишет:
>
> Ой, как страшно. Думаешь что-то изменится от того, что люди будут
> отсижывать по 8 часов
Измениться отношение к работе.

>
> Задумаюсь. Если человек так успешно работает, то почему бы не предложить
> ему больше?
Есть опасность, что больше он не потянет, просто вымотается и все —
деньги это уже во вторую очередь (сыр в мышеловке). Просто этот человек
способен 4 часа в день очень интенсивно работать головой.

>
> G>Ну тут вот в топике звучали фразы типа "дайте программистам свободу и
> они сами все сделают, а не дадите — ничего не получится".
>
> Ну это уже глупость.
Да? Ты тоже воспринимаешь слово свобода исключительно в варианте
доведенном до маразма (свобода от всего)?

Posted via RSDN NNTP Server 2.1 beta

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

V>3. Программист делает разбивку задачи на подзадачи сроками по 2-3 дня,
V>но не дальше, чем на 2 недели вперед.

Вот это уже предметно. Я по пунктам напишу в понедельник.
пока только мелкое замечание.

вот тут ты утверждал что Подобная методика гарантирует завышение сроков раза в 2-3.

как-то странно, не?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>То есть ты уверен, что все проделывают одинаковый объем работ? Или ты думаешь что это так?
AV>Нет, уверен что разный объем работы. И что?

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

А вот если нет:
AV>Я не говорю, что контроля не должно быть. Вот только контроль в виде меряния сколько времени я просиживаю штаны практически бессмысленен.

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

AV> Гораздо продуктивнее анализировать результаты деятельности программиста, и на их основании делать выводы.
ТАк одно другому не мешает, а помогает.

G>>Ага. А человек скажет, а чего это вы мне за часы платите, а не за задачи?
AV>И правильно скажет. Кто сказал, что при увеличении пользы от человека з.п. ему не надо подымать?
см. выше. проблема эту пользу измерять.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Проблема в том, что приходя на работу скажем в 11 утра ты можешь уткнуться в проблему требующую участия клиента. А клиент на работу придет часов в 5 вечера. То есть работа над фичей стоит. А фича, допустим, обещана через неделю.

AV>Да, такое может быть. Но вся соль и состоит в том, чтобы на самом раннем этапе постараться сделать так, чтобы таких затыков не было.

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

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

AV>Хотя это и не полная гарантия. Опять же, что мешает маневрировать ресурсами?

Это не значит, что ресурсы простаивают. Есть много задач. Но вот конкретно эта задача — стоит.

G>>В итоге ты вынужден следующий раз закладывать сроки на вот эти коммуникации.
AV>И как велики размеры этого дополнительного времени?

Зависит от начальных условий. Бывает и очень много.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

FR>Во первых зачем уравниловка?
FR>И как мерять одинаковость?
FR>И вообще люди неравны, а программисты сильно неравны, разбежка производительности на порядок вполне реальна:
FR>http://russian.joelonsoftware.com/Articles/HighNotes.html

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

G>>И не вызвать ощущение неравенства в команде?
FR>А вот это задача для хорошего менеджера.

Ну как например?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

И как же решаются подобные проблемы?

G>>Ну то есть пришел Вася в 7 утра на работу, в 5 ушел. Едет себе в метро И тут звонит тестер и разворачивает его обратно на работу?

AV>В чем проблема? Не, я, конечно, обратно в офис не поеду. А доеду домой и оттуда начну работать над проблемой. А пока буду ехать, то постараюсь по скайпу выудить как можно больше полезной информации. И заодно договорюсь во сколько завтра с утра будем пересекаться.

Хорошо. Меняем в предыдущей фразе предложение Едет себе в метро на "допивает шестое пиво"

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

E__>В описанной тобою там ситуации всем на баг насрать. Потому так и получается. Реально свободный/гибкий график хорошо работает там, где людям по разным причинам небезразлично то, что они делают. Потому что телефон, аську, мыло и прочие коммуникационные инструменты никто не отменял. А у тебя там все действовали по принципу "на от#бись": отфутболил кому-то, и забыл.

Категоричность это зло

Почему сразу насрать? Программер вечером ушел в бассейн, трубку не берет. Тестер не пришел с утра, зная что фикс будет поздно, программер ушел рано потому что с 6 утра багу фиксил в авральном режиме. итд.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

>> Ой, как страшно. Думаешь что-то изменится от того, что люди будут
>> отсижывать по 8 часов
V>Измениться отношение к работе.

Вопрос только в какую сторону. Не совсем уверен, что в нужную.

>> Задумаюсь. Если человек так успешно работает, то почему бы не предложить
>> ему больше?
V>Есть опасность, что больше он не потянет, просто вымотается и все —
V>деньги это уже во вторую очередь (сыр в мышеловке). Просто этот человек
V>способен 4 часа в день очень интенсивно работать головой.

В таком случае останемся при своих. То есть вернемся к начальному положению. Никаких проблем.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>>Проблема в том, что приходя на работу скажем в 11 утра ты можешь уткнуться в проблему требующую участия клиента. А клиент на работу придет часов в 5 вечера. То есть работа над фичей стоит. А фича, допустим, обещана через неделю.

AV>>Да, такое может быть. Но вся соль и состоит в том, чтобы на самом раннем этапе постараться сделать так, чтобы таких затыков не было.

G>Ну вот конкретно в этом примере эта задача называется сбор требований. Да, в идеальном мире, нужно собрать сначала все требования, написать доку на 500 страниц, отдать её девелоперам, потом они год девелопят и потом тестеры год тестят. В такой схеме действительно затраты на коммуникации сводятся к минимуму и можно месяцами работать из дома.
G>Но в реальном мире с этим сложнее. Требования меняются, уточняются итд.

G>Вот и приходиться учитывать затраты на коммуникации между всеми отделами.

Ну, есть сомнения что в таком случае именно затраты на коммуникации являются критическим моментом. Что-то сильно изменится если обе стороны будут пересекаться в течении длительного времени? Просто надо рассматривать на промежуток чуть более чем один день работы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

G>И как же решаются подобные проблемы?

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

G>>>Ну то есть пришел Вася в 7 утра на работу, в 5 ушел. Едет себе в метро И тут звонит тестер и разворачивает его обратно на работу?

AV>>В чем проблема? Не, я, конечно, обратно в офис не поеду. А доеду домой и оттуда начну работать над проблемой. А пока буду ехать, то постараюсь по скайпу выудить как можно больше полезной информации. И заодно договорюсь во сколько завтра с утра будем пересекаться.

G>Хорошо. Меняем в предыдущей фразе предложение Едет себе в метро на "допивает шестое пиво"

Фигово будет. И что?

Взять то же сидение в фиксированое время. Программер работает с 9 до 18 часов. В 17 часов приходят с багом. Ну прикинул программер, что за 5-10 минут не пофиксить. А в 18 часов все равно уходить. Ну и черт с ним, посмотрю завтра.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>>То есть ты уверен, что все проделывают одинаковый объем работ? Или ты думаешь что это так?
AV>>Нет, уверен что разный объем работы. И что?

G>И у тебя это отражено в зарплатах?

Да, у нас з.п. работников различаются.

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

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

G>А вот если нет:
AV>>Я не говорю, что контроля не должно быть. Вот только контроль в виде меряния сколько времени я просиживаю штаны практически бессмысленен.

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

А какая разница за сколько человек сделал необходимый объем работ? Вот просидели два человека 5 дней по 8 часов. Каждый выполнил те задачи, что стояли перед ними. И что дальше? Какая разница, если то же самое они сделали за те же 5 дней, но один при этом тратил на это 8 часов в день, а другой — всего лишь по 6?

AV>> Гораздо продуктивнее анализировать результаты деятельности программиста, и на их основании делать выводы.
G>ТАк одно другому не мешает, а помогает.

И как же помогает знание "просиженного времени"?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>Я украинский тимлид

Один только вопрос.
Работники финансово заинтересованы выполнять работу?
Ну, то есть, получают ли они профит с вовремя качественно реализованной задачи? Нет? Тогда все логично.

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

G>>Ну то есть пришел Вася в 7 утра на работу, в 5 ушел. Едет себе в метро И тут звонит тестер и разворачивает его обратно на работу?

AV>В чем проблема? Не, я, конечно, обратно в офис не поеду. А доеду домой и оттуда начну работать над проблемой. А пока буду ехать, то постараюсь по скайпу выудить как можно больше полезной информации. И заодно договорюсь во сколько завтра с утра будем пересекаться.

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

Да, цена вопроса _вроде как_ невелика. Порядка 800 тысяч гривень(примерно за выходные, благо точно неизвестно: ни разу не происходило, данные аналитические) +, ну, точнее, минус лояльность клиентов нашей компании.

ЗЫ 800 тысяч гривень это порядка 100 тысяч долларов. Так, подумаешь, копеечки

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

G>>>Ну то есть пришел Вася в 7 утра на работу, в 5 ушел. Едет себе в метро И тут звонит тестер и разворачивает его обратно на работу?

AV>>В чем проблема? Не, я, конечно, обратно в офис не поеду. А доеду домой и оттуда начну работать над проблемой. А пока буду ехать, то постараюсь по скайпу выудить как можно больше полезной информации. И заодно договорюсь во сколько завтра с утра будем пересекаться.

E__>Что-то подобное. Вот сегодня как раз была такая ситуация. Только я был еще на работе, а человек уже домой ехал. Я по телефону объяснил проблему, он попросил выслать нужные для решения данные на его мыло. Я спокойно уехал пиво пить. Сейчас приехал домой, зашел — проблема решена. Да, сотрудником из дома. Будет проблема моя — я из дома решу. А сейчас, напоминаю, ночь с пятницы на субботу.

Нормальный подход.

E__>С вашей моделью жопочасов проблема была бы решена только в понедельник утром.

Ты точно меня не путаешь с кем-то другим? А то я не сторонник подхода жопочасов.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E__>>С вашей моделью жопочасов проблема была бы решена только в понедельник утром.

AV>Ты точно меня не путаешь с кем-то другим? А то я не сторонник подхода жопочасов.

Я тебе ответил, но писал эту фразу оппонентам. Они это ведь тоже прочитают.

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

E__>Но есть и другой менеджмент. Его просто нужно найти. Я нашел, и рад. И да, жопочасы — не мера. Это тупость ограниченных руководителей.

Это да.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E__>>>С вашей моделью жопочасов проблема была бы решена только в понедельник утром.

AV>>Ты точно меня не путаешь с кем-то другим? А то я не сторонник подхода жопочасов.

E__>Я тебе ответил, но писал эту фразу оппонентам. Они это ведь тоже прочитают.

Аааа, тогда принимается.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>Ну, есть сомнения что в таком случае именно затраты на коммуникации являются критическим моментом. Что-то сильно изменится если обе стороны будут пересекаться в течении длительного времени? Просто надо рассматривать на промежуток чуть более чем один день работы.

Крайний случай: все работают в одно время — лаг на коммуникации стремиться к нулю. Теперь раздвигаем рабочее время — лаг начинает увеличиваться до максимального значения в одни сутки.

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>И как же решаются подобные проблемы?
AV>У нас? На текущем проекте у меня было пару моментов, когда время фикса было ограничено. Например, была ситуация, когда у нас все было хорошо, а у клиента заказчика не работало как надо. И доступ к машине этого клиента через день был бы закрыт. То есть у нас, с учетом временных разбежек, всего лишь полтора дня. Пришлось эти полтора дня поработать чуть больше.

Это решение какой-то другой проблемы, а не описанной мной.

G>>Хорошо. Меняем в предыдущей фразе предложение Едет себе в метро на "допивает шестое пиво"
AV>Фигово будет. И что?
AV>Взять то же сидение в фиксированое время. Программер работает с 9 до 18 часов. В 17 часов приходят с багом. Ну прикинул программер, что за 5-10 минут не пофиксить. А в 18 часов все равно уходить. Ну и черт с ним, посмотрю завтра.

А то, что это как минимум детерминированно. Если на фикс бага надо 8 часов мы знаем когда он точно будет пофикшен. В другом случае мы не знаем точно когда он будет пофикшен.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>Да, у нас з.п. работников различаются.

Зп у всех различаются. Различаются ли они у вас соответственно работе выполняемой программистами?

AV>Опять же надо смотреть для чего нужно это меряние. Если для з.п., то тут скорее надо смотреть на то, на какие условия согласны стороны (работник и работодатель). Если какая-то из сторон не согласна со сложившимся положением, то надо садиться за стол переговоров. И знаешь, при этом мне в принципе по барабану сколько там зарабатывает Вася.

Что значит на что согласны? Вот есть у тебя 10 работников. Как определять кому сколько платить если ты не знаешь кто сколько работы делает?

AV>А какая разница за сколько человек сделал необходимый объем работ? Вот просидели два человека 5 дней по 8 часов. Каждый выполнил те задачи, что стояли перед ними. И что дальше? Какая разница, если то же самое они сделали за те же 5 дней, но один при этом тратил на это 8 часов в день, а другой — всего лишь по 6?

Разница в том, что "необходимый объем работ" для каждого из них разный.

AV>>> Гораздо продуктивнее анализировать результаты деятельности программиста, и на их основании делать выводы.
G>>ТАк одно другому не мешает, а помогает.
AV>И как же помогает знание "просиженного времени"?

Я уже писал об этом. Как ты будешь сравнивать людей делающих разное количество разных задач за разное время? Надо какие-то показатели уметь приводить к общему знаменателю.
Если ты умеешь формально померять сложность задач — то можно уравнивать это. А если не умеешь?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

Ну вот у меня на работе стоит в качестве основной ОС Win2008R2 т.к. пишем софт именно под неё.
Хочу я для решения каких то своих задач поставить туда твою софтину. И что получается? Легально купленный софт автоматом лишается поддержки?
Нехорошо выходит.

TL>Как минимум, достаточно. История примерно та же: "я читал(-а) что один товарищ поставил своей сестре вин2003 сервер вместо ХП и у нее после этого ни один вирус не завелся! (на компе, в смысле

) — так ты и мне поставь!" (к) Ответ один: "ставь" (к)

дык чистая истина

TL>

Мине за это денюжку не плотят.
По идее тебе денежку платят за то, что писанный тобой софт работает везде где надо кастомеру, не?

CC>>В драйверах между серверной и юзерской виндой различий не сильно много и они локализованы в паре "областей".
L>Угу. Всего-то расширенный доступ к памяти и отсутствие прямой поддержки производителем драйвера именно как версии под серверную винду.
Это ты про что? Я почему то считал что производитель драйвера в случае с твоим продуктом это ты и есть.

TL>Мне на это в основном класть — я тупо не хочу с этим заморачиваться. Зачем мне это? Если после установки серверной версии по совету "крутого младшего брата-кулхацкера" у них вдруг отпадает любимый сканер, фотик, и видеокамера, а с игрушками тоже непонятки какие творятся, потому как видяха тоже не совсем правильно стала — я посылаю в сад. Ибо нефиг.
Такого я давно не встречал. А как ты понимаешь я в основном контактирую с серверными виндами. Все проблемы (2-3 за всё время) были строго изза криворукости производителя. К слову сказать у них и под ХР не всегда работало.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>>И как же решаются подобные проблемы?
AV>>У нас? На текущем проекте у меня было пару моментов, когда время фикса было ограничено. Например, была ситуация, когда у нас все было хорошо, а у клиента заказчика не работало как надо. И доступ к машине этого клиента через день был бы закрыт. То есть у нас, с учетом временных разбежек, всего лишь полтора дня. Пришлось эти полтора дня поработать чуть больше.

G>Это решение какой-то другой проблемы, а не описанной мной.

Как бы я действовал в описанной тобой ситуации я уже писал. Если бы был в состоянии (не был бы пьяным или что-то подобное), то начал бы рассматривать проблему в тот же день. И договорился бы о том, как будем работать в следующие дни.

G>>>Хорошо. Меняем в предыдущей фразе предложение Едет себе в метро на "допивает шестое пиво"
AV>>Фигово будет. И что?
AV>>Взять то же сидение в фиксированое время. Программер работает с 9 до 18 часов. В 17 часов приходят с багом. Ну прикинул программер, что за 5-10 минут не пофиксить. А в 18 часов все равно уходить. Ну и черт с ним, посмотрю завтра.

G>А то, что это как минимум детерминированно. Если на фикс бага надо 8 часов мы знаем когда он точно будет пофикшен. В другом случае мы не знаем точно когда он будет пофикшен.

Отнюдь, я скажу что на фикс нужно 9 часов. И последний час спокойно досижу. И завтра начну фиксить и потрачу эти самые пресловутые 8 часов. Да и в остальное время не напрягался бы. Ибо мне всего лишь платят за часы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Тут на перекуре подумалось

G>А то, что это как минимум детерминированно.

Да, тут возможно большая детерменированость. Но скорее всего это будет за счет увеличения времени в целом.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

E__>Продавцы магазина тоже приходят как минимум к открытию, а чаще раньше. Работа у них такая: если продавец придет через пару-тройку часов после времени открытия, то магазин потеряет деньги. Работа программиста редко связана с кем-то еще, потому смысла ехать в час пик вместе со всеми в таких случаях глупо.

В Европе программисты обычно работают с 9, а в Лондоне — часто и с 8. И дело не в завязанности на кого-то, а "тут так принято".

24.09.2010 19:47, genre пишет:
>
> как-то странно, не?
Нет.

Posted via RSDN NNTP Server 2.1 beta

25.09.2010 0:22, ambel-vlad пишет:
>
> А если сделать примерно так. Есть команда А и команда Б. Команда А своим
> вечером говорит команде Б, что ей завтра нужно будет вот та вот
> загогулина. Пока команда А спит, другая сторона делает эту загогулину. И
> в свою очередь говорит, что ей в свою очередь надо будет что-то другое.
> И меняются местами. Где здесь будет лаг?
>
> Но это если жить только одним днем. Если же оперировать несколько более
> крупными объемами, то вклад этих лагов еще меньшим становится.
Меня поражает, что такие простейшие вещи приходится разжевывать.

Posted via RSDN NNTP Server 2.1 beta

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

>> А если сделать примерно так. Есть команда А и команда Б. Команда А своим
>> вечером говорит команде Б, что ей завтра нужно будет вот та вот
>> загогулина. Пока команда А спит, другая сторона делает эту загогулину. И
>> в свою очередь говорит, что ей в свою очередь надо будет что-то другое.
>> И меняются местами. Где здесь будет лаг?
>>
>> Но это если жить только одним днем. Если же оперировать несколько более
>> крупными объемами, то вклад этих лагов еще меньшим становится.
V>Меня поражает, что такие простейшие вещи приходится разжевывать.

Не все так просто. Это кажется элементарным, когда сам прошел через такое. Тем более, что и ты и я прекрасно знаем каково работать с моим нынешним и твоим бывшим боссом. Далеко не все прошли такую школу.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>И толку? Вот Вася за 8 часов сделал один модуль. Петя — 5 модулей. Как будем приводить к общему знаменателю? Будем рассматривать сложности модулей?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Для команд работающих в стиле "как сделаем, так и отдадим клиенту" работает и суточный лаг.
AV>Максимум суточный лаг. Если же планировать более чем на один день, то лаг уменьшается.

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

G>>Ну и для большинства приемлимый лаг где-то в середине. А срок не важен, потому что лаг копится.
AV>Если нормально работать, то лаг не копится.

Нормально это как? И за счет чего он не будет копиться?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>Да, тут возможно большая детерменированость. Но скорее всего это будет за счет увеличения времени в целом.

Возможно за счет небольшого увеличения времени. Но определенность зачастую гораздо важнее.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

>> как-то странно, не?
V>Нет.

То что ты сам себе противоречишь это не странно?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>>Да, тут возможно большая детерменированость. Но скорее всего это будет за счет увеличения времени в целом.

G>Возможно за счет небольшого увеличения времени.

Насчет "небольшого" можно и поспорить. Смотря что считать "небольшим"

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>>Для команд работающих в стиле "как сделаем, так и отдадим клиенту" работает и суточный лаг.
AV>>Максимум суточный лаг. Если же планировать более чем на один день, то лаг уменьшается.

G>Интересно за счет чего. Вот запланировал ты работ на неделю и на второй день у тебя вылез баг какой-нибудь, который надо обсуждать. И?

И все. Все работы остановились. Что-то неладно с проектом в этом случае.

G>>>Ну и для большинства приемлимый лаг где-то в середине. А срок не важен, потому что лаг копится.
AV>>Если нормально работать, то лаг не копится.

G>Нормально это как? И за счет чего он не будет копиться?

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>И толку? Вот Вася за 8 часов сделал один модуль. Петя — 5 модулей. Как будем приводить к общему знаменателю? Будем рассматривать сложности модулей?

G>именно сложности. если мы знаем, что васин модуль сложнее всех петиных, то ясно что вася работает лучше чем петя.

Нет, не ясно. Как ты определишь, что васин модуль сложнее всех пяти петиных? Но даже если и так, то как определить насколько больше Вася должен получать Пети?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>Да, может так случиться, что по хожу работы выясниться, что мне надо у них что-то уточнить, а там уже спят. Ничего страшного. Отложу это до вечера, а сам продолжу работать над другими частями. Такие затыки ничем не отличаются от подобных проблем при работе внутри команды.

Это верно для достаточно больших сроков и хорошего параллелизма. А если срок допустим 2-3 недели и нужно сделать вот конкретно эту часть?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

E__>А я-то, дурак, считал, что нужно судить не по сложности, а по бизнес важности модуля.

При оценке качества работы конкретного программиста? Конечно по сложности. А как иначе?

E__>Учитывая, что программеры часто любят сложные, но иногда не особо нужные вещи.

Вот потому и нужен менеджер.

E__>При этом человек, который реализует простой, но очень нудный в реализации, но при этом очень нужный модуль, сделает куда больше,

Вот это почему? ДЛя развития проекта — да, по собственному вкладу — нет. Иначе можно считать, что 99% вклада в бизнес фирмы вносят сейлзы, их бизнес важность намного выше программеров.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>именно сложности. если мы знаем, что васин модуль сложнее всех петиных, то ясно что вася работает лучше чем петя.

AV>Нет, не ясно.

Ну яснее чем если бы они сделали это еще и за разное время, правда?

AV>Как ты определишь, что васин модуль сложнее всех пяти петиных?

Ну это отдельный вопрос.

AV>Но даже если и так, то как определить насколько больше Вася должен получать Пети?

В идеальном мире — пропорционально количеству работы в месяц.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>>именно сложности. если мы знаем, что васин модуль сложнее всех петиных, то ясно что вася работает лучше чем петя.

AV>>Нет, не ясно.

G>Ну яснее чем если бы они сделали это еще и за разное время, правда?

Неа. Не вижу разницы. Если проект завершен в установленные сроки.

AV>>Как ты определишь, что васин модуль сложнее всех пяти петиных?

G>Ну это отдельный вопрос.

А без ответа на этот вопрос все мерялки становятся пустым звуком.

AV>>Но даже если и так, то как определить насколько больше Вася должен получать Пети?

G>В идеальном мире — пропорционально количеству работы в месяц.

Вот только еще бы придумать как объективно мерять это кол-во. Да и опять же, что считать работой. Еще очень многое зависит от того, что ждут от конкретного работника. Знаю одну компанию. Так в ней, например, есть человека 2-3, которые могут месяц или дальше больше ничего не делать. Но когда приходится сделать кое-что хитрозавернутое, то именно они бросаются на эти задачи. Не, эти ребята работают и когда таких задач нет. Но опять же, по достаточно свободному графику. Ну и как будем определять из з.п.?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>Нефиксированный рабочий день тоже вполне может давать прекрасную определенность. Нефиксированный график не означает что каждый творит что хочет.

G>Не означает. Но и определенности не добавляет. Тем более прекрасной.

Да, все зависит от того, как устроен процесс изнутри, какие отношения сторон. Это касается как фиксированного графика работы, так и не фиксированного.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>>Как ты определишь, что васин модуль сложнее всех пяти петиных?
G>>Ну это отдельный вопрос.
AV>А без ответа на этот вопрос все мерялки становятся пустым звуком.

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

AV>Вот только еще бы придумать как объективно мерять это кол-во. Да и опять же, что считать работой. Еще очень многое зависит от того, что ждут от конкретного работника. Знаю одну компанию. Так в ней, например, есть человека 2-3, которые могут месяц или дальше больше ничего не делать. Но когда приходится сделать кое-что хитрозавернутое, то именно они бросаются на эти задачи. Не, эти ребята работают и когда таких задач нет. Но опять же, по достаточно свободному графику. Ну и как будем определять из з.п.?

Ну значит этим людям платят за какие-то особые умения. Но это исключение из правил.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>Это верно для достаточно больших сроков и хорошего параллелизма. А если срок допустим 2-3 недели и нужно сделать вот конкретно эту часть?

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

ну то есть например пн-вт выпадают, ничего не делаем, а потом в ср-чт-пт за 5 дней сразу работаем? сомнительное удовольствие.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>>>Это верно для достаточно больших сроков и хорошего параллелизма. А если срок допустим 2-3 недели и нужно сделать вот конкретно эту часть?

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

G>ну то есть например пн-вт выпадают, ничего не делаем, а потом в ср-чт-пт за 5 дней сразу работаем? сомнительное удовольствие.

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>>>Как ты определишь, что васин модуль сложнее всех пяти петиных?
G>>>Ну это отдельный вопрос.
AV>>А без ответа на этот вопрос все мерялки становятся пустым звуком.

G>ну например тот кто раздает задачи старается делать это одинаковыми порциями на основании своего опыта.

То есть, примерно на глаз. Да?

AV>>Вот только еще бы придумать как объективно мерять это кол-во. Да и опять же, что считать работой. Еще очень многое зависит от того, что ждут от конкретного работника. Знаю одну компанию. Так в ней, например, есть человека 2-3, которые могут месяц или дальше больше ничего не делать. Но когда приходится сделать кое-что хитрозавернутое, то именно они бросаются на эти задачи. Не, эти ребята работают и когда таких задач нет. Но опять же, по достаточно свободному графику. Ну и как будем определять из з.п.?

G>Ну значит этим людям платят за какие-то особые умения. Но это исключение из правил.

Очень уж сообразительные ребята. Да, они исключение. Но не такое уж редкое.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>ну например тот кто раздает задачи старается делать это одинаковыми порциями на основании своего опыта.
AV>То есть, примерно на глаз. Да?

да. предваряя следующий вопрос — разное время за которое эти таски были сделаны это повод задуматься. и уточнять собственные оценки на следующий раз.

G>>Ну значит этим людям платят за какие-то особые умения. Но это исключение из правил.
AV>Очень уж сообразительные ребята. Да, они исключение. Но не такое уж редкое.

2-3 на компанию — довольно редкое.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>Это что ж такое надо утворить, чтобы процесс мертво стопнулся на первых минутах. Тут уж надо смотреть что надо подправить в консерватории.

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

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

Здесь большая детерминированность. Время на решение задачи == времени на девелопмент + время на коммуникации.
В другом случае еще возникает случайная поправка на разный часовой пояс/рабочее время/итд.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

У меня уже ощущение, что мы на второй круг пошли

И пора либо резюмировать к чему пришли, либо сворачиваться.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>>Это что ж такое надо утворить, чтобы процесс мертво стопнулся на первых минутах. Тут уж надо смотреть что надо подправить в консерватории.

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

Вот про это я и говорил выделенное выше.

Кстати, ты так и не объяснил откуда взялся простой в два дня (пн-вт).

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

G>Здесь большая детерминированность. Время на решение задачи == времени на девелопмент + время на коммуникации.
G>В другом случае еще возникает случайная поправка на разный часовой пояс/рабочее время/итд.

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

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>>ну например тот кто раздает задачи старается делать это одинаковыми порциями на основании своего опыта.
AV>>То есть, примерно на глаз. Да?

G>да. предваряя следующий вопрос — разное время за которое эти таски были сделаны это повод задуматься. и уточнять собственные оценки на следующий раз.

И что дальше? Положим Вася доволен текущими нагрузками и з.п. И что дальше в твоем случае? В моем случае все стороны довольны текущим status quo. Вася получает удовлетворяющую з.п. Работодатель вовремя и с заранее известными расходами/доходами выполняет проект

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>У меня уже ощущение, что мы на второй круг пошли

Есть такое.

G>И пора либо резюмировать к чему пришли, либо сворачиваться.

Ну в предыдущем сообщении я небольшой личный вывод уже написал.

Про взаимосвязь детерминированности и фиксированности графика

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>И что дальше? Положим Вася доволен текущими нагрузками и з.п. И что дальше в твоем случае? В моем случае все стороны довольны текущим status quo. Вася получает удовлетворяющую з.п. Работодатель вовремя и с заранее известными расходами/доходами выполняет проект

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>Вот про это я и говорил выделенное выше.

Ну а что ты можешь подправить в консерватории в данном случае? Люди бывают ошибаются.

AV>Кстати, ты так и не объяснил откуда взялся простой в два дня (пн-вт).

В пн утром я нашел проблему. Написал письмо и в 17-00 утопал домой. В 18-00 очнулся клиент и задумался что и как. и у него возник вопрос ко мне. и он задал мне его в 17-00 следующего дня.

AV>Я уже давно пришел к выводу, что детерминированость никак не зависит от того фиксированный график или он плавающий.

Ну вот выше непредсказуемый лаг вылез.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

E__>Здравствуйте, Glоbus, Вы писали:

G>>Я украинский тимлид

E__>Один только вопрос.
E__>Работники финансово заинтересованы выполнять работу?
E__>Ну, то есть, получают ли они профит с вовремя качественно реализованной задачи? Нет? Тогда все логично.

Заинтересованы: если они не выполняют работу вовремя и качественно, и при этом делают это систематически, то их банально увольняют

Учитывая то, что контора в которой я ща работаю, дает з/п выше рыночной, это ощутимая потеря

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

AV>Есть команда А и команда Б. Команда А своим вечером говорит команде Б, что ей завтра нужно будет вот та вот загогулина. Пока команда А спит, другая сторона делает эту загогулину
На практике получается так, что во время разработки загогулины (если она совсем не примитивная) у команды Б возникают вопросы, на которые ответить некому. В результате или делают загогулину не того калибра, либо ждут команды А.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

AV>>Вот про это я и говорил выделенное выше.

G>Ну а что ты можешь подправить в консерватории в данном случае? Люди бывают ошибаются.

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

AV>>Кстати, ты так и не объяснил откуда взялся простой в два дня (пн-вт).

G>В пн утром я нашел проблему. Написал письмо и в 17-00 утопал домой. В 18-00 очнулся клиент и задумался что и как. и у него возник вопрос ко мне. и он задал мне его в 17-00 следующего дня.

Аааа, ты это про фиксированный график. Не удивлен. В случае гибкого графика — максимум день потеряем

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>Есть команда А и команда Б. Команда А своим вечером говорит команде Б, что ей завтра нужно будет вот та вот загогулина. Пока команда А спит, другая сторона делает эту загогулину
O>На практике получается так, что во время разработки загогулины (если она совсем не примитивная) у команды Б возникают вопросы, на которые ответить некому. В результате или делают загогулину не того калибра, либо ждут команды А.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>И что дальше? Положим Вася доволен текущими нагрузками и з.п. И что дальше в твоем случае? В моем случае все стороны довольны текущим status quo. Вася получает удовлетворяющую з.п. Работодатель вовремя и с заранее известными расходами/доходами выполняет проект

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

Угу. И первое что придется выдумывать — как сравнить сложность/объем задач.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>Проект состоит из кучи загогулин, и можно заняться другими.
Это если вы релизите раз в год.

AV>В случае гибкого, мы можем играть временем работы.
Играть временем работы? Т.е. человек рассчитывал ночь погулять, потом прийти, как обычно к 3 дня, а ты ему вечером звонишь и говоришь, что надо быть на работе завтра в 8 утра? Такой подход на порядок хуже фиксированного графика.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

AV>>Проект состоит из кучи загогулин, и можно заняться другими.
O>Это если вы релизите раз в год.

Отнюдь, релизим чаще. Но, конечно, не пару раз в неделю.

AV>>В случае гибкого, мы можем играть временем работы.
O>Играть временем работы? Т.е. человек рассчитывал ночь погулять, потом прийти, как обычно к 3 дня, а ты ему вечером звонишь и говоришь, что надо быть на работе завтра в 8 утра?

Что в этом ужасного если человек не против? Тем более, что это исключительная ситуация.

O>Такой подход на порядок хуже фиксированного графика.

И чем же фиксированный график лучше? В этом случае и будут накапливаться лаги и прочее. Даже в пределах одной команды.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>Что в этом ужасного если человек не против? Тем более, что это исключительная ситуация.
В исключительном ситуации криминала нет, плохо, когда это становится правилом.

AV>И чем же фиксированный график лучше?
Тем, что работник четко знает когда ему идти на работу и соответственно может планировать внерабочее время.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

AV>>>Не был бы так категоричен. Зависит от проекта, от того как поставлена работа над проектом.
O>>Да хоть как поставлена. Неудобно.

AV>Да ты шо? Образумь нас. А то мы уже более года на проекте где между нашей командой и командой заказчика 10 часов разбежки.

Я вот находился как с одной стороны так и с другой. В Мск в итоге сдвинул график с 4-х до 11 вечера +/-, народ, который меньше от заказчика зависил — с 12 до 8.

Когда уже здесь индусами рулил митинги в 7 утра обычное дело, а в 11-12 их уже нет на работе. Создавалось ощущение, что финансового выигрыша от оффшора нет никагого.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>>>>Не был бы так категоричен. Зависит от проекта, от того как поставлена работа над проектом.
O>>>Да хоть как поставлена. Неудобно.

AV>>Да ты шо? Образумь нас. А то мы уже более года на проекте где между нашей командой и командой заказчика 10 часов разбежки.

A>Я вот находился как с одной стороны так и с другой. В Мск в итоге сдвинул график с 4-х до 11 вечера +/-, народ, который меньше от заказчика зависил — с 12 до 8.

Мы вообще практически не сдвигаем. Обычно начинаем работать с 10 часов утра. Но если необходимо, то можем позволить себе сдвиг в ту или иную сторону.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>Что в этом ужасного если человек не против? Тем более, что это исключительная ситуация.
O>В исключительном ситуации криминала нет, плохо, когда это становится правилом.

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

AV>>И чем же фиксированный график лучше?
O>Тем, что работник четко знает когда ему идти на работу и соответственно может планировать внерабочее время.

При нефиксированном графике точно так же можно планировать внерабочее время. К тому же далеко не каждая проблема требует немедленного подхода к компу. Такие ситуации гораздо реже, чем ситуации когда надо поговорить 10-15 минут. А с этим проблем вообще нет. Есть скайп, есть редирект на мой сотовый. А потрындеть по сотовому я могу практически в любой обстановке. Ну за исключением времени когда я сплю.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

L>>Никакой спонтанной необходимости обсуждения технических деталей не бывает. Бывает плохой менеджмент, способный убить эффективность на корню.
L>>Все обсуждения, для которых требуется присутствие более чем одного человека, необходимо планировать, причем совсем не по той причине, что народ когда хочет, тогда и приходит.

G>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.

Те кто такое аутсорсит — ССЗБ. В таких случаях разраб/саппорт частенько сидит бок о бок с пользователем.

В менее критических случаях готовность 24/7 оказаться быстро у компа не редкое требование. Не можешь — заранее ищи замену. Как-то так.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

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

А, тут была просьба работодателей ответить.
Я не работодатель.

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

AV>>>Кстати, ты так и не объяснил откуда взялся простой в два дня (пн-вт).

G>>В пн утром я нашел проблему. Написал письмо и в 17-00 утопал домой. В 18-00 очнулся клиент и задумался что и как. и у него возник вопрос ко мне. и он задал мне его в 17-00 следующего дня.

AV>Аааа, ты это про фиксированный график. Не удивлен. В случае гибкого графика — максимум день потеряем

Я как раз про свободный.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

AV>>>Аааа, ты это про фиксированный график. Не удивлен. В случае гибкого графика — максимум день потеряем
G>>Я как раз про свободный.
DM>Скоро третий круг пойдет.
DM>Обсуждать бессмысленно, не доходит.

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

DM>Когда будет семья и дети — возможно, что-то поменяется. Иначе очень жаль семью.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AV>>>>Кстати, ты так и не объяснил откуда взялся простой в два дня (пн-вт).

G>>>В пн утром я нашел проблему. Написал письмо и в 17-00 утопал домой. В 18-00 очнулся клиент и задумался что и как. и у него возник вопрос ко мне. и он задал мне его в 17-00 следующего дня.

AV>>Аааа, ты это про фиксированный график. Не удивлен. В случае гибкого графика — максимум день потеряем

G>Я как раз про свободный.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

FR>>Кстати не факт, что даже отрабатывая и не халтуря 40 часов они будут делать в два раза больше работы.
FR>>У меня например максимальная производительность при отработке 4 — 6 часов в день.
У меня если "мысль попёрла" то и 10 получалась, забыв про обед и задержавшись чтоб дописать, бо когда уже прёт то хочется дописать до какого то логического завершения.
Особенно если работаю из дому — там не надо на дорогу тратить время и пожрать занимает 10 минут а не час.
Да и работая из дому "задержаться на работе" куда проще по всем параметрам. RDP сессию закрыл — и ты уже дома. Вот она, давешняя мечта о телепортации!

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>Вот на этом месте у меня возникают серьезные сомнения.
G>Любой человек кто пытался мало мальски сложный проект вести с помощью диаграмм Ганта иначе как матом о них не вспоминает.
На моей прошлой фирме пытались внедрить.
Получился полный отстой.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>Ну то есть пришел Вася в 7 утра на работу, в 5 ушел. Едет себе в метро И тут звонит тестер и разворачивает его обратно на работу?
Доезжает до дома, VPN + RDP на работу и вот он уже на рабочем месте.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

FR>>>Кстати не факт, что даже отрабатывая и не халтуря 40 часов они будут делать в два раза больше работы.
FR>>>У меня например максимальная производительность при отработке 4 — 6 часов в день.
CC>У меня если "мысль попёрла" то и 10 получалась, забыв про обед и задержавшись чтоб дописать, бо когда уже прёт то хочется дописать до какого то логического завершения.

Это да, можно и по 12 часов изредка работать, но постоянно это невозможно и после этого практически всегда гарантирован откат, поработав скажем
неделю в таком режиме следующую неделю будешь работать очень плохо и в среднем будет не больше тех же 4 — 6 часов в день.

CC>Особенно если работаю из дому — там не надо на дорогу тратить время и пожрать занимает 10 минут а не час.
CC>Да и работая из дому "задержаться на работе" куда проще по всем параметрам. RDP сессию закрыл — и ты уже дома. Вот она, давешняя мечта о телепортации!

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

G>>Ну то есть пришел Вася в 7 утра на работу, в 5 ушел. Едет себе в метро И тут звонит тестер и разворачивает его обратно на работу?
CC>Доезжает до дома, VPN + RDP на работу и вот он уже на рабочем месте.

Ну вот лично у меня есть привычка ходить в бассейн/кино/гости/к девушке/другие развлечения по вкусу после работы.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

27.09.2010 12:25, genre пишет:
>
> Вот на этом месте у меня возникают серьезные сомнения.
> Любой человек кто пытался мало мальски сложный проект вести с помощью
> диаграмм Ганта иначе как матом о них не вспоминает.
Это говорит лишь о яйцах плохого танцора.

Posted via RSDN NNTP Server 2.1 beta

29.09.2010 21:49, CreatorCray пишет:
>
> На моей прошлой фирме пытались внедрить.
> Получился полный отстой.
Ты не поверишь, я знаю конторы, где С++ пытались внедрить и тоже
получался полный отстой.

Posted via RSDN NNTP Server 2.1 beta

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

FR>Это да, можно и по 12 часов изредка работать, но постоянно это невозможно и после этого практически всегда гарантирован откат, поработав скажем
FR>неделю в таком режиме следующую неделю будешь работать очень плохо и в среднем будет не больше тех же 4 — 6 часов в день.
Дык постоянно и не надо и не приходится.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>>Ну то есть пришел Вася в 7 утра на работу, в 5 ушел. Едет себе в метро И тут звонит тестер и разворачивает его обратно на работу?
CC>>Доезжает до дома, VPN + RDP на работу и вот он уже на рабочем месте.
G>Ну вот лично у меня есть привычка ходить в бассейн/кино/гости/к девушке/другие развлечения по вкусу после работы.
В таких случаях сеанс RDP откладывается на несколько попозже.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

G>>Вот на этом месте у меня возникают серьезные сомнения.
G>>Любой человек кто пытался мало мальски сложный проект вести с помощью диаграмм Ганта иначе как матом о них не вспоминает.
CC>На моей прошлой фирме пытались внедрить.
CC>Получился полный отстой.

Извините, а какие диаграммам Ганта альтернативы? вообще без планирования жить?

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

G>>>Вот на этом месте у меня возникают серьезные сомнения.
G>>>Любой человек кто пытался мало мальски сложный проект вести с помощью диаграмм Ганта иначе как матом о них не вспоминает.
CC>>На моей прошлой фирме пытались внедрить.
CC>>Получился полный отстой.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

O>>Извините, а какие диаграммам Ганта альтернативы? вообще без планирования жить?
CC>А гантом что нить чколь либо сложное не выразишь. Полностью оторванная от реалий картина получится.

Стоп-стоп-стоп
Что использовать вместо Ганта? где альтернатива? Не вижу ее.

Здравствуйте, genre, Вы писали:

G>РУководитель мотивирован ставить реальные сроки.
совершенно неправильно. Руководитель мотивирован ставить наименьшие сроки, чтобы получить за проект денег больше и скорее. А если Руководитель (вестимо, группы программистов) не является самым главным — то со сроками все еще хуже.

Ситуация из жизни: менеджер по продажам продает некий штучный проект со сроком исполнения в 2 месяца (чтобы получить премию). Проект требует серьезной инженерной работы (адаптации под конкретного покупателя), а завод работает по нормам производства (бумаги, сроки, техзадания и прочее). В результате, проект сдается и продается, завод получает бабло, менеджер — премию, моя мать (инженер-конструктор, что-то типа руководителя группы на этом проекте) — почти сердечный приступ. Было реально страшно за нее.

Здравствуйте, genre, Вы писали:

AV>>Но даже если и так, то как определить насколько больше Вася должен получать Пети?

G>В идеальном мире — пропорционально количеству работы в месяц.
а разве у них это количество разное? Не 5*8*4 часов у каждого?

Здравствуйте, genre, Вы писали:

G>Здравствуйте, landerhigh, Вы писали:

L>>Никакой спонтанной необходимости обсуждения технических деталей не бывает. Бывает плохой менеджмент, способный убить эффективность на корню.
L>>Все обсуждения, для которых требуется присутствие более чем одного человека, необходимо планировать, причем совсем не по той причине, что народ когда хочет, тогда и приходит.

G>Да конечно. Нашли критикал багв 11 утра, а человек девелопивший этот код придет к 16. А разобраться с нуля займет еще больше времени. А у клиента минута простоя в тысячах долларов исчисляется.
ага. нашли баг в 11 утра, а чел, девелопивший этот код, взял отгул на этот день. Согласно всем КЗоТам, еще вчера.

...
O>В том, что те, кто находят в 20 вечера не работают. А если и работают, то это еще один пример бардака, устроенного излишне свободным рабочим графиком.
жизнь за пределами америки существует, поверь! И я часто получаю баг-репорты в 19-20 часов по моему локальному времени.

ты прав — во всем виноват свободный график. перевести всех американцев на наше локальное время.

Здравствуйте, genre, Вы писали:

G>Здравствуйте, ambel-vlad, Вы писали:

AV>>Какие претензии к средствам коммуникации? У нас на проекте нет никаких затыков по причине разного времени. Да, иногда по ходу работы возникают моменты, когда хочется поговорить с другой стороной, но там уже давно спят. Но такое возникает достаточно редко и не носит критических характер.

G>К средствам никаких претензий. Телефон, аська, почта и видеоконференции — все работает прекрасно.

G>Проблема в том, что приходя на работу скажем в 11 утра ты можешь уткнуться в проблему требующую участия клиента. А клиент на работу придет часов в 5 вечера. То есть работа над фичей стоит. А фича, допустим, обещана через неделю. В итоге ты вынужден следующий раз закладывать сроки на вот эти коммуникации.
а вот тут — спасибо графику рабочего времени. Ибо ты ДОЛЖЕН отработать 8 часов времени начиная с 11. И плевать, что сегодня твой день пройдет не ильно полезно. Как у меня было: копался в логах весь день, пытаясь выяснить, что за ошибка произошла у наших коллег из америки. А когда он появился в онлайне (19.30) я уже не очень и в состоянии работать, ибо целый день делал что-то.

Здравствуйте, ambel-vlad, Вы писали:

AV>Здравствуйте, genre, Вы писали:

G>>ДА, а теперь представим, что в ситуации а он еще и поздно пришел, и когда он багу отдал тестеру, тот уже ушел домой. И еще пару таких итераций. В итоге набежит задержка в пару дней, которой могло бы не быть.

AV>Что мешает в случае таких архикритических багов временно договорится участникам об общем времени?
как что? фиксированный рабочий режим. Ибо какая работа в 10 часов вечера, если люди уже 10 часов как в офисе? и завтра им к 8 вставать и ехать в офис?

Здравствуйте, March_rabbit, Вы писали:

G>>В идеальном мире — пропорционально количеству работы в месяц.
M_>а разве у них это количество разное? Не 5*8*4 часов у каждого?

Я если честно уже позабыл контекст беседы.

Но кажется, что речь шла про количество работы, а не потраченного времени.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, March_rabbit, Вы писали:

G>>РУководитель мотивирован ставить реальные сроки.
M_>совершенно неправильно. Руководитель мотивирован ставить наименьшие сроки, чтобы получить за проект денег больше и скорее. А если Руководитель (вестимо, группы программистов) не является самым главным — то со сроками все еще хуже.

Глупый — да. Разумный мотивирован в повышении продуктивности команды.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, genre, Вы писали:

G>Здравствуйте, alzt, Вы писали:

A>>Если ошибка у него вылезет не в 11 утра, а в 7 вечера, то есть вероятность, что люди не разбежались по домам, а только с обеда пришли и рабочий день в самом разгаре, просто немного смещён.

G>Верно. Если они все на работе. А не в разнобой. Проблема-то именно в этом.
G>По сути совершенно все равно днем или ночью люди работают — лишь бы все одновременно.
получается, что как раз наоборот. Если бага всплыла в 19:01, то все уже свалили. А если есть разнобой — то есть вероятность того, что хоть кто-то еще в офисе. А тут уже появляется вероятность, что этот чел не сильно далек от темы или может связаться с автором по телефону и после консультации взяться за ремонт.

Здравствуйте, March_rabbit, Вы писали:

G>>>ДА, а теперь представим, что в ситуации а он еще и поздно пришел, и когда он багу отдал тестеру, тот уже ушел домой. И еще пару таких итераций. В итоге набежит задержка в пару дней, которой могло бы не быть.

AV>>Что мешает в случае таких архикритических багов временно договорится участникам об общем времени?
M_>как что? фиксированный рабочий режим. Ибо какая работа в 10 часов вечера, если люди уже 10 часов как в офисе? и завтра им к 8 вставать и ехать в офис?

Ну тут вообще-то речь шла про договориться при нефиксированном графике.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, March_rabbit, Вы писали:

M_>получается, что как раз наоборот. Если бага всплыла в 19:01, то все уже свалили. А если есть разнобой — то есть вероятность того, что хоть кто-то еще в офисе. А тут уже появляется вероятность, что этот чел не сильно далек от темы или может связаться с автором по телефону и после консультации взяться за ремонт.

Вероятность обычно хуже предсказуемости

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, shapovalov, Вы писали:

S>Здравствуйте, UVV, Вы писали:

UVV>>Здравствуйте, Eudjinn, Вы писали:

E>>>Ну ладно, мы не наивные, мало кто реально работает 8 часов в день...

UVV>>Я работаю 40 часов в неделю. Именно работаю, поскольку оплата у меня почасовая.
S>как то я слабо представляю как можно все 40 часов работаь без перерыва.

Это невозможно чисто медицински. Плохо, что есть люди, мнящие себя управленцами и не понимающие этого.

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, Armadilio, Вы писали:

A>>Здравствуйте, sharpcoder, Вы писали:

S>>> 4. часть сотрудников, если им предоставить свободу, начинают приходить позже и позже. Обычно со временем начинают приходить к часу, и откровенно не дорабатывать.

A>>платить за результат не пробовали?

B>За строчки кода что ли?
B>Или за пофиксенные баги?
B>Не работает это.

конечно нет — а работает просто держать в офисе народ 8 часов, аки тягловый скот?

Здравствуйте, bkat, Вы писали:

B>Важна прежде всего пресказуемость.
B>Хуже всего, когда никто не знает, когда придет Вася Гибкий
B>и ты постоянно в раздумиях, подождать ли еще с часок, или все же плюнуть и написать ему письмо.
B>Когда есть предсказуемость, тогда можно как-то планировать совместную работу.
B>Гибкость в целом приветствуется, покуда это не мешает другим членам команды.

B>Я лично предпочитаю жесткий график.
B>Мне самому так проще планировать свободное время и я точно знаю,
B>когда я на работе и когда я свободен от работы.

а всё-таки научится именно планировать вы не пробовали?

т.е. пусть приходят когда хотят, главное что в 12.00-12.30 (допустим) у нас собрание по такой-то теме. Собрание объявляется заранее, за пару дней хотя, дабы участники смогли не нарушая своей работы подготовиться.

Соответственно если сотрудник не может подойти, он пишет decline, и тут вы его и спрашиваете, а почему? если причина неудовлетворительная, то объясняете — так и так рабочий день у нас формально с 10, тебе надо быть на этом совещании. Т.е. в этом случае сотрудник нажимает accept.

Если причина важная — сдвигаете совещание.

Итого у всех состояние accept.

если кто-то после accept не пришёл, или опоздал — вот тут можно применить санкции.

Неужели это ТАК сложно для вас?

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, landerhigh, Вы писали:
E>>>1. Спонтанная необходимость обсуждения технических деталей. Возникли вопросы, хочется обсудить, а на рабочем месте нет то одного, то другого. Тот пришел, другой ушел на обед. Другой вернулся с обеда, тот ушел на обед и в таком духе. А теперь представим, что разработчиков, с которыми надо обсуждать что-то (не одновременно, а в разных комбинациях) не двое, а два десятка и все любят гибкий график и не регламентированный обед.
__>госсподи, вы будто не работали никогда
__>вот приходите вы на работу. бац — глюк — приложение падает у кого-то, подтвердились какие-то опасения насчет сырой технологии. нужно принять решение -переписывать на другую или ставить костыли.
__>идем с этим вопросом к начальнику.
__>а его нет. ага
__>потом обед
__>потом приходит начальник, куда-то уходит
__>потом опять приходит, ты ему — вот, значит, есть такая ситуация, либо делаем так — тогда такие минусы, либо так — тогда такие.
__>он тебе — давай менять технологию, значит, посоветуйся с тем чуваком по такому вопросу, он уже делал подобное
__>ищем того чувака
__>его нет
__>пишем, идем домой

__>приходим с утра, начинаем писать, приходит чувак, разговариваем с ним, оказывается нужно было лучше по-другому начинать писать, переписываем заново
__>готово, сами проверяем, — отдаем тестеру
__>а тестера нет — свалил уже
__>на след день приходите на два часа позже тестера, он сидит фигней страдает, пинаете его, он начинает работать, потом обед, он опять убегает, потом че-то поделает — все он уже собирается уходить.
__>несем приложение начальнику — вот, можно выкладывать. а начальника нет. он свалил куда-то уже.

ппц- это у вас реально так? тут как-бы в организации проблема, а не в свободном графике

Здравствуйте, __kot2, Вы писали:

__>вот приходит письмо тестеру. он его когда прочтет? когда чай попьет, когда башорг почитает, когда сходит покурит, когда прочитает еше 5 писем пришедших ему, когда походит поищет по офису что-то..
__>когда он его прочтет, он насколько быстро примется за задачу? а кто его знает? может у него другие задачи скопились и он их захочет сделать сначала? но сначала он еще раз чай попьет, потом пообедать сходит, потом обсудит в коридое что-то с кем-то
__>а когда ты пришел и на месте ему тут же дал все в руки и сказал — это надо сделать сейчас, он тебе дал свое согласие, назвал сроки и тут же приступил, ты тогда можешь расчитывать на определенный результат.

ппц ну и бред?

а про системы багтрекинга, где у каждого бага выставляется приоритет, в соответствие с которым тестеры обрабатывают баги вы не слышали?

ну честное слово, вы какой-то весельчак

Здравствуйте, Nick-77, Вы писали:

G>>Ага. 10 тикетов High 10 Normal, что делать будем?

N7>будем исправлять 10 тикетов high в ЛЮБОМ удобном для нас порядке.

N7>Что тут непонятного?

тут непонятно что например делать если исправление 10 тикетов не влезает в релизный цикл. это например.
остальной миллион ситуаций когда порядок имеет значение оставляю додумать самому.

на это сообщение можешь не отвечать. дискуссия в таком тоне мне не интересна.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Nick-77, Вы писали:

N7>Неужели это ТАК сложно для вас?

Да ты так не переживай.
Ради тебя на все пойдем и под любые капризы подстроимся

Здравствуйте, genre, Вы писали:

G>тут непонятно что например делать если исправление 10 тикетов не влезает в релизный цикл. это например.
G>остальной миллион ситуаций когда порядок имеет значение оставляю додумать самому.

значит в данный релиз заносятся N багов, остальные переносятся на следующий.

остальной миллион ситуацию у тебя тоже из-за нежелания думать и моделировать?

п.с. может хватит тут разыгрывать оскорблённую ранимость уже?

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, Nick-77, Вы писали:

N7>>Неужели это ТАК сложно для вас?

B>Да ты так не переживай.
B>Ради тебя на все пойдем и под любые капризы подстроимся

основы планирования как-бы, о каких капризах тут речь, непонятно

Здравствуйте, Nick-77, Вы писали:

N7>Здравствуйте, bkat, Вы писали:

B>>Здравствуйте, Nick-77, Вы писали:

N7>>>Неужели это ТАК сложно для вас?

B>>Да ты так не переживай.
B>>Ради тебя на все пойдем и под любые капризы подстроимся

N7>основы планирования как-бы, о каких капризах тут речь, непонятно

Думаешь мы не планируем? Хочешь взлянуть на наши планы?

Больше половины собраний на пол года вперед запланированы.
Ты конечно вправе нажимать decline и орагнизатор собрания будет искать подходящее для всех (а не только для тебя) время.
Но если это придется делать постоянно и только потому что тебя постоянно нет в офисе
и никто не знает когда ты там появляешься, то тебя перестанут приглашать вообще.
Скорей всего перестанут вообще рассчитывать на тебя.

А вообще я не про это писал.
Я говорил, что конкретно мне удобен фиксированный график.
Мне так проще планировать свое время (как там насчет основ планирования?).
Вот скажем со мной после 6-ти в любой день можно пойти попить пиво или поиграть в бильярд.
Я это знаю наперед и мне так удобно.
А с тобой когда можно попить пива? В 9 вечера в офисе между билдами?

Здравствуйте, bkat, Вы писали:

B>Больше половины собраний на пол года вперед запланированы.
B>Ты конечно вправе нажимать decline и орагнизатор собрания будет искать подходящее для всех (а не только для тебя) время.

тогда не вижу проблемы — пишешь в комменте мол присутствие обязательно. И усе — кто не пришёл и не представил уважительную причину — санкции.

Помоему всё просто, нет?

B>А вообще я не про это писал.
B>Я говорил, что конкретно мне удобен фиксированный график.
B>Мне так проще планировать свое время (как там насчет основ планирования?).
B>Вот скажем со мной после 6-ти в любой день можно пойти попить пиво или поиграть в бильярд.
B>Я это знаю наперед и мне так удобно.
B>А с тобой когда можно попить пива? В 9 вечера в офисе между билдами?

конкретно кому-то может быть и удобней. Но мне удобней нормальный график, со свободным приходом/уходом.
При этом если назначена встреча, то я распределю своё время так, что буду в офисе и во время встречи не пойду ни на какие обеды и подготовлю материал заранее (если от меня таковой требуется)

Т.е. дисциплина не противоречит свободному графику.

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, Nick-77, Вы писали:

N7>>тогда не вижу проблемы — пишешь в комменте мол присутствие обязательно. И усе — кто не пришёл и не представил уважительную причину — санкции.

B>Кому не обязательно, те и не приглашаются.
B>А вообще никто не обязан присутствовать.
B>Все ведь добровольно.
B>Если тебя приглашают, то не потому что твое присутствие обязательно,
B>а потому что ты был бы полезен. Если ты так не считаешь, то и проблем нету.

ну... эко ты загнул

как опровергающий пример могу привести оценку сроков на релиз — тут присутствие представителей от разработчиков обязательно, что-бы оценить сроки исполнения хотелок, что-бы управленцы могли составить scope задач

Здравствуйте, Nick-77, Вы писали:

N7>как опровергающий пример могу привести оценку сроков на релиз — тут присутствие представителей от разработчиков обязательно, что-бы оценить сроки исполнения хотелок, что-бы управленцы могли составить scope задач

Ну это всего лишь вопрос акцентов.
Единственное, что обязан сделать человек в этом мире — это умереть

Все остальное — дело добровольное.
Ну а такая вещь как "оценка сроков" — это точно вещь добровольная,
в том смысле, что раз тебя пригласили, то просто считают твое мнение ценным.
Не больше и не меньше. Если ты откажешься, то сделают оценку без тебя,
пригласив другого разработчика, который согласится помочь управленцам с оценками.
Даже не сомневайся в этом

17.11.2010 18:21, Nick-77 пишет:
>
> конечно нет — а работает просто держать в офисе народ 8 часов, аки
> тягловый скот?
Да, конечно. И неважно, что код ужасен, продукт сплошь в багах, баги
фиксятся годами, главное весь народ в офисе и упорно "работает"
(по-русски говоря, штаны протирает).
Подытоживается все это фразой: "Мы делаем все, что можем".

Posted via RSDN NNTP Server 2.1 beta

17.11.2010 18:54, Nick-77 пишет:
> решается очевидно что самым критичным ставиться статус critical или
> blocker.
>
> Вопросы?
О. Ты наверное никогда не видел, как русские манагеры в подавляющем
большинстве выставляют приоритет critical почти всем багам.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Nick-77, Вы писали:

N7>значит в данный релиз заносятся N багов, остальные переносятся на следующий.

какие N? что делать если влезло N-2 и осталось времени еще только на один, какой из оставшихся двух выбрать. как учесть зависимости между тасками, как начать с более критичных, чтобы их можно было раньше начать тестировать, итд.

N7>п.с. может хватит тут разыгрывать оскорблённую ранимость уже?

практика показывает, что человек ведуший дискуссию с позиций "все дураки", не приводит никаких разумных аргументов кроме эмоциональных. а на это мне банально жалко времени.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Nick-77, Вы писали:

G>>Могут конечно исправляться в том порядке который устраивает того, кто над ними работает. Но это в идеальном мире. А в реальном мире среди этих 10 high тикетов тоже нужно расставлять приоритеты. И вместо заведения десятков градаций приоритетов (что очевидно не работает) используется метод "Вась, глянь мой тикет первым", что вполне работает в подавляющем большинстве случаев, а исключительные ситуации обрабатываются отдельно уровнем выше.

N7>решается очевидно что самым критичным ставиться статус critical или blocker.

N7>Вопросы?

выделил.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Vzhyk, Вы писали:

V>17.11.2010 18:54, Nick-77 пишет:
>> решается очевидно что самым критичным ставиться статус critical или
>> blocker.
>>
>> Вопросы?
V>О. Ты наверное никогда не видел, как русские манагеры в подавляющем
V>большинстве выставляют приоритет critical почти всем багам.

Ну и кто им злобный баклан?

Здравствуйте, genre, Вы писали:

G>Здравствуйте, Nick-77, Вы писали:

G>>>Могут конечно исправляться в том порядке который устраивает того, кто над ними работает. Но это в идеальном мире. А в реальном мире среди этих 10 high тикетов тоже нужно расставлять приоритеты. И вместо заведения десятков градаций приоритетов (что очевидно не работает) используется метод "Вась, глянь мой тикет первым", что вполне работает в подавляющем большинстве случаев, а исключительные ситуации обрабатываются отдельно уровнем выше.

N7>>решается очевидно что самым критичным ставиться статус critical или blocker.

N7>>Вопросы?

G>выделил.

пример когда нужны подприоритеты в студию.

Здравствуйте, genre, Вы писали:

G>Здравствуйте, Nick-77, Вы писали:

N7>>значит в данный релиз заносятся N багов, остальные переносятся на следующий.

G>какие N? что делать если влезло N-2 и осталось времени еще только на один, какой из оставшихся двух выбрать. как учесть зависимости между тасками, как начать с более критичных, чтобы их можно было раньше начать тестировать, итд.

Вот конкретно тут таки да, можно посовещаться с разработчиками (и, возможно, подвинуть сроки)

п.с. почему я вас должен учить азам управления dev?

Здравствуйте, hrensgory, Вы писали:

>> E__>>Ну честно, не могу я серьезно себе представлять это. У вас там
>> системы документооборота/багофичетрекера нету, что-ли? Зачем этот цирк
>> по утрам?
>>
>> G>Речь шла про scrum daily meeting
>>
>> Все подобные системы, своды правил и прочие инструкции сделаны для
>> обезьян

H>Осторожнее со scrum, несчастный, жрецы Agile уже мастерят твою куклу,
H>чтобы проткнуть её иголками

Скучно мне... Мои товарищи накурились и прутся, а я это не очень люблю, я просто нажрался. Потроллить, да поднять топик, штоле.

А еще хотел поднять тему про протыкание не совсем иголками, но тут не поймут, это в СВ. Обидно.

Здравствуйте, Eudjinn, Вы писали:

D>>Просьба ответить работодателям.
D>>Насколько вам важно, что работник находится на работе строго по часам без плавающего прихода и ухода и с регламентированным обедом? Какие в этом плюсы? Можете дать четкий расчет выгоды компании от этого?
D>>Или наоборот, в чем видите выгоду в ненормированном и нерегламентированном рабочем дне?

E>Достаточно важно, по ряду причин.

E>1. Спонтанная необходимость обсуждения технических деталей. Возникли вопросы, хочется обсудить, а на рабочем месте нет то одного, то другого. Тот пришел, другой ушел на обед. Другой вернулся с обеда, тот ушел на обед и в таком духе. А теперь представим, что разработчиков, с которыми надо обсуждать что-то (не одновременно, а в разных комбинациях) не двое, а два десятка и все любят гибкий график и не регламентированный обед.

Это где ж такое видано? Я так полагаю, в этой конторе нет таких понятий, как аналитик, манагер, тимлид, сеньор? А есть Царь да 20 червей? Максимальное число участников обсуждения, которое я когда-либо видел — это 3 человека (директор — манагер/аналитик, манагер — аналитик/тимлид, тимлид — разработчкики).

E>2. Приходят пара сотрудников, сначала к 10, потом начинают приходить к 10:20, потом к 10:45, потом в 11:15. Сначала раз в две недели, потом два раза в неделю, потом 3 дня из 5. Глядя на них, остальные тоже начинают позволять себе вольности. Через несколько месяцев получаем отдел разработки, где все приходят когда хотят, уходят когда хотят и ходят на обед когда хотят. Хочешь собрать совещание с 3 участниками, и см. пункт 1. Окей, думаете вы, а почему бы не запланировать совещание заранее? На 10 не запланируешь — некоторые приходят к 11. Планируем на 11 — а такая же ерунда, люди отучились приходить вовремя.

Если вы планируете совещания, а ваших подчиненным наплевать на них, то вас просто не уважают.

E>Прелесть работы в одном офисе в том, чтобы упростить и ускорить коммуникации, тем самым ускорить решение вопросов, а с таким подходом, когда нужных людей не соберешь быстро, в чем тогда смысл?

Ну да. Прелесть для того, кто в отдельном кабинете сидит. Что ему до тех, кто вынужден сидеть в вонючих шумных опенспейсах, где даже пернуть негде?

E>В целом, я за гибкий график в разумных пределах (у нас эти разумные пределы обозначены). Проблема в том, что привыкнув к удобству в этих разумных пределах, каждому сотруднику хочется эти пределы расширить, просто потому что удобно вставать не по будильнику, а потому что выспался. И ведь правда, если не выспался — какая эффективность работы будет? А лечь спать вовремя — это скучно, ведь вечером хочется весело провести время.

E>В общем, как-то так.

А вообще, нерегламентированный <> недисциплинированный/безответственный. Если вам так уж нужно провести совещание с 20 участниками к 11 утра, то просто договоритесь об этом заранее.

От:	Eudjinn	http://eudjinn.livejournal.com
Дата:	14.09.10 12:22
Оценка:	27 (7) +8 -3

	От:	landerhigh
	Дата:	14.09.10 12:59
	Оценка:	13 (4) +10 -1

	От:	Eugeny__
	Дата:	21.09.10 14:13
	Оценка:	24 (3) +4

	От:	__kot2
	Дата:	15.09.10 06:01
	Оценка:	1 (1) +9

От:	Eudjinn	http://eudjinn.livejournal.com
Дата:	14.09.10 14:54
Оценка:	38 (6) +3

	От:	hrensgory
	Дата:	20.09.10 10:10
	Оценка:	6 (1) +1 -5

	От:	MescalitoPeyot
	Дата:	21.09.10 06:57
	Оценка:	+2

	От:	BulatZiganshin
	Дата:	15.09.10 10:05
	Оценка:	2 (2) +5

	От:	antonio_banderas
	Дата:	28.09.10 08:32
	Оценка:	13 (3) +3

	От:	8bit
	Дата:	14.09.10 14:36
	Оценка:	1 (1) +3 -1

	От:	sharpcoder
	Дата:	15.09.10 16:19
	Оценка:	24 (3)

	От:	bkat
	Дата:	14.09.10 19:40
	Оценка:	1 (1) +2 -1

	От:	Она На Нас Ий
	Дата:	16.09.10 01:09
	Оценка:	1 (1) -3

	От:	Nik_1
	Дата:	18.09.10 11:42
	Оценка:	1 (1) +1 -2

	От:	avpavlov
	Дата:	14.09.10 15:31
	Оценка:	7 (2) +1

	От:	De-Bill
	Дата:	21.09.10 07:56
	Оценка:	3 (1) +2

От:	Donz	http://donz-ru.livejournal.com
Дата:	20.09.10 11:03
Оценка:	+2 -1

	От:	Uzumaki Naruto
	Дата:	18.11.10 00:18
	Оценка:	8 (1) +1

От:	ilya.buchkin	http://engineering.meta-comm.com/
Дата:	14.09.10 19:02
Оценка:	4 (1) +1

	От:	blackhearted
	Дата:	14.09.10 16:55
	Оценка:	+1 -1

	От:	ambel-vlad
	Дата:	25.09.10 15:54
	Оценка:	+1 -1

От:	Denis Mingulov	http://denis.mingulov.com
Дата:	28.09.10 08:56
Оценка:	-2

	От:	_Dinosaur
	Дата:	15.09.10 07:49
	Оценка:	12 (1)

От:	shapovalov	https://www.yaplex.com
Дата:	14.09.10 15:41
Оценка:	+1

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	15.09.10 09:04
Оценка:	+1

От:	kosmik	http://www.linkedin.com/in/kosmik
Дата:	15.09.10 10:53
Оценка:	+1

От:	мыщъх	http://nezumi-lab.org
Дата:	17.09.10 22:25
Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	22.09.10 05:56
Оценка:

	От:	Злобастик
	Дата:	26.09.11 06:37
	Оценка: