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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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