Привет! Меня зовут Александр. Я ведущий инженер-технолог в авиационной литейке. И я нашёл один диагноз, который вскрывает все симптомы зомби-Agile – не десять объяснений, а одну единую структуру. И инструмент, чтобы поставить этот диагноз в вашей команде.
В моей работе нет Agile, зато есть техпроцессы, допуски и цена ошибки – в забракованной отливке.
Меня зовут Иван Васильев, я ведущий аналитик в Ви.Tech, IT-дочке ВсеИнструменты.ру. Хочу показать, как из на первый взгляд простой формулы KPI выросла инженерная задача: нам нужно было не просто посчитать интегральный показатель эффективности поставщика, а объяснить, какая именно закупка его ухудшила и почему. В статье разберу, почему для агрегированных метрик не работает наивный подход, как мы пришли к remove-one analysis и где пришлось отдельно фиксировать логику расчета, чтобы результат вообще можно было интерпретировать.
Недавно я посмотрел большое интервью с основателем и руководителем Revolut. Кто не знает, это такой Т-банк, только в мировом масштабе (они представлены в 40 странах уже) - как бы банк без офисов, но по сути ИТ-компания.
Самое интересное для меня была часть про управление такой большой и быстрорастущей компанией. Все управление выстроено на цифрах: метриках и показателях.
«Решения в компании принимаются на основе цифр, а не эмоций. Это позволяет минимизировать человеческий фактор и ошибки».
Почему это важно:
Устранение субъективности.Читать полностью »
До определённого момента юридический процесс кажется управляемым.
Есть стадии, статусы, отчёты, дедлайны. Пока дел немного, это работает.
Но когда их становится больше сотни, иллюзия управления начинает разваливаться.
Именно в этот момент я впервые понял, что с процессами что-то не так.
Проблемы начали проявляться не сразу и не в одном месте.
Одни дела шли быстро, другие — зависали без видимых причин.
Читать полностью »
Привет! Поведаю историю, неизвестную почти никому, но от того не менее занимательную.
Занимательной она мне кажется по нескольким причинам:
Она заставляет задуматься, как этика разработчиков влияет на имидж компании,
Приоткрывает завесу процесса разработки и запусков,
Иллюстрирует, на чем можно построить пиар
Я – один из ее фигурантов
Истории почти год, и сейчас я уже давно не работаю в компании, в которой работал тогда – поэтому считаю себя свободным от всяких аффилиаций и вправе написать эту статью в том виде, в котором считаю нужным.
Знакомая картина? Вы полгода впахивали над проектом. Ночами не спали, код рефакторили до блеска, разруливали косяки смежников, выкатили фичу, которой гордятся. Вы - молодец.
А потом приходит тимлид и с лицом хирурга, сообщающего плохие новости, говорит:
«Слушай, к твоей работе вообще нет вопросов. Ты красавчик. Но отдел маркетинга в этом квартале запустил вирусную кампанию, и по квоте „выдающихся“ сотрудников они забрали все слоты. Так что у тебя оценка „соответствует ожиданиям“. Без бонуса. Не обижайся».
Не обижаться? Да в этот момент хочется не обижаться, а перевернуть стол.
⚡️Классическая поддержка не справляется с ростом нагрузки. Мы внедрили цикл непрерывных улучшений (self-care + два уровня работы внутри поддержки), и это реально снизило число обращений, повысило FCR и вовлекло сотрудников в развитие процессов.
В классической модели техподдержки всё строится по принципу: «есть проблема → решаем её».
Работает? Да. Эффективно в масштабе? Нет.
С ростом клиентов и сервисов начинаются типичные боли:
количество обращений растёт быстрее, чем команда,
ожидания клиентов становятся выше,
В банковском секторе (и не только) эффективность — понятие относительное.
Зачастую корпоративные университеты представляют результаты обучения в виде сухого показателя обученности или, в лучшем случае, оптимистичного NPS. Сами по себе эти показатели ни плохи, ни хороши, но при их выбор бизнес-заказчик, как правило, выражает скепсис, и тогда в переговорной нависает вопрос: «А действительно ли обучение что‑то решает?»
В данной статье я покажу на примере, как можно измерять эффективность обучения, какие метрики выбрать и на что ориентироваться?
Привет! Я Арсен, разработчик в DDPlanet. Хочу рассказать, как мы делали свою систему KPI для оценки - кто и сколько реально работает.
