Чек-листы в авиации

На правах авиаконструктора в отставке✈️ проконсультировал @terbiy для его статьи про чек-листы в авиации.

Он ведет канал «Итак, список» целиком посвященной теме чек-листов и спискам.

Хотите узнать, как обеспечивают качество обслуживания в ресторанах? Смотрите чек-лист "ДоДо Пицца" или может, прочитать список самых знаменитых казненных французов - на это есть список.

А если вы сами хотите поделиться, как вы используете чек-листы в своей работе или жизни, обязательно напишите Герману 😊

#прошлое_авиатора

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

Например, если системный аналитик Катя работает усерднее системного аналитика Васи, но получает более низкую зарплату, то она будет считать эту ситуацию несправедливой. И вариантов развития событий не так уж много:
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️⃣ Если вы только начали карьерный путь, пришли в новую компанию или решили сменить профессию, отмечайте каждую свою маленькую победу! Эти моменты — как маяки или фонарики — освещают дорогу вперед и показывают, как далеко вы уже продвинулись.

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