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

_>Почитал советы. Долго думал Роботизм какой-то советуют
_>А ведь грамотный начальник д.б. а) грамотным программистом, проектировщиком, девелопером и б) грамотным управленцем. ВСЁ!
_>п. а) позволяет начальнику самому поставить срок, а не обсуждать его с сотрудником
_>п. б) позволяет адекватно оценивать возможности сотрудника для применения предыдушего шага.

Не согласен.

Начальник не обязательно должен быть грамотным девелопером. Достаточно иметь возможность аудита девелопера (например, иметь под рукой грамотного специалиста, которому доверяешь). Акцептировать срок исполнения у разработчика нужно, если нет чёткого устоявшегося и основывающегося на предыдущем опыте знания, сколько какая задача должна выполняться.

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

Насчёт управленца — это TO BE, а не AS IS. Все начальники на N% грамотные управленцы... К сожалению диапазон N великоват...

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

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

_>Надо нанимать тогда еще специально обученный персонал, который эти самые таски будет составлять Галочку-то поставим, вопрос- на что. Что значит таск? Детальное ТЗ? А кто его составляет? project manager у которого и так дел по горло?

Пример таски от PM: Я говорил с клиентом, он хочет что бы эта кнопка была круглой, а надпись на ней желтого цвета
Пример таски от архитектора: Я обнаружил, что при перерисовке грида постоянно дергается сервак. Надо делать кэш.
Пример таски от девелопера: Какой урод писал этот кусок программы???? Валиться с NullPointerException каждый раз, как пытаюсь закрыть окно!!!

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

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

_>>Почитал советы. Долго думал Роботизм какой-то советуют
_>>А ведь грамотный начальник д.б. а) грамотным программистом, проектировщиком, девелопером и б) грамотным управленцем. ВСЁ!
_>>п. а) позволяет начальнику самому поставить срок, а не обсуждать его с сотрудником
_>>п. б) позволяет адекватно оценивать возможности сотрудника для применения предыдушего шага.

S>Не согласен.

S>Начальник не обязательно должен быть грамотным девелопером. Достаточно иметь возможность аудита девелопера (например, иметь под рукой грамотного специалиста, которому доверяешь). Акцептировать срок исполнения у разработчика нужно, если нет чёткого устоявшегося и основывающегося на предыдущем опыте знания, сколько какая задача должна выполняться.

Лишний человек. Хорошо или плохо- но факт.

S>Адекватно оценивать начальник может либо на основании устоявшихся правил и норм, либо путём аудита решения разработчика. Что позволяет начальнику опять таки не быть разработчиком.

S>Насчёт управленца — это TO BE, а не AS IS. Все начальники на N% грамотные управленцы... К сожалению диапазон N великоват...

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

с PS: не согласен. Детский сад с его сказками про "старого морского волка" отметаем Грамотный начальник не будет приставать к тебе (у него и так дел по горло), если твой модуль, юнит, программа работает нормально. Зато если возникнет такая ситуация, что реально необходимо что-то подправить в модуле, а ты в командировке (в другом часовом поясе и без мобильника), а остальные сотрудники загружены по полной. То начальник-девелопер абсолютно без зазрения совести и брезгливости лезет в твой код и правит баг. Заметим, баг по дефолту не может быть серьезным раз его до этого не заметили

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

S>Таски должны акцептироваться разработчиком либо отклоняться с указанием причин. Если этого не делается, то есть несколько вариантов исхода:
S>1) Время на таски выделяется правильно, но разработчик не соответствует принятому в компании уровню. BAD DEVELOPER
S>2) Время на таски занижается, разработчик заведомо не успевает. BAD MANAGER
S>3) Все таски типичные и время выделяется правильно, разработчик учпевает. GOOD BOTH

Уточните: Поставленные кем "Таски должны акцептироваться разработчиком либо отклоняться с указанием причин" ?
Ведь одно дело расписать по таскам "кому что делать", и совсем другое — написать "это буду делать я", "я этого делать не буду, потому что ...".

Ну ещё соглашусь написать так: "это буду делать я и сделаю за 8 часов, если с другими task-ами дёргать не будут".

Уважаемый Dyusha — он же ведь разработчик, а его "заставляют расписывать планы по дням, а то и по часам". И таких как он очень много.

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

M> То есть оценивать ПРОДУКТИВНОСТЬ а не СТАРАНИЯ.

Ну, если у человек старание стремиться к нулю, то его продуктивность в лучше случае будет невозрастающей.
Под старанием я понимание в т.ч. и способность к (само)обучению.

