⚡️ Всем привет! Сегодня в гостях у OTUS News Антон Губарев — руководитель буткемпа “DevOps”.
Поговорили с Антоном о том, какие требования предъявляют работодатели к роли техлида.

Для многих инженеров техлид — желаемая и почетная должность. Это признак высокой квалификации и доверия со стороны руководства, а также возможность оказывать максимальное влияние на продукт и технические/архитектурные решения. Приятным бонусом станет и более высокая зарплата. Однако техлид — это еще и высокий уровень ответственности и большое количество предъявляемых требований и обязанностей.

Я несколько лет работал в роли техлида и в роли архитектора, и в этом посте собрал для вас основные требования, которые предъявляют работодатели для этой роли:

✔️ Автономность. Вам можно поручить задачу/проект и быть уверенным, что все будет доведено до конца без пинаний и контроля, даже если потребуется подключать другие команды и организовывать людей.
✔️ Ориентация на бизнес-результат. В первую очередь надо понимать, какую пользу для бизнеса принесет ваше решение. Нередко для этого необходимо срезать углы в технических решениях. А по окончании задачи/проекта самостоятельно убеждаться в достижении цели.
✔️ Коммуникабельность. Для техлида нет понятия «это их недоработка/проблема». Для реализации проекта часто будет требоваться договориться с другой командой или отделом о внесении нужных вам правок, в идеале без привлечения вышестоящего руководителя. А иногда и внутри своей команды надо проявлять умение убеждать.
✔️ Высокая квалификация. Умение выбрать и спроектировать наиболее подходящее решение, нарезать на этапы, при необходимости провести исследование, и, конечно, аргументированно донести все это до команды.

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

#expert

👋 Всем привет! Сегодня в гостях у OTUS Илья Прахт — опытный менеджер в IT, консультант и тренер, автор телеграмм-канала Седой Директор, а также руководитель курсов Delivery Manager, COO и преподаватель курсов TeamLead и Senior Product Manager в OTUS.

Поговорили с Ильей про инструменты аудита команды — как понять, на что способна ваша команда, какие у нее есть проблемы, и как добиться эффективности в ее работе.

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

Итак, есть команда. Она есть, что называется AS IS, и с ней нужно как-то работать. Какой линейкой можно ее измерить, чтобы это информация была хоть сколько-нибудь полезной?

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

💁‍♂Начнем со второго – с сотрудника. У сотрудника есть 3 основных параметра, с которых следует начинать:

1. Компетенции – понять, что он умеет, и какого качества и количества работы от него ожидать. Хорошо помогают здесь матрицы/карты компетенций и некий ассессмент по этой матрице. Лучше варианта я и не знаю.

2. Мотивация – ради чего сотрудник будет работать хорошо. Мне нравится здесь модель Герчикова. Она относительно простая, но очень наглядная. Понимая истинную мотивацию, понимаешь, как сотрудником управлять.

3. Психотип – как сотрудник будет работать и какого поведения от него ожидать. Хорошим инструментом является DISC. Да, он простоват, но зато понятный и наглядный.

Важно! 📎 Прям обращаю внимание! Все 3 типа инструментов (да-да, даже матрица компетенций!) – это упрощенные модели. Не бывает одного ярко выраженного типа, всегда есть комбинация: и в психотипах, и в мотивации, и в компетенциях. Поэтому и использовать эти инструменты нужно как некоторую базу, которую потом нужно натягивать на реальных людей. Как ту самую сову на ту самую уменьшенную модель мира.

✊Теперь про команду. Здесь есть 4 основных параметра, характеризующих команду:

1. Общая цель – куда и ради чего команда идет. Плохо, если цели нет. Лучше, если она есть, но не та, что нужна бизнесу. Ну и хорошо, когда и бизнес и команда смотрят в одну сторону. Неплохой инструмент придумал Стратоплан и обозвал его Мамонт. Цель должна выглядеть, как мамонт, которого нужно всем вместе завалить, чтобы утолить голод и обогатиться рогами и шкурами.

2. Командная динамика – в каком состоянии находится команда. Пресловутые шторминги, норминги, перформинги по Такману. Для каждого этапа свои подходы и инструменты, путать не стоит.

3. Закрытость команды – какие у команды внешние границы, насколько она открыта для взаимодействия и коммуникаций наружу. Модель Берна с ее кружками хорошо иллюстрирует эту идею.

4. Роли в команде – какие роли есть, каких не хватает, каков баланс/перекос на данный момент. Неплохо роли описал Белбин (подробнее можно прочитать в моей статье на Хабр). Есть еще модель Бенна и Шитса, направленная больше на выявление деструктивных ролей, но тоже полезно.

