Хочу или могу? Определяем уровень сотрудника в компании

Я знаю и умею или только так думаю? Как меня видят со стороны и как это совпадает с моим мнением? Каковы мои достоинства и недостатки? Каким меня видит моя команда, мои коллеги, мое начальство? Какие у меня перспективы, на что я могу рассчитывать?

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

Среди моих обязанностей на позициях Program и Engineering менеджера были улучшение методов разработки, оптимизация цикла выпуска продукта, повышение эффективности работы сотрудников, а также содействие их профессиональному росту и определение плана дальнейшего развития, который совмещает в себе личные интересы сотрудников и цели компании.

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

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

Обсудить, учесть все мнения и учиться на ошибках. Фиксировать полученный опыт и результаты, и на их базе совершенствовать процесс. Это мы называем Agile. На самом деле, он давно уже проник во многие сферы нашей деятельности. Мы его используем в современном менеджменте, не только непосредственно в разработке. Некоторые его уже успешно применяют в работе с персоналом. И тут действительно работает аксиома, что кадры решают все. В этом мы постоянно убеждаемся на практике.

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

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

Более того, по личному опыту могу утверждать, что сотрудник не всегда точно знает, развития каких именно компетенций от него ожидает компания. За что конкретно сотрудник получает оплату труда. Что из своих компетенций он должен развивать, чтобы достичь следующего уровня. В каких компетенциях компания в данный момент испытывает потребность. Возможно, имеет смысл не искать кого-то на рынке труда, тратить время на адаптацию и оценку результатов нового сотрудника. В первую очередь, целесообразным является обратить внимание на своих собственных перспективных сотрудников, которые хотят развиваться. Важно вовремя предоставить информацию о том, какие сейчас в компании приоритетные направления, в каком направлении есть дополнительная потребность (в чем наблюдается недостаток).

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

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

В системах оценивания и грейдинга применяется следующий подход. Определяются критерии, по которым будет производиться оценивание или грейдирование, и детально описывается каждый из уровней. Совместно с методологом определяются единые стандарты внутри компании.

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

Все готово, у нас появляется возможность перейти от слов к цифрам. На основании полученной информации появляется возможность определить уровень соответствия сотрудника занимаемой им должности в процентном отношении:

Personal Evaluation Form

На картинке выше приведен пример оценки по одному из критериев. Определено пять уровней с детальным описанием, от базового до экспертного. Конкретные формулировки в данный момент не важны, так как они прописываются отдельно с учетом специфики каждой компании. Если данный критерий по специальности обязательный, определяется так называемый Pass level — необходимый и достаточный уровень для того, чтобы сотрудник полностью соотвествовал занимаемой должности.

Оценку проводят несколько компетентных людей, которые способны объективно оценить сотрудника по данному критерию. Оценки не должны существенно отличаться, если информации достаточно. Иначе необходимо провести уточняющую сессию, во время которой происходит согласование оценок. Очень похоже на Planning Poker. Оценкам лучше присвоить буквы, чтобы оценка не превратилась в советскую допотопную трехбалльную систему, с которой связано множество стереотипов.

Далее вычисляется среднее арифметическое и сравнивается с Pass Level. Таким образом получается процент соответствия по данному критерию. Для каждой специальности обычно набирается основных или так называемых первоочередных критериев, по которым вычисляется общий уровень компетенции. При правильно собранной информации в среднем ожидается значение от 90 до 110%. Большие отклоннения требуют более детального анализа.

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

Очень важно получить комментарии по каждой оценке. Они помогают больше узнать об источнике информации и определить объективность оценки.

В результате проведения подобных регулярных мероприятий решается ряд сложных задач:

• Оценивание на базе принципа «360 текущих успехов и достижений за прошедший период».
• Предоставление детальной информации сотруднику о его текущем уровне и перспективах.
• Определение компетенций на уровне компании.
• Составление грейдов.
• Утверждение и публикация официальной информации по компетенциям и грейдам внутри компании.
• Определение грейдов сотрудников. Подсчет уровня соответствия в процентном отношении.
• Личная беседа с каждым сотрудником, предоставление и обсуждение полученной информации.
• Обсуждение дальнейших перспектив и пожеланий сотрудника.
• Составление и утверждение плана развития (PDP) с учетом интересов как сотрудника, так и компании.
• Сбор и анализ статистических данных на регулярной основе, которая может использоваться как дополнительный инструмент во время Performance review.

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

Стремление к результату порой намного важнее самого результата, так как результат — это всего лишь маленькая точка на промежуточной вершине, тогда как стремление — беспрерывный процесс, направленный на совершенствование и всестороннее развитие. Этот процесс имеет множество положительных «побочных» эффектов, которыми мы как снежный ком обрастаем на пути к профессионализму.

