От стажера до эксперта: матрица компетенций разработчика 1С

20.09.21

Саморазвитие

Работа с разработчиками 1С предполагает постоянное развитие их компетенций. Сотрудников надо мотивировать на совершенствование, в том числе путем повышения заработной платы. Но как понять, за какие компетенции сколько платить? Какой навык для работодателя более ценный? О том, как устроена система оценки компетенций в компании ФТО, рассказал ведущий разработчик и руководитель разработчиков 1С проектного отдела Виталий Онянов.

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

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

Ссылки:

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

Хотел бы сразу сказать, что это не будет какая-то история типа «смотрите, какую штуку мы сделали, она крутая получилась, используйте ее тоже». Это будет, скорее, история про то, что мы хотели сделать, что получилось, а что нет. Плюс какие-то мои личные мысли на эту тему.

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

 

 

Ну а тем кто остался, приятного прочтения. =)

 

О компании

 

 

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

  • Компания ФТО – крупный интегратор. Количество сотрудников перевалило уже за 300 человек.

  • Из них разработчиков 1С, по последней переписи, 70 человек, не считая довольно большого количества декретниц.

  • Разработчики в нашей компании работают совместно с аналитиками.

  • Как правило, наши разработчики занимаются потоковой разработкой по функциональному дизайну либо отрабатывают по заявкам пользователей. Главное – они не общаются и не видят конечного пользователя, не занимаются настройкой 1С, администрированием, не ездят к клиентам. У нас разработчик – это только разработчик, и ничего более.

  • Раньше мы располагались в двух городах – Омске и Краснодаре, но в последнее время мы наняли и продолжаем нанимать много людей в других городах, и уже можно говорить, что у нас распределенные команды, что особенно актуально сейчас, во время режима самоизоляции.

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

Все это вынудило нас в свое время разработать некоторую программу обучения разработчиков 1С "с нуля". При этом мы не ограничились студентами, а разработали некую программу развития разработчиков, которая актуальна практически на протяжении всего пути работы разработчика 1С.

Результатом этой работы стало некое «Дерево развития разработчика 1С» – перечень необходимых разработчику компетенций с привязкой к различным учебным курсам, каким-то источникам знаний.

 

Дерево развития разработчика 1С

 

 

Подробно про это дерево и путь Джедая разработчика 1С я рассказывал в докладе на Infostart Event в 2018 году. В докладе можно подробно про это дерево посмотреть.

 

 

Если говорить вкратце, то мы выделяем четыре области развития разработчика:

  • навыки разработчика 1С – его умение программировать;

  • знание предметной области;

  • на каком-то этапе, когда разработчик становится ведущим, ему будут необходимы функции управления, взаимодействия с командой, управления разработкой;

  • и не забываем про личную эффективность.

 

 

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

 

КАК развивать разработчиков 1С? Внедрение системы грейдов

Что развивать, мы поняли. Но если дать ребенку учебник, он не станет от этого умнее. И не надо думать, что все разработчики 1С целеустремленные, постоянно учатся, дай им только учебную программу, и они кинутся ее сразу изучать. Умом они, может быть, и понимают, что нужно постоянно учиться, но на практике, к сожалению, все немного не так.

 

 

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

 

 

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

  • примеры нефинансовой мотивации;

  • систему грейдов;

  • рассказал про постановку целей;

  • контроль выполнения целей;

  • обязательные встречи 1 на 1 и т.д.

Таким образом, мы разобрались:

  • ЧТО развивать в разработчиках 1С;

  • КАК это делать.

Но остался нерешенным самый главный вопрос – вопрос финансовой мотивации.

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

 

Финансовая мотивация разработчиков 1С

 

 

Мы выделили принципы, какой должна быть система мотивации.

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

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

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

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

  5. Система должна отвечать ценностям и каким-то сложившимся правилам компании ФТО. Мы на рынке с 2003 года, у нас уже сложилась какая-то система мотивации, и сотрудники к ней привыкли. Намерения и возможности ее менять у нас не было. Например, была система грейдов. И кроме того, у нас в компании всегда была строго окладная система мотивации: т.е. сотрудники у нас получают только оклад, и из-за переработок возможны премии, которые тоже зависят от окладов. И позиция нашего руководства всегда была и остается однозначной: окладную систему мы оставляем и менять ее не будем.

  6. Последний, довольно тяжелый момент – система должна быть единой для всех отделов компании ФТО. Дело в том, что у нас много различных отделов:

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

    • Есть отдел поддержки, там немного другая специфика, там разработки немного, а много консультаций, исправлений ошибок, обновлений релизов. Тот же самый показатель план-факт здесь не подойдет, потому что разработчик может два дня просидеть в отладчике и подправить две строчки кода. Здесь у нас главное – уровень удовлетворенности заказчика, соблюдение SLA.

    • Есть еще группа развития – это что-то среднее между этими двумя отделами.

    • Иногда продаем наших разработчиков на аутстафф.

    • Кроме этого, есть и другие направления.

    • Плюс разработчики могут переходить между отделами как насовсем, так и временно - поэтому систему мы хотели сделать единую.

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

 

