Про то как я решил задачу вместо программиста и понял, что зря.      Часто бывает так, что твои компетенции не ограничиваются той должностью, которую ты занимаешь. Например, бизнес и системному аналитику не нужно иметь навык программирования. Главное понимать логику разработки и ее возможности, чтобы уметь грамотно составить технические требования для разработчиков. Но вот у меня получилось так, что я немного умею прогать на Python. И как не странно, это сыграло со мной злую шутку.        На проекте нужно было подружить 2 системы, одна — от вендера, а вторая — наша разработка. В результате анализа столкнулись с критичным ограничением. Заказчику нужно было, чтобы система вендора направляла результаты работы в нашу систему, где сотрудники могли работать с этими данными и строить привычные им отчеты. Но как оказалось, система от вендора не умеет отправлять такие данные по API. Хорошо хоть может выгружать в csv файл, но и здесь проблема. Система может выгружать файл только в корень сервера, где крутится само ядро системы. Это грустно. Расшаривать заказчику доступ до файла на сервер системы нельзя по соображениям безопасности.        Я предложил решение, написать программу, которая будет копировать новые файлы с сервера системы вендора и размещать их в сетевой папке, доступной заказчику. Решение руководство поддержало, но вот только программиста на эту задачу выделить не могли. Я решил сам выступить в роли программиста. Тем более, что для такой задачи достаточно написать скрипт с одной функцией и парой библиотек. Вроде бы звучит красиво, но тогда я не подумал, что написанная программа автоматически станет моей зоной ответственности и придется заниматься ее поддержкой. Еще и оказалось, что никто не собирается мне выделять рабочие часы, так как разработка это не профиль системного аналитика. Для меня это было странным и неприятным моментом. Но такой я человек, за свои слова отвечаю. Раз уж вызвался, то доведу дело до конца.        Вечерами и в выходные дни занялся задачей:

• отрисовал схему, согласовал с ИБ;
• настроил внешний доступ на чтение файлов в каталоге на Linux сервере системы вендора;
• примонтировал каталог на мастер сервере;
• примонтировал smb каталог;
• разработал скрипт;
• настроил cron для периодического запуска скрипта.        Спустя 3 вечера кропотливой работы все заработало. Провели тестирование, доработал еще пару моментов и проект запустили в ОПЭ. С одной стороны было приятно, но с другой, отголоски этой задачи продолжают догонять меня по сей день.        Примерно через 2 недели заказчик обратился в техподдержку, нужно было доработать некоторые моменты. И ребята, которые обслуживают систему пришли ко мне. Пришлось снова тратить личное время, чтобы допилить скрипт. Я думал на этом закончили, но через 2 месяца снова заявка и снова доработка.        В общем, что хочется сказать и какие выводы сделать. С одной стороны хорошо, когда системный аналитик владеет техническими навыками, но с другой, нужно уметь правильно их применять. Не стоит перетягивать на себя роль программиста или системного инженера. Лучше всего сделать упор на аналитику, свои прямые обязанности, а то что в них не входит, доверить коллегам. Если видишь какие-то узкие места, знаешь лучшее решение, то просто подсвети это коллегам, но не бери исполнение на себя. На своем опыте понял, насколько важно балансировать на грани компетенций и правильно расставлять приоритеты.