Come work in Estonia – the most advanced digital society. Many Ukrainians already know that Estonia is affordable – become one of them and check out the jobs available!

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

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

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


© Andy dot Moore

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

В какую сторону мы идем?

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

Кадры решают все

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

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

Что в имени тебе моем?

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

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

Среди нас много талантливых людей.

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

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

Что это изменит?

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

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

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

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


Personal Evaluation Form

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

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

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

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

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

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

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

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

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

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

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

Лучшие комментарии пропустить

У подобной системы, когда формулируются требования к должностям и «грейдам» и потом к ним же привязывается фиксированная ставка зарплаты есть свои плюсы и минусы:
+ Это все-таки логически обоснованная и более-менее объективная система. А не «сколько выторговал» или «как босс решил».
+ От сотрудника на определенной должности можно ожидать некоторой «универсальности». Т.е. он может написать хороший код + еще сносно написать техническую документацию, поговорить с клиентом, сделать доклад на конференции, выжить в самолете и т.д.
+ Сотрудник становится «сертифицированным товаром», наподобие компьютеров. Их удобно считать «по головам» и управлять ими можно одинаково. Это упрощает работу начальников.
+ Исчезает конкуренция за зарплату, лучший проект или другие бонусы. Проще «тасовать» кадры и заполнять вакансии.
— Зарплата сотрудника теперь полностью зависит не от знаний и опыта — а от соответствия критериям. Т.е. целью развития сотрудника становится не собственный рост, а прохождение аттестации. Это как экзамен в ВУЗе — выучить что бы сдать и забыть.
— Специалист в отдельной области получит среднюю оценку хуже, чем середнячок по всем параметрам. Т.е. SQL гуру, который способен поддерживать огромную и тяжело нагруженную «живую» базу, но хорошо не знает ничего другого (включая английский), навсегда останется «мидлом» (пока не уйдет на зарплату синьора в другую компанию).
— Эта система никак не поощряет сотрудника развивать свои сильные стороны — только подтягивать слабые.
— Вместо команды разнородных специалистов, каждый из которых умеет что-то делать замечательно получим команду середнячков, из которых никто замечательно сделать не может. Т.е. качество всегда будет не выше среднего (а если еще и начальство среднее — то и вообще посредственное).
— Во всей компании не будет к кому обратиться со сложной технической проблемой. Придется нанимать узкоспециализированных консультантов со стороны.
— Принцип Питера будет работать: сотрудник, который получает 5 — продвигается выше. Как только на новой должности он получает 3 — он на ней останавливается. В итоге начальник всегда будет справляться со своими обязанностями средне.
— Невозможно платить очень нужному человеку больше в обход системы. Или придется искусственно завышать ему оценки. Примерно как в школе: победил на олимпиаде по физкультуре — математику и физику поставили «автоматом».
В целом эта система означает переход от хаотичного «научного поиска», как в ВУЗе или «творческого развития», как в лицее, к формальной дисциплине как в общеобразовательной школе или армии. В итоге можно рассчитывать на стабильно средние результаты, но «прорывов» и блестящих идей ждать не стоит.

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

92 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

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

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

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

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

Очередная брократическая сказка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выписываем критерии и ставим им в соответствие вес:
— вождение 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 накатал, из них уже год половина так и не исправлена :)

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

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

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

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

Даже в самых инновационных компаниях инновациями занимаются ну 10% сотрудников максимум. Иначе она просто прибыли не приносит — продавать то надо результаты работы, а не инновационные идеи.
Остальные 90% же просто должны делать то, что от них требуется, получать за это деньги, развивать свои профессиональные навыки, чтобы получать еще больше денег, и не мнить себя «яркими креативными личностями».

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

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

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

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

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

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

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

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

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

Вот где Вы увидите, НАСКОЛЬКО все люди разные, и что за деньги которые Вы платите, Вы имеете право быть крайне требовательным «покупателем».

«А у вас есть такой же, только с перламутровыми пуговицами? Будем искать...»

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

А иначе вот так www.youtube.com/...h?v=2wxL3DYen5g

