Вариант разработчика против варианта аналитика
Свидетелем этой ситуации я стал, когда работал на должности системного архитектора.
На протяжении трех лет команда разработки получала данные из других систем и не волновалась о том, как эти данные формируются. Со временем появилась потребность передавать документы из своего контура в несколько внешних систем-получателей.
Сами данные нужно было получать из одного источника, а вот структура данных требовалась для каждой системы своя, поэтому типичный обмен через шину не совсем подходил. С одного узла копирование на разные системы было невозможно ввиду ограниченности бюджетов у систем-получателей.
Аналитик пришел к разработчику с запросом: есть три разных узла и три технических задания с различным набором атрибутов данных, которые должна получать каждая система. Однако разработчик указал, что такая реализация ведет к постоянным доработкам системы. Например, каждый раз при запросе нового реквизита из объекта-источника надо править код и добавлять необходимый реквизит для каждой из трех систем.
В свою очередь, разработчик предложил другой вариант: создать три очереди в системе, где аналитики смогут редактировать состав данных для обменов в пользовательском режиме через специальную обработку. Аналитик с этим не согласился, потому что решение не отвечало требованиям безопасности и создавало лишнюю работу для его коллег.
Противоречие в решениях вылилось в открытый конфликт на внутренней встрече. Аналитик считал, что разработчик хочет спихнуть дополнительную работу на аналитиков, и очень жестко отстаивал свои границы. Ребята уже начали выходить за рамки допустимого диалога: аналитик обвинял разработчика в банальной лени и нежелании делать свою работу, а разработчик ставил под сомнение компетенции аналитика, потому что он предлагал неудачный вариант реализации.
Я об этом конфликте узнал от аналитика. Разумеется, не стал выслушивать только одну сторону и организовал общее собрание со всеми заинтересованными сторонами.
На общем собрании, взвесив оба варианта и ориентируясь на трудозатраты на поддержку и сопровождение будущей системы, я выбрал идею разработчика. Она требовала меньше трудозатрат и упрощала поддержку, особенно с учетом того, что все системы были во внутреннем контуре заказчика.
Дополнительно удалось существенно сократить трудозатраты разработчиков и аналитиков при тестировании интеграции, потому что новые реквизиты продолжали добавляться и при этом не было потребности существенно переписывать код.
Кто прав — диспетчеры или планировщики?
Второй случай также из моего опыта, когда я работал аналитиком. Мы создавали автоматизированные рабочие места (АРМ) для завода — в отделе планирования и отделе диспетчеров, которые отвечали за отгрузку нефтепродуктов. Отдел планировщиков составлял план по отгрузке продукции, учитывая очень много факторов (план продаж, производства, закупок). А главная цель диспетчерского отдела — управление отгрузкой в течение ближайших суток, то есть только в течение своей смены.
В разработке было два автоматизированных взаимосвязанных рабочих места, одно использовало данные другого, и наоборот. С ними работали диспетчеры и планировщики. Основным заказчиком было вышестоящее подразделение, в которое входили эти отделы. Первоначальный запрос на автоматизацию пришел из отдела планирования, но в процессе проектирования АРМ для планировщиков выяснилось, что нельзя сделать их без данных от диспетчеров. И для того чтобы получить данные от диспетчеров, нужен инструмент для ввода и генерации этих данных, т. е. еще одно АРМ.
Когда проект подошел к стадии опытной эксплуатации, стало понятно, что из-за недостатка ресурсов и ограничений по срокам релиза мы не сможем одновременно вывести оба АРМ на продакшен. И команда приняла решение отдавать их в разных релизах, но тонкость состояла в том, какой из релизов выпускать первым. Этот момент нам надо было урегулировать с заказчиком в лице диспетчеров и планировщиков.
Мы организовали встречу со всеми заинтересованными сторонами, но не ожидали, что наш вопрос выльется в такую жаркую дискуссию. Диспетчеры говорили, что каждый день на протяжении нескольких месяцев тестировали АРМ, делали замечания, ребята их устраняли, они уже к нему привыкли, оно им нравится. И главное, они работали одновременно в двух программах и уже устали от этого.
Планировщики настаивали на том, что именно они и есть основной заказчик, а второго автоматизированного рабочего места изначально вообще не было в планах. Кроме того, у них не было программы, работа велась только в Excel.
При этом диспетчеры действительно проявляли большую заинтересованность и вовлеченность в проекте, а планировщики заняли позицию: «Мы будем работать уже в готовой программе, на реальных данных. На тестовых данных ничего проверять не будем».
Собрание закончилось, а решение так и не было принято, потому что никто не хотел уступать позицию.
Накануне даты релиза нашей команде нужно было самой понять, какое АРМ для нас в приоритете. В результате более тщательного анализа руководитель проекта принял решение, что в первую очередь мы запускаем АРМ для диспетчеров: это требовало меньше ресурсов разработки и все необходимые для тестирования данные уже были в системе.
С этим решением он произвел эскалацию на общего руководителя планировщиков и диспетчеров.
В итоге отдел планировщиков согласился и принял решение перенести свой запуск на несколько недель. Разумеется, руководителю проекта пришлось дать гарантию, что их функционал к тому времени будет готов на 100%, и добавить еще несколько функций.
Что не поделили аналитики
Этот конфликт произошел, когда я работал на должности системного архитектора. Два аналитика готовили одну обработку: условия захватывали обе их зоны ответственности. Они собирали требования с разных стейкхолдеров, отвечающих за один и тот же бизнес-процесс.
Конфликт возник на почве того, что нужно включать в обработку данных, а что не стоит. Это привело к тому, что задачи отдавались разработчикам, которые трудились над одним и тем же функционалом. Ветки их разработок приводили к проблемам, которые не решались системой по той причине, что требования от разных стейкхолдеров были противоречащими. Всё это вылилось в обсуждение на общей планерке.
Видение процесса у пользователей было разным, поэтому и требования они формулировали зачастую противоречивые. Объясню, в чем суть. Два аналитика работают над одной большой обработкой, которая рассчитывает план отгрузок, исходя из огромного количества условий (72 входящие таблицы данных). Естественно, такое большое количество данных не может управляться одним человеком и процесс расчета очень объемный как в шагах, так и во времени. Для того чтобы грамотно учесть все условия, формулы и последовательность расчета, нужно опросить большое количество пользователей. Наша команда для более прозрачного управления разделила входящие таблицы данных на группы, и каждый аналитик работал со своей группой и отвечал за свой кусок процесса.
В итоге получилось так, что есть взаимозависимые условия при расчете и разный взгляд на реализацию процесса у пользователей, потому каждый знает только свою часть процесса, единого источника правды не было, и поэтому информация от каждого пользователя считалась правильной. Привело это к тому, что один пользователь не посчитал нужным учитывать при расчете несколько условий от другого пользователя. Наши аналитики об этом не знали и поставили разным разработчикам задачи, которые частично противоречили друг другу.
Как результат, когда разработчики начали соединять все разработки в одну общую обработку, выяснилось, что они привели к конфликту в итоговом алгоритме.
Один аналитик говорил другому, что так работать и собирать требования к системе нельзя и не получится в будущем. Он был уверен, что конфликт из-за противоречащих требований необходимо выносить на обсуждение команде заказчика: если есть два стейкхолдера из одного процесса, которые видят его по-разному, то они должны изначально договориться между собой.
Руководитель проекта разделил зоны ответственности аналитиков и расставил границы между ними, чтобы они больше не пересекались либо чтобы пересечение было несущественным. Т. е. один из аналитиков полностью взял на себя задачи по работе с этим функционалом, чтобы исключить возникновение противоречий. Такое решение позволило снизить накал страстей, т. к. устраивало всех участников конфликта, и спор не перешел на сторону заказчика. Чтобы усилить контроль и консолидировать все требования к этому большому процессу, дополнительно подключили меня как архитектора.
Личный конфликт
К сожалению, личный конфликт в работе у меня тоже был. Ситуация произошла на внутренней встрече с командой. На встрече присутствовали 12 тимлидов по всем направлениям. Наша команда готовилась к сдаче выполненных работ заказчику для тестирования, и я рассказывал, как нужно писать сценарий тестирования, и объяснял все тонкости процесса.
Задачей каждой команды было составить от 10 до 30 сценариев тестирования и описать на Confluence с использованием шаблона. После того как вопросов по процессу и шаблону у команды не осталось, я попросил указать сроки подготовки сценариев каждого тимлида, разумеется, в рамках сценариев своей команды. И тут я наткнулся на очень сильное сопротивление одного из них, у которого был самый объемный блок. Человек просто отказывался называть хоть какие-то сроки, объясняя это тем, что предложенный процесс и шаблон документа их команде абсолютно не подходит.
Я пытался перевести диалог в конструктивное русло, узнать, что конкретно не подходит, предлагал разобрать пример, но мой оппонент ничего не хотел слышать. К тому же поток недовольства всем происходящим лился уже без моих контраргументов. Видимо, накипело и нужно было выговориться, но были два момента, которые для меня недопустимы:
- Человек при других тимлидах занижал их заслуги, ставил свою команду выше других и говорил, что для них нужны особые условия. Например, говорил другим тимлидам: «Да что у вас там, работы на два дня! У меня у одного сценариев больше, чем у вас всех, вместе взятых. Вы видели наши процессы, да их невозможно положить в сценарии, потому что там очень много шагов, не то что у вас!» Такой подход, действительно, может быть, и его можно принять, но не надо при этом ставить себя выше других.
- Человек использовал на мне косвенное поучение. Представим, что его команда отвечает за бизнес-процесс жарки пирожков. И этот человек мне говорит при всей команде: «Вообще-то, на вашем уровне надо знать, как жарить пирожки, прежде чем говорить моей команде, что делать». Негатив от этого приема возникает потому, что человек ставит себя на позицию выше вас, как будто он ваш начальник или учитель, хотя это вы от него что-то требуете. И кроме того, при прочих участниках встречи указывает на вашу некомпетентность. Я специально говорю об этом в третьем лице, потому что меня это лично не задело, но я считаю, что это прямое профессиональное оскорбление именно меня, а хамов надо ставить на место. Я же рекомендую придерживаться принципа: похвала — публично, наказание — лично.
Словесная перепалка между мной и тимлидом длилась около 20 минут. Я старался найти разные аргументы, компромиссный вариант и пропускал мимо ушей негатив в мою сторону и в сторону команды. Он же использовал лишь два аргумента, описанные выше: «Моя команда особенная, а ваши посредственные» и «Вы не знаете наши процессы, поэтому не можете говорить нам, как работать». В итоге я предложил закончить обсуждение лично позднее и завершил общую встречу.
На отдельном звонке непосредственно с этим тимлидом такого напора уже не было, человека как подменили — видимо, действительно «накипело». Я пошел на компромисс и признал, что есть некоторые особенности в их процессах, но они не такие существенные, чтобы под них делать отдельный шаблон и перестраивать процесс тестирования. При этом указал на недопустимость такого поведения и объяснил, как решать такую ситуацию в будущем. Человек сказал, что всё понял, и выглядел виноватым. Мне этого было достаточно 🙂
Выводы
Во всех вышеописанных примерах наглядно видно, что, пока люди гнули свою линию, они просто не могли договориться. Как только им помогали выйти на поиск совместного решения, а не доказывания, кто лучше знает, решение находилось. Хотя без вмешательства внешних сил в лице руководителя конфликт не разрешался: именно он помогал найти оптимальное решение с точки зрения имеющихся ресурсов и технических ограничений.
Участники команды должны иметь эмпатию и способность взглянуть на проблему со стороны оппонента. Развивайте это качество в себе и, критикуя любое решение, представляйте себя на месте того человека, которого критикуете. И будьте аккуратны с профессиональной гордостью, иначе конфликт из профессионального перерастет в личный.
