Матрица компетенций аналитика 1С

28.01.22

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

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

Меня зовут Анна Бирюкова, я работаю руководителем аналитиков 1С в проектном отделе компании ФТО.

В сферу 1С я попала 15 лет назад, после окончания математического факультета Омского университета – начинала с разработчика на 7.7, затем была аналитиком на 7.7.

10 лет назад пришла в компанию ФТО и начала работать как аналитик с восьмеркой. Доросла до руководителя проектов. Сейчас руковожу аналитиками в проектном отделе компании ФТО.

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

 

О компании

 

 

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

  • Количество сотрудников у нас порядка 300.

  • Мы располагаемся в 3 филиалах, плюс у нас есть удаленные сотрудники.

  • Мы занимаемся крупными внедрениями, в основном ERP-систем – на базе 1С и BI.

  • Аналитиков 1С в нашей компании порядка 100 человек. Это три отдела – проекты, поддержка и группа развития. Из них в проектах внедрения работает порядка 30 человек.

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

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

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

 

Прежняя система мотивации

 

 

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

 

 

До 2020 года и частично еще в 2020 году у нас была система грейдов из 8 уровней, и наши аналитики росли по этой системе только вертикально.

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

 

 

На каждом уровне были свои требования, с каждым грейдом они росли, но в целом мы учитывали следующие компетенции:

  • Проектный опыт – на каждом грейде у нас были свои требования к количеству пройденных проектов. Например:

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

    • для перехода на третий грейд необходимо было пройти проект среднего уровня и выше (у нас были разработаны свои критерии, что такое средний и что такое крупный проект);

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

  • Знание предметной области или бизнес-процессов - у нас были перечислены бизнес-процессы, и для перехода на каждый уровень необходимо было набрать определенное количество внедренных процессов. Например:

    • аналитик среднего уровня должен знать один любой бизнес-процесс;

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

  • Знание функциональности и архитектуры систем 1С.

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

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

 

 

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

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

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

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

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

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

 

Принципы новой системы мотивации

 

 

Мы решили, что новая система должна быть:

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

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

  • Система должна быть справедливой.

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

  • Новая система должна стимулировать на развитие.

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

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

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

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

 

Какие компетенции и навыки решили оценивать

 

 

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

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

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

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

 

 

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

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

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

  • знания по конфигурациям 1С;

  • технические навыки – сюда относится качество написания документации, концептуальный и функциональный дизайны, техзадания, тестовый сценарий, инструкции, попадание в оценку по срокам и прочее;

  • и еще софт-скилы – то, что очень важно для аналитиков: взаимодействие с клиентом, внутри команды, со смежными отделами, навыки устной и письменной речи, самостоятельность, ответственность и т.д.

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

 

 

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

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

 

 

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

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

  • например, за работу с ERP мы назначили 8 баллов – это максимальное количество баллов, потому что на данный момент эта система самая перспективная и распространенная;

  • за «Управление торговлей» мы поставили 2 балла;

  • за ЗУП – 4 балла и т.д.

Так мы оценили знания по каждой из конфигураций и другие компетенции.

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

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

 

 

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

Например, по ERP максимальное количество баллов – 8. Эти баллы складываются из нескольких блоков:

  • базовый уровень;

  • продвинутый уровень;

  • производство;

  • казначейство;

  • планирование;

  • бюджетирование;

  • НДС, налоги и т.д.

То есть мы расписали эти 8 баллов по подбаллам.

Или, например, по системе ЗУП максимально возможное количество баллов – 4. Они складываются из нескольких подбаллов:

  • 0,5 балла можно получить за базовое умение оформлять кадровые документы;

  • 0,8 балла – за умение работать с видами учета рабочего времени, графиками и табелями;

  • 0,5 баллов – за умение работать с зарплатой по простой схеме (оклады, налоги, выплаты);

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

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

 

 

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

Эти баллы мы проставляем вместе с аналитиком на встрече «один на один», обсуждаем, на какие проекты он в ближайшее время идет, на каких проектах он сейчас работает.

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

 

Критерии для оценки навыков и компетенций

 

 

Мы решили, что для подтверждения навыков в предметной области нужно иметь:

  • либо успешный опыт участия в проекте;

  • либо опыт работы в поддержке от полугода.

 

 

Для подтверждения знаний по определенной конфигурации 1С сотруднику необходимо иметь:

  • либо успешный опыт участия в проекте;

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

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

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

 

 

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

 

 

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

 

 

