Вы ничего не знаете про стол. Возможно он не позволяет крутить книжки по оси.
Сосредоточьтесь на том что точно можно - со спины на живот и наоборот. Этого вполне достаточно.
Если ориентироваться на 4 переворота (первый из которых вполне может быть случайным), то можно остановиться после трех посещений и умереть.
Если на 5 переворотов - то можно и не дождаться.
Я уже один раз написал "Горячо", получил -1 :)
Рациональное зерно в предложении есть, но со взаимным расположением книг это никак не связано. Данных в задаче хватает для решения, а стол может оказаться настолько маленьким, что книги на нем еле умещаются.
Тест на заболевание имеет 5% ложных положительных результатов. Болезнь затрагивает 1/1,000 часть населения. Люди проверяются наугад, независимо от того, подозреваются ли они в наличии болезни.
Тест пациента положителен. Какова вероятность, что пациент поражен болезнью?
По ТРИЗ любая задача перед решением должна быть должным образом сформулирована, иначе получается тривиальный метод проб и ошибок. Точки на листике бумаги ставить можно долго и без особого успеха.
Инфографика, уважаемые товарищи из Ле Монде, - это вам не впихнуть от балды столбики на карту, да разукрасить некоторые страны самыми популярными социалками.
Если переформулировать задачу (разместить пять линий таким образом, чтобы было как можно меньше точек пересечения), то решение напрашивается само собой.
В целом - согласен с обоими замечаниями. Добавлю, что:
2. Все люди разные. У меня в группе несколько человек и к каждому из них свой подход: одному я могу дать задание и забыть об этом на 8 часов, т.к. я уверен что он не будет задавать глупых вопросов и сделает все возможное сам; второго мне надо каждый час контролировать, причем при этом эффективность его труда возрастет по сравнению со случаем, когда я не трогал бы его и пустил все на самотек. Я не хочу расставаться со вторым, как Вы предложили, т.к. я знаю что он способен давать результат, в то же время мне надо им именно "руководить".
А тот вариант, который Вы предложили, будет работать только если у Вас супер-команда или куча времени на ее подбор.
6. Я, конечно же, преувеличил со 100 часами работы на 2 дня. Но общий смысл остается неизменным: работать маленькими группами хорошо, но не всегда получается это реализовать в реальных условиях.
Если бы вместо 6-го совета написали бы что-нибудь про то, как работать, если дедлайн был "вчера", то это было бы более полезно для программистов. А так выходит, что автор лишь показывает "идеальные" условия для работы, которые редко когда увидишь на практике.
Это все конечно красиво, но справедливо только в случае программиста-одиночки, работающего над личным проектом в свободное время (плюс это самое время не контролирующего).
Как только на фирме будет более 5 программистов, вот что произойдет:
1. Как можно меньше отвлекайтесь.
Чистейшая правда, это будет влиять благоприятно на производительность труда. Вот только как правило у одного программиста за плечами еще как минимум 10 проектов, которые, как это не прискорбно приходится сопровождать.
2. Работайте запоем.
Как программисту - мне это нравится. Но как руководитель проекта я с этим категорически не согласен. Я просто обязан знать, чем занимается вверенный мне человек, и не давать ему большую свободу действий, чтобы уложиться в сроки. А то он реализует мегафичу, которой не было в эстимейте, и потратит на нее половину предназначенного времени, а то что нужно было сделать - не сделает.
4. Постоянно переписывайте программы.
Опять же - время, время, время. Если свободное время есть - пусть переписывает. Хотя лучше пусть изучает новые технологии. Баги всплывут во время тестинга.
5. Пишите код, который удобно читать вам.
Когда от вас уйдет очередной программист, код которого вы через месяц никто не сможет разобрать (хотя он и будет рабочим), вы вместе со мной посмеетесь над этим советом.
6. Работайте маленькими группами.
А если дэдлайн через 2 дня, а на проект выделено 100 часов? Волей-неволей придется привлекать настолько много программистов, насколько возможно.
7. Не допускайте редактирование одного и того же кода несколькими людьми.
Вы думаете клиент будет ждать программиста, который заболел или ушел в отпуск, с месяц? Покажите мне этого клиента.
8. Начинайте с малого.
Каким боком программист связан с прототипом?? Прототипом занимается кто угодно (ПМ, менеджер по работе с клиентами, дизайнер и т.д.), но только не программист.
Это целое искусство сводить задачи к более простым.
Отлично.
Сосредоточьтесь на том что точно можно - со спины на живот и наоборот. Этого вполне достаточно.
Но потратить время до вечера можно с большей пользой. Думайте.
Единственное, на что нужно обращать внимание, - это лицом или спиной лежат книги.
Если ориентироваться на 4 переворота (первый из которых вполне может быть случайным), то можно остановиться после трех посещений и умереть.
Если на 5 переворотов - то можно и не дождаться.
Может что-то в консерватории подправить?
Новая поза?
Рациональное зерно в предложении есть, но со взаимным расположением книг это никак не связано. Данных в задаче хватает для решения, а стол может оказаться настолько маленьким, что книги на нем еле умещаются.
Тест пациента положителен. Какова вероятность, что пациент поражен болезнью?
По ТРИЗ любая задача перед решением должна быть должным образом сформулирована, иначе получается тривиальный метод проб и ошибок. Точки на листике бумаги ставить можно долго и без особого успеха.
2. Все люди разные. У меня в группе несколько человек и к каждому из них свой подход: одному я могу дать задание и забыть об этом на 8 часов, т.к. я уверен что он не будет задавать глупых вопросов и сделает все возможное сам; второго мне надо каждый час контролировать, причем при этом эффективность его труда возрастет по сравнению со случаем, когда я не трогал бы его и пустил все на самотек. Я не хочу расставаться со вторым, как Вы предложили, т.к. я знаю что он способен давать результат, в то же время мне надо им именно "руководить".
А тот вариант, который Вы предложили, будет работать только если у Вас супер-команда или куча времени на ее подбор.
6. Я, конечно же, преувеличил со 100 часами работы на 2 дня. Но общий смысл остается неизменным: работать маленькими группами хорошо, но не всегда получается это реализовать в реальных условиях.
Если бы вместо 6-го совета написали бы что-нибудь про то, как работать, если дедлайн был "вчера", то это было бы более полезно для программистов. А так выходит, что автор лишь показывает "идеальные" условия для работы, которые редко когда увидишь на практике.
Как только на фирме будет более 5 программистов, вот что произойдет:
1. Как можно меньше отвлекайтесь.
Чистейшая правда, это будет влиять благоприятно на производительность труда. Вот только как правило у одного программиста за плечами еще как минимум 10 проектов, которые, как это не прискорбно приходится сопровождать.
2. Работайте запоем.
Как программисту - мне это нравится. Но как руководитель проекта я с этим категорически не согласен. Я просто обязан знать, чем занимается вверенный мне человек, и не давать ему большую свободу действий, чтобы уложиться в сроки. А то он реализует мегафичу, которой не было в эстимейте, и потратит на нее половину предназначенного времени, а то что нужно было сделать - не сделает.
4. Постоянно переписывайте программы.
Опять же - время, время, время. Если свободное время есть - пусть переписывает. Хотя лучше пусть изучает новые технологии. Баги всплывут во время тестинга.
5. Пишите код, который удобно читать вам.
Когда от вас уйдет очередной программист, код которого вы через месяц никто не сможет разобрать (хотя он и будет рабочим), вы вместе со мной посмеетесь над этим советом.
6. Работайте маленькими группами.
А если дэдлайн через 2 дня, а на проект выделено 100 часов? Волей-неволей придется привлекать настолько много программистов, насколько возможно.
7. Не допускайте редактирование одного и того же кода несколькими людьми.
Вы думаете клиент будет ждать программиста, который заболел или ушел в отпуск, с месяц? Покажите мне этого клиента.
8. Начинайте с малого.
Каким боком программист связан с прототипом?? Прототипом занимается кто угодно (ПМ, менеджер по работе с клиентами, дизайнер и т.д.), но только не программист.