Нассчёт музы. Чтобы она пришла, нужно разгружать голову от суеты, от текущих дел. Лучсший способ это сделать — зафиксировать все дела на физическом носителе (ежедневник, листы бумаги, карточки, смартфон, ноут и пр.), тем самым очищая собственную оперативную память!
Про три категории задач — это всё очень условно. Например, задачу «обновить операционку на ноуте» может быть разумно сделать тогда, когда будет несколько свободных часов, А вовсе не «на этой неделе».
Когда ты ведёшь собственный бизнес, это может быть и работает. Когда у тебя есть какие-то связи со сроками и эстимейтами, то есть есть какие-то обязательства по сроками перед другими людьми — ситуация меняется.
Ну и ещё один интереснейший вопрос — это методика входа: как перейти из текущего состояния («живу как попало») в правильное (aka «живу по-Архангельскому»). Этот переход — один из самых инетесных моментов.
Да, в своё время тайм-менеджмент считался мэйнстримом, а сейчас это уже устаревшая и непопулярная по сравнению с GTD техника… Забавно.
Матрица Эйзенхауэра — примитивный, устаревший и совсем не универсальный метод. Я знаю только одного человека, у которого она заработала. Если чо, он — водитель-дальнобойщик, к IT отношения не имеет.
Для IT-шников чаще всегоэтот подход не работает, поскольку в итоге в четвёртой корзине («не срочно и не важно») накапливается огромное количество всякой мелочи, которая потихоньку начинает давить на мозг.
что есть «планировать риски»? надо управлять ими! Закладывать их в проект и прорабатывать варианты заранее. Может быть, минимизировать, может быть — страховать, может быть — принимать.
Умножение на два — это странное заявление… Хороший исполнитель тем и хорош, что в частности, называет правильные оценки, а не заниженные в два раза. Если он даёт заниженные — значит он облажался: был слишком оптимистичен, где-то не докопал, не было опыта подобных проектов и т.д. Косяк это!
И почему именно умножать на два? Почему не на полтора или на три? :)
Да, короткие итерации могут помочь, это правда. Но и они не помогают, если, например, на стороне заказчика появляются новые люди с новыми идеями или заказчика покупает кто-то более крупный или у него заканчивается финиансирование… Я знаю несколько проектов, которые год делали честный скрам, а на выходи всё равно получили недовольного заказчика и дикое говно вместо проекта))
Во-первых, имеется workaround: disable loop optimizations using the
-XX:-UseLoopPredicate JVM option to not risk index corruptions, о чём написано по ссылке. Так что проблему нельзя назвать критической.
Во-вторых, ко всем большим продуктам постоянно выходят апдейты. Это нормально, так устроена жизнь.
В-третьих, у Oracle, как я понимаю, был выбор: выпустить всё стразу, но позже, либо зарелизить часть фич, а часть отложить. Был выбран второй вариант. Не понимаю, чем он плох. Много «приятностей» вошло-таки в семёрку.
Во-первых, Oracle JDK 7 — огромный продукт, которым занимаются сотни специалистов по всему миру. Если в нём находят баги — их фиксят, как и в любом другом разумном продукте. И выпускают критические патчи с макимально возможной скоростью, уверяю Вас. Оракл не враг сам себе.
Клиентской джавой пользуются банки и биржи, серверной — разработчики по всему миру, а сама джава — популярейший язык программирования. Качество продукта — высочайшее.
Но никто не застрахован. Как Вы понимаете, невозможно гарантировать отсутствия багов в продукте. Для этого нужно было бы проверить все сценарии использования, что физически невозможно даже в теории. Это азы тестирования, про это говорят тестерам-новичкам в день их приёма на работу.
Кстати, если не секрет, что за «дырень» Вы имеете в виду?
я думаю, что если у фирмы не остаётся расходов, то у неё и доходов не будет. Потому что не понятно, как добавленную стоимость делать.
А повышение эфективности — история вечная. Как её повышать: нанимать, увольнять или ещё что-то третье делать — нужно в каждом случае отдельно смотреть.
Там довольно чётко сказано, почему оно не работает — потому что скапливается куча «не срочных и не важных» задач, которая давит на мозг.
Про три категории задач — это всё очень условно. Например, задачу «обновить операционку на ноуте» может быть разумно сделать тогда, когда будет несколько свободных часов, А вовсе не «на этой неделе».
Когда ты ведёшь собственный бизнес, это может быть и работает. Когда у тебя есть какие-то связи со сроками и эстимейтами, то есть есть какие-то обязательства по сроками перед другими людьми — ситуация меняется.
Ну и ещё один интереснейший вопрос — это методика входа: как перейти из текущего состояния («живу как попало») в правильное (aka «живу по-Архангельскому»). Этот переход — один из самых инетесных моментов.
Да, в своё время тайм-менеджмент считался мэйнстримом, а сейчас это уже устаревшая и непопулярная по сравнению с GTD техника… Забавно.
Для IT-шников чаще всегоэтот подход не работает, поскольку в итоге в четвёртой корзине («не срочно и не важно») накапливается огромное количество всякой мелочи, которая потихоньку начинает давить на мозг.
GTD, кстати, учит с этим бороться.
И почему именно умножать на два? Почему не на полтора или на три? :)
Да, короткие итерации могут помочь, это правда. Но и они не помогают, если, например, на стороне заказчика появляются новые люди с новыми идеями или заказчика покупает кто-то более крупный или у него заканчивается финиансирование… Я знаю несколько проектов, которые год делали честный скрам, а на выходи всё равно получили недовольного заказчика и дикое говно вместо проекта))
-XX:-UseLoopPredicate JVM option to not risk index corruptions, о чём написано по ссылке. Так что проблему нельзя назвать критической.
Во-вторых, ко всем большим продуктам постоянно выходят апдейты. Это нормально, так устроена жизнь.
В-третьих, у Oracle, как я понимаю, был выбор: выпустить всё стразу, но позже, либо зарелизить часть фич, а часть отложить. Был выбран второй вариант. Не понимаю, чем он плох. Много «приятностей» вошло-таки в семёрку.
Клиентской джавой пользуются банки и биржи, серверной — разработчики по всему миру, а сама джава — популярейший язык программирования. Качество продукта — высочайшее.
Но никто не застрахован. Как Вы понимаете, невозможно гарантировать отсутствия багов в продукте. Для этого нужно было бы проверить все сценарии использования, что физически невозможно даже в теории. Это азы тестирования, про это говорят тестерам-новичкам в день их приёма на работу.
Кстати, если не секрет, что за «дырень» Вы имеете в виду?
А повышение эфективности — история вечная. Как её повышать: нанимать, увольнять или ещё что-то третье делать — нужно в каждом случае отдельно смотреть.
Я говорю о том, что происходило до этого — про те годы, когда Sun так и не смог выпустить семёрку.
А что, как, почему и каковы истоки — отдельный вопрос. Пользователям-то пофиг все скрытые мотивы. Они новую джаву хотят!