Мы ведем проекты в отдельной корпоративной системе Redmine. Эта система позволяет вести проект позадачно, здесь аналитики у нас разносят фактические часы, и здесь можно указывать:

  • плановые показатели – такие как оценка трудозатрат по тестированию, на написание тех. задания, на дизайн и т.д. (это видно на нижнем скриншоте);

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

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

 

 

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

Например, в тех же технических компетенциях есть качество написания документации. У нас в каждом среднем или крупном проекте участвует функциональный координатор (или архитектор проекта), который производит обязательное рецензирование написанной документации – дизайнов, ТЗ, скриптов и т.д. И, прежде чем отправлять их клиенту либо отправлять в разработку, функциональный координатор их вычитывает. В данной компетенции мы решили, что будет три уровня:

  • 0 баллов;

  • 0,5 балла;

  • 1 балл.

 

 

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

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

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

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

Таким образом мы сформировали критерии оценки для субъективных и труднопроверяемых навыков.

 

 

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

  • взаимодействие с клиентом – это обратная связь от заказчика, от экспертов заказчика, пользователей:

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

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

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

 

 

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

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

 

 

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

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

 

 

В итоге у нас получилась стоимость каждого грейда равная 10 баллам.

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

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

 

Плюсы и минусы новой системы

 

 

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

Сначала о плюсах.

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

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

  • В целом аналитики нормально восприняли эту систему.

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

  • Она позволяет аналитикам набирать баллы, развиваться без привязки к проекту.

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

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

 

 

Но есть и минусы.

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

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

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

  • Мы совсем не исключили субъективизм, но на самом деле непонятно, надо ли это делать и как это делать.

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

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

 

Планы

 

 

Недочетов, в принципе, хватает, но мы не останавливаемся.

 

 

Мы планируем дальше развивать эту систему.

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

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

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

  • Следующий момент – надо подумать, как, по возможности, увеличить объективизм некоторых оценок.

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

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

 

Вопросы

Предусмотрено ли по вашей новой системе мотивации движение вниз? Например, раньше сотрудник попадал в оценку, а теперь перестал попадать. Что будет с его заработной платой?

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

Мы старались сделать нашу систему безопасной, поэтому если баллы уменьшаются, это не влияет на заработную плату человека. В этом случае аналитик понимает, что раньше ему, чтобы перейти на следующий грейд, нужно было набрать +5 баллов, а если у него сейчас стало -3, то теперь где-то нужно 8 баллов набрать.

 

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

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

 

10 - 12 октября 2024 года состоится конференция INFOSTART TECH EVENT, на которой прозвучит 130+ докладов.

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

  • Приемы, методы разработки и тестирования
  • DevOps-практики, управление инфраструктурой разработки
  • Интеграция и обмен данными
  • Идеи и тренды в разработке 
  • Администрирование серверов 1С и СУБД. HighLoad оптимизация  
  • Развитие технической команды. Личная эффективность разработчика 

INFOSTART TECH EVENT - крупнейшая профессиональная конференция для программистов 1С.


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

 


См. также

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

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

31.01.2024    3480    0    a_a_burlakov    25    

46

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

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

15.01.2024    2249    0    KChebykina    0    

32

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    4658    0    ivanov660    10    

33

Саморазвитие Бесплатно (free)

Советы рекрутерам по составлению описания вакансий, цепляющих нужных специалистов.

19.09.2023    3188    0    barelpro    33    

42

Саморазвитие Бесплатно (free)

Если внутренние проблемы мешают человеку жить, не поможет ни образование, ни курсы, ни даже многолетний опыт. А человек, который привёл свою голову в порядок, охотно трудится, с удовольствием учится, на него всегда можно положиться. В конце концов – он просто счастлив. На Infostart Event 2021 Moscow Premiere Алексей Бурлаков из компании «ДНС Ритейл» на примере превращения Йорика из нежити в рыцаря привел классификацию «тараканов» и рассказал о том, что можно сделать, чтобы привести мысли в порядок.

28.02.2023    6799    0    a_a_burlakov    59    

46

Отчеты и дашборды Программист Платформа 1С v8.3 Система компоновки данных Бесплатно (free)

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

26.02.2023    3615    0    DemetrKlim    38    

28

Саморазвитие Программист Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse рассказал, какие трудности и приключения ждут 1С-ника, если тот решит стать «настоящим программистом». Докладчик показал, чем 1С выигрывает у других фреймворков и почему дрель – это ненужный инструмент.

30.09.2022    30981    0    Evil Beaver    178    

