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

Интересно можно ли переубедить? Хотелось бы стимулировать ответственностью... Или это бесполезное занятие?

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

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

S>Интересно можно ли переубедить? Хотелось бы стимулировать ответственностью... Или это бесполезное занятие?

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

Ну а как стимулировать — ХЗ. Не любит это народ, факт.

Здравствуйте.
И опять Джоэл Сполски

Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях. (Когда я вижу план, измеряемый в днях, или даже в неделях, я знаю –он не реален). Возможно вы думаете, что план с мелко дроблёными задачами просто более точен. Неправильно! Очень сильно ошибаетесь! Когда вы начнете с плана с грубо определенными задачами и затем разобьёте его на меньшие задачи, вы увидите, что получили другой результат, не просто более точный. Это будет полностью другое число. Почему так получается?

Когда вы ставите мелко дроблёные задачи вы вынуждаете себя фактически вычислять то, какие шаги вы предпримите. Написать подпрограмму foo. Создать диалог такой и такой. Прочитать файл wawa. Эти шаги просто оценить, потому что прежде вы уже писали подпрограммы, создавали диалоги, и читали файлы wawa.

Если вы неаккуратны и ставите большие "короткие" задачи ("реализовать исправление грамматики"), то вы в действительности не думали, что вам предстоит сделать. Поскольку вы не думали, что собираетесь делать, вы просто не можете знать, сколько времени на это потребуется.

Как правило, каждая задача должна быть от 2 до 16 часов. Если у вас в плане стоит задача на 40 часов (одна неделя), значит вы не достаточно её разбили.

Имеется другая причина устанавливать мелкодроблёные задачи: это вынуждает вас разрабатывать проклятое свойство. Если у вас в программе будет некое сомнительное свойство, названное "Межсетевая Интеграция" и вы на него планируете недели, то вы обречены, приятель. Если же вам нужно определить, какие подпрограммы вы собираетесь написать, то вы вынуждены выявить свойство. Заставляя себя планировать вперед на этом уровне, вы устраняете много неустойчивости в программном проекте.

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

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

S>Интересно можно ли переубедить? Хотелось бы стимулировать ответственностью... Или это бесполезное занятие?

Скажу я вот что, и буду прав.

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

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

S>в ход идут различные отмазки вроде "ну есть кое-какие идеи — чем не план? зачем его писать если он всеравно поменяется?" короче все как у Ашманова

Если всё как у Ашманова, то у него наверняка есть и решение

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

_>>План как факт — это не плюс в разработке, нужно применять другие методы.
N_C>А по-моему как раз именно плюс.
N_C>Во-первых видишь все (обозримые) задачи, которые необходимо сделать в рамках проекта;
Видишь не все задачи, а только те, которые находятся на текущем листе бумаги.
ПОЧТИ ВСЕГДА, задачи меняются, а иногда и отменяются, и на место них ставятся другие.
Хотя, если сам себе хозяин, то может быть все и видно, смотря какой из тебя проект-манагер, а если нет — то вместо плана нужно использовать более современные методы.

N_C>Во-вторых позволяет более грамотно распределить собственное разработческое время;
План неудобно использовать в комманде.
План трудно изменять.
Опять же, одни проблемы, на которые разработчику приходится отвлекатся.

N_C>В-третьих — повышает ответственность в той части, когда приходишь на работу с утра
N_C>и думаешь "Надо сделать то-то то-то". И, сделав это вечером уходишь удовлетворенный
N_C>зная, что будешь делать завтра, а не мычительно размышляя на темы "Успею/Не успею".
Если человек неорганизован — то ему ничего не поможет. Ни план, ни конопля.
А успею/не успею — всегда имеет место, даже когда план перед глазами, сидишь и смотришь-думаешь, успею/не успею...

N_C>Ну и кстати, в-четвертых — позволяет отчитаться руководству о проделанной работе,
N_C>что тоже немаловажно.
Другие методы существуют. Не в плане дело.

_>>>План как факт — это не плюс в разработке, нужно применять другие методы.
N_C>>А по-моему как раз именно плюс.
N_C>>Во-первых видишь все (обозримые) задачи, которые необходимо сделать в рамках проекта;
_>Видишь не все задачи, а только те, которые находятся на текущем листе бумаги.
Я говорил про план хотя-бы текущей недели (дней трех вперед) — не зря я написал "обозримые" — а это заведомо уместится на одном листе.

