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

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

G>И у тебя это отражено в зарплатах?

Да, у нас з.п. работников различаются.

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

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

G>А вот если нет:
AV>>Я не говорю, что контроля не должно быть. Вот только контроль в виде меряния сколько времени я просиживаю штаны практически бессмысленен.

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

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

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

И как же помогает знание "просиженного времени"?

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


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

Один только вопрос.
Работники финансово заинтересованы выполнять работу?
Ну, то есть, получают ли они профит с вовремя качественно реализованной задачи? Нет? Тогда все логично.

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

G>>Ну то есть пришел Вася в 7 утра на работу, в 5 ушел. Едет себе в метро И тут звонит тестер и разворачивает его обратно на работу?

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

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

Да, цена вопроса _вроде как_ невелика. Порядка 800 тысяч гривень(примерно за выходные, благо точно неизвестно: ни разу не происходило, данные аналитические) +, ну, точнее, минус лояльность клиентов нашей компании.

ЗЫ 800 тысяч гривень это порядка 100 тысяч долларов. Так, подумаешь, копеечки

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

G>>>Ну то есть пришел Вася в 7 утра на работу, в 5 ушел. Едет себе в метро И тут звонит тестер и разворачивает его обратно на работу?

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

E__>Что-то подобное. Вот сегодня как раз была такая ситуация. Только я был еще на работе, а человек уже домой ехал. Я по телефону объяснил проблему, он попросил выслать нужные для решения данные на его мыло. Я спокойно уехал пиво пить. Сейчас приехал домой, зашел — проблема решена. Да, сотрудником из дома. Будет проблема моя — я из дома решу. А сейчас, напоминаю, ночь с пятницы на субботу.

Нормальный подход.

E__>С вашей моделью жопочасов проблема была бы решена только в понедельник утром.

Ты точно меня не путаешь с кем-то другим? А то я не сторонник подхода жопочасов.

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


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

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

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


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

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

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


E__>>С вашей моделью жопочасов проблема была бы решена только в понедельник утром.

AV>Ты точно меня не путаешь с кем-то другим? А то я не сторонник подхода жопочасов.

Я тебе ответил, но писал эту фразу оппонентам. Они это ведь тоже прочитают.

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

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

Это да.

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

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

E__>>>С вашей моделью жопочасов проблема была бы решена только в понедельник утром.

AV>>Ты точно меня не путаешь с кем-то другим? А то я не сторонник подхода жопочасов.

E__>Я тебе ответил, но писал эту фразу оппонентам. Они это ведь тоже прочитают.

Аааа, тогда принимается.

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


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

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

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

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

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

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

Это решение какой-то другой проблемы, а не описанной мной.

G>>Хорошо. Меняем в предыдущей фразе предложение Едет себе в метро на "допивает шестое пиво"
AV>Фигово будет. И что?
AV>Взять то же сидение в фиксированое время. Программер работает с 9 до 18 часов. В 17 часов приходят с багом. Ну прикинул программер, что за 5-10 минут не пофиксить. А в 18 часов все равно уходить. Ну и черт с ним, посмотрю завтра.

А то, что это как минимум детерминированно. Если на фикс бага надо 8 часов мы знаем когда он точно будет пофикшен. В другом случае мы не знаем точно когда он будет пофикшен.

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

AV>Да, у нас з.п. работников различаются.

Зп у всех различаются. Различаются ли они у вас соответственно работе выполняемой программистами?

AV>Опять же надо смотреть для чего нужно это меряние. Если для з.п., то тут скорее надо смотреть на то, на какие условия согласны стороны (работник и работодатель). Если какая-то из сторон не согласна со сложившимся положением, то надо садиться за стол переговоров. И знаешь, при этом мне в принципе по барабану сколько там зарабатывает Вася.

Что значит на что согласны? Вот есть у тебя 10 работников. Как определять кому сколько платить если ты не знаешь кто сколько работы делает?

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

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

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

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

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