Я, конечно, как руководитель не копенгаген, но IMHO взять человека, который мало знает, но старается узнать что-то новое -- это лучше, чем взять кренделя, который что-то да знает, но ничего другого знать не хочет. В первом варианте отдача в конечном итого поболе будет.

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

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

S>>Таски должны акцептироваться разработчиком либо отклоняться с указанием причин. Если этого не делается, то есть несколько вариантов исхода:
S>>1) Время на таски выделяется правильно, но разработчик не соответствует принятому в компании уровню. BAD DEVELOPER
S>>2) Время на таски занижается, разработчик заведомо не успевает. BAD MANAGER
S>>3) Все таски типичные и время выделяется правильно, разработчик учпевает. GOOD BOTH

SSP>Уточните: Поставленные кем "Таски должны акцептироваться разработчиком либо отклоняться с указанием причин" ?
SSP>Ведь одно дело расписать по таскам "кому что делать", и совсем другое — написать "это буду делать я", "я этого делать не буду, потому что ...".

SSP>Ну ещё соглашусь написать так: "это буду делать я и сделаю за 8 часов, если с другими task-ами дёргать не будут".

SSP>Уважаемый Dyusha — он же ведь разработчик, а его "заставляют расписывать планы по дням, а то и по часам". И таких как он очень много.

Если это работа по найму, то весь процесс можно кратко расписать так:
1. Менеджер (или руководитель проекта, или ведущий разработчик... начальник, в общем) расписывает задачи/сроки и раздаёт их разработчикам.
2. Разработчики рассматривают задачи и ставят пометку: "принято к исполнению" или "не принято к исполнению".
3.1. Если принято, то всё нормально. Таск должен быть выполнен в срок.
3.2. Если не принято, то должна указываться причина, почему не принято и проводиться обсуждение, которое приводит либо к увеличению срока, либо к уменьшению объёма таска. (Ну, либо, к смене разработчика в более жёстком варианте). Иначе срок будет гарантированно сорван.

Расписывать разработчику свой план самому имеет смысл, если начальников несколько (т.е. несколько работ, которые нужно приоретизировать).

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

C>Здравствуйте!
C>В конторе складывается такая ситуация.
C>Составляется квартальный план, с учетом мнения разработчика.
C>Т.е., по общему мнению руководителя и разработчика плотный, но выполнимый график.
Вот именно — по мнению!
Нет объективной оценки времени выполнения работы. По собственному опыту и руководителя и разработчика знаю, что программисты — оптимисты по натуре своей, поэтому подсознательно сроки ставят меньше. чем потребуется реально. Это связано еще и с тем, что человек как правило, не учитывает ни собственную накапливающуюся усталость, ни возможные недомогания, ни тем более форс — мажорные обстоятельства (дополнительную не предусмотренную работу, о которой вы написали).
По многолетнему опыту могу сказаить: после всех договоренностей и согласий можно смело умножать сроки на 2 (а лучше — на Пи ) — тогда это будет похоже на реальный срок выполнения. И это при добросовестном отношении к работе.

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

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

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

_>>>Почитал советы. Долго думал Роботизм какой-то советуют
_>>>А ведь грамотный начальник д.б. а) грамотным программистом, проектировщиком, девелопером и б) грамотным управленцем. ВСЁ!
_>>>п. а) позволяет начальнику самому поставить срок, а не обсуждать его с сотрудником
_>>>п. б) позволяет адекватно оценивать возможности сотрудника для применения предыдушего шага.

S>>Не согласен.

S>>Начальник не обязательно должен быть грамотным девелопером. Достаточно иметь возможность аудита девелопера (например, иметь под рукой грамотного специалиста, которому доверяешь). Акцептировать срок исполнения у разработчика нужно, если нет чёткого устоявшегося и основывающегося на предыдущем опыте знания, сколько какая задача должна выполняться.

_>Лишний человек. Хорошо или плохо- но факт.

Кто из них?

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

_>с PS: не согласен. Детский сад с его сказками про "старого морского волка" отметаем Грамотный начальник не будет приставать к тебе (у него и так дел по горло), если твой модуль, юнит, программа работает нормально. Зато если возникнет такая ситуация, что реально необходимо что-то подправить в модуле, а ты в командировке (в другом часовом поясе и без мобильника), а остальные сотрудники загружены по полной. То начальник-девелопер абсолютно без зазрения совести и брезгливости лезет в твой код и правит баг. Заметим, баг по дефолту не может быть серьезным раз его до этого не заметили

"Детский сад" рекомендую не отметать. Если вы с таким детским садом не сталкивались, это не значит, что таких ситуаций нет.

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

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

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

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

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

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

