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

Например, если системный аналитик Катя работает усерднее системного аналитика Васи, но получает более низкую зарплату, то она будет считать эту ситуацию несправедливой. И вариантов развития событий не так уж много:
1️⃣ попросит повышения,
2️⃣ сбавит обороты
3️⃣ найдет новую работу.

Иногда мне кажется, что у англосаксов на каждый случай жизни есть своя теория, график или закон. 😂

#объяснение #опрос

🧭🌺🧡🌿💎🌸🧡🌸💎🌷 по каналу

Всем привет! 👋

Пришло время менять закрепленные сообщения.

Познакомимся? О канале и обо мне

Уже сейчас количество постов - на минуточку! - перевалило за сотню. Среди них есть те, которые сохраняют свою актуальность и полезность. Мне как автору канала очень хочется, чтобы они не затерялись в бесконечной ленте, и вы могли всегда вернуться к особенно удачным постам.

Ловите списки!

🔥Топ-5 самых лучших постов
1️⃣ Как проверить будущее место работы. Советы, о которых вам никогда не расскажет HR
2️⃣ Как меняться, не изменяя себе
3️⃣ Почему лучше не хлопать дверьми, даже если очень хочется
4️⃣ Про мой самый первый раз
5️⃣ Говорите на понятном языке с разработчиком

📝 Список абсолютно всех постов канала

📰 Список всех моих публикаций в СМИ

А еще я сделал хештеги в канале для навигации
#гайды
#советы
#кейсы
#объяснение
#мнение
#карьера
#обзор_книги
#опрос
#интересное
#моипубликации
#AMA
#осебе
#личное
#прошлое_авиатора
#юмор #мем
#quiz

Смело пишите в комментариях, что бы вы еще хотели видеть в канале 😊

Как менеджеру перестать быть «блондином», если ты 3 месяца в айти

Когда я пришел в айти в роли Release Manager в 2022 году, первые месяцы остро чувстовал нехватку технических знаний. Мне успешно удавалось руководить командой за счет прошлого опыта управления. И курс "Менеджер It-проектов" от Яндекс Практикума дал общее понимание, как разрабатывается ПО.

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

"Саша, ты представляешь, эти дебилы NULL отправляют для такого-то параметра!".

Я покивал головой, как будто понимаю, о чем речь, а про себя подумал, мне хоть нуль, хоть единица, одна хрен разница - ничего не понимаю.

Мои непосредственные руководители выросли в мире айти, они разбирались хорошо в деталях и при необходимости с легкостью читали HTTP-запросы и ответы, понимали архитектуру и взаимосвязи системы; могли быстро написать SQL-запрос, чтобы проверить, как отрабатывает REST API; сравнить дифы в Git и посмотреть конфиги, расплести сложные бранчи. Я равнялся на них. Чтобы ни говорили, если руководитель понимает технические детали, он будет лучше и чаще принимать верные решения.

Ситуацию усугубляло еще то, что мы разрабатывали сложное микросервисное веб-приложение, представляющее собой целую IT-платформу для взаимодействия сотрудников всех подразделений одной известной компании. И к технической сложности добавлялась специфика разнообразных доменных областей с множеством бизнес-зависимостями (заключение сделки, финансы, сервис и т.д.).

Вначале я пытался самостоятельно закрывать эти пробелы в знаниях: пробовал разрозненные курсы по отдельным темам (например, взял курс SQL), начинал читать книги, статьи в интернете. Но знания оставались фрагмертарными и не складывались в общую картину, а часть информации была непонятной для меня. Да и время было спресованно: мы в сжатые сроки шли к нашему MVP.

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

В голове выстроились критерии:
1️⃣ Мне необходима широкая картина процесса разработки от идеи до поддержки, но с бóльшим количеством деталей, чем та, которую я получил от менеджерского it-курса.
2️⃣ Мне необходимо было научиться понимать разрабатываемую систему на уровне компонентов и взаимосвязей между ними.
3️⃣ Мне необходимо было узнать базовые понятия и связи между ними
❎ У меня не было необходимости понимать систему на уровне кода, поэтому варианты с изучением программирования я не рассматривал

