#подкаст #сережаимикрофон #яндекс #рассуждения #мысливслух #примерразвитиятехнологий

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

Если брать историю, я бы добавила историю развития технологий, то мы как раз и получаем волны развития. Когда сначала способ передачи информации у нас не особо интересен компаниям, государству и данные передаются анонимно, а потом всё мы приходим к процессу, что дай паспорт, ИНН и другие данные о себе.

18 век письма, пишешь адрес и всё, можешь по этому адресу прийти.
Дальше телефон - даёшь номер и тебя соединяют через оператора, но прийти к тебе, это нужно знать адрес. Десятками лет этот барьер стирался и в 80-х годах можно было узнать и адрес. Дальше справочник жёлтые страницы лежал на станциях метро, я вот помню его, это уже 90-ые. Открыто можно узнать и номер телефона, и адрес. Моя мама по началу телефона могла сказать, к какому району Москвы относится телефон))
Потом интернет, и тоже все начинали со своих ник неймов, анонимности, а чем больше интернет проникает, тем больше происходит регулирования.
Теперь ждём новый способ коммуникации, который у нас также будет проходить этап анонимности))

Фактически Иван Черевко рассказал график развития технологий)))
Обычно я этот график через развития транспорта рассказываю, а вот ещё отличный пример через технологии коммуникации.

А насчёт приватности, черт его знает, стоит ли бояться, что мир прозрачен и все знают про всех. И через интернет можно найти много информации. Всё равно всё идёт к тому, чтобы эта информация была подтверждена. И интернет пока не следить за авторством, того, что появляется в сети. Фейк на фейке...

Ещё ребята обсуждают защиту финансовой информации. Всё таки PCI DSS как стандарт существует давно, и информация о платежах лучше шифруется и защищена, чем персональные данные или личные данные. При этом сотрудники Яндекса рассказали о том, что можно чистить историю заказов в яндекс)) Нехотя, но рассказали.

Вот тут то и я вспомнила одного разработчика, который так парился насчёт личного кабинета и мобильного банкинга, что пользовался виртуальной клавиатурой и заходил в банкинг только в экстренных случаях. А на телефоне у него не было приложения. Он мне пытался объяснить свою цепочку размышлений)))) Я поняла, что чем меньше знаешь, проще жить)) и в какой-то момент, когда ты знаешь как оно работает пользоваться совсем не хочется.

Про S - кривую писала вот тут: https://t.me/start_in_IT/357

С наступающим новым годом дорогие и любимые мои подписчики)))

Год капец какой был непростой. Когда меня спрашивали про цели и мечты, в этом году, я просто говорила - "мне бы выжить" ))
Цель выполнена, я выжила и даже как-то стала возвращаться в жизнь!

Благодарю всех за поддержку, за то, что читаете меня, иногда со мной же обсуждаете меня, не помня, что это я писала))) Это показатель! Спасибо за отклики, что приходите на курсы, менторство, конференции. Конференция в Новосибирске в моем сердце навсегда! Сибирь просто топ место и топ люди) ещё раз спасибо за это Евгению Галактионову!

Слава богу идей много, главное нам всем сил физических, моральных, чтобы с кайфом от жизни и от работы идти дальше)

Желаю всем здоровья, в том числе и ментального!) Чтобы вы были всегда в строю, востребованы и могли себя реализовать! Береги себя, во время отдыхайте, празднуйте новый год, один из самых тёплых, семейных праздников)))

Пусть всё будет хорошо, а там уже и отлично будет рядом)

😍❤️🔥😜👏👍🎄🧣🌏💫✨🍾

Мы с коллегами-добровольцами подготовили для вас
Базу ссылок на полезные материалы по системной интеграции
для аналитиков и проектировщиков.

В базе собраны ссылки на русскоязычные и англоязычные статьи, видео, книги, сервисы и курсы.

Что в неё сейчас вошло:

Основы интеграции информационных систем
- Постановка задачи и общий обзор
- Способы классификации интеграций

Форматы представления данных
- Форматы JSON и YAML
- Форматы XML и XSD