Та блин ну все же просто. Сомтрим человекочасы на решение проблемы и делаем выводы.. прогер может быть сильный но лентяй знатный :) Вот и неизвестно кто быстрее справится с задачей трудяга джуниор или лентяй-распиз...й сеньор :)А реальный левел можно проверить просто сначала даем задачу на те знания которыми он якобы уже обладает, а потом даем новую для него задачу и смотрим за сколько он разберется с неизвестной технологией или найдет решение для нестандартной задачи :) но опять ж это не повод делать зп по результатам! Поверьте лучше переплачивать 200-500$ прогеру который может и работает не так быстро, чем недоплатив ему эту пару сотен потерять его (уйдет где больше платят), остановить работу над проектам, платить левым ХР за поиск нового, а потом еще ждать пока новый типа быстрый и классный работник втянется в проект, и дай бог чтобы проект вообще не оказался похороненным, из-за того что вы зажали несчастных 3-5 тыс $ прогеру, а проект обошелся в 50 тыс $.

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

Есть проверенный веками факт: чем больше человек знает, тем больше он понимает сколько всего ещё НЕ знает!
Например: Вы в политике разбираетесь? А в футболе? А в сексе? В жизни?

Другой пример — эти тёти вообще в курсе, что складывать эти показатели нельзя? Что некоторые надо умножить? Правило Парето (деление 80/20) применяли? Или тупо всё в эксельке сложили — и вуаля цыфирька.

Может человек вообще сильнейший профи в 1 области, а в остальных не дотягивает? По формуле — неподходит. Реально — команда с лёгкостью бы компенсировала отсуствующую мелочь джуниором, но усилилась бы профессионалом экстра-класса.

Пример: человек не знает UML. И что теперь, проект рухнет? Другой пример — не знает CVS, а версиализация на нём. Всё, сели начали плакать :). Третий пример — всё знает и умеет, но «работает один», по баллам его возьмут. Кто не в курсе, это якорь на шею всей команде :( :( :[#]

Пример: человек не знает UML. И что теперь, проект рухнет? Другой пример — не знает CVS, а версиализация на нём. Всё, сели начали плакать :)

Это говорит всего лишь о том, что требования излишне специфицированы. Например, можно говорить не о UML, а об умении спроектировать и задокументировать архитектуру системы. Не о CVS, а об умении грамотно работать с системами контроля версий. И так далее.

Может человек вообще сильнейший профи в 1 области, а в остальных не дотягивает?

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

Третий пример — всё знает и умеет, но «работает один», по баллам его возьмут.

Это довольно просто покрывается добавлением «в формулу» еще и так называемых soft skills, в частности, оценки умения работать в команде.

«Справляется не очень хорошо» — не то слово. Вредит! Отравляет процесс! Стремится к посредственности и уравниловке!

Не «soft-skills», а психологичесике доминанты! Движущие силы команды. Эта система — набирает в команду людей по принципу «лебедь, рак и щука». Скрам из этого получается — душевный, вот только КОД потом так и работает как лебедь, рак и щука.

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

Читаю эти все тексты про сотрудников, как оно меня умеляет... Украинский аутсорс нагло использует людей, не платит налоги или уходит от них, выганяет людей почем зря... При этом пыжаться про потребность в классных сотрудниках =)

«не платить налоги» — Вы так говорите, будто это что-то плохое

Вы так говорите, будто это что-то плохое
Если отбросить театральные моменты про «эту власть», то однозначно плохо.

даже если убрать и при этом хорошо подумать.

да, это плохо. вы видели дороги и уровень жизни в ЕС, США, Канаде?

Это все сделали люди своим трудом, а не государство и не надо делать из государства «золотого тельца» которому надо поклонятся.

или по вашему без государства хороших дорог не будет уровень жизни будет не тот?

или по вашему без государства хороших дорог не будет уровень жизни будет не тот?

Да. И это не по его или моему, это так рассказывали в ВУЗе на всяких не технических парах.

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

«Кое-где существуют еще народы и стада, но не у нас, братья
мои; у нас есть государства.
Государство? Что это такое? Итак, слушайте меня, ибо
теперь я скажу вам свое слово о смерти народов.
Государством называется самое холодное из всех холодных
чудовищ. Холодно лжет оно; и эта ложь ползет из уст его: „Я,
государство, есмь народ“.
Это — ложь! Созидателями были те, кто создали народы и
дали им веру и любовь; так служили они жизни.
Разрушители — это те, кто ставит ловушки для многих и
называет их государством: они навесили им меч и навязали им
сотни желаний.
Где еще существует народ, не понимает он государства и

ненавидит его, как дурной глаз и нарушение обычаев и прав.»

Критическому мышлению и способности изучать суть вещей тоже учили...

Да учили. И поэтому после фразы:

Это все сделали люди своим трудом,

Я задаю вопрос:

А кто принял решение о постройке дороги? Кто выбрал место? Кто оплатил труд? Кто защитил работников от бандитов? Кто не дал работникам растащить материалы (это к теме качества)?

Где еще существует народ, не понимает он государства и

ненавидит его, как дурной глаз и нарушение обычаев и прав

Красивые слова! Вот только не имеющие смысла, так как государство — это форма тех самых «обычаев и прав». Иногда эта форма хорошая, а иногда ... бывают плохие дороги ;)