НАЧАЛЬНИК НЕ ДОЛЖЕН ЛАЗИТЬ В КОД!!! ЧТО ЗА ДЕТСКИЙ САД!!!
Если возникает острая нехватка кадров (описанный вами случай) значит надо нанимать ещё одного работника. Если контора не может этого сделать — значит экономит на сотрудниках. Хотя, возможно, вы путаете начальника с тимлидом.

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

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

_>>Надо нанимать тогда еще специально обученный персонал, который эти самые таски будет составлять Галочку-то поставим, вопрос- на что. Что значит таск? Детальное ТЗ? А кто его составляет? project manager у которого и так дел по горло?

O>Пример таски от PM: Я говорил с клиентом, он хочет что бы эта кнопка была круглой, а надпись на ней желтого цвета
O>Пример таски от архитектора: Я обнаружил, что при перерисовке грида постоянно дергается сервак. Надо делать кэш.
O>Пример таски от девелопера: Какой урод писал этот кусок программы???? Валиться с NullPointerException каждый раз, как пытаюсь закрыть окно!!!

Типичный таск от пользователя: поменяйте надпись на кнопке с "Add" на "New", а то никому не понятно, что это кнопка...

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

D>Можно я выскажусь с точки зрения разработчика. Ненавижу планы!!! Ладно еще, когда тебе говорят — вот тебе два месяца — напиши за это время программу, но когда заставляют расписывать планы по дням, а то и по часам, то это КОШМАР. Честное слово, это блокирует всю работу. Это еще можно делать, когда работа тупая, механическая, но когда работа творческая........ И вместо того, чтобы спокойно окунуться в процесс разработки ты решаешь ребусы: как составить эти планы, чтобы начальник не придрался, как отчитываться по ним. Например, неделя ушла на отлавливание какого-нибудь злостного глюка в программе. И что писать в отчете? Напишешь как есть, начальник точно разгильдяем посчитает, приходится что-то придумывать, выкручиваться. Как можно разделить задачу?
D>У нас принято делить по формам. Но разве можно сделать сначала одну форму от начала до конца, потом другую. Все же взаимосвязано. Да и не в формах дело, вначале какие-то общие принципы придумываешь, стиль программы в конуе концов. И как это все в планах учитывать???
D>В общем, КОШМАР!!!

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

Пример
1) Продажники начинают продавать продукт до его готовности т.к. цикл продаж долог но им нужно знать когда будет готово.
2) Заказчик знает когда нужно будет показывать систему конечным пользователям т.к. их нужно собирать со всей страны.
3) Клиент знает когда можно нанимать персонал для внедренного под ключ Call Центра.

Бить разработчиков это вовсе не цель планов, а просто средство соблюдения планов. Притом не самое эффективное. Просто многие об этом забывают.

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

А руководство которое требует все прямо сейчас покажи что это оценить с большой точностью нельзя. Сошлись что это не умеет делать никто и для примера приведи например Microsoft. У них хорошая картинка есть которую я всегда в таком случае всем показываю.
http://www.microsoft.com/technet/images/itsolutions/techguide/innsol/images/msfpmd07_big.gif
Где сразу видно что на начальном этапе оценки различаются в 16 раз.

C>Вот такая у вот проблема... Поделитесь опытом, пожалуйста!

Каждую неделю минисовещание с тимлидом и pm. (обсуждаются задачи на неделю, прикидываются сроки на каждую. Если задача большая — разбивается на части, для выполнения которых нужно 1-2 дня).

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

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

X>Ежедневно — отчеты о проделанной работе (контроль соблюдения сроков). В отчете должно быть зафиксировано все, что отняло более получаса времени.
А крышу не оторвёт?

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

C>Я почему озадачился этим вопросом.
Известно, почему. Потому что мозги тебе закомпостировали.

C>Я вроде себя разгильдяем не считаю. С другой стороны, со мной работает человек, про которого все отзываются, что отдачи от него мало. С третьей стороны, начальник меня часто пытается убедить, что я разгильдяй (см. первое сообщение про квартальный план).
C>Вроде бы, с одной стороны, можно четко определить, кто разгильдяй, а кто — нет, а с другой — все разгильдяи.
C>И вот вчера приходит ко мне коллега (новенький) и жалуется, мол дал задание: разобраться с задачей автоматизированного тестирования и освоить одно из средств. Называет того разгильдяем. Вот я и задумался, как мне определить, это разгильдяй или слабенький сотрудник или его действительно отвлекали другими работами.
Да, точно мозги тебе запудрили...

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

