Здравствуйте, Кодёнок, Вы писали:

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

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

Кё>>Достоверный это какой? Этот чем не достоверен?
_>Тем, что я не видел такого ни разу, и не могу с этим спорить, или соглашаться.
_>Я не сказал, что он достоверен, но этот факт просто ставить обсуждение в тупик. Поэтому и говорю — не про "гагарина".

А таких, которые на себя работают, а не наемные, знаешь?

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

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

Тут уже упоминалось, что план это не панацея. Вот давайте составим план на реализацию такой фичи:
получение всех строковых констант из Flash-ролика.

Для того чтобы составить план в часах, нужно сделать следующее:
— Проверить доступены ли дока на этот формат и готовые либы (это заняло ~1 час, заранее время предсказать нельзя)
— Для избранной либы посмотреть качество кода и методы ее интеграции с приложением. В зависимости от сложности либы этот фактор варьируется. (потрачено ~1.5 часа).
— Как минимум собрать либу (это отдельная песня, на это может уходить до нескольких дней, просто на сборку, в реальной задаче это заняло минимум времени)

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

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

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

Что же касается методов переубеждения, то если сотрудник не заинтересован в результатах проекта, вряд ли он вам будет выдавать точные планы. Когда он пишет план, то берет на себя ответсвенность, ему это нужно? Если да, то планы будут реальными и постепенно уточняться. Если же нет, то автоматически сработает отмазка: "В любом случае план будет сорван, так что можно в него писать любые цифры. Все равно это меня ни к чему не обязывает".

Ну а вопрос мотивации, это уже совсем другая песня. Тут уже было много копий сломано.

Кё>И где бред? Мой знакомый художник рисует картины и портреты на заказ, и легко называет сроки исполнения. И творчества в рисовании портрета нет никакого.

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

Однако грамотный художник все же может совместить творчество при рисовании со сроками исполнения, а не рисовать портрет до тех пор, пока модель умрет от старости.

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

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

G>Тут уже упоминалось, что план это не панацея. Вот давайте составим план на реализацию такой фичи:
G>получение всех строковых констант из Flash-ролика.

Такие задачи должны делиться как минимум на две: исследование, и по результатам — реализация. Об этом уже было в другом топике. Если задача небольшая (как эта), то вполне нормально в середине попросить разработчика переоценить сроки по результатам исследования. Руководитель же не враг, если вы обнаружите, что работа на самом деле займет в 5 раз больше, то об этом нужно сразу говорить.

G>Проделав указанные шаги, человек сказал, что добавление данной фичи займет 1 час. Итого, получение данных для составления плана, 2.5 часа, работа 1 час.

Забавно, что практически выведенное правило умножать на Пи и тут выполнилось. Выслушали разработчика (час) и умножили.

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

Может. Но как часто будет? 1 раз из 100 — вполне приемлемо для бизнеса. Зато в остальных 99 работа замечательно планируется.

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

А откуда ты взял почасовые планы? Я таких даже не видел ни разу Речь идет о приблизительных планах (см. первый пост топика). Как минимум, чтобы разработчик всегда знал и мог сказать, что он делает и что собирается делать дальше. Без плана его ответ ("Сливаю классы Дуболом и ТолпаКостоправов") ни о чем не скажет. И ответственности у него без плана нет, потому что спросишь — что делаешь? ответит делаю то-то и это; а то ли делает, нужно ли это вообще делать, успевает или опаздывает — непонятно.

G>Что же касается методов переубеждения, то если сотрудник не заинтересован в результатах проекта, вряд ли он вам будет выдавать точные планы. Когда он пишет план, то берет на себя ответсвенность, ему это нужно? Если да, то планы будут реальными и постепенно уточняться. Если же нет, то автоматически сработает отмазка: "В любом случае план будет сорван, так что можно в него писать любые цифры. Все равно это меня ни к чему не обязывает".

Так именно об этом и речь Безответственные работники никому не нужны. А явное фуфло в план во-первых все-таки не впишешь, во-вторых, по результатам сразу будет видно, продолжать с ним работать или сказать "до свидания". Дольше одного проекта он так не прохалтурит — это лучше, чем год ему зарплату платить, считая нормальным работником.

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



_>Планирование в экстремальном програмировании есть. Но это не "План" как таковой. Это то, что нужно сделать.

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

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



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

Неопределенность — это риск. Риски в любом проекте должны быть сняты на начальных этапах. Лучше вообще до старта.

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

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

S>>>а как же тогда быть? написанный менеджером плохо, написаный программером тоже плохо, выходит совсем без плана? а какже время планировать?

_>>см. Экстремальное Программирование

L>А ты сам-то его видел?

Угу, недавно в юморе пробегала ссылка на блог одного товарища, описывающего признаки "плохого программиста". Список, походу можно дополнять: они везде используют XP.

PS. Лень ссылку искать. Суть там была в том, что самое плохое в разработке ПО — это догматизм.

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

X>Угу, недавно в юморе пробегала ссылка на блог одного товарища, описывающего признаки "плохого программиста". Список, походу можно дополнять: они везде используют XP.

На основе чего вы сделали такой вывод? С какими именно практиками XP вы несогласны?

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

X>Неопределенность — это риск. Риски в любом проекте должны быть сняты на начальных этапах. Лучше вообще до старта.

