Отличная статья! Сколько времени ушло на её написание?:)
Когда размышляю о сложности оценить реальную эффективность в IT, с любопытством отмечаю как решение этой проблемы эволюционировало в формат performance review в крупных компаниях. Фактически мы признаем, что не можем напрямую корректно измерить эффективность сотрудников, поэтому будем их калибровать на основе информации из всех возможных источников: обратная связь от заказчиков, обратная связь от тимлида, который регулярно взаимодействует с сотрудником и его заказчиками, подтверждение его технических навыков, выполнение требований грейда и т.д.
И недавно спросил у HR, как они оценивают эффективность проведения мною технического скоринга для кандидатов. Оказалось, что косвенно с нескольких сторон: 1. Реакция на негативную связь кандидата сразу после скоринга (корнер кейсы); 2. Процент кандидатов, которые пройдут следующий этап; 3. Обратная связь от тех, кто в итоге получил оффер.
Важно уточнить, что я не занимал в IT менеджерской позиции - на протяжении 4-х лет в аналитике данных работаю исполнителем.
Если же под подходом "с точки зрения менеджера" подразумевается посмотреть на проект глазами клиента (заказчика) и подумать в первую очередь о его интересах в контексте целей команды, то я действительно продвигаю этот подход.
Безусловно в разработке есть своя специфика, но в аналитике тоже разрабатывается немало сложных вещей, поэтому думаю, что общая картина схожа.
Проблема со сроками понятна. Я сталкиваюсь с ней регулярно, и для того, чтобы её решить нужно провести целый пласт специальной работы (по сути, параллельно закрыть несколько других пунктов описанных в статье): иметь долгосрочное планирование, согласованное с заказчиками, принимать проактивное участие в создании ТЗ (понимать общий контекст задачи), управлять ожиданиями заказчиками и т.д.
Если просто говорить об оценке сроков, то тут обычно есть 2 подхода:
Называть сроки с запасом;
Брать сроки на предварительное исследование проекта, которое позволит более точно назвать сроки по самому проекту.
Отличная статья!
Сколько времени ушло на её написание?:)
Когда размышляю о сложности оценить реальную эффективность в IT, с любопытством отмечаю как решение этой проблемы эволюционировало в формат performance review в крупных компаниях. Фактически мы признаем, что не можем напрямую корректно измерить эффективность сотрудников, поэтому будем их калибровать на основе информации из всех возможных источников: обратная связь от заказчиков, обратная связь от тимлида, который регулярно взаимодействует с сотрудником и его заказчиками, подтверждение его технических навыков, выполнение требований грейда и т.д.
И недавно спросил у HR, как они оценивают эффективность проведения мною технического скоринга для кандидатов. Оказалось, что косвенно с нескольких сторон:
1. Реакция на негативную связь кандидата сразу после скоринга (корнер кейсы);
2. Процент кандидатов, которые пройдут следующий этап;
3. Обратная связь от тех, кто в итоге получил оффер.
Важно уточнить, что я не занимал в IT менеджерской позиции - на протяжении 4-х лет в аналитике данных работаю исполнителем.
Если же под подходом "с точки зрения менеджера" подразумевается посмотреть на проект глазами клиента (заказчика) и подумать в первую очередь о его интересах в контексте целей команды, то я действительно продвигаю этот подход.
Безусловно в разработке есть своя специфика, но в аналитике тоже разрабатывается немало сложных вещей, поэтому думаю, что общая картина схожа.
Проблема со сроками понятна. Я сталкиваюсь с ней регулярно, и для того, чтобы её решить нужно провести целый пласт специальной работы (по сути, параллельно закрыть несколько других пунктов описанных в статье): иметь долгосрочное планирование, согласованное с заказчиками, принимать проактивное участие в создании ТЗ (понимать общий контекст задачи), управлять ожиданиями заказчиками и т.д.
Если просто говорить об оценке сроков, то тут обычно есть 2 подхода:
Называть сроки с запасом;
Брать сроки на предварительное исследование проекта, которое позволит более точно назвать сроки по самому проекту.