P. S. Настоящему профи не нужен процесс. Четкий сценарий на все случаи жизни и сопутствующая бюрократия только утяжеляют его. Профессионал, досконально знающий свое дело, точно знает, что, где и в какой именно момент необходимо сделать. Оценить его трудно, еще сложнее его развить. Но если научиться — результат превзойдет все ожидания.

Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно. І підписуйтеся на Telegram-канал редакції DOU

До обраного В обраному 0

Health-чек проєкту може бути актуальним для багатьох: від топменеджерів і власників бізнесу до будь-кого в компанії. Він допоможе краще оцінити якість сервісу на проєкті, виявити те, що можна поліпшити, та запобігти можливим ризикам. 7

Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да. Было весело (саркастический, нервный смех). Я попробую изложить подход, который вы можете использовать, если обнаружите себя в подобной ситуации. 43

У статті ми поговоримо про естимацію тестування, оскільки це те, від чого залежить можливість проджект-менеджера ухвалювати правильні рішення щодо управління проєктом. З’ясуємо, з чого починати оцінювання завдань, щоб експертність QA-департаменту зростала. 5

DOU News #12

Вывод: для бодишопов — самое оно; для компаний, который ставят на инновации — смерть. Соответственно для девелоперов: середнячок, хочешь денег — проходи оценку в бодишопе; творческая личность, умеешь что-то действительно хорошо — добро пожаловать в продуктовые компании и стартапы.

Лично моя позиция касательно этих вопров такая — позиция девелопера независима от других позиций — принцип что сказали — то сделал, если девелопер делает не то — то это вина его тимлида или ПМа, но никак не девелопера. можно выделить такие уровни исполнения:начинающий — на сложные таски знаний и опыта не хватает, делает легикие с средние долго но делает — джуниор.средний — делает все таски, не всегда быстро, не всегда сам. не всегда умеет разглядеть проблемы на перед- миддл.хороший — делает все таски, в срок, не долго, помогает коллегам, видит проблемы на перед, немного разбирается в предметной области для подстраховки БА и ПМа — синьер.По-этому на примере аутсорса разные люди несут разную маржинальность для компании, по-этому на джуниорах — зарабатывают, миддлы создают костяк рабочей силы, на синьерах почти не зарабатывают, получая надежность и уверенность что все задачи будут решены в срок и правильно.

Может быть я немного не так понял твои слова о

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

Человеки, а где подобные формализированные процессы оценки применяются?Я раньше таким вопросом не задавался(ну, и коллегам не задавал), только SoftServe и знаю.

В реальности компания является единым организмом, и чем сильнее её будете разрывать тем больнее будет. Деньги конечно умогут «обезболить», но вызывают привыкание.

Неужели есть ещё кто-то, кто не читал Деминга?

Спешу выразить огромную благодарность всем, кто откликнулся на статью и поделился своим мнением. В рамках подготовки следующего материала, прошу вас оставить свои пожелания, какие еще темы в этом направлении были бы вам интересны?

Спасибо огромное за статью!

Кстати было бы интересно продолжение «Как определить / оцифровать уровень директора компании »

К сожалению, высшее руководство живет немного по другим законам. И оцениваются они по-другому. В основном, это KPI, направленные на достижение определенных показателей по прибыльности, расширению, повышению репутации, устранению проблем, наращиванию производительности и т.д. Как и все люди, руководители бывают разных типов, и достигают своих целей они за счет (или благодаря, или продвигая, это уже кто как умеет) своих сотрудников по-разному. Так ли это интересно для читателей, непосредственно вовлеченных в процесс разработки? )

Так ли это интересно для читателей, непосредственно вовлеченных в процесс разработки? )

ага, еще бы. Трезвый адекватный директор — это высокие шансы на запуск проектов /стартапов. Вот интересуюсь потихоньку .

Отвечу наводящим вопросом: Что такое «экспертные методы», и когда их применяют?

Вот вроде бы и правильно пишите а вроде бы и нет :)

Итак о талантах.

Если у вас талант проектировать архитектуру — пишите дома свой фреймворк, и нехрен лезть на проекты заставляя народ разбираться с вашими идеями, ведь непонятно что талант придумать решение или разобраться и использовать его в конкретной реализации (а это рутина, которую таланты типа нехотят делать). И что получается я придумал подвязал проект на решение а вы все потом е. тесь?

Если у вас талант придумывать удобные пользовательские интерфейсы работайте UX и не хрен сидеть в прогерах!

Умеете находить дыры в проекте- значит тестировщик ваше призвание!

