Ответ
Подхожу к конфликтам как к возможности улучшить продукт и процессы, фокусируясь на фактах и общей цели.
Конструктивный алгоритм действий:
- Отделить проблему от личности. Конфликт не "я vs. разработчик", а "тест-кейс vs. реализация".
- Опираться на данные. Предоставляю конкретные артефакты:
- Требования из спецификации (JIRA ticket, Confluence).
- Шаги воспроизведения бага.
- Скриншоты/логи, демонстрирующие проблему.
- Ожидаемое поведение, описанное в acceptance criteria.
- Инициировать диалог. "Я вижу расхождение. Вот что говорит документация, а вот что происходит в системе. Как мы можем это согласовать?"
- Привлечь арбитра при необходимости. Если согласие не достигнуто, прошу мнение тимлида, проджект-менеджера или аналитика для финального решения по требованиям.
- Зафиксировать результат. Независимо от исхода (баг/фича/улучшение), обновляю задачу в трекере, чтобы решение было документировано.
Пример: Разработчик считает, что падение приложения при вводе 10 000 символов в поле — не баг. Я предоставляю:
- Требование: "Поле должно принимать до 255 символов".
- Результат теста: Приложение крашится, а не показывает ошибку валидации.
- Риск: Возможность DoS-атаки. Итог: Команда признаёт дефект и вносит исправление для корректной обработки длинного ввода.
Ответ 18+ 🔞
А, вот ты как, подходишь к конфликтам? Как к возможности улучшить? Ну, молодец, блядь, оптимист. А я вот, сука, иногда смотрю на это как на возможность кому-нибудь ебальник набить, но твой способ, наверное, правильнее, да.
Слушай, а у меня там свой, блядь, алгоритм выработался, неформальный такой. Прям по шагам, как в мануале, только с душой, понимаешь?
Алгоритм действий, когда тебя уже бесит, но надо не наорать, а сделать дело:
-
Личность в сторону, нахуй. Это самое главное, ёпта. Не «Вася-козёл написал хуйню», а «функция „сохранить“ работает как попало». Как только начинаешь на личности переходить — всё, пиши пропало, диалог превращается в «сам дурак». А нам надо продукт делать, а не выяснять, чья мамка круче.
-
Данные, сука, данные! Без них ты просто воздух трясёшь. Подходишь и не «чё за херня?», а:
- Вот тикет, вот требование, чёрным по белому, блядь.
- Вот я делаю раз, два, три — и бац, пиздец.
- Вот скрин, где всё горит синим пламенем.
- А вот, блядь, что должно было случиться по документам. Видишь разницу? Не я придумал, а тут написано.
-
Диалог начинать, а не ультиматумы кидать. Фраза «как мы можем это согласовать?» — это волшебная, блядь. Она как бы говорит: «Я не против тебя, я за общее дело, давай вместе подумаем». Часто оказывается, что документы устарели, или я косяк в тест-кейсе нашёл. Бывает же.
-
Если упёрлись рогами — звать большого дядю. Не надо до последнего стоять на своём, ебать друг другу мозги. Типа «окей, мы не сошлись, давай спросим у [тимлида/аналитика], как по канону должно быть». Это не стыдно, это профессионально. Пусть он рассудит, этот, блядь, Соломон.
-
Фиксируем результат, чтобы не было «а я говорил!». Всё, что решили — сразу в таску. Баг, не баг, фича, «оставим как есть» — неважно. Главное, чтобы через месяц не началось «а мы это не обсуждали, ты всё выдумал!».
Вот, например, реальный случай, был у меня: Сидит разработчик, смотрит на баг-репорт и такой: «Да это не баг, это фича! Приложение упало? Ну и что, кто будет 10000 символов вводить?»
А я не спорить начинаю. Я открываю спецификацию и тычу пальцем:
- Требование: «Поле „Комментарий“: макс. длина — 255 символов, валидация на стороне UI».
- Реальность: Ввёл 10000 символов — не ошибка, не предупреждение, а просто хрясь! — и всё накрылось медным тазом. Сервер, наверное, в ахуе.
- Риск: А если это не юзер, а скрипт? DoS-атака же готовая, в рот меня чих-пых!
И говорю спокойно: «Понимаю, что сценарий редкий. Но разница между „показать ошибку“ и „положить всё приложение“ — это, как бы, овердохуища разница, да? Как думаешь, стоит ли привести в соответствие?»
Итог: посмотрели, почесали репу, и такой: «Да, это баг, ёпта. Надо обрабатывать корректно». И пофиксили.
Вот и весь секрет. Без истерик, но и без похуизма. Работаем.