Схема такого воздействия очень простая. Объективно твою "вину" можно будет пронаблюдать. Например, сорвал внутренний срок: вместо 5 дней потратил 6. Дальше начальник выключает из рассмотрения все параллельные факторы — что ты чем-то занимался, что были ещё нагрузки, и т.д. и т.п. То есть, вместо анализа работы он концентрируется на личности. И всё, привет. Ты, кстати, сейчас делаешь то же самое.

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

Или у вас такой внутрифирменный стиль "чморения"...

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

---

По моему скромному опыту больше всего неприятностей вызывает честный и исполнительный трудяга. Почему так получается, не знаю. Но подозреваю, что здесь задействован принцип "несдвигания сроков во что бы то ни стало". Во всяком случае, от тех, кто строг и исполнителен в административном смысле проблемы в архитектуре или кривой API получить удавалось чаще, чем от лентяев, к которым как ни зайдёшь, так они либо в инете сидят, либо музыку слушают, либо ещё чем-то занимаются.

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

Написал тебе это

Автор: Геннадий Васильев
Дата: 20.11.04

и вдруг понял, что ты, хулиган, ищешь способ обосновать оскорбление. Ну ни фига себе заявочки! Да мало того, что ищешь, так ещё и считаешь, что к тебе сие справедливо применили. Ну ваще дела...

C>По прошествии квартала разработчик отчитывается за свой первоначальный план, а дополнительные задания упускаются из рассмотрения. Чаще всего, естественно, разработчик свой план выполнить неуспевает.
C>Поднимается вопрос о том, что разработчик — разгильдяй.
А по мне так руководство страдает хронической олигофренией. И что? До много так можно договориться?

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

C>С другой стороны, было уже несколько раз, что я выступал в роли руководителя.
Ой, беда...

C>Я предлагал человеку сделать определенную работу. Вместе мы обсуждали объем и сроки. Вроде бы было полное согласие. И после этого план свой он не выполнял. Я вроде следил, чтобы никаких других работ у него не было.
Вспомни, не задавал ли ты ему вопросов: "Назвови минимальный срок, за который ты управишься", "А нельзя ли побыстрее?", "Почему так долго?". Как ты обосновывал подобные пожелания?

C>Складывается такая ситуация: практически не отслеживается, кто, когда и чем занимался. Точно могу сказать, что разные люди у нас выполняют совершенно разный объем работ. Разные люди разное время проводят в инете. Разные люди проявляют разный интерес к освоению новых технологий и разную степень стремления к повышению своей квалификации.
"Узнаю тип и узнаю калибр" (c) Луи Буссенар. А з/п у всех примерно одинаковая.

C>Всх ровнять под одну гребенку нехорошо... Хотелось бы научиться ненавязчиво контролировать, кто чем занимается, кто сталкивается с какими трудностями. Научиться достоверно определять: если человек не справился с работой, то это из-за 1) разгильдяейства или 2) его еще слабой подготовки или 3) недооценки сложности задачи.
Первую причину убираем до точного определения понятия "разгильдяй". Вторая требует определения критериев достаточной подготовленности. Относительно третьей можно ответить вопросом на вопрос: а сам-то ты часто сходу определял сложность задачи? Ну хотя бы контекстные факторы удавалось учесть все без исключения? Кстати, все три названные тобой причины можно свести к недостаточной добросовестности сотрудника. Почему? Оставляю это тебе в качестве домашнего задания. Ответишь на этот вопрос — ответишь и на другие, связанные с выявлением реальных факторов.

C>Причем чтобы свои оценки можно было четко обосновать. И руководителю, и подчиненному.
Ну суперская задача! Обосновать титул "разгильдяй". Ага, и шкалу разработать: "разгильдяй — рсп%$дяй — гуру".

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

C>Всх ровнять под одну гребенку нехорошо... Хотелось бы научиться ненавязчиво контролировать, кто чем занимается, кто сталкивается с какими трудностями. Научиться достоверно определять: если человек не справился с работой, то это из-за 1) разгильдяейства или 2) его еще слабой подготовки или 3) недооценки сложности задачи.
4) Из-за отсутствия у руководителя элементарных знаний в project management, управлении рисками и планировании. Критерий прост. Если программисты у такого руководителя систематически срывают план (и/или работают сверхурочно), то его надо снимать с должности по несоответствию. Это — инструкция для руководителя руководителя. А по другому ответить нельзя — ответ из специализированной литературы чрезвычайно развернут.

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

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

X>>Ежедневно — отчеты о проделанной работе (контроль соблюдения сроков). В отчете должно быть зафиксировано все, что отняло более получаса времени.
ГВ>А крышу не оторвёт?

Вам как отвечать, абстрактно, в вашем же тоне, или конкретно ?

Конкретно: конторе 6 лет, текучка очень маленькая.

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