Риски в общем случае можно снять только одним способом — отказавшись от проекта.

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

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



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

X>Неопределенность — это риск. Риски в любом проекте должны быть сняты на начальных этапах. Лучше вообще до старта.
Не сняты, а определены. Снять риски по определению невозможно.

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

_>>Планирование в экстремальном програмировании есть. Но это не "План" как таковой. Это то, что нужно сделать.

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

Я сам менеджер.

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

X>>Угу, недавно в юморе пробегала ссылка на блог одного товарища, описывающего признаки "плохого программиста". Список, походу можно дополнять: они везде используют XP.

L>На основе чего вы сделали такой вывод? С какими именно практиками XP вы несогласны?

Да, мне тоже очень интересно.
Вероятно, изза отсутствия таковых...

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

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

S>>>а как же тогда быть? написанный менеджером плохо, написаный программером тоже плохо, выходит совсем без плана? а какже время планировать?

_>>см. Экстремальное Программирование

L>А ты сам-то его видел?
Конечно видел, стал бы я говорить, если бы не видел...

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

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

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

X>>Угу, недавно в юморе пробегала ссылка на блог одного товарища, описывающего признаки "плохого программиста". Список, походу можно дополнять: они везде используют XP.

L>На основе чего вы сделали такой вывод? С какими именно практиками XP вы несогласны?

Я не согласен не с XP, а с догмами, вы неправильно меня поняли. Это был выпад в сторону alex_ez

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

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

X>но если уж отвечать на вопрос, то XP сама по себе не панацея, бывают процессы, в которые XP целиком плохо вписывается. Я согласен с теми практиками, от которых есть польза для меня и моей команды: сразу вспоминается только короткие итерации, автоматическое тестирование и code review (парное программирование во многих случаях не оправдано).

Для хорошей отдачи от XP — нужно пользоваться ВСЕМИ практиками XP сразу. Использование некоторых из практик XP — не дадут нужного результата, а часто сделают его хуже. (c) Brooks, кажется.

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

X>>но если уж отвечать на вопрос, то XP сама по себе не панацея, бывают процессы, в которые XP целиком плохо вписывается. Я согласен с теми практиками, от которых есть польза для меня и моей команды: сразу вспоминается только короткие итерации, автоматическое тестирование и code review (парное программирование во многих случаях не оправдано).

Ну уж нет. Взялся за гуж, так уж говори, с какими практиками не согласен.

_>Для хорошей отдачи от XP — нужно пользоваться ВСЕМИ практиками XP сразу. Использование некоторых из практик XP — не дадут нужного результата, а часто сделают его хуже. (c) Brooks, кажется.

Не знаю кто, но уж точно не Брукс.

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

LV>У нас читал лекции по организации процесса программирования главный архитектор Питерского филиала Motorola. Насколь я его понял, план составляется сверху (проектировщиками) и спускается вниз (к программистам). Обычно разница оценки во времени составляет 30%, вроде бы ее согласовывают уже вместе. Очень важно понимать, что успешным может быть план только в организации, которая знает свой процесс. Должно быть высчитано среднее количество кода, которое пишут программисты в неделю и исходить из этого параметра. Кстати, по мнению преподавателя, этот параметр изменить в фирме очень сложно. Он постоянен.
LV>Я считаю, что план должен быть, но чтобы получить грамотный план должна быть проведена очень большая подготовительнА кая работа менеджерами. Кстати, Motorola собирает около 500 метрик. И у нее CMMI 5 уровня.

А кто у них там главный архитектор?

Всем привет. выскажу свое имхо.
Значится так. Первое.
Если вы набрали в команду безответсвенных программистов... то вам для начала необходимо научится набирать команду .
Итак решение напрашивается само собой. Ж)

Второе
если речь всетаки идет о том как планировать время. ТО необходимо вспомнить Черчилля "планирование очень сложная проблема, особенно когда она касается будущего"

мое ИМХО, что касается декомпозиции работы. Это очень правильно Если разрабочик ее не может выполнить, то это прямо указывает на непонимание проблемы. Если проблема не ясна, то говорить о сроках глупо.

Далее основным риском всетаки является невыполнение задачи в срок. Ваша задача выработать план реакции на такой риск. Наверное дейсвтительно достаточно иметь некторое время в запасе. Кроме этого вы должны выработать контрольные точки по которым понятно что риск такого рода наступает.
Ваша задача лишь правильно реагировать. успешный проект может быть задержан на 10% от полного срока проекта.

Далее научите персонал не бояться говорить Вам о проблемах. Очень часто ПМ оказывается последним человеком, узнавшим о том, что все идет наперекосяк.

ну и тд.

Евгений

А и еще в догонку.

Разговор разработчика на тему "слишком творечская задаача чтобы..." по сути боязнь вам сказать правду. Например у меня когда то был менеджер, которому когда я честно сказал что необходимо порядка 3 месяцев на выполнение работы (там был по сути целый проект) то получил замечательную фразу "3 мес в сетовой график писать нельзя, мы запишем 2 недели") в конечном итоге чуда не произошло и работа была сделана за 3.5 месяца. но после этого случая, я отвечал на подобные вопросы об оценке так же как ваш безответсвенный программист. По сути эти ответы страх быть наказаным за невыполнени срока. а страх как известно очень плохой мотиватор. Но это уже другая история

Удачи