Рецензия на пост «Размывание целей» Марии Серёгиной 📝

Итак, я еще участвую в конкурсе «Продолжи мысль» от @systems_education и успешно прошел во второй тур 🎉

В этом туре нужно оставить рецензию на пост другого участника. Наиболее интересным мне показался пост «Тенденция к снижению производительности» или «Размывание целей» на примере чашечки кофе Марии Серёгиной

📌 О чем пост?

Про один из системных архетипов – и нет, не про паттерны архитектуры или другие технические приколы. Системные архетипы описывают скрытые закономерности в поведении, применимые к людям, организациям, корпорациям – в общем, в разных контекстах. Для каждого эти архетипы будут близки по-своему

Мария разбирает архетип «Тенденция к снижению производительности» на уровне организации, используя пример с кофейней ☕

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

👍 Что понравилось

🤍Четкая структура поста – понятно, от чего и к чему идем
🤍Приятное оформление, ничего не отвлекает от темы
🤍Сама тема нестандартная и интересная
🤍Разбор архетипа на простом примере
🤍Оставлены ссылки на предыдущие посты – в итоге легко найти первоисточник и прочитать про другие архетипы
🤍Есть аналогия с IT-областью
🤍Не просто объяснение концепции, но и вывод, что с этим делать – в посте есть практическая ценность

💡 Что бы я улучшил

🤍Вторую часть поста читать сложнее, чем первую. Информации много, а абзацы к концу становятся длиннее и «тяжелее». Я бы разделил на два или сократил бы
🤍Было бы интересно прочитать о примерах из других сфер

🤔 Какие мысли вызвал пост

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

Например, когда работал копирайтером, ставил себе цель писать не менее 20000 символов в день. Но за этот день у меня могла быть учеба в вузе, я мог съездить за продуктами, потратить время на готовку – в итоге цель чаще всего не была достигнута 🥲

Другой пример – стремление накопить какую-то сумму, но минутные и импульсивные траты не позволяли этого достичь (то есть, цель была «размыта» мелкими тратами). В итоге опускал планку и убеждал себя, что это тоже нормальный результат

Думаю, это и есть описанный Марией архетип. Теперь я могу распознать его, но получится ли бороться с ним – вопрос времени и силы воли

—————

⬇ А что вы думаете про «Размывание целей»? Бывали ли такие случаи? Пишите в комментариях, интересно обсудить

#продолжи_мысль_SE

Как я НЕ стал техническим писателем 🙅‍♂️

В августе 2022 года я окончательно распрощался с попытками работать инженером и решил входить в IT. Рассказываю, как это было

🥵 Войти в айти

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

Прошел экспресс-курс на технического писателя за 2 недели и 7000 руб. Полностью переписал резюме под тех писателя, а в качестве опыта работы взял 6 лет копирайтинга 😏. Начал откликаться, и буквально через пару дней меня пригласили на собес в Москва Сити 🌈

Подготовился за день, на самом собесе отвечал неуверенно – я тогда не знал ни про API, ни про БД, ни еще что-то. Но как-то рассказал, думал, что провалился – но меня приняли

Но не все так просто

🤔 В чем подвох?

И вот я начал работать техническим писателем. Документации на проекте не было, поэтому я изучал код, чтобы восстановить архитектуру, описывал API, макеты интерфейса, функциональные требования, базу данных, затем ставил задачи на разработку… Что-то тут не так

Через четыре месяца осознал, что выполняю работу системного аналитика, а не технического писателя. ГОСТ, docs as code, инструкции, мануалы – всего этого тут не было. Максимум писал release note, и все. Все остальное подходило под описание работы СА

А по записи в трудовой книжке я вообще был программистом 😁

🏃‍♂️‍➡️ Что я сделал

Осознав это, в январе 2023 поступил на четырехмесячный курс СА. Знания сразу применял – дорабатывал то, что уже написал, и старался внедрить практику СА в команде, т.к. в процессах творился хаос

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

После этого искал работу уже СА, пытался пройти несколько собеседований – но говорили, что опыт маловат. Попросил помощи у компании, которая меня обучала, в итоге устроила к себе на аутстафф

Там немного набрал опыта, структурировал знания и уже через пару месяцев устроился в хорошую компанию сразу на Middle+

———————

Вот такой у меня путь в IT. В итоге техническим писателем я не проработал ни дня, получилось «перепрыгнуть» эту ступень, что и так было в планах. Работодатель просто не знал, кто такие СА, и думал, тех писатели от слова «писать», а писать доку надо было срочно

