Привет!
Я - Катя Лысенко. Это мой личный канал, в котором я буду делиться:
- мыслями и вопросами, которые меня волнуют и беспокоят;
- лайфхаками и открытиями, которые мне помогают в работе и жизни;
- успехами и неудачами, вдруг они смогут ваш путь сделать проще;
- просто чем-то инетересным...
15+ лет в IT в отраслях: fintech, e-grocery, TIS. Спикер многих конференций. Запускала: ЯндексЗаправки; ЯндексПарковки; Закрытые парковки г. Москвы; KYС и единый кошелек ЦУПИС. Ментор.
Самое важное, что вам стоит знать обо мне:
1. Пропагандирую Domain Driven Design
Обращаю бизнес и разработку в приверженцев построения архитектуры, как проекции бизнеса на код.
2. Дружу бизнес и разработку
Меняю процессы и архитектуру выстраивая коллаборацию между бизнесом и разработкой. Проектирование - проекция бизнес-процессов на кодовую базу.
3. Привношу в разработку ценности и культуру
Учу собирать команды и развивать продукты опираясь на ценности и культуру, заложенные в бизнес и технической стратегиях.
4. Помогаю компаниям пройти кризис роста разработки
Выстраиваю процессы для постстартапных IT команд без лишней бюрократии и с учетом необходимых темпов найма и онбординга.
Я - Катя Лысенко. Это мой личный канал, в котором я буду делиться:
- мыслями и вопросами, которые меня волнуют и беспокоят;
- лайфхаками и открытиями, которые мне помогают в работе и жизни;
- успехами и неудачами, вдруг они смогут ваш путь сделать проще;
- просто чем-то инетересным...
15+ лет в IT в отраслях: fintech, e-grocery, TIS. Спикер многих конференций. Запускала: ЯндексЗаправки; ЯндексПарковки; Закрытые парковки г. Москвы; KYС и единый кошелек ЦУПИС. Ментор.
Самое важное, что вам стоит знать обо мне:
1. Пропагандирую Domain Driven Design
Обращаю бизнес и разработку в приверженцев построения архитектуры, как проекции бизнеса на код.
2. Дружу бизнес и разработку
Меняю процессы и архитектуру выстраивая коллаборацию между бизнесом и разработкой. Проектирование - проекция бизнес-процессов на кодовую базу.
3. Привношу в разработку ценности и культуру
Учу собирать команды и развивать продукты опираясь на ценности и культуру, заложенные в бизнес и технической стратегиях.
4. Помогаю компаниям пройти кризис роста разработки
Выстраиваю процессы для постстартапных IT команд без лишней бюрократии и с учетом необходимых темпов найма и онбординга.
❤5👍2🔥1
Про базовые ценности
Никто не принёс столько вреда agile как agile-коучи, по-сути они «украли» все хорошее из agile и сделали из гибкой методологии самую закостеневшую.
4 ценности agile:
1 Люди и взаимодействие важнее процессов и инструментов.
2 Работающий продукт важнее исчерпывающей документации.
3 Сотрудничество с заказчиком важнее согласования условий контракта.
4 Готовность к изменениям важнее следования первоначальному плану.
И то что создавалось, как манифест разработчиков для коммуникации и коллаборации в мире, который шел в продуктовую разработку, в какой-то момент стало «продаваться» под соусами: «agile принципы в отделе продаж», «строим дом по agile”, “медицинская диагностика и гибкие методологии». Ничего нет плохого в заимствование, в том, когда ты не изобретаешь колесо. Но страшное случилось в том, что agile “переопылился». И на рынок хлынул поток книг/брошюр/курсов о том, как именно проводит встречи; как декомпозировать; как планировать. И это КАК стало описано до каждой запятой.
Если в компании есть agile-коучи, то не так много желающих в разработке, «рискнуть» в конце ретро написать цели не по SMART. Причина: тебя вызовут «на ковер» публичный или прикрытый «подорожником» 1:1 и отругают. И, к сожалению, я не утрирую. Это горькая реальность далеко не маленьких и ничего не значащих на рынке компаний, как раз зачастую это уже бич флагманов индустрии.
При этом мы потеряли цели и ценности, которые были заложены в манифест, забыли кем этот манифест был придуман и для кого!
Любой призыв всегда провозглашался в рамках конкретного социокультурного состояния! Жизнь, компания, но главное ЛЮДИ, это не константы, это изменяющиеся/ращвивающиеся сущности! И принцип гибкости как раз про то, что «Изменение требований приветствуется, даже на поздних стадиях разработки.» Это нормально меняться и пробовать делать что-то не по-методичке! Это не про скатывание в нигилизм, это про важность помнить, что история знает массу случаев, когда из ошибок и неверных решений создавалось новое и прекрасное, несущее новые смыслы и ценности.
Мне нравится, что сейчас, вместе с одной из команд, мы совместно пересматриваем практики, знакомые и прожитые всеми по несколько раз, но пересматривая их, мы строим гипотезы и проверяем что хорошо, а что плохо зайдет у нас. И нет цели изобрести СберДжайл (тут именно как пример нейминга и трансформации методолгии "под себя") или именной аналог. Цель, получить максимум из применяемых практик и сделать процесс поставки в соответствии с ценностями DevOps философии: рост темпов поставки продукта при сохранении или росте качества путём оптимизации процессов (в том числе за счет автоматизации).
Вполне возможно, настало время пересмотреть текс на «скрижалях» и задуматься, а точно ли он все еще подходит в неизменной форме нам. А те же мы? И должны ли мы нести "дословность" исполнения или следовать ценностям и смыслам?..
Ведь люди и взаимодействие - важнее!
#project_management #people_management
Никто не принёс столько вреда agile как agile-коучи, по-сути они «украли» все хорошее из agile и сделали из гибкой методологии самую закостеневшую.
4 ценности agile:
1 Люди и взаимодействие важнее процессов и инструментов.
2 Работающий продукт важнее исчерпывающей документации.
3 Сотрудничество с заказчиком важнее согласования условий контракта.
4 Готовность к изменениям важнее следования первоначальному плану.
И то что создавалось, как манифест разработчиков для коммуникации и коллаборации в мире, который шел в продуктовую разработку, в какой-то момент стало «продаваться» под соусами: «agile принципы в отделе продаж», «строим дом по agile”, “медицинская диагностика и гибкие методологии». Ничего нет плохого в заимствование, в том, когда ты не изобретаешь колесо. Но страшное случилось в том, что agile “переопылился». И на рынок хлынул поток книг/брошюр/курсов о том, как именно проводит встречи; как декомпозировать; как планировать. И это КАК стало описано до каждой запятой.
Если в компании есть agile-коучи, то не так много желающих в разработке, «рискнуть» в конце ретро написать цели не по SMART. Причина: тебя вызовут «на ковер» публичный или прикрытый «подорожником» 1:1 и отругают. И, к сожалению, я не утрирую. Это горькая реальность далеко не маленьких и ничего не значащих на рынке компаний, как раз зачастую это уже бич флагманов индустрии.
При этом мы потеряли цели и ценности, которые были заложены в манифест, забыли кем этот манифест был придуман и для кого!
Любой призыв всегда провозглашался в рамках конкретного социокультурного состояния! Жизнь, компания, но главное ЛЮДИ, это не константы, это изменяющиеся/ращвивающиеся сущности! И принцип гибкости как раз про то, что «Изменение требований приветствуется, даже на поздних стадиях разработки.» Это нормально меняться и пробовать делать что-то не по-методичке! Это не про скатывание в нигилизм, это про важность помнить, что история знает массу случаев, когда из ошибок и неверных решений создавалось новое и прекрасное, несущее новые смыслы и ценности.
Мне нравится, что сейчас, вместе с одной из команд, мы совместно пересматриваем практики, знакомые и прожитые всеми по несколько раз, но пересматривая их, мы строим гипотезы и проверяем что хорошо, а что плохо зайдет у нас. И нет цели изобрести СберДжайл (тут именно как пример нейминга и трансформации методолгии "под себя") или именной аналог. Цель, получить максимум из применяемых практик и сделать процесс поставки в соответствии с ценностями DevOps философии: рост темпов поставки продукта при сохранении или росте качества путём оптимизации процессов (в том числе за счет автоматизации).
Вполне возможно, настало время пересмотреть текс на «скрижалях» и задуматься, а точно ли он все еще подходит в неизменной форме нам. А те же мы? И должны ли мы нести "дословность" исполнения или следовать ценностям и смыслам?..
Ведь люди и взаимодействие - важнее!
#project_management #people_management
❤2🔥1
Коллаборация и ценности
Коллаборация в IT играет важную роль на всех этапах разработки. Эта философия сотрудничества, охватывающая парное программирование, архитектурные комитеты, DevOps практики и многие другое. Она строится на общих ценностях и едином языке.
Понимание ценностей - ключевой аспект сотрудничества. Например, обсудим популярное "парное программирование" - практику, при которой два программиста работают вместе на одном участке кода. Использование этого подхода требует глубокого взаимопонимания, а также общих ценностей, связанных с качеством кода и процессом разработки. Если один разработчик стремится к сокращению строк кода, а другой - к максимальной ясности, конфликты неизбежны. В этом случае общие ценности и язык помогают гармоничной работе.
Но не только подход к написанию кода должен быть общим. Конечно же единый язык должен быть и на этапе постановки задачи и выбора решения! И в этой работе важно избегать филологических парадоксов. Чаще всего недопонимание быстро выявиться. Но на сколько быстро будут выбраны корректные термины дающие однозначность понимания транслируемой информации, соответственно; на столько быстро уйдет недопонимание терминов и их нечетких определений, затрудняющих сотрудничество.
Правильное формулирование терминов и их понимание приводит к коллаборации, взаимообогащабщему процессу. Например, если все участники проекта имеют четкое представление о том, что такое "нагрузка" и "нагрузочное тестирование", они могут работать в едином ритме, избегая недопониманий и ошибок. Может быть вам пример показался странным, но, к сожалению, даже в столь кажущимися очевидными терминах скрывается недопонимание!
Коллаборация в IT всегда строится на общих ценностях и языке, обеспечивая успешное сотрудничество. Эффективное понимание играет важную роль в этом процессе, позволяя избегать филологических парадоксов и допуская разработку высококачественных продуктов. Но, да, к сожалению, не гарантируя качество :)
#people_management #project_management
Коллаборация в IT играет важную роль на всех этапах разработки. Эта философия сотрудничества, охватывающая парное программирование, архитектурные комитеты, DevOps практики и многие другое. Она строится на общих ценностях и едином языке.
Понимание ценностей - ключевой аспект сотрудничества. Например, обсудим популярное "парное программирование" - практику, при которой два программиста работают вместе на одном участке кода. Использование этого подхода требует глубокого взаимопонимания, а также общих ценностей, связанных с качеством кода и процессом разработки. Если один разработчик стремится к сокращению строк кода, а другой - к максимальной ясности, конфликты неизбежны. В этом случае общие ценности и язык помогают гармоничной работе.
Но не только подход к написанию кода должен быть общим. Конечно же единый язык должен быть и на этапе постановки задачи и выбора решения! И в этой работе важно избегать филологических парадоксов. Чаще всего недопонимание быстро выявиться. Но на сколько быстро будут выбраны корректные термины дающие однозначность понимания транслируемой информации, соответственно; на столько быстро уйдет недопонимание терминов и их нечетких определений, затрудняющих сотрудничество.
Правильное формулирование терминов и их понимание приводит к коллаборации, взаимообогащабщему процессу. Например, если все участники проекта имеют четкое представление о том, что такое "нагрузка" и "нагрузочное тестирование", они могут работать в едином ритме, избегая недопониманий и ошибок. Может быть вам пример показался странным, но, к сожалению, даже в столь кажущимися очевидными терминах скрывается недопонимание!
Коллаборация в IT всегда строится на общих ценностях и языке, обеспечивая успешное сотрудничество. Эффективное понимание играет важную роль в этом процессе, позволяя избегать филологических парадоксов и допуская разработку высококачественных продуктов. Но, да, к сожалению, не гарантируя качество :)
#people_management #project_management
👍1
Проектирование VS Документирование
Проектирование в сфере информационных технологий - это не просто создание бумажной документации, а скорее искусство предвидения и разработки решений, которые будут устойчивы на всех уровнях бизнеса. По сути, проектирование подразумевает способность видеть ситуацию в целом и понимать, как каждая деталь взаимодействует в контексте всей системы.
Важно понимать, что проектирование не ограничивается созданием кучи бумаги с техническими спецификациями. Прежде всего это процесс размышления и поиска наилучших решений для сложных задач. На практике это означает, что документы могут быть полезными, но они не являются самой целью. Вместо этого, они служат инструментом для обеспечения понимания и утверждения планов, которые будут успешно работать в реальной среде.
Одним из ключевых элементов в проектировании является способность видеть "всё." Метрики играют роль глаз проектировщика на всех уровнях бизнеса. Например, представьте, что ваша компания интегрируется с разными контрагентами для проверки пользовательских документов. Один из контрагентов запускает неудачный релиз и начинает направлять к вам большое количество неправильных запросов. В результате, вы сталкиваетесь с непредвиденными проблемами, в том числе с очередью пакетов, которая стремится вас «уронить».
Вместо паники и бегства «по кругу», вы обращаетесь к метрикам! Они позволят вам понять, что происходит, как система ведет себя в этой ситуации и какие меры нужно предпринять, то есть метрики дают возможность принимать обоснованные решения.
Однако, проектирование не ограничивается только анализом текущего состояния и доработок под существующие нужды. Оно предусматривает создание устойчивых решений для будущего. Ведь в IT индустрии изменения - это норма. Системы постоянно эволюционируют, и необходимо предвидеть, как будут взаимодействовать новые компоненты, какие могут возникнуть вызовы и как наилучшим образом адаптироваться к ним.
Чтобы не утонуть в море бумаг и формальных документов, вы и ваша архитектура должны быть гибкими и адаптивными. Таким образом, проектирование становится искусством прогнозирования, где главной целью является создание устойчивых решений, способных адаптироваться к изменениям на всех уровнях бизнеса.
"Если вы думаете, что создание большой стопки бумаги решает все проблемы, вы, вероятно, работаете на целюлозной фабрике, а не в IT." Проектирование — это процесс мышления и разработки, который требует умения видеть всю картину и принимать обоснованные решения на основе данных и анализа, а не просто создавать бумажные артефакты. А вот про то, какие уровни и «слои» имеются у картины мы поговорим в следующий раз.
#project_management #architecture
Проектирование в сфере информационных технологий - это не просто создание бумажной документации, а скорее искусство предвидения и разработки решений, которые будут устойчивы на всех уровнях бизнеса. По сути, проектирование подразумевает способность видеть ситуацию в целом и понимать, как каждая деталь взаимодействует в контексте всей системы.
Важно понимать, что проектирование не ограничивается созданием кучи бумаги с техническими спецификациями. Прежде всего это процесс размышления и поиска наилучших решений для сложных задач. На практике это означает, что документы могут быть полезными, но они не являются самой целью. Вместо этого, они служат инструментом для обеспечения понимания и утверждения планов, которые будут успешно работать в реальной среде.
Одним из ключевых элементов в проектировании является способность видеть "всё." Метрики играют роль глаз проектировщика на всех уровнях бизнеса. Например, представьте, что ваша компания интегрируется с разными контрагентами для проверки пользовательских документов. Один из контрагентов запускает неудачный релиз и начинает направлять к вам большое количество неправильных запросов. В результате, вы сталкиваетесь с непредвиденными проблемами, в том числе с очередью пакетов, которая стремится вас «уронить».
Вместо паники и бегства «по кругу», вы обращаетесь к метрикам! Они позволят вам понять, что происходит, как система ведет себя в этой ситуации и какие меры нужно предпринять, то есть метрики дают возможность принимать обоснованные решения.
Однако, проектирование не ограничивается только анализом текущего состояния и доработок под существующие нужды. Оно предусматривает создание устойчивых решений для будущего. Ведь в IT индустрии изменения - это норма. Системы постоянно эволюционируют, и необходимо предвидеть, как будут взаимодействовать новые компоненты, какие могут возникнуть вызовы и как наилучшим образом адаптироваться к ним.
Чтобы не утонуть в море бумаг и формальных документов, вы и ваша архитектура должны быть гибкими и адаптивными. Таким образом, проектирование становится искусством прогнозирования, где главной целью является создание устойчивых решений, способных адаптироваться к изменениям на всех уровнях бизнеса.
"Если вы думаете, что создание большой стопки бумаги решает все проблемы, вы, вероятно, работаете на целюлозной фабрике, а не в IT." Проектирование — это процесс мышления и разработки, который требует умения видеть всю картину и принимать обоснованные решения на основе данных и анализа, а не просто создавать бумажные артефакты. А вот про то, какие уровни и «слои» имеются у картины мы поговорим в следующий раз.
#project_management #architecture
🔥1
Я в нано-отпуске в осенне-прекрасной солнечной Грузии!
А пост внезапно про ПТСР!
Посттравматическое стрессовое расстройство (ПТСР) характеризуется повторяющимися навязчивыми воспоминаниями о шокирующем травматическом событии, которые начинаются в период до 6 месяцев после события и сохраняются в течение > 1 месяца.
Считается что ПТСР это про катастрофы, войны, но иногда бывает и ПТСР после работы, работодателя. Конечно, можно применять к таким людям, как подорожник, призыв ставший названием книги: «Не работай с мудаками»! Но, это, как применять к жертвам насилия фразы: «Вы могли не провоцировать!»…
Достаточно сложно выходить из таких отношений, но это еще пол беды! Выйдя из них в тебе селится страх. Ты боишься, что будут ругать, наказывать, чего-то лишать… (у каждого свой список).
Я не предложу выхода из абьюза с работодателем, и не расскажу, как справиться с ПТСР. Я только могу обнять и поддержать. Поделиться тем, что мой путь занял около года, у одной подруги-3 года. И это - нормально! В смысле - нет, но, нормально переживать и просить помощь в такой ситуации, искать поддержку!
А теперь собственно к чему я: самое ценное что можно сделать для себя в такой ситуации - сделать вывод! И больше не вводить себя в это состояние! Поэтому, для себя, я вывела правило: хоть на чуть-чуть, но если устал-иди в отпуск. Если выгораешь и все надоедает- иди в отпуск! Я не очень умею в work&life balance, меня затягивает работой, я могу фанатично над чем-то просидеть все выходные. И да, я люблю то, что приносит мне денюжку на хлеб! Поэтому, пусть 2 дня, но я провела в прекрасной компании, узнавая что-то новое и классное, наслаждаясь абсолютно несвязанными с профессиональной жизнью вещами: виноделием, краеведением, историей моды! Думаю, что признаками отступающего ПТСР как раз и является возможность: вдохнуть/выдохнуть и дать себе отчёт, что пора в отпуск!
А на фото люди, которые сделали эту поездку волшебной:
- Тим Ильясов - стилист и историк моды
- Георгий - коллекционер, краевед, один из команды гидов Фаига
- Лиза - винодел, специалист по грузинским винам, женщина за 2 года создавшая винодельню
Ну и наша девчачья тусовка, которая на 2 дня умчалась в грузинскую осень 🍂!
А что вы думаете про: пострабочий ПТСР? Какие у вас способы разгрузки?
#mylife
А пост внезапно про ПТСР!
Посттравматическое стрессовое расстройство (ПТСР) характеризуется повторяющимися навязчивыми воспоминаниями о шокирующем травматическом событии, которые начинаются в период до 6 месяцев после события и сохраняются в течение > 1 месяца.
Считается что ПТСР это про катастрофы, войны, но иногда бывает и ПТСР после работы, работодателя. Конечно, можно применять к таким людям, как подорожник, призыв ставший названием книги: «Не работай с мудаками»! Но, это, как применять к жертвам насилия фразы: «Вы могли не провоцировать!»…
Достаточно сложно выходить из таких отношений, но это еще пол беды! Выйдя из них в тебе селится страх. Ты боишься, что будут ругать, наказывать, чего-то лишать… (у каждого свой список).
Я не предложу выхода из абьюза с работодателем, и не расскажу, как справиться с ПТСР. Я только могу обнять и поддержать. Поделиться тем, что мой путь занял около года, у одной подруги-3 года. И это - нормально! В смысле - нет, но, нормально переживать и просить помощь в такой ситуации, искать поддержку!
А теперь собственно к чему я: самое ценное что можно сделать для себя в такой ситуации - сделать вывод! И больше не вводить себя в это состояние! Поэтому, для себя, я вывела правило: хоть на чуть-чуть, но если устал-иди в отпуск. Если выгораешь и все надоедает- иди в отпуск! Я не очень умею в work&life balance, меня затягивает работой, я могу фанатично над чем-то просидеть все выходные. И да, я люблю то, что приносит мне денюжку на хлеб! Поэтому, пусть 2 дня, но я провела в прекрасной компании, узнавая что-то новое и классное, наслаждаясь абсолютно несвязанными с профессиональной жизнью вещами: виноделием, краеведением, историей моды! Думаю, что признаками отступающего ПТСР как раз и является возможность: вдохнуть/выдохнуть и дать себе отчёт, что пора в отпуск!
А на фото люди, которые сделали эту поездку волшебной:
- Тим Ильясов - стилист и историк моды
- Георгий - коллекционер, краевед, один из команды гидов Фаига
- Лиза - винодел, специалист по грузинским винам, женщина за 2 года создавшая винодельню
Ну и наша девчачья тусовка, которая на 2 дня умчалась в грузинскую осень 🍂!
А что вы думаете про: пострабочий ПТСР? Какие у вас способы разгрузки?
#mylife
❤1
Я сегодня опечалена 😕
Снялась с ArchDays так как воспалился зуб 🦷 и я утопала на больняк, так как долго лечить и жуткая боль. Вот ссылка на доклад, который должен был быть: https://archdays.ru/speakers/
😩 Из плохого: болит сильно!
🙂 Из хорошего: доклад превратится в митап!
🤣 Из смешного: у нас с @miknatr точно семейный подряд, так как оба с конфы перенеслись на митапы.
Вот ссылка на Мишин митап про доменные саги: https://www.youtube.com/watch?v=tLw8lJ-Eijk
Мне импонирует отношение к саге, как к доменной сущности. ИМХО, при таком подходе, многие проблемы проектирования уходят и жизнь становится как-то проще и понятнее (в том числе и в части объяснений, выстраивания диалога с бизнесом).
А моралей сегодня 2:
Мораль 1: если болит зуб совсем чуть-чуть что даже не беспокоит - идите к врачу, иначе у вас все шансы все равно пойти к врачу но с куда большими проблемами (особенно при высоком болевом)
Мораль 2: если ты расстраиваешься, что что-то идет вообще не так как планировалось-погоди унывать, мб просто все изначально запланировано было не самым удобным образом, а станет только лучше (эт я про митап).
А если хотите похоливарить на тему доклада или накинуть идей-го в комменты!
ПыСы ссылка на прошлогодний с ArchDays: https://youtu.be/iZx4HCqEV-o?si=40WKv7Ekx2yxDQ5a
Снялась с ArchDays так как воспалился зуб 🦷 и я утопала на больняк, так как долго лечить и жуткая боль. Вот ссылка на доклад, который должен был быть: https://archdays.ru/speakers/
😩 Из плохого: болит сильно!
🙂 Из хорошего: доклад превратится в митап!
🤣 Из смешного: у нас с @miknatr точно семейный подряд, так как оба с конфы перенеслись на митапы.
Вот ссылка на Мишин митап про доменные саги: https://www.youtube.com/watch?v=tLw8lJ-Eijk
Мне импонирует отношение к саге, как к доменной сущности. ИМХО, при таком подходе, многие проблемы проектирования уходят и жизнь становится как-то проще и понятнее (в том числе и в части объяснений, выстраивания диалога с бизнесом).
А моралей сегодня 2:
Мораль 1: если болит зуб совсем чуть-чуть что даже не беспокоит - идите к врачу, иначе у вас все шансы все равно пойти к врачу но с куда большими проблемами (особенно при высоком болевом)
Мораль 2: если ты расстраиваешься, что что-то идет вообще не так как планировалось-погоди унывать, мб просто все изначально запланировано было не самым удобным образом, а станет только лучше (эт я про митап).
А если хотите похоливарить на тему доклада или накинуть идей-го в комменты!
ПыСы ссылка на прошлогодний с ArchDays: https://youtu.be/iZx4HCqEV-o?si=40WKv7Ekx2yxDQ5a
👍4😢2❤1
Делюсь видео своего прошлогоднего доклада с TechLead
А еще у меня есть скидка -30% для одного человека!
Если вы хотите - получить скидку - пишите в комменты, если будет несколько желающих - выберу рандомом.
А вот ссылка на само мероприятие: https://techleadconf.ru/2023
А еще у меня есть скидка -30% для одного человека!
Если вы хотите - получить скидку - пишите в комменты, если будет несколько желающих - выберу рандомом.
А вот ссылка на само мероприятие: https://techleadconf.ru/2023
🔥1
Forwarded from TechLead Conf Channel
Media is too big
VIEW IN TELEGRAM
Часто Domain-Driven Design мы рассматриваем сугубо с технической стороны. Но DDD воплощают люди. Екатерина Лысенко рассказала, как ценности и культура в компании влияют на работу практик и архитектуру.
#ТопДокладовTechLeadConf2022
#ТопДокладовTechLeadConf2022
🔥4
Всем привет!
Сегодня я к вам с просьбой пройти небольшой опрос: https://forms.gle/yd5MYmefrf4KNp2d8
Буду очень признательна за помощь. И да, да, опрос посвящен продукту, который сейчас разрабатываю!
СПАСИБО за время!!!
Сегодня я к вам с просьбой пройти небольшой опрос: https://forms.gle/yd5MYmefrf4KNp2d8
Буду очень признательна за помощь. И да, да, опрос посвящен продукту, который сейчас разрабатываю!
СПАСИБО за время!!!
Google Docs
Проблемкометр :)
Все мы сталкиваемся с проблемами и трудностями на работе и в жизни. Для моего собственного продукта я хотела бы узнать, как именно ты формулируешь проблемы и трудности, с которыми сталкиваешься ты сам и на твой взгляд компания в которой ты работаешь. Ничего…
🔥3
Сегодня хочу поделиться с вами небольшой своей статьей на LinkedIn о том, кого бы мне хотелось находить при поисках аналитика
Буду признательна, если поделитесь мыслями на эту тему!
Особенно если вы считаете себя аналитиком или выходцем из анализа 🙂
#project_management
Буду признательна, если поделитесь мыслями на эту тему!
Особенно если вы считаете себя аналитиком или выходцем из анализа 🙂
#project_management
Linkedin
Аналитики: возвращение к Корням в cпиральном развитии профессии
Сейчас, на многих конференциях, заявлены холиварные доклады о месте аналитика в IT-команде. Нужен/нет? Человек это или роль? И я решила тоже немножечко порассуждать, вдобавок, что я считаю себя выходцем из аналитиков и до сих пор беру часть задач анализа.
🔥2👍1
Начнем недельку анонсом на TechLead
Я там с МК буду. Приходить повакобулярить!
Я там с МК буду. Приходить повакобулярить!
🔥3🐳2
Forwarded from TechLead Conf Channel
На мастер-классе от Екатерины Лысенко вы узнаете, как словарь может стать вашим гидом в DDD. Погрузитесь в мир определений и их влияния на архитектуру. Поупражняетесь в формулировке и узнаете секреты внедрения этого подхода.
⠀
DDD — это стильно, модно, уже не очень «молодежно», но до сих пор нечасто применимо! Словарь — это понятно, неинтересно, «покрыто пылью», но привычно и является стандартом на начальных этапах проектирования.
⠀
Екатерина хочет предложить вам найти связь между словарем и DDD. На примерах понять, как словарь может стать отправной точкой DDD и как, описывая бизнес-контекст, оказывать влияние на архитектуру и выстраивать разумную коллаборацию, основанную на симбиотических связях между бизнесом и разработкой.
⠀
Что по итогу:
⠀
1) Основы DDD — общая теория. Язык и словарь — как основа DDD и выстраивания разумной коллаборации между бизнесом и разработкой.
⠀
2) Екатерина поделится методикой эволюционного, а не революционного внедрения DDD вместе с новыми проектами в компании (методика апробирована и дает хорошие результаты).
⠀
3) Разберем правила формулирования определений и поймем, как через определения строить архитектуру.
⠀
4) Тренировочная часть формулирования определений и их влияния на архитектуру.
⠀
5) Екатерина поможет найти свой стиль «словоплетства» и даст обратную связь.
⠀
6) Разберем процесс внедрения такого подхода в компании, работу с возражениями.
⠀
Встречаемся на TechLead Conf 2023, которая пройдет в рамках TeamLead++ Conf 2023 🖐
⠀
✅ Программа конференции и билеты на сайте в описании канала @TechLeadConfChannel
⠀
DDD — это стильно, модно, уже не очень «молодежно», но до сих пор нечасто применимо! Словарь — это понятно, неинтересно, «покрыто пылью», но привычно и является стандартом на начальных этапах проектирования.
⠀
Екатерина хочет предложить вам найти связь между словарем и DDD. На примерах понять, как словарь может стать отправной точкой DDD и как, описывая бизнес-контекст, оказывать влияние на архитектуру и выстраивать разумную коллаборацию, основанную на симбиотических связях между бизнесом и разработкой.
⠀
Что по итогу:
⠀
1) Основы DDD — общая теория. Язык и словарь — как основа DDD и выстраивания разумной коллаборации между бизнесом и разработкой.
⠀
2) Екатерина поделится методикой эволюционного, а не революционного внедрения DDD вместе с новыми проектами в компании (методика апробирована и дает хорошие результаты).
⠀
3) Разберем правила формулирования определений и поймем, как через определения строить архитектуру.
⠀
4) Тренировочная часть формулирования определений и их влияния на архитектуру.
⠀
5) Екатерина поможет найти свой стиль «словоплетства» и даст обратную связь.
⠀
6) Разберем процесс внедрения такого подхода в компании, работу с возражениями.
⠀
Встречаемся на TechLead Conf 2023, которая пройдет в рамках TeamLead++ Conf 2023 🖐
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5
Всем привет!
Сегодня продолжу холивар про аналитиков и анализ! Нужны/нужно или дешевле, чтобы не было! И в чем измеряется "дороговизна" таких "товарищей"
Пост в статье на LinkedIn.
Давайте обсуждать!
#project_management
Сегодня продолжу холивар про аналитиков и анализ! Нужны/нужно или дешевле, чтобы не было! И в чем измеряется "дороговизна" таких "товарищей"
Пост в статье на LinkedIn.
Давайте обсуждать!
#project_management
Linkedin
Любимый холивар: нужен ли аналитик на проекте?
..
Сегодня небольшая статья на LinkedIn порожденная разговором с Анваром, исследованием (ссылка на которое в самой статье), моим весенним докладом на DevOps и недавними диалогами с коллегами из различных IT компаний.
Рассуждаю на тему разрыва и неудовлетворенности между C-level компаний и сотрудниками компаний, и почему я вижу выход из кризиса в рациональной коллаборации.
И вопрос: а на сколько вам удобно читать материалы на LinkedIn?
#people_management
Рассуждаю на тему разрыва и неудовлетворенности между C-level компаний и сотрудниками компаний, и почему я вижу выход из кризиса в рациональной коллаборации.
И вопрос: а на сколько вам удобно читать материалы на LinkedIn?
#people_management
Linkedin
Проблемы, Решения и Коллаборация
Недавно для собственного проекта я запустила опрос "Проблемкометр". Моя цель была выяснить, сталкиваются ли люди с проблемами и трудностями в своей работе и в жизни, и как они формулируют эти проблемы и трудности.
❤2
В последние дни много думаю про Обратную связь (ОС), как очень сильный инструмент, которым легко "пренебречь", но который, при разумном использовании, дает потрясающие результаты.
Размышления вылились во внеочередную небольшую статью.
Теперь "лонг-риды" попробую публиковать на Хабре, пжл, дайте ОС - на сколько вам теперь удобно будет!
А еще интересно:
- какие модели ОС вы зачастую используете?
- считаете ли вы ОС - ретроспективной практикой?
- в чем для вас (если оно имеется) отличие ОС от 1:1?
Почему я вообще про ОС вспомнила?! К сожалению (или к радости), занимаясь проектированием, вступая во взаимодейтсвие с различными командами, приходится постоянно реагировать на происходящее и, ИМХО, ОС - один из основных инструментов позволяющих инициировать изменения. Особенно, если вы живете с коллегами в +- единой системе ценностей. Но, нет, ОС - не панацея и все ей не починить!
#people_management
Размышления вылились во внеочередную небольшую статью.
Теперь "лонг-риды" попробую публиковать на Хабре, пжл, дайте ОС - на сколько вам теперь удобно будет!
А еще интересно:
- какие модели ОС вы зачастую используете?
- считаете ли вы ОС - ретроспективной практикой?
- в чем для вас (если оно имеется) отличие ОС от 1:1?
Почему я вообще про ОС вспомнила?! К сожалению (или к радости), занимаясь проектированием, вступая во взаимодейтсвие с различными командами, приходится постоянно реагировать на происходящее и, ИМХО, ОС - один из основных инструментов позволяющих инициировать изменения. Особенно, если вы живете с коллегами в +- единой системе ценностей. Но, нет, ОС - не панацея и все ей не починить!
#people_management
Хабр
Про обратную связь и ответственность
Сила обратной связи Обратная связь – это механизм, который помогает нам понимать, как мы выполняем свои задачи, взаимодействуем с окружающими, и какие результаты достигаем. Это ключевой инструмент...
💯4
Про Парето
Сегодня подумалось, про ожидания бизнеса от крупных реинжиниринговых проектов. Я про общую ситуацию в секторе.
Правило 20% усилий дают 80% результата зачастую ставится в красный угол всего бизнеса. И это нормально! Но, речь идет о % - то есть о долях! Но нигде не говорится о том, от чьего целого стоит считать! Соответственно у каждого из нас есть возможность попасть в ситуацию, когда 20% моих усилий = 70% усилий другого человека. И тогда, для этого второго человека, мои 20% станут оверкилом!
ИМХО, все «интереснее» при проектировании: 20% потраченные на анализ от общего объема «океана неизвестности» дадут стабильную на 80% архитектуру. И вроде бы это «норм», НО! У каждого из нас размер «океана» свой. Кто-то видит до горизонта, кто-то помнит, что на противоположной стороне другая страна (продукт), а кто-то помнит, что океан всемирный и все продукты компании находятся в одной экосистеме.
И что же получается? Чем больше я знаю, тем больше мои 20% и тем меньше мои 20% на шкале других? И ладно при выводе новых продуктов на рынок, но при реинжиниринге стоит учитывать проблемы интеграций в перспективе 1-5 лет (в зависимости от стабильности компании и продукта).
Мб «продавая» большие архитектурные решения нужно еще и «продать» веру, что приложил ты к этой архитектуре все еще 20%! Но при различных размерах «океана» это уже сложнее…
Что думаете? Какого размера ваш океан?
Сегодня подумалось, про ожидания бизнеса от крупных реинжиниринговых проектов. Я про общую ситуацию в секторе.
Правило 20% усилий дают 80% результата зачастую ставится в красный угол всего бизнеса. И это нормально! Но, речь идет о % - то есть о долях! Но нигде не говорится о том, от чьего целого стоит считать! Соответственно у каждого из нас есть возможность попасть в ситуацию, когда 20% моих усилий = 70% усилий другого человека. И тогда, для этого второго человека, мои 20% станут оверкилом!
ИМХО, все «интереснее» при проектировании: 20% потраченные на анализ от общего объема «океана неизвестности» дадут стабильную на 80% архитектуру. И вроде бы это «норм», НО! У каждого из нас размер «океана» свой. Кто-то видит до горизонта, кто-то помнит, что на противоположной стороне другая страна (продукт), а кто-то помнит, что океан всемирный и все продукты компании находятся в одной экосистеме.
И что же получается? Чем больше я знаю, тем больше мои 20% и тем меньше мои 20% на шкале других? И ладно при выводе новых продуктов на рынок, но при реинжиниринге стоит учитывать проблемы интеграций в перспективе 1-5 лет (в зависимости от стабильности компании и продукта).
Мб «продавая» большие архитектурные решения нужно еще и «продать» веру, что приложил ты к этой архитектуре все еще 20%! Но при различных размерах «океана» это уже сложнее…
Что думаете? Какого размера ваш океан?
🔥6👍1