А теперь занад к умению думать:

не надо делать из государства «золотого тельца» которому надо поклонятся.

и не платить налоги — это очень мало связанные понятия.

Кто принял решение? марсиане Люди!
Если внимательней присмотреться то там где хорошие дороги самоуправление развито на высоком уровне.

Там же где «плохие дороги» центральное управление.

Государство это не форма это организация которая меня например не устраивает в нынешнем положении.

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

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

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

Там же где «плохие дороги» центральное управление.

То есть при самоуправлении не надо платить налогов?

куда уходят мои деньги или не согласен куда они тратятся,

Я же предложил:

отбросить театральные моменты про «эту власть»

Кто принял решение? Люди!

Наш сценарий!

1. Кто принял решение строить дорогу? Люди!
2. Кто принял решение закупить песка за 100500 денег, а не за 100, ну шоб всем хорошо было, чисто из побуждений гуманизма? Люди!
3. Кто потом из этого песка половину с...л? Люди!
4. Кто потом по вечерам бухал на вырученные деньги? Люди!

5. Кто потом дорогу строил? (Доагатайтесь сами)

Вы абсолютно правы.. Люди.

Вы абсолютно правы.. Люди.

Україна для людей!

Я живу в городе который топ 10 лучших для жизни на украине, почему? Потому что здесь продают много товаров. Експортируют из моего города товары в другие страны. Соответственно большой приход денег. У нас в налоговой для людей ЛСД 30 дюймовые телеки повесили. У многих налоговых ЛСД висят? (Не учитывая киев) А вы говорите налоги не платить...

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

У нас в налоговой для людей ЛСД 30 дюймовые телеки повесили. У многих налоговых ЛСД висят?

рукалицо.jpeg

У меня на сегодня закончились доводы...

Ты не понял, это означает, заботяться о людях. Если есть деньги на телеки, то и дороги сделают, и садики, и школы, больницы...

Если есть деньги на телеки, то и дороги сделают, и садики, и школы, больницы...

16-летние тру анархисты четко знают что деньги есть только на телеки и на дороги ... к даче начальника налоговой.

Та ладно, люди развиваються, думаю дело будет у нас в стране, когда то только сельхоз был, щас проги пишут... =)))

Вы кладете дороги за свои (не заплаченные в налоговую) деньги, я правильно понял?

Та не вы что =) Гос администрация вроде, а если честно не знаю... На соседней улице вот 500 метров кто то сам положил...

Это я спрашиваю у Evgen Petrov вольный каменщик....

а если честно не знаю...

Это тут ключевой момент. Не знаете — значить вам это до лампочки ;)

