У меня есть некий разработчик, которого я хочу научить самостоятельно выявлять причины дефектов ПО и устранять их.
То есть, чтобы я мог дать ему симптомы проблемы, а от него получить диагноз и разумные предложения по её устранению.
Сейчас мне приходится объяснять ему банальные вещи:
*) Что не имеет смысла мучить код, если ты не понимаешь, чего хочешь от него добиться
*) Что сначала надо поставить диагноз, потом проверить его и только после этого устранять и т. п.
Я уже давно в разговорах с ним говорю про все эти вещи в надежде на то, что в один прекрасный день он просечёт принцип и сам сможет выполнять указанные умственные операции.
Надежды не оправдываются. Его способ работы не улучшается.
Мне иногда приходится заниматься микроменеджментом — за ручку вести его к решению проблемы. Это всё очень сильно изнуряет.
Вопрос: Как можно научить его систематически (а не хаотично, мол дебажу отсюда и до обеда) устранять ошибки в коде, при условии, что
а) это человек из азиатской культуры,
б) я общаюсь с ним по скайпу в режиме чата и
в) я не хочу применять давление
?
Примечание: Это не проблема менталитета, т. к. другие люди из этого же региона работают достаточно хорошо (мне не надо строить/микроменеджить их).
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Сейчас мне приходится объяснять ему банальные вещи:
ДП>*) Что не имеет смысла мучить код, если ты не понимаешь, чего хочешь от него добиться ДП>*) Что сначала надо поставить диагноз, потом проверить его и только после этого устранять и т. п.
Эти навыки закладываются в возрасте седьмого класса.
Так что плюнь — этого человека ты не научишь, тем более дистанционно.
Самое гуманное, что ты можешь делать — перевести его на другую работу.
ДП>Мне иногда приходится заниматься микроменеджментом — за ручку вести его к решению проблемы. Это всё очень сильно изнуряет.
Вопрос: если ему предоставить возможность сделать всё от начала до конца без "помощи" (дёргания за рукав на "неправильных" промежуточных шагах), он справляется? Посмотрите на тему различия в восприятии у сенсориков и интуитивов.
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
Здравствуйте, 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 % случаев после того, как я дал ему задание, я с ним пошагово обсуждаю, как его выполнять. Потом эти задания довольно чётко очерчены, т. е. есть однозначные критерии, по которым можно определить сделана работа или нет.
Честно говоря, я не очень представляю, куда дальше упрощать те задачи, которые я ему даю.
Если нам не помогут, то мы тоже никого не пощадим.
