Работа с негибкими программистами

Иногда программисты, которые работают над проектом в течение долгого времени, становятся негибкими, и с ними становится трудно рассуждать. Даже если нам удастся убедить их, они вряд ли смогут реализовать наши предложения.

Например, я недавно присоединился к проекту, где процесс сборки и выпуска слишком сложен и имеет ненужные препятствия.

Я предложил избавиться от некоторых накладных расходов на разработку (таких как заполнение нескольких электронных таблиц), просто интегрировав инструменты управления дефектами и контроля версий (оба являются инструментами IBM-Rational, поэтому интеграция может быть очень простой разовой операцией). Кроме того, если мы используем такие инструменты, как Maven & Ant (проект включает в себя Java и некоторые продукты COTS), сборка и выпуск могут быть упрощены, что должно уменьшить количество ошибок и вмешательства вручную.

Мне удалось убедить других, и я готов приложить усилия для разработки концепции. Но «Старший» разработчик не хочет, возможно, потому что текущий процесс делает его более ценным.

Как мы справимся с этой ситуацией, не развивая трения в команде?

Вы новый член команды и хотите изменить некоторые фундаментальные аспекты работы команды. Удачи, я чувствую счастливую команду в вашем будущем.

Хорошо, несколько практических советов:

Докажи себя команде. Вам нужно сделать это с точки зрения технической надежности и надежности. Если вы хотите, чтобы люди следовали за вами, вам нужно дать им причину для этого.

Понять историю методологии. Почему это существует? Какую проблему он решал в то время? Убедитесь, что ваше решение действительно приносит пользу команде. Возможно, ваши изменения лучше, но на самом деле они могут не решить проблему, с которой сталкивается команда.

Узнай свои контрольно-пропускные пункты. Узнайте причины их сопротивления и поработайте над этими предметами.

Если вы хотите быть агентом изменений, узнайте, как быть успешным агентом изменений . Десятки книг и других доступных источников предоставят вам гораздо больше информации, чем вы получите здесь.

И да, я желаю вам удачи. Но, пожалуйста, ради вашего счастья и счастья вашей команды, будьте умны с этим. Ваше желание внести изменения в процесс, не вкладывая энергию в создание правильного пути, может принести гораздо больше вреда, чем пользы.

Я был в положении, которое вы упомянули. Я провел годы в качестве разработчика Java и в конечном итоге пошел на работу, где все они использовали Smalltalk. Моей первой реакцией было: «OMG, они используют эту устаревшую технологию», и я начал пытаться решать конкретные проблемы Smalltalk с помощью решений Java. Я могу только представить, какой головной болью я должен был стать для других разработчиков, и они страстно ненавидели Java.

Только когда мне дали проект среднего размера для работы, в то время как два старших разработчика наставляли меня в течение нескольких месяцев, я начал изучать язык Smalltalk и учиться любить его. После того, как я ушел с работы и вернулся к разработке Java, я чувствую себя гораздо более гибким, поскольку я могу взять проект и реализовать его на любом языке, который использует компания. Главное, чтобы эти люди поняли, что язык - не что иное, как среда. Я также нашел время, чтобы научить себя Lisp и Erlang, но это может не сработать со всеми.

В качестве стратегии построения команды я бы порекомендовал « Семь языков за семь недель» людям, с которыми у вас проблемы.

Я думаю, это также зависит от того, сколько времени эти люди готовы инвестировать в повышение гибкости. Проблема большинства университетов (по крайней мере, тех, которые я видел) состоит в том, что они склонны к определенному языку, и его студенты становятся «институционализированными», как вы упомянули. Я думаю, что частью вашей стратегии должно быть воспитание гибкости в вашей команде. Это может быть дополнено разработкой, управляемой доменом .

(1) Моделирование домена (простой) (2) Реализация его с использованием двух разных языков (например, Java и Lisp)

Опять же, это при условии, что они мотивированы, чтобы сделать вышеупомянутое и готовы тратить свое собственное время, чтобы достигнуть этого.

Надеюсь это поможет

Я мог бы быть здесь на совершенно неверном пути, но мне кажется, что те же проблемы распространены в более широком масштабе и связаны с человеческим консерватизмом. Люди часто отказываются менять общеизвестные модели поведения по причинам, которые слишком многочисленны для упоминания.

Будучи российским разработчиком (и, следовательно, видя менее рациональный западный прагматизм), я вижу практические рассуждения гораздо менее убедительными, чем пытаться ходить в чужой обуви.

