Процессы моей команды вышли из-под контроля?

16

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

У меня есть 6 старших разработчиков в моей команде, но здесь все кажется беспорядочным. Ситуация такова, что мне приходится иметь дело с запросами JIRA от примерно 10 разных точек контакта в нашей компании, и все они представляют разные бизнес-единицы или клиентов.

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

Какие есть хорошие способы справиться с этим? У меня тонны теорий, но я ищу ответ от кого-то, кто действительно имеет опыт работы в такой ситуации, как моя.

Вот небольшой список того, как все работает:

  • Каждый разработчик несет ответственность за конкретное приложение и сервисы, взаимодействующие с ним;
  • Релизы обычно тестируются клиентом на смоделированном производственном сервере, а затем развертываются на работающем сервере;
  • Каждое приложение используется в среднем 50-80 человек, всего 8 приложений.

Благодарность

Даниэль Миннаар
источник
4
Корпоративную культуру сложно изменить. Это все равно что пытаться повернуть очень длинный грузовой поезд.
Роберт Харви
@drminnaar Не могли бы вы кратко описать промежуточные этапы, начиная с процесса, начиная с запроса JIRA и заканчивая развертыванием кода в производственной среде. Вы чувствуете, что недоукомплектованы (от 6 до 8 приложений)?
Ocaj Nires
@Ocaj Nires Request зарегистрирован, я подтверждаю приоритет (чем я пожертвую, чтобы получить это для вас сейчас?), Назначаю его разработчику, сообщаю ETA, тестирую изменения и выпускаю их. Я чувствую, что недоукомплектован количеством работ на нашей пластине, но это немного сложно оправдать, если мои процессы не являются надежными ...
Даниэль Миннаар,
1
Можете ли вы уточнить, кто отвечает за тестирование? Это звучит немного реактивно.
Temptar

Ответы:

17

наши клиенты не примут внезапную задержку результатов

Ну, тогда они должны принять низкое качество, которое они получают.

Что у вас естьЧтобы изменить это, заставить своих клиентов принять реальность разработки программного обеспечения (или любого другого производства!): Спешка влияет на качество.

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

Соберите ключевых заинтересованных лиц в комнате и скажите: «Вы хотите, чтобы X исправили, или вы хотите, чтобы Y доставили? У нас есть время только для одного из двух». Сделать их ответственность за установление приоритетов и убедитесь, что у вас ограниченные возможности. Если они просят что-то новое, спросите их, чем они готовы пожертвовать из своей текущей дорожной карты, чтобы достичь этого.

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

Лучшее, что я когда-либо делал в своей нынешней работе, - это собрал в одной комнате 8 главных заинтересованных лиц и выложил стопку из 16 учетных карточек, представляющих запрошенные новые функции. Я отступил от стола и сказал: «Мы можем доставить один из них за один раз. В каком порядке вы хотите, чтобы они?» Пусть они спорят друг с другом о приоритете бизнеса, а не застрять в середине.

Дэн Пьюзи
источник
Если вы можете собрать всех в комнате, которая звучит как отличная идея (мне придется запомнить эту тактику). Однако это может быть невозможно.
Джоккинг
@jhocking: возможно, вы не можете собрать всех в комнате вместе, но вы можете отправить электронное письмо «всем заинтересованным сторонам» ...;)
IAbstract
5

Стоп, бросай и катись. Пожары нуждаются в топливе, и часто это приходит в виде паники. Выделите время, чтобы управлять собой и командой по порядку. Оцените своих разработчиков и посмотрите, есть ли у вас те, кто недостаточно квалифицирован и / или недостаточно усердно работает, чтобы получить желаемые результаты. Решите, кто останется (и приложите усилия, чтобы удержать их), кому нужно немного подтолкнуть, остальные должны уйти. Оцените поддержку и инструменты, которые получают ваши программисты, чтобы убедиться, что они могут выполнять свою работу. Убедитесь, что звуковое тестирование, обзор, контроль источников и документация соблюдаются. Хорошие люди с хорошими инструментами должны быть ответственны за хорошую работу.

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

Получите лучшее понимание того, что ожидают клиенты. Это не может быть частью вашей работы. Могут быть другие люди, которые притворяются, что их волосы в огне, их клиенты несчастны, и небо падает. Это то, что они делают, и некоторые действительно хороши в этом. Если все является чрезвычайной ситуацией, то ничто не является чрезвычайной ситуацией, потому что это не все будет сделано. Предлагаем иногда участвовать в обсуждениях с клиентами. Вы обнаружите, что многие «приятные имущие» превращаются в «нарушителей», когда они попадают в команду разработчиков. Быть техническим обманом или каким-либо другим оправданием, чтобы помочь. Давать обещания, которые вы не можете выполнять, хуже, чем рассказывать им то, что они не хотят слышать. Мы хотим сделать хорошую работу, поэтому нам нужно 8 недель, а не 5. Они будут счастливее в долгосрочной перспективе.

JeffO
источник
+1 за "понять ... что ожидают клиенты". Это ключ. Если вы не можете заставить их понять преимущества более качественных релизов, привыкните к тому, что ваша голова отскакивает от стены.
Дэйв
4

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

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

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

ChrisF
источник
0

Мое (ограниченное) мнение: я думаю, что есть две проблемы, которые нужно решить. Во-первых, качественный процесс. Вы используете скрам / водопад / что-то среднее? В Scrum вы можете добавить дополнительные задачи для каждой истории: 1, чтобы придумать тестовый сценарий / план, другой для его запуска, другой для проверки кода и т. Д. В водопаде, вы можете просто добавить эти шаги?

Другая проблема - это основная проблема, которая существует везде в программном обеспечении. Управление ожиданиями. Т.е. увеличивается время от того, чтобы кто-то кричал, что ему нужна кнопка, чтобы сделать X, до его доставки.

Если вы можете добавить дополнительные шаги к процессу и сделать большое фанфарное объявление об этом [мы сейчас реализуем этот процесс качества: это будет означать меньше времени на исправление ошибок! и лучшие результаты качества! большое электронное письмо / встречи и т. д., чтобы сообщить им об этом] и регулярно предоставлять результаты (ala scrum). Идея состоит в том, что те, кому вы предоставляете информацию, узнают и увидят ценность на дополнительных этапах процесса, и они купятся на это. Меньше времени на исправление ошибок = больше времени на реализацию и тестирование функций.

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

Опять же, если вы используете скрам или что-то подобное, вы можете стремиться к однонедельному спринту, чтобы регулярно доставлять результаты. Это успокоит людей так же, как быстрый поворот.

Надеюсь, это в какой-то степени поможет ... надеюсь, я не упустил суть.

Кирен Джонстон
источник
-1

То, что вы описали, звучит очень нормально и совсем не пугает.

  • Клиенты обычно думают иначе, чем инженеры. Мы хотим, чтобы все было правильно, но клиенты сталкиваются с реальностью, которая вознаграждает пунктуальность за чистоту. Им нужно быстро решать свои проблемы, чтобы быть конкурентоспособными, и это именно то, за что они вам платят.
  • Распределение приоритетов слишком велико и сложно для одного человека, чтобы справляться с ним в одиночку, имея отставание по важным вопросам (поэтому вы используете JIRA), а лейтенанты, управляющие каждой областью интересов, - это лучший вариант, который мы можем использовать для выполнения важной работы в начале. расписание.

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

SingleNegationElimination
источник
«Нормальный» - это не то же самое, что «не о чем беспокоиться».
Дэн Пьюзи