Исходя из этого в марте 2023 года я записался на 9-ти месячный курс "Системный Аналитик" от Яндекс Практикум. Это решение дало чувство спокойствия и управляемости.

Что из этого получилось, читайте в следующем посте.

#советы

Итак, в марте 2022 я снова влился в поток студентов Яндекс Практикума на курс "Системный аналитик".

Курс полностью оправдал мои ожидания. Структура обучения была выстроена таким образом, что каждый новый модуль опирался на предыдущий, что особенно важно для последовательного освоения материала. Это было именно то, чего мне не хватало в самостоятельном обучении.

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

Что особенно запомнилось:
1️⃣ Тренажер по SQL
Уже имея опыт изучения SQL в другой онлайн-школе, я наивно полагал, что новый материал мне знаком. Поэтому открыл модуль только в конце спринта, что оказалось роковой ошибкой. Количество заданий и их сложность быстро выросли, и это стал единственный спринт, который я не завершил вовремя. Одно из заданий я пытался решить 4 дня, но так и не справился. В итоге, мне пришлось обратиться за помощью к коллеге — системному аналитику, чтобы разобраться с подзапросами и общими табличными выражениями.
2️⃣ Модуль с моделированием данных и проектированием баз данных
В домашнем проекте я САМ разработал и задокументировал модель данных для сайта магазина, охватывающую три уровня абстракции: концептуальный, логический и физический. Этот опыт позволил мне понять, как формируется структура будущей базы данных.
3️⃣ Проект по пользовательскому интерфейсу
Этот проект стал для меня возможностью проявить креативность. Нужно было разработать интерфейсы экранов мобильного приложения в Figma, добавив переходы и интерактивные "вау"-эффекты.

Кому будет полезен курс
👶Новичкам, которые хотят стать системными аналитиками. Если бы я начинал карьеру в IT в 20 лет, то выбрал бы путь системного аналитика.
😡Руководителям, наевшихся уставшим от менеджмента и желающим перейти к более спокойной аналитической работе. Я лично встречал такие примерЫ
👨‍💻 Руководителям команд, разрабатывающих сложные веб-приложения. Курс поможет им лучше понимать разработчиков и говорить с ними на одном языке.

Теперь вы расскажите про свой опыт, как вы закрывали гэпы в технических знаниях и навыках?

#советы

Как эффективно говорить со своим руководителем

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

В спокойной рабочей обстановке руководитель может подумать: "Господи! Я задал ему конкретный вопрос! Зачем он мне это вываливает? Избавь меня, пожалуйста, от этих деталей». Если при этом подчиненный увлекается и "его понесло", то руководитель может просто перестать слушать и задуматься о следующей встрече, текущих делах, а иногда и о том, пора ли уже менять шины.

В более напряженных ситуациях, особенно если руководитель отличается прямолинейностью, он может не постесняться оборвать подчиненного на полуслове. И призвать к конкретике. При этом подчиненный почувствует досаду и непонимание: "Я же старался, как можно подробнее рассказать, чтобы он лучше понял все нюансы!».

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

❔ Какие же особенности этого языка?

1️⃣ Ограниченное время и множество контекстов
Руководитель работает с большим количеством разноплановых задач и не может погружаться в детали каждой из них. Ему важно получить актуальную и сжатую информацию о текущем положении вещей, чтобы принять правильное решение.

2️⃣ Фокус на ключевых аспектах
Руководителя интересуют три вещи: статус, сроки и риски. Если есть проблема — лучше сразу предложить решение. Ему не нужны детали "от мамонтов и до наших дней". Если информация понадобится, руководитель сам спросит, но и тогда важно выдавать ее небольшими порциями.

3️⃣ Различие в стилях восприятия информации
Ваш руководитель может отличаться от вас в типе мышления, предпочтениях и стиле взаимодействия. Так, если вы привыкли писать длинные отчеты, а он предпочитает получать информацию устно, к сожалению, вам придется адаптироваться и научиться четко и кратко излагать суть на встречах.

Учитывайте эти особенности при следующем разговоре. Тем самым вы сэкономите свое и чужое время. И за это вам будут благодарны.

Расскажите, какие лайфхаки вы используете, когда общаетесь со своим руководителем?

#советы

Полёт в Стратосферу #2

