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

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

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

ппц- это у вас реально так? тут как-бы в организации проблема, а не в свободном графике

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



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

+1500

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


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

ппц ну и бред?

а про системы багтрекинга, где у каждого бага выставляется приоритет, в соответствие с которым тестеры обрабатывают баги вы не слышали?

ну честное слово, вы какой-то весельчак

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

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


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

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

будем исправлять 10 тикетов high в ЛЮБОМ удобном для нас порядке.

Что тут непонятного?

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


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

решается очевидно что самым критичным ставиться статус critical или blocker.

Вопросы?

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

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

N7>будем исправлять 10 тикетов high в ЛЮБОМ удобном для нас порядке.

N7>Что тут непонятного?

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

на это сообщение можешь не отвечать. дискуссия в таком тоне мне не интересна.

Здравствуйте, 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 вечера в офисе между билдами?

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

Т.е. дисциплина не противоречит свободному графику.

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

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

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

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

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

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

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

ну... эко ты загнул

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

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

N7>как опровергающий пример могу привести оценку сроков на релиз — тут присутствие представителей от разработчиков обязательно, что-бы оценить сроки исполнения хотелок, что-бы управленцы могли составить scope задач

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

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

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

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

Берем продукт — отделом маркетинга составляется набор 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 — потому что мне так хочется — это не ПМ. В свое время меня во дворе приучили к одному правилу — сказал что-то заявил — обоснуй — за слова ответь... не ответил — получи по морде... или молчи...

17.11.2010 18:21, Nick-77 пишет:
>
> конечно нет — а работает просто держать в офисе народ 8 часов, аки
> тягловый скот?
Да, конечно. И неважно, что код ужасен, продукт сплошь в багах, баги
фиксятся годами, главное весь народ в офисе и упорно "работает"
(по-русски говоря, штаны протирает).
Подытоживается все это фразой: "Мы делаем все, что можем".

17.11.2010 18:54, Nick-77 пишет:
> решается очевидно что самым критичным ставиться статус critical или
> blocker.
>
> Вопросы?
О. Ты наверное никогда не видел, как русские манагеры в подавляющем
большинстве выставляют приоритет critical почти всем багам.

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

N7>значит в данный релиз заносятся N багов, остальные переносятся на следующий.

какие N? что делать если влезло N-2 и осталось времени еще только на один, какой из оставшихся двух выбрать. как учесть зависимости между тасками, как начать с более критичных, чтобы их можно было раньше начать тестировать, итд.


N7>п.с. может хватит тут разыгрывать оскорблённую ранимость уже?

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

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

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

N7>решается очевидно что самым критичным ставиться статус critical или blocker.

N7>Вопросы?

выделил.

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

V>17.11.2010 18:54, Nick-77 пишет:
>> решается очевидно что самым критичным ставиться статус critical или
>> blocker.
>>
>> Вопросы?
V>О. Ты наверное никогда не видел, как русские манагеры в подавляющем
V>большинстве выставляют приоритет critical почти всем багам.

Ну и кто им злобный баклан?