Вот такие 7 основных параметров и 7 основных инструментов, которые сильно помогают в аудите команды. Есть много других, не менее полезных. Но начать можно с этих 7 – они дают полную и комплексную картину, кто перед вами, что может ваша команда.
👊 Удачи в работе с вашими командами!

#expert

⚡️ Всем привет! 👋
Сегодня в гостях у OTUS News наш преподаватель Александр Миленькин — Team Lead Machine Learning Engineer в компании Dodo Brands, автор телеграмм-канала Data Feeling, а также преподаватель курсов ML Advanced/Basic/Professional в OTUS. Kaggle Expert.

Поговорили с Александром про три неочевидных цель ML «фичей» в сервисе ⬇️

***
Фича — это, по сути, какое-то новое решение, которая делает ваш сервис лучше. Например, рекомендательная система или любая другая система персонализации.

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

Вот два неочевидных слушая, когда после A/B теста имеет смысл выбрать ML модель, которая проигрывает по принесенной прибыли.

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

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

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

Конечно, в зависимости от сервиса и политики компании, решения по выбору итоговых ML моделей могут быть иными. Приведенные выше примеры позволяют мыслить стратегически. А вообще, это все очень короткие выжимки из теории A/B тестирования и продуктовой аналитики.

#expert

👋 Всем привет! Сегодня в гостях у OTUS Светлана Черникова — бизнес-тренер, консультант по выводу на рынок IT-продуктов, автор канала «Давайте уже запускаться» и руководитель курса Product Marketing Manager в IT в OTUS.

7 СМЕРТНЫХ ГРЕХОВЪ ПРИ ЗАПУСКЕ ПРОДУКТА

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

🤑 Чревоугодие: не жалейте денег, чтобы казаться суперуспешным и сделать идеально вылизанный продукт — он должен выглядеть дорохо и быть роскошен, как Линда Евангелиста на обложке Vogue. Ведь людям важна красота и эстетика, а не польза и актуальность.

😠 Зависть: ваши конкуренты стали успешными благодаря шаману/вспышке на Марсе/25 кадру. Вы точно-преточно лучше, поэтому поднимите правую руку вверх и махните на них хорошенько, упаси бог ещё изучать, что они там делают.

😡 Гнев: вы имеете полное право злиться на ваших клиентов, которые никак не могут разобраться в вашем очумительном продукте. Вы ведь так для них старались: запилили блокчейн, подключили искусственный интеллект, добавили 3D-аватары… Простота — она же для бедняков, а у нас тут такой супер-пупер, что даже в 10 абзацах его не опишешь.

💃 Блуд: будьте всегда впереди — придумайте себе ещё один проект и начните заниматься им параллельно. А ещё обязательно меняйте гипотезы во всех проектах как только, так сразу. Что-что, не окончили проверять ещё прошлые? В топку, часики-то тикают.

🤷‍♀️ Жадность: экономьте на персонале. На рынке полно «сеньоров» с международным опытом, и это недорого. Перед сном представляйте, как они с ночи занимают очередь перед дверьми вашего офиса, ведь ваша идея такая крутая. А если выгорает текущая команда, снова поднимите руку вверх и махните. Некогда отдыхать, сам Джобс велел ходить голодным!

🤪 Лень: ух, страшно представить, сколько сил и времени пришлось бы вбухать в предварительный ресёч, тестирование MVP и валидацию спроса, аж ладошки потеют от ужаса. Гораздо лучше эти ладошки да на клавиатуру и кодить, ведь как может не продаться блокчейн с искусственным интеллектом да ещё и с 3D-аватарами?!

🙏 Хорошо, что в грехах всегда можно покаяться и встать на истинный путь исправления вместе с продактарианкой @redhead_product
Аминь!

#expert

Всем привет!

🤟 Сегодня в гостях у OTUS News — Евгений Жильцов, Head of QA с более чем 11-летним опытом в IT и преподаватель курса OTUS "QA Lead". Евгений расскажет, как эффективно организовать процесс Code Review в команде.

Вот 7 стратегий Code Review, которые помогут оптимизировать работу вашей команды:

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

🔹Стратегия «Напарники»
На старте спринта назначаются пары для взаимного ревью. Постоянная смена напарников способствует обмену знаниями и улучшению взаимодействия между разработчиками.

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

🔹Стратегия «Доверенное лицо»
Назначьте одного опытного разработчика, чье мнение принимается автоматически. Это идеально подходит для команд с большим количеством младших специалистов, нуждающихся в наставничестве.

🔹Стратегия «Экспертная зона»
При изменении в конкретной области кода приглашайте специалиста по этому домену. Это поможет получить точную и полезную обратную связь.