Система грейдов

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

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

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

Мы взяли то дерево развития, про которое я рассказывал, и из формата дерева переложили его в формат таблицы. У нас получилось 4 направления.

 

 

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

 

 

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

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

Например:

  • за навык работы с интерфейсом, знание СКД и за сертификат «1С:Специалист по платформе 1С» мы даем 2 балла;

  • за все остальные навыки – по 1 баллу.

 

 

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

Далее мы начали продумывать, по каким критериям в принципе оценивать разработчиков? Как понять, что один разработчик плохой, а другой – нет?

Мы сформировали определенные требования, после чего в таблицу вошли еще такие строки, как:

  • скорость разработки, план-факт;

  • качество кода;

  • дисциплина самотестирования;

  • и такой субъективный параметр, как «Можно поручить задачу любой сложности».

 

 

Теперь осталось только понять, как проверять каждую из полученных компетенций, чтобы остался тот самый «принцип прозрачности» – чтобы сотрудник пришел к нам и спросил: «Что мне нужно сделать, чтобы подтвердить этот навык?», а мы ему дали абсолютно точный ответ.

 

Проверка навыков

 

 

Как я говорил, для очень многих навыков у нас были и есть учебные курсы – и наши внутренние, и внешние, и какие-то купленные, например, курс по запросам, по СКД, по правам доступа RLS. И мы решили их использовать. Надо пройти курс, сделать все практические задания, защитить экзамен, если он есть, получить диплом.

  • За прохождение курса мы даем половину балла.

  • Вторую половину балла разработчик должен подтвердить навыком на практике.

То есть прошел курс – хорошо, полбалла взял, а теперь подтверди своими задачами, что ты умеешь. И тут мы можем на встрече 1 на 1 поставить разработчику некоторую цель, например, закрыть 200 плановых часов по обменам или по СКД (в зависимости от навыка).

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

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

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

Как я сказал, в проектной деятельности я часто ставлю просто количество закрытых часов – например, закрыть 200 плановых часов на обменах через «Конвертацию данных 2.0».

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

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

У Redmine есть довольно хороший API, мы сделали интеграцию с ним и уже собираем некоторую статистику в своей базе данных 1С, где мы можем смотреть:

  • выработку по план-факту;

  • кто с каким консультантом и с какой производительностью работает;

  • на каких проектах и с какой производительностью работает;

  • и в том числе какие навыки он использует на том или ином проекте.

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

В общем, очень интересная статистика в итоге получилась.

 

Субъективные навыки

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

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

  • 0 баллов – когда каждую задачу нужно рецензировать, и большинство задач уходит на доработку;

  • 1 балл – когда половина задач проходит сразу же в тест после рецензирования;

  • 2 балла – когда только какие-то самые большие задачи необходимо рецензировать;

  • 3 балла – это уже опытный разработчик, который может сам рецензировать код, проводить code review.

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

 

 

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

 

 

Проверка знаний предметной области – сертификаты 1С

Чуть сложнее у нас пошло с предметной областью.

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

То же самое и в поддержке – очень нужны знания предметной области, чтобы быстрее закрывать задачи.

Но как проверить эти знания – не очень понятно.

Например, у нас в проектах разработчик может закрыть 500 или даже 1000 часов на задачах в какой-нибудь 1С:ERP, где будет и блок торговли, и блок управленческого учета, и регламентированный учет, и даже производство. Вот он закрыл 1000 часов, а предметную область так и не выучил, потому что он занимался либо обменами, либо просто доработкой типового или не типового функционала (свои документы/регистры создавал), либо на отчетах просидел… То есть в принципе не совсем понятно, чем он занимался – изучил он предметную область или нет.

Устраивать разработчику экзамен – не вариант. Ведь для экзамена надо придумать какие-то вопросы, и принимать его должен более опытный человек.

Тут нам на выручку приходят сертификаты 1С по различным областям учета. Конечно, можно подискутировать на тему того, насколько реально вообще сертификат 1С отражает знания в предметной области. Лично я считаю, что более-менее отражает.

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

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

 

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

Из-за этого мы пробуем проставлять задачам теги по предметным областям. Если ты считаешь, что эта конкретная задача тебя в конкретной предметной области прокачала – поставь тег, это тебе в зачет пойдет. Но все равно мы не очень понимаем, как проверить, что разработчик силён, например, в управленческом учете. А 2 балла в нашем понимании – это разработчик, который может при необходимости и аналитиком выступать.

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

 