Всем привет! В эти выходные я завершил второй модуль курса "Руководитель отдела" от Стратоплана.

❔ О чем был модуль

Начну с вопроса, который задал нам преподаватель: "Сколько решений вы принимаете за день на работе?". Ответы варьировались от 5 до 30 (я ответил 16). А ведь и правда: нам платят за то, что мы принимаем и реализуем решения. И чем больше процент удачных решений, тем успешнее не только руководитель, но и любой человек в своей жизни.

Многие повседневные решения мы принимаем автоматически, опираясь на опыт и интуицию. Практически мгновенно. Привет "системе-1" Даниэля Канемана! Зачем размышлять, что надеть вначале рубашку или джинсы? Делай, как научили в три года.

Но как поступить, если перед нами комплексная задача и в ней задействованы другие люди? А еще бывает, что простые проблемы - обманчиво знакомы, и мы привычно достаем свой молоток и начинаем забивать гвозди в бетонную стену.

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

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

👨‍💻 Что мы делали

Так вот в Стратоплане целых 3 дня нас учили подходить к принятию решений структурно: анализировать проблемы, формулировать решения и грамотно их доносить до всех заинтересованных сторон. Знакомые инструменты и понятия (Декартовы квадранты, когнитивные искажения) дополнились новыми: треугольник Липпмана и конфликтогены. Но ценность заключалась не только в самих инструментах, но в их соединении в единую систему.

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

Выводы

⚠️Структурный подход к принятию решений действительно важен.

Плохая новость: он требует времени. Например, на кейс у нас было 40 минут, но и этого порой не хватало, чтобы пройти все шаги качественно.

Хорошая новость: с регулярной тренировкой (преподаватель рекомендовал делать это хотя бы раз в неделю) мозг начинает быстрее находить решения. Со временем это не только увеличит количество принятых решений, но и повышает их качество, что в конечном счете способствует успеху как компании, так и отдельного человека.

#мнение

Семь бед - один ответ!

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

Ваша команда уверенно справляется с разработкой, но вот незадача: новая фича относится к той доменной области, с которой вы никогда не работали. А бизнес попросил его сильно не отвлекать и прислал ссылки на страницы в Confluence, где часть информации была обновлена N-2 лет назад, а актуальные страницы представляют собой огромный поток неструктурированного текста без иллюстраций и схем.

Вы обращаетесь в соседнюю команду, с которой нужно выстроить несколько сценариев взаимодействий. На предложение совместно создать Sequence Diagram для описания сквозных процессов, аналитик другой команды восклицает, что он и его разработчики не знакомы с этой нотацией.

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

Отличным инструментом для решения такого рода проблем может стать Event Storming.

❔Что это такое?

Event Storming - это метод, позволяющий достаточно точно и быстро визуализировать бизнес-процессы и системы. Его преимущество в простоте: для описания системы любой сложности достаточно всего 5-7 элементов. Сравните на минуточку c BPMN, где более 100 элементов.

Автор подхода - итальянский программист Альберто Брандолини, который, кстати, ориентировался на принципы Domain Driven Design (DDD).

📎Как это работает?

Event Storming - это серия воркшопов, на которые собираются ключевые специалисты из разных отделов (бизнес-аналитики, разработчики, эксперты в предметных областях), чтобы совместно создать визуальную модель системы с помощью цветных стикеров.

Процесс проходит итерационно: сначала описывается общая картина (Big Picture), затем уточняются детали процессов (Process Modeling) и в конечном итоге разрабатывается дизайн будущего приложения (Design-Level).

Ведет встречи фасилитатор, знакомый с принципами и эвристиками Event Storming.

👩‍🎓Как познакомиться с Event Storming?

1️⃣ Прочитайте статью на хабре
2️⃣ Посмотрите видео на Youtube
3️⃣ Ознакомьтесь с книгой Альберто Брандолини Как пишет сам автор, книга написана на 70%, но я нашел ее крайне полезной
4️⃣ Следите за постами c хештегом #EventStorming в канале: я буду делиться своим опытом использования этого подхода и фасилитации воркшопов

Расскажите, применяли ли вы EventStorming в своей работе?
🦄 - Да
🙈 - Нет

#EventStorming

