Есть опыт внедрения и того, и другого. Я склонен рассматривать его (их) как неудачный.
Основные проблемы (кратко):
1. Программеры привыкли, что доки и прочии тексты нужно писать из под палки.
2. Распространенность практики заметания мусора под ковер.
3. Несовместимость форматов: трудно вытащить из вики текст в требуемые проектные документы.
Это ограничение де-факто снято давным-давно с появлением архитектуры TTA. Поскольку исполнение генетических алгоритмов является одним из самых очевидных ее применений. Интересующимся этим вопросом будет нетрудно нарыть материалы в гугле, используя очевидные термины: genetic algorithms, transport triggered architecture.
Лично я не смог прочесть оигинальную статью ввиде незнания соответствующего языка. А во второй статье ценной информации нет. Но если оченивать сложность задачи, то для двух студентов 2-3 курса это очень хороший результат. В принципе, даже на дипломный проект мржет потянуть.
Мое личное мнение основано на моих личных наблюдениях. Но единственным аргументом здесь может быть только корректно поставленный эксперимент.
Лично я не имею времени и ресурсов на его проведение. Соответственно, я намерен ограничиться высказыванием своего личного мнения.
Возможно, я недостаточно внимательно прочел ваше письмо, но в нем я как рез аргументов и не вижу. Вижу только декларацию того, как, по вашему мнению, обстоит дело. Я верю, что вы действительно так считаете и потому сообщил о том, что это не вызывает у меня протеста. :)
Заполнение простоя это не многозадачность. Под многозадачностью следует понимать именно одновременное выполнение нескольких дел
Поскольку мозг работает одновременно и по-разному на разных уровнях, то это не просто заполнение. Утыкаясь в сложную проблему, я спустя какое-то время переношу ее "в фоновый режим". Верхний слой сознания продолжает заниматься активностью "переднего плана", что-то лежащее ниже работает над "отложенной задачей". Собственно, именно поэтому выбор "заполнителя" существенен для выполнения фоновой задачи.
Так что аналогия с написанием двух текстов двумя руками неуместна она предполагает загрузку двумя задачами одного и того же слоя сознания. А вот написание одной рукой текста и обдумывание в фоновом режиме спорной формулировки во втором разделе срабатывает хорошо.
Это очень хороший пример того, как результаты потенциально здравого и корректного научного исследования искажатся журналистами при публикации до полной потери здравого смысла.
Результаты эксперимента говорят вовсе не о том, что многозадачность вредна, а о том, что внешние раздражители отрицательно сказываются на выполнении работы, требующей концентрации внимания.
В действительности правильно организованная многозадачность повышает эффективность работы. Вот только многие путают многозадачность с неорганизованностью.
Когда человек прерывает работу над письмом клиенту, чтобы ответить на вопрос подошедшего коллеги, а разговор с ним чтобы ответить на телефонный звонок, то это не многозадачность, а раздолбайство.
Отправив на печать документ в 200 страниц вы будете 15 минут тупо бычить в монитор чтобы не приведи господь не случилось переключение контекста? Чушь. Остановка в работе сама по себе переключает контекст, причем зачастую сильнее, чем переход к другой деятельности. Ответив во время вынужденной паузы на письма вы эффективно используете свое время и снижаете эффект от переключения контекста.
Здесь важно, что письмами вы занялись потому, что возникла пауза в "задаче переднего плана", а не потому, что "возникло прерывание" и вас сдернули разбирать письма.
Применительно у упоминавшейся выше GTD, удобно иметь отдельный контекст для Action'ов, которые можно выполнять во время вынужденных простоев в основной задаче. Типа "почистить клавиатуру" или "сходить в бухгалтерию за справкой о доходах". Т.е., в дополнение к контексту @Office иметь @Office.Background.
В неоплачиваемом тендере участвуют только в следующих случаях:
1. Тендер объявлен гигантом уровня Газпрома и априори известно, что за реализацию проекта будет получено в 5-10 раз больше, чем это реально стоит. В этом случае дизайнерская контора сознательно идет на риск в надежде на сверхприбыль. Обе стороны это понимают.
2. Тендер рассчитан на участие пионэров от дизайна. В большинстве случаев это используется как cвоеобразный брейнстрминг и результаты будут просто переданы прикормленной заранее конторе, которая выигрывает тендер независимо от.
Я говорю о GTD, соответственно имеются в виду Action'ы. Посольку GTD'шные проекты задачам определенно не соответствуют. А других кандидатов на это звание я в GTD не вижу.
Как может тот кто добавил задачу, что задача выполнена?
Поскольку нет "универсального сценария делегирования", то в GTD нет и жесткой схемы обработки такой ситуации. Соответственно, алгоритм действий и требуемая программная поддержка определяются соглашениями среды. Примеры:
1. Делегируя задачу, указываем, что с ней делать после завершения. "Назначить встречу с Ивановым и сообщить мне дату", "Рассмотреть прилагаемую заявку и переслать ответ Петрову". В этом случае мы вообще не намерены непосредственно отслеживать состояние работы.
Это идеальный случай. Но если завершения данной работы ожидает другая наша активность или исполнителя требуется жестко контролировать, то вступаю в дело два других варианта:
2. Делегируя задачу, добавляем себе в "Waiting for" запись "Петров: Отчет о рассмотрении жалобы гражданки Сидоровой о покусании ея казенной собачкой". В этом случае мы рассматриваем состояние делегированных задач во время Review.
3. Делегируя задачу, добавляем себе в календарь или в тиклер задание проверить исполнение. Например: "1 июня 2007 проверить исполнение приказа о закупке намордников для казенных собак".
...кстати, замечание по опыту наблюдения за своими и чужими попытками: GTD не работает полноценно, если заниматься самообманом и часть дел оставлять вне системы.
P.S. Служба QA принимает только в DOC. :)
Самому делать геморройно.
Основные проблемы (кратко):
1. Программеры привыкли, что доки и прочии тексты нужно писать из под палки.
2. Распространенность практики заметания мусора под ковер.
3. Несовместимость форматов: трудно вытащить из вики текст в требуемые проектные документы.
Будем учиться на ошибках.
Это ограничение де-факто снято давным-давно с появлением архитектуры TTA. Поскольку исполнение генетических алгоритмов является одним из самых очевидных ее применений. Интересующимся этим вопросом будет нетрудно нарыть материалы в гугле, используя очевидные термины: genetic algorithms, transport triggered architecture.
Лично я не смог прочесть оигинальную статью ввиде незнания соответствующего языка. А во второй статье ценной информации нет. Но если оченивать сложность задачи, то для двух студентов 2-3 курса это очень хороший результат. В принципе, даже на дипломный проект мржет потянуть.
Лично я не имею времени и ресурсов на его проведение. Соответственно, я намерен ограничиться высказыванием своего личного мнения.
Возможно, я недостаточно внимательно прочел ваше письмо, но в нем я как рез аргументов и не вижу. Вижу только декларацию того, как, по вашему мнению, обстоит дело. Я верю, что вы действительно так считаете и потому сообщил о том, что это не вызывает у меня протеста. :)
Вы, бесспорно, имеете право на свое личное мнение.
Поскольку мозг работает одновременно и по-разному на разных уровнях, то это не просто заполнение. Утыкаясь в сложную проблему, я спустя какое-то время переношу ее "в фоновый режим". Верхний слой сознания продолжает заниматься активностью "переднего плана", что-то лежащее ниже работает над "отложенной задачей". Собственно, именно поэтому выбор "заполнителя" существенен для выполнения фоновой задачи.
Так что аналогия с написанием двух текстов двумя руками неуместна она предполагает загрузку двумя задачами одного и того же слоя сознания. А вот написание одной рукой текста и обдумывание в фоновом режиме спорной формулировки во втором разделе срабатывает хорошо.
Результаты эксперимента говорят вовсе не о том, что многозадачность вредна, а о том, что внешние раздражители отрицательно сказываются на выполнении работы, требующей концентрации внимания.
В действительности правильно организованная многозадачность повышает эффективность работы. Вот только многие путают многозадачность с неорганизованностью.
Когда человек прерывает работу над письмом клиенту, чтобы ответить на вопрос подошедшего коллеги, а разговор с ним чтобы ответить на телефонный звонок, то это не многозадачность, а раздолбайство.
Отправив на печать документ в 200 страниц вы будете 15 минут тупо бычить в монитор чтобы не приведи господь не случилось переключение контекста? Чушь. Остановка в работе сама по себе переключает контекст, причем зачастую сильнее, чем переход к другой деятельности. Ответив во время вынужденной паузы на письма вы эффективно используете свое время и снижаете эффект от переключения контекста.
Здесь важно, что письмами вы занялись потому, что возникла пауза в "задаче переднего плана", а не потому, что "возникло прерывание" и вас сдернули разбирать письма.
Применительно у упоминавшейся выше GTD, удобно иметь отдельный контекст для Action'ов, которые можно выполнять во время вынужденных простоев в основной задаче. Типа "почистить клавиатуру" или "сходить в бухгалтерию за справкой о доходах". Т.е., в дополнение к контексту @Office иметь @Office.Background.
1. Тендер объявлен гигантом уровня Газпрома и априори известно, что за реализацию проекта будет получено в 5-10 раз больше, чем это реально стоит. В этом случае дизайнерская контора сознательно идет на риск в надежде на сверхприбыль. Обе стороны это понимают.
2. Тендер рассчитан на участие пионэров от дизайна. В большинстве случаев это используется как cвоеобразный брейнстрминг и результаты будут просто переданы прикормленной заранее конторе, которая выигрывает тендер независимо от.
Это абсолютно неизбежно. И не думаю, что это случится позднее, чем через 1-2 недели.
Только мне непонятно, о каком рабочем процессе идет речь. GTD не является средством для упорядочивания рабочих процессов.
Поскольку нет "универсального сценария делегирования", то в GTD нет и жесткой схемы обработки такой ситуации. Соответственно, алгоритм действий и требуемая программная поддержка определяются соглашениями среды. Примеры:
1. Делегируя задачу, указываем, что с ней делать после завершения. "Назначить встречу с Ивановым и сообщить мне дату", "Рассмотреть прилагаемую заявку и переслать ответ Петрову". В этом случае мы вообще не намерены непосредственно отслеживать состояние работы.
Это идеальный случай. Но если завершения данной работы ожидает другая наша активность или исполнителя требуется жестко контролировать, то вступаю в дело два других варианта:
2. Делегируя задачу, добавляем себе в "Waiting for" запись "Петров: Отчет о рассмотрении жалобы гражданки Сидоровой о покусании ея казенной собачкой". В этом случае мы рассматриваем состояние делегированных задач во время Review.
3. Делегируя задачу, добавляем себе в календарь или в тиклер задание проверить исполнение. Например: "1 июня 2007 проверить исполнение приказа о закупке намордников для казенных собак".
Чего именно недостает в линейном списке?
И, кроме того, много места уделено именно разным оптимизационными ухищрениям.
Вы уверены, что прочтали книгу целиком? :)