[Ролевые модели] Раздел 1. Роли и связанные понятия

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

Анатолий Левенчук говорил, про своего ученика “пришёл на производство, смотрю на людей и вижу людей выполняющих практики”. Так же я теперь вижу “людей исполняющих какие-то роли” и не могу развидеть. И не хочу развидеть потому что это первая зацепка на пути к устранению неудовлетворенности. Неудовлетворенность проявляется при взаимодействии с людьми по поводу выполнения наших общих задач.

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

Обращаю внимание. У нас периодически случаются повторные циклы работ. Была задача реализовать новый функционал. Она описана аналитиком со стороны бизнеса. Реализована инженерами. Протестирована инженерами по качеству и выпущена в эксплуатацию. Задача закрыта. Проходит время. Аналитик приходит с багом. Я (инженер) читаю описание бага. И понимаю, что там описан дополнительный кейс. Про который мы (я, он, она, кто?!) не подумали, когда проектировали/реализовывали и даже тестировали новую фичу.

Роль интересует ряд характеристик (предметов интереса) относительно системы.

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

Разные роли имеют разные ролевые интересы/предпочтения в важных характеристиках.

Это второй круг подобных историй. Часто оказывается, что “мы сделали баг намеренно” потому что удовлетворяли ролевой интерес бизнеса (менеджмента?) - срок поставки фичи. Т.е. с другим аналитиком при реализации мы устно (надо было письменно) договорились, что сейчас вот это мы делать не будем, потому что нам надо успеть отдать к такому-то сроку. Теперь нынешний аналитик говорит “окей, но это же баг с точки зрения клиента, оно же не работает”. Я говорю “но задачи на то, чтобы это работало никто не ставил, мы договорились, что сделаем это позже. Может как раз сейчас пора поставить задачу на доработку, а не баг?”. Дальше может быть много красок, изменений тона голоса, повторов этих двух реплик по 4 раза. В конце я обычно сдаюсь. Про себя продолжаю накапливать неприятное отношение к аналитикам, как классу или к конкретному человеку в роли. Надеюсь, что всё-таки к роли этого человека, а не личную неприязнь.

Учат не должностям, а выполнению практик (игре по роли).

Первая попытка разрешить неудовлетворённость свелась к тому, что “спорить себе дороже”. У меня не хватает риторики, чтобы объяснить почему такая стратегия невыгодна всем. Следующий вопрос, который я себе задаю: какой мой интерес по роли инженера в этих случаях? Видимо просто взять задачу и добиться нормального описания. Хорошо бы максимально подробного, чтобы не принесли очередной баг. Но про описания, системы и как делать хорошо - впереди светлое будущее “Основная программа ШСМ”. Пока у меня нет ни мастерства, ни инструментов, чтобы зарешать до конца. При этом заметила, что в “баталиях” я могу выпадать из роли инженера. Мне уже становится принципиально важно доказывать, что не прав человек в роли аналитика. Потом подумала ещё, что грань тонкая и возможно в конце уже не роли спорят. А два раздраженных человека. Интерес по ролям улетел в трубу, мы тупо ругаемся. Тратим силы, нервы, копим фрустрацию. Зачем это надо? Мне не надо.

Если роли не выполняют свои практики в проекте, если они бездействуют, то вас они не должны интересовать.

Контринтуитивно - не должны интересовать. Я когда это прочитала, меня попустило. Остаётся вопрос, если не выполняется конкретная роль, кто же её должен выполнять. Пока пробую ходить к другим людям с похожими ролями. Где-то это помогает. Где-то не очень. И думаю, как подбирать слова, чтобы максимально мягко проходить ситуации с багами. Можно ли тыкать носом в описание, если там написано, что работает в случаях 1, 2, 3. А мне приносят баг, где написано, что в случае 4 не работает. Сработает логика пересечения множенств? Не знаю, проверим. Радует, что есть описание того, как мы договорились. Описание зафиксировано в трекере задач. Автор описания - аналитик. С меня взятки гладки.

Думаю меня ещё раздражают, косяки страгерирования. Вроде все знают, что у нас есть важные задачи и нерешенные проблемы, которые влияют на то, как работает вся система. А когда тебе приносят проблему про “фантик”. Мелкий косяк в UX, я не понимаю зачем это всё. Нам делать нечего, может мы реально полезным инженеров займём? Но это я тоже вываливаюсь из роли. Хотя может и не совсем, будем разбираться.