Менеджмент

Привет, Хабр! 

Сегодня я пришел с небольшими спойлерами из новой серии нашего подкаста «Скрамное ИТ». В свежем выпуске мы залезли в одну из самых неудобных тем — тот момент, когда задачи, которые еще вчера вдохновляли, вдруг начинают вызывать тоску, и когда возникает желание сделать CTRL+Z… в карьере. 

В новой серии мы, три айтишника с разным опытом (и разной степенью цинизма), разбираем, что же делать, когда карьера пошла не по тем рельсам. 

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

Но прежде чем радикально что-то менять, стоит разобраться — это профессиональный тупик или запрос на развитие? Например, желание перейти в менеджмент может быть как искренним стремлением к росту, так и попыткой убежать от надоевшей рутины. 

Кстати, о менеджменте. Казалось бы — карьерный рост, новые горизонты. Но почему тогда столько технических специалистов, сделавших этот шаг, тоскуют по временам, когда все, что от них требовалось, — писать код (желательно хороший)? Когда не было бесконечных митингов и сложных решений… И вот возникает вопрос: «А не зря ли я променял интересные задачи на тонны отчетности и погоню за KPI?». 

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

Привет! Меня зовут Елена Тупикова, я академический руководитель программы онлайн-магистратуры «Управление IT-продуктами» от Яндекса и МФТИ. В этой статье я расскажу, чем занимается продакт-менеджер в IT и для чего ему нужно разбираться в базах данных, языках программирования и машинном обучении. А ещё дам список технических навыков, которые нужны продакт-менеджеру для работы в IT.

Вы «должны» проводить 1-on-1.
А зачем?

Знаете, зачем они нужны — по-настоящему?
Или пробовали, но всё свелось к «ну, как дела?»
Может быть, встречи идут — но ничего не меняется?

Что ж, давайте разбираться:

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

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

Мир меняется. Мы чувствуем тенденции на себе. Больше информации, больше логики, больше конкуренции, больше комплексности, больше правил, больше автоматизации, больше контекста, больше скорости… 

У нас был опыт работы с Lean, Kanban, CPM/CCM, Waterfall, PMBOK, Six Sigma, Scrum, Agile, OKR+Product Discovery, GIST Planning, включая их вариации и гибриды. Некоторые – мы ценим и применяем сейчас. И тем не менее, спустя 15 лет в проектном и операционном менеджменте мы по себе знаем о чем все также плачут проджекты, продакты и управленцы. О большей точности, координации, информации, взаимодействии и сроках. 

Нам понадобилось время по-новому осознать казалось бы простую идею, о которой чуть ниже. Проекты, как и компании в целом – это ресурсы направленные на достижение целей. Время, люди, информация – ресурсы, но сами по себе они не равны достижению целей. Ценность ресурсов – в их связях и взаимодействии. Связь и взаимодействие ресурсов – краеугольный камень в достижении целей. Это и есть идея Cоntext.

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

На днях я прочитал на Harward Business Review материал «Оценка эффективности: предостережение руководителям» и был потрясён. Публикация стала результатом исследования общепринятого способа ранжирования и вознаграждения сотрудников на основе результатов их работы. Речь идёт про тот самый метод, разновидности которого в разное время применялись в известных компаниях: Google, Microsoft, Facebook, Яндекс, ВК, Авито и других.

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

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

Я собрала ресурсы, которые прошли проверку на bullshit, на соотношение времени/усилий к пользе и на актуальность ко всему, что происходит на рынке. 

Итак, если вы IT менеджер и собираетесь работать по-английски, то вам нужны ресурсы, которые подготовят вас

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

б) к самой работе: постоянному проблем-солвингу, убеждению, уточнению, нюансированию, реагированию. Это решается знанием слов: как что называется, как что расшифровывается, какими глаголами описывается изменение, падение, рост, как формулируется запрос, отмена, и проч.

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

На чем я советую сосредоточиться, чтобы не распыляться и бить точно в цель: 

I. Видео с Mark Rose

Марк 20 лет проработал продаком в гугл, сейчас он консультирует стартапы. Его видео можно найти на нескольких платформах в Youtube, в том числе и у него на сайте в разделе Watch and Learn. Он человек своей среды: эксперт из Силиконовой Долины, но без токсичной позитивности и воды, плюс с большим опытом работы в Европе, в том числе в постсоветских странах. В частности, одним из клиентов его собственного стартапа в свое время были World of Tanks. Марк провел какое-то время в Минске и работал с командой. Во-первых, Марк дает отличные советы по прохождению всех этапов интервью. Во-вторых, обратите внимание, как он пользуется английским языком: на простоту словаря и при этом точность и гибкость формулировок.

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