Проверка навыка взаимодействия с командой – обратная связь от аналитиков

Далее у нас был пункт про личную эффективность. Но опять-таки – как проверять личную эффективность, не очень понятно.

 

 

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

 

Поэтому мы подумали – что нам действительно важно? И вместо личной эффективности мы добавили блок «Взаимодействие с командой».

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

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

Как мы собираем обратную связь? Мы написали простые вопросы о работе разработчика и просим аналитиков периодически оценивать разработчиков, с которыми они работают. Это такой внутренний Net promoter score, где по пятибалльной системе мы оцениваем каждый навык.

 

 

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

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

По результатам проекта либо с определенной периодичностью и консультантов разработчики тоже оценивают. Так что это справедливо в обе стороны.

 

Но как я сказал, у нас есть понимание, что 3 балла для навыка взаимодействовать с командой, наверное, маловато, и надо вес этой компетенции увеличивать.

 

Обучение и наставничество

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

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

 

 

Навыки управления

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

А на реализацию своих навыков, которые мы им ставим по предметной области либо по технологическим вопросам, им банально не хватает энергии.

Хотя на самом деле не совсем ясно, что тимлиду важнее – знания управленческого учета на проекте либо навыки управления команды. По идее, обе вещи важны, но приходится что-то выбирать одно.

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

 

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

Причем, мы делаем оценку сверху – опрашиваем ключевых специалистов клиентов, PM-менеджера, функционального координатора, владельца продукта, если он есть.

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

 

Итоговая таблица оценки специалиста по грейдам

В итоге у нас получилась вот такая табличка.

 

Стоимость грейда у нас получилась 5 баллов, а всего 70 баллов.

Максимальный – 15-ый грейд, но это не совсем так. Невозможно прокачаться во всех отраслях: быть и экспертом, и предметную область знать, и командами управлять, и обучать.

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

Вот такая система. Выглядит неплохо, как нам кажется.

 

Выводы

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

Начну очень оптимистично:

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

  2. В целом сотрудники довольно хорошо приняли систему. Хочется, конечно, надеяться и верить, что это благодаря тому, что она прозрачна, безопасна и справедлива или смотри пункт 1.

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

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

  5. Данная система очень хорошо работает где-то до 5-6 грейда, там вообще никаких проблем нет. Что нужно разработчику до 5-6 грейда? Ему нужно изучать новые компетенции, разрабатывать, желательно получше и побыстрее, ему нужно брать самые разнообразные задачи, чтобы все попробовать, ему нужно посмотреть курсы, налаживать контакты с аналитиками и так далее. И цели у них очень понятные, они дают очень быстрый эффект – посмотрел курс, выполнил какие-то задачи, навык получил.

 

Чуть сложнее с опытными разработчиками, здесь не так все хорошо, как хотелось бы.

  1. Дело в том, что сильные разработчики у нас довольно сильно загружены – даже если они не работают ведущими, то все равно у них есть какая-то дополнительная активность, на них ставятся самые сложные задачи, у них физически не остается ресурса выполнять еще какие-то цели, которые лежат вне работы. А поставить цели, которые полностью в рамках работы, у нас не всегда получается, либо, может быть, мы просто не умеем пока этого делать. Нам тут тоже есть, над чем подумать. Кроме того, с новыми сотрудниками иногда бывают проблемы. Не секрет, что мы можем принять сотрудника на работу чуть выше стоимости по рынку. Но потом, когда кончится испытательный срок, мы делаем ему ввод по таблице грейдов, и разработчик может уйти на более низкий грейд. Потому что на собеседовании у нас была необходимость срочно взять разработчика, и мы его взяли авансом. Кроме того, за три месяца испытательного срока не все навыки можно проверить, и для некоторых навыков приходится верить на слово.

  2. Еще наша система не очень хорошо оценивает софт-скилы разработчиков и такие переменные поля, как вклад в работу, отношение к работе. У нас есть выработка, план-факт, взаимодействие в команде, мы опросники делаем. Но если технические скилы мы научились оценивать, ставить цели, тут все хорошо, то с софт-скилами у нас пока есть еще некоторые проблемы. Тут мы ещё находимся в поиске каких-то оптимальных целей, оптимальных решений.

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

  4. Кроме того, люди сразу видят, что они работают на неперспективных проектах. К сожалению, у нас есть поддержки, где самописные конфигурации, какие-то старые «КА1.1», «УПП» и даже проекты на УПП мы еще делаем. И разработчики очень хорошо чувствуют, что текущие задачи в таблицу грейдов, в их рост не ложатся. И мотивировать их работать на таких проектах становится все тяжелее и тяжелее.

 

В общем, и плюсов, и минусов – хватает.

 

Планы

