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

G>>>Пример из реальной жизни.
AV>>И? Бардак он и в реальной жизни существует.

G>ты точно понял про какой пример я говорю? Там пробелемы не из-за бардака.

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

G>>>Так баги не появляются по расписанию. Как договориться-то?
AV>>Какие проблемы? Если честно, то я не вижу их. Или мы живем в Средние Века и современные средства коммуникации недоступны?

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

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

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

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

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

G>>Кто не умеет, тот не получит 50% надбавки — только и всего

A>Кто не умеет — не получит вообще ничего до тех пор пока не сделает.

Насколько я понял идею автора, надбавка в 50% дается за то, что вовремя сделал, а если пролетел — то обычная ставка. По-моему, вполне демократично

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

AV>>Какие претензии к средствам коммуникации? У нас на проекте нет никаких затыков по причине разного времени. Да, иногда по ходу работы возникают моменты, когда хочется поговорить с другой стороной, но там уже давно спят. Но такое возникает достаточно редко и не носит критических характер.

G>К средствам никаких претензий. Телефон, аська, почта и видеоконференции — все работает прекрасно.

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

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

G>В итоге ты вынужден следующий раз закладывать сроки на вот эти коммуникации.

И как велики размеры этого дополнительного времени?

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

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

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

Автор: genre
Дата: 22.09.10

Уже раз 100 писал тут на форуме. Не надо придумывать себе проблемы, а
потом не успешно их преодолевать.

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

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

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


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

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

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

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

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

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

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

24.09.2010 17:36, ambel-vlad пишет:
>
> Ой, как страшно. Думаешь что-то изменится от того, что люди будут
> отсижывать по 8 часов
Измениться отношение к работе.

>
> Задумаюсь. Если человек так успешно работает, то почему бы не предложить
> ему больше?
Есть опасность, что больше он не потянет, просто вымотается и все —
деньги это уже во вторую очередь (сыр в мышеловке). Просто этот человек
способен 4 часа в день очень интенсивно работать головой.

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

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

V>3. Программист делает разбивку задачи на подзадачи сроками по 2-3 дня,
V>но не дальше, чем на 2 недели вперед.

Вот это уже предметно. Я по пунктам напишу в понедельник.
пока только мелкое замечание.

вот тут ты утверждал что Подобная методика гарантирует завышение сроков раза в 2-3.

Автор: Vzhyk
Дата: 21.09.10

как-то странно, не?

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

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

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

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

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

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

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

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


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

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

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

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

AV>Хотя это и не полная гарантия. Опять же, что мешает маневрировать ресурсами?

Это не значит, что ресурсы простаивают. Есть много задач. Но вот конкретно эта задача — стоит.

G>>В итоге ты вынужден следующий раз закладывать сроки на вот эти коммуникации.
AV>И как велики размеры этого дополнительного времени?

Зависит от начальных условий. Бывает и очень много.

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

FR>Во первых зачем уравниловка?
FR>И как мерять одинаковость?
FR>И вообще люди неравны, а программисты сильно неравны, разбежка производительности на порядок вполне реальна:
FR>http://russian.joelonsoftware.com/Articles/HighNotes.html

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

G>>И не вызвать ощущение неравенства в команде?
FR>А вот это задача для хорошего менеджера.

Ну как например?

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

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

И как же решаются подобные проблемы?

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

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

Хорошо. Меняем в предыдущей фразе предложение Едет себе в метро на "допивает шестое пиво"

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

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

Категоричность это зло
Почему сразу насрать? Программер вечером ушел в бассейн, трубку не берет. Тестер не пришел с утра, зная что фикс будет поздно, программер ушел рано потому что с 6 утра багу фиксил в авральном режиме. итд.

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

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

Вопрос только в какую сторону. Не совсем уверен, что в нужную.

>> Задумаюсь. Если человек так успешно работает, то почему бы не предложить
>> ему больше?
V>Есть опасность, что больше он не потянет, просто вымотается и все —
V>деньги это уже во вторую очередь (сыр в мышеловке). Просто этот человек
V>способен 4 часа в день очень интенсивно работать головой.

В таком случае останемся при своих. То есть вернемся к начальному положению. Никаких проблем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

G>И как же решаются подобные проблемы?

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

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

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

G>Хорошо. Меняем в предыдущей фразе предложение Едет себе в метро на "допивает шестое пиво"

Фигово будет. И что?

Взять то же сидение в фиксированое время. Программер работает с 9 до 18 часов. В 17 часов приходят с багом. Ну прикинул программер, что за 5-10 минут не пофиксить. А в 18 часов все равно уходить. Ну и черт с ним, посмотрю завтра.