_>ПОЧТИ ВСЕГДА, задачи меняются, а иногда и отменяются, и на место них ставятся другие.
Это никак не отменяет ценность планирования. Этак можно вообще сказать, что раз все меняется, то зачем писать программу? Все-равно все изменится и придется переписывать заново.

_>Хотя, если сам себе хозяин, то может быть все и видно, смотря какой из тебя проект-манагер, а если нет — то вместо плана нужно использовать более современные методы.
Например Как не обзови эти методы — конечный результат — все-равно план.

N_C>>Во-вторых позволяет более грамотно распределить собственное разработческое время;
_>План неудобно использовать в комманде.
_>План трудно изменять.
_>Опять же, одни проблемы, на которые разработчику приходится отвлекатся.
1) Очень удобно — по крайней мере мне не надо беспокоится, о том, что делает тот или иной разработчик. Если есть план, то проверяется следование генеральной линии, а не то, придумал-ли себе разработчик новую задачу или нет.
2) Это зависит от костности управления, поставленного в организации. Все это относительно.
3) Никаких проблем. Выбрал очередную задачу и реализуй ее. На что отвлекаться? А вот без плана — наоборот — надо вспоминать, что делать,
сколько это займет времени, согласовывать задачи с соседями и т.п.

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

_>А успею/не успею — всегда имеет место, даже когда план перед глазами, сидишь и смотришь-думаешь, успею/не успею...
Да, только одно но... Есть такая фраза (не моя): "Если не знаешь что делать — составь план и четко следуй этому плану. По-крайней мере избежишь мотаний и неопределенности".

_>Другие методы существуют. Не в плане дело.
См. выше — как не обзови, а все равно придет к одному.

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

_>>>>План как факт — это не плюс в разработке, нужно применять другие методы.
N_C>>>А по-моему как раз именно плюс.
N_C>>>Во-первых видишь все (обозримые) задачи, которые необходимо сделать в рамках проекта;
_>>Видишь не все задачи, а только те, которые находятся на текущем листе бумаги.
N_C>Я говорил про план хотя-бы текущей недели (дней трех вперед) — не зря я написал "обозримые" — а это заведомо уместится на одном листе.
У Вас другой подход.
Я неприемлю перепланировать каждые три дня (каждую неделю) переделку списка задач.

_>>ПОЧТИ ВСЕГДА, задачи меняются, а иногда и отменяются, и на место них ставятся другие.
N_C>Это никак не отменяет ценность планирования. Этак можно вообще сказать, что раз все меняется, то зачем писать программу? Все-равно все изменится и придется переписывать заново.
Я говорю про такую бумажку под названием "ПЛАН" и как негативно она влияет на разработку, а не про планирование в целом.

_>>Хотя, если сам себе хозяин, то может быть все и видно, смотря какой из тебя проект-манагер, а если нет — то вместо плана нужно использовать более современные методы.
N_C>Например Как не обзови эти методы — конечный результат — все-равно план.
Ваше право так считать.

N_C>>>Во-вторых позволяет более грамотно распределить собственное разработческое время;
_>>План неудобно использовать в комманде.
_>>План трудно изменять.
_>>Опять же, одни проблемы, на которые разработчику приходится отвлекатся.
N_C>1) Очень удобно — по крайней мере мне не надо беспокоится, о том, что делает тот или иной разработчик. Если есть план, то проверяется следование генеральной линии, а не то, придумал-ли себе разработчик новую задачу или нет.
N_C>2) Это зависит от костности управления, поставленного в организации. Все это относительно.
N_C>3) Никаких проблем. Выбрал очередную задачу и реализуй ее. На что отвлекаться? А вот без плана — наоборот — надо вспоминать, что делать,
N_C>сколько это займет времени, согласовывать задачи с соседями и т.п.
Планирование — должно быть.
План — нет.
Задачи должны разрабатываться отдельно, но могут быть зависимости одних задач от других.
Задачи должны лежать отдельно — это не проблема, ибо разрабатываются они отдельно.
ЛЮБУЮ задачу может взять ЛЮБОЙ член комманды.
Совещания должны быть как минимум каждое утро на 5-10 минут для решения кто что делает, и если ничего — то какие задачи берет.
Прочитайте внимательнее, пожалуйста, то, что я Вам пишу.

_>>Если человек неорганизован — то ему ничего не поможет. Ни план, ни конопля.
N_C>Неправда твоя. Как раз план больше действует на менее организованных людей. Для них, собственно и составляется. Кстати! Опять-же говоря про теорию. В любой книжке по самоорганизации первое, что говорится: "Для того, чтобы стать более организованным, надо ежедневно составлять план дел на следующий день".
А я не хочу организововаться, и хоть дерьмом ты меня корми, план на меня никак не повлияет. А теория — она и есть теория.