У нас в планах:

  • Изменить баланс, пересмотреть количество баллов за некоторые компетенции,

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

  • И чем больше мы растем, тем больше у нас становится людей, тем больше мы понимаем, что единую систему поддерживать для всех отделов становится тяжелее и тяжелее. Вполне возможно, у нас появятся какие-то отдельные блоки внутри каждого отдела, потому что сейчас договориться о внесении изменений очень тяжело, они должны во все отделах нормально ложиться.

  • В планах развивать систему и дальше – пока она нам нравится, мы ею пользуемся. Надо только кое-что чуть-чуть улучшить.

 

У меня все. Систему грейдов я нигде выкладывать, конечно, не буду, но кому эта тема интересна, пишите в личку, я готов делиться.

 

Вопросы

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

Вполне нормально. Раньше я был противником окладной системы. Я говорил, что должна быть окладно-премиальная часть, что каждый должен зарабатывать столько, сколько ему надо. Но потом я почитал разные книжки по управлению, пообщался с людьми, и понял, что мой тип – предпринимательский, я готов работать усерднее, лучше, чтобы это сразу отражалось. Но оказывается, в России таких людей только 4%, а большинство людей хочет стабильности, хочет спокойствия, хочет не думать о том, сколько они просидели над задачами и сколько денег за это получат. Это вгоняет их в стресс.

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

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

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

Как организован процесс рецензирования кода и работа с ответами?

Через трекер. Каждую задачу, которую разработчик сделал, он переводит на своего ведущего разработчика в статусе «На рецензирование». Разработчик накапливает эти задачи, обычно тестовую базу мы обновляем 2-3 раза в день, тимлид просматривает весь новый код, обновляет базу. Если есть доработки, отправляет на доработку, совместно разбирает. Если это удаленная работа, звонит, делает демонстрацию экрана, мы сидим, разбираем, в чем код неправильный. Если все ок, после обновления теста переводим задачу в тестирование. Мы это делаем через хранилище конфигурации.

Вы пушите изменения в конфигурацию большими блоками или маленькими частями?

Мы стараемся все-таки задачки брать поменьше. То есть у нас есть некоторые правила разбивки задач, и большие задачи мы стараемся декомпозировать. Максимум, наверное, 40 часов, больше 40 часов задачу точно не надо ставить. Потому что она будет бесконечно крутиться в трекере. Если это документ, то отдельно форма, отдельно проведение, отдельно печатная форма, отдельно заполнение табличной части, если он какой-то хитрый. Стараемся декомпозировать по возможности.

А в меньшую сторону вы баллы корректируете?

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

Не думали ли вы вводить допуск к выполнению работ на основе компетенций?

Нет, потому что распределением работ занимается ведущий разработчик. У нас команды обычно по 3-4-5 человек, редко по 9-10 человек. И ведущий разработчик более-менее представляет компетенции своих специалистов. Все задачи ставятся на него, и после оценки и вычитки задания на адекватность, он уже примерно в голове может представить, кто из его команды может справиться. Поэтому пока такой проблемы у нас не было.

Судя по всему, у вас слишком маленький вклад в софт-скилы.

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

Кто у вас занимается оценкой 360, как физически устроен процесс?

Сбором оценки для разработчиков занимаюсь я. А ведущих разработчиков и руководителей оценивают HR. То есть каждый руководитель либо ведущий разработчик раз в год получает полностью оценку 360 от коллег, от смежных специалистов, от руководителя, от тех, с кем он взаимодействует. Этим занимаются HR-менеджеры, они же проводят встречи по этой оценке. А по разработчикам, которые в команде, провожу лично я. Это просто опросник в Google, который я кидаю аналитикам, смотрю, с кем они работали по нашей системе, и вывожу какой-то итог, который мы с каждым разработчиком на встрече 1 на 1 обсуждаем.

Получается, что узкий специалист и многостаночник могут иметь одинаковый балл?

Мы стараемся, чтобы узких специалистов у нас не было. Даже если есть узкий специалист, и горит задача под его компетенции, а он занят на другом проекте, его тимлид никогда не отдаст. Поэтому не могу сказать, что у нас много таких ситуаций. У нас есть специалисты, которые уходят в проектную область, они очень хорошо знают учет и могут с аналитиками вместе работать. Есть специалисты, которые уходят в производительность, сдают на экспертов, всем этим занимаются. А в остальном я бы не сказал, что у нас у кого-то узкие навыки – мне кажется, что в разработке все сильны.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Оценка компетенций специалистов".

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Радио "Аналитик", 15 выпуск 2 сезона. "Путь аналитика" с Ильёй Никитиным. Переход от технической поддержки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

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

18.03.2024    285    0    Radio_Analyst    0    

5

Радио "Аналитик", 14 выпуск 2 сезона. "Путь аналитика" с Натальей Лосевой. Переход от разработки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

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