🔹Стратегия «Открытый стол»
Приглашайте всех желающих участвовать в ревью. Этот подход стимулирует обсуждение и повышает вовлеченность команды.

🔹Стратегия «Свежий взгляд»
Пригласите ревьюера из другого проекта или команды, чтобы получить объективный взгляд на изменения и избежать эффекта «замыленного глаза».

📌 Больше идей из арсенала тимлида можно найти в канале

#expert

Всем привет!
🤟 Сегодня в гостях у OTUS Дмитрий Панкрашов — Python Backend Developer в Сбере, автор канала DevIO | IT | GameDev и преподаватель курса “Python Developer. Professional” в IT в OTUS.
Дмитрий поделился личным опытом проектирования и внедрения системы автоматизации без четкого ТЗ и менторской поддержки, с какими ошибками он столкнулся в процессе и какие выводы сделал.

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

Когда‑то и я таким был. Устроившись на должность разработчика к подведу местного МинОбра (образования, не обороны!), мне поручили реализовать и внедрить в работу систему, рассчитанную на массовое использование. Система предназначалась для автоматизации процесса аттестации педагогических работников. Сотрудники школ, детских садов и других организаций могут подать заявление на присвоение категории, которая дает некоторую прибавку к зарплате. Заявление сопровождается отправкой портфолио, содержащим подтверждающие документы. Портфолио рассматривают эксперты, по результатам принимается решение о присвоении, либо отказе в присвоении категории.

Процесс, как водится, был «в бумаге» и требовалось перенести его и все данные «в компьютер». Технических заданий, дизайн‑документов, UML‑диаграмм, и прочего аналитического добра у меня, конечно же, не было. Были только утвержденные формы портфолио, и объяснения, как оно работает «на пальцах».
Как вы понимаете, этот текст не об успешном успехе и результатах внедрения, превосходящих все самые смелые ожидания, а о допущенных ошибках.

Ошибки — важная часть процесса обучения. Можно заучить «как правильно», и не понимать, почему же правильно именно так, а не по‑другому. А может, «правильно» делать надо не во всех случаях? А где можно срезать углы, и чем это черевато?

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

Ошибки проектирования

Все слышали поговорку «Семь раз отмерь — один раз отрежь»? Она в том числе и про проектирование.

Ошибка 1️⃣- Не проектировать вообще.
Максимум, что было у меня в голове после изучения бумажной формы портфолио — примерная концепция пользовательского интерфейса с деревом папок‑критериев оценки. На тот момент я мог еще нарисовать диаграмму потоков данных (по сути, схему базы данных, с таблицами и отношениями между ними), но, как я посчитал, без этого можно обойтись. Да и вообще, что там программировать?!

Ошибка 2️⃣-Проектировать только техническое решение.
Как показала практика, учитывать взаимодействие «пользователь — сотрудник — проверяющий», особенно, если оно может происходить в обход системы, все же нужно. Хотя бы для планирования возможных «дырок в заборе».

Ошибка 3️⃣- Я вообще‑то разработчик, а не эти ваши…
Любой разработчик минимально тестирует то, что пишет. Но «протыкал кнопки по предполагаемому user‑flow» и реальное использование — разные вещи, как выяснилось позже.

Спустя время кажется, что при отсутствии внятного ТЗ и желания его писать, можно было на неделю погрузиться в будни сотрудников, работающих по автоматизируемым процессам. Тем более, что после разработки всплыли дополнительные «хотелки», не учтенные изначально, и работа стала напоминать на строительство рельс перед несущимся паровозом.

➡️ В следующем посте поговорим про технические ошибки.

#expert

Всем привет!

Сегодня пост-продолжение рассказа Дмитрия Панкрашова (Python Backend Developer в Сбере, автор канала DevIO | IT | GameDev) про опыт проектирования и внедрения системы автоматизации.

Первая часть

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

Ошибка 1️⃣- Хранить файлы в базе данных
Как вам идея? Почему‑то мне показалось, что нет особой разницы между хранением на диске и в базе. В базе даже поудобнее, сразу связи видно, а на диске — вдруг чего где потеряется или затрётся? Загружаемые файлы, конечно, были ограничены по размеру. Сначала это было ограничение в 100Мб, потом приняли решение ограничить размер одного файла до 1Мб, но не ограничивать количество файлов. И что же стали делать люди, которым нужно отправить 100-страничный скан рукописных тетрадей? Конечно же, паковать все в архивы, с разбиением на тома. 300 томов по 1Мб, да еще и загружать это полдня, стараясь не пропустить том, и не загрузить одно и то же два раза (потом же не откроется ничего). Гвозди из этих людей можно делать! Но вернемся к базам. Хранить файлы в базе — решение плохое, в том числе и потому, что файл будет вычитан куда? Правильно. В память. А убирается он кем? Правильно. Сборщиком мусора. В результате на ровном месте получили тормозной и падающий по непонятным причинам хайлоад. Вот надо оно было?