Кто сегодня молодец?

В одном из недавних проектов мы работали над повышением точности алгоритмов для определения местоположения респондентов по IP-адресам. Эта доработка позволит более аккуратно раскладывать просмотры ТВ, кино-сериалов, маркетплейсов с учетом географии. Например, мы будем еще точнее понимать, в каких городах и селах России любят смотреть сериал "Лихие", а в каких - предпочитают "Комбинацию" и "Трассу".

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

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

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

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

💡И тут - эврика! - в голове возникает гипотеза. Некоторое время назад в другом проекте мы улучшали функциональность для повышения точности определения устройств. Возможно, возник конфликт версий этих 2 функциональностей.

Обсуждаю гипотезу с коллегой, знакомой с контекстом. Проверяем вместе с ней и разработчиком: да, действительно на standby частично уехала не та версия библиотеки определения устройств.

📍Выводы
1️⃣ Четыре месяца работы с BigData, и я очень доволен, что уже начал сам находить решения для неочевидных проблем, а не просто двигать таски в трекере и фасилитировать встречи. По многим исследованиям, сотрудники достигают полной автономности в среднем спустя 6 месяцев работы, и я рад, что иду с опережением.

2️⃣ Если вы только начали карьерный путь, пришли в новую компанию или решили сменить профессию, отмечайте каждую свою маленькую победу! Эти моменты — как маяки или фонарики — освещают дорогу вперед и показывают, как далеко вы уже продвинулись.

Давайте сегодня похвастаемся своими маленькими победами. Жду вас в комментариях 😊

Почему важно знать ВСЁ?

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

Хорошо, если весь этот процесс отдан на откуп профессионалам. А если приходиться вовлекаться самому? И становиться "менеджером своего ремонтного проекта"… Тут уже нужно знать основные этапы ремонта: от демонтажных работ и черновой отделки до инженерных работ и чистовой отделки.

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

Software Development Life Cycle (SDLC, жизненный цикл программного обеспечения) - концепция, описывающая ключевые этапы от момента зарождения идеи и до момента, когда вы получаете оповещение, что ваше любимое приложение больше не работает ⚰️

Условно, цикл обычно включает такие этапы:
1️⃣ Планирование
2️⃣ Определение требований
3️⃣ Проектирование архитектуры
4️⃣ Разработка
5️⃣ Тестирование
6️⃣ Развертывание и сопровождение
7️⃣ Вывод из эксплуатации

📍Важные комментарии
💡Не всеми этапами вы будете управлять лично. В крупных компаниях или в масштабных проектах вам, вероятно, придется фокусироваться только на одном-двух этапах. Но возможна и обратная ситуация, что вы будете вовлечены в большинство этапов.
💡Этапы могут различаться по глубине проработки. Для сложных систем проектирование архитектуры требует значительных ресурсов и артефактов. В случае разработки маленькой фичи иногда достаточно накидать схему на доске с командой.
💡Не каждый проект проходит все этапы.
А можно ли пропустить этап тестирования? 😂 Можно, но будьте готовы к "happy holidays". Как и пренебрежение гигиеной, пропуск важных этапов приведет к большим проблемам.
💡Не все этапы идут строго в том порядке, который написан выше. Последовательность может изменяться, и этапы часто пересекаются.

Как же настраивать жизненный цикл при таком разнообразии?

Здесь помогут устоявшиейся модели жизненного цикла программного обеспечения: Waterfall, Итеративный подход, Scrum, Kanban и т.д. О выборе моделей, их преимуществах и недостатках поговорим как-нибудь в будущих постах.

Вывод

Понимание последовательности и взаимосвязей жизненных циклов ПО - критично для руководителя. Без него вы рискуете оказаться в роли хозяина квартиры, который через несколько месяцев ремонта теряет контроль над сроками и затратами.

😂👍👍❤️👌😅😊😊😍😘
в моём тг-канале

В пятницу, 15 ноября в 19:00 по МСК я жду каждого из вас на эфире на тему:

«Доверие как капитал: КАК построить прочные доверительные отношения внутри команды и с клиентами?»

Спикер: Александр Хван – старший технический менеджер проектов в Big Data.

