Відео

Будем рады дискуссии о применимости

когда работаешь строго по ТЗ )))

Всё видео по сути про проблему качества данных и согласованности. Согласованность должна состоять из: 1. Данные поступили 2. Данные приняты конечными системами 1 обеспечивается ETL слоем сервиса держателя масте-данных 2 ETL слоем получателя. Тогда зоны ответственности каждого сервиса становятся прозрачными. Если за 1,2 начинает отвечать некая центральная MDM со своими правилами, то 1 и 2 теряют часть ответственности, что представляет проблему организационного характера. Про это и речь.

починили, все работает! Спасибо за внимательность ))

хороший вопрос, помогает с чем? 😉

​@@andrey_putinпомогает в практике развития. Например приходит js и говорит могу на следующий уровень и хочу 300. А внутренняя вилка нового уровня условно 260. Наверное уходит специалист?

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

Жаль, что нам не удалось донести концепт слабой связанности

Мне кажется и это у него не получилось.😂

спасибо, здоровы )

Да, тянул локалку к соседям по подъезду )

Скорее, что работает вместо ERP?

Да, доступа нет

доступ починили, пользуйтесь и ждем обратную связь!

Если буквально, DWH - это склад данных. Я не считаю, что DWH - (только) аналитический инструмент. То, что его часто (только) так используют, не оценивая побочные эффекты такого отношения - другая история. Если у вас все интеграции делаются через middleware, то во-первых это делает ваш контур слабо связанным, а если у вас данные выходов всех бизнес-процессов уже в DWH, то подключить к этому BI - задача на часы и дни, даже в очень крупных контурах.

@@andrey_putin мне кажется тут могут быть проблемы с точки зрения размытия зоны ответственности систем, пытаясь сделать универсальный инструмент. Например, dwh это больше про пакетный сбор, в то время, как классическая интеграция через брокеры/шины чаще про потоковый сбор, пытаясь использовать систему не по назначению, мы начинаем костылить усложняя ее и давая не свойственную нагрузку.

это просто фамилия )

да, популярная фамилия

Уточните, что именно требует пояснений?

Подходы MDM мне кажется фундаментально нарушающими принципы слабой связанности, но может быть вы что-то иное имели ввиду. first law first!

@@andrey-putin-ktteam Слабая связанность (что считается хорошим патреном) имет обратную сторону медали - плохую согласованность данных. По какому телефону звонить клиенту, если в системе программы лояльности он один, в системе продаж другой, в системе рекомендаций третий, и т.д.? Или когда слать клиенту промо-предложение ко дню рождения, если дата его ДР в разных системах разная? И это только одна бизнес-проблема, которую призвана решать МДМ. О других можетет почитать у тех же Берсона и Дубова. К тому же не все МДМ-патерны ухудшають связанность. При реестровом подходе МДМ не вмешиватеся в процессы и в данные других сервисов, а протсто хранит ссылки на "золотые записи". Типа: Хочешь узнать точную дату ДР - иди в сервис А, а точных адрес клиента хранится в сирвисе Б, а точные ФИО в сервисе С и т.д. (т.е. где хранятся "золотая запись" для каждого атрибута данной сущности).

у нас в офисе около 500 живых растений. В основном это амстелы, бенджамины и замиокулькасы.

Спасибо, какую еще тему считаете важным подсветить?

иногда фамилия - это просто фамилия

Ей Богу, видео интересные но вот вы ссылки ни как не научитесь вставлять правильно. Я бы хотел перейти, но ссылка не интерактивная. А пересмотреть ваш канал в поиске одного видео не интересно.

@@Alex89muller кликабельная ссылка на полное видео в самом шортс - в нижней части экрана. А кликабельные ссылки в комментариях ютуб запретил, да (

​@@andrey_putinСпасибо.

Пожалуйста )) А доступ открыли, пользуйтесь )

Артем, спасибо за обратную связь. Для нас это важно 😘

Постарался описать фокус - результат-ориентированная рескиллинг карта. Хард скиллов в этой карте нет совсем (а если иногда и находим, то удаляем). Какой смысл от хард скиллов если ты не доставляешь соответствующий результат?