⬇ А как вы начинали свой путь в IT?

#истории_системный_анализ

Я – Senior. Что дальше? 🤔

Рассказываю свое видение дальнейших тропинок ведущего системного аналитика

🤍 Team Lead/Руководитель СА

Меньше hard skills, больше soft skill. Меньше работы с задачами, больше с людьми: найм и увольнение, контроль состояния, принятие различных решений и ответственности за них

Рекомендую:
🤍Попробовать менторство (от 2 и более людей)
🤍Прокачать теорию управления людьми – через литературу или курсы
🤍Просить руководителя делегировать часть своих задач

Заметил, что чаще стали появляться курсы для тимлидов – знаю, такие есть на Отусе и Стратоплан. Из книг советую начать с «Пять пороков команды: притчи о лидерстве»

🤍 Архитектор

Если развивать hard skills, то со временем можно попробовать стать архитектором. Они бывают разные:

🤍Системный архитектор (Software Architect)
🤍Архитектор решений (Solution Architect)
🤍Корпоративный архитектор (Enterprise Architect)

Их обязанности отличаются, но, как мне пояснил архитектор с опытом, на практике их не всегда разделяют, особенно в небольших и средних компаниях

Что делать, если хочешь уйти в архитектуру (общие рекомендации):
🤍Изучать теорию по архитектуре – через литературу или курсы
🤍Найти проект с микросервисной архитектурой, где СА вовлечен в задачи архитекторов и разработчиков
🤍Брать сложные задачки, которые требуют проработки архитектуры
🤍Осваивать технологии (OpenShift, Docker и др)
🤍(необязательно) Освоить язык программирования и написать pet-проект

➡️ Подробности – в следующем посте

🤍 Tech Lead

Организует техническую работу команды, принимает ключевые архитектурные решения, менторит разработчиков, а также может писать код и закрывать сложные задачи. В отличие от Team Lead, фокус в техническую сторону. В отличие от Архитектора, больше вовлечен в код.

На мой взгляд наименее вероятная ветка перехода, нужен опыт разработчика 🤯

🤍Разработка/QA/DevOps/иная смежная роль

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

Правда, придется доучиться и откатиться по ЗП и грейду 💸 – но опыт СА определенно будет плюсом

Шаги по смене профессии очевидны: обучаемся через курсы или книги, дорабатываем резюме и пробуем устроиться на работу

🤍Фриланс/подработки

Можно остаться Senior и укреплять свои hard и soft skills без смены рода деятельности, и направить внимание на:

🤍Фриланс – проекты вне основной работы
🤍Менторинг – персональное обучение
🤍Преподавание в онлайн-школах – тоже обучение, но на широкую аудиторию
🤍Личный бренд – выступление на конференциях, участие в активностях сообщества, развитие своего блога
🤍Открытие своего дела – онлайн-школа, компания по разработке

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

————————————

💡 В следующем посте поделюсь своим планом по переходу в архитекторы – что уже сделал, что предстоит, возможно ли это вообще и что я думаю по этому поводу

#полезное_системный_анализ

Не забывайте надевать футболку перед созвоном 🙈

Еще готовлю посты про свои планы по переходу в архитектуру – там будет много интересного и полезного, но потребуется больше времени

А пока держите кринжовую историю о том, как мы вели демо с элементами легкой эротики 🔞

Итак, история

Жаркое лето, очередное демо на проекте 👨‍💻. Вели его в паре с разработчиком на удаленке. На созвонах со своими сидим без камеры, но перед заказчиком обязательно включаем ее для хорошего тона

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

Так вся команда и заказчик лицезрели голый подкачанный торс гигачада-разработчика ☺, что у команды сначала вызвало смятение, а затем разрывные улыбки. Заказчик был довольно позитивным, поэтому тоже воспринял все происходящее с улыбкой

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

Что в итоге?

Как итог – ничего страшного не случилось, разработчик поймал стыд, мы же (и заказчик тоже) просто запомнили эту юморную ситуацию. Однако если бы перед экраном сидели корпораты в костюмах, думаю, было бы не до смеха ❌

———

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

⬇ А какие у вас были кринжовые ситуации на работе, связанные с камерой?

#истории_системный_анализ

Путь до архитектора. Часть 1 🚀

Как и обещал, рассказываю о своих планах по переходу в архитекторы

