И вообще, для возмущающегося товарища — я не знаю, сколько у него человек в команде,
но у меня прогресса примерно был такой —
1. Когда у меня один человек, я помнил, что он делает
2. Когда у меня было 2-3 человека, я записывал в Word'е задачи и потом их вычеркивал.
3. Когда у меня было 5 человек, я распределял залачи через TestTrack, но уже тогда остро стояла необходимость
календарного планирования и отслеживания прогресса.
4. Сейчас у меня 12 человек я не представляю, как можно в голове удержать прогресс по всем направлениям.
Без MS Project (или аналога) просто не обойтись.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>По поводу работы по ночам — лично я считаю это более вредным, чем полезным.
M_E>Разработчик может сидеть до середины ночи и зачекинить такое, что не будет правильно работать.
M_E>Тогда команде с утра придется либо ждать его прихода, пока он выспится, либо самим разбираться в том, что он ночью написал и M_E>пытаться устранить ошибку.
M_E>Второй момент (более общего плана) — нарушение взаимодействий в команде. Если один человек пришел с утра, а второго нет, и работа первого зависит от второго, то получаем потерю времени.
M_E>В общем я против этого и мне пришлось прекратить такую практику более года назад
если команда построена так что вся работа стоит пока когото нет, значит чтото здесь неправильно — работа должна иметь возможность продолжаться, даже если неожиданно ктото ушел в отпуск...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Streamer1, Вы писали: S>>Вот давай по сути. S>>Человек предложил схему решения задачи: еждневные отчеты участников комманды о времени затраченныом в течение дня на те или иные задачи. Эта тривиальная методика, при всем ее несовершенстве, достаточно эффективно используется в индустрии, и неплохо работает, особенно на небольших проектах. Она проста как льдинка, и дешева с точки срения затрачиваемых ресурсов. Да, при усложнении проектов, увеличении числа вовлеченного персонала и схем взаимодействия внтури проектов рекоммендуется применять более мощные методики и схемы конторля, но на средних проектов — то что надо. S> ежедневные отчеты — это признак "полного завала проекта"
Где аргументация? Может мне привести вам примеры проектов, в которых разработчики писали ежедневные отчеты, и они были сданы в срок с необходимым качеством? А заодно примеры проектов которые провалились, потому что ПМ понятия не имел чем занимаются разработчики — они не вели такие ежедневные отчеты. В результате, разработчики тратили время на ненужные вещи, и всплывало это не сразу.
S>>Что ты имеешь против? Почему такого рода отчестность должна каким-то образом ограничивать совбоды и творческий порыв участников комманды? Как ты предлагаешь осуществлять контороль за выполнением? Или ты полагаешь что контороль и мониторинг вообще не нужен и водоворот анархии внутри проекта сам вынесет на поверхность готовое решение, при чем в срок?
S>читаем Ашманова: S>Контроль посещаемости
<skipped>
Кто-то говорил о контроле посещаемости?
S>Контроль количества работы S>Далее светлая мысль начальства достигает самой сути: нужно контролировать даже не рабочее время, а количество работы! Возникает смелый план заставить программистов вечером каждого дня (вариант — по пятницам) записывать, что сделано, и тут же "одной кнопкой" отправлять запись в некую общую систему. S>Обычно, к счастью, этот ежедневный вариант контроля не удается даже внедрить. Сопротивление разумной части коллектива оказывается слишком велико. S>Пятничные отчеты начинают писаться (руководитель проекта упросил всех поддаться), но их перестают читать наверху через пару недель, а писать внизу — через месяц-полтора.
Ашманов юморист. Заметьте как идут тезисы.
1. Пытаются внедрить ежедневные отчеты
2. "Обычно" их внедрить не удается, потому что разработчики сопротивляются. Не раскрыта тема — почему они сопротивляются? Может потому что они большую часть времени занимаются не тем что надо? (они при этом могут писать код и реализовывать фичи, но неизвестно ТЕ они делают фичи или нет, успевают они реализовывать фичи согласно плану или нет).
3. В качестве отчетов делаются отписки наверх. Поскольку они не отражают реальное положение дел — их перестают читать.
Теперь внимание вопрос. Что эти тезисы утверждают?
Ответ. На гнилых и провальных проектах внедрить ежедневные отчеты сотрудников о проделанной работе не удается! Это и есть признак плохого проекта . Так что этот аргумент не в пользу уважаемого Streamer1.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Да, я с вами совершенно согласен.
M_E>И вообще, для возмущающегося товарища — я не знаю, сколько у него человек в команде,
Я вас умоляю...
Не относитесь к этому слишком серьезно. Готов поспорить, что товарищ не имеет ни грамма опыта в практическом менеджменте.
Здравствуйте, Streamer1, Вы писали:
S>ежедневные отчеты — это признак "полного завала проекта"
это лозунг?
если это твоя мысль — будь добр поподробнее...
потому, что у меня на этот счет совершенно противоположное мнение.
и это мнение подтверждается моим практическим опытом.
S>читаем Ашманова:
нда, авторитетный источник, чего и говорить...
когда говорит ашманов, остальной мир нервно курит в сторонке
одним словом, либо свернем дискуссию ввиду несостоятельности твоей аргументации, либо сформулируй четко что так сурово выводит тебя из равновесия?
методика мониторинга выполнения, основанная на ежедневных репортах?
предложи альтернативу. ты предлагаешь вообще не мониторить статус проекта? или делать это каким либо другим способом?
--
(ашманова смело в топку, ну ей-богу не трать время на подобный мусор)
Здравствуйте, 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.
не совсем так, ответ: Люди которые доводят проекты до гнилого и провального состояния как правило склонны к внедрению ежедневных отчетов сотрудников о проделаной работе, что свидетельствет о серьезности некомпетентности в управлении, а не о случайных ошибках в планировании...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Но ведь действительно, многие члены команды вообще не пишут код. M_E>Их работу как-то надо планировать и отслеживать
Впринципе, можно применять технику планирования/контороля объема работы только для разработчиков. Уже это немало, учитывая то, что это есть основной и наиболее массовый в ИТ компании ресурс.
M_E>Можно, конечно, использовать кол-во найденных ошибок для тестировщиков.
Да. Например, в CQG в числе прочих используется и эта метрика для оценки/контроля/планирования работы QA.
Здравствуйте, 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.
не совсем так, ответ: Люди которые доводят проекты до гнилого и провального состояния как правило склонны к внедрению ежедневных отчетов сотрудников о проделаной работе, что свидетельствет о серьезности некомпетентности в управлении, а не о случайных ошибках в планировании...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Streamer1, Вы писали:
S>>> ежедневные отчеты — это признак "полного завала проекта" RGB>>Где аргументация?
Причин завала проекта может быть миллион и ежедневные отчеты здесь роли никакой не играют.
Рассматривайте их как следование поставленному с утра плану и контроля эффективности вашего планирования на заданный период времени.
Можно для развлечения вычислять коэффициент соответствия запланированного с утра и сделанного к вечеру.
Из своего опыта заметил, что планирование (как минимум на день) позволяет не только видеть актуальные задачи, но и сократить цикл разработки.
S>приведите, желательно с описанием последствий и таких косвенных показателей как текучесть кадров, заинтересованность (не только денежная но и моральная) сотрудников в работе, атмосфера в коллективе... короче тех факторов которые отпугивают людей от работы...
У нас принята ежедневная система отчетности. Из той части коллектива, которая относится к работе с заинтересованностью они не представляет неудобств (по сравнению с другими, бОльшими огрехами в организации проивзодства). Немного приврал, но в целом все так.
RGB>>1. Пытаются внедрить ежедневные отчеты RGB>>2. "Обычно" их внедрить не удается, потому что разработчики сопротивляются. Не раскрыта тема — почему они сопротивляются? S>потому что это серьезно отвлекает от работы и создает впечатление что человека загоняют в кабалу
Чем это фиксация сделанных изменений (достаточно 5 минут на каждую завершенную подзадачу) отвлекает от работы?
RGB>>3. В качестве отчетов делаются отписки наверх. Поскольку они не отражают реальное положение дел — их перестают читать.
Есть такой пунктик, но если проект разбит на подзадачи с интервалом в 4-40 часов, то даже отписки позволяют фиксировать направление, в котором идут работы. Тоесть здесь проблемы манагера, а не системы или девелопера.
S>не совсем так, ответ: Люди которые доводят проекты до гнилого и провального состояния как правило склонны к внедрению ежедневных отчетов сотрудников о проделаной работе, что свидетельствет о серьезности некомпетентности в управлении, а не о случайных ошибках в планировании...
"Люди которые доводят проекты до гнилого и провального состояния" — это какие люди имеются ввиду? Проект сам по себе не загнивает, он загнивает при неправильном планировании и отсутствии контроля. Уж этого я наелся :D
Здравствуйте, Slick, Вы писали:
S>>читаем Ашманова:
S>нда, авторитетный источник, чего и говорить... S>когда говорит ашманов, остальной мир нервно курит в сторонке
S>одним словом, либо свернем дискуссию ввиду несостоятельности твоей аргументации, либо сформулируй четко что так сурово выводит тебя из равновесия?
S>методика мониторинга выполнения, основанная на ежедневных репортах?
S>предложи альтернативу. ты предлагаешь вообще не мониторить статус проекта? или делать это каким либо другим способом?
альтернатива — тратить время на выполнение основной работы (за которую кстати и платятся деньги), а не разводить бюрократию, сжигая время на составление отчетов и пытаясь наладить испорченную атмосферу неадекватными методами...
Важно помнить что деньги платят не за попытки создания жизнеспособной системы с жесткой отчетностью, неадекватными попытками управления и несбалансированными отношениями, а за результаты выполнения работы. Под результатами работы понимается не гора отчетов, а программный продукт.
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, PVA, Вы писали:
PVA>Здравствуйте, Streamer1, Вы писали:
S>>приведите, желательно с описанием последствий и таких косвенных показателей как текучесть кадров, заинтересованность (не только денежная но и моральная) сотрудников в работе, атмосфера в коллективе... короче тех факторов которые отпугивают людей от работы... PVA>У нас принята ежедневная система отчетности. Из той части коллектива, которая относится к работе с заинтересованностью они не представляет неудобств (по сравнению с другими, бОльшими огрехами в организации проивзодства). Немного приврал, но в целом все так.
а часть эта состоит из одного человека — менеджера требующего ежедневные отчеты?
RGB>>>1. Пытаются внедрить ежедневные отчеты RGB>>>2. "Обычно" их внедрить не удается, потому что разработчики сопротивляются. Не раскрыта тема — почему они сопротивляются? S>>потому что это серьезно отвлекает от работы и создает впечатление что человека загоняют в кабалу PVA>Чем это фиксация сделанных изменений (достаточно 5 минут на каждую завершенную подзадачу) отвлекает от работы?
тем что человек будет думать о том что ему написать в отчете, а не о том как быстрее и качественнее решить задачу. Соответственно и результат будет ориентирован на отчет, а не на решение задачи.
S>>не совсем так, ответ: Люди которые доводят проекты до гнилого и провального состояния как правило склонны к внедрению ежедневных отчетов сотрудников о проделаной работе, что свидетельствет о серьезности некомпетентности в управлении, а не о случайных ошибках в планировании... PVA>"Люди которые доводят проекты до гнилого и провального состояния" — это какие люди имеются ввиду?
PM
PVA>Проект сам по себе не загнивает, он загнивает при неправильном планировании и отсутствии контроля. Уж этого я наелся :D
согласен, однако ежедневными отчетами хорошего контроля не добъешься, т.к. это стимул работать на отчеты, а не на решение задачи, а это несколько разные вещи...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Streamer1, Вы писали:
PVA>>У нас принята ежедневная система отчетности. Из той части коллектива, которая относится к работе с заинтересованностью они не представляет неудобств (по сравнению с другими, бОльшими огрехами в организации проивзодства). Немного приврал, но в целом все так. S>а часть эта состоит из одного человека — менеджера требующего ежедневные отчеты?
Это проблема заинтересованности. Давайте введем разницу между требовать и заинтересовать.
PVA>>Чем это фиксация сделанных изменений (достаточно 5 минут на каждую завершенную подзадачу) отвлекает от работы? S>тем что человек будет думать о том что ему написать в отчете, а не о том как быстрее и качественнее решить задачу. Соответственно и результат будет ориентирован на отчет, а не на решение задачи.
Отчет фиксироует сделанную работу — зачем там о чем-то думать? Достаточно написать, что сделал "то-то", потому что "как сделал" — видно из кода, а "почему так сделал" из комментариев к коду.
PVA>>"Люди которые доводят проекты до гнилого и провального состояния" — это какие люди имеются ввиду? S>PM
Тогда давайте вскроем причину довода до провального состояния. Опишете?
PVA>>Проект сам по себе не загнивает, он загнивает при неправильном планировании и отсутствии контроля. Уж этого я наелся :D S>согласен, однако ежедневными отчетами хорошего контроля не добъешься, т.к. это стимул работать на отчеты, а не на решение задачи, а это несколько разные вещи...
См. выше. Отчет только фиксирует выполненную задачу, но никак не дает волю фантазии — никто не требует трехстраничного описания о ходе выполнения работы.
Здравствуйте, Slick, Вы писали:
M_E>>Да, я с вами совершенно согласен.
M_E>>И вообще, для возмущающегося товарища — я не знаю, сколько у него человек в команде,
S>Я вас умоляю... S>Не относитесь к этому слишком серьезно. Готов поспорить, что товарищ не имеет ни грамма опыта в практическом менеджменте.
интересно а зачем ты пытаешься перейти на личности? неужели доводов нет?
опыт у меня пока действительно небольшой, но непрофессиональные менеджеры это отнюдь не редкость среди людей с большиииим опытом, я бы даже сказал что таких можно считать как уже привыкших и плохо подающхся исправлению...
поверхностно мыслите товарищь!
Тот кто говорит не знает, тот кто знает не говорит.
S>>одним словом, либо свернем дискуссию ввиду несостоятельности твоей аргументации, либо сформулируй четко что так сурово выводит тебя из равновесия? S>>методика мониторинга выполнения, основанная на ежедневных репортах? S>>предложи альтернативу. ты предлагаешь вообще не мониторить статус проекта? или делать это каким либо другим способом?
S>альтернатива — тратить время на выполнение основной работы (за которую кстати и платятся деньги), а не разводить бюрократию, сжигая время на составление отчетов и пытаясь наладить испорченную атмосферу неадекватными методами... S>Важно помнить что деньги платят не за попытки создания жизнеспособной системы с жесткой отчетностью, неадекватными попытками управления и несбалансированными отношениями, а за результаты выполнения работы. Под результатами работы понимается не гора отчетов, а программный продукт.
Streamer1, вам не надоело подменять понятия? Уже несколько раз в этом топике вам на это указывали.
Составление очтета в конце рабочего дня о проделаной работе занимает 5 минут и НЕ является разведением бюрократии, НЕ сжигает время, НЕ портит атмосферу и НЕ является целью работы программистов.
Важно помнить, что деньги платят не за деятельность разработчиков-"художников", которые не знают что они будут писать завтра, что они писали вчера. Разработчиков, которые работают по принципу "3 месяца рубаемся в кваку, а потом прибегает заказчик и говорит что надо было сделать вчера", словами имитирующие результаты работы, дающие устные оценки "да у меня почти все готово". Под результатами работы понимается программный продукт, сделанный В СРОК, а не гора обещаний заказчику что "вот еще чуть-чуть и оно заработает".
Пытался воспроизвести полемику автора .
А на вопрос ответа не получено. Повторю вопрос Slick'a:
"ты предлагаешь вообще не мониторить статус проекта?"
Варианты ответов — да \ нет. Дайте ответ и тогда будет иметь смысл дальше дискутировать.
S>>>одним словом, либо свернем дискуссию ввиду несостоятельности твоей аргументации, либо сформулируй четко что так сурово выводит тебя из равновесия? S>>>методика мониторинга выполнения, основанная на ежедневных репортах? S>>>предложи альтернативу. ты предлагаешь вообще не мониторить статус проекта? или делать это каким либо другим способом?
S>>альтернатива — тратить время на выполнение основной работы (за которую кстати и платятся деньги), а не разводить бюрократию, сжигая время на составление отчетов и пытаясь наладить испорченную атмосферу неадекватными методами... S>>Важно помнить что деньги платят не за попытки создания жизнеспособной системы с жесткой отчетностью, неадекватными попытками управления и несбалансированными отношениями, а за результаты выполнения работы. Под результатами работы понимается не гора отчетов, а программный продукт.
RGB>Streamer1, вам не надоело подменять понятия? Уже несколько раз в этом топике вам на это указывали.
RGB>Составление очтета в конце рабочего дня о проделаной работе занимает 5 минут и НЕ является разведением бюрократии, НЕ сжигает время, НЕ портит атмосферу и НЕ является целью работы программистов. RGB>Важно помнить, что деньги платят не за деятельность разработчиков-"художников", которые не знают что они будут писать завтра, что они писали вчера. Разработчиков, которые работают по принципу "3 месяца рубаемся в кваку, а потом прибегает заказчик и говорит что надо было сделать вчера", словами имитирующие результаты работы, дающие устные оценки "да у меня почти все готово". Под результатами работы понимается программный продукт, сделанный В СРОК, а не гора обещаний заказчику что "вот еще чуть-чуть и оно заработает". RGB>Пытался воспроизвести полемику автора .
RGB>А на вопрос ответа не получено. Повторю вопрос Slick'a: RGB>"ты предлагаешь вообще не мониторить статус проекта?" RGB>Варианты ответов — да \ нет. Дайте ответ и тогда будет иметь смысл дальше дискутировать.
нет, мониторить нужно, первый раз я этому уделял мало внимания что потом вылилось в глюки из-за небольших нестыковок и переносу сроков...
но, есть проблема что если сильно затягивать гайки то люди просто разбегутся и никаким калачом их не заманишь... так что палка тут о двух концах...
Тот кто говорит не знает, тот кто знает не говорит.
. Так что этот аргумент не в пользу уважаемого Streamer1.
