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

S>>>Человек предложил схему решения задачи: еждневные отчеты участников комманды о времени затраченныом в течение дня на те или иные задачи. Эта тривиальная методика, при всем ее несовершенстве, достаточно эффективно используется в индустрии, и неплохо работает, особенно на небольших проектах. Она проста как льдинка, и дешева с точки срения затрачиваемых ресурсов. Да, при усложнении проектов, увеличении числа вовлеченного персонала и схем взаимодействия внтури проектов рекоммендуется применять более мощные методики и схемы конторля, но на средних проектов — то что надо.
S>> ежедневные отчеты — это признак "полного завала проекта"
RGB>Где аргументация?

встречался с таким, видел чем заканчивалось

RGB>Может мне привести вам примеры проектов, в которых разработчики писали ежедневные отчеты, и они были сданы в срок с необходимым качеством? А заодно примеры проектов которые провалились, потому что ПМ понятия не имел чем занимаются разработчики — они не вели такие ежедневные отчеты. В результате, разработчики тратили время на ненужные вещи, и всплывало это не сразу.

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

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

S>>>Что ты имеешь против? Почему такого рода отчестность должна каким-то образом ограничивать совбоды и творческий порыв участников комманды? Как ты предлагаешь осуществлять контороль за выполнением? Или ты полагаешь что контороль и мониторинг вообще не нужен и водоворот анархии внутри проекта сам вынесет на поверхность готовое решение, при чем в срок?

S>>читаем Ашманова:
S>>Контроль посещаемости
RGB><skipped>
RGB>Кто-то говорил о контроле посещаемости?

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

S>>Контроль количества работы
S>>Далее светлая мысль начальства достигает самой сути: нужно контролировать даже не рабочее время, а количество работы! Возникает смелый план заставить программистов вечером каждого дня (вариант — по пятницам) записывать, что сделано, и тут же "одной кнопкой" отправлять запись в некую общую систему.
S>>Обычно, к счастью, этот ежедневный вариант контроля не удается даже внедрить. Сопротивление разумной части коллектива оказывается слишком велико.
S>>Пятничные отчеты начинают писаться (руководитель проекта упросил всех поддаться), но их перестают читать наверху через пару недель, а писать внизу — через месяц-полтора.
RGB>Ашманов юморист. Заметьте как идут тезисы.
RGB>1. Пытаются внедрить ежедневные отчеты
RGB>2. "Обычно" их внедрить не удается, потому что разработчики сопротивляются. Не раскрыта тема — почему они сопротивляются?

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

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

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

RGB>3. В качестве отчетов делаются отписки наверх. Поскольку они не отражают реальное положение дел — их перестают читать.
RGB>Теперь внимание вопрос. Что эти тезисы утверждают?
RGB>Ответ. На гнилых и провальных проектах внедрить ежедневные отчеты сотрудников о проделанной работе не удается! Это и есть признак плохого проекта . Так что этот аргумент не в пользу уважаемого Streamer1.

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