Ошибка 2️⃣- Не учитывать поток пользователей
Сколько RPS (запросов в секунду) выдержит ваш сервис? А как вы это посчитали? Я был ответил — не знаю, никак не считал. Придут пользователи — разберемся. Пользователи пошли — начались ошибки. Тратя время на борьбу с ними, я все никак не мог прийти к мысли — а ведь можно было взять статистику за предыдущие годы и посчитать распределение аттестуемых по месяцам! В RPS это, конечно, никак не пересчитывается, но понять, даже примерно, к чему готовиться, и проверить приложение под нагрузкой перед его релизом возможность все же была.

Ошибка 3️⃣- Не собирать ошибки и метрики производительности
Это сейчас я знаю, что такое Sentry, ELK, Jaeger и т. д., а в то время анализ ограничивался постулатом «раз не пишут, значит, и проблем нет». А если проблемы были — сначала нужно было ошибку воспроизвести, потом исправить, и потом воспроизвести еще раз, чтобы провалидировать ее исправление. А уж про метрики производительности говорить даже не буду. До сих пор никто не знает, сколько там операции с базой времени занимают.

Ошибка 4️⃣- Бэкапы
Классика. Ситуация: в 2 часа ночи вспомнил, что обещал с утра сделать фичу. Естественно, забыл про обещание напрочь. Выхода нет — надо делать, раз обещал. И что‑то в систему войти не получается, сейчас себе в базе пароль поменяю. UPDATE users set password = «mYp@$$w0rd»; Поменял, отлично, работаем. С утра звонок — люди не могут войти в систему. Ну я‑то вхожу, вот смотрите, набираю mYp@$$W0rd, и я внутри. И только потом дошло, что кто‑то забыл написать WHERE id = 123. Мем смешной, ситуация страшная, да. Но ничего страшного по итогу не случилось, все, кто хотел, сбросили себе пароль через почту, а меня попросили так больше не делать. А был бы бэкап — можно было бы восстановиться, пусть даже перенося пароли из другой БД скриптом.

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

➡️ Про ошибки коммуникации поговорим в следующем посте.

#expert

Всем привет!
Завершаем рассказ Дмитрия Панкрашова про его опыт проектирования и внедрения системы автоматизации.
Сегодняшний пост посвящен ошибкам коммуникации.

Первая часть
Вторая часть

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

Ошибка ❤️ - Рабочий телефон для работы, личный — НЕ для работы
Хотите, чтобы ваш телефон превратился в справочную? У меня так было. 2 телефона и 3 сим‑карты. Звонили везде одновременно, и даже ночью. Никому не рекомендую повторять такой опыт. И будет лучше, если вы не понимаете, чем может закончиться раздача своего личного номера телефона, пусть даже вам и кажется, что ничего страшного не случится, завести отдельный телефон только для рабочих коммуникаций.

Ошибка ❤️ - Нет каналов коммуникации
Вот представьте, отключили у вас электричество, и все никак не включат. Будете звонить? Конечно, будете. А куда? Сначала в УК\ТСЖ, потом в диспетчерскую, потом еще куда‑нибудь. А если никто не берет трубки — то и до администрации президента дозвонитесь. Собственно, дать пользователям единственный и живой канал коммуникации — важно. Если канал живой — пользователи будут туда писать. Если канал единственный — это исключает дубли и «сломанный телефон». Конечно, я стоял в конце этой цепочки и решений не принимал. Но сейчас предложил бы сделать пусть даже самого простого бота для подачи заявок и ответов на вопросы.

Ошибка ❤️ - Иерархия бизнес‑заказчиков
Что делать, если задачи вам ставят все кому не лень? Особенно прикольно, когда эти задачи еще и взаимоисключающие. Эталонная ситуация — когда два равных друг другу по должности и влиянию на продукт лица ставят вам в работу эти самые взаимоисключающие задачи. В моем случае было не так, и, хотя сами требования к продукту и хаос в их описании больше относятся к ошибкам проектирования, все же хорошей практикой считается задать вопрос «Кто мне ставит задачи?» — при условии, что ответ «Все» не принимается.

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

Чтобы узнать больше полезного из мира IT и разработки, подписывайтесь на канал Дмитрия: DevIO | IT | GameDev

#expert