У подобной системы, когда формулируются требования к должностям и «грейдам» и потом к ним же привязывается фиксированная ставка зарплаты есть свои плюсы и минусы:
+ Это все-таки логически обоснованная и более-менее объективная система. А не «сколько выторговал» или «как босс решил».
+ От сотрудника на определенной должности можно ожидать некоторой «универсальности». Т.е. он может написать хороший код + еще сносно написать техническую документацию, поговорить с клиентом, сделать доклад на конференции, выжить в самолете и т.д.
+ Сотрудник становится «сертифицированным товаром», наподобие компьютеров. Их удобно считать «по головам» и управлять ими можно одинаково. Это упрощает работу начальников.
+ Исчезает конкуренция за зарплату, лучший проект или другие бонусы. Проще «тасовать» кадры и заполнять вакансии.
— Зарплата сотрудника теперь полностью зависит не от знаний и опыта — а от соответствия критериям. Т.е. целью развития сотрудника становится не собственный рост, а прохождение аттестации. Это как экзамен в ВУЗе — выучить что бы сдать и забыть.
— Специалист в отдельной области получит среднюю оценку хуже, чем середнячок по всем параметрам. Т.е. SQL гуру, который способен поддерживать огромную и тяжело нагруженную «живую» базу, но хорошо не знает ничего другого (включая английский), навсегда останется «мидлом» (пока не уйдет на зарплату синьора в другую компанию).
— Эта система никак не поощряет сотрудника развивать свои сильные стороны — только подтягивать слабые.
— Вместо команды разнородных специалистов, каждый из которых умеет что-то делать замечательно получим команду середнячков, из которых никто замечательно сделать не может. Т.е. качество всегда будет не выше среднего (а если еще и начальство среднее — то и вообще посредственное).
— Во всей компании не будет к кому обратиться со сложной технической проблемой. Придется нанимать узкоспециализированных консультантов со стороны.
— Принцип Питера будет работать: сотрудник, который получает 5 — продвигается выше. Как только на новой должности он получает 3 — он на ней останавливается. В итоге начальник всегда будет справляться со своими обязанностями средне.
— Невозможно платить очень нужному человеку больше в обход системы. Или придется искусственно завышать ему оценки. Примерно как в школе: победил на олимпиаде по физкультуре — математику и физику поставили «автоматом».
В целом эта система означает переход от хаотичного «научного поиска», как в ВУЗе или «творческого развития», как в лицее, к формальной дисциплине как в общеобразовательной школе или армии. В итоге можно рассчитывать на стабильно средние результаты, но «прорывов» и блестящих идей ждать не стоит.

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

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

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

Ну сказано ведь было классиками en.wikipedia.org/...o_Silver_Bullet , умнее не скажешь.

і знову оутсорс/бодішоп — кака, а продуктова компанія — рай на землі?

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

Ну так каждый же у нас мнит себя как торвальдсом или фаулером, оттого и баттхёрт. При этом «яркая индивидуальность» выражается, как правило в изобретении бажных велосипедов и выкладывании мыльных зеркалкошедевров во фликер и фейсбук.

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

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

Вот интересное заявление. Торвальдсов в принципе мало! А КАК они откроются, если не будут писать велосипеды. Опять же, Торвальдс не бог, и не сверхчеловек, он просто ЗАДАЛСЯ ЦЕЛЬЮ и шел к ней. А секрет в том, что его ПОДДЕРЖАЛИ! а не забросали какашками, мол ты такой-сякой велосипеды пилишь, бери кредит на покупку Юникса и не вые...

потребность в них довольно-таки ограниченна

Это все отмазки. В 90-м году Торвальдс, рядовой финский студент, тоже никому не был нужен. Она САМ СДЕЛАЛ себя нужным, сделав что-то большое и светлое :)

А посему, заявляю: здравая критика рулит, бросателей какашек — в топку. Мы сами себя загоняем в яму своим же менталитетом! У соседа корова появилась, хоть кривая, хоть больная, нужно обязательно ему по этому поводу подгадить ... пИчалька =(

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

© :)

Где именно мало — в Luxoft?

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

В прикладной разработке — собаку съел. И вот здесь узкая специализация просто позарез. И нужно понимать в первую очередь свой «человеческий фактор», а именно — что технологии тебе подчиняются, а не наоборот. А уже «for fun» или «for business» — не принципиально. Я более чем уверен, заказчик сам потом отдаст этот функционал клиенту бесплатно. Например: В ресторане не берут отдельно за мясо, за специи, за готовку и за вино — там берут «for fun», а потом ещё и на чай сверху.