Разбил пост на три части – тут делюсь чек-листом по темам архитектуры ПО. Им со мной поделился мой ментор – опытный архитектор

Делюсь доской в Холст – там весь чек-лист можно рассмотреть подробнее. А еще оригинал картинки в комментариях

📌 Чек-лист по темам

🤍 Теория по проектированию систем (System Design)

Must have темы для изучения, развитие базы системного аналитика:

🤍Паттерны архитектуры: монолит, сервисная, микросервисная, Serverless, корпоративная
🤍Сеть: топология, DNS, OSI & TCP/IP, протоколы
🤍Интеграции: REST, SOAP, GraphQL, gRPC, WebSockets, Webhook, Kafka, ActiveMQ, RabbitMQ
🤍Прокси: балансировщики нагрузки, Reverse Proxy, API Gateway
🤍Процессные движки: BPM, Activiti, Camunda
🤍Базы данных: DML & DDL, транзакции, ACID, изоляция, нормализация, реляционные БД, нереляционные БД, in-memory БД, индексы, репликация, шардирование, профилирование, CAP-теорема
🤍Кэширование: CDN, клиентский кэш, серверный кэш
🤍BigData: Hadoop, S3, Spark
🤍Поисковые движки: Elasticsearch, Opensearch
🤍Безопасность: виды аутентификации, хэш-функции, SSL/TLS, HTTPS

🤍 Алгоритмы и структуры данных

Двигаемся далее и погружаемся в алгоритмы и структуры данных:
🤍Алгоритмы: понятие сложности алгоритмов, оценка сложности
🤍Структуры данных: массивы, списки, очереди, графы, деревья, хэш-таблицы

🤍Frontend & Backend

Наиболее сложная и объемная часть для тех, кто ранее не программировал. И пригодятся темы только архитекторам, работающим с кодом

🤍Frontend: базовое понимание устройства (протоколы, веб-сокеты, cookie). В идеале изучить какой-нибудь язык (например, JavaScript) и написать небольшой pet-проект
🤍Backend: общие принципы работы (ООП, SOLID, Паттерны проектирования), изучение языка (например, Java) и pet-проект

🤍DevOps & Тестирование:

Не обязательно углубляться, достаточно изучить общие концепции и инструменты:
🤍DevOps: как устроен CI/CD, Docker, Kubernetes
🤍Тестирование: теория, интеграционные тесты, unit-тесты, Postman, Swagger, Charles

🤍Методологии разработки & Soft Skills:

Все что связано с управлением проектом и взаимодействием с людьми:
🤍Методологии: Waterfall, Agile, Lean
🤍Soft Skills: все, что с ними связано

И как все это осилить? 🤯

Курсы, книги, менторство, pet-проект, сложный проект на работе:

🤍Курсы. Дорого и эффективно. О курсах, которые для меня покрыли бОльшую часть тем System Design, расскажу в будущих постах
🤍Книги. Углубляют знания, полученные на курсах. Мне помогли Крис Ричардсон «Паттерны микросервисной архитектуры» и Алекс Сюй «Прохождение сложного интервью по System Design», о которых я уже писал
🤍Менторство. Хороший способ выявить пробелы и восполнить знания – проверено
🤍Pet-проект. Лучший способ попробовать все технологии и инструменты. И благодаря ИИ это будет не так сложно
🤍Сложный проект на работе. Это как кидать ребенка в воду, чтобы тот научился плавать

—————

💡 Если тоже хотите начать изучать архитектуру – сохраняйте пост себе, чтобы не потерять

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

#полезное_системный_анализ

Путь до архитектора. Часть 2 🚀

Первая часть тут. Во второй – список годных книг по архитектуре в желаемом порядке чтения 📚

📌 Забирайте себе, чтобы не потерять

🤍Погружаемся в архитектуру

В целом о том, что такое архитектура и для чего нужна:

🤍«Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы»: Нил Форд, Марк Ричардс

🤍 Знакомимся с типами архитектуры и распределенными системами

Подробнее про типы архитектуры: монолит, микросервисы

🤍«Распределенные системы. Паттерны проектирования»: Брендан Бернс
🤍«От монолита к микросервисам»: Сэм Ньюмен
🤍«Создание микросервисов»: Сэм Ньюмен

🤍 Углубляемся в корпоративные приложения и интеграции

Некоторая информация в этих книгах устарела, но они такие же классические, как Вигерс:

🤍«Шаблоны корпоративных приложений»: Мартин Фаулер
🤍«Шаблоны интеграции корпоративных приложений»: Хоп, Вульф

🤍Думаем о будущем

Важная книга о том, почему архитектура должна быть эволюционной (то есть адаптироваться и меняться со временем):

🤍«Эволюционные архитектуры. Поддержка непрерывных изменений»: Нил Форд, Ребекка Парсонс, Патрик Куа

🤍Глубже изучаем модели данных

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

🤍«Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем»: Эрик Эванс
🤍«Изучаем DDD предметно-ориентированное проектирование»: Влад Хоронов

🤍Собираем все в кучу

🤍«Высоконагруженные приложения. Программирование, масштабирование, поддержка»: Мартин Клеппман

🤍А как же поддержка?

Следующие книги – про релизный цикл, доставку обновлений, поддержку систем, CI/CD и все такое:

🤍«Site Reliability Engineering». Надежность и безотказность как в Google»: Байре, Джоунс, Петофф
🤍 «Release it!! Проектирование и дизайн ПО для тех, кому не все равно»: Майкл Т. Найгард

🤍Про масштабирование и нагрузку

🤍«Масштабирование приложений. Выращивание сложных систем»: Ли Атчисон
🤍«Паттерны Kubernetes: Шаблоны разработки собственных облачных приложений»: Билджин Ибрам, Роланд Хасс

🤍Облака

Сложная и специфичная тема с облачными решениями, особенно востребованная в международных проектах

🤍 «Шаблоны проектирование для облачной среды»: Корнелия Дэвис

––——–––

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

#книги_системный_анализ

Путь в архитекторы. Часть 3 🚀

Всех с пятницей и хороших выходных! 🌴

Это заключительная часть серии постов про архитектуру (часть 1, часть 2). Расскажу про виды архитекторов в IT, что я сделал по плану и что еще предстоит

Архитекторы в IT 📌

Рассмотрим, какие есть архитекторы в IT, на примере строительства города

🤍 Корпоративный архитектор (Enterprise Architect)

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

В IT такой человек занимается архитектурой всей компании/предприятия, которая состоит из множества решений. Вовлечен в бизнес-процессы и общается с топ-менеджерами, практически никогда не работает с кодом

🤍Архитектор решений (Solution Architect)

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

В IT архитектор решений занимается конкретным проектом (или проектами): собирает требования и подбирает технологии, платформы, сервисы для реализации. Редко вовлечен в код, больше работает с технологиями и проектированием

🤍Системный архитектор (Software Architect)

Отвечает за сложные системы внутри каждого дома: вентиляция, электроснабжение, лифты, отопление. Гарантирует, что все работает надежно и эффективно

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

Куда расти системному аналитику? 🤔

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

🤍Solution Architect – наиболее частое мнение. Они тоже собирают требования, моделируют и проектируют, но более технически подкованы и смотрят на систему шире. Желательно, но не обязательно, уметь программировать
🤍Enterprise Architect – путь для «стратегов», кого интересует «большая картина». Такие архитекторы более погружены в бизнес-часть и понимают, как архитектурные решения влияют на всю экосистему компании

А Software Architect, на мой взгляд, наиболее подойдет для разработчика, а не СА

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

Мои мысли 💡

Обо всем этом я начал задумываться год назад, когда стал Senior. Прошел несколько курсов и прочитал несколько книг, что покрыло бОльшую часть тем по System Design из первой части

Недавно прошел тестовое интервью по System Design с ментором-архитектором. Ментор оценил мои знания как очень неплохие. По его оценке, уже через полгода могу претендовать на роли в архитектуре

Правда, я в этом сомневаюсь, у меня немного другой план:

🤍Поработать с высоконагруженным проектом с микросервисной архитектурой
🤍Брать сложные задачки с принятием решений
🤍Прочитать хотя бы 50% из списка книг из второй части
🤍Прокачать софт-скиллы
🤍Написать pet-проект а-ля Социальная сеть и пощупать разные технологии (особенно темный лес DevOps)

Без спешки и непредвиденных обстоятельств оцениваю переход в 1.5-2 года. Причем не могу сказать, каким хочу быть архитектором – пока у меня только самурайский путь без цели

——

Если посты на этой неделе были полезны, ставь 🔥

И как вы думаете, куда логичнее расти системному аналитику? Или may be свой вариант?

#полезное_системный_анализ