Если у вас талант придумывать сценарии для игровых проектов работайте сценаристом! etc.

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

Для меня талантливый девелопер тот, кто делает рутину быстрее остальных, и результат его работы стабильнее и быстрее, чем у сотрудников этого же офиса, а то что там у кого-то еще и гениальные идеи, которые недооценены, ну так а я классные котлеты жарю, ах недооценивают это :)

А на счет оуценки сотрудников по критериям не совсем корректно просто множить.

Выписываем критерии и ставим им в соответствие вес: — вождение 0.6, — контраварийность 0.2, — вежливость 0.1,

— мягкий стиль вождения 0.1

Каждый делает это на свое усмотрение. Далее смотрим сколько балов для каждого критерия набирает испытуемый, например: — вождение 6 из 10, — контраварийность 8 из 10, — вежливость 1 из 2,

— мягкий стиль вождения 2 из 2

Находим процент набранных баллов, и перемножаем с весом: — вождение 0.6×6/10= 0.36, — контраварийность 0.2×8/10=0.18, — вежливость 0.1×1/2=0.05,

— мягкий стиль вождения 0.1×2/2=0.1

Дальше просто суммируем результат result=0.36+0.18+0.05+0.1=0.79

И прогоняем результат по градациям:

result меньше 0.4 — не берем на работу 0.4 больше result меньше 0.7 — джуниор 0.7 больше result меньше 0.9 — сеньор

0.9 больше result меньше 1 — тимлид

Понятно что все критерии оценки и градации на ваше усмотрение. А сама идея почерпнута из Формулы Байеса :)

Для меня талантливый девелопер тот, кто делает рутину быстрее остальных

Запостил в «афоризмы» ДОУ.

Если у вас талант проектировать архитектуру — пишите дома свой фреймворк, и нехрен лезть на проекты заставляя народ разбираться с вашими идеями .

Вы случайно не ПМом работаете? Мой ПМ на никому не нужном «гнилом» проекте в бодишопе поучает меня очень похожими фразами.

Нет, на текущей работе я всего лишь типа джуниор :) но довелось поработать в команде с умниками, которые постоянно искали новые решения (то на стороне то внутри себя), но по факту избегали доделки текущих багов типа та это 5 минут дела, к тому же своими переделками порой делали систему нерабочей. Дошло того что довелось две недели ждать пока один закончит очередную переделку архитектуры, до отпуска он сделать ее не успел, и ушел в отпуск на 2 недели. Потом вышел и через день заболел и еще две недели пропал. А из-за несправленных ним на сервере багов, я не мог отладить и сдать клиентскую часть полтора месяца. При моей зп 2500$ в месяц, насколько пострадал проект? а если еще учесть что временные задержки это как оказалось в дальнейшем стало причиной безперспективности проекта, то на месте инвестора я бы такому девелоперу устроил бы жесткий анал :)

Бла, бла, бла, 2500$ бла, бла, бла.

но довелось поработать в команде с умниками, которые постоянно искали новые решения (то на стороне то внутри себя), но по факту избегали доделки текущих багов типа та это 5 минут дела, к тому же своими переделками порой делали систему нерабочей.

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

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

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

то на месте инвестора я бы такому девелоперу устроил бы жесткий анал :)

Знаете, тут еще неизвестно как ситуация с IPO Facebook-а закончится, программы количественного смягчения Q3,4,5 и тд. . плюс цепная реакция по всему фондовому рынку и американской экономике вцелом. Пока что более вероятно жесткое наказание инвесторами друг друга, в попытке найти хоть какую-то ликвидность. А девелоперы, будут дальше разрабатывать проекты с людьми у которых на первом месте — сделать, а на втором — заработать, но не наоборот.

Конечно свои баги должны были править, но типа из-за текущих работ им просто было некогда :) На таких как я зарплатниках можно было делать, только я там оказался единственный работающий даже по ночам и по выходным, так как я реально думал что проект интересный и попрет если сделать на уровне. Остальные по факту либо по уровню такие никакие, либо им было все пофиг кроме зарплаты. Вот у меня как раз на первом месте всегда было и будет сделать, зарплата для меня на втором месте, хоть ее уровень и стабильность конечно же важны, так как нет желания отвлекаться на дела не связанные собственно с кодингом и искать себе левые подработки, или другие источники денег. К сожалению доходы айтишников привели в бизнес огромное количество «охотников за зарплатами» в большинстве случаев с завышенной самооценкой и нежеланием заботиться о проекте как о своем детище. Как и сказано этот народ неготов работать больше положенного, вкладывать больше возможного и помогать всем с кем работает, пришел отсидел максимум таски поделал, и в день зарплаты ушел с работы раньше.