147
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. maksa2005 540 28.01.22 12:46 Сейчас в теме
Как мне сказал один из программистов: Какой порядочный программист (Москвы) получает меньше 190 тыс. Я сам скажу, что я не порядочный и столько не получаю...
2. rusmil 262 29.01.22 09:32 Сейчас в теме
Хорошая статья и доклад! Было бы неплохо еще почитать от вас статью или посмотреть доклад на тему что конкретно делает аналитик. Так сказать "практические будни аналитика".
8. abir 19 09.02.22 07:55 Сейчас в теме
(2) Вы именно от меня ждете эту статью или видео? Или вообще эта тема интересна? Если вообще, то есть много статей и материалов на эту тему в свободном доступе, в том числе и на Инфостарте
3. user844067 04.02.22 09:20 Сейчас в теме
Спасибо, что поделились материалом! У меня опыт работы разросся вширь: конфигурация 1С одна, разные предметные области + BI)). Разбираюсь в прогнозировании.
4. roman72 384 04.02.22 14:30 Сейчас в теме
Вот и отдайте аналитикам предложенную вами систему оценки аналитиков на основе функциональных знаний - по итогам их оценки и скорректируйте её, интересно что скажут, заодно и подтвердят свой скилл аналитика. ))))))
7. abir 19 09.02.22 07:53 Сейчас в теме
(4) А мы так и сделали. Отдали эта матрицу им - они оценили себя сами, потом с каждым аналитиком были встречи 1 на 1, на которых обсуждали и верифицировали их оценки себя и наши оценки их. Так получились итоговые цифры (на каждый момент времени обсуждения), которые приняты и аналитиком, и руководителем.
10. roman72 384 09.02.22 21:14 Сейчас в теме
(7) Тогда вызывает сомнения компетентность аналитиков. Иначе бы они указали бы на то, что переход из аналитиков/координаторов в руководители проектов несколько неадекватен.
Поскольку руководитель проекта должен обладать более широкой компетенцией чем аналитик.
Ведь в проектные команды серьёзного проекта входят разные профессиональные функциональности:
- менеджеры
- аналитики
- консультанты
- методологи
- архитекторы
- разработчики
- тестировщики
- технические писатели
Ну или у вас исключительно аналитические проекты.
И да, любой качественный аналитик сразу поймёт что система грейдов - замануха - из 10 аналитиков никогда не будет 10 руководителей проектов.
Грейдовая система хороша для оценки имеющегося персонала и стоимости проекта.
Но, на практике, на мой взгляд она чаще создаёт для конкретных исполнителей препятствия к росту. Чем выше грейд, тем сложнее на него почему-то становится переходить. Рост сотрудника часто тормозится искусственно.
16. abir 19 24.02.22 05:40 Сейчас в теме
(10) В докладе как раз и говорится, что одной из причин ухода от старой системы - это тупиковое развитие аналитика до руководителя. Не все аналитики хотят/могут и не всех мы видим в будущем руководителями, хотя были и такие случаи, когда аналитик рос до ФК и потом до ПМ.
В новой системе развитие аналитика идет больше во горизонтали, чем по вертикали.
5. biimmap 1986 06.02.22 10:12 Сейчас в теме
Очередная компания, которая не понимает, что качество знаний должно быть в рамках одной области! Невозможно глубоко знать много областей. Понятно, что Вам это невыгодно... на каждую предметку своего аналитика или разработчика.
Вот у Вас хороший пример приведен по ЗУП. Сразу видно, что ЗУПер в Вашей компании - это пустое место! Точно также видно, что в Вашей компании скорей всего нет сильных ЗУПеров и такие проекты Вы делаете с низким качеством. Почему такой вывод? Давайте разбираться:
1. К примеру у меня опыт 15 лет в ЗУП. Нерешаемых задач просто не существует. Но ни одну другую конфигурацию я не знаю. А значит из 41.5 баллов я получаю только 4!
2. Почему Вы решили. что ЕРП - это 8 баллов, а ЗУП 4? Откуда у Вас заблуждение, что ЗУП такой простой? Наверняка эти показатели отражают прибыльность проектов для Вас, не более того! Правда Вы сами написали, что это и есть минус Вашей системы грейдовой.

тут небольшой спойлер-реклама... в конце марта будет конференция Желтая субмарина. Буду рассказывать как раз про ЗУП. Очень рекомендую Вам послушать, чтоб развеялись заблуждения. После будут опубликованы статьи под комичным названием "Ни в ЗУП ногой. А мне нравится!" будет 5 или 6 статей, 4 уже написаны.

3. Очередное заблуждение насчет того, что аналитик должен знать архитектуру... Она для того и называется архитектурой, что знает её АРХИТЕКТОР! Исходя из текста статьи таковой у Вас отсутствует! А значит на проектах бардак дикий происходит! Т.к. целостность этой самой архитектуры кто-то должен контролировать! Тут могу рекомендовать (не настаиваю) уже готовую статью "Кто такой архитектор". Возможно ещё пару заблуждений пропадут.

