Здравствуйте, IT, Вы писали:
G>>Ну так поробуй формализовать понятия "не делать ошибок" и "заведомо плохие варианты", получишь те самые метрики.
IT>Я не знаю как формализуются понятия "не делать ошибок" и "заведомо плохие варианты".
"Не делать ошибок" — вносить поменьше ошибок. "Заведомо плохие варианты" — варианты, которые придется в будущем затратно исправлять, и эти проблемы в состоянии определить design review.
G>>Любое планирование будет метафизикой если не использовать метрики.
IT>Вообще-то речь не о планировании, а о выборе наиболее оптимального варианта.
Если выбор твоего варианта определяет дальнейшие действия (как например, архитектурные и "дизайнерские" технические решения), то это и есть по своей сути планирование. Ибо, при выборе ты должен учитывать эти самые дальнейшие действия.
Планирование вообще неразрывно связано с архитектурной работой.
Здравствуйте, Gaperton, Вы писали:
IT>>Вообще-то речь не о планировании, а о выборе наиболее оптимального варианта.
G>Если выбор твоего варианта определяет дальнейшие действия (как например, архитектурные и "дизайнерские" технические решения), то это и есть по своей сути планирование. Ибо, при выборе ты должен учитывать эти самые дальнейшие действия.
G>Планирование вообще неразрывно связано с архитектурной работой.
Вообще, меня не перестает изумлять, до какой степени упорно инженеры, занимаясь планированием каждый день, любят от этого дистанцироваться, называя планирование "менеджерской работой".
Я случай расскажу.
Однажды одному разработчику фокус показал. Сначала, я спросил его прогноз сроков по его проекту. Он сказал — полгода. Потом, я предложил ему обсудить подход в этом проекте, который определяет план. Он ответил, что планы должен составлять менеджер, а подходы — это их, инженеров дело.
Хорошо, сказал я, и попросил его написать список задач в экселе, из которых я сделаю план. Он написал.
Потом, я попросил его оценить сроки каждой задаче в днях. Разработчик сказал, что это невозможно. Тогда, я предложил ему ответить для каждой задачи на пару вопросов — "точно не справлюсь" — "успею с запасом". Он сделал и это.
После этого, я загнал эту сотню задач в MS Project, и ввел туда среднюю оценку. Выполнил шедулинг, и позвал разработчика посмотреть на результат.
— Че мне смотреть, это ж ваше, менеджерское — планы?
— Да все бы ничего, да вот только мне мой менеджерский план показывает, что ты не успеешь за полгода. В лучшем случае — полтора.
— Как это?!
— Вот, смотри. Я ничего не выдумал — взял твои задачи, и твои оценки. Все остальное — MS Project. Ты ведь уверен в своих оценках?
— Уверен.
— Ну вот я тебе говорю — если сейчас не изменить технический подход к решению, то это полтора года. Ты ведь понимаешь, что результат этого проекта ценой в полтора года никому не нужен?
— Конечно.
— Так что будем делать, дружище? Закрывать проект, или вместе подумаем, как изменить подход?
И вы знаете — как-то ВНЕЗАПНО план перестал быть "нашим менеджерским", и оторванным от проектирования и технических решений .
ЗЫ: В этой компании сроки регулярно в 10 раз срывались — обычное дело. Там мне директор задачу поставил при найме — сократить underestimate в группе разработки до двух раз. Лекарство и одну из причин "болезни" вы видите.
Здравствуйте, Silver_s, Вы писали:
G>>Составил план работ. Нарисовал кривую — общее количество (нарастающим итогом) закрытых задач понедельно, на основании плана. И каждую неделю наносишь на этот же график новую точку фактической кривой — с общим количеством фактически закрытых задач. S_>... G>>Я тебе простейший вариант планирования с учетом метрик дал. Есть другие.
S_>Планирования чего? Архитекутры приложения, или уровня загруженности конвеера(массива разработчиков), с целью уменьшения простоев и слабых мест.
В разработке ПО архитектура и прочие высокоуровневые технические решения оказывают определяющее влияние на план работ.
Также, в разработке софта указанный тобой "конвейерный эффект" мизерный, и возникает настолько редко, что этим в большинстве ситуаций можно пренебречь. И пренебрегают.
S_>А если надо определиться в том что использовать WPF или WinForms. Или боле того, надо писать подобную библиотеку. Какую архитектуру выбрать как у WinForms или как WPF. Планирование уровня загруженности разработчиков уже будет недостаточно?
В представленной схеме вопросы "шедулинга" и уровня загруженности разработчиков оставлены за кадром, что, в общем, сложно не заметить.
А вот выбор базовых технологий — имеет настолько серьезные последствия, и настолько сильно повлияет на все планы, что не принимать во внимание влияние на будущее (т.е. планы не только текущих, но и будущих работ), делая этот выбор, будет клиническим идиотизмом.
Почему бывает, что на практике этот выбор и не предоставляют делать кому попало, и настолько часто, насколько этому кому-попало хочется.
Здравствуйте, Silver_s, Вы писали:
G>>Ты откуда планирование загруженности взял? S_>Там было про график работ, распределение задач, оценку производительности, управление сроками.
Там не было про распределение задач и планирование загруженности. Из чего следует, что ты не читал, что там было.
S_>А если это все неактуально, а нужно в первую очередь узнать нужно ли вобще такую-то задачу решать, или лучше совсем другую.
Если "это все" для принимающего решения, имеющие далеко идущие последствия, не актуально, то ему следует поискать другую работу.
Здравствуйте, Silver_s, Вы писали:
I>>Вообще говоря дело именно в том, сколько ошибок на единицу кода делает основная масса программистов. I>>Косяки и возможности фреймворков — это уже второстепенное.
S_> Неправильный выбор фреймворка или библиотеки, или крупные архитектурные ошибки, это к тем же ошибкам причисляется о которых идет речь? Или механические ошибки-описки имеются ввиду?
Разумеется — да. И ошибочное представление о требованиях также причисляется к ошибкам. Или ты думаешь, что в технических решениях ты никогда не ошибаешься, только механические описки допускаешь?
Ошибочный (неоптимальный) выбор фрейморка (базовых технологий) сейчас, может сделать невероятно затратным реализацию ключевых требований потом, или ограничить принципиальные возможности. Повлияв, таким образом, не только на текущий "план", но и на все последующие.
Поэтому, к выбору базовых технологий надо относиться серьезно, обязательно делать это группой, и, для начала, как минимум, согласиться насчет критериев выбора этих самых базовых технологий, что уже веха в плане. Далее — можно рассмотреть несколько кандидатов, отобрать из них парочку наилучших, и их уже пустить в детальную проработку с разработкой "эскизного проекта", PoC прототипов, и — планов дальнейших работ. После чего уже — можно сделать аргументированный выбор.
Заметь, я уже набросал некий план, т.е. подход к проведению организованного исследования. Впрочем, ничего особо не выдумывал — это распространенный "паттерн" планирования в советской конструкторской школе при проведении НИОКР.
План — это что именно и в каком порядке ты собираешься делать, и каким образом проверять, что таки сделал. Качество плана вообще — показывает, насколько осмысленно ты подходишь к своей работе. Если он для тебя — абстрактная хрень, сводящаяся к оптимизации конвейера — ну тут, собственно, "nuff said". Это можно позволить себе работая индивидуально. Но для работы группы с мало-мальски нормальным КПД — требуется согласованность и целенаправленность действий. Для чего и нужен план.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
IT>>>>>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. I>>>>Ты уже в который раз вместо указания конкретных фактов используешь эмоциональную оценку.
IT>>>Я уже в который раз пытаюсь кое-кому объяснить, что эмоциональная оценка такие же конкретные факты, как и всё остальное.
G>>Сложной от эмоций не зависит.
G>Если рассматривать отношение метрик объем/время как характеристику сложности, то совершенно объективно — сложность зависит от эмоций. И иногда — очень сильно. G>http://gaperton.livejournal.com/50685.html
G>А вот если не рассматривать — то можно вообще что угодно говорить. Метафизика.
А разве мы еще не договорились считать сложность неким "объективным фактором", а не трудозатратами (которые вообще дофига от чего зависят)?
Здравствуйте, gandjustas, Вы писали:
G>>А вот если не рассматривать — то можно вообще что угодно говорить. Метафизика.
G>А разве мы еще не договорились считать сложность неким "объективным фактором", а не трудозатратами (которые вообще дофига от чего зависят)?
Вобще говоря есть такой момент, многие гроссы, имеется ввиду шахматисты или игроки в настольных играх такого же уровня, очень часто не могут внятно объяснить свое видение позиции в партии.
В книгах, статьях, используют не конкретные проверяемые утверждения, а какой то эмоциональный бред.
Вот, по памяти: "этот ход однозначно вялый. Запомните — вы так никогда играть не будете !".
Про тот же ход "цель этого хода — не дать никакой помощи противнику".
И только редкие игроки того же уровня, их буквально единицы, суровые методисты, про тот же ход пишут достаточно скучкно, приводят варианты, где эмоциональные оценки отсутсвуют, комантарии примерно такие "цель хода — избежать локальной борьбы и форсированых вариантов(варианты указаны)".
Правда и те и другие и третьи во сложных(для них) позициях, используют именно интуитивные оценки "чуть-чуть", "неудобно", "туманно", "слабо".
Кроме того, некоторые в комментариях заходят еще дальше — буквально рассказывают, что происходит в партии, как в анекдоте
"- Где мы находимся, Холмс ?
— В воздушном шаре, Ватсон !"
Кстати, сейчас вспомнил. У этой истории было смешное продолжение. Проект я таки в результате закрыл. А дело было так.
Сначала, поработав над подходом, мы сократили затраты на этот проект втрое. Удалось это сделать благодаря тому, что инженер взял себя в руки, и отказался от "переписывания всего-превсего", и разбиению этого переписывания на итерации, результат каждой из которых фиксируется в репозитории.
Это что-то вроде lazy evaluation. Мы выписываем фичлист, и проектируем минимальную правку, с серией мостов, откладывая "полный рефакторинг" на те моменты, когда в соответствующую подсистему будет реально нужна какая-нить правка.
Так вот, когда я выписывал для этого проекта фичлист, он оказался, к моему удивлению, весьма небольшим. В основном, это было две полезных фичи — поддержка кнопок Hold и Transfer на IP-телефоне.
Ну ладно. И вот, однажды к нам зашли сейлзы, и стали чуть не на коленях умолять — так или иначе дать возможность перевода звонка с терминала в IP-АТС. У них клиент был с DECT-трубками, хотел IP-коллцентр, и отказывался без этих элементарных фич брать продукт.
Наши орлы говорят — нет, грят, низя, дождитесь мегапроекта. Тут я решил вмешаться.
— Парни, — говорю, — так на DECT-телефонах все равно ведь нет кнопок Hold и Transfer.
— Ну? — говорят разработчики.
— Так и на обычных телефонах их тоже нет. Но с обычными-то телефонами у нас все работает! Расскажите, как.
Парни рассказали, что на то в обычных телефонах есть кнопка Flash, но этой кнопки нет в IP-телефонах. Поэтому, в IP-версии данный код тупо выключен.
— Отлично, — говорю, — давайте эмулировать Flash даблкликом звездочки. Сейлзы, вас это устроит?
Сейлзы на все готовы. Да, грят, нам хоть как.
— Скока, — говорю, — времени надо, чтобы это сделать?
— Да дня два, — говорят инженеры.
И мы сделали. После чего я смотрю, и совсем не понимаю, нахрена нам тратить полгода на кнопки Hold и Transfer. Особенно, когда в бэклоге висит ряд других фич, из-за отсутствия которых недавно был проигран тендер Циске.
Как нибудь в другой раз, короче. Так и закрыли нафиг.
Здравствуйте, Gaperton, Вы писали:
G>Почитай, что мы, менеджеры, пишем про эмоциональную оценку. Будет интересно. Примерь на себя. G>http://gaperton.livejournal.com/50685.html G>Hint: некоторые из нас, менеджеров, не боятся "грязной работы", и иногда устраивают себе испытание: заставляют себя тряхнуть стариной, и в полный рост кодить. Из принципа, чтобы не отрываться от реальности. Редкость, но бывает, ага. И тогда появляются такие статьи.
Насчет классификации проблем вот тут http://kapterev.livejournal.com/496630.html есть интересный график
То есть по мнению психологов "интересные проблемы" хорошо вознаграждаются на физиологическом уровне — состоянием потока.
Хорошо..... Кажется, мой поток мыслей на сегодня иссяк. И этому я тоже рад: выходить из потока – полезный навык.
График на ту же тему. Но моя классификация, вообще-то, лучше. Она куда более специфична, информативна, и при этом ощущается человеком непосредственно, без рассуждений (не надо ничего иллюстрировать). И даже через метрики наблюдаема, и имеет прямую связь с техниками риск-менеджмента . То есть, легко интегрируется в работу. Ей легко воспользоваться на практике, этим графиком — нет. А понимание требуется для действия. Ни для чего другого.
FR>То есть по мнению психологов "интересные проблемы" хорошо вознаграждаются на физиологическом уровне — состоянием потока.
Я бы не сказал, что состояние "потока" само по себе является вознаграждением. Это далеко не элементарное состояние, и оно слишком сложное, чтобы непосредственно участвовать в цепочке стимул-реакция.
Вознаграждением является удовлетворение от решения каждой отдельной проблемы и задачи. Для "понятной" проблемы оно слишком слабо, для "принципиальной" — слишком нерегулярно и редко случается, пока его получишь — успеешь отчаяться. И на подпроблемы не всегда удается сходу побить, чтобы словить кайф на них.
Само состояние "потока" — это далеко не элементарный процесс непрерывного получения значимого вознаграждения. То есть, производное, сложное состояние. И оно не является устойчивым состоянием.
И вообще — по употреблению характерных слов вроде "картируется", становится ясно, что по ссылке не психологи, а мимикрирующие под них нлпсты . А это очень большая разница. Бросьте каку.
Читать надо гештальтистов и бихейвиористов. Это гораздо сложнее, но — и "вознаграждение" гораздо больше. Описанием творческой деятельности, озарений, и свободно перетекающего внимания занимается гештальт, стимул-реакциями — бихейвиористика.
Здравствуйте, gandjustas, Вы писали:
G>>Если рассматривать отношение метрик объем/время как характеристику сложности, то совершенно объективно — сложность зависит от эмоций. И иногда — очень сильно. G>>http://gaperton.livejournal.com/50685.html
G>>А вот если не рассматривать — то можно вообще что угодно говорить. Метафизика.
G>А разве мы еще не договорились считать сложность неким "объективным фактором", а не трудозатратами (которые вообще дофига от чего зависят)?
Черт его знает, наверное это без меня было .
"Сложность" — это не фактор, а интуитивная, субъективная интегральная оценка "геморройности". Выделять объективные факторы, которые на эту оценку влияют, можно.
Считать же саму "сложность" объективным фактором, очевидно нельзя. Начать можно с того, что "сложность" не элементарная характеристика, а результат многофакторной оценки. И продолжить тем, что находясь в разном эмоционально-психическом состоянии человек по разному оценивает "сложность" одной и той же задачи, по разному расставляя "веса" в своей формуле. Военным это хорошо знакомо — они учитывают как фактор "боевой дух", и его влияние оценивается некоторыми специалистами чуть ли не как 3:1 ко всем прочим.
Здравствуйте, Gaperton, Вы писали:
G>"Сложность" — это не фактор, а интуитивная, субъективная интегральная оценка "геморройности".
При всем при том, эта самая сложность коррелирует с объективно измеримым отношением "время/объем". Которое называется не "сложностью", а "продуктивностью". И косвенно характеризуется этим соотношением.
Не, ну можно было бы сказать "вы программеры, ничего в сложности не понимаете, мы лучше знаем, что это за слово такое и что оно означает". Но это было бы чепухой. Смысл слова лучше оставить фактический, такой, какой он есть по частоте употребления .
Здравствуйте, Gaperton, Вы писали:
G>График на ту же тему. Но моя классификация, вообще-то, лучше. Она куда более специфична, информативна, и при этом ощущается человеком непосредственно, без рассуждений (не надо ничего иллюстрировать). И даже через метрики наблюдаема, и имеет прямую связь с техниками риск-менеджмента . То есть, легко интегрируется в работу. Ей легко воспользоваться на практике, этим графиком — нет. А понимание требуется для действия. Ни для чего другого.
Угу лучше. Но если переживал поток график вызывает сильный эмоциональный отклик
FR>>То есть по мнению психологов "интересные проблемы" хорошо вознаграждаются на физиологическом уровне — состоянием потока.
G>Я бы не сказал, что состояние "потока" само по себе является вознаграждением. Это далеко не элементарное состояние, и оно слишком сложное, чтобы непосредственно участвовать в цепочке стимул-реакция.
Физиологи практически установили что
Особенность лиц, имевших признаки состояния «потока» состояла в значительно меньшей физиологической цене деятельности.
Так что награда есть и вполне осязаемая, кто испытывал "второе дыхание" сразу поймет
G>Вознаграждением является удовлетворение от решения каждой отдельной проблемы и задачи. Для "понятной" проблемы оно слишком слабо, для "принципиальной" — слишком нерегулярно и редко случается, пока его получишь — успеешь отчаяться. И на подпроблемы не всегда удается сходу побить, чтобы словить кайф на них.
G>Само состояние "потока" — это далеко не элементарный процесс непрерывного получения значимого вознаграждения. То есть, производное, сложное состояние. И оно не является устойчивым состоянием.
Да это конечно комплексное состояние, мне кажется оно сейчас просто позабыто и во многом атрофировалось, но вполне могло играть
гораздо большую роль в ранних стадиях развития человечества.
А так да положится на него особо не получится.
G>И вообще — по употреблению характерных слов вроде "картируется", становится ясно, что по ссылке не психологи, а мимикрирующие под них нлпсты . А это очень большая разница. Бросьте каку.
По моему все психологи немного шаралатаны
G>Читать надо гештальтистов и бихейвиористов. Это гораздо сложнее, но — и "вознаграждение" гораздо больше. Описанием творческой деятельности, озарений, и свободно перетекающего внимания занимается гештальт, стимул-реакциями — бихейвиористика.
Гештальт да вещь хорошая, а бихевиоризм во многом как раз самая кака и есть, ну бестолково такие сложные вещи изучать методом черного ящика,
лучше уж физиологов почитать, к примеру того же Бернштейна у него хоть вполне рабочие модели подкрепленные фактами.
Здравствуйте, Gaperton, Вы писали:
G>Считать же саму "сложность" объективным фактором, очевидно нельзя. Начать можно с того, что "сложность" не элементарная характеристика, а результат многофакторной оценки.
Если из этих факторов убрать эмоциональные что получится?
Здравствуйте, gandjustas, Вы писали:
G>>Считать же саму "сложность" объективным фактором, очевидно нельзя. Начать можно с того, что "сложность" не элементарная характеристика, а результат многофакторной оценки. G>Если из этих факторов убрать эмоциональные что получится?
Зачем их убрать, если они полезны, и их можно учитывать? Для нового кода работает оно примерно так:
Набор объективных фактов -> (логические рассуждения) -> (индивидуальная оценочная функция на базе опыта, "сложность" и эмоции где-то внутри) -> Оценка вариации сроков, объема результата, + эмоциональная оценка "геморройности", которую ты получаешь бесплатно — на халяву. Хочешь ты этого, или нет. Эмоции все равно испытываешь.
Теперь, с предыдущих проектов берешь вариацию время/объем. Эта штука будет колебаться в диапазоне — его, диапазон, ты из истории и берешь.
А далее смотришь — твой запланированный коэффициент время/объем соответствует интуитивной оценке "геморройности", или нет. Если задача кажется тебе "геморройной", а запланированный коэффециент строки кода/час такой, что ты должен колбасить с олимпиадной скоростью (для меня это более 60 строк кода в час), то ты явно где-то в своей оценке ошибся.
И нафига мне такую ценную штуку убирать, которая позволяет технические риски буквально задницей чувствовать?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>>Считать же саму "сложность" объективным фактором, очевидно нельзя. Начать можно с того, что "сложность" не элементарная характеристика, а результат многофакторной оценки. G>>Если из этих факторов убрать эмоциональные что получится?
G>Зачем их убрать, если они полезны, и их можно учитывать? Для нового кода работает оно примерно так:
G>Набор объективных фактов -> (логические рассуждения) -> (индивидуальная оценочная функция на базе опыта, "сложность" и эмоции где-то внутри) -> Оценка вариации сроков, объема результата, + эмоциональная оценка "геморройности", которую ты получаешь бесплатно — на халяву. Хочешь ты этого, или нет. Эмоции все равно испытываешь.
G>Теперь, с предыдущих проектов берешь вариацию время/объем. Эта штука будет колебаться в диапазоне — его, диапазон, ты из истории и берешь.
G>А далее смотришь — твой запланированный коэффициент время/объем соответствует интуитивной оценке "геморройности", или нет. Если задача кажется тебе "геморройной", а запланированный коэффециент строки кода/час такой, что ты должен колбасить с олимпиадной скоростью (для меня это более 60 строк кода в час), то ты явно где-то в своей оценке ошибся.
G>И нафига мне такую ценную штуку убирать, которая позволяет технические риски буквально задницей чувствовать?
Это я и так отлично знаю.
Меня интересует другое. "Сложность" существует объективно, вот и хочется понять какие факторы влияют на нее. И как можно бороться с объективной сложностью, чтобы минимизировать итоговые метрики "объем", "время", "плотность ошибок"
Здравствуйте, FR, Вы писали:
FR>Угу лучше. Но если переживал поток график вызывает сильный эмоциональный отклик
Возможно. У меня не вызывает . Хотя закономерность он, безусловно, иллюстрирует наглядно. Ибо график.
FR>>>То есть по мнению психологов "интересные проблемы" хорошо вознаграждаются на физиологическом уровне — состоянием потока.
G>>Я бы не сказал, что состояние "потока" само по себе является вознаграждением. Это далеко не элементарное состояние, и оно слишком сложное, чтобы непосредственно участвовать в цепочке стимул-реакция.
FR>Физиологи практически установили что
FR>
FR>Особенность лиц, имевших признаки состояния «потока» состояла в значительно меньшей физиологической цене деятельности.
Здесь не идет речи о награде. Здесь они нудно описывают наблюдаемые особенности физиологии, не осознаваемые испытуемым, перечисляя установленные ими факты.
Вывод-то вот он:
Причина указанного парадокса прояснилась при изучении ритма и временных характеристик фаз дыхательного цикла. Оказалось, что характер дыхания у выделенной группы лиц имел признаки «связности», вывод о чем можно сделать из значений вариативности дыхательного ритма, которая была более чем в 2 раза ниже, и продолжительности выдоха, которая была на 65–90% выше, при практически прежней частоте дыхания.
Далее, углубившись в анализ ЭЭГ и альфа-ритмов, и накидывая over 9000 умняка, чтобы усыпить бдительность читателя и навести легкий транс, автор статьи ВНЕЗАПНО вдруг говорит:
Таким образом, результаты М. Чиксентмихайи могут быть дополнены еще одним элементом, который может быть использован сознательно для вызывания состояния «потока». Используя терминологию нейро-лингвистического программирования, можно сказать, что связное дыхание служит при этом для «якорения» состояния «потока». Более того, существует реальная возможность создавать физиологические и нейропсихологические предпосылки для вызывания ресурсных, творческих состояний личности – процессы осознанного связного дыхания.
Что представляет собой полный бред, который автор даже не потрудился как-то обосновать. Ибо перед этим он вещал:
Вскоре после этих исследований в русле идей биологической обратной связи были разработаны портативные приборы, осуществляющие стимуляцию мозга через электрические датчики, наушники и светодиоды.
Оказалось возможным навязывание мозгу человека ритмов, характерных для разных состояний сознания. Например, низкий бета-ритм частотой 15 Гц...
G>>Вознаграждением является удовлетворение от решения каждой отдельной проблемы и задачи. Для "понятной" проблемы оно слишком слабо, для "принципиальной" — слишком нерегулярно и редко случается, пока его получишь — успеешь отчаяться. И на подпроблемы не всегда удается сходу побить, чтобы словить кайф на них.
G>>Само состояние "потока" — это далеко не элементарный процесс непрерывного получения значимого вознаграждения. То есть, производное, сложное состояние. И оно не является устойчивым состоянием.
FR>Да это конечно комплексное состояние, мне кажется оно сейчас просто позабыто и во многом атрофировалось, но вполне могло играть FR>гораздо большую роль в ранних стадиях развития человечества. FR>А так да положится на него особо не получится.
Это комплексное состояние, оно неустойчиво, и его нельзя вызвать "якорями" и какими-либо другими заклинаниями. Так же бессмысленно и глупо, как и вызвать ощущение радости от победы.
Вы "полагаетесь" на "ощущение победы", которое дает заряд бодрости и прилив новых сил? Оно "позабыто" и атрофировалось? Может быть, для него нужны сложная психология, и физиологи с аппаратами?
Или для того, чтобы вызвать это ощущение — надо победить, черт бы его побрал?
Так же и для поддержания состояния "потока" нужны не альфа ритмы и особое дыхание. Человек не система веревочек, за которые можно тупо дергать. Нужен набор факторов, поддерживающих спонтанный интерес и свободно перетекающее внимание. Следствием этого являются возбуждение, особенности дыхания, и прочие вещи, которые увлеченно наблюдает автор статьи, делая из бодрый вывод, что "таракан слышит ногами".
"Практика гештальт-терапии", Фриц Перлз, читаем вводные главы, где он про фигуру-фон и основы гештальт-психологии рассказывает. Все понятно будет.
G>>И вообще — по употреблению характерных слов вроде "картируется", становится ясно, что по ссылке не психологи, а мимикрирующие под них нлпсты . А это очень большая разница. Бросьте каку.
FR>По моему все психологи немного шаралатаны
НЛПсты не психологи. Они такие же психологи, как продавцы скрама специалисты по процессам разработки, а продавцы пищевых добавок — фармацевты. НЛП — это инфраструктура по зарабатыванию бабла, а не наука.
G>>Читать надо гештальтистов и бихейвиористов. Это гораздо сложнее, но — и "вознаграждение" гораздо больше. Описанием творческой деятельности, озарений, и свободно перетекающего внимания занимается гештальт, стимул-реакциями — бихейвиористика.
FR>Гештальт да вещь хорошая, а бихевиоризм во многом как раз самая кака и есть, ну бестолково такие сложные вещи изучать методом черного ящика,
С когнитивными психологами бихейвиористов не путаете? Нет у них никакого черного ящика. Методы бихейвиористов основаны на модели психики, в основе которой лежит система условных рефлексов. В частности, "непавловском условном рефлексе". И в своем классе ситуаций бихейвиористика потрясающе эффективна — напоминает магию. НЛПстам не снилось. Собственно, НЛП сдернуло большую часть именно у бихейвиористов, выкинув при этом всю теоретическую базу.
FR>лучше уж физиологов почитать, к примеру того же Бернштейна у него хоть вполне рабочие модели подкрепленные фактами.
Это примерно так же продуктивно, как пытаться реверс-инжинирить оперсистему Windows, копаясь на уровне транзисторов, замера времянок, и спиливания печатной платы по слоям.
Скажем, практический интерес представляет "мышечный панцирь", и, в частности, связь переживания тревожности с неконтроллируемым напряжением диафрагмы. Связь есть, она экспериментально наблюдается, она двухсторонняя, и этим можно пользоваться.
А что там происходит с точки зрения физиологии при переживании тревожности — абсолютно по барабану. Понимание, совершенно лишнее для действия.
Здравствуйте, Gaperton, Вы писали:
IT>>Всё правильно. Я бы только ещё добавил категорию задач, которые являются заведомо геморройными и тогда картина будет полной. G>Как эти задачи отличить от приводимых трех типов?
Отношением к ним.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
IT>>Молодца! Мой босс тоже периодически тренирует польчики, чтобы не забыть как код писать G>Ну, тебе тоже надо иногда руководить . Не менее полезно для познания реальности во всех ее гранях.
Я уже своё отруководил. Лет 6 начальником группы/сектора в одном НИИ, потом 4 года начальником отдела разработки ПО в одной программистской конторе. В целом — не понравилось Руководить людьми не моё.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Всё правильно. Я бы только ещё добавил категорию задач, которые являются заведомо геморройными и тогда картина будет полной. G>>Как эти задачи отличить от приводимых трех типов?
IT>Отношением к ним.
Приведи пожалуйста пример "заведомо геморройной" задачи, не подпадающей ни под один из трех типов.
Если нам не помогут, то мы тоже никого не пощадим.
