Pull to refresh

Comments 11

Отличная статья. =) KPI где-то так и считаем =)

Предложение автору: оставь свои контакты, может PM-ом возьмут сразу в один из проектов. Мышление правильное =)image
Вроде направление интересное, со сведением всего к количеству баллов.
Но получилась не совсем геймификация.

Это аккордно-премиальная система + штрафы. Пусть и с прозрачной системой расчетов, выраженная в баллах.

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

После просмотра про геймифиакцию на корсере, была идея запилить трекер задач со всем вышеперечисленным, но погрязла в рутине :)

Заставлял всегда фиксировать время, но никогда не использовал в качестве оргвыводов. Просто чтобы знать затраты.
Иначе начинается высиживание часов и атомарные отчеты в стиле «крутил гайку №5» и «делал рефакторинг».

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

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

Очень нравится идея Лебедева о «единицах смысла». Достаточно просто отмечать в записной книжке каждый такой вклад и больше для расчета премии не нужно. Теоретически, в дополнение к материальным поощрениям, можно вешать значки за каждую единицу смысла, чтобы все видели и тянулись за лидером.

Это аккордно-премиальная система + штрафы.

От штрафов и дополнительных коэффициентов мы отказались, т.к. страдает общая мотивация.

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

В целом согласен. Изначально в проекте системы я предполагал такие ачивки. Но ещё до запуска в тестирование столкнулся с тем, что часть сотрудников вообще не играли в РПГ, а часть не любит подобный жанр. Кроме того, при собеседовании многих может испугать настолько далёкий от стандартов подход. Пример ачивок:
За переработку
За активность в подготовке корпоративов
За минимум багов / претензий от клиентов
За помощь стажёрам
За инициативные предложения (которым я дал зелёный свет)
Придумать можно многое и материальную составляющую назначить в зависимости от приоритетов компании. Хотели даже в CRM изменить профиль сотрудника в стиле:
image
Но всё упёрлось в сложность адаптации.

Очень интересная статья. Большое спасибо автору за ее публикацию. Тема численной оценки труда разработчиков меня сейчас интересует особенно сильно, и чужой опыт очень полезен. Есть ряд вопросов, которые хотел бы уточнить:

Как вы добиваетесь и проверяете достоверность отчетов по времени? Кто и как расставляет баллы сложности на задания/проекты? Насколько справедливой коллектив считает эту оценку? Сколько времени занимает процедура оценки задач? А сколько — подсчета итогов?

И самое главное: как масштабируется эта система при росте команды до 3-4-5 команд? Все предыдущие вопросы интересуют в большей степени именно в этом ключе.
Как вы добиваетесь и проверяете достоверность отчетов по времени?

У всех сотрудников есть непосредственный начальник. В обязанностях которого в т.ч. курирование трудозатрат. Если тех. директор видит явное несоответствие сложности задачи и времени на её выполнение, то программист обязан пояснить что и в каком виде он делал. Свежий пример из студийного чата:

— Толян, сколько готово страниц по агрегату?
— 1,5
— А сколько времени потрачено?
— 37
— Чё там совсем ***?
— Да не, со слайдерами на главной долго ***. Потом с формами на странице стилей. Сейчас о компании наполовину сделал, там тоже слайдер.
— Когда планируешь закончить если у тебя не будет отвлекающих задач
— Пока дедлайн к среде сохраняется. Другие страницы простые. Если не буду успевать, дома поработаю. У меня учёба закончилась.

Вопрос по срокам закрыт. То же самое арт-директор и дизайнеры. Цель ведения табеля — сбор и анализ трудозатрат, а не тотальный контроль за временем сотрудников. Мотивация к работе, а тем более к честности по отношению к коллегам и руководству воспитывается не табелем. Просто если за сотрудником будут появляться постоянные косяки, которые он не сможет адекватно пояснить, то это поставит вопрос о целесообразности его работы в студии в целом.

Кто и как расставляет баллы сложности на задания/проекты?