4. С каких пор соблюдение сроков - это технический навык???

5. Также хочется написать: очередная контора, где верхом совершенства является должность Руководитель проекта. Вы вообще в курсе, что это другая профессия???!!! Вообще никак аналитик не может вырасти в РП! Просто потому, что в процессе роста аналитик не знает способов и методик управления проектом. Логичным можно считать рост аналитика до Функционального архитектора! Вот здесь всё выглядит логично: раньше ты отвечал только за свой результат, а по достижении этого уровня отвечаешь за результат коллег. Вот таким образом и получаются некомпетентные РПшники, которые ещё потом и разработчикам задачи ставят.

6. Обратная связь от разработчиков... Это единственный пункт в данной статье, с которым можно согласиться. НО! Ответственность за качество лежит на АРХИТЕКТОРЕ. Ах да, у Вас же его нет! Вот потому и требуете не с того, с кого надо! В нормальном процессе ТЗ пишет аналитик и согласовывает с архитектором. А обратная связь от разработчика она уже по сути в адрес архитектора пойдёт!

Когда ж уже общество осознает, что проекты построенные на РП и аналитиках провальные по умолчанию!?
Что касается системы грейдов - она не учитывает сильных спецов, не мотивирует развитие внутри одной области! Она мотивирует набрать как можно больше баллов, поставить как можно больше галочек. По опыту работы почти в 20 лет точно могу сказать, что грошь цена таким спецам.

Успехов в работе.
DaKar7; Andreev.a; +2 Ответить
6. abir 19 09.02.22 07:51 Сейчас в теме
(5)
Вы сделали кучу неверных и безапеляционных выводов только на основании одной статьи (или видео), причем вы даже не уточняли, верны ли ваши умозаключения. Если бы вами это было подано в другой манере изложения, я бы с вами побеседовала и подискутировала, но в таком ключе не хочется даже с вами спорить. И это не значит, что мне нечего сказать, просто не вижу смысла. И вам всего доброго!
11. biimmap 1986 09.02.22 22:40 Сейчас в теме
(6) Ну вот коллега ниже со мной согласен. Выводы на основе 20 лет опыта, а не статьи. Просто Вам рекомендовал почитать для информации.

Я к сожалению разгребаю результаты работы вот таких деятелей на всех моих проектах! Потому да - выводы без аппеляций...
Ну а Вы как хотите: можете продолжить свою деятельность, а можете прислушаться... Выбирать Вам. А вот клиентов мне всегда жаль.
13. biimmap 1986 09.02.22 23:34 Сейчас в теме
(6) Стоит отдельно остановиться на манере изложения... Важно не манера, а суть написанного! Я не фотку в инстаграмме прокомментировал, а статью в проф. сообществе.

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

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

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

Так что, соглашусь с коллегой, в пору не обижаться, а выводы делать! И перестать хотя бы из аналитиков плодить никчёмных РПшников. Систему мотивации точно стоит сделать зависимой от качества работы, а не от количества баллов "на входе" за знание конфигураций и умение хорошо общаться.

Если есть что сказать - скажите. Только аргументы крепкие должны быть.
20. abir 19 25.02.22 11:43 Сейчас в теме
(13) Каждый из тех, кто читает эту статью - делает свои выводы. Я рассказала о нашем опыте, при этом с момента этого доклада прошло уже больше года и эта система сильно претерпела изменения, т.к. мы понимаем, что она неидеальна.
Это тоже самое что бездумно начинать принимать все витамины подряд, начитавшись об их пользе. Ну нет, это не так работает. Тут каждый может вынести из этой системы что-то для своей компании или для себя полезное. Или даже то, что никогда не стоит делать. Мы свои уроки из нашего опыта работы с этой системой извлекли.
9. roman72 384 09.02.22 21:03 Сейчас в теме
(5) Очень качественные замечания вы сделали. Всё в точку.
Не соглашусь только с пунктом 3.
Аналитик может знать архитектуру, а в некоторых случаях должен, а иногда выявить отсутствующую архитектуру - прямая задача аналитика. При этом, безусловно, за разработку и состояние архитектуры отвечает Архитектор.

Автор статьи совершенно зря обиделась на ваш комментарий, из него можно извлечь много полезных выводов для улучшения своей модели оценки аналитиков. На мой взгляд автору просто возразить по существу нечего.
12. biimmap 1986 09.02.22 22:43 Сейчас в теме
(9) Про архитектуру давай уточню:
Конечно, не зная её нельзя даже инструкцию написать! Моя мысль о том, что отвечать за неё он никак не может. Здесь коллеги утверждают, что разработчики дают обратную связь о деятельности аналитиков. Именно это неверно! Архитектор должен контролировать целостность архитектуры. И обратная связь от разработчиков должна быть о деятельности архитектора. Вот о чём я написал.

