diva в dev-e

Дайджест постов про карьеру Здорово, когда эксперты делятся материалами коллег, так можно получить максимум пользы - через перспективу и опыт других профессионалов в отрасли. Сегодня в моей подборке посты про то, как успешно начать карьеру в IT и наращивать свою экспертизу. О начале карьеры в IT: ❤️ Стратегия входа в IT из 5-ти шагов без излишних сложностей и overthinking. ❤️ 5 вещей о работе в IT, которые лучше знать в самом начале карьеры. ❤️ Какие вопросы задать на собеседовании, чтобы попасть на работу мечты. ❤️ Почему крутые спецы куда чаще встречаются с выгоранием и как его предотвратить. По специальностям: ❤️ Как стать хорошим продактом в любых условиях, даже в компаниях со слабыми продуктовыми процессами. ❤️ Подборка курсов для начинающих программистов (гуманитарии-friendly). ❤️ Подборка полезных материалов для QA ❤️ Где учиться и какие курсы проходить по дизайну ❤️ Книги, дающие хороший кругозор в IT - от Big Data, программирования, до UI/UX.

Как управляют в ИТ? ч.2 В предыдущем посте мы обсудили особенности директивного и недирективного управления, большинство проголосовали за то, что в ИТ наиболее распространен недирективный стиль. Это совпадает и с моим опытом, в моих командах он всегда превалировал, и вот почему: ❤️в основе методологии agile, которую все шире используют в разработке - идея автономной кросс-функциональной команды, способной декомпозировать и решить задачу без менеджера с указкой. Отсюда базовое требование - самостоятельность членов команды и навык целиком вести свой кусок работы.

В одной компании, мне удалось застать внедрение Agile с нуля. Дело было в аудите - сфере весьма иерархичной. Главные вопросы были - «кто теперь начальнике-е» и «как руководить командой без формальной власти», в итоге коллеги старались получить титул scrum-мастера, ведь его роль - наиболее близкая к менеджеру проекта.

❤️необходимость работать в условиях неопределенности - любая задача требует декомпозиции, ресерча, анализа альтернативных решений и выбора оптимального. И важно уметь прочертить этот путь к решению в условиях, когда некому дать четкие инструкции - как. ❤️gap (разрыв) между бизнесовой стороной продукта и его технической реализацией - часто стейкхолдеры со стороны бизнеса имеют весьма опосредованное представление о том, как все работает «под капотом». И задача команды разработки - закрыть этот gap - разобраться, что именно нужно бизнесу, и предложить грамотное техническое решение.

Как итог, пара уточняющих вопросов стейкхолдерам - и вот вы уже на пару с продактом в середине discovery.

❤️широкий стек и on-going развитие технологий заставляют постоянно разбираться в новом. Менеджер может стараться держать руку на пульсе, но один за всем не поспеет так, как это сделает команда. ❤️высокие доходы двигают ИТшников выше по пирамиде Маслоу, заставляя больше задумываться о самореализации в работе. В результате, мало повышать ЗП, им хочется от работодателя индивидуального плана развития, карьерного коучинга и регулярных 1-на-1 встреч. А какой стиль управления используется на ваших проектах?

Какой самый нелепый полет у вас был? Я начну, мой - у Ryanair. Авиакомпания позаботилась о том, чтобы загрузить на борт все виды туалетной воды - кою настойчиво продавали во время полета (кто вообще покупает парфюм в самолете? господа продакты в канале, нужен ваш проф. взгляд на аудиторию и use-кейсы) - но вот, увы, забыли прихватить обычную воду на 4х-часовой перелет. В меню - фанта/кола, как в загадке о двух стульях. В финале подкинули еще кринжа - после приземления заиграл бравый мотив в духе «мы все выжили 💪» (см. видео), приправленный гордым, хоть и трудноразличимым, слоганом. Мне слышится «Ryanair - no air» (что соответствует действительности).