Предполагалось, что это будет делать непосредственный руководитель при согласовании с сотрудником, которому будет поручен проект. Например:
— Вась ты за 48 часов проект N заверстаешь?
— Нет, там Макс замудрил с картой присутствия.
— Давай тогда 56.
— Ок

От оценки сложности и адекватности заказчика мы отказались как раз из-за субъективности этих параметров. Об этом я писал в статье.

Насколько справедливой коллектив считает эту оценку?

В целом, как я написал выше оценка происходит при участии прогнозируемого исполнителя. Главное условие: сотрудник и студия (в лице руководителя сотрудника) должны быть с оценкой согласны.

Сколько времени занимает процедура оценки задач?

Сложно сказать, т.к. это зависит от самих задач. У нас при оценке разработки сайта по адекватному ТЗ уходит суммарно 0,5 -1,5 часа. Я думаю, что у всех компаний есть собственные механизмы оценки трудозатрат. Нужно ориентироваться именно на них, т.к. людям так будет проще, а значит оценка точнее.

А сколько — подсчета итогов?

0 мин. Из табеля автоматически распределяется время по задачам, на которые оно тратилось. Так по каждому сотруднику. Мне остаётся зайти и посмотреть диаграмму Ганта по задачам, сопоставить оценочное время и реально затраченное по завершённым проектам, ну и самое интересное — сделать соответствующие выводы.

как масштабируется эта система при росте команды до 3-4-5 команд?

Это зависит от того, что именно у Вас является командой и кто является ответственным за действие команды. Если брать тривиальную горизонтальную схему, где во главе команды стоит ПМ, то именно он должен следить за всем происходящим в табелях у подчинённых и, если что-то ему кажется неадекватным, то просить разъяснений у начальников этих сотрудников. После всех согласований он подаёт информацию бухгалтеру для начисления з/п.

У нас немного иная схема, и у нас нет ПМов и сейлсов (это тема для отдельной статьи). Поэтому контроль за табелями произвожу я. Учёт табелей 8 сотрудников занимает примерно 3 часа 1 раз в месяц.
Какие-то мудреные схемы… зачем придумывать велосипед… оклад+ежемесячная премия 100%. Накосячил — минус 50% премии, сильно накосячил — минус вся премия. А если проект сдал вовремя, прибыли принес много, то можно и дополнительную премию выдать.
А разве это заслуга разработчика что проект принёс много денег? Вот что вовремя запущен — то да. А деньги — это заслуга продавцов и всех из направления BezDev'а.

Насчёт накосячил — разработчик может не согласиться что это его вина. И тогда всё скатывается к авторитаризму, где где решения принимаются лично руководителем, и теряется прозрачность и предсказуемость системы.
разработчик может не согласиться

Если разработчик не согласен с обвинениями, то он может доступно объяснить, что он невиновен, предоставить факты, алиби. Никто не отменял диалоги с начальством, всегда можно беседой уладить вопросы.
решения принимаются лично руководителем, и теряется прозрачность и предсказуемость системы.

А разве руководитель не для того существует на проекте чтобы принимать решения? Или вы считаете что группа друзей-товарищей без лидера будет работать предсказуемо и прозрачно? Все будут вовремя делать дела, никто не будет лениться и все будут выкладываться для общего дела? Если такие товарищества существуют, то им наверно и зарплата не нужна…
А деньги — это заслуга продавцов

Т.е. если разработчики сделают недопроект, то хороший продавец всё равно продаст его? Тогда можно пойти в ближайший университет, набрать студентов последних курсов, дать им ТЗ, когда они что-то сделают послать одного из студентов на рынок, чтобы он привел продавца арбузов, чтобы тот продал ваш продукт. Утрирую конечно, но прибыль во многом зависит и от разработчиков.
Вы утрируете, а многие компании именно так и поступают. Особенно в регионах, особенно в низком ценовом сегменте.
Как я уже писал в статье, от большинства «замудрёностей» мы как раз отказались во время тестирования. По факту остались как раз те же самые оклад (зависящий от выработки сотрудника за всю историю работы в компании) и премия (зависящая от выработки в отчётный месяц).
Sign up to leave a comment.

Articles