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

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

Третий. вы должны установить четкие, измеримые и достижимые цели в разработке вашего продукта. Цели, которые легко регулярно проверять. В бизнес-администрировании мы называем это «контролем качества».

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

TL;DR

Хотя качество можно измерить объективно, определение элементов качества, специфичных для предметной области, для вашей организации — это не то, где вы можете полагаться на стандартное словарное определение.

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

Ваши примеры, анализ

1. В последнее время не было выпущено никаких больших новых функций

   Непрерывное развитие функций не является признаком качества. Когда продукт «достаточно хорош», чтобы продаваться на рынке, и соответствует своему назначению, то особенность часто является признаком того, что компании не хватает видения рынка или обратной связи с клиентами. Например, люди не хотели Clippy или Microsoft Bob; они часто просто хотели меньше ошибок, синих экранов и вирусов.

2. Разный UX для субпродуктов

   Это проблема процесса , а не проблема качества как таковая. Кто стимулирует потребность в объединяющем UX? Если клиенты этого не требуют, а ваш процесс не включает межкомандную интеграцию, то это проблема внешнего вида, а не реальной проблемы качества.

3. Некоторые программные модули почти не обслуживаются после смены владельца

   Это 100% организационная проблема. Без коллективного владения кодом, культуры непрерывного рефакторинга или ИТ-управления, обеспечивающего владение компонентами или процессами, заброшенный код почти всегда становится нелюбимым унаследованным кодом. Ваше руководство должно назначать владельцев компонентов на протяжении всего жизненного цикла продукта, потому что надежда и желание не являются реальными стратегиями.

4. Команда архитекторов не несет ответственности за качество

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

   Опять же, качество означает то, что ваша организация решает, что оно означает. Определите его, согласуйте его со всей организацией, а затем постоянно проверяйте любые показатели качества, с которыми вы все вместе согласились. Без этого соглашения и тестирования «качество» — просто модное слово.

5. Разработчики программного обеспечения начали покидать проект

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

6. Кажется, слишком много координации между командами для новых инициатив

   «Аналитический паралич» — известный антипаттерн. Крупные инициативы, особенно для проектов на старых месторождениях, всегда требуют большего сотрудничества, чем небольшие проекты с нуля. Хотя темп изменений часто замедляется или останавливается по мере того, как проекты становятся больше, более серьезная проблема может заключаться в том, что вам нужна структура, которая масштабируется за пределы одной команды и работает в нескольких командах. Nexus, LeSS и SAFe — примеры из мира agile.

7. Часто используются обходные пути, отвечающие требованиям заказчика

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

Как улучшить качество

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

1. Практика разработки через тестирование или через поведение.
2. Интеграция современных методов непрерывной интеграции в конвейер разработки.
3. Обеспечить, чтобы команда и организация регулярно тратили время на проверку и адаптацию своих ценностей и практик, а непрерывное улучшение было приоритетом.
4. Постоянное отслеживание технического долга и регулярное выделение ресурсов для погашения этого долга.
5. «Остановка линии» для решения важных проблем контроля качества.
6. Убедиться, что работающее программное обеспечение и его «соответствие назначению» важнее для организации, чем просто соответствие спецификациям.
7. Потратьте время на рефакторинг и перепроектирование любого аспекта системы, который трудно расширять или поддерживать.
8. Методический подход к изменениям. Написание тестов перед написанием кода или следование методу Микадо для реализации редизайна — это всего лишь два важных примера.
9. Обеспечение того, чтобы ваше программное обеспечение всегда находилось в состоянии потенциально готовой к поставке.
10. Использование переключателей функций и других методов непрерывной доставки.

Многие из них действительно относятся к лагерю методов разработки, а не к управлению проектами как таковому. На этом фронте ваши лучшие ставки действительно таковы:

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

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

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

«Разработчики ПО начали покидать проект»

Спроси почему? Спросите их, почему? Спросите людей, которые остаются, почему?

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

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

Кроме того, размер вашей команды слишком велик («В последнее время не было выпущено ни одного крупного нового функционала», «50+ человек»). Однако вы не должны выгонять их из компании. Найдите для них другую независимую работу (другой проект). Получите письменное заверение совета директоров, что увольнений в связи с улучшением процессов не будет. Первое увольнение разрушит сотрудничество.

«Добавление человеческих ресурсов к позднему программному проекту делает его более поздним». - Фред Брукс в своей книге 1975 года «Мифический человеко-месяц». Их удаление может сделать это раньше. Но не зацикливайтесь на этом аспекте. Сосредоточьтесь на том, почему они уходят (люди могут уйти тем временем, и вам нужно выяснить, как сократить штат, не разрушая мотивацию. Вы можете перевести часть команды на тестирование, другие роли поддержки или улучшение процессов. Затем в итоге в другие проекты.

Первый вопрос: какие у вас цели в области качества? Типичные цели перечислены здесь .

Если вы определяете ограниченное количество целей, вы можете поместить их в свое определение готовности (DoD) в таких формах, как: «Каждая фиксация должна быть сохранена или улучшена (модульность/безопасность/что угодно)».

Тогда возникает следующий вопрос: как обеспечить и обеспечить соблюдение? Используете ли вы метрики кода? Делать обзоры кода? И вообще кто-нибудь использует DoD? :-)