Здравствуйте, Кондор, Вы писали:
К>Может у разработчика есть ощущение что он выступает в роли папа крало? К>Когда менеджер вобще нихера не делает и только строчит нечетабельные отписки (которые в последствии и сам прочитать не может без помощи программиста). К>Программер попросту деморализован.
Большая часть кода пишется/адаптируется/дебажится непосредственно мной.
Так что не думаю, что у него есть основания, что я ничего не делаю, а всю работу даю ему.
Здравствуйте, Кондор, Вы писали:
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>кого ты хорошо лично знаешь и с которыми переодически встречаешься/работаешь вживую.
Если нам не помогут, то мы тоже никого не пощадим.