Удовольствие заказчика — дорогого стоит. Если ваши «Торвальдсы» умеют его делать — флаги им в руки. А есть и такие, кто может удовлетворить клиентов заказчика.

Хорошая аналогия. Так промышленная разработка софта — это ресторан или может предприятие другого типа?

По организации процесса очень близка к бизнесу общепита. И те же по сути проблемы: линейный персонал не оценивают по уровню качества результата. А клиент оценивает прежде всего по качеству результата.

И согласитесь, кулинары готовящие «just for fun», даже дилетанты — готовят на порядок лучше шеф-повара средней забегаловки.

Математика здесь не работает! Сделав код на 1% хуже, он превращается из полезного во вредящий. А на 1% лучше — может стать на +100% более полезным.

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

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

= финансовая дыра.

И финансовая дыра в эксплуатации стоит намного дороже любых задержек по времени и перерасходов бюджета программирования. Этому и учит теория качества. :)

И согласитесь, кулинары готовящие «just for fun», даже дилетанты — готовят на порядок лучше шеф-повара средней забегаловки.

У них задачи разные. Макдональз держится не на шеф-поваре, а на стабильном качестве, обеспеченном промышленными методами, работающими далеко за пределами «забегаловки just for fun».

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

Это вам кто сказал? «Практически бесплатна» — только стоимость технического копирования. Даже доставка — и та будет стоить определенную копеечку в промышленных объемах.

Этому и учит теория качества.

Пруфлинк? :)

пруфлинк rutracker.org/...c.php?t=3248058

Кстати, МакДональдс держится на том, что он МакДональдс. Попробуйте построить забегаловку с таким же качеством, но не Мак (то есть не бренд) — и результаты будут куда скромнее. Я бы даже делал ставку на убыточность.

Потому постройка ещё одного МакДональдса получит клиентов сразу. И не понесёт убытков на раскрутку. Аналогично веб-проект, не несёт затрат на обслуживание +1 нового пользователя. И даже затраты на + 10 000 новых юзеров — минимальны.

Я лично хотел бы участвовать в проекте сродни МакДональдсу. И считаю бренд — ключевым фактором успеха программных проектов. Но строить бренд без фундамента качества — всё равно что небоскрёб на болоте: дорого и нерентабельно уже на первых этапах.

Ясно. На самом деле это даже хорошо что есть такое видение и что оно — популярно.

Те, кто мнит себя Торвальдсом настолько, что готовы писать код с удовольствием, как «для себя», а не г*внокод из-под палки — ПИШИТЕ КОД, и не слушайте бездарей!

А кто грезит наймом посредственностей — купите ОТЕЧЕСТВЕННЫЙ велосипед, и отъедьте километров за 30 за город. Просто чтобы поучвствовать, каково потом клиенту! А как будет себя чувствовать клиент Вашего клиента??

Тем более, при нынешних объемах услуг по аутсорсинговой разработке на украинском рынке труда тупо на найдется столько «звезд»

на найдется столько «звезд»

Звезды не «находятся» в аутсорсе, они с неба падают )

Да все субьективно. Кому-то нравиться аутсорс т.к. там все модно, кто-то не выносит к себе отношения как к товару. Каждому свое.

Сравнивать собственное дело, продуктовую компанию, и аутсорс — всё равно что роль жены, любовницы и проститутки:

Выбор конечно за каждым, но потом поменять этот выбор очень проблемно. И смею заметить, разный возрастной ценз!

Не будем лукавить, 20-летние аутсорсу гораздо интереснее 30-летних. А 35 фактически неликвид.
В продуктовой компании можно задержаться и до 45, но и там наступают кризисы, и решать их пытаются зачастую «традиционными» методами. Устроиться после 40 в продуктовую компанию — очень сложно.

Собственное дело невыгодно как раз поначалу. Но именно оно может кормить и после 70. Притом по расходной части, именно сотрудники 30+ будут приносить прибыль. И эта планка поднимется ещё выше, если часть работы... отдавать на аутсорс :)

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