_>>А успею/не успею — всегда имеет место, даже когда план перед глазами, сидишь и смотришь-думаешь, успею/не успею...
N_C>Да, только одно но... Есть такая фраза (не моя): "Если не знаешь что делать — составь план и четко следуй этому плану. По-крайней мере избежишь мотаний и неопределенности".
Это, опять же, !актуально для волка, а не для стаи!.

_>>Другие методы существуют. Не в плане дело.
N_C>См. выше — как не обзови, а все равно придет к одному.
Скажем дружно — плана — не нужно.


p.s. Молодой человек. Я с Вами не согласен. И у меня на это есть ряд причин, одна из них — мой опыт. И не надо меня кормить теорией, я вижу практику.

_>Я неприемлю перепланировать каждые три дня (каждую неделю) переделку списка задач.
Утрирование, утрирование — я об этом не говорил.

_>Планирование — должно быть. План — нет.
Планирование есть, а плана — нет. Это просто подмена понятий.

_>Задачи должны разрабатываться отдельно, но могут быть зависимости одних задач от других.
Должны и могут — понятия относительные и сильно зависят от реализуемых систем.

_>ЛЮБУЮ задачу может взять ЛЮБОЙ член комманды.
С утверждением не согласен, но если так поставлена работа, то...

_>Совещания должны быть как минимум каждое утро на 5-10 минут для решения кто что делает, и если ничего — то какие задачи берет.
Ну а я про что говорю? Команда составляет план работ на день. Но при этом есть план работ на несколько дней. Чем это так уж сильно отличается от того, что я писал?

_>А я не хочу организововаться, и хоть дерьмом ты меня корми, план на меня никак не повлияет. А теория — она и есть теория.
Не организовывайся, кто-же тебе мешает. Но теория зачастую выстрадана многими людьми методом проб и ошибок. И говорить, что это все ерунда? .

_>>>А успею/не успею — всегда имеет место, даже когда план перед глазами, сидишь и смотришь-думаешь, успею/не успею...
N_C>>Да, только одно но... Есть такая фраза (не моя): "Если не знаешь что делать — составь план и четко следуй этому плану. По-крайней мере избежишь мотаний и неопределенности".
_>Это, опять же, !актуально для волка, а не для стаи!.
Да ну? Стая как раз и сильна тем, что все следуют генеральной линии. А если каждый в стае говорит, что он не хочет организовываться — это это как раз вредно для стаи.

_>Скажем дружно — плана — не нужно.
Примеры примеры...

_>p.s. Молодой человек. Я с Вами не согласен. И у меня на это есть ряд причин, одна из них — мой опыт. И не надо меня кормить теорией, я вижу практику.
PS
Как вы все тут любите козырять возрастом? По стилю ведения дискуссии я бы не дал Вам больше 35 лет. А тогда и нечего на возраст кивать.
То, что у Вас так сложилась практика ведения проектов — да на здоровье! Но говорить о том, что это единственно правильный путь — не надо.

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

_>План — это конечно хорошо, но план по сути своей если написан кем-то — то для разработчика это пи##ец.
_>Если самим разработчиком — то это меньший пи##ец, а иногда и просто потраченное немного времени.
_>План как факт — это не плюс в разработке, нужно применять другие методы.
У буржуев есть такое правило — "Если этого не на бумаге — то этого нет вообще". Бюрократия тут не причем. Если у вас нет положительного опыта в использования планов, то попробуйте ответить на такие вопросы (Ответы так же должен дать человек не знающий ваших программистов):
1. Какова производительность программиста Иванова(Петрова, Сидорова)
2. Сколько времени нужно для реализации среднего юзекейса
3. Какие сильные стороны (что лучше делает — цена/качество) программиста Иванова (Петрова, Сидорова)
4. Какие слабые стороны программиста Иванова (Петрова, Сидорова)
5. Понимает ли программист Иванов (Петров, Сидоров) что от него требуется быстрое качественное решение, а не создание нового Microsoft Office в конкретный момент времени.
6. Нужен ли новый программист в команде и когда
7. Что сейчас делает программист Иванов (Петров, Сидоров). У вас в команде 5 человек. У вас в команде 50 человек. У вас в команде 500 человек.
8. Кому отдать "горящюю" путевку на Канары (Реализация быстрой но важной работки в 4 — 6 человекочасов) с наименьшими потерями в текущих процессах.