Сетевые протоколы и транспорт
- Протоколы HTTP, HTTPS
- Протокол WebSocket

Сценарии взаимодействия, Sequence, Plant UML

Web Serviсes / RPC
- Проектирование API
- REST-like сервисы. Стиль REST
- Протокол SOAP и форматы XML, XSD, WSDL
- Технология GraphQL
- Технология gRPC

Обмен сообщениями
- Паттерны обмена сообщениями
- Apache Kafka
- Брокер Rabbit MQ

Файловый обмен

Интеграция через общую БД

Архитектурные паттерны интеграции систем
- Интеграционные шины, Enterprise Service Bus (ESB)
- API Gateway, Backend For Frontend
- Оркестрация и хореография
- Circuit breaker

Дальше готовим другие подборки по темам:

- Базы данных и анализ данных
- Бизнес-анализ и моделирование
- Архитектура программного обеспечения и Systems Design

#мысливслух #рассуждения #usecases #мойопыт #менторство #замечено #выводы #системныйанализ

Почему аналитики плохо пишут use cases?

Очень часто на курсах по интеграции в ШСА, да и не только, на менторстве тоже, и на собеседованиях встречается общая проблема по use cases. Аналитики плохо пишут сценарии вариантов использования.

👉1.Во первых, есть аналитики, кто не делает различий между use cases и user story. Вместо того, чтобы спрашивать аналитиков различие между Soap и Rest, на собеседование, лучше спросить различие между use cases и user story.
👉2.Во вторых, сценарии, как техника, используются на разных уровнях абстракции и не только аналитиками, но и тестировщиками, проектировщиками интерфейсов, продактами, да всеми)) Удобно.
👉3.Действительно, на системном или на уровне проектирования взаимодействия систем, мало кто из аналитиков грамотно может описать use cases. Это уже уровень архитектора, проектировщика, разработчика. Но он часто необходим на проектах, особенно если речь едет об интеграции.
👉4.Часто идёт ещё и смешение понятий функция и сценарий использования. Хотя use case вполне можно считать спецификацией функции.
👉5.Ну и плюс очень часто мы стараемся оперировать каноничным подходом, который был у Коберна (по крайней мере я всех к нему отправляю). И ещё пытаемся смаппить use cases и user story, я об этом писала, аж в 2020 году, что есть такое понятие как use cases 2.0 - https://t.me/start_in_IT/257

В самой технике сценариев, нет ничего сложного. Вот тебе основной, happy, поток, вот тебе расширения, где есть альтернативы и обработки исключений. Сюда же ещё и циклы включают. И получается, что есть канон, и есть реальность. И как сценарий эволюционировал мало кто знает, да и просто нет времени, надо делать работу)))

В итоге мы получаем высокоуровневые, часто до конца не проработанные сценарии. Их бы ещё детализировать и ещё докручивать и докручивать.

Выводы у меня следующие:
✅1.Высокоуровневые, на уровне бизнеса и взаимодействия пользователь - система, аналитики вполне отлично справляются.
✅2.Если аналитик не имеет базы, фундамента, плохо пишет алгоритмы, блок-схемы, то и сценарии также идут плохо. Везде в основе теория графов, сети Петри.
✅3.Сюда же я отнесу абстрактное мышление, это прям бич. Переключаться с одного уровня на другой самая большая проблема. Сложно понять где мы находимся, и где наши границы и рамки описания сценариев.
✅4.Сценарии на уровне взаимодействия модулей, систем требует знаний словаря данных, модели данных, что кому передаёт, как, в каком формате, по каким протоколам, синхронно, асинхронно, или файлами, или голубиной почтой.
✅5.Плюс сценарий не панацея и часто его нужно дополнять описанием алгоритмов, функций, а это математика. И я опять возвращаюсь к базовым, фундаментальным знаниям.
✅6.И ещё сюда добавлю обзор архитектурных решений. Потому что нужно хотя бы на пальцах понимать, как выстроено решение, к которому мы пишем уже на системном уровне требования, а точнее проектируем на языке требований, функций, что объединяет в себе целый комплекс знаний.