04.03.2024    351    0    Radio_Analyst    0    

5

Измерение и развитие потенциала сотрудников

Обучение и наставничество Бесплатно (free)

Тема измерения и развития потенциала сотрудников является ведущей последние два года в компании Proaction. Елена Дуюн, руководитель направления «Развитие корпоративной культуры», поделится с нами откровением, которое возникло в процессе исследовательского проекта на платформе Proaction. Елена расскажет о текущей кадровой ситуации, о видах потенциала сотрудников, о том, как оценивать этот потенциал и как мотивировать персонал на саморазвитие.

01.03.2024    369    0    DuyunElena    0    

3

Радио "Аналитик", 13 выпуск 2 сезона. "Путь аналитика" с Анастасией Лощиловой. От финансового директора на заводе до функционального архитектора

Обучение и наставничество Бесплатно (free)

Что отличает аналитика от самурая? Аналитик не прокладывает путь, пока не поставит цель. В серии “Путь аналитика” поговорим, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

20.02.2024    508    0    Radio_Analyst    0    

1

Презентация продукта как искусство

Презентации и публичные выступления Бесплатно (free)

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

12.02.2024    935    0    comol    4    

17

Личный бренд в IT: а оно вообще надо?

Личная эффективность Бесплатно (free)

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

01.02.2024    837    0    mitinskiy    2    

7

Зачем программисту книжки читать

Личная эффективность Бесплатно (free)

Нам с детства постоянно твердят, что книга – лучший друг, книга – лучший подарок, книга – вообще лучшая вещь в мире. Да, это действительно так. Книги явно и значительно влияют на нашу работу, карьеру и жизнь. О том, как правильно читать книгу, как книга вообще влияет на человека, и главное: зачем вообще читать эти книги программисту, сисадмину, аналитику, расскажем в статье.

31.01.2024    2838    0    a_a_burlakov    25    

46

Гореть, но не выгорать: как сохранить ресурс специалистов

Коммуникации Мотивация Личная эффективность Бесплатно (free)

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

15.01.2024    1701    0    KChebykina    0    

31
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. AronMav 20.09.21 14:03 Сейчас в теме
2 Балла - Специалист по платформе и 3 балла - Эксперт по тех. вопросам. Проще получается добрать другими компетенциями по мелочи, чем сдавать на такой трудоёмкий сертификат.
2. Tavalik 3350 20.09.21 15:38 Сейчас в теме
(1)
Там хитро. Сначала вы зарабатываете баллы относительно легким способом (хотя еще вопрос, что легче, Специалиста по платформе получить стажеру или матерому разработчику Эксперта - все относительно). Но когда простые способы заработка заканчиваются, приходится зарабатывать уже такими, как 1С:Эксперт. Количество баллов одинаковое мы сделали, чтобы шаг грейда сохранить (5 баллов). А вот разница в ЗП на высоких грейдах отличается заметно.
3. AronMav 20.09.21 15:51 Сейчас в теме
(2)
Тут вопрос во времени затраченном на получение сертификата. На своём примере, на подготовку к 1С Специалисту, в 1ый год своей работы, у меня ушло около месяца, сдал с 1го раза. На одну только сдачу 1С Эксперта ушло 2 года (6 попыток), но тут скорее виноват Ковид.
starik-2005; +1 Ответить
4. VVi3ard 52 20.09.21 17:04 Сейчас в теме
(3) Не проще потратить 6-8 мес на изучение kotlin и вообще забить на 1С, получая на уровне джуна, ЗП эксперта, и не забивая голову костылями? И уже поверьте опытный специалист на долго в джунах не задержится, буквально 6 мес и будете мид с 250к на руки.
d4rkmesa; soci0pat; morin; uri1978; smit1c; Birby; ArtManis; Merkalov; solaru; starik-2005; +10 Ответить
5. AronMav 20.09.21 17:14 Сейчас в теме
(4) Ты сейчас рассказываешь свой личный опыт или просто превьюшки известных онлайн школ цитируешь? Советую открыть hh.ru и сначала проанализировать рынок. А если имеется ввиду зарубеж, тогда знания английского нужно подтягивать, а тут уже по срокам все индивидуально.
SergeyTerentyev; ubnkfl; akpaevj; +3 Ответить
6. VVi3ard 52 20.09.21 17:18 Сейчас в теме
(5) https://vc.ru/hr/293852-analitika-dlya-hantinga-i-rekomendacii-po-naymu-it-specialistov
2014 — стоимость Hyndai Solaris 17800$
Зарплата MID 1C — 2300$
Зарплата MID Front — 2500$