Александр 14 лет работал в конструкторском бюро AIRBUS - руководил и проектировал самолеты. На данном этапе его любимая часть работы – развивать команды и сотрудников: считает своей сильной стороной тактико-операционное управление.

На эфире мы с Александром поднимем важные вопросы:

❓ПОЧЕМУ доверие так важно для успешной работы команды и взаимодействия с клиентами
❓КАК измеряется уровень доверия и КАКИЕ показатели могут свидетельствовать о его росте или снижении
❓КАКИЕ факторы мешают формировать доверие в команде, особенно в IT-сфере, где многие взаимодействия происходят удаленно
❓КАК руководитель может укрепить доверие в коллективе
❓ЧТО делать, если доверие уже нарушено, и КАК можно его восстановить

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

Чтобы не пропустить отличную возможность прокачать свои навыки управления и узнать, КАК создавать здоровую и продуктивную атмосферу в команде, приходите на эфир уже завтра, в 19:00 (МСК).

Присоединиться можно будет по ссылке ➡️ https://news.1rj.ru/str/LogachevaEQ?livestream

Полёт в Стратосферу #3

Всем привет! В прошлые выходные я завершил третий модуль курса «Руководитель отдела» от Стратоплана.

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

Модель Минцберга позволяет лучше понимать устройство компаний и принимать взвешенные решения. С помощью нее можно:
1️⃣ Определить текущий тип компании, чтобы адаптировать под неё стиль управления
2️⃣ Выбрать структуру, в которую лучше трансформировать организацию, чтобы соответствовать внешним вызовам

Однако, как и любая модель, это лишь упрощенное отражение реальности.

Когда я был подростком, меня завораживали классификации: жанры литературы, музыкальные направления, классы растений и животных Карла Линнея. Систематизация казалась мне идеальным способом сделать мир ясным и логичным. Но меня всегда бесили те, кто не вписывался в эти рамки, например, художники и музыканты, которых невозможно однозначно отнести к какому-то направлению. И, конечно, грибы🍄‍🟫 с их «недорастениями-недоживотными» рушили мой идеальный мир!

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

И это нормально. Жизнь всегда сложнее любой модели, схемы или матрицы. Возникает вопрос: стоит ли тогда вообще запоминать всё это? Мой ответ - да! Чем больше моделей и концепций вы знаете, тем легче анализировать реальность. Эти модели могут причудливо складываться в вашей голове, помогая увидеть картину с разных сторон.

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

Записи эфиров для успешных IT-руководителей: начать неделю с этой подборки будет лучшим вашим стратегическим решением

Полезная подборка свежих видео-интервью на ▶️YouTube, которая станет отличным ресурсом для IT-руководителей, заинтересованных в противостоянии выгоранию (как личного, так и своих сотрудников), в мотивации через нематериальные ценности, в карьерном росте без ущерба для личного счастья, а также в важной и бесценной теме — доверие.

1️⃣ Секреты самореализации или «Перезагрузка» вашего карьерного пути в IT –

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

Вас ждут ценные рекомендации о том, КАК выбирать карьерный трек, оставаясь верным своим внутренним жизненным интересам и ценностям. Интервью

с Даниилом Пилипенко, директором Центра подбора IT-специалистов и карьерным коучем.

2️⃣ Доверие как капитал: создание доверительных отношений в команде и с клиентами.

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

Александр Хван, старший технический менеджер проекта в BigData.

3️⃣ Интервью, которое защитит от выгорания каждого IT-руководителя.

Что важнее: счастье от своей деятельности или увеличение зарплаты? Как предотвратить выгорание?
Ответы уже доступны в эфире

с Евгением Идзиковским,
сертифицированным психологом и психотерапевтом с 15-летним опытом.

➡️ ПОДПИСЫВАЙТЕСЬ,
ЧТОБЫ ИСПОЛЬЗОВАТЬ ПРОВЕРЕННЫЕ РЕШЕНИЯ ОТ ЛУЧШИХ ЭКСПЕРТОВ В ИНДУСТРИИ IT, А НЕ ОГРАНИЧИВАТЬСЯ ТЕОРИЕЙ.

Делитесь своими идеями о том, кого бы вы хотели услышать в следующих интервью, и какие темы вам интересны для обсуждения!