Благодарю за поддержку.
Andreev.a; roman72; +2 Ответить
14. Vyatcheslav 22 13.02.22 21:21 Сейчас в теме
(12) Я так же Вас поддержу. То, что грейды от количества конфигураций это дно. Специалист во всем это невежда во всем. Аналитик может знать только хорошо одну-две области и этого может быть достаточно, если франч может обеспечить загрузку аналитику по его областям знаний. Закупки или от и до Бюджетирование и постановку его с нуля. Или автоматизацию МСФО. При этом аналитик может не знать производственный учет в ERP или не быть экспертом по Документообороту и это нормально.

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

Для серьезных проектов со сложной спецификой и большим количеством арм нужны аналитики с глубокими знаниями конкретной автоматизируемой области и, конечно, архитектор по внедряемому прикладному решению. Особенно, если учесть, что на большом проекте будет не один аналитик, представьте, как каждый аналитик под свои требования будет внедрять в конфигурацию свои технические решения вне зависимости от другого аналитика.
DaKar7; Andreev.a; biimmap; +3 Ответить
18. abir 19 24.02.22 06:00 Сейчас в теме
(5) Ну, а теперь можно немного и пообщаться. По пунктам:
1. У нас есть аналитики, специализирующиеся в конкретных предметных областях (и есть аналитики, которые очень хорошо знают например, только ЗУП и рег. учет). И мы с этим также работаем и ценим это. И в "минусах" этой системы про это сказано. После внедрения этой системы она еще претерпевала изменения. И это тоже учтено.
2. Аналитик, не знающий архитектуру системы, никогда не вырастет в сильного аналитика. Как можно разбираться в системе и не понимать ее начинку? Как он может продумать и предложить какие-то варианты заказчику, написать корректное ТЗ для разработчика? Архитектор будет всегда за него это делать? Нет. Архитектор нужен для того, чтобы помочь, состыковать разные процессы разных аналитиков, но не работать за всех.
Функции архитектора и знание и понимание архитектуры - это вообще о разном. Архитектор (или функциональный координатор) у нас есть на каждом среднем или крупном проекте.
3. Не согласна, что аналитик не может вырасти в РП. Конечно, не каждый аналитик вырастает в РП - многие не хотят, кто-то не может, кого-то руководство не видит в роли РП. Но есть и такие (их конечно единицы), которые становятся хорошими РП-никами. Конечно, в ходе своего становления они проходят обучение по управлению проектом.
Machiavelli; +1 Ответить
19. biimmap 1986 24.02.22 09:12 Сейчас в теме
(18) Хорошо, что здравый смысл возобладал!

Просто смотрите у Вас по существующим показателям непонятно что цените людей знающих глубоко одну область.
Прям нужен такой доп. показатель, который показатель за знание одной области (например ЗУП 4 балла) способен увеличить в 5-7 раз! Вот чего не хватает. Тогда люди будут не галочки себе ставить по 0,5 балла за каждую конфигурацию, а будут прокачиваться в одной предметке! А это в свою очередь неизбежно приведет к повышению качества работы! И получится, что Ваша бальная система грейдов заработает более адекватно.

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

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

Успехов!
Andreev.a; abir; +2 Ответить
15. maxx 995 15.02.22 16:46 Сейчас в теме
А как система грейдов вписывается в экономическую модель предприятия? Стоимость часа для Заказчика одинаковая? Как другими словами окупается фонд зарплаты аналитиков? Кто им обеспечивают и распределяет работу на постоянной основе? Нет такого что одну и ту же работу делают, но из-за грейдов получает у кого выше получает и з/п выше, в результате напряженность среди аналитиков?
17. abir 19 24.02.22 05:49 Сейчас в теме
(15) Да, стоимость часа для Заказчика одинаковая, независимо от специалиста. Обычно на проекте же есть специалисты разного уровня - и опытные, высокооплачиваемые, и среднего уровня, и могут быть новички. За счет этого средняя ставка себестоимости по проекту не может быть всегда высокой. И коррелируется с продажной ставкой, чтобы у компании была возможность зарабатывать.
Непростая задача работодателя - обеспечить постоянной загрузкой всех (с учетом отпусков и возможных обучений).
21. пользователь 09.01.23 13:32
Сообщение было скрыто модератором.
...
Оставьте свое сообщение