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

Почти все задачи были сложные и требующие компромиссов. Обычно конфликт требований бывает из-за того, что делать надо долго, а сделать надо было ещё вчера. Компромисс выражается в том, что делаем самый необходимый минимум, который согласно правилу Парето закрывает до 80% потребности. Далее примеры из моей практики: На последнем проекте был случай, когда после анализа процессов бизнес-аналитики описали необходимые доработки. В целом это всё требовало много времени и разработка откладывалась, но изучив результаты анализа, я указал, что подобные функции реализованы в нашей лоу-код платформе, необходимо только сделать дополнительные настройки аналитикам, а разработчикам необходимо добавить только одну функцию. Предложенное решение позволило серьезно сократить сроки разработки, ускорить сдачу функций заказчику и уложиться в сроки контракта. Вообще основные трудности всегда были при взаимодействии с бизнесом с большим количеством стейкхолдеров. Например, на предпоследнем проекте внедряли ЛИМС на предприятии с 10 отделами контроля и 2 лабораториями, у каждого подразделения была своя система шифровки образцов, а внедряемый ЛИМС не имел гибкого процесса настройки шифровки. Доработки лимс могли занять от двух месяцев до полугода. Предложенным решением было изменение регламентов всех подразделений, использование единого подхода по шифровке образцов. Путём согласования такого подхода удалось в короткий срок обойти ограничение платформы без долгих затрат со стороны разработки. Ещё один сложный вопрос был при внедрении процессов ВЛК в лабораториях нескольких заводов, когда после первичного анализа потребностей заказчика, было выявлено большое разнообразие имеющихся процессов (способов) реализации ВЛК. В ходе совещаний с разработкой стало понятно, что реализация всех вариантов через низкоуровневый код потребует много времени, к тому же понадобится более глубокий анализ всех процессов (способов из разных методики измерений), что тоже займет больше времени. Тогда я предложил максимально ускорить разработку за счёт доработки уже имеющегося модуля для лоу-код настройки. А последующую реализацию отдельных процессов переложить на аналитиков, которые будут проводить анализ процесса и сразу его настраивать в виде простого кода. Это сократило затраты на разработку и анализ, ускорило появление прототипа, который можно было демонстрировать заказчику и обеспечило своевременное закрытие последнего этапа проекта.