Зарплата сотрудника теперь полностью зависит не от знаний и опыта — а от соответствия критериям

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

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

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

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

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

Остается нерешенным главный вопрос: как же создать объективную и справедливую систему расчета зарплаты? Если мидлы могут получать больше чем синьоры, то звания ничего не решают и опять возвращаемся к торговле: один уникальный специалист, другого клиент любит, третий родственник босса

Если исключить сценарий «родственник босса» (в смысле привелегий и зарплаты) как ИМХО очень нетипичный для IT-индустрии, то в остальном зарплату и так регулируют, с одной стороны, рынок труда, с другой — норма прибыли, мотивируя бизнес платить меньше легко заменяемым специалистам, и больше — имеющим уникальные компетенции. Уметь нравиться клиенту — это, кстати, тоже компетенция, только не техническая.

Другое дело, что линейные системы грейдирования а-ля «junior->middle->senior», мне кажется, не очень хорошо справляются с оценкой роста «вширь и вглубь» — отсюда и когнитивный диссонанс «мидлы могут получать больше сеньоров». Один из простых вариантов решения — это делать разветвленную систему грейдов, когда после определенной точки человек может расти либо как архитектор, либо как именно хардкорный технарь, либо (при наличии нужных скиллов) вообще начать менеджерскую карьеру, став тимлидом, а, впоследствии, и ПМом.

Другое дело, что линейные системы грейдирования а-ля «junior->middle->senior», мне кажется, не очень хорошо справляются с оценкой роста «вширь и вглубь» — отсюда и когнитивный диссонанс «мидлы могут получать больше сеньоров».

Тогда зачем вообще такие «грейды» и звания? Оценивать человека по 20 разным критериям, включая как технологии так и английский и «лидерство», «креативность» и другие абстрактные оценки, что бы потом посчитать «средний бал» и присвоить ему ярлык «синьор»?!
Лучше тогда просто сделать 100 независимых оценок (можно сторонние сертификации) по каждому пункту от 0 (даже не слышал) до 100 (гуру — может все). И больше никакой «обобщенной оценки», «грейда» или звания.
Тогда не будет проблем со справедливым расчетом зарплаты и соответствия должности. Пишем на должность требования, вроде: HTML — 40, Java Script — 30, ООД — 20, Java — 50, English — 30. Или, наоборот: DICOM — 80, Java — 30. По каждой технологии считаем «цену»:
(0 — 20) = $300, (20 — 40) = $500, (40 — 60) = $800, (60 — 80) = $1000, (80 — 95) = $2000, (95 — 100) = $1000(час). Перемножаем, суммируем — получаем сколько стоит вакансия. Потом оцениваем кандидатов и сопоставляем оценки. Если у человека оценка на 30% больше чем надо — оверквалифаед, если на 30% меньше — не годится, если немного не дотягивает — вот для сотрудника и есть план развития на ближайшее время и четкая прибавка, которую он получит если подучится.

Требования к должностям и оценки сотрудников можно сделать открытыми внутри компании. Тогда во-первых: можно легко увидеть где сотрудник «перерос» свою должность и куда ему можно предложить переместиться; во-вторых: понятно к какому «гуру» идти с проблемами. А клиент уже пусть платит, на сколько его «раскрутят». Если он готов платить рейт синьора за сапортный манки-джоб то компании совсем не обязательно держать на этой должности настоящего специалиста — для него найдется работа поважнее.

Все бы ничего, но судьи кто? Кто скажет, что HTML — 40, а не 30 и т.д. и на основании чего?

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

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

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

Пишем на должность требования, вроде: HTML — 40, Java Script — 30, ООД — 20, Java — 50, English — 30

Так «звания» — это просто алиасы к множествам требований )

Это чистой воды подводный камень для аутсорса. На так называемых продуктовых компаниях проекты нечасто меняются.

Не путайте сеньора, тимлида и манагера проекта. Например при разговоре с заказчиками нужно выставлять 2 человека: Один знает максимально все положительные/отрицательные стороны, понимает объёмы рисков, может предложить что-то за какие-то деньги, но много преукрашает (читайте врёт). Второй — максимально знает детали, ответсвенный за реализацию, знает где грабли, а где есть готовые пробитые головой стены (конкурентные возможности) — продать сам он не может (знает реализацию, но не так очевидно видит выгоды), но ему всегда можно верить.

