Comments 4
Прохожу курс project management'a, который построен на базе PMBoK.
И вот там есть интересная вещь, которая хорошо подходит к
> Не просто “сократилось время обработки инцидентов”, а “сократилось время обработки инцидентов на 30%” — отвечаем на вопрос “что именно изменилось?”.
таким вот заявлениям. Уменьшилось на 30% - это сырые данные, а информация - это данные обработанные с наличием контекста.
Так вот, контекст. Было 50 часов, стало 35 часов. Снижение на 30%, но мы видим, что было плохо, да и сейчас плохо.
Второе, вот пилит некий разработчик некую систему самопомощи. И да, с этой системой время обработки инцидентов сократилось (наверное). Но вот со скольки и до скольки - откуда разработчику известно? Обычно неизвестно, потому что таких данных (и доступа к этим данным) у разработчика нет, и не может быть. К этим данным может быть доступ у продуктового аналитика, но поделиться ли он ими с разработчиком - это вопрос.
Но все продолжают натягивать на STAR все роли подряд, не понимая, что у "кодеров" работа тасочки двигать с определенным KPI, а разработчиков нынче мало, стоят они дорого, и проще заменить одного разраба на команду. И бас фактор ниже, и цена на штатную единицу ниже, и работодателю проще заменить человека в системе, потому что вместо богатого набора компетенций нужна одна конкретная.
Без контекста все эти циферки ничего не значат.
Нас в отделе год назад было пятеро, двое админов ушло и остаток персонала (все трое - техподдержка, не админы) держат "на зубах" ИТ-инфраструктуру электростанции на плаву - героически ликвидируя аварии и превозмогая массовые инциденты. Здесь не сокращение времени надо считать, а удивляться что всё вообще как-то работает. Это раз.
Второе: кто мне даст показатели времени решения заявок/инцидентов? Аналитик в исполаппарате в Москве? На каком основании спросит он и отошлёт моё письмо безопасникам. Оно мне это надо? Значит цифру -24% я придумаю сам, сам впишу её в резюме. Но правильно ли это?
Беда НР в неправильном целеполагании - надо искать персонал, а не идеальные с вашей точки зрения резюме. "Как?" спросите вы - вопрос не по зарплате - вы этим занимаетесь, вы и думайте.
Итого: глупая статья. Неправильная.
сократилось время обработки инцидентов на 30%
Тут два момента:
Во-первых, разработчики этих цифр обычно не знают (ну т.е. технические метрики может быть и знают, а процессные скорее всего нет; связаны они не напрямую и даже не всегда коррелируют). Поэтому человек, который это пишет в резюме, скорее всего, врёт. И врёт он не потому, что хочет, а потому что вы (конечно же, не Вы конкретно) заставили его врать.
Во-вторых. Заставляя людей врать, что само по себе проблема, вы заставляете их врать плохо и непрофессионально, и это гораздо большая проблема. Сама формулировка - "сократилось время обработки инцидентов на 30%" - как это в реальности выглядит? Все инциденты обрабатывались за 10 минут, а стали за 7 минут? Такого же не бывает. У нас была какая-то текущая статистика, текущее распределение времени обработки. Мы что-то сделали, распределение изменилось. 30% - это что? Среднее? Медиана? P95? А если среднее время уменьшилось на 30%, а P95 увеличилось в 10 раз это достижение или полный провал? А разработчик сам себе задачу ставил (ну, чтобы контекст и основные трейдоффы он мог описать)? Пусть даже и сам, и пусть даже всё получилось, он сделал что хотел и стало действительно лучше, и даже может всё это представить с цифрами (такого почти никогда не бывает, но вдруг). Вы готовы по каждому пункту STAR читать два-три абзаца текста? Сколько таких кейсов можно описать в резюме, просто исходя из объёма? Кто эту ерунду придумал вообще?
Когда руководители компаний начнут осознавать, что главная проблема в найме - это их же рекрутеры, ожидающие захватывающего сюжета в сопроводительном письме, найм начёт эволюционировать от базара к рынку.
Как писать резюме в IT-сфере? Как даже хорошее резюме может терять отклики и что с этим делать?