Итого: круг замыкается снова на том, что системный анализ инженерия, и даже в таком простом, с первого взгляда, инструменте, как use cases, собирает целый комплекс знаний.

#системныйанализ #usecases #выводы #мойопыт #моемнение #замечено

Цель в use cases
Тема про use cases и системный уровень их написания оказалась животрепешущей. И на эту тему ко мне пришли ещё подписчики, чему я очень рада)))

Итак, давайте ещё соберём информацию.
Евгений Галактионов https://t.me/systemspodhod
правильно описал, то что проблема часто заключается в понимание цели. А зачем вообще use case и что он делает?

Это очень видно, когда на пользовательском уровне мы получаем набор use cases по crud.
Пользователь создаёт заявку, редактирует, читает, удаляет (или переводит в архив).

Но вот я диспетчер автобазы с автомониторингом, я вообще не мыслю такими понятиям! На кой ляд мне эти функции?
Бизнес пользователь думает о том, что ему Васю с Петей нужно отправить на линию да ещё так, чтобы они не слили бензин, доехали до места и сделали ремонт оборудования. То есть наш диспетчер Маша, хочет сформировать бригаду для выполнения запросы от жителей дома. И описать в ней ограничения, быстро согласовать и после проконтролировать выполнение.

Почувствовали разницу?
CRUD это прекрасно, спасает в любых обстоятельствах, но цели с точки зрения бизнеса, регламентов, должностных инструкций понятнее, важнее, что в свою очередь собирает функции в большие цепочки.

Уже классика жанра, когда разные команды делают разные функции, кнопочки, блоки на front-end, а работать с этим невозможно, потому что нет связи и пользовательских сценариев.

Но и на уровне межсистемного, межмодульного взаимодействия также часто никто не может рассказать, зачем одна система делает вычисления, кеширует данные и передаёт в другую? Кто-то был художником и так видел реализацию чего-то, для того чтобы ЧТО выполнить и получить?

А потом мы и получаем истории, про то, что мы не знаем кто этим пользуется, сейчас отключим и будем ждать, кто будет орать))))

18 января, в среду вечером, Евгений Галактионов поделится своими мыслями о роли Системного аналитика.
Откуда произошла данная профессия, каково ее место в процессе разработки и как правильно СА использовать в разных типах проектов?
https://sistemnyy-podkhod.timepad.ru/event/2286703/

#системныйанализ #usecases #функция #моделирование #СергейНужненко #митап

Мне очень нравится старое выступление Сергея Нужненко на митапе Superjob, аж 4 года как прошло, про функциональное моделирование, в том числе с помощью use cases.

ГОСТ нам говорит классификацию с чем нам приходится работать:

✅Информационная система
✅Автоматизированная система
✅Сервис

Это тоже подсказка, как нам определить рамки той области, к которой мы описываем use cases.

Рамки могут быть любые и это самое сложное вычленить блок и увидеть его, в том числе и на абстрактом уровне.

Делюсь ссылкой, как всегда уровень докладов Сергея Нужненко зашкаливает своей системностью и глубиной):
https://youtu.be/lIIPyaUVUeo

Прямая ссылка на сегодняшнюю трансляцию Евгения Галактионова в 18:00 по Москве
https://www.youtube.com/watch?v=DSM67ONbMdQ

#books #мояполка #интеграцияуправления #spaceX #критерииуспеха #мысливслух

Начала читать книгу "Интеграция управления программой и системной инженирии" Эрика Ребентиша. Про большие компании, проекты, где задействованы инженеры, проектирование и много всего.

И вот в первой же главе пример SpaceX. И вот такие интересные цифры, что NASA, использую свои традиционные подходы, тратит на разработку новой ракеты-носителя 4 млдр долларов, а при использование новых, коммерчески ориентированных подходов - около 1,7 млрд долларов.
Вот дураки, сколько же можно было бы распилить.

