Написать статью решил после прочтения этой. Вроде бы и правильного в ней было много, но с другой стороны, понимаешь что нельзя на баги и дедлайны реагировать эмоционально. Так в чём же проблема?
Все ниже приведённые стадии выдуманны мной исходя исключительно из моего опыта работы. Для иллюстрации на примерах, будем использовать три ситуации:
- В баг трекере появилась новая проблема
- На разработчика пришла жалоба со стороны заказчика
- Продукт не успевает выйти в срок
Стадия первая, А есть ли проблема?
Поведение участников: рационально.
Первое что мы делаем, услышав о проблеме — пытаемся удостовериться в её существовании — воспроизвести, проверить график успеваемости проекта. Это не отрицание проблемы, просто проверка. Ведь если проблемы нет — то и решать нечего.
Примеры:
- В баг трекере появилась новая проблема Пытаемся воспроизвести
- На разработчика пришла жалоба со стороны заказчика Надо бы проверить, не пришло ли письмо с изменённым заголовком «от кого», но скорее всего — проблема таки есть.
- Продукт не успевает выйти в срок Всё зависит от того, откуда у Вас эти сведения — если это мысли бухгалтера, обиженного на IT, это одно дело. Но если с повинной головой пришёл тимлид — у нас определённо есть проблема
Стадия вторая, В чём проблема?
Поведение участников: рационально.
Нужно определить, в чём именно заключается проблема — толи сервер неправильно настроен, то ли юзер кеш не сбросил, то ли у заказчика личные счёты с разработчиком. Эта стадия должна плавно перетекать в четвёртую, но, к сожалению, обычно переходят к третьей.
Примеры:
- В баг трекере появилась новая проблема Если баг добавил тестировщик, то он должен был описать условия возникновения. Если же его добавил пользователь — определяем когда баг появляется
- На разработчика пришла жалоба со стороны заказчика Выясняем, какие события предшествовали этому, вчитываемся в текст письма
- Продукт не успевает выйти в срок Нужно понять, какая часть продукта отстаёт или какие орг. вопросы у нас не решены
Стадия третья, Кто виноват?
Поведение участников: эмоционально.
Извечный славянский вопрос :). Именно на этой стадии начинаются нервы и всё остальное, описанное здесь. Моё личное мнение — надо всеми усилиями избегать её, т.к. никаких продуктивных решений на этой стадии не принимается, а вот энергии тратится огромное количество. Да и вообще — хотите рассорить команду — ищите виноватых. Но самый невероятный поступок который я видел — успокоиться на этом этапе — а что, виноватые найдены, можно спокойно жить дальше, зачем проблему то решать?
Примеры:
- В баг трекере появилась новая проблема Ааа, опять Вася набыдлокодил!
- На разработчика пришла жалоба со стороны заказчика Да я что виноват, что эти мудаки в час ночи звонили?!
- Продукт не успевает выйти в срок Даа, мы все знаем, как наш IT отдел работает!
Стадия четвертая, что делать?
Поведение участников: рационально. Но если начать сразу после третьей стадии, может быть и эмоционально
Если Вы всё таки не удержались, и нашли виноватых, обязательно остыньте перед этой стадией, иначе наделаете проблем.
Если же мы можем логически мыслить, то разбираемся более детально с причинами проблем, и если их можно устранить — выбираем путь решения. Если нельзя — пытаемся что-то изменить, чтоб этих проблем не существовало — отрезаем функционал, пересматриваем список партнёров и тд
Примеры:
- В баг трекере появилась новая проблема Так, вроде ошибка в этом участке кода, но стоит уточнить у Васи
- На разработчика пришла жалоба со стороны заказчика Вась, похоже тебя просто неправильно поняли...
- Продукт не успевает выйти в срок Критичным для нас является *функционал*, он вроде готов. Давайте остальное уберём, первый релиз, всё таки
Стадия пятая, решение проблемы
Поведение участников: рационально
Просто делаем намеченное ранее. Если стадия затягивается, то может потребоваться ещё перепланирование.
Примеры:
- В баг трекере появилась новая проблема Исправляем ошибку
- На разработчика пришла жалоба со стороны заказчика Извиняемся перед заказчиком, проводим беседу с Васей
- Продукт не успевает выйти в срок Согласовываем с продукт менеджерами изменения, перераспределяем усилия
Стадия шестая, кнут и пряник или «Кто виноват»-2
Поведение участников: рационально
Мы уже говорили о поиске виноватых, и пришли к выводу, что это пустая затея. Однако, часто нужно всё таки отреагировать на постоянные промахи сотрудника, или наоборот, наградить за хорошую работу. Главное при этом, не выносить всё на суд коллектива, не устраивать охоты на ведьм. К тому же, на данном этапе, часто оказывается что проблема не так существенна, как казалась нам на первых стадиях, и собственно наказывать виноватого (который, быть может всё сам и справил) просто нет смысла.
Примеры:
- В баг трекере появилась новая проблема Вася был занят на другом проекте, но Петя остался после работы и всё исправил. Дадим ему премию
- На разработчика пришла жалоба со стороны заказчика Журим Васю за грубость, и обещаем, что в следующий раз будет штраф
- Продукт не успевает выйти в срок Случай самый серьёзный, так что, возможно, прийдёться кого-то и уволить
Каков итог? Он очень прост — большинство стадий вполне логичны и рациональны. Они проходят без напряжений. Но есть одна стадия, которую к сожалению очень любят у нас — это искать виноватых, вместо решения проблемы. Если Вы сможете от этого уйти — работать станет намного комфортнее
Автор: vaevictus