Ну вот как назвать работников у которых висит в разделе о нас уже почти три года в первой строчке вот такой текст: «создан для того, чтоб сделать доступ к информации удобным и быстрым, по средствам продажи». А сколько функциональных приколов и проколов на самом сайте, а сколько прой. ов пм и ух, я когда-то начал выписывать за два часа 6 листов A4 накатал, из них уже год половина так и не исправлена :)

Для меня талантливый девелопер тот, кто делает рутину быстрее остальных, и результат его работы стабильнее и быстрее, чем у сотрудников этого же офиса

Вы даже не представляете что Вы только что ляпнули .

Хорошо, называйте что в вашем понимании рутина? Ну и собственно талант?

Рутина — это последствия чьей-то непродуманности. Талант — это умения и способности одного человека, которые попадают в «болевую точку» способностей и умений другого человека, в следствии чего второй воспринимает первого как «Таланта» .

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

10% . Ну то Вы перегнули. Эпизодически — 1 на 2000 человек! Постоянно — 1 на 5000 и менее. И это там, где инновацию стартануть можно просто по собственному желанию, будучи в любой должности.

Просто посчитайте, СКОЛЬКО в год сотруднику платит компания! Подумайте, скольким людям Вы лично заплатили такие деньги, и за что? Потому — прекращайте «мнить» себя яркими личностями и т.д., будьте ими. Но ещё больше — прекратите мнить себя «винтиком» в большом механизме. Вы — очень дорогой винтик, Вам платят — не за механику, а как раз за человеческие способности.

Заниматься инновациями — не значит генерить фонтан стратегических мега-идей. А хотя бы ОДНУ простую идею за год. Или поучаствовать в том же мозговом штурме, даже просто отсеяв плохие идеи. Не обязательно рождать идею ребрендинга компании или переезда в ноый супер-пупер офис.

Ну вот оцените — моя идея для этой компании: Чтобы описать только сами принципы понадобился текст на N страниц. Это говорит о бюрократии. Заставить такую систему работать на человеческую цель — невозможно, будучи системой с простыми но строгими математичесикми формулами, не имеющими в основе НИКАКОЙ полезной модели — система СТРЕМИТСЯ к своей, арефметической цели!

Систему выгодно изменить, добавив к ней ВОЗМОЖНОСТЬ экспертной оценки, и именно экспертную оценку ставить во главу угла. В основе должны лежать — принципы качества!

Почему так: Для каждой должности, каждой роли — своя, индивидуальная формула успеха. Например, нанимая водителя маршрутки, важнее его ВНИМАТЕЛЬНОСТЬ, а не опыт работы, не рекомендации, и даже не опыт работы на конкретном типе автобуса. К примеру участие в ДТП — уже требет детально рассмотреть подробности ДТП прежде чем принимать (кстати, ДТП может дать и положительную характеристику). Ключевая оценка — ставится в результате тест-драйва: если человек закрыл дверь не дождавшись выхода пассажиров, быковал, возил «как дрова» и создавал аварийные ситуации на дороге — пусть он там хоть семи пядей во лбу, но КРИТЕРИИ КАЧЕСТВА для данной должности он не прошёл, если ХОТЯ БЫ ОДИН завалил. Их нужно не сложить, а умножить. К примеру — вождение 9 из 10, контраварийность 2 из 10, вежливость 3 из 10, мягкий стиль вождения 2 из 10. Степень соответствия 0,9*0,2*0,3*0,2 = 1%. И это я ещё не ставил коэффициенты по правилу Парето (если есть система качества, то она даст более точные). Вот где Вы увидите, НАСКОЛЬКО все люди разные, и что за деньги которые Вы платите, Вы имеете право быть крайне требовательным «покупателем».

Для девелопера ещё сильнее: если он пишет код, который потом не читается, если пытается применять «стандарты» абстракций вместо того чтобы делать конкретику, если пытается делать стиль вместо логики, и главное — если стремится сделать программу линейной, все сложности алгоритма оставив конечному пользователю — он г-кодер, а не сеньор, и тем более не тимлид и не PM. Могу утверждать: большинство остаются г-кодерами на всю жизнь, а будучи возведённым в ранг лидера — убивает таланты. Потому среди юниоров больше талантов, чем среди опытных: таланты рождаются и умирают: рождаются тяжело и редко, а вот убить — система может, и будет убивать если только ей это спускать с рук.

Система — боится талантов. Потому что тогда само строительство и управление системы будет требовать талантливых людей, а «к кормушке» обычно ставят родственников/знакомых, кто не способен позаботиться о себе сам.