Как создать «культ качества» [закрыто]

21

Демарко и Листер (Peopleware) предлагают вам создать «культ качества» в вашей команде программистов. К сожалению, они не предлагают, как вы поступите так!

У кого-нибудь есть мысли о том, как этого добиться?

Крейг Шварц
источник
1
Ваш «культ качества» будет настолько эффективным, насколько позволяет время. Когда босс говорит: «Это должно быть сделано к пятнице» , вы вынуждены снижать качество ради скорости. Очевидно, это не то, что предпочитают кодеры. В идеале мы предпочитаем время для обеспечения качества!
инвертировать
1
@WesleyWerner: Хороший вопрос. Но я думаю, что «культ качества» должен также включать заботу о технических долгах, что (в конечном итоге) решит проблему с боссом, которую вы упомянули.
talonx
@invert: Я обычно отвечаю в таких случаях, что у нас есть ситуация, аналогичная теореме CAP здесь. У нас есть качество, скорость и рабочая сила, и он может выбрать два.
JensG

Ответы:

37

Мой опыт показывает, что команды разработчиков (но в целом любая команда) состоят из 3 типов людей:

  • те со встроенным приводом для качества,
  • тех, кто только ради денег (пиво / девушки / что угодно) и не заботится о них, однако вы пытаетесь их мотивировать,
  • «посредственные» (из-за отсутствия лучшего слова).

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

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

[Update2] размышляет над ответом Альба : IMO нет необходимости, чтобы качественные разработчики составляли абсолютное большинство в команде (хотя это не повредит :-). Существует «порог установления тренда» , выше которого взгляды и поведение подгруппы могут быстро стать «основным направлением» внутри сообщества , поэтому другие люди обращают на это внимание и начинают следовать. Вы можете видеть это на работе в более широком обществе все время (например, (не) курение, здоровье и диеты, популярность, органическая еда). Моя очень грубая оценка состоит в том, что это может быть где-то около 25-30%, но это зависит от многих факторов. Здесь плохие люди могут причинить много вреда. Даже пара плохих людей в вашей команде может значительно повысить этот порог. [/ Обновление2]

Конечно, не всегда можно нанять достаточно лучших парней. Поэтому, когда первая фракция недостаточно сильна, чтобы управлять своими силами, руководство должно помочь им. Пара мыслей по этому поводу:

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

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

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

Обновить

@Machado в своем комментарии дал новый поворот в вопросе (по крайней мере для меня):

Что я, как член команды, а не менеджер, могу сделать, чтобы улучшить качество кода моей команды?

Несколько мыслей:

  • Продолжайте учиться и распространяйте знания среди всех, кто слушает. Изучите и используйте лучшие практики в ваших областях знаний.
  • Гордитесь своей работой .
  • Эти двое почти естественно позволят вам стать положительным примером для подражания для других - особенно для новичков и юниоров -; осознавать это и использовать свою роль на благо всей команды. Лучший способ повлиять на других - это положительный пример.
  • Посмотрите не только на код, но и на весь процесс разработки программного обеспечения; Продолжайте задавать вопросы и оставлять отзывы, чтобы оптимизировать процесс разработки .

И последнее, но не менее важное: найдите место, где вы можете стать «лучшим парнем» . Если вы сейчас находитесь в «посредственной» группе, стремитесь к саморазвитию - надеюсь, что приведенные выше идеи помогут в этом. Но если вы оказались в «низших слоях» вашей нынешней команды, я рекомендую вам проанализировать причины. Что тебя демотивирует? Плохие условия труда? Одноклубники? Управление? Тип работы? И что тебя волнует и интересует? Возможно, вам придется поговорить об этом со своими коллегами и / или начальником. Или вам, возможно, придется искать лучшую работу - или даже новую профессию - где вы можете начать блестеть. На самом деле не стоит тратить значительную часть своей жизни на неудовлетворительную или удручающую деятельность.

