Привет!
Я - Катя Лысенко. Это мой личный канал, в котором я буду делиться:
- мыслями и вопросами, которые меня волнуют и беспокоят;
- лайфхаками и открытиями, которые мне помогают в работе и жизни;
- успехами и неудачами, вдруг они смогут ваш путь сделать проще;
- просто чем-то инетересным...
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