2021 — стоимость Hyndai Solaris 17500$
Зарплата MID 1C — 1600$
Зарплата MID Front — 2500$
RailMen; Hatson; sapervodichka; +3 Ответить
9. starik-2005 3033 20.09.21 22:27 Сейчас в теме
(6)
Зарплата MID
Сейчас на 1С есть ЗП 300+ , на Go, Java, C++ и т.д. - там сейчас хорошие разработчики просят от 400к, так что витрина ХХ очень сильно поменялась, а работодатели надеются на авось (ага, придет к ним студент и забацает что-нить такое-этакое, ага....)...
Hatson; sapervodichka; +2 Ответить
16. VVi3ard 52 21.09.21 10:28 Сейчас в теме
(9)если вы сейчас работает mid за 300к на 1с вы очень хорошо устроились. В 1с в теории можно зарабатывать 300к на внедрении erp/ух но это совсем другая история.
20. starik-2005 3033 21.09.21 11:10 Сейчас в теме
(16)
если вы сейчас работает mid за 300к на 1с
Я техдир + архитектор в другой конторе. Выходит побольше. Но я на 1С, Python, C++ разрабатываю, а не только на 1С.
10. rpgshnik 3631 21.09.21 06:30 Сейчас в теме
17. VVi3ard 52 21.09.21 10:30 Сейчас в теме
7. VVi3ard 52 20.09.21 17:23 Сейчас в теме
(5) Пример из Kotlin просто как самое простое для 1С разработчика, всё же на фронт сложнее уйти, на java фреймворки сложные да и сам язык посложнее. Я на Kotlin первое приложение написал после 2х недель изучения. На Java мне было сложнее получить быстрый результат, и у меня проблема не с языком была а с Spring фреймворком.

Насчет "зарубеж" то полно бодишопов которые вас продадут на проекты и обеспечат рускоязычную обвязку.
morin; ArtManis; starik-2005; +3 Ответить
8. AronMav 20.09.21 17:27 Сейчас в теме
(7) Я думал уже свичнуться после сдачи, Kotlin кстати не рассматривал, сегодня попробую погрузиться.
18. smit1c 106 21.09.21 10:31 Сейчас в теме
(8) как успехи с погружением ? )
19. AronMav 21.09.21 10:32 Сейчас в теме
(18) Нужно больше времени)
SergeyTerentyev; +1 Ответить
21. starik-2005 3033 21.09.21 11:21 Сейчас в теме
(19) книжечка есть в магазах по Котлину - там тетрис и серверная фича на нем в качестве учебных проектов. If в котлине в виде тернарной операции меня ввел в ступор, хотя в XFormula оно такое же)))
23. VVi3ard 52 21.09.21 12:17 Сейчас в теме
(18) Попробуйте сами: https://www.youtube.com/watch?v=foTZ4rzCFKc&list=PLmjT2NFTgg1fdHN-9Wn4XYr-IOuadxMm5&index=3
Один - два дня на то что бы въехать в структуру проекта (активити/потоки), настроить рабочее место, и примерно месяц по 2 часа в день на то что бы въехать в ООП. и еще 3 месяца что бы руку набить.

Я думаю человек который осилил эксперта по тех вопросам вполне может освоить за указанное время.
stsasha87; kote; Merkalov; starik-2005; +4 Ответить
27. smit1c 106 21.09.21 13:59 Сейчас в теме
(23) Неизвестно что выбрать Котлин или Дарт с Флаттером.
Флаттер сразу на две платформы компилируется (Андроид и IOS).
30. VVi3ard 52 21.09.21 16:07 Сейчас в теме
(27) По мне так флаттер более перспективный, просто была задача под андроид и переход на Котлин был намного проще для меня. Флатер всё же требует немного другого мировозрения и ближе к фронту.

Если опыта мало так вообще нужно идти во фронт, там и универсальности больше (не важно что писать ЛК для банка или очередной маркет плэйс). Но имея за плечами 15 лет в 1С и/или эксперта по тех. вопросам намного ближе BackEnd или классическая разработка, там многое из полученных знаний пригодится. А вот в фронте вам знания той же СУБД не особо нужны.
akR00b; smit1c; +2 Ответить
11. dim-rudakov 5 21.09.21 06:58 Сейчас в теме
Только вся эта матрица рассыпется в пух и прах, когда разработчика позовут на фикс с зп в 2 раза больше, чем текущая.
d4rkmesa; san4o; Suonny; Krio2; al_zzz; uri1978; rpgshnik; VVi3ard; smit1c; user715892; morin; Birby; +12 Ответить
12. Birby 87 21.09.21 08:45 Сейчас в теме
33. Tavalik 3350 22.09.21 09:05 Сейчас в теме
(11)

Не знаю насколько крутой должна быть работа, чтобы человек отказался от предложения с аналогичной работой, но с ЗП х2.