Другими словами, вы упомянули, что старший программист ценит свою собственную позицию, связанную с текущей рабочей схемой. Возможно, вам следует убедить его, что новый способ ведения дел сделает его положение еще более ценным, и есть много способов сделать это. Например, вы можете попросить его озвучить вашу идею и получить за нее кредит, или вы можете найти определенное место в процессе, которым он может управлять исключительно и т.д.

Я полагаю, что гибкость вне очевидных преимуществ вашей идеи может быть вашим волшебным заклинанием здесь.

Мне удалось убедить других, и я готов приложить усилия для разработки концепции. Но «Старший» разработчик не хочет, возможно, потому что текущий процесс делает его более ценным.

Вместо того, чтобы бросать оскорбления на персонажа старшего разработчика (плохой ход), возможно, вам следует попытаться понять, почему он без энтузиазма:

• Может быть, он думает, что вы один из тех людей, которые переоценивают свои идеи. Может быть, он сомневается, что вы можете доставить их.

• Может быть, он думает, что вы преувеличиваете проблемы. (Они не могут быть такими плохими ...)

• Может быть, он думает, что вы не до конца понимаете технические риски.

• Может быть, он думает (знает), что сейчас есть более важные дела.

• Может быть, вы просто растерли его неправильно.

Мой совет - доказать ему себя. Например, выполняя проекты, которые вам действительно дали. Когда он больше доверяет вашим способностям и суждениям, вернитесь к этому вопросу.

Если вы хотите прямо сейчас следовать линии «улучшения процессов», мой совет будет делать это медленно, небольшими шагами.

Имейте в виду, что, несомненно, существует риск того, что предложенные вами изменения окажут значительное влияние на производительность вашей группы и даже на их способность поддерживать существующее программное обеспечение. Если это произойдет, ответственное лицо, скорее всего, получит наибольшую отдачу от высшего руководства.

Институционализированы о чем конкретно? Технологии, шаблоны, практики?

Если они были в организации / проекте в течение долгого времени, есть вероятность, что они являются старшими разработчиками, и у них есть ответственность / опыт для выполнения этих вызовов, и они имели опыт в проекте, а не просто были подготовлены, как эксперимент с 5 обезьянами .

Решение для их убеждения будет зависеть от того, что является предметом, поскольку, если шаблон / технология уже выбрана, будет веская причина, и должна быть более веская причина для изменения, чтобы оправдать отказ от работы и повторное знакомство и т. Д. ., если так, то решение для архитектора / старшего разработчика, организующего собрание, чтобы демократическим путем выбрать лучшее решение.

Если команда действительно имеет ненужные дорожные преграды, то они, вероятно, будут очень рады, если вы поможете им исправить их. Заметьте, однако, что может быть очень веская причина для их присутствия, и вы будете выглядеть глупо, если скажете: «О, ну, тогда моя фантастическая идея не работает», после того, как она слишком долго продавалась всем.

Сначала исследуй, а потом выходи. Также обратите внимание, что возможность ПОКАЗАТЬ, как вы предлагаете улучшить его, намного лучше, чем ручное махание.

Я склонен сказать, что вы тот, кто является "Негибким Программистом". Вы новичок в проекте, но вы настаиваете на том, что ваша идея самая лучшая, и парень, который руководит проектом, который был их дольше и знает, что система изнутри и снаружи, только что сошел с ума.

Я довольно опытный и довольно уважаемый, и мне часто назначают исправлять трудные проекты как член команды тигра. Даже тогда я все еще трачу время на то, чтобы узнать, как, почему, динамику команды, проект и их практики, а не дико входить и рассказывать им, как это и что неправильно. На самом деле, я никогда не говорю, что то, что они делают, неправильно, потому что это не дает того ответа, который я хочу, и обычно то, что они делают, не неправильно, просто нужно немного подправить.

Каждый проект уникален. Каждая команда уникальна. Ваше решение может быть лучше для вас и разработчиков, но оно не может быть лучше для лидера, клиента, бизнеса или проекта, но, поскольку у вас нет опыта в проекте, чтобы знать лучше, вы не будете знать, ответ на это.

Лучший способ заставить людей делать то, что вы хотите, - заставить их думать, что все это их идея. Таким образом, вместо непосредственного внесения предложений, представьте варианты. Если ваши идеи явно лучше, чем альтернативы, дайте старшему разработчику шанс выбрать их и сделать их своими. Не беспокойтесь о получении кредита. Люди, которые имеют значение, будут знать, что происходит.