Всем привет! Вдруг у меня тут есть ребята из Тинькова. У вас сломалась распознавалка телефона при отправке платежа в мобилке. Вставляешь номер с +7, раньше она сама резала эту +7, теперь только + и, соответственно, сдвигает цифры номера на одну назад теряя последнюю. Пофиксите, пожалуйста, жуть как бесит)

Настало время поговорить про KPI.
Что такое KPI - это просто метрика с планом. Главная особенность, что она должна быть достижима. И если она достигнута, то по ней можно принимать решение о эффективности сотрудника или предприятия.
Эта история отлично работает на конвейере в любом его проявлении от классического производственного до конвейера службы технической поддержки. Основное условие - операции должны быть классифицированы, описаны, понятны, пригодны для подсчета, прогнозируемы и в достаточной степени изолированы от условного внешнего влияния.
В этом случае вы и правда, можете ставить определенный план по достижению какого-либо значения показателя, например, скорость реакции на заявку в минутах и оценивать по нему эффективность сотрудника поддержки и его менеджера.
А теперь давайте посмотрим на разработку продуктов. Все оценки, даже в часах очень условны. Да, их можно вписать в план и договор, но никто не застрахован от того, что во фреймворке у вас обнаружилось некорректное описание или баг в новом релизе. Или то, что никто из пользователей не сказал аналитику о редком корнер кейсе, который в итоге не обработали. Тут появляется очень большое влияние случайности (такие маленькие черные лебедята), потому что работу у нас творческая. Таким образом, любой KPI может быть не выполнен по независящим не то что от аналитика, а от всей команды разработки, обстоятельствам. Поэтому количество багов, конечно, можно использовать как KPI, но он будет хакаться, прятаться под ковер или вся разработка будет осуществляться на “годами проверенных решениях”, которые будут антонимом для инноваций и по настоящему крутых разработок.
Мое мнение достаточно простое - метрики, это супер важно, за ними нужно следить и контролировать из оптимальное состояние, но судить по них об эффективности сотрудника или команды чревато проблемами в процессах и мотивации. У вас должны быть реально недостижимые цели, к которым ты стремишься, поддерживающие метрики и это не должно быть привязано к материальной мотивации сотрудников.

Хороший ликбез по видам БД с перечнем БД различных типов, для первичного ознакомления и понимания, какую БД как используют (а внезапно почти все постреляционные или NoSQL базы данных имеют достаточно узкоспециализированное назначение в рамках которого они очень круты) очень годный материал https://habr.com/ru/companies/amvera/articles/754702/

Немного не по теме канала, но не могу не поделиться. Волшебное выступление Марти Кагана про уровни продуктовой стратегии и целеполагание. Я всегда знал, что с этими роадмапами что то не так) https://www.youtube.com/watch?v=x4H_gluZI10

Интересная статья о типовых ошибках при обсуждении зарплаты на собеседовании с объяснением, почему рекрутеры так себя ведут и что они подразумевают. https://interviewing.io/blog/sabotage-salary-negotiation-before-even-start

Привет, Миша Максимов выпустил новый выпуск новостей СА и БА на своём канале, налетай, смотрите! https://youtu.be/gDlRTaXr-n8. Вообще не реклама, и даже рядом не стояло и никаких денег, все по дружбе и ради полезного контента!

Всем привет! И снова из рубрики не реклама. И никаких денег я за это не получил. Два дня будет в онлайне проходить конференция Flow, на которой я появлюсь в эфире оба дня.
Сегодня помогаю в качетсве эксперта Мише Максимову рассказать про управление изменениями требований.
Завтра же вместе с моим другом и коллегой Максом Корейченко, разработчиком в немецкой HRTech компании, буду рассказывать про то, как ставить задачу разработчиками, так, чтобы они не считали тебя идиотом

Прекрасный ролик про коммуникации украл у Дмитрия Филлипова. Очень часто ловлю себя на том, что оказываясь в роли второй стороны с такими "руководителями", как в ролике, действительно терял всякую мотивацию и сильно негативил, так что это очень крутой поинт по исправлению коммуникаций

На этой неделе обсуждали со студентами методологии разработки ПО, гибкие методологии и конкретно Скрам и место аналитика в нем. И возник вопрос, а если скрам нельзя менять, то как же он может относиться к гибким методологиям.
И сегодня на глаза попалось короткое видео, почему же он все таки под зонтиком Agile. https://youtu.be/di8CZIKq9Q4?si=VVQMFzINF-Nh54sN

Всем привет, сегодня посетил чудесный Утрехт и встретился с Алиной Романович, которая несколько лет радовала студентов нашего курса подробным и полезным фидбеком на их домашки. Алина работает аналитиков в голландском маркетплейсе и рассказала много интересного про работу аналитика в голландской компании и чем это отличаетсот работы аналитикав РФ. Хотите тоже послушать? Пишите свои вопросы и голосуйте в опросе ниже, в среду подведём итоги.

Очередная прекрасная мысль от Дмитрия

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

Всем привет. Неделя выдалась тяжёлая, поэтому результаты опроса глянул только сейчас. Эфиру быть. У нас есть тактика мы её придерживаемся, но мы хотим её скорректировать под ваши запросы. Накидайте в комментарии поинты, которые хотите обсудить.

Всем привет. Ко мне тут пришли с предложением рекламы. Я немного в замешательстве, давать ли рекламу в канале. Как считаете?

А я возвращаюсь с эфиром с Алиной. по времени два варианта в четверг в 21 час по Мск или в понедельник в 18 часов по Москве. Давайте определимся

Итак, эфир завтра в 21.00 по Москве. Готовьте ваши камеры и микрофоны!