На х2 я бы ушел особо не раздумывая. Но, слава Богу, ЗП удается держать +/- по рынку.
35. morin 57 23.09.21 09:25 Сейчас в теме
(33) Если ЗП держать +/- по рынку, проблем с мотивацией вообще не будет, а на каждого мудреца-работодателя довольно простоты.
13. Birby 87 21.09.21 08:47 Сейчас в теме
Хорошая публикация, спасибо! Видны и типичный франчовые проблемы, и желание их решить.
Реквестирую аналогичную публикацию от вас по аналитикам-консультантам.
14. Tavalik 3350 21.09.21 09:25 Сейчас в теме
(13)
Есть аналогичный доклад про аналитиков от моей коллеги: https://youtu.be/xM7uBFn-6vI
AlbinaAAA; Birby; +2 Ответить
15. ranger 123 21.09.21 09:36 Сейчас в теме
Статья интересная. Система аттестации наверное для разработчиков важна(в плане собственной эффективности, а значит эффективности всей компании). Это конечно не профессия врача или лётчика, где цена ошибки-человеческая жизнь, но все же... А если результат аттестации привязан к денежной компенсации, то это обоюдно выгодно обеим сторонам. Как говорил классик, опыт - сын ошибок трудных. Помню, как в своё время сам себя мотивировал на развитие, я это называл "убить" в себе лень. Лень прям физически ощущал своим телом, старался искоренить как недуг. Чтобы не было мучительно больно за бесцельно прожитое время:) Правда есть и обратная сторона медали, это тенденция к трудоголизму. На эту тему наверное можно написать отдельную статью.
starik-2005; Алексей_mir2mb; +2 Ответить
22. starik-2005 3033 21.09.21 11:25 Сейчас в теме
(15)
Это конечно не профессия врача или лётчика, где цена ошибки-человеческая жизнь
Мне кажется, что многие переоценивают эти профессии, т.к. стюардесса садила самолет, а именитые врачи ставили неправильный диагноз в двух случаях из пяти (соревнование нейросети и консилиума врачей в Китае). Ошибки в профессии врача - это рабочий процесс, как и у программиста, а в профессии летчика всегда есть "парное программирование", т.к. летчик не водит самолет в одну харю, при том его постоянно пасет стадо авиадиспетчеров. Отличие в скорости реакции. Летчик отреагировать должен молниеносно, но только пока в рейсе, да и то далеко не в каждой его точке. А доктор только в операционной реагирует мгновенно ("десять кубиков того-этого" - слышим мы, и восхищаемся, но вариантов этих "кубиков", поверьте, куда меньше, чем объектов в самой простой типовой конфе). В операционной дохтор не круче мясника, а оставленные в телах пациентов штуковины - это покруче говнокода, оставленного стажерами-1С-негами. Да и количество операций в пьяном виде не сильно меньше, чем количество строк кода в этом пьяном виде написанного.

Фактически, когда мы думаем о враче или летчике, то у нас перед глазами Юрии Гагарины и именитые хирурги, имена которых мне, например, вспомнить не получается. Но кажется, что вот все врачи и летчики - такие. Увы и ах, но нет. С другой стороны, обычным обывателям (тем же летчикам и дохторам) кажется, что все программисты - это Цукерберги (который вообще не программист), Джобсы (тоже, кстати, так себе программист), Гейтсы и т.п., но мы-то знаем, каковы большинство разрабов на самом деле, да? )))
lefthander; Albert_2008; vakham; kote; Сто27001; 1CKEBO; al_zzz; amd1986; +8 Ответить
24. amd1986 21.09.21 13:10 Сейчас в теме
(22)
..

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

Лажать могут многие, но ответственность разная. Не нужно превозносить программистов. На мой взгляд, они очень переоценены.
SergeyTerentyev; +1 Ответить
25. starik-2005 3033 21.09.21 13:21 Сейчас в теме
(24)
А программистом можно работать после простых курсов.
Видел я таких "погромистов" после курсов. Тут если не дано, то очень непросто взять.

Косяки врачей - они повсеместно, ежедневно, кучей дел врачей завалены суды. Так и х два курса учат тому, что писать в отчетах, чтобы под суд не попасть. Отсюда и коррупция - в Мск слышал неоднократно: "или десять косых, или оперировать тебя интерн будет". Жена лежала в больничке, врач прошлась и собрала по штукарю со всех, мотивируя тем, что ЗП 35 косых и надо как-то жить. Потом аттракцион с анализами - три раза анализы разные совершенно прилетали, и это в Мск (жена сама лаборант-микробиолог, говорит, что раньше так плохо не было). Так что я о врачах, поверьте, очень много чего нелестного могу написать. В телевизоре доктор Хаус - это одно, а на практике большинство врачей - это Лобавновы, в редких случаях Романенко (или как его там из Интернов). С учителями все еще хуже в разы - в пед идут по остаточному принципу, в итоге дети ОГЭ по математике три раза пересдавали - не могли сдать толком. А всего-то КИМы поменяли, при том год назад, убрав варианты, в которых можно угадать.