TL>из платежеспособных граждан мало кому придет в голову для таких задач серверные версии виндов использовать.
Ну вот у меня на работе стоит в качестве основной ОС Win2008R2 т.к. пишем софт именно под неё.
Хочу я для решения каких то своих задач поставить туда твою софтину. И что получается? Легально купленный софт автоматом лишается поддержки?
Нехорошо выходит.

TL>Как минимум, достаточно. История примерно та же: "я читал(-а) что один товарищ поставил своей сестре вин2003 сервер вместо ХП и у нее после этого ни один вирус не завелся! (на компе, в смысле ) — так ты и мне поставь!" (к) Ответ один: "ставь" (к)
дык чистая истина

TL> Мине за это денюжку не плотят.
По идее тебе денежку платят за то, что писанный тобой софт работает везде где надо кастомеру, не?

CC>>В драйверах между серверной и юзерской виндой различий не сильно много и они локализованы в паре "областей".
L>Угу. Всего-то расширенный доступ к памяти и отсутствие прямой поддержки производителем драйвера именно как версии под серверную винду.
Это ты про что? Я почему то считал что производитель драйвера в случае с твоим продуктом это ты и есть.

TL>Мне на это в основном класть — я тупо не хочу с этим заморачиваться. Зачем мне это? Если после установки серверной версии по совету "крутого младшего брата-кулхацкера" у них вдруг отпадает любимый сканер, фотик, и видеокамера, а с игрушками тоже непонятки какие творятся, потому как видяха тоже не совсем правильно стала — я посылаю в сад. Ибо нефиг.
Такого я давно не встречал. А как ты понимаешь я в основном контактирую с серверными виндами. Все проблемы (2-3 за всё время) были строго изза криворукости производителя. К слову сказать у них и под ХР не всегда работало.

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

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

G>Это решение какой-то другой проблемы, а не описанной мной.

Как бы я действовал в описанной тобой ситуации я уже писал. Если бы был в состоянии (не был бы пьяным или что-то подобное), то начал бы рассматривать проблему в тот же день. И договорился бы о том, как будем работать в следующие дни.

G>>>Хорошо. Меняем в предыдущей фразе предложение Едет себе в метро на "допивает шестое пиво"
AV>>Фигово будет. И что?
AV>>Взять то же сидение в фиксированое время. Программер работает с 9 до 18 часов. В 17 часов приходят с багом. Ну прикинул программер, что за 5-10 минут не пофиксить. А в 18 часов все равно уходить. Ну и черт с ним, посмотрю завтра.

G>А то, что это как минимум детерминированно. Если на фикс бага надо 8 часов мы знаем когда он точно будет пофикшен. В другом случае мы не знаем точно когда он будет пофикшен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тут на перекуре подумалось

G>А то, что это как минимум детерминированно.

Да, тут возможно большая детерменированость. Но скорее всего это будет за счет увеличения времени в целом.

E__>Продавцы магазина тоже приходят как минимум к открытию, а чаще раньше. Работа у них такая: если продавец придет через пару-тройку часов после времени открытия, то магазин потеряет деньги. Работа программиста редко связана с кем-то еще, потому смысла ехать в час пик вместе со всеми в таких случаях глупо.

В Европе программисты обычно работают с 9, а в Лондоне — часто и с 8. И дело не в завязанности на кого-то, а "тут так принято".

24.09.2010 19:47, genre пишет:
>
> как-то странно, не?
Нет.

25.09.2010 0:22, ambel-vlad пишет:
>
> А если сделать примерно так. Есть команда А и команда Б. Команда А своим
> вечером говорит команде Б, что ей завтра нужно будет вот та вот
> загогулина. Пока команда А спит, другая сторона делает эту загогулину. И
> в свою очередь говорит, что ей в свою очередь надо будет что-то другое.
> И меняются местами. Где здесь будет лаг?
>
> Но это если жить только одним днем. Если же оперировать несколько более
> крупными объемами, то вклад этих лагов еще меньшим становится.
Меня поражает, что такие простейшие вещи приходится разжевывать.

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

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

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