Иногда в команде появляется человек, про которого сложно сказать, чем он вообще занимается.
Он вроде не пилит фичи. Не закрывает таски с горящими дедлайнами. Не устраивает эффектных демо.
Но при этом он всегда рядом...

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

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

Когда вы слышите «облачный провайдер», что первое приходит в голову? Компания, которая предоставляет виртуальные ресурсы и с которой приходится разговаривать строго по шаблону? Но чтобы решения действительно работали, нужен не поставщик, а партнёр — тот, кто погружён в вашу инфраструктуру, анализирует, советует, помогает.

Мы в K2 Cloud не всегда были такими. Наш путь начался более 15 лет назад, и сначала мы были просто провайдером. Но время, опыт и сотни проектов изменили всё: мы прошли путь от первого ЦОДа до облачной платформы собственной разработки с партнёрскими услугами под любой запрос бизнеса. И сегодня я расскажу, как это было — без маркетингового шума, просто как есть.

Меня зовут Кирилл Бойко, я технический директор K2 Cloud, и в облаках (в хорошем смысле) — давно.

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

Привет! Меня зовут Андрей, я технический директор в компании КЕДР Solutions. Мы занимаемся контрактной разработкой электроники и программного обеспечения. “Рисуем” платы и кодим уже больше 10 лет! 

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

До 2022 года я думал, что автоматизация — это удел только крупных компаний. Но в 2022 году я открыл для себя n8n, и всё изменилось. Теперь я автоматизирую рутинную работу, отчёты и даже целые бизнес-процессы — иногда менее чем за 30 минут. Вот как это работает, что меня удивило и что вы можете попробовать уже сегодня.

Как мы снизили расходы на экспресс-доставку в Яндекс.Доставке на 13% и не потеряли в качестве

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

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

Вы наверняка замечали, что в начале общения ИИ кажется очень толковым и понятнливым, правда почему спустя 10-20 сообщений начинает путаться, повторно совершить те же ошибки которые уже совершал или выдавать рассчеты с ошибками. Это не случайность, а следствие мироустройства. Давай разберемся почему это происходит и как именно ИИ все “помнит” и почему его память устроена иначе чем у человека.

Сейчас я активно нанимаю ПМ-ов и на собеседования приходят совершенно разные кандидаты. Половина из них — зумеры. Если описать этот тип соискателя через призму характеров моих любимых персонажей, то это был бы Крош. 

В статье поделюсь статистикой с сотни собеседований и расскажу, почему Ёжик никогда не уходит без оффера, в чём вы должны соответствовать Совунье, чтобы взять её на работу, и почему в моей команде нет Кар-Карыча. А Крош есть.

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

Если вы хоть раз были на стороне бизнеса, наверняка слышали (или говорили):

Сколько можно делать такую простую штуку?; Они что, не понимают, как это важно?

Но тут надо смотреть шире...

Привет Хабр! Меня зовут Олег, я являюсь действующим QA Engineer в компании Intelsy. Это моя вторая статья после этой (тут могла бы быть ваша реклама), уж очень понравилось делиться информацией и получать обратную связь от читателей! Статья для тех, кто хочет улучшить процессы поставки кода в прод или понять, где можно сэкономить время! Постараюсь немного раскрыть эту тему, поделиться своим мнением (которое ни в коем случае не претендует на звание "истина в последней инстанции"), и да, по традиции помним "у каждого своя кухня". Надеюсь прочтение будет интересным и полезным!

В современных IT-командах границы между ролями стираются: разработчики пишут тесты, DevOps внедряют мониторинг, а тестировщики всё чаще участвуют в процессах, выходящих за рамки классического QA. Один из самых спорных вопросов — должен ли QA инженер заниматься релиз-менеджментом?

Некоторые компании нанимают отдельного релиз-менеджера, другие доверяют этот процесс DevOps, но всё больше организаций приходят к выводу, что именно QA инженер — лучший кандидат на эту роль (Так собственно все работает и у меня на проекте).

 В этой статье мы разберём:

· Почему QA идеально подходит для управления релизами?
· Плюсы и минусы
· Как внедрить релиз-менеджмент в обязанности тестировщика
· Почему отдельная роль релиз-менеджера часто избыточна
· Какие инструменты и метрики использовать для успешного контроля выпусков

 1. Что такое релиз-менеджмент и почему QA должен в нём участвовать?

Релиз-менеджмент — это комплекс процессов, связанных с планированием, подготовкой и развертыванием новой версии продукта. Он включает:

Мы думали, что франшиза — это готовые процессы, окупаемость – 10 месяцев и работа под сильным брендом. Недавно я подбил все цифры и решил рассказать, как все вышло на самом деле. А еще я посчитал себестоимость батона, эклера и сосиски в тесте.

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

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