За счёт чего SpaceX удаётся добиться успехов?
✅1.Простота проектных решений. Проектирование ракетоносителей Falcon строится на принципе взаимозаменяемости. Для обеих ступеней используется керосин и сжиженный газ, обе ступени имеют одинаковый диаметр и сделаны из одного и того же материала. (Тут хочется провести аналогию и грабли, на которые многие компании наступают. Нет автоматизации вообще и стартуют сразу с уникальных сложных решений, ещё и с микросервисами, за время разработки компания подрядчик перемалывает свою команду и банкротится.)
✅2.Совместное расположение подразделений (Сбер к этому тоже пришёл). Все подразделения в одном здании площадью 93000 м2 в Хоторне, Калифорния, работает там примерно 4000 сотрудников (страшно себе представить этот муравейник)
✅3.Вертикальная интеграция - spaceX закупает исходное сырье, самостоятельно разрабатывает, производит, собирает, испытывает все двигатели, ракеты, космические корабли (нет подрядчиков).
✅4.Встраивание действий по обеспечению гарантий безопасности во все типы операций. Выстроенные процессы, инфраструктура для оптимизации и эффективности цикла - "проектирование - испытания - производство - сборка готовой продукции". Переиспользование элементов, компонентов, оборудования. Персональная ответственность сотрудников за разработку в течение всего цикла разработки, включая ответственность на горизонтали ведущих инженеров.
✅5.И главный и часто неосязаемый пункт - культура. Высокий уровень командной работы, взаимовыручка, координация, общение, генерация новых идей. Страсть к делу, "искра в глазах", необычные интересы. Перевод на вышестоящие должности происходит только на основе опыта и достижений сотрудника.

Ну и как показал твиттер)) ещё играет роль того, что Илон Маск не будь дураком отсеил сотрудников и начал драть, чтобы они работали, а не только пили смузи)

Что тут скажешь, все смотрят в сторону Илона Маска, и те пункты, что перечислены в книге больше кажутся #капитаночевидность банальными, но попробуй реально их превратить в жизнь))) Возможно сбер когда-нибудь станет такой компанией, но пока там можно встретить целые команды, которые что-то делают, и это что-то никому не нужно, вместе с бюрократией. Вцелом треш есть везде, я думаю и spaceX тоже нефига не идеал))) Просто реально работает и реально экономит деньги и достигает результатов.

#капитаночевидность #критерииНЕуспеха #аэропортДенвера #интеграцияуправления #мояполка #books #управление

Как не нужно делать
Продолжаю делиться информацией из книги и своими комментариями. Пробую ещё формат мини статей, так что пишите насколько удобно читать другой формат?)

https://telegra.ph/Kak-ne-nuzhno-delat-proektprogrammu-01-19

#мысливслух #пробренд #историиизжизни #замечено

Хотела начать с высказывания, что в СССР не было брендов, но потом поняла, что они были, но я всё таки опишу свои мысли.
ЦУМ и ГУМ до сих пор можно назвать брендом. Или часы, машины, определённых заводов.

Я как ребёнок СССР, потом 90-х, помню момент, когда в Москву навалили бренды и какая очередь была в макдональдс на Пушкинской. Помню как мама сказала, зачем они там стоят, ну еда и еда. И мне кажется это у меня от мамы, ну бренд и бренд.
И знаете я тут смотрела на фотографию одного европейского аэропорта и поймала, как раз себя на мысли, того, что мне неинтересно, когда везде, всё одинаково. Конечно понимаю, что в этом есть смысл. Но хочется самобытности, а не глобализации.
И вот смотрю я на фото, а там на втором этаже старбакс, внизу KFC, сбоку реклама, и я такая фу.
Вот потом вспомнила своё детское чувство, бренд???
Приходишь ты в универмаг, а там хлеб и хлеб, он из соседнего хлебзавода, по ГОСТу, молоко, сметана, яйца. Сметану набирают тебе в твою банку, яйца кладёшь в сеточку. Блин и никто не парился)) и не думали про эпидемию. И я так отчётливо помню, как тетинька продавщица набирала сметану в банку, для меня это было представление, у неё был огромный половник.
Да, потом уже дефецит, ад и очереди за товаром в 90-х. Ну и я тоже стояла в очереди, пока мама бегала по другим.