Как управляют в ИТ? ч.1 Недавно я наткнулась на термин недирективное управление и задумалась о том, как управление строилось на моих проектах. Но сперва к терминам, итак директивное управление подразумевает раздачу прямых указаний сотрудникам что и как им делать. Решения принимаются лидером и контроль их выполнения лежит на нем же, ввиду чего он становится «узким горлышком» и незаменимым звеном. Если это звено отправить в отпуск, все посыпется: велик шанс, что подчиненные сами не разберутся, что делать (если им, конечно, предварительно не дать подробных указаний на эту неделю-две). Тем не менее, этот стиль лучше всего себя показывает в ситуациях: ❤️горящих дедлайнов - когда нет времени мусолить альтернативные идеи, надо делать. ❤️на фабриках - когда есть четкая технология и меры по технике безопасности. ❤️с junior-коллегами - неопределенность в сложных задачах их может пугать и только демотивировать, а вот понятные инструкции дадут +100 к уверенности в своих силах. ❤️в критичных ситуациях - когда нужно быстро принимать решения, которые вне компетенции рядовых сотрудников. недирективное управление помогает построить более автономную команду, способную действовать в условиях неопределенности и принимать собственные решения. Такой подход сфокусирован на индивидуальном развитии сотрудника - личная ответственность и свобода решений вместо четких инструкций. Звучит бомбически, не правда? А в чем подвох? Для недирективного управления нужны предпосылки: ❤️мотивация сотрудника - если он не хочет развиваться и брать ответственность, то с него уж взятки гладки 💍 ❤️безопасная среда - если каждое смелое предложение менеджменту - это «игра на вылет» или в целом токсины in the air, проявлять инициативу вряд ли захочется. ❤️фокус на сотруднике - его цели, стремления, как он сам видит свое развитие? Используются коучинговые методики, когда менеджер, задавая правильные вопросы, помогает сотруднику самому прийти к решению. ❤️обоюдная готовность к переменам - развитие команды требует сил и времени, к чему любой из участников может не быть готов в данный момент. Как думаете, какой стиль управления превалирует в ИТ и почему?

Fight or flight в офисе Как часто наши неосознанные реакции, рефлексы и эмоции, эволюционно призванные нас защитить, мешают жить той жизнью, которой мы хотим. Особенно они проявляются в стрессовых ситуациях, при выходе из зоны комфорта, в которой коучи по личностному росту обещают нам тот самый «рост и масштаб».

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

Хорошая новость состоит в том, что этот порочный круг можно разорвать. И первый шаг к этому - начать отслеживать свои реакции. Мне нравится терминология «бей или беги» (или «замри»), введенная Уолтером Кенноном для описания реакций на стресс. Причем, часто у человека превалирует одна из них. Думаю, вы замечали в своем окружении этих супергероев, которых адреналин заставляет собраться, ринуться в бой, и все зарешать будто играючи. Такой реакции fight можно только позавидовать 🥲 Я же за собой куда чаще замечаю «замри» (до онемения в теле и зажима в горле) или «беги» - когда на работе все пригорает, я отвожу душу просматривая вакансии в LinkedIn Jobs или ищу как выйти в окно отпуск ASAP. Так и получилось, что я сбегаю на уикенд в Париж 😅 Жду посадку, предвкушаю свежий круассан на завтрак и радуюсь, что моя работа таки дает возможность вот так спонтанно от нее уехать 😄 Пока я отдыхаю и практикую slow posting, хочу поделиться своими любимыми каналами девушек-айтишниц, сама я вдохновляюсь их опытом развития карьеры в разработке и продукте, и узнаю, как зарешивать различные вопросы так, чтобы стрессовать не пришлось 🤝 Добавляйте папку и наслаждайтесь ежедневной порцией вдохновения и пользы. А как вы реагируете на стресс? И как преодолеваете его?

Куда делись все проджекты в Big Tech-e? В далекие времена моей работы в аутсорсе, мне казалось, что роль project-а не заменима. Ведь кто еще бы смог менеджить весь цикл проекта - от kick-off встречи с заказчиком до приемки-сдачи, прорываясь через горящие дедлайны и утрясая конфликты в команде, у которой тоже от всего периодически пригорает? Затем я перешла в продуктовую разработку и сменив 3 компании в Big Tech-e, я так и не встретила ни одного project-а. Такой роли у нас попросту нет. Куда же она делась? Разделилась и трансформировалась в: ❤️ «трушных проджектов» - этих ребят я искала днем с огнем и нашла в отдельном департаменте, с которым мы лишь изредка пересекаемся. Они планируют и запускают проекты с 0 до MVP/MLP, а дальнейшее развитие продукта передают уже в руки delivery manager-ов (они же - engineering manager-ы). ❤️delivery manager-ов - вот они уже day-to-day менеджат команду разработки, приоритизируют задачи, находят нужные ресурсы, убирают блокеры - в общем делают все для масштабирования продукта. В чем плюсы такой трансформации и как стать успешным delivery-manager-ом - можете узнать в интервью с Артемом Арюткиным. Артем - директор по технологическому развитию в Сбере и на своем канале он рассказывает о том, как резал монолит СБОЛ, повышал надежность платформы для масштабирования с 10 до 79 MAU, и как строит эффективные процессы и команды. Рекомендую подписаться, если вам так же как и мне интересна тема delivery-management-а. А у вас в компании есть проджекты? Какая у них зона ответственности?