Если ты видешь группу то на эти вопросы зачастую можешь ответить (конечно не факт что правильно). Ну а вот тебя завтра решили сделать директором. На твое место берут нового человека. Отдел встанет колом или резко "провалится". Так что не имея опыта в планировании — плюсы в разработке уже видны

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

SED>Если ты видешь группу то на эти вопросы зачастую можешь ответить (конечно не факт что правильно). Ну а вот тебя завтра решили сделать директором. На твое место берут нового человека. Отдел встанет колом или резко "провалится". Так что не имея опыта в планировании — плюсы в разработке уже видны

См. Экстремальное программирование.

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

_>Скажу я вот что, и буду прав.

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

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

Здравствуйте, alex_ez, Вы писали:
_>См. Экстремальное программирование.
Смотрю http://www.xprogramming.ru/Articles/XPlannerReview.html

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

И?

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

12) Никогда, не позволяйте менеджерам ни при каких обстоятельствах, указывать программистам, уменьшать оценку времени. Много начинающих программных менеджеров думают, что они могут "мотивировать" своих программистов, работать быстрее, давая им симпатичные, "плотненькие" (нереально короткие) планы. Я думаю, что этот вид мотивации — без мозгов (brain-dead). Когда я отстаю от плана, я чувствую себя обреченным, попадаю в депрессию, становлюсь неактивным. Когда я работаю с опережением плана, я весел и производителен. План — не место, для психологических игр.

Если ваш менеджер заставляет вас уменьшить оценку времени, есть что делать: Создайте новый столбец в плане, с именем Оценка Рика (предположим вас зовут Рик). Поместите туда свою оценку. Позвольте вашему менеджеру делать всё что угодно с колонкой Нач Оцн. Игнорируйте его оценку. Когда проект выполнен, посмотрите, кто был ближе к действительности. Я обнаружил, что стоит только пригрозить поступать так, как произойдут чудеса, особенно, когда ваш менеджер увидит, что он добился только того что попал на конкурс под названием "как медленно вы можете работать"!

Почему непутёвые менеджеры пытаются заставить программистов снижать оценки времени?

Когда проект начинается, технические менеджеры уходят, встречаются с деловыми людьми, и появляются со списком свойств, который, как они думают, займёт около 3-х месяцев, но в действительности он займёт 9. Когда вы думаете о написании кода без учёта всех шагов, которые предстоит сделать, всегда кажется, что потребуется n времени, хотя реально, скорее всего, потребуется 3n. Когда вы составляете реальный план, вы складываете все задачи и понимаете, что проект оказывается намного более длинный чем казалось сначала. Действительность погружается [куда-то] (Reality sinks in).

Непутёвые менеджеры пытаются ответить на это, прикидывая, как заставить людей, работать быстрее. Это не очень реально. Возможно вы способны нанять больше людей, но им нужно ещё выйти на заданную скорость, возможно они и станут работать на 50% эффективнее в течение нескольких месяцев (при этом понижая эффективность тех кто должен выполнять роль их наставников). Во всяком случае, на этом рынке, добавление хороших программистов может позволить уложиться в 6 месяцев.

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

Возможно вы способны добиться от людей на 20% большего выхода исходных текстов, прося каждого работать супер тяжело, независимо от того, насколько он устал. Ажиотаж, время отладки удвоится. Идиотский шаг который блестяще отзовется на [вашем] кармическом пути.

Но вы никогда не добьётесь 3n из n, ни при каких обстоятельствах, а если вы думаете, что добьётесь, пожалуйста пришлите мне по е-мэйл график биржевых котировок акций вашей компании, чтобы я мог сыграть на понижение (email me the stock ticker of your company so I can short it).

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

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

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

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

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

SED>Здравствуйте, alex_ez, Вы писали:
_>>См. Экстремальное программирование.
SED>Смотрю http://www.xprogramming.ru/Articles/XPlannerReview.html
SED>

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

SED>И?

И все.

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


_>И все.
Я так понял вы привели экстремальное программирование как пример методики в которой не используется планирование вообще и она работает на ура. Но я увидел что планирование тоже есть. Может я не правильно вас понял. Разъясните по подробнее — что вы хотели сказать, рекомендуя смотреть экстремальное программирование.

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

_>См. Экстремальное программирование.
И что мы там видим? Доску и карточки? Это да. НО! Только при планировании работ эти карточки берутся и раскладываются
на доске. Таким образом получается тот-же план, только вид сбоку. И XP говорит, вообще-то, если поступает новые задачи,
то происходит пересмотр положения карточек на доске — а это вообще-то и есть пересмотр планов.