Но бренд? В том понимание, что сейчас был или нет?

И я люблю те города, где есть самобытность. Ты выходишь в центр города, а там товары этого города и страны, а не бренды, которые есть во всём мире. И вот тогда мой отдел мозга, отвечающий за интерес говорит даааа! Оно!

А когда всё по одному шаблону... Ну так себе... Да и вцелом я не особо падкая на бренды, хотя люблю всё очень добротное, функциональное, фундаментальное, чтобы надолго. Я готова платить за качество, и часто бренд должен быть равно качеству. Но по факту оно не так.

Папа мой в силу своего возраста до сих пор не понимает, почему молоко одного бренда дороже другого, а если это фермерские товары, то ему совсем непонятна цена. Ну молоко, и молоко. И папа так и продолжает брать самое дешёвое, а потом негодует почему качество плохое и кот не ест колбасу)))

#прямойэфир #анонс #системныйаналитик #Сербия #Люксофт

Давно у меня тут не было прямых эфиров)))

Пригласила в гости, моего хорошего друга, коллегу, знакомого, с кем работали и держим общение - Сергея Сушкова))

Сергей в прошлом году со своей семьёй переехал в Белград, Сербию. Прошёл практически год и вот мне стало интересно пообщаться на тему: "насколько работа системным аналитиком там, отличается от работы тут, с какими проблемами на работе приходится сталкиваться, да и вцелом, как оно?"

Сергей в России был Тим Лидом Аналитиков, сейчас Старший Системный Аналитик компании Люксофт.

Если у вас есть вопросы к Сергею, пишите в комментариях под постом 👇

Прямой эфир планируем провести 30 января в 19:00 по Москве, присоединяйтесь))) Запись будет.

#историиизжизни #мысливслух #проаналитика #моемнение #мойопыт #системныйаналитик #нерешаемыезадачи

Нерешаемые задачи

Мне кажется многие сталкивались с тем, что вот дают задачу, а полномочий нет, условия заведомо провальные, но это не сразу понятно или непонятно вообще.
И ты такой красивый ходишь, ходишь, крутишь в голове решение, и ничего не получается. В какой-то момент, аналитик приходит к выводу, что он явно чего-то не знает, находится в тупике и, например приходит ко мне на менторство. А я как #капитаночевидность говорю, задача нерешаемая, или просто уровень задачи не под уровень аналитика.

Не под уровень аналитика, это очень больно и может довести человека до нервного истощения, если он бьётся уже месяцами. Мы же все герои и умеем преодолевать, и нет нерешаемых задач, и ваще если мне дали задачу, я должен её сделать!

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

Вспомнила тут очень яркий момент, когда я обнаружила ошибку проектирования, все подтвердили, что да это ошибка, да она за собой тянет риск, того, что интеграция двух больших систем может накрыться медным тазом, но никто не будет её трогать!

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

То есть по факту ситуация - системы огромные, близки к запуску и сдачи в прод, имеют очень рискованное решение, которое может похерить всё, но никто даже не будет пробовать показывать руководству, что всё очень плохо.

Другая ситуация и очень часто встречающаяся у аналитика, это копание в "грязном белье". Когда разработка что-то сделали, для кого-то, это что-то нужно уже бы отдать в прод, но непонятно как? Вдруг сломается то, что работает? Нет тестов, тестировщик не понимает, как оно должно работать. Аналитик пришёл позже и не понимает как ему одновременно восстановить требования и ещё разобраться в том, что уже сделано, насколько оно правильно спроектированно и какое влияние оказывает на основные, критичные процессы.

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

Выкинуть - никому не нравится, все будут кричать, мы же работали!!! Алё! Ты че! Но часто дешевле сделать заново, чем копаться в том, что кем-то, для кого-то было сделано, исходя из того, что я так понял или из того, чтобы разработка не простаивала, пусть делает козе баян.