Но ведь, например, джун сам по себе не принесет ценность бизнесу, тут больше зависит от постановки ему задачи, достаточно ли она понятно поставлена, и решаема для его уровня, все что требуется от джуна это писать качественный код и знать инструменты. Чем выше уровень, тем больше фокус сдвигается к софт скилам, но на нижних уровнях без хард никак. С другой стороны как tdd приносит результат? На сколько тестирование повышает качество продукта - вопрос дискуссионный и может оказаться сильно переоценненным, Макконнел по-моему по этому поводу даже приводил какие-то исследования. Ещё интересно как вы определяете этот уровень, что за тесты? Особенно при приеме на работу нового сотрудника...

значит его бизнес-ценность "я решаю простые декомпозированные задачи", у нас как-то так и написано в L1. Я пока не понял зачем хард-скиллы нужны, чтобы это определить. Однако, хард-скиллам в будущем действительно может иметь место, как например ответ "а что я должен выучить или прочесть или пройти, чтобы попасть в этот уровень". Т.е. к каждому такому уровню может прилагаться такой план обучения, но это уже другая задача. Задача рескиллинг-карты - определить где ты есть сейчас и какие результаты будут на следующем для тебя уровне. @@BASic_37

@@andrey-putin-ktteam Спасибо, понял. У меня почему-то в голове такой универсальный инструмент по которому можно и определить где сейчас сотрудник (аргументированно доказать) и что нужно для роста (прозрачность для сотрудника) и отсюда же можно и должностные составить... Но все равно верхние уровни кажутся высосанными из пальца.

девочкам простительно ))

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

Да, у меня диплом спецкурсов (профподготовки) бухгалтерского учета в России и отдельно в UNO GAAP.

@@andrey-putin-ktteam Понятно. А бухгалтером, реально, доводилось работать?

Принцип "синхронизация с контрактом" (общим контекстом), а не с сервисом. У всех сервисов уже есть какой-то API -- даже если это взаимодействие с файлами через FTP. "квадратик" (ETL вы имеете ввиду?) служит для преобразования из контекста приложения в контекст предприятия. Все нюансы потребления, вся сложность забора данных -- в этом ETL слое. Сервис же просто предоставляет свои данные (и это единственное что он должен делать). Тогда у вас может быть любой сервис, который не содержит логики отправки внутри, это может быть и облачный и какой угодно сервис. А входы и выходы видны всей организации в лаконичном виде. Это заставляет ответить на вопрос "а в чем ключевой смысл бизнес-процесса этого сервиса". А дальше этот клубок начинает распутываться. Принцип слабой связанности (он же кстати SOLID + DDD) выделен как ключевое например командой Кима Фосгрина и Хамбла в Accelerate (которая описывает методику DORA), есть в плейбуках Яндекса и далее, и мне очень жаль что мне не удалось донести суть этого принципа.

Поддержу. Тема не раскрыта. Теорию не стал рассказывать и ничего не понятно

Поддержу. Тема не раскрыта. Теорию не стал рассказывать и ничего не понятно

На связи ))

спасибо, о каких еще базовых вещах считаешь нужным больше делиться?

@@andrey_putin в последнее время я все больше начинаю думать в сторону того, почему особо нигде нет информации касательно роста управленца и проджект менеджера в компаниях и почему рост должен идти в стратегическом направлении . Однако сталкиваюсь с тем фактом, что в подавляющем количестве PM не работают так, как могли бы, останавливаясь только на таск-менеджменте и администрировании проекта, в то время как философия ПМ (как по мне) не просто вести проект, а так же быть частью бизнеса клиента на стороне своей команды. Андрей, это много лирики, но по сути хотелось бы увидеть какие шаги и действия необходимо предпринимать проектному менеджеру и управленцу, для роста в CTO/CPO/Тимлида Это немного личная боль и история, ибо все еще спрашивая знакомых и людей извне нет понимания в самом смысле PM Заранее спасибо!