Сегодня пятница, я хотела, что-то попроще написать, но поняла, что мой #инсайт, а для кого-то может быть #капитаночевидность или #капитаннеочевидность будет полезен.
А именно, что конфликт это нормальный, рабочий момент!
Это сложно бывает осознать, потому что конфликт может быть микро, и вспыхивать молниеносно. Реагировать в стрессе мы можем, но часто из разряда бей, беги или замри.
Мои конфликты происходят из-за того, что мы видим друг друга впервые и вместо знакомства, идут некие требования и ожидания, и конечно моя соответствующая реакция. И так, кстати, происходит у меня не только на работе, я понимаю и чувствую очень ярко, что где-то перешли границы, где-то "со мной так нельзя ", и реакция чаще всего бей. А в сети понятно, что какие-то вещи проще высказать, чем лично в лицо.
Но у меня это бей, переваривается со шлейфом. Физически меня может даже потрясти, голос уйдёт в напряжение, но самое плохое, что могу и заболеть, чего очень бы не хотелось.
А дальше триггер "со мной, что-то не так", и вот эта рефлексия, тут же синдром самозванца и желание быть идеальной, или хорошей.
✅ А могла ли я поступить по-другому? Нет!
✅ А могу ли я сейчас выйти из конфликта по-другому? Да!
✅ Могу ли я спустить на нет переживания? Конечно!
И как же?
Всё идёт с принятия, что это нормально. Да, мы повздорили, была такая реакция в моменте, чаще всего приходят извинения. И я понимаю, что это рабочий момент.
И конечно начинаешь проговаривать с коллегами, что да, было в моменте не очень, местами эмоционально, но это возникло не просто так, конфликт интересов в том числе но это рабочий процесс, волнения и вовлечения, выдохнули, прогулялись, отвлеклись, восстановились и вернулись к задаче.
Спасибо за крутые комментарии и информацию к предыдущему посту. 👆
Вспомнили такие вещи как FURPS и SQUARE, картинка как раз из ГОСТ (перевод как раз стандарта SQUARE).
Ситуация, которую я описала, тоже можно рассматривать как многослойную.
Потому что с одной стороны это требования к качеству, которые возникают в процессе использования, а с другой стороны это требования к качеству данных.
Что можно сделать?
✅1. Ввести шаблон Нфт, чек лист, но это не будет работать без внутреннего регламента.
✅2. Если требуется, то нужно обучить аналитиков.
✅3. Следить, чтобы новое всё шло с Нфт, если раньше не писали и не было в шаблонах.
✅4. Оценить и спланировать процесс реинженеринга требований. Это конечно больно и тяжело и на это нужно выделять отдельный ресурс.
✅5. И старое доброе, ротация в архив, или туда где дешевле, если например, год никто не просил, то удалили. Но тут нужно понять, что из этого бизнес критично, что фз, а что непонятно, а там где непонятно ждать криков. А чтобы были крики можно для начала просто переместить 😂
⚡️ Вышел отчет «Отечественные решения Data Lakehouse-круг Громова 2026»
Российский рынок Data Lakehouse перешёл от пилотных проектов к промышленным внедрениям. При этом рынок разделился на два архитектурных подхода, а информационная безопасность стала одним из главных критериев выбора платформы.
В исследование вошли 10 отечественных решений: MWS Data Lakehouse, Платформа Selena, Digital Q.DataFactory, CedrusData Platform, Data Ocean Nova, Tengri Data Platform, Arenadata Hyperwave, VK Data Platform, YTsaurus и Yandex Data Platform.
➡️ Отчёт даст ориентиры:
– чем отличаются интегрированные платформы от унифицированных систем,
– когда важнее гибкость и технологическая свобода, а когда – простота внедрения и сопровождения,
– какие компоненты и архитектурные подходы используют российские Data Lakehouse,
– на что обратить внимание при выборе платформы для корпоративного хранилища данных.
➡️ Особое внимание уделено:
– драйверам перехода на Data Lakehouse – почему технология становится востребованной и какие задачи заказчиков стимулируют её внедрение,
– информационной безопасности – RBAC, сквозному управлению доступом, аудиту и Data Lineage,
– S3-хранилищу, которое фактически становится фундаментом производительности Lakehouse,
– AI/ML и AI-агентам: полноценные агентные возможности на российском рынке пока остаются скорее исключением, чем стандартом.
📌 Исследование основано на сравнении технологических стеков, экспертной оценке решений и анализе практических сценариев их применения. Полный отчёт доступен на сайте центра «Круги Громова» – скачать бесплатно!
Получите актуальную картину российского рынка Data Lakehouse на 2026 год.
Круги Громова | Подписаться и стать частью Data-сообщества ⬅️
💡"Волшебные" требования Нфт, что может пойти не так? И почему....
Сегодня расскажу прекрасную историю "из полей", то что кажется никогда не произойдёт, но потом случается "вдруг".
Вот в уездом городе N.... А точнее в компании N, есть своя история и эта история в том числе отражается в ИТ-ландшафте, это прям как эпохи строительства отражаются в Москве.
И вот в начале 2000-х, память была дорогой, и сразу же возникали требования, что, где и как мы будем хранить, чистить, или вообще записывать на диск. Да, я помню такие требования, что мы согласно ФЗ, храним платёжные транзакции и их пишем на диск, а есть вдруг пожар, то тогда сорян.
И вот где-то с годов 2010 память стала дешевле и все начали хранить больше, разработчики уже не особо и просили требования о ротации логов, и хранилища стали большими.
А где-то с 2015 все резко решили собирать всю информацию о клиенте. Прям помню эти прекрасные постановки, когда бизнес-заказчик говорит "храните всё, потом разберёмся", потом конечно можно не наступить.
И вот 2026 год, и виток работы с подобными требованиями из разряда Нфт сделал поворот истории и замкнулся на том, что
храним слишком много, часть памяти стала для нас дорогой, и надо бы понять, что можно удалить.
И тут возникает момент "как не выплеснуть с водой ребёнка".
✅Что должны хранить по ФЗ, несколько лет?
✅Что сфоткали, потому что это внутренние регламенты и вообще контроль работы сотрудников. И уже не актуально, и можно удалить.
✅А что-то можно проанализировать, сделать выводы, а может даже сжать.
Ответов нет, есть много информации, без структуры, и самое ужасное без привязки к ключевым бизнес-объектам автоматизации.
Где же потерялись?
Да, где-то на требованиях Нфт. Потому что тренд 2020-х, забить на Нфт.
Даже, к сожалению, слышала от аналитиков такое мнение, что это "не наша часть ответственности", #смертельные_грехи_аналитика и это тоже можно понять, особенно в больших компаниях, где всё в контуре проработано, и просто Нфт пишутся копипастом, а аналитик не хочет тут быть техническим писателем и просто собирать со всех некую информацию...
А получаем проблему, которую быстро не решить, а бизнес ежедневно тратить средства на хранение ненужного #капитаночевидность
А вы пишите #Нфт❓
Есть с такими требованиями проблемы❓
Казалось бы, сколько раз уже обсудили, что такое требование, какие они бывают и почему важно начинать с требований, а не с решений.
Но я не перестаю удивляться как круг повторяется.
Из любимого:
1.У нас нет системного анализа и он нам не нужен.
2.Нфт фигня и зачем их писать, пустое.
3.Главное в бизнес-анализе процессы.
4.Микросервисы нас спасут (а теперь ещё ИИ спасёт).
5.Предметная область, что это такое? Всем же итак понятно.
Можете дополнить, то с чем вы столкнулись на этой неделе? 🔽
Поймала себя на мысли, что в живой команде, всё не очень, а где-то точно круто и хорошо.
Если у тебя что-то не так, где-то же есть идеал?)
И когда обсуждаешь проблемы команды, компании, кажется, что где-то есть идеал. И мысль идёт дальше, вот бы его найти. Но вспоминая крутые доклады на конференциях того же озона, где все работали на тайм ту маркет, и зрелые процессы, и я сразу понимаю, что мне скучно будет)))
И вот такой когнитивный диссонанс, хочется думать, что где-то есть недостижымый идеал, в котором не хочется работать 😂
Ключевой момент состоит в том, чтобы понять мы делаем "проект или продукт".
Разницу между продуктом и проектом я описывала в статье, которая до сих пор актуальна.
Очень редко я слышу от руководства, что нам ещё нужно набрать экспертизу, у нас мало проектов было на этом теме. И вот когда уже был большой обзор болей заказчика и мы вырастили внутри себя экспертизу, тогда можно говорить - мы делаем продукт.
Да, есть тиражирование, есть своё место на рынке, и сбор сразу нескольких болей заказчика, а в какой-то момент уже экспертиза выше, чем у самого заказчика.
Мне понравилась аналогия, что
стоматолог не может научиться на себе лечить зубы.
Почему я топлю всегда за изменения, настройки под заказчика, потому что хардкод быстро себя изживает, да он может быть хорош, на определённом этапе, и показывать нужные метрики. Но бизнес и ситуация во внешнем мире изменяется быстрее, чем код. Тем более no-code, low-code, и да простят меня разработки ещё и вайбкодинг.
Но так как я любитель всего добротного, качественного и на века) То я за то, чтобы ядро системы было мощным и пусть оно не изменяется, если работает. Что мы часто видим в больших компаниях с историей, что есть сердце айти-ландшафта, которое лучше не трогать, оно работает.
И мы получаем гибридное решение. Там где можно сделать гибкость и быстрое изменение, то это нужно делать (чаще всего фронты), а там где нужны мощности, защищенность и отказоустойчивость, там хоть монолит сделать можно. Не так уж он плох.
И вот, вроде бы я говорила, про продукт и проект, но фактически спустилась на рассуждения архитектуры, потому что стратегия в бизнесе напрямую отражается на стратегию айти-ландшафта.