Ровно та же фигня и в 1С - большинство больших франчей продают стажеров по цене спеца, т.к. спецов нет почти - все на "жирных" проектах. Ну или "спецов", которые "жирный" проект не тянут.
vakham; 1CKEBO; +2 Ответить
26. amd1986 21.09.21 13:54 Сейчас в теме
(25)
...

Не знаю как у вас, но у нас в Калининграде, над врачами суды идут. Кого то сместили, кого то посадили. У врачей больше залет, когда кто то умрет. Там в любом случае проверка и будут гонять по экспертизам. А если программист сделает багу - гонять не будут. В этом плане им проще. И на душе проще.


(25)
Ровно та же фигня и в 1С - большинство больших франчей продают стажеров по цене спеца, т.к. спецов нет почти - все на "жирных" проектах. Ну или "спецов", которые "жирный" проект не тянут.

Если клиентов устраивает(в плане рисков), то все ок. Понятно, что результата может не быть, но ждать у моря погоды, когда появится спец - тоже бывает не вариант.
28. starik-2005 3033 21.09.21 15:07 Сейчас в теме
(26)
И на душе проще.
Все относительно. Когда грохаешь базу клиента без бэкапа - на душе так себе )))

С погромистами на знаю, а вот админы было время присаживались очень даже на тему воровства лицензий.
31. amd1986 21.09.21 16:14 Сейчас в теме
(28)
Все относительно. Когда грохаешь базу клиента без бэкапа - на душе так себе )))

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

Ну это немного не то, не ошибка, а воровство.
32. starik-2005 3033 21.09.21 16:22 Сейчас в теме
(31)
не ошибка, а воровство
Ну как сказать. Ворует вроде как работодатель, а сажают одмина...

Сегодня с коллегами общались про врачей - впечатление удручающее. Докторов Хаусов действительно ничтожно мало, а Лобановых - полные закрома родины...
vakham; 1CKEBO; amd1986; +3 Ответить
36. teyana 35 23.09.21 11:53 Сейчас в теме
(22) как мне говорил знакомый хирург - "1С программируете? это же так сложно..." )))
29. mikl79 118 21.09.21 15:08 Сейчас в теме
спасибо очень интересно
34. пользователь 22.09.21 13:12
Сообщение было скрыто модератором.
...
37. CreateNewUser 23.09.21 12:55 Сейчас в теме
Интересная статья, спасибо. А как вы оцениваете при приёме на работу. Тоже по таблице проверяете?
38. Tavalik 3350 29.09.21 06:32 Сейчас в теме
(37)
Офер выставляется все же по итогам собеседования. Затем уже после прохождения испытательного срока и некоторого времени работы (~6 месяцев), переходим к таблице грейдов.
41. fvr2000 11 11.11.21 14:40 Сейчас в теме
(38)
Статья крутая! Интересует ситуация вида "достиг высокого грейда и расслабился", ну или когда переоценили при приеме на работу. Не было мыслей перейти к более сложному расчету грейда, добавив зависимость от времени? Т.е., когда вклад тех или иных достижений снижается со временем. Тогда, если новых достижений нет, грейд будет снижаться.
39. Hatson 528 07.10.21 10:55 Сейчас в теме
В дереве "Предметная область" я бы еще добавил следующие пункты:

- Глубокие познания налогового и трудового кодекса (чтобы мариванну освободить от этой повинности)
- Профессиональный участник рынка ценных бумаг (а почему бы и... да?)

Следующее must have, чтобы говорить на одном языке с бизнесом (а как без этого?):
- Оценка инвестиционных проектов и рисков
- Консолидация бюджетирования в структуре компаний холдинга
- Навыки постановки эффективной системы управленческого учета

Так же вам понадобятся:
- Стратегическое мышление
- Харизма
- Коммуникабельность
- Активная жизненная позиция

Для широты кругозора (раз пошла такая пьянка):
- знание технологий горизонтального бурения и гидроразрыва пласта
- знания в области педиатрии и ухода за грудничками будет вашим плюсом
40. lefthander 07.11.21 10:20 Сейчас в теме
Спасибо, интересно и познавательно. Именно сейчас думаю и пробую приложить себя к новому. Фикса утомила, франча разочаровала, менять 1С на что то нет мотивации, вот и думаю как быть и что делать дальше... ;)
42. zuzechka 19.03.23 22:49 Сейчас в теме
Спасибо огромное, статья достойна уважения! Интересно как со временем претерпели изменения какие-либо пункты или все работает до сих пор?
Можете поделиться системой грейдов ?
Оставьте свое сообщение