Отстаивал ли свою точку зрения в команде

Отстаивание своей точки зрения в команде: из личного опыта IT Project Manager

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

Мой подход основан на доказательности, прозрачности и фокусе на общих целях. Приведу конкретный пример из опыта управления разработкой крупного fintech-сервиса.

Конкретный пример: архитектурное решение и оценка рисков

На одном из проектов команда разработки (Tech Lead и архитектор) предложили использовать новую, модную NoSQL базу данных для модуля обработки транзакций. Их аргументы были весомы: высокая скорость записи, горизонтальная масштабируемость, использование современного стека.

Однако, проанализировав требования (строгая консистентность данных, сложные join-запросы для отчетности, наличие в команде экспертов по реляционным БД), я увидел потенциальные риски:

• Резкое увеличение сроков из-за обучения команды.
• Сложности с реализацией ACID-транзакций, критичных для финансовых операций.
• Скрытые расходы на миграцию и поддержку.

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

-- Пример, который я подготовил, чтобы проиллюстрировать сложность запросов для отчетности
-- Запрос, типичный для нашего модуля отчетов:
SELECT
    u.account_id,
    SUM(t.amount) as total_amount,
    COUNT(t.id) as transaction_count,
    c.name as currency_name
FROM transactions t
JOIN users u ON t.user_id = u.id
JOIN accounts a ON u.account_id = a.id
JOIN currencies c ON a.currency_id = c.id
WHERE t.status = 'COMPLETED'
  AND t.created_at BETWEEN '2023-01-01' AND '2023-12-31'
GROUP BY u.account_id, c.name
HAVING SUM(t.amount) > 10000;

Я наглядно показал, как подобный запрос будет выглядеть в выбранной NoSQL БД (через map-reduce или несколько отдельных запросов), что привело бы к снижению производительности отчетов и росту сложности кода.

Как я отстаивал свою позицию: структурированный подход

1. Сбор данных и анализ рисков. Я создал сравнительную матрицу в Confluence, где наглядно сопоставил два решения по критериям: соответствие требованиям, сроки, стоимость владения (TCO), риски, экспертиза команды. Моя точка зрения (использовать проверенную реляционную БД с возможностью шардинга) была подкреплена цифрами из похожих прошлых проектов.

2. Фокус на цели, а не на технологии. Я постоянно возвращал дискуссию к бизнес-требованиям: "Наша главная цель — гарантировать целостность каждой финансовой операции и сдать модуль в срок. Какое решение максимально способствует этому, а не является просто технически интересным?"

3. Предложение альтернативы и поиск компромисса. Я не говорил "нет, только так". Я сказал: "Я понимаю преимущества нового подхода для масштабирования. Давайте рассмотрим гибридный вариант: основную OLTP-нагрузку берет на себя реляционная БД, а для логгирования событий и кэша мы как раз внедрим ту самую NoSQL-систему. Это снизит риски и даст команде необходимый опыт."

4. Эскалация на основе фактов. Когда техническая дискуссия зашла в тупик, я, как менеджер проекта, использовал свой мандат. Я четко заявил: "Основываясь на анализе рисков (приложен здесь), я, как ответственный за delivery, не могу подписать план с высоким риском срыва сроков. Я предлагаю принять решение в пользу Option A. Готов зафиксировать этот риск в реестре и доложить стейкхолдерам о нашем обоснованном выборе."

Результат и выводы

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

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

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