У меня есть некий разработчик, которого я хочу научить самостоятельно выявлять причины дефектов ПО и устранять их.
То есть, чтобы я мог дать ему симптомы проблемы, а от него получить диагноз и разумные предложения по её устранению.
Сейчас мне приходится объяснять ему банальные вещи:
*) Что не имеет смысла мучить код, если ты не понимаешь, чего хочешь от него добиться
*) Что сначала надо поставить диагноз, потом проверить его и только после этого устранять и т. п.
Я уже давно в разговорах с ним говорю про все эти вещи в надежде на то, что в один прекрасный день он просечёт принцип и сам сможет выполнять указанные умственные операции.
Надежды не оправдываются. Его способ работы не улучшается.
Мне иногда приходится заниматься микроменеджментом — за ручку вести его к решению проблемы. Это всё очень сильно изнуряет.
Вопрос: Как можно научить его систематически (а не хаотично, мол дебажу отсюда и до обеда) устранять ошибки в коде, при условии, что
а) это человек из азиатской культуры,
б) я общаюсь с ним по скайпу в режиме чата и
в) я не хочу применять давление
?
Примечание: Это не проблема менталитета, т. к. другие люди из этого же региона работают достаточно хорошо (мне не надо строить/микроменеджить их).
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Сейчас мне приходится объяснять ему банальные вещи:
ДП>*) Что не имеет смысла мучить код, если ты не понимаешь, чего хочешь от него добиться ДП>*) Что сначала надо поставить диагноз, потом проверить его и только после этого устранять и т. п.
Эти навыки закладываются в возрасте седьмого класса.
Так что плюнь — этого человека ты не научишь, тем более дистанционно.
Самое гуманное, что ты можешь делать — перевести его на другую работу.
ДП>Мне иногда приходится заниматься микроменеджментом — за ручку вести его к решению проблемы. Это всё очень сильно изнуряет.
Вопрос: если ему предоставить возможность сделать всё от начала до конца без "помощи" (дёргания за рукав на "неправильных" промежуточных шагах), он справляется? Посмотрите на тему различия в восприятии у сенсориков и интуитивов.
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
Здравствуйте, Osaka, Вы писали:
ДП>>Мне иногда приходится заниматься микроменеджментом — за ручку вести его к решению проблемы. Это всё очень сильно изнуряет.
O>Вопрос: если ему предоставить возможность сделать всё от начала до конца без "помощи" (дёргания за рукав на "неправильных" промежуточных шагах), он справляется?
Нет. Если его не проверять, то он отметит задачу как выполненную, а на самом деле она не будет сделана так, как было оговорено ранее.
Критерии достижения цели в процессе не меняются и прописаны достаточно чётко.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Надежды не оправдываются. Его способ работы не улучшается.
Т.е. он как не мог фиксить баги, так и не научился?
Или тебя не устраивает то, как он это делает?
Если первое, то думаю ты ничего сделать не сможешь.
Максимум — это пару раз самому вместе с ним сделать работу.
Ну а далее либо он сам со временем "врубится", либо просто не дано.
Ну а если второе, то тут тебе самому над собой надо работать
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Здравствуйте, Osaka, Вы писали: ДП>>>Мне иногда приходится заниматься микроменеджментом — за ручку вести его к решению проблемы. Это всё очень сильно изнуряет. O>>Вопрос: если ему предоставить возможность сделать всё от начала до конца без "помощи" (дёргания за рукав на "неправильных" промежуточных шагах), он справляется?
ДП>Нет. Если его не проверять, то он отметит задачу как выполненную, а на самом деле она не будет сделана так, как было оговорено ранее. ДП>Критерии достижения цели в процессе не меняются и прописаны достаточно чётко. ДП>Всего доброго ДП>Дмитрий
Ситуация очень похожа на ту, что наблюдается в нашем коллективе: молодой программист лихо закрывал таски одну за другой, которые приходилось возвращать на доработку по нескольку раз, прежде чем закрыть.
И работал по принципу: "Делаю от сих до сих, а дальше — не моя область".
Уже были настроения его увольнять как приносящего больше проблем, чем пользы.
Но примерно через год работы начал исправляться, проваленных тестов всё меньше.
Почему? "Въехал в тему"? — Это кардинально не исправляет.
Единственное объяснение нахожу: постоянное давление со стороны коллег (замечания, недовольство без грубостей, похвала за удачу), пример ответственного подхода к работе в противовес его разгильдяйству, демонстрирование ему важности цели — сдача сложного проекта солидному заказчику и т.п.
Подобно тому, как взрослые прививают маленьким детям основы правильного взаимодействия вопреки их природной эгоистичности.
Окружение — великая сила!
Он даже уходить с работы стал не по часам, а по ситуации в работе, и по выходным вкалывает.
Ваше воздействие и наука, конечно, играют положительную роль, но окупятся ли Ваши усилия в разумные сроки, если в его ближайшем окружении нет примеров, достойных подражания (а может, даже совсем наоборот)?
В любом случае, классно, что Вы стараетесь найти решение
С большим уважением,
Игорь
Здравствуйте, Igro K., Вы писали:
IK>Уже были настроения его увольнять как приносящего больше проблем, чем пользы. IK>Но примерно через год работы начал исправляться, проваленных тестов всё меньше.
"Академиком может стать каждый, только одному для этого нужно тридцать лет, другому — триста" (c) Какой-то учёный. Твоему орлу понадобилось условно 60 лет. А разработчику топик-стартера может понадобится все 250.
ЗЫ. Если человек не способен понять проблему, а тупо уговаривет код работать, то лучше с таким не иметь дела. Особенно, если это не вчерашний студент.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Надежды не оправдываются. Его способ работы не улучшается.
Делал попытки научить пару таких людей — безуспешно. При разборе полетов все понимает правильно, как надо было поступать и почему, но в работе это применить не додумывается. Учитывая, что другие при этом — додумывались, я думаю им просто не хватает способностей к этому виду деятельности, и поправить тут ничего нельзя, по крайний мере за приемлемый срок.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Здравствуйте!
ДП>У меня есть некий разработчик, которого я хочу научить самостоятельно выявлять причины дефектов ПО и устранять их.
ДП>То есть, чтобы я мог дать ему симптомы проблемы, а от него получить диагноз и разумные предложения по её устранению.
ДП>Сейчас мне приходится объяснять ему банальные вещи:
ДП>*) Что не имеет смысла мучить код, если ты не понимаешь, чего хочешь от него добиться ДП>*) Что сначала надо поставить диагноз, потом проверить его и только после этого устранять и т. п.
ДП>Я уже давно в разговорах с ним говорю про все эти вещи в надежде на то, что в один прекрасный день он просечёт принцип и сам сможет выполнять указанные умственные операции.
ДП>Надежды не оправдываются. Его способ работы не улучшается.
ДП>Мне иногда приходится заниматься микроменеджментом — за ручку вести его к решению проблемы. Это всё очень сильно изнуряет.
ДП>Вопрос: Как можно научить его систематически (а не хаотично, мол дебажу отсюда и до обеда) устранять ошибки в коде, при условии, что
ДП>а) это человек из азиатской культуры, ДП>б) я общаюсь с ним по скайпу в режиме чата и ДП>в) я не хочу применять давление
ДП>?
ДП>Примечание: Это не проблема менталитета, т. к. другие люди из этого же региона работают достаточно хорошо (мне не надо строить/микроменеджить их).
Попросите его описать в письме, чем он хотел бы заниматься. Может быть, стоит подобрать что-то, что ему больше по душе? Он же на кого-то учился, писал диплом на какую-то тему, ходил добровольно на какие-то курсы — наверняка он для себя решил, что ему нравится, а что нет.
У вас описан человек, занимающийся противной ему работой. Ждать от него энтузиазма — по моему, не стоит. Либо смените тип его занятий, либо, если это невозможно — замените самого человека. Не портите ему дальнейшую жизнь, да и себе тоже.
Если будет мучить совесть — оплатите его обучение за пару-тройку недель в том направлении, какое ему нравится (конечно, если это не SAP
Здравствуйте, Igro K., Вы писали:
IK>Ситуация очень похожа на ту, что наблюдается в нашем коллективе: молодой программист лихо закрывал таски одну за другой, которые приходилось возвращать на доработку по нескольку раз, прежде чем закрыть. IK>И работал по принципу: "Делаю от сих до сих, а дальше — не моя область". IK>Уже были настроения его увольнять как приносящего больше проблем, чем пользы. IK>Но примерно через год работы начал исправляться, проваленных тестов всё меньше. IK>Почему? "Въехал в тему"? — Это кардинально не исправляет.
Сработался просто. Команды разные, у вас поощряют лезть в чужую область, а где-то за это могут и нахлобучить. Ну и задачи можно закрывать на разных стадиях: сделано, не проверялось; проходит девелоперский тест; проходит набор тестов QA; соответствует best practices, покрыто тестами и документировно и т.п. Человек просто привык к вашим требованиям и стал соответствовать. Даже прекрасным программистам на первых code review достаются замечания, это нормально.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Как можно научить его систематически (а не хаотично, мол дебажу отсюда и до обеда) устранять ошибки в коде,
Возникает вопрос: а точно ли задача ему по плечу? Может он просто не может уложить задачу в голове, какая уж тут систематичность. Как он ведет себя на простых задачах?
Здравствуйте, IT, Вы писали:
IT>ЗЫ. Если человек не способен понять проблему, а тупо уговаривет код работать, то лучше с таким не иметь дела. Особенно, если это не вчерашний студент.
Есть другая крайность, когда лень менеджеров требует таких вот оправданий. Вместо написания документации,
организации процесса и т.п. выполнений своих обязанностей можно пораньше пойти домой а разработчику сказать: делай как там,
подумай, научись решать проблемы и т.п.
Может у разработчика есть ощущение что он выступает в роли папа крало?
Когда менеджер вобще нихера не делает и только строчит нечетабельные отписки (которые в последствии и сам прочитать не может без помощи программиста).
Программер попросту деморализован.
Как показал опыт прошлой недели, разработчик этот иногда способен думать и производить хорошие результаты (без микроменеджмента).
Мои выводы:
1) Надо давать ему побольше заданий и мягко повышать планку сложности.
2) Если он пытается побудить меня сделать его работу, то нельзя поддаваться. Вместо этого надо повторно объяснить ему, что и как, подробно, но саму работу должен сделать он сам.
3) Если я получаю недоделанный результат, то ошибки надо исправлять не самому, а составить их перечень и дать на доработку разработчику. Тогда он будет учиться.
4) Если он сделал что-то качественно (как договаривались и в срок), то надо демонстративно сказать ему "спасибо".
Здравствуйте, Кондор, Вы писали:
К>Есть другая крайность, когда лень менеджеров требует таких вот оправданий. Вместо написания документации, К>организации процесса и т.п. выполнений своих обязанностей можно пораньше пойти домой а разработчику сказать: делай как там, К>подумай, научись решать проблемы и т.п.
В моём случае это не так — каждая цель, которую я ему поручаю описана довольно чётко, плюс я каждый день спрашиваю его, есть ли у него непреодолимые трудности и если есть, то вместе с ним разбираю их (по скайпу).
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>>Надежды не оправдываются. Его способ работы не улучшается.
B>Т.е. он как не мог фиксить баги, так и не научился?
Он иногда делает то, что нужно, а иногда ведёт себя так, что это выглядит как лень.
Пример: Я ему сказал сделать одну вещь, а потом её протестировать, т. е. запустить программу и посмотреть на результат.
Так вот он мне сначала говорил, что "программа должна работать, багов нет, следовательно нет нужды тестировать" и мне потребовалось некоторое время, чтобы "уломать" его проверить эту программу на практике.
Кстати, когда он её запустил, оказалось, что там много чего не сделано, о чём договаривались раньше.
А бывает и иначе — на прошедшей неделе он одну задачу сделал именно так, как я ему сказал и без микроменеджмента.
От чего зависит его поведение я пока не понял до конца.
Одна из причин задержек такая: Он понимает, что не знает как выполнять ту или иную операцию слишком поздно, т. е.
1) я дал ему задание,
2) мы с ним поговорили,
3) он начал работать и
4) только здесь понял, что не понимает, как делать тот или иной шаг нужный для достижения цели.
Из-за различий в часовых поясах на этапе 4) я недоступен в скайпе (когда у них утро, у нас ночь) и поэтому работа стоит.
Что против этого можно сделать?
После обсуждения (этап 2), когда он сказал "я всё понял" я ему говорю следующее: Составь мне перечень шагов, которые тебе нужно сделать, чтобы достичь эту цель, за 15 минут.
В процессе он либо составит этот список (если всё понимает), либо нет. Во втором случае это означает, что он что-то не понял из формулировки цели и это надо повторно (или другими словами) объяснить.
Преимущество: Недопонимание выявляется раньше (на этапе 2), когда его легко устранить без потерь времени.
Здравствуйте, nvb, Вы писали:
nvb>Попросите его описать в письме, чем он хотел бы заниматься. Может быть, стоит подобрать что-то, что ему больше по душе? Он же на кого-то учился, писал диплом на какую-то тему, ходил добровольно на какие-то курсы — наверняка он для себя решил, что ему нравится, а что нет.
nvb>У вас описан человек, занимающийся противной ему работой. Ждать от него энтузиазма — по моему, не стоит. Либо смените тип его занятий, либо, если это невозможно — замените самого человека. Не портите ему дальнейшую жизнь, да и себе тоже.
Спасибо, но для меня этот совет неприменим, т. к. формально я не являюсь его начальником и не уполномочен менять его сферу деятелльности, давать обучение и т. д. Я фрилансер, а этот товарищ — подчинённый моего заказчика.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>>Как можно научить его систематически (а не хаотично, мол дебажу отсюда и до обеда) устранять ошибки в коде,
M>Возникает вопрос: а точно ли задача ему по плечу? Может он просто не может уложить задачу в голове, какая уж тут систематичность. Как он ведет себя на простых задачах?
В 90 % случаев после того, как я дал ему задание, я с ним пошагово обсуждаю, как его выполнять. Потом эти задания довольно чётко очерчены, т. е. есть однозначные критерии, по которым можно определить сделана работа или нет.
Честно говоря, я не очень представляю, куда дальше упрощать те задачи, которые я ему даю.
Здравствуйте, Кондор, Вы писали:
К>Может у разработчика есть ощущение что он выступает в роли папа крало? К>Когда менеджер вобще нихера не делает и только строчит нечетабельные отписки (которые в последствии и сам прочитать не может без помощи программиста). К>Программер попросту деморализован.
Большая часть кода пишется/адаптируется/дебажится непосредственно мной.
Так что не думаю, что у него есть основания, что я ничего не делаю, а всю работу даю ему.
Здравствуйте, Кондор, Вы писали:
IT>>ЗЫ. Если человек не способен понять проблему, а тупо уговаривет код работать, то лучше с таким не иметь дела. Особенно, если это не вчерашний студент.
К>Есть другая крайность, когда лень менеджеров требует таких вот оправданий. Вместо написания документации, К>организации процесса и т.п. выполнений своих обязанностей можно пораньше пойти домой а разработчику сказать: делай как там, К>подумай, научись решать проблемы и т.п.
Любая крайность — плохо. Но приведённая выше крайность гораздо лучше, чем крайность, когда у разработчика просто нет мозгов для решения поставленной задачи.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Аноним, Вы писали:
nvb>>Попросите его описать в письме, чем он хотел бы заниматься.
А>С людьми лучше просто говорить.
В общем случае — да, но не в этом. Здесь нужна обдуманная и сформулированная позиция, а не то, что придет в голову за первые 10 секунд. Вот уточнять написанное уже лучше словами.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>После обсуждения (этап 2), когда он сказал "я всё понял" я ему говорю следующее: Составь мне перечень шагов, которые тебе нужно сделать, чтобы достичь эту цель, за 15 минут.
ДП>В процессе он либо составит этот список (если всё понимает), либо нет. Во втором случае это означает, что он что-то не понял из формулировки цели и это надо повторно (или другими словами) объяснить.
ДП>Преимущество: Недопонимание выявляется раньше (на этапе 2), когда его легко устранить без потерь времени.
Совместное рисование UML диаграмм не поможет? Расшарьте свой экран по скайпу и рисуйте в процессе общения. Тогда напортачить ему будет значительно сложнее, да и его стиль мышления станет для вас понятнее. Как и наоборот, кстати.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Здравствуйте!
ДП>Одна из причин задержек такая: Он понимает, что не знает как выполнять ту или иную операцию слишком поздно, т. е.
ДП>Из-за различий в часовых поясах на этапе 4) я недоступен в скайпе (когда у них утро, у нас ночь) и поэтому работа стоит.
ДП>Что против этого можно сделать?
Вопросы будут всегда, чтобы не придумывать. Мне кажется, лучше иметь пакет разных заданий, разной продожительности и приоритетов
Типа
— основная задача. Что нужно сейчас.
— исследовательская задача. Что надо будет в блишайшем будущем.
— документация. Можно без чего-то обойтись, но желательно иметь.
Тогда вероятность "простоя" будет почти нулевой. (Хотя при большом желании причины простоя можно найти всегда
Вообще, я смотрю, ситуация не простая. Или Вы работаете с ним или ищите другого заказчика?
Вам уже удалось понять стиль его мышления?
Ну например, одному коллеге мне достаточно сказать пару слов, чтобы он понял что я хочу. Второму нужно нарисовать картинку,
с третьим, нужно вместе сделать простой пример, не отвечая немедленно на вопросы (после того как он сам поймет пример, почти все вопросы отпадут. Если отвечать на вопросы без примера, то потеряется попусту куча времени)
Одно могу сказать более менее точно. Как будет идти работа, можно уже предсказать в первую неделю, еще несколько месяцев могут понадобится на подтверждение/опровержение предсказаний.
Но особых надежд на чудесное исцеление я бы делать не стал и лучше просто не доходить до того момента, когда "вода начнет переливаться через край"
Здравствуйте, nvb, Вы писали:
nvb>Совместное рисование UML диаграмм не поможет?
UML я не пробовал. Обычно, я делаю так — сам пишу интерфейсы тех классов, которые мне нужны, а ему потом говорю — сделай класс такой-то, чтобы в нём был метод такой-то, который получал бы такие-то параметры и преобразовывал их в такой-то результат.
Можно сказать так — интерфейсами я задаю общую структуру той или иной функции, а разработчик наполняет её функционалом.
Но в некоторых из этих пунктов есть подводные камни. > > 1) Надо давать ему побольше заданий и мягко повышать планку сложности.
Не перегни палку.
> > 2) Если он пытается побудить меня сделать его работу, то нельзя > поддаваться. Вместо этого надо повторно объяснить ему, что и как, > подробно, но саму работу должен сделать он сам.
Смотри, чтобы объяснения не стали длительнее самой работы.
> > 3) Если я получаю недоделанный результат, то ошибки надо исправлять не > самому, а составить их перечень и дать на доработку разработчику. Тогда > он будет учиться.
Можешь превратиться в тестера его поделий.
> > 4) Если он сделал что-то качественно (как договаривались и в срок), то > надо демонстративно сказать ему "спасибо".
А вот это применимо всегда и ко всем. Все любят, когда их хвалят,
особенно если за сделанную работу. Не хвали за несделанную.
У меня ещё один вопрос к присутствующим: Кто-нибудь пытался повысить скорость освоения программистами нужных навыков (не только технических) с помощью методик Щедровицкого (ОДИ), Альтшуллера (ТРИЗ), ДеБоно, Голдратта (теория ограничений), проблемных расстановок, системного мышления, некоторых частей НЛП (формулировка цели), PSP (Personal Software Process) и т. д.?
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Здравствуйте!
ДП>У меня ещё один вопрос к присутствующим: Кто-нибудь пытался повысить скорость освоения программистами нужных навыков (не только технических) с помощью методик Щедровицкого (ОДИ), Альтшуллера (ТРИЗ), ДеБоно, Голдратта (теория ограничений), проблемных расстановок, системного мышления, некоторых частей НЛП (формулировка цели), PSP (Personal Software Process) и т. д.?
ДП>Если пытались — каковы результаты?
с альтшулером есть опыт.
вывод: триз — это бомба замедленного действия. на этапе постижение триза многие концепты кажутся тупо смешными (маленькие человечики, белая обезъяна и т.п.) и это действительно так. другое дело, что сами по себе (все!) альтшулерские концепты — это метод посмотреть на ту же вещь только с другой стороны — эдакие притчи. вот когда до пациента дойдет это "посмотреть с другой стороны" (вместо маленьких человечков) и он "смирится" с таким подходом (то есть не просто поймет, но прочувствует своими фибрами) бомба буквально взрывается.
за сим...
минусы: потеря времени на сам триз, ржаки во время донесения концептов, время на усвоение концептов
плюсы: расширенный кругозор, способность принятия "альтернативных" взглядов, способность к поиску решений за "горизонтом известного"
итого: очень результативно, но ну слииишком долго. поэтому не рекомедую, если задача повысит скорость освоения навыков стоит в конкретный момент времени, а не в принцыпе.
ДП>Заранее благодарен
ДП>Дмитрий
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Вопрос: Как можно научить его систематически (а не хаотично, мол дебажу отсюда и до обеда) устранять ошибки в коде,
Личный пример.
ДП>при условии, что ДП>а) это человек из азиатской культуры, ДП>б) я общаюсь с ним по скайпу в режиме чата и ДП>в) я не хочу применять давление
При данных условиях — никак. Невозможно. Расслабься.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Сейчас мне приходится объяснять ему банальные вещи: ДП>*) Что не имеет смысла мучить код, если ты не понимаешь, чего хочешь от него добиться ДП>*) Что сначала надо поставить диагноз, потом проверить его и только после этого устранять и т. п.
ДП>Вопрос: Как можно научить его систематически (а не хаотично, мол дебажу отсюда и до обеда) устранять ошибки в коде, при условии, что..
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>>Вопрос: Как можно научить его систематически (а не хаотично, мол дебажу отсюда и до обеда) устранять ошибки в коде,
G>Личный пример.
Как лучше всего продемонстрировать ему систематическое мышление в действии, если он работает удалённо (нельзя сесть с ним вместе за компьютер, чтобы я делал и объяснял, а он наблюдал) ?
Мне пока не пришло в голову ничего лучшего, кроме этого: Я беру какую-то маленькую задачку, включаю видеозапись и потом выполняю эту работу. По ходу дела комментирую свои действия, чтобы ему было понятно, что и зачем я сейчас делаю.
Готовый ролик размещаю в интернете на запароленной странице.
Вчера сделал первый эксперимент такого рода, жду обратной связи от разработчика.
Здравствуйте, Дмитрий Писаренко, Вы писали:
G>>Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>>>Вопрос: Как можно научить его систематически (а не хаотично, мол дебажу отсюда и до обеда) устранять ошибки в коде,
G>>Личный пример.
ДП>Как лучше всего продемонстрировать ему систематическое мышление в действии, если он работает удалённо (нельзя сесть с ним вместе за компьютер, чтобы я делал и объяснял, а он наблюдал) ?
В офлайне у тебя нет обратной связи, и ты не можешь видеть, какое действие оказывают твои слова. Делать видеозапись с монологом в такой ситуации — бить вслепую, наугад. Плюс — ты не знаешь, насколько интересно твоему коллеге тебя слушать и смотреть.
Чтобы до человека дошло — вы должны исправлять один дефект вдвоем. Удаленно это делать довольно тяжело. В ситуации, когда человек на том конце ничерта не знает + уверен, что он самый умный — вообще невозможно.
Узнаешь работающий способ — скажи, будет интересно.
Здравствуйте, Gaperton, Вы писали:
ДП>>Как лучше всего продемонстрировать ему систематическое мышление в действии, если он работает удалённо (нельзя сесть с ним вместе за компьютер, чтобы я делал и объяснял, а он наблюдал) ?
G>В офлайне у тебя нет обратной связи, и ты не можешь видеть, какое действие оказывают твои слова. Делать видеозапись с монологом в такой ситуации — бить вслепую, наугад. Плюс — ты не знаешь, насколько интересно твоему коллеге тебя слушать и смотреть.
Скайп разве не позволяет расшарить свой экран и при этом, чтобы у собеседника была включена веб камера? Вы ему показываете/рассказываете и видете его реакцию по лицу.
Здравствуйте, ilvi, Вы писали:
I>Скайп разве не позволяет расшарить свой экран и при этом, чтобы у собеседника была включена веб камера? Вы ему показываете/рассказываете и видете его реакцию по лицу.
Есть скайп, есть и куча других решений, которые даже еще лучше подходит, только нифига это не работает.
Вернее работает, но даже и близко не может считаться заменой живого контакта.
Скайп и подобное относительно неплохо работает только с теми,
кого ты хорошо лично знаешь и с которыми переодически встречаешься/работаешь вживую.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, ilvi, Вы писали:
I>>Скайп разве не позволяет расшарить свой экран и при этом, чтобы у собеседника была включена веб камера? Вы ему показываете/рассказываете и видете его реакцию по лицу.
B>Есть скайп, есть и куча других решений, которые даже еще лучше подходит, только нифига это не работает. B>Вернее работает, но даже и близко не может считаться заменой живого контакта. B>Скайп и подобное относительно неплохо работает только с теми, B>кого ты хорошо лично знаешь и с которыми переодически встречаешься/работаешь вживую.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, bkat, Вы писали:
B>>Есть скайп, есть и куча других решений, которые даже еще лучше подходит, только нифига это не работает.
BZ>расшаренный экран плюс голос чем-то отличаются от живого общения?
Занимаюсь этим чуть ли не каждый день.
Отличается и сильно. Ну примерно как резиновая кукла от живой женщины
Здравствуйте, bkat, Вы писали:
BZ>>расшаренный экран плюс голос чем-то отличаются от живого общения?
B>Занимаюсь этим чуть ли не каждый день. B>Отличается и сильно. Ну примерно как резиновая кукла от живой женщины
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, bkat, Вы писали:
BZ>>>расшаренный экран плюс голос чем-то отличаются от живого общения?
B>>Занимаюсь этим чуть ли не каждый день. B>>Отличается и сильно. Ну примерно как резиновая кукла от живой женщины
BZ>- чем хуже? BZ>- чем грузины!
Что, не можешь представить себе чем отличается резиновая кукла от живой женщины?
Живому общению полноценной замены нету.
Все что есть, с оговорками можно пользоваться, но уровень взаимопонимания, эффективность гораздо падает.
Невербальное общение через инет весьма неполноценно, даже с самым топовым оборудованием.
Если нам не помогут, то мы тоже никого не пощадим.