Сеньор — и есть узкопрофильный специалист. И чем сильнее — тем узкопрофильнее. Он даже может (должен) менять этот профиль от проекта к проекту, но остаётся узкопрофильным.

Кстати, человек может владеть несколькими специальностями. РАЗНЫМИ. Но что касается близких — они исключаются, например нельзя сеньору в одинаковой мере владеть С++ и Java, это как быть православным буддистом. А Юниорам — так и нужно.

ЗЫ. Хороший программист с клиентом поговорить и не может! Иначе последствия такого разговора потом будут разгребать юристы. Всё равно что спросить байкера, с какой максмиальной скоростью он может подвезти до аэропорта — вряд ли клиент действительно расчитывал на экстрим. Собственно, Такси все смотрели :)

А в бодишопе — такая система убьёт КЛИЕНТА бодишопа! Клиент-то находится на рынке, рынок — любит инновации, а «вчерашний день» — не любит. Особенно там, где доля IT-технологий в продукте велика.

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

Если бы руководство клиента понимало, КТО ВИНОВАТ,... они бы сыграли в Postal 2 в офисе компании.

Хорошие программисты хотят работать с другими хорошими программистами. Как только качество программистов в вашей компании падает, вы входите в спираль, из которой невозможно выбраться.
habrahabr.ru/...01595/#habracut
Клиент-то находится на рынке, рынок — любит инновации, а «вчерашний день» — не любит.
Я думаю принцип Парето работает и для ИТ: 80% приложений, который пишутся на самом деле никому не нужны, и только 20% — действительно полезны. Зачем же их пишут: да потому что у клиента в компании только 20% работы приносит доход, а 80% — просто деньги, выброшенные на бюрократию (сделать сайт что бы было как у других).
Я бы сказал что в итоге 80% проектов в бодишопе это как раз «вчерашний день» и «халтура» (quick and dirty). И только 20% — какие-то инновационные или R&D проекты на новых технологиях, с толковой командой и грамотным процессом разработки.
И вполне может быть что 80% клиентов как раз «умирающие организации» для которых этот аутсорс- проект станет их «лебединой песней». Именно поэтому бодишоп модель и побеждает — она снимает любую ответственность за финансовый успех проекта с подрядчика, ведь бодишоп только продает людей.

Это — кризис. И уже далеко не 80 на 20, компютеры лекго возводят пропорцию в степень. И смею заметить если выживет только 5%, они с лёгкостью поглотят 95% рынка! Как рынка труда, так и клиентов.

Поднимите руку, кто сейчас работает в будущем Майкрософте? [Не удивлюсь если кто и в настоящем :) ]

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

Принцип Парето в ИТ однозначно работает. Ряд сведений дают основания полагать, что он здесь задвинул шляпу гаусса далеко в чулан

а что, если так:
система оценки является базисом для грейда
з/п пересматривается в параллель. причем, аргументами за повышение могут быть как повышение грейда(тогда повышается «ставка»), так и необходимость/критичность/уникальность скиллов на текущем проекте(тогда накидываются бонусы-премии в рамках бюджета текущего проекта). в таком случае, и овцы сыты(формализированный процесс), и волки целы(не в ущерб гибкости и здравому смыслу).
а насчет
сотрудник, который получает 5 — продвигается выше. Как только на новой должности он получает 3 — он на ней останавливается
то если вместо «3, 3, 3, 4, 5, 3, 3» человек получит конкретные, исправляемые замечания — то все может быть намного радужнее :) одно дело «ты не справляешься», другое — «надо подтянуть то, то и то».
Соответственно для девелоперов: середнячок, хочешь денег — проходи оценку в бодишопе; творческая личность, умеешь что-то действительно хорошо — добро пожаловать в продуктовые компании и стартапы.

какоето очень неправильное сравнение продуктовых и аутсорс компаний

Подписаться на комментарии