Может также случиться так, что вы вынуждены продолжать свою текущую, неоптимальную работу из-за внешних факторов (отсутствие лучших возможностей трудоустройства, необходимость оплачивать счета и т. Д.) - это происходит время от времени. Даже в этом случае постарайтесь извлечь из этого максимум пользы. Производство качественной работы (насколько позволяют обстоятельства) само по себе является наградой, которая помогает вам повысить самооценку и сохранить себя в здравом уме и быть открытыми в долгосрочной перспективе. Таким образом, когда появляется возможность для чего-то лучшего, вы лучше подготовлены к ее использованию.

Петер Тёрёк
источник
4
Опасный совет. Что если ОП принадлежит 2-й / 3-й группе? ;)
1
отличный ответ, я никогда не думал об этом, но это имеет такой смысл.
Alb
9
@ Разработчик, если бы они были, они бы не читали DeMarco и Lister и не задавали здесь вопрос.
Alb
Я думал, что вопрос был более направленным с точки зрения члена команды. Если руководство действительно хочет качество, они будут слушать своих ведущих разработчиков. Что я, как член команды, а не менеджер, могу сделать, чтобы улучшить качество кода моей команды?
Мачадо
1
@ Торбьерн, отличный вопрос! Я признаю, что до сих пор упускал это на большинстве своих рабочих мест. Надеясь не показаться слишком самодовольным, я всегда искал товарищей по команде, чтобы учиться и учиться у них, но я редко их находил. Поэтому я обратился к книгам и интернету. Насколько это возможно, я нашел образцы для подражания у Мартина Фаулера, дяди Боба Мартина и других. И последнее время в SO сообществе! Это потрясающее место для изучения. Также мощный "провайдер проверки реальности". Трудно воспринимать унизительные переживания, выявляющие границы и пробелы в знаниях, но они очень полезны для меня.
Петер Тёрёк
2

Отличный ответ Петера Тёрока, чтобы подчеркнуть, что вы справитесь с этим только с большинством хороших людей. Как только у вас появятся хорошие люди, вам нужно больше стремиться к морковному подходу, чем клюшке. Расширьте возможности разработчиков, дайте им возможность взять на себя ответственность за проекты / задачи и поощряйте конкуренцию с точки зрения качества, возможно, попросите людей сделать короткие презентации о том, как они улучшили качество в проектах. Хорошие разработчики будут мотивированы, чтобы произвести впечатление на своих коллег.

стихарь
источник
+1 Хорошие моменты о мотивации. Я был явно неправильно истолкован относительно большинства; Я обновил свой ответ, чтобы уточнить.
Петер Тёрёк
2

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

Более конкретно:

  • Удалите все следы мысли: «Мы очистим это позже». Вместо этого приложите усилия в начале, чтобы сделать это правильно.
  • Требуйте, чтобы изменения были рассмотрены и проработаны в процессе QA, в котором участвует кто-то, кроме разработчика.
  • Сила мысли о качестве на ранних этапах проектов. Держите в центре внимания такие вещи, как «как легко это поддерживать другим» во время разработки.
  • Отслеживайте и сообщайте о найденных ошибках. Если есть тенденции, посмотрите на способы борьбы с первопричиной ошибок.
  • Представьте мысль о программном обеспечении как о ремесле, которое можно улучшить, и чем могут гордиться создатели.
JZD
источник
1

Я бы сказал, что лучший способ - повысить качество продукции. Это одна из предпосылок движения Lean Software (на основе Lean Manufacturing). Я написал длинный пост в блоге, в котором обсуждается, что такое Лин . Я расскажу вам, как создать культ качества. Инвестируйте в своих сотрудников и позвольте им инвестировать в вашу компанию (не денежные, а личные).

Дэн Пинк выступил в TED с большой речью о том, что нас мотивирует. Пока он не ссылается на это конкретно. Иерархия потребностей Маслоу прекрасно объясняет наблюдаемое явление. Пока работодатель удовлетворяет первые две потребности (т.е. платит достаточно денег, чтобы деньги не были проблемой), остается только Принадлежность, Уважение и Самореализация.

  • Обеспечить солидное сообщество для принадлежности.
  • Создайте обстановку, в которой сотрудник может свободно совершать ошибки, чтобы он мог завоевать уважение, когда он делает достижения.
  • Дайте вашим разработчикам повод, чтобы они могли принимать важные решения для самореализации

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

Майкл Браун
источник