C>Составляется квартальный план, с учетом мнения разработчика. Т.е., по общему мнению руководителя и разработчика плотный, но выполнимый график.....
<skipped>
вы лучше план на пятилетку составляйте, когда начнут искать разгильдяя, он будет уже в другом месте

C>Складывается такая ситуация: практически не отслеживается, кто, когда и чем занимался....
<skipped>
C>Поднимается вопрос о том, что разработчик — разгильдяй.

ну это уже обьяснимо, начальник всегда найдет виноватого

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

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

X>>>Ежедневно — отчеты о проделанной работе (контроль соблюдения сроков). В отчете должно быть зафиксировано все, что отняло более получаса времени.
ГВ>>А крышу не оторвёт?
X>Вам как отвечать, абстрактно, в вашем же тоне, или конкретно ?
Да будет этот выбор только Вашим.

X>Конкретно: конторе 6 лет, текучка очень маленькая.
Ага, уже выбрали, значит... Только мимо. Каким образом это связано с моим комментарием?

Поясню, что я имел ввиду под "крышу не оторвёт".

Получасовых дел при 9-10-часовом рабочем дне (чаще всего он именно такой) может быть около 20 (не ловите меня на арифметике). В том числе и "ходил, искал, не нашёл...", позвали, спросили, огадывали", так что, попытка написать "дневник" такого рода будет сопряжена с определёнными трудностями.

А именно.

При плотной загрузке разнородными делами (хаосе) для их перечисления потребуется минимум 40 минут. Кстати, n+1-м пунктом войдёт само составление отчёта (уж я бы вписал обязательно, и ещё вычел бы это время из общего рабочего). Кроме того, на самом деле, из таких отчётов потом очень трудно составить некую цельную картину процесса — все пишут разным языком и называют одни и те же вещи разными именами. Разумеется, лучше всего об этом будет знать тот, кто соответствующее поручение выдаёт. Так что, пусть он и пишет — кто и на какое время был загружен. Так что, следует признать критерий "всё что боле получаса" — неадекватным.

При небольшом же разнообразии нужно ориентироваться на те дела, котрые соответствуют поставленным задачам. Тогда справедливость предложенного критерия вызывает ещё большие сомнения — гораздо проще отмечаться в каком-нибудь Planner-е, или просто отмечать достигнутый прогресс.

То есть, при обоих случаях критерий "всё, что более получаса" — неадекватен. Ergo, вызывает сначала насмешку, потом раздражение, потом — депрессию ("Отрыв крыши").

Вопрос, который я люблю задавать любителям отчётности (простите за ёрничающий тон): как нужно отображать в отчёте процесс размышлений над некоторой задачей? А спонтанные микросовещания, которые могут длиться по полтора-два часа?

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

C>>Здравствуйте!
C>>В конторе складывается такая ситуация.
C>>Составляется квартальный план, с учетом мнения разработчика.
C>>Т.е., по общему мнению руководителя и разработчика плотный, но выполнимый график.
LVV>Вот именно — по мнению!
Да, верно. Притом один обычно смущается, а другой этим пользуется.

LVV>Нет объективной оценки времени выполнения работы. По собственному опыту и руководителя и разработчика знаю, что программисты — оптимисты по натуре своей, поэтому подсознательно сроки ставят меньше. чем потребуется реально. Это связано еще и с тем, что человек как правило, не учитывает ни собственную накапливающуюся усталость, ни возможные недомогания, ни тем более форс — мажорные обстоятельства (дополнительную не предусмотренную работу, о которой вы написали).

Согласен. Могу добавить, что подобный сверхоптимизм связан с тем, что программист нередко предлагает интересный ему способ решения задачи. Но при этом, к сожалнию, боится, что руководство его заставит идти более короткой, но туповатой дорогой, если не будет удовлетворено сроками. Это его психологическая защита от возможного распада личности под влиянием требования творить глупости. Соответственно, он вынужденно идёт на подмену понятий, например, объявляет сроки готовности основных фич сроками общей готовности продукта и так далее. Другая причина подобных подмен — перманентный риск нарваться на обвинения в "разгильдяйстве". То есть, руководство само создаёт атмосферу напряжённости, а валит снова всё на программистов. Третья причина связана с контекстными факторами — прибежали, приволокли срочное задание, которое нужно сделать "вчера" и т.п. (здесь у нас, похоже, консенсус )

LVV>По многолетнему опыту могу сказаить: после всех договоренностей и согласий можно смело умножать сроки на 2 (а лучше — на Пи ) — тогда это будет похоже на реальный срок выполнения. И это при добросовестном отношении к работе.

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