А второй вариант нравится всем, но долго оно и скорее всего его выберут, аналитик будет сидеть читать код, восстанавливать требования, идти с двух сторон и возможно придёт к чему-то. Долго и больно.

У нас был на проекте второй вариант, аналитику помогли графы в yed приложение, где можно было смаппить набор фич, что уже сделано и набор требований, что нужно. Большая работа, но была успешно проведена, мощным аналитиком) Ещё одно НО тут, микросервисная была архитектура, и добавление нового не должно было ломать, уже существующий функционал, по факту не всегда так получалось.

Но чаще всего такие задачи быстро не решаются, очень больные и трудоёмкие, а сроки конечно вчера. И ситуация совсем невеселая с огромной нагрузкой на аналитика.

Эх... Всё таки я разболелась...

Прямой эфир с Сергеем мы переносим на следующий понедельник 7 февраля.
Дополнительно ещё сообщу.

#прямойэфир #анонс #системныйаналитик #Сербия #Люксофт

Мне стало лучше, благодарю всех за поддержку!
Поэтому прямому эфиру сегодня быть!

Напоминаю, что общаемся сегодня с Сергеем Сушковым))

Сергей в прошлом году со своей семьёй переехал в Белград, Сербию. Прошёл практически год и вот мне стало интересно пообщаться на тему: "насколько работа системным аналитиком там, отличается от работы тут, с какими проблемами на работе приходится сталкиваться, да и вцелом, как оно?"

Сергей в России был Тим Лидом Аналитиков, сейчас Старший Системный Аналитик компании Люксофт.

Если у вас есть вопросы к Сергею, пишите в комментариях под постом 👇

Начало прямого эфира в 19:00 по Москве, сегодня.

Запись будет.

#системныйаналитик #прямойэфир #СергейСушков #Белград #каконотам #Люксофт

Запись вчерашнего прямого эфира с Сергеем Сушковым)))

Говорили о том, как оно там в Белграде после Москвы. Мне кажется словили "полако", размеренный ритм, спокойствие и домашнюю атмосферу 😂

Для себя я сделала вывод #капитаночевидность что Сербия мостик к Европе и что-то среднее между Россией и Германией. За супер пупер развитием это не в Сербию, но если нужен международный опыт и английский язык, то это хороший вариант.

#мысливслух #руководство #лидерство #командообразование #управление #рассуждения #отношения

Про лидерство, отношения с руководством

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

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

Что же такое лидерство? И на кой ляд оно вам?))) Для кого-то, #капитаночевидность это возможность потешить своё эго. А для кого-то, это смелость брать на себя ответственность за принятие решений и вести команду за собой. Красиво звучит)

Но есть но, в виде второго дна - это командообразование, и решение конфликтов. Если ты действительно руководитель, то ты лидер. А лидер это человек, которому я, как член команды, готов доверять. Я готов работать с лидером и выполнять задачи, которые мне даются. Если человек в ваших глазах не является лидером, да и ваще вы постоянно его троллите и обесцениваете, не стоит идти в его команду.

Я долго училась командообразованию. Долго меняла себя. Лидерство сидело внутри всегда. Даже когда не хочешь, всё равно это не скрыть. Приходишь в новую среду и вот через 5 минут, на тебе уже какие-то лидерские задачи, показать всем своим примером. И сидишь и думаешь, блиииин Наташа, ну что за фигня, ты просто пришла провести хорошо время, а тут такое...

При этом мне в руководстве командами помогал, и до сих пор помогает, опыт руководства походов, туров, выездов, как с друзьями, так и со знакомыми. Даже с друзьями сложнее. Ты драган и отношения другие, в другой плоскости. Лидер наравных со всеми, ему доверяют принимать решения. Оры, крики, это больше про лидерство самцов у обезьян, когда они деруться, отгрызают друг другу пальцы и вообще до крови решают, кто тут главный.

Можно ли подготовить себя к руководству командой, лидерству? Конечно можно. Иногда аналитики сеньорного уровня, как раз приходят с таким запросом.

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