Но при этом вы говорите «нужно посещать все занятия, потому что есть шанс, что рано или поздно какой-то процент из них станет полезным/интересным». В чем разница с «нужно покупать лотерейные билеты, потому что есть шанс, что рано или поздно один из них станет выигрышным»?
Еще раз. Если знания профессора актуальны для студентов и востребованы ими, студенты будут ходить на его занятия. Если знания профессора востребованы кем-то еще и актуальны для кого-то еще, то при чем тут вообще студенты и их посещаемость?
И более того. Вот, например, студент. Он считает профессорские знания неактуальными и невостребованными. По какой разумной и логичной причине вы хотите обязать его посещать занятия у этого профессора? Ради какой цели?
А зачем нужен-то такой профессор? Если его знания неактуальны и невостребованы, то с какой стати мы должны считать его преподавателем и заставлять студентов посещать его лекции?
Сколько у вас сотрудников?
На каком числе пришло понимание, что «всё стало плохо»?
Используете ли какие-то метрики, чтобы понимать, стало лучше или нет? Если да, то какие?
Плюс если не трудно — три главные проблемы, которые удалось решить, три, которые не удалось, и три, которые появились.
Мой (скромный) опыт говорит о том, что хорошо и стабильно оценивать сроки получается при сочетании трех параметров: опыта, контекста и мотивации. По пунктам:
-Опыт. Тут все просто и очевидно: человек, который никогда не оценивал сроки, делает это хуже; человек, у которого уже есть опыт оценки и работы со своей оценкой, со временем оценивает лучше. То же самое верно для команд.
-Контекст. Под контекстом я имею в виду любое окружение: технологии, команду, тип проекта. Человек, который всю жизнь работал с одним языком программирования, может серьезно ошибиться с оценкой проекта на другом языке; человек, долгое время работавший в стабильной команде, может серьезно ошибиться, выставляя сроки для другой команды (или выставляя сроки для себя после перехода в новую команду), и так далее.
-Мотивация. Если у людей нет стимула выставлять максимально точную оценку, они и не будут этим заниматься.
Слаженная, стабильная команда, которая занимается более-менее типовыми проектами и мотивирована выставлять максимально точные оценки, способна стабильно и регулярно выполнять работу в оговоренный срок.
P.S. «Зацикленность клиента на низкой цене приводит к перерасходу бюджета проекта» — это проблема всего бизнеса, а не проблема оценки сроков при разработке ПО. "Просто посмотрите, сколько подрядчиков при тендере на строительство шоссе называли условия лучше, чем конкурент, чтобы заполучить контракт и потом превысить смету на два миллиарда долларов и срок — на полтора года. Это бизнес. Когда речь идет о том, чтобы оставить свою компанию на плаву, ты пойдешь на всё".
Кто-то, по-моему, Пол Грэм, поделился лайфхаком для работающих дома: настроить два компьютера, один для работы, другой «для себя», причем желательно в разных комнатах или хотя бы в разных углах одной комнаты. Соответственно, за рабочим — только работаешь, никаких развлечений. Говорит, что очень помогает переключаться между режимами и не отвлекаться ни на что во время работы.
Нееет, сейчас я обычный программист с некоторым уклоном в архитектуру, выпадать на треть года для меня пока еще мечта и цель, а не серые будни =) Для этого, конечно, многое придется поменять, в первую очередь — структуру занятости и доходов, но вроде как ничего нереального, а там посмотрим, как сложится.
Я стараюсь закончить проект, уйти в отпуск и, вернувшись, начать работу над другим, в идеале — только стартующим или стартовавшим проектом. Так что вполне нормально. В ближайшие годы хочу перестроить свою жизнь так, чтобы меньше работать и больше отдыхать, в идеале — месяцев восемь в году интенсивно работать, а месяца четыре интенсивно путешествовать, ну или как-то совмещать всё это дело.
Обратная ситуация — я беру отпуска редко (раз в полтора-два года), но большие (4-8 недель). При текущей бюрократической структуре каждый мой отпуск приносит огромное количество головной боли как мне, так и моему работодателю.
Потому что а) очень часто есть заказчик, который, услышав «без проблем, мы сделаем, но когда — хрен его знает», отнесет свои деньги кому-то еще (и будет прав), и б) невозможно заниматься среднесрочным и долгосрочным планированием развития компании, если у тебя нет никакого представления о том, с какой скоростью эта самая компания движется.
У меня есть еще маленький, субъективный и, возможно, параноидальный пунктик по поводу того, что нельзя давать тем же программистам задачу без четко установленных сроков.
И более того. Вот, например, студент. Он считает профессорские знания неактуальными и невостребованными. По какой разумной и логичной причине вы хотите обязать его посещать занятия у этого профессора? Ради какой цели?
На каком числе пришло понимание, что «всё стало плохо»?
Используете ли какие-то метрики, чтобы понимать, стало лучше или нет? Если да, то какие?
Плюс если не трудно — три главные проблемы, которые удалось решить, три, которые не удалось, и три, которые появились.
-Опыт. Тут все просто и очевидно: человек, который никогда не оценивал сроки, делает это хуже; человек, у которого уже есть опыт оценки и работы со своей оценкой, со временем оценивает лучше. То же самое верно для команд.
-Контекст. Под контекстом я имею в виду любое окружение: технологии, команду, тип проекта. Человек, который всю жизнь работал с одним языком программирования, может серьезно ошибиться с оценкой проекта на другом языке; человек, долгое время работавший в стабильной команде, может серьезно ошибиться, выставляя сроки для другой команды (или выставляя сроки для себя после перехода в новую команду), и так далее.
-Мотивация. Если у людей нет стимула выставлять максимально точную оценку, они и не будут этим заниматься.
Слаженная, стабильная команда, которая занимается более-менее типовыми проектами и мотивирована выставлять максимально точные оценки, способна стабильно и регулярно выполнять работу в оговоренный срок.
P.S. «Зацикленность клиента на низкой цене приводит к перерасходу бюджета проекта» — это проблема всего бизнеса, а не проблема оценки сроков при разработке ПО. "Просто посмотрите, сколько подрядчиков при тендере на строительство шоссе называли условия лучше, чем конкурент, чтобы заполучить контракт и потом превысить смету на два миллиарда долларов и срок — на полтора года. Это бизнес. Когда речь идет о том, чтобы оставить свою компанию на плаву, ты пойдешь на всё".
А поподробнее?
У меня есть еще маленький, субъективный и, возможно, параноидальный пунктик по поводу того, что нельзя давать тем же программистам задачу без четко установленных сроков.