Как вывезти конфликты и переговоры и выйти из них победителем? Вчера прошло завершающее занятие курса по коммуникации, ради которого я вставала в пущую рань по субботам вот уже 3 месяца 😬 (но я сама вызвалась в это время, так что не пристало жаловаться 🤪) Курс вел Марат Айрапетян, преподаватель по переговорам в ВШЭ и Сколково, а еще космический инженер с 5-летним опытом работы в Роскосмосе. С Маратом я познакомилась еще 2 года назад и тогда меня поразила история с одного из его публичных выступлений. Вот представьте, полный зал на 200+ человек, все смотрят на вас. Вы выступаете с темой, которую старательно готовили. И тут выкрик из зала:

Ну какой же бред! А вы точно эксперт в теме?

Ваша реакция? Игнорировать выкрик? Съязвить? Начать оправдываться? Тогда Марат ловко отработал манипуляцию. Я же была уверена, что в такой ситуации растеряюсь. А недавно похожий кейс произошел на моем выступлении… и я таки смогла сориентироваться 🤩 Курс был объемный, инсайтов море. Делюсь некоторыми из них: 1️⃣ Конфликты и переговоры - это не поле боя, где соперник унижен 😁, а победителю все лавры. Наоборот, это про сотрудничество, где идеальный итог - когда каждый достиг своей цели (win-win), и вы сохранили отношения. 2️⃣ Работа с эмоциями собеседника - первый этап любого конфликта. Невозможно переходить к рациональным аргументам и вообще стараться о чем-то договориться, пока человек еще находится в «эмоциональной плоскости». 3️⃣ При отстаивании своих границ важно соблюдать итеративность, т.е. постепенно переходить по следующим стадиям защиты: ❤️работа с эмоциями (вдруг человек нарушил границы неосознанно, из-за эмоций) ❤️обозначение своих границ (мягкое) ❤️защита границ (уже более твердое воздействие с большим шансом на ухудшение отношений) ❤️эскалация или сепарация (сюда же входят и просто «позже поговорим», и разрыв отношений) Важно дать человеку право на ошибку и возможность ее исправить. 4️⃣ По сути, конфликт - это нападение на границы или социальную роль.

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

Если подобную нападку не обработать и не «выровнять свою роль», то она может закрепиться и к вам начнут относиться именно так 😐 Поэтому важно отслеживать изменение соц. ролей в моменте и уметь их восстанавливать. 5️⃣ Для успешных переговоров важно выяснять «картину мира» собеседника - какой у него взгляд на проблему, цели, вводные… Иначе вы будете как 😶 тыкаться наугад, что уж точно не укрепит вашу позицию. Это можно сделать задавая вопросы. Причем, и для выяснения («как ты на это смотришь?»), и для верификации («я правильно поняла, что для тебя наиболее важно то и то?»). 6️⃣ Итеративность важно так же соблюдать и в переговорах. Не нужно пытаться закинуть сразу все 3-5-6 вопросов, которые вы хотите обсудить, потому что собеседник сразу зацепится за тот, который наиболее удобен ему. Лучше идти поочередно, начиная с самого важного. Когда пришли к соглашению по нему - переходите к следующему. 7️⃣ Любую проблему можно рассматривать в разных плоскостях - юридической, финансовой, этической и т.д. Если ваш собеседник говорит об этической стороне вопроса, а вы в ответ закидываете финансовые аргументы, вы будете выглядеть меркантильно и в целом жалко. 8️⃣В переговорах важно держать в голове «точку 0» - что будет, если мы не договоримся. Это поможет в ситуации, когда вас пытаются продавить на невыгодные вам условия. Вдруг, ситуация «не договориться» заведомо проигрышная для вашего парнера, а вы наоборот ничего не теряете. Но в моменте при давлении вы можете растеряться, если четко этого не осознаете и не держите это в голове. Если вам тоже интересна тема коммуникации, искренне рекомендую подписаться на канал Марата. У него куча полезного контента. А у вас возникали сложные или конфликтные ситуации на работе? Как вы с ними справлялись?

Как ловить прод, если он падает - ч.2 Сейчас сижу, пишу отчет по новому инциденту (IR - incident report) 😬 и думаю, что самое время закрыть тему, которую мы уже начинали обсуждать в этом посте. Тогда я рассказывала о том, как готовиться к инцидентам в ИТ сервисах (н-р «пользователи не могут залогиниться», «курьерам не показываются новые заказы в приложении» или же просто «запросы стали обрабатываться недопустимо долго»). Сейчас обсудим, как действовать во время - куда бежать, что делать, и как при этом не чувствовать себя 🐶 Итак, вам пришло уведомление о том, что что-то не работает. 1️⃣После того, как вы подтвердили получение уведомления, проверьте источник - если его вручную создала операционная команда, свяжитесь с ними за деталями. Также, они помогут оценить ущерб и blast radius - согласитесь, "ухудшился пользовательский опыт" для 0.001% пользователей и "отпал целый регион" - совсем разные проблемы, и реагирование будет отличаться. Часто есть позыв пропустить этот этап, но так не надо.

Мы так как-то решили, что проблема не критична и ушли в воскресенье отдыхать. Как итог - продолжительность инцидента 31 час и десятки тысяч $ потерь обнаруженных постфактум 🙄

2️⃣С поправкой на потенциальный ущерб определите состояние приложения, обычно выделяют: - operational (работает) - degraded performance (опыт пользователя ухудшен, но основные сценарии работают) - partial outage (часть важного функционала отпала) - major/full outage (все очень плохо) Эскалируйте инцидент согласно вашей оценке. 3️⃣Локализуйте проблему - постарайтесь определить, в вашем ли она сервисе, если есть подозрение, что нет, добавьте соответствующие команды как responder-ов, чтобы они подключились и проверили свои зоны ответственности. 4️⃣Сфокусируйтесь на том, чтобы "оживить прод" (англ. to stop bleeding) - проверьте, какие были последние изменения, имеет ли смысл их откатить и т.д. Детально исследовать, что именно привело к инциденту можно уже после - когда проблема решена. 5️⃣Если все вроде разрешилось - продолжайте мониторить и составьте postmortem (он может выглядеть как тот incident report, который я сегодня пишу): ❤️оцените точный ущерб, ❤️проанализируйте, почему же так произошло (мы используем технику 5-whys), ❤️опишите action-поинты и в какие сроки они должны быть закрыты. 6️⃣Мы презентуем эти отчеты на еженедельной встрече, где можно эскалировать менеджменту какие-то action point-ы при необходимости. Что делают в это время менеджеры и аналитики? ❤️помогают связаться со стейкхолдерами (чтобы те были в курсе происходящего и могли со своей стороны что-то сделать - н-р, включить fallback) или нужными командами разработки ❤️смотрят на метрики и помогают оценить ущерб и в целом состояние приложения ❤️эскалируют Что еще почитать по теме? - DH Reliability Manifesto - Создание SRE культуры чтобы предотвратить потерю 12mln $ - Как Ozon работает с упавшим продом Расскажите, вам доводилось быть участником/наблюдателем/сочувствующим на инциденте? Тем временем, на канале новая аватарка, не теряйтесь 👋

Мы выписали коллег из Барселоны, сделали работающий MVP и победили в хакатоне 👆саммэри последних двух дней. Это первый раз, как я участвую в хакатоне, который компания организовывает для своих внутренних сотрудников. Мне всегда казалось, что эти хакатоны - попытка сделать нечто на коленке, без адекватного discovery и понимания, как это потом пришить к бизнесу. В общем, то, что потом с должным ускорением полетит в трубу 😐 Тем не менее, в этот раз по качеству проработки тем и понятному roadmap-у - как их доработать и пустить в бизнес - который представили команды, я чую мощный выхлоп от этих двух дней. Моя команда вообще сделала интеграцию, которую в других условиях мы планировали бы месяц и после делали столько же. Так что мой вердикт: не зря отрывали 30 человек от праведных дел работы и везли испанскую команду в Берлин 👌 В этот раз решали одну из ключевых задач в логистике - дисбаланс спроса (заказы пользователей) и предложения (курьеры, готовые эти заказы развезти). Эта проблема особенно остра во время пика спроса, когда курьеров не хватает - что называется fleet saturation. Эта задача решается комплексно на разных уровнях и обычно задействует много доменов в продукте. Вот хороший пример одного из возможных решений - от Яндекс.Еды. Мы же в эти дни нагенерировали еще ряд других, которые, вероятно, +-скоро воплотятся в наших брендах доставки по миру. А вы участвовали в хакатонах от компаний? Видели от них какую-то пользу?