Система мотивации отдела внутренней разработки

21.08.17

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

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

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

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

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

Бизнес-процесс - самый обычный:

1. Программистам ставятся задачи, от любых отделов;

2. Задачи проходят согласование, если требуется. Список согласующих - разный для разных задач;

3. У задач есть срок, есть возможность его переноса (не более двух раз). До начала выполнения срок согласовывается обеими сторонами;

4. Есть проекты автоматизации, выполняемые по каскадному принципу. Задачи в проекте живут той же жизнью, что и остальные - есть сроки, есть согласования и т.д.;

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

Система мотивации:

1. У программистов есть оклад, в зависимости от квалификации;

2. Есть демотивация за невыполоненные в срок задачи;

3. Есть премии за выполнение проектов.

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

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

Но нам не давал покоя один вопрос - как зарабатывать больше денег? 

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

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

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

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

Но рано или поздно руководитель начинает задавать вопрос - если человек все время делает проекты раньше срока, почему я за это должен доплачивать? Может, срок неправильно рассчитан?

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

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

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

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

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

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

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

Если лучший программист решит задачу за 1 час, то стоит она 1 час. Другой программист, решающий эту задачу за 4 часа, получит за нее 1 оплаченный час.

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

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

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

Классификатор содержал, например, такие пункты:

  • Разработка простого отчета, типа "Продажи", по одному регистру, на СКД в пользовательском режиме. Оценка - 15 минут;
  • Создание регистра накоплления, с простой записью движений, полностью определяемых контектстом документа. Оценка - 15 минут;
  • Разработка роли, без RLS, с небольшим перечнем (до 10) разрешенных объектов. Оценка - 10 минут;

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

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

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

Несложные подсчеты и округление дали нам часовую ставку лучшего программиста: 600 рублей в час.

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

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

Однако, понимая, что разговор про эту ставку с руководством все равно состоится, мы решили убедиться в своей правоте. Для этого пообщались со знакомыми и незнакомыми франчами и фрилансерами. Мы дали этим ребятам несколько задач для оценки, и задали простой вопрос - сколько возьмете денег за такую работу? Результат был прогнозируемый - ребята просили за работу в 2-3+ раз больше, чем мы (с учетом налогов на з/п). На этом успокоились - задница прикрыта.

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

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

Выход из ситуации тоже простой - "запоминать минус". Сделал работ на 40 т.р., получил оклад 60 т.р. - ок, запоминаем "минус" 20 т.р. В следующем месяце будешь должен. Сделаешь в следующем месяце работ на 80 т.р. - получишь 60 т.р., и должен не будешь.

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

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

Выход тоже простой, и опять же подсмотренный у других - часть сдельной зарплаты накапливать и выдавать по окончании проекта. Мы решили, что у нас это будет 20 %. Пока проект идет, программист получает за час 480 рублей, а оставшиеся 120 рублей с каждого часа получает по окончании проекта.

Ну, вроде все посчитали и продумали, надо начинать тестовую эксплуатацию.

Первым делом понадобилось изменить бизнес-процесс работы программистов: 

1. Задачи теперь должны ставиться не персонально исполнителю, а мне, руководителю;

2. Я теперь должен каждую задачу оценивать в часах;

3. После принятия и оценки задача становится доступна для выполнения.

Ок, бизнес-процесс изменили, надо автоматизировать. Чтобы иметь больше свободы творчества, мы перестали использовать поручения и служебные записки (ими пользовались все), а придумали и за 1-2 дня изготовили себе два новых объекта:

1. Заявка в ИТ-отдел, со всеми необходимыми полями для нашей оценки;

2. Упрощенную систему учета проектов и задач в них, с той же системой оценки.

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

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

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

Вроде ответ очевиден - должна. Но так ли уж все очевидно? Что получается.

Вот одному программисту поставлена задача - сделать заполнение субконто Склад в проводке по счету 003 (в типовой УПП, почему-то, не заполняется). А он в переработку не знает, ни на стороне давальца, ни на стороне переработчика.

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

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

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

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

Итак, решение стало для нас очевидным:

1. За передачу знаний и помощь друг другу надо платить;

2. За получение новых компетенций надо платить.

Второй пункт - про знания, которыми не обладает никто из команды. Например, у нас появилась задача постоянно затаскивать в 1С данные из внешней системы прямыми запросами к MS SQL. Задача несложная, но никто такого раньше не делал. Я поступил так - оформлял от своего имени заявку, суть которой - раскурить работу с внешними источниками данных на уровне, достаточном для решения конкретной задачи. Оценка задачи - 1 час (а просидеть можешь хоть целый день).

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

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

1. Вопрос, который обсуждался/проектировался/передавался;

2. Время начала и окончания обсуждения, с точностью до минут;

3. Участники.

В учетной системе добавили отдельный документ, в который раз в неделю вбивались результаты таких обсуждений. Обычно обсуждения укладывались в 5 минут, изредка достигая 15 минут. За неделю получалось на всех 3-5 часов.

Что важно: время обсуждений оплачивалось всем его участникам, т.е. было выгодно как приобретать, так и передавать знания. Было выгодно оказывать помощь коллегам, т.к. людские законы никуда не делись - если помогаешь ты, то помогут и тебе, а если ты держишь знания при себе, то будь готов, столкнувшись с незнакомой задачей с оценкой 1 час, просидеть с ней 2 дня. Разумеется, бывали исключения, когда я сам вычеркивал из списка участников того, кто сидел и считал ворон.

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

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

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

Сначала была мысль вообще не платить, а уменьшать базу для расчета оклада при расчете выплаты. Например, если программист имеет оклад 60 т.р., просидел 2 недели в месяце на тех.поддержке, то при расчете считать окладом половину - 30 т.р., а за остальное время считать сделку.

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

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

По результатам замеров оказалось, что тех.поддержка занимает в среднем 2 часа в день. Отлично, вот и цифра. Договорились, что в таком размере она и будет оплачиваться дежурному - 2 часа в день, или 10 часов в неделю.

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

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

Собственно, на этом картинка сложилась, и мы продолжили тестовую эксплуатацию системы.

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

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

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

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

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

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

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

Мое участие стало прозрачным и понятным, это просто точки в бизнес-процессе:

1. Прием и оценка задач, я делал это раз в день, минут 15;

2. Участие в совещаниях по анализу и проектированию (это ~3 раза в день по 5 минут).

Итого, на управление тремя программистами - 30-60 минут в день. Никого не нужно пинать, следить за исполнением и сроками, мотивировать, проверять качество - все делалось само собой. За результатами я мог смотреть в любой момент через систему. Нельзя сказать, что получилось полное самоуправление, но мы были к нему максимально близко.

Тестовую эксплуатацию мы проводили в течение 3 месяцев. За это время выработка в часах у нас выросла вдвое, а рассчитанная по новой мотивации зарплата - на 30 %. Разница понятна - теперь оклад приходилось отрабатывать. По словам самих программистов, им нигде до этого не приходилось так интенсивно работать. Именно интенсивно, а не много или долго - я всегда был против более чем 8-часового рабочего дня. 

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

Успех я объясняю так:

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

2. Если взглянуть на процесс разработки через self-management, то видно, что система создавалась при непосредственном участии людей, которым в ней работать.

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

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

Мне, как руководителю ее разработки, особенно интересно было мнение HR-консультанта, т.к. он хорошо знает мировую практику и выполнил сотни проектов по разработке систем мотивации. Его оценка моей системы оказалась очень высокой, особенно ему понравились контуры защиты ("запомнить минус" и ограничение максимальной выплаты).

Впоследствии принципы этой системы стали базовыми для других систем мотивации предприятия.

Приятный бонус

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

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

Еще узнали, что люди, которые вечно ноют "нами не занимаются", потребляют 40 % всех денег на автоматизацию.

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

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

Что в итоге? Нас стали чаще и внимательнее слушать, особенно ДО начала работ. Потому что мы теперь умели прогнозировать результаты проектов, опираясь не только на системное мышление, но и на статистику в цифрах. Объем бессмысленных работ за первые месяцы уменьшился до 30 % - притом, что улучшилась структура "бессмысленности". Но это уже другая история.

См. также

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

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

25.11.2024    4647    0    PROSTO-1C    7    

11

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

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

12.11.2024    645    0    AlexSvoykin    9    

4

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

«Я знаю одно – во мне есть нечто, и я это скрываю. Я не говорю об этом. Но оно там всегда. Мой Темный попутчик. Когда он просыпается, я чувствую себя живым.» (сериал «Декстер»). «Жажда разработки» – это психологические проявление внутреннего «я», вызывающее острую необходимость программировать. Все, кто любит программировать, неоднократно испытывали такую жажду, и я не исключение. Расскажем о том, как утолить свою жажду и найти баланс между хобби, работой и другими аспектами жизни.

07.11.2024    3457    0    BlizD    79    

44

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

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

09.10.2024    2370    0    Akcium    1    

5

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

В этом выпуске мы поговорили с ведущими подкаста "Аналитики у микрофона" Татьяной Рыловниковой и Анной Войкиной про цели и ценности создания, прослушивания и участия в подкастах.

09.09.2024    397    0    Radio_Analyst    1    

2

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

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

23.08.2024    1124    0    user1947860    3    

5

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

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

20.08.2024    4493    0    PROSTO-1C    14    

23

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

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

23.07.2024    1899    0    SerjoginaMaria    6    

13
Вознаграждение за ответ
Показать полностью
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. ig-efrem 22 21.08.17 19:36 Сейчас в теме
Интересная статья, спасибо большое
24. 1c-intelligence 12852 22.08.17 09:34 Сейчас в теме
(1) вам спасибо, надеюсь будет полезна.
2. script 128 21.08.17 21:06 Сейчас в теме
Очень было интересно. Спасибо за статью. Скажу честно, когда дошел до оплаты часа самого лучшего программиста, внутри все взбунтовалось и захотел закрыть страницу - типа чепуха.(сам программист). Но все - таки заставил себя дочитать до конца. Очень классных подход, в чем-то жесткий. Ведь по общепринятому мнению: "о надежности всей системы нужно судить по самому слабому звену, а не по самому сильному". А Ваш подход, примирительно к устоявшемуся мнению, является революционным. Резко всех напрячь ориентируя на лучших. Интересно не выдохнуться ли середняки? Надеюсь что Ваши не выдохнуться, но поднимать планку бесконечно не получится, и кроме того сам "лучший" может уйти или начать "тормозить".
master555; +1 Ответить
5. Krasnyj 1288 21.08.17 23:23 Сейчас в теме
(2) Считать техподдержку по "лучшему программисту" - это, конечно, умилило. Там, где "лучший программист" кинет ссылку на инструкцию и займется другими делами - из худшего программиста начнут вынимать душу нытьем, что в инструкции ничего не понятно, а у них срочная проблема, и эта ваша программа срывает нам... ну, и т.д.
3762515; user751626; Silenser; awk; user761890; uncle_Vasya; +6 Ответить
31. 1c-intelligence 12852 22.08.17 09:47 Сейчас в теме
(5) вы все верно подметили, такие проблемы были, с одним конкретным программистом. Ну не шло у него общение с людьми, по психологическим соображениям.
В итоге ребята сами решили, что на тех.поддержке будет сидеть один человек - тот, у кого лучше всех был показатель выработки на тех.поддержке, и время переключения было почти равно нулю.
35. Krasnyj 1288 22.08.17 09:54 Сейчас в теме
(31) А тут все дело, на мой взгляд, вовсе не в том - "идет у человека общение с людьми" или не идет. Ни для кого не секрет, что обслуживаемые сотрудники любят, подчас, скинуть на IT или ответственность за нерешение проблемы, или саму ее. Но они всегда пробивают - кого можно подставить, кого нельзя или бесполезно. Тут подметили - у Вас есть административный ресурс (я в этом и не сомневаюсь). Вы дадите ссылку на инструкцию, дальше читайте сами. А в другого вцепятся по принципу - главное, громче ныть, что обращалась, и от них одной ссылкой на инструкцию уже не отделаешься. Хотя, если у Вас этот вопрос решен - тогда респект.
56. 1c-intelligence 12852 22.08.17 10:27 Сейчас в теме
(35)
Хотя, если у Вас этот вопрос решен - тогда респект.

навсегда его решить, наверное, нельзя. Каждая смена главбуха или замглавбуха заставляла все заново настраивать, объяснять кто должен месяц закрывать и т.д. Один главбух никогда не читает инструкции, другой их требует.
Я никогда не бетонировал порядок тех.поддержки, перестраивал на ходу, в зависимости от ситуации.
97. Krasnyj 1288 22.08.17 13:04 Сейчас в теме
(56)
Я никогда не бетонировал порядок тех.поддержки, перестраивал на ходу, в зависимости от ситуации.


Ну да. Вы тоже, я так понимаю, смотрели - от кого можно отделаться ссылкой на инструкцию, а кого уже придется ублажать по полной.
user761890; +1 Ответить
98. 1c-intelligence 12852 22.08.17 13:08 Сейчас в теме
(97) почти. Я смотрел, от кого можно отделаться, а кого надо переводить в категорию "от кого можно отделаться", и что для этого нужно.
100. Krasnyj 1288 22.08.17 13:09 Сейчас в теме
(98)
почти. Я смотрел, от кого можно отделаться, а кого надо переводить в категорию "от кого можно отделаться", и что для этого нужно.


Мне хорошо знаком этот офисный волейбол :)
102. 1c-intelligence 12852 22.08.17 13:14 Сейчас в теме
(100) тут не было волейбола, была конкретная работа.
Например, какое-то время сотрудник тех.поддержки записывал и группировал вопросы. Если люди спрашивают одно и то же по одному и тому же, например, документу, то мы его улучшали, чтобы вопрос не повторялся.
Это было не системно и далеко от идеала. Идеал - когда нет тех.поддержки. Но системно поработать над этой темой у меня руки так и не дошли, мирился с приемлемыми потерями.
103. Krasnyj 1288 22.08.17 13:20 Сейчас в теме
(102)
Например, какое-то время сотрудник тех.поддержки записывал и группировал вопросы. Если люди спрашивают одно и то же по одному и тому же, например, документу, то мы его улучшали, чтобы вопрос не повторялся.


Вот это, кстати, прекрасная идея, слов нет. Но из них следует вывод, что обращались по телефону, а писать заявки... отказывались или..?
106. 1c-intelligence 12852 22.08.17 13:30 Сейчас в теме
(103) тех.поддержка работала по скайпу, ну и пешком приходили. Какого-то деска по тех.поддержке не было, если вы об этом.
Цель тех.поддержки - ответить на вопросы, помочь что-то настроить (типа отчета), и т.д.

Если на тех.поддержку звонили и просили сделать новый отчет, то пользователь отсылался в оформление заявки на доработку/разработку.
108. Krasnyj 1288 22.08.17 13:32 Сейчас в теме
(106)
Какого-то деска по тех.поддержке не было, если вы об этом.


Ну да, об этом.
109. Krasnyj 1288 22.08.17 13:32 Сейчас в теме
(106)
А перевести их на заявки по всем вопросам не пробовали?
110. 1c-intelligence 12852 22.08.17 13:34 Сейчас в теме
(109) была такая мысль, но такой подход сильно выбивался из привычных паттернов компании. Мы итак сильно отличались от коллег, не хотелось усугублять.
111. Krasnyj 1288 22.08.17 13:36 Сейчас в теме
(110)
была такая мысль, но такой подход сильно выбивался из привычных паттернов компании. Мы итак сильно отличались от коллег, не хотелось усугублять.


Ну да. И коллектив бы взвыл. :)
104. Krasnyj 1288 22.08.17 13:24 Сейчас в теме
(102)
тут не было волейбола, была конкретная работа.


В основном волейбол устраивают те самые пасомые, которым приходится работать с внедрямой системой. И хорошо, если у вас действительно была конкретная работа, это еще одно ключевое везение. Обычно, коллектив волнами саботажа пытается все сорвать.
26. 1c-intelligence 12852 22.08.17 09:37 Сейчас в теме
(2) спасибо.
Никто не выдохся, потому что программистам нравится быть лучше других. К тому же, никаких переработок, работы в выходные и т.д.
Там много работы персональной, каждый программист уникален, и каждому нужна уникальная мотивация. Но в целом подход уложился для всех, каждый нашел возможность проявить себя. Кто-то за счет зарабатывания денег, кто-то за счет того, что стал лучшим по выработке, кто-то за счет того, что доказал всем, что он не валенок.
3. genayo 21.08.17 21:27 Сейчас в теме
Система прозрачная и логичная, программистам такое нравится. Есть пара уточняющих вопросов:
1. Как оплачиваются задачи рефакторинга и оптимизации производительности?
2. Сколько различных конфигураций на поддержке?
27. 1c-intelligence 12852 22.08.17 09:39 Сейчас в теме
(3)

(3)
1. Как оплачиваются задачи рефакторинга и оптимизации производительности?

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

(3)
2. Сколько различных конфигураций на поддержке?

несколько баз УПП с разной конфигурацией и УРБД, ДО 2, несколько БП 2.0, привязанный битрикс.
4. dmpas 418 21.08.17 22:22 Сейчас в теме
я так понимаю, вы не в Москве, раз так измываетесь над разрабами и они от вас до сих пор не свалили?

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

А как же фактор автобуса, нет? Одну область должны покрывать хотя бы двое.

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

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


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

Программисты стали азартными и жадными, в хорошем смысле этого слова.

Программисты хорошо умеют работать на показатели.


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

Упустил, на протяжении какого времени это уже продолжается??


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

ага:
1. Задачи теперь должны ставиться не персонально исполнителю, а мне, руководителю;
2. Я теперь должен каждую задачу оценивать в часах;
3. После принятия и оценки задача становится доступна для выполнения.


участие хоть и минимальное, но критичное.


А так, неплохо. Осталось вам вывести отдел разработки в отдельное юрлицо.
Deslime; Stepa86; user751626; pbabincev; Chernik; 1cccc; ДАК1; msvd; zqzq; awk; RainyAugust22; user761890; uncle_Vasya; mitia.mackarevich; AlenaR; alsegor; Gluk_1C; pfilyk; artbear; alest; Tavalik; ivanov660; Dmitri93; azhilichev; Aleskey_K; ifilll; @lexandr; YLioY; корум; Dem1urg; chebser; comol; Kim1C; adapter; KapasMordorov; brr; temdj; pm74; Krasnyj; +39 Ответить
6. Krasnyj 1288 22.08.17 00:21 Сейчас в теме
(4)
Осталось вам вывести отдел разработки в отдельное юрлицо.


И этому юрлицу мгновенно станут задерживать оплату, а разрабы будут требовать зарплату с ТС (ту же самую белую, а это налоги). И вот тогда они и начнут разбегаться.
1cccc; user761890; корум; +3 Ответить
15. dmpas 418 22.08.17 08:44 Сейчас в теме
(6)
И вот тогда они и начнут разбегаться.

Да ну и пёс с ними. Такая система в итоге должна предполагать низкую зависимость от личности разработчика и устойчивость к текучке. Типичная же франча, только в рамках одного клиента.
Deslime; ДАК1; user761890; uncle_Vasya; AlenaR; Ta_Da; ice-net; artbear; jobkostya1c_ERP; chebser; KapasMordorov; +11 Ответить
17. Krasnyj 1288 22.08.17 08:50 Сейчас в теме
(15)
Да ну и пёс с ними. Такая система в итоге должна предполагать низкую зависимость от личности разработчика и устойчивость к текучке. Типичная же франча, только в рамках одного клиента.


Предполагать система может все, что угодно. Вы посчитайте, сколько народу, поработав во франче, создало себе клиентские базы. Да и пока автор будет снижать зависимость от личности - зарплату этой личности уже надо будет не один раз заплатить, а то личность сбегает в трудовую, и контору в три узла завяжут. И если автор на правах начальника отдела, то прямой ответственности за зарплату он не несет. А вот если он вывел этот отдел на отдельный баланс - тут извините уже...
uncle_Vasya; +1 Ответить
19. dmpas 418 22.08.17 09:06 Сейчас в теме
(17)
сбегает в трудовую

насколько я понял, с точки зрения ТК у них всё более менее ровно. Если я ничего не упустил.
uncle_Vasya; +1 Ответить
25. Krasnyj 1288 22.08.17 09:35 Сейчас в теме
(19) Это сейчас ровно. Потому, что это - отдел чего-то большого. А если такой отдел станет ООО-шкой с автором во главе, то зарплату своим людям будет должна эта ООО-шка (т.е., по сути, автор лично), а фактическая зарплата будет платиться "заказчиком" через расчетный счет на эту ООО-шку, и будет это не вторая очередь платежа, а пятая. Да еще за "аренду офиса" вычтут :)
uncle_Vasya; +1 Ответить
53. 1c-intelligence 12852 22.08.17 10:23 Сейчас в теме
(25) фантазировать не буду, т.к. ОООшки нет.
Когда будет - расскажу об опыте (если будет что)
47. 1c-intelligence 12852 22.08.17 10:12 Сейчас в теме
(15)
Такая система в итоге должна предполагать низкую зависимость от личности разработчика и устойчивость к текучке

да, такое предполагалось, но не пригодилось - текучки не было.

(15)
Типичная же франча, только в рамках одного клиента.

не совсем. Здесь было важно тесное общение с заказчиками, чтобы знать их потребности лучше самих заказчиков. Франчи таким вроде не увлекаются.
32. 1c-intelligence 12852 22.08.17 09:49 Сейчас в теме
(6)
И этому юрлицу мгновенно станут задерживать оплату, а разрабы будут требовать зарплату с ТС (ту же самую белую, а это налоги)

конкретно этим разрабам зарплату не задерживали ни разу.
Сейчас их доход выше среднего по Челябинску на 30-45 %.
33. Krasnyj 1288 22.08.17 09:50 Сейчас в теме
(32) Правильно. Потому, что эти разрабы - на работе непосредственно у владельца бизнеса. А если они перейдут на работу в ООО-шку, выделенную для IT-обслуживания... я вот о чем.
8. pm74 203 22.08.17 07:46 Сейчас в теме
(4)
раньше хоть как-то думали, а теперь накостылил и ладно

классический треугольник время-деньги-качество
user761890; uncle_Vasya; AlenaR; rovenko.n; +4 Ответить
30. 1c-intelligence 12852 22.08.17 09:46 Сейчас в теме
(4)
я так понимаю, вы не в Москве, раз так измываетесь над разрабами и они от вас до сих пор не свалили?

дело было в Челябинске. Рынок труда программистов 1С - такой же как везде, т.е. спрос значительно превышает предложение.
Я в этой конторе проработал 6 лет, программисты до старта этой системы 2-3 года. За 6 лет ИТ-отдел вырос с одного человека до 8 человек, текучка была равна нулю. Я первый, кто оттуда уволился.

А как же фактор автобуса, нет? Одну область должны покрывать хотя бы двое.

В итоге большинство областей знали 75 %. Узких областей было мало - это то, что делал я в первые 2-3 года, когда был один. Оно работало и работало, есть не просило, поэтому и разбираться не приходилось.
(4)
Программисты хорошо умеют работать на показатели.

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

(4)
Упустил, на протяжении какого времени это уже продолжается??

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

(4)
участие хоть и минимальное, но критичное.

В той конкретной компании - нет, для меня по крайней мере. Я хорошо знал людей и их задачи.
120. vlavek 23.08.17 14:14 Сейчас в теме
(30)
Я первый, кто оттуда уволился.

Т.е. уволился тот кто эту кашу заварил?
zqzq; awk; user761890; uncle_Vasya; +4 Ответить
122. 1c-intelligence 12852 23.08.17 15:17 Сейчас в теме
39. 1c-intelligence 12852 22.08.17 09:59 Сейчас в теме
(4)
А то небось, раньше хоть как-то думали, а теперь накостылил и ладно

проверка качества не была формализована, но трудностей не было, все знали мое отношение к говнокоду. Если интересно - гляньте описание решений кастомизации на лету (https://infostart.ru/public/516379/), или опубликованные https://infostart.ru/public/290094/. Вроде не очень на костыли похоже. Все эти решения появились в той компании и той команде.
chebser; pm74; +2 Ответить
94. dmpas 418 22.08.17 12:30 Сейчас в теме
(39) говнокод виден сразу. А кривая архитектура нет.
user761890; uncle_Vasya; Ta_Da; Dem1urg; +4 Ответить
171. Светлый ум 423 24.08.17 10:39 Сейчас в теме
(0 )в ТАКИХ командах растешь относительно быстро если выдерживаешь нагрузку.
Действительно достойные вещи обычно создаются в стрессовой ситуации, это вам любой человек с творческой профессией скажет

(4)
- для молодого спеца поработать в такой команде полезно, для опытного бессмысленная трата времени
NeLenin; awk; +2 Ответить
173. 1c-intelligence 12852 24.08.17 10:43 Сейчас в теме
(171) у вас такой ник, что мне страшно вам возражать.

А опытному где полезно время тратить?
174. dmpas 418 24.08.17 14:12 Сейчас в теме
(173)
А опытному где полезно время тратить?

а опытный не тратит время :-)
NeLenin; zqzq; uncle_Vasya; +3 Ответить
177. 1c-intelligence 12852 24.08.17 14:48 Сейчас в теме
178. genayo 24.08.17 15:20 Сейчас в теме
(174) Опытный пытается делать как можно меньше за как можно большие деньги :)
mityushov.vv; DmitrySinichnikov; zqzq; uncle_Vasya; +4 Ответить
183. 1c-intelligence 12852 28.08.17 10:09 Сейчас в теме
(178) ну т.е. принцип-то тот же самый: ускорение.
Если ты научишься решать задачи вдвое быстрее, то сможешь зарабатывать больше.
Если ты фрилансер или франч, то решая задачу вдвое быстрее, ты можешь ее продавать клиенту за те же деньги, а времени тратить меньше. Клиенту польза - он выигрывает в сроке. Тебе польза - ты можешь зарабатывать вдвое больше.
Можно сделать дисконт, чтобы клиенту было приятнее. Например, решать вдвое быстрее, клиенту продавать на 25 % дешевле конкурентов, времени тратить на 50 % меньше конкурентов.
Если ты на фиксе, то можешь решать задачи вдвое быстрее, никому об этом не говорить, а освободившееся время тратить на свои стратегические цели. Если есть возможность продать текущему работодателю свое время дороже, то можно в этом направлении поработать.
Если продать дороже нет возможности, то можно делать левые подработки. Или, как многие тут пишут - разворачивать демобазы, курить новые механизмы, бла-бла-бла.
184. genayo 28.08.17 10:33 Сейчас в теме
(183) Это вы берете хорошего профессионала, далеко не все такие. Некоторые просто тратят свободное рабочее время на чтение форумов, просмотр ютуба и т.д, им быстрее работать не надо...
185. 1c-intelligence 12852 28.08.17 10:39 Сейчас в теме
(184) да, каждому своё.
Главное же с собой честным быть, разве нет?
Если все равно на работе 8 часов сидеть, то почему бы не потратить это время с большей пользой?
186. TODD22 19 28.08.17 10:40 Сейчас в теме
(185)
с большей пользой?

Пользу для себя каждый сам определяет....
187. 1c-intelligence 12852 28.08.17 10:49 Сейчас в теме
(186) см выше:

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


Можно и на турнике повисеть, и с девчонками сходить чай попить, и metadata.js покурить, и книжку почитать, и статью на инфостарте написать, и домой пораньше свалить, и <тут свое добавьте, что хотите>.
188. genayo 28.08.17 10:56 Сейчас в теме
(185) Но вы против подхода - все задачи закрыты вовремя и качественно - и не важно, что на это потрачено по факту 4 часа из 8?
189. 1c-intelligence 12852 28.08.17 10:59 Сейчас в теме
(188) я против того, чтобы "вовремя" определялось извне, как данность, т.к. это убивает стремление к эффективности.
191. genayo 28.08.17 11:09 Сейчас в теме
(189) Не понял, стремление кого и к какой эффективности? Бизнеса или разработчика? И если бизнес-процесс меняется например с 20 числа, бизнес ставит задачу реализовать автоматизация изменений к 15 числу, то это "вовремя", поставлено извне, и это плохо?
194. 1c-intelligence 12852 28.08.17 13:00 Сейчас в теме
(191) в описанной вами постановке очень много неясностей и путей развития.
Например, почему бизнес-процесс меняется с 20 числа? Не потому ли, что автоматизация изменений закончится 15 числа?

Допустим, разговор происходит в последний день предыдущего месяца. Тогда на изменение бизнес-процесса нужно 20 дней, на автоматизацию 15 дней. Какова в проекте изменений доля автоматизации? По трудозатратам, по важности?

Что будет, если автоматизация займет не 15, а 3 дня? Ускорится ли изменения бизнес-процесса?
Ускорение изменения бизнес-процесса - важно для бизнеса? Или там изменения раз в год происходят?

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

Какова доля бюрократии и бумажек в этих 20 днях? А в этих 15 днях на автоматизацию?

Как часто происходит отмена изменений? Апгрейд изменений, когда сразу после запуска стало ясно, что надо не сильно, но изменить курс?

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

Сколько времени уходит на ТЗ для разработчика? Сколько корректировок вносится в ТЗ после того, как его прочитал разработчик? Сколько времени уходит на согласование?

В зависимости от ответов на эти вопросы станет ясно, причем тут эффективность бизнеса и эффективность разработчика, и как они связаны.

Вполне может быть, что не связаны, и все нужно оставить как есть. А может оказаться, что программисты 1С - главный тормоз в развитии предприятия. Но они настолько уверены в себе и красиво рассказывают о сложности автоматизации, что с ними ничего нельзя поделать.
196. genayo 28.08.17 13:55 Сейчас в теме
(194) Самый простой пример - для запуска процесса нужно внесение новых данных. Вносить пользователи их смогут только после 15 числа, не важно по каким причинам. Соответственно, автоматизация раньше 15 числа не нужна.
197. 1c-intelligence 12852 28.08.17 14:00 Сейчас в теме
(196) ну так и ладно. Можно сделать автоматизацию за 3 дня, и и оставить в покое.
За оставшиеся 12 дней сделать еще 4 таких автоматизации.
Или в Турцию слетать, коксаки на себе испробовать. Или 5 книжек прочитать.
не важно по каким причинам

действительно не важно? или не интересно? насколько можно повлиять на этот срок?
Может, он вполне себе резиновый?

Главное - если работа занимает 3 дня, а начальство отвело на нее 15 дней, то не стоит заниматься ей 15 дней. Это мое личное мнение.
mifka186; +1 Ответить
198. genayo 28.08.17 14:55 Сейчас в теме
(197) Не стоит. Но бизнесу без разницы, 3 дня на нее потрачено или 15, если результат аналогичный. А вот сделать за 3 дня, а потом самому себе задачи выдумывать, чтобы получить туже зарплату - это не каждый способен...
199. falcon 28.08.17 21:35 Сейчас в теме
(198) ну так-то, бизнесу не без разницы сколько потрачено... ему может быть без разницы в какие из 15 дней, было выделено эти необходимые для доработки 3 дня....
200. genayo 28.08.17 22:24 Сейчас в теме
(199) Если не знать, что это можно сделать за 3 дня - без разницы ;)
202. 1c-intelligence 12852 29.08.17 14:10 Сейчас в теме
(198) опять за бизнес отвечаете :)
Ни один из директоров/собственников, с которыми я об этом говорил, не сказал, что ему без разницы.
а потом самому себе задачи выдумывать, чтобы получить туже зарплату

зачем самому выдумывать - спросите у бизнеса. Если желание есть, конечно.
203. genayo 29.08.17 14:40 Сейчас в теме
(202) Да, настоящий профессионал должен стремиться делать больше работы за теже деньги :)
Ну ладно, я в общем конечно с вами согласен в большей части, это так, больше для поддержания разговора с умными людьми возражения :)
204. 1c-intelligence 12852 29.08.17 14:43 Сейчас в теме
(203)
Ну ладно, я в общем конечно с вами согласен в большей части

фуф, ура. Я этого и добивался.
Успехов вам!
7. &rew 52 22.08.17 06:56 Сейчас в теме
Интересно, живо, красочно, но не покидает ощущение "слащавости" (по типу того, как рыбаки улов свой хвалят).
Объясню:
1. "на управление тремя программистами - 30-60 минут в день", это да. Но вот еще нужно время на управление хотелками заказчиков. Сколько времени уходило у Вас внутри вашей компании?
2. В статье удивило то, что внешний HR-консультант не слышал о системе "запомнить минус" и "ограничение выплат". Это ж в чистом виде система "Аванс/получка/отгул". Получил авансом, не отработал его, в след месяце удержат. Переработал, иди в отгул (чтобы больше не платить).
Эту систему мы и с клиентами на техподдержке применяем. Есть фиксированное количество часов. Если в одном месяце переработали, в другом, "удерживаем". Если не получается в силу объема задач, то пересматриваем количество выделяемых часов и т.д. по кругу.
3.И вот это" за свой счет (размышления, интернет, общение в мессенджерах, перекуры, нытьё, депрессии и т.д.)." С одной стороны согласен, а с другой - нытье очень часто является поводом задуматься и спросить у человека, что ему надо для повышения эффективности. Интернет, а как без него? Естественно, речь о профильных сайтах. Это же вопрос компетенции. Размышления и перекуры - честно говоря в курилке с опытными программистами, будучи новичком, многому научился.
И, да, статья понравилась. Много полездного + Вам в карму и в рейтинг.
uncle_Vasya; AlenaR; корум; +3 Ответить
37. 1c-intelligence 12852 22.08.17 09:56 Сейчас в теме
(7)
но не покидает ощущение "слащавости" (по типу того, как рыбаки улов свой хвалят).

если такое ощущение складывается, то не намеренно. Наверное, слишком долго работал ИТ-директором.

(7)
о вот еще нужно время на управление хотелками заказчиков. Сколько времени уходило у Вас внутри вашей компании?

у меня, скорее, не на управление хотелками, а на создание хотелок. Большинство проектов я сам инициировал, защищал, "продавал". Времени - столько, сколько сам решу.

(7)
что внешний HR-консультант не слышал о системе "запомнить минус" и "ограничение выплат"

Я видимо коряво написал в статье. Он не "не слышал", а ему понравилось, что в моей системе применены эти элементы.

(7)
нытье очень часто является поводом задуматься и спросить у человека, что ему надо для повышения эффективности

разумеется. Речь в статье - про бессмысленное нытьё. Поныть по делу я сам люблю.
(7)
Интернет, а как без него?

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

согласен, сам курю и люблю там совещания проводить. Важно, чтобы человек сам понимал, полезны ему перекуры или нет.
9. Doom2w 37 22.08.17 07:57 Сейчас в теме
Оценка выполнения задачи (выполнена или не выполнена) осталась за кулисами.
AlenaR; itriot11; chebser; kraynev-navi; +4 Ответить
40. 1c-intelligence 12852 22.08.17 10:00 Сейчас в теме
(9) оценку давал заказчик:
1. Принимал работу (булево);
2. Ставил оценку качества от 1 до 5 (цифра).
10. PerlAmutor 155 22.08.17 08:05 Сейчас в теме
В традиционной, окладной системе, работодатель тебе оплатит время, пока ты там ковыряешься сидишь.

Ситуация из жизни. Оклад 10 000 руб. остальное премия. Какой смысл работать сверхурочно или по выходным, если в отличие от будней стоимость часа ниже в несколько раз?
11. Goleff74 218 22.08.17 08:15 Сейчас в теме
А мотивация руководителя отдела какая? Ну, кроме возможной коррупционной составляющей.
uncle_Vasya; alsegor; chebser; Krasnyj; +4 Ответить
12. dmpas 418 22.08.17 08:38 Сейчас в теме
(11)
А мотивация руководителя отдела какая?

он же всё-таки программер в душе - так что ему может быть просто-напросто интересно :)
uncle_Vasya; +1 Ответить
43. 1c-intelligence 12852 22.08.17 10:06 Сейчас в теме
(12)
он же всё-таки программер в душе - так что ему может быть просто-напросто интересно :)

да, вы уловили суть. Систему мотивации я делал, в основном, ради интереса - хотел понять, насколько сложнее программировать людей и процессы, чем 1С.
42. 1c-intelligence 12852 22.08.17 10:05 Сейчас в теме
(11)
А мотивация руководителя отдела какая? Ну, кроме возможной коррупционной составляющей.

На тот момент - оклад и премия за хрен-пойми-что.
Коррупционную составляющую отсекали спец.средствами.
13. smurf2315 22.08.17 08:42 Сейчас в теме
Не совсем понятно - кто оценивает трудоемкость поступающих задач? Руководитель? Тогда это конечно здорово, но так бывает конечно очень редко.
44. 1c-intelligence 12852 22.08.17 10:07 Сейчас в теме
(13)
Не совсем понятно - кто оценивает трудоемкость поступающих задач? Руководитель? Тогда это конечно здорово, но так бывает конечно очень редко.

значит, нам повезло :)
14. PerlAmutor 155 22.08.17 08:43 Сейчас в теме
Автор статьи наверное забыл, что программисты - люди, со всеми вытекающими (как бы это странно не звучало).
Какая мотивация предполагается для тех программистов на которых перекладывают чужие задачи в момент отпуска или болезни другого программиста, а в момент увольнения одного из, пока ищут нового кандидата? Тут 2 варианта, либо организация передвигает сроки и ждет пока до этой задачи доберутся те кто остался, либо бесплатно (как обычно бывает) их эксплуатируют.
uncle_Vasya; +1 Ответить
16. dmpas 418 22.08.17 08:46 Сейчас в теме
(14)
либо бесплатно (как обычно бывает) их эксплуатируют

так вот же она, мечта!!! На тебя работают с диким азартом, а им ещё и платить можно меньше!
awk; uncle_Vasya; Ta_Da; корум; chebser; KapasMordorov; Krasnyj; +7 Ответить
18. PerlAmutor 155 22.08.17 08:56 Сейчас в теме
(16) у многих руководителей есть очень неприятная особенность - они повышают в должности, повышают зарплаты или премии только тем, кто часто к ним бегает с просьбами или кто выносит мозг день за днем. А про тех кого не видно и не слышно - они забывают, их как будто нет, а раз нет, значит всем довольны и их все устраивает и им не нужна мотивация. Как правило это оборачивается тем, что внутри коллектива начинается раздор из-за несправедливости, а самый молчаливый внезапно решил уволится. Тут руководитель может его пригласить и попытаться уговорить остаться повысив немного зарплату. И это вместо того, чтобы её индексировать и повышать каждый год всем сразу.
IrinaKostroma; Ta_Da; Nelli_A86; +3 Ответить
28. Krasnyj 1288 22.08.17 09:42 Сейчас в теме
(18)
Тут руководитель может его пригласить и попытаться уговорить остаться повысив немного зарплату. И это вместо того, чтобы её индексировать и повышать каждый год всем сразу.


В кризисное время индексация зарплаты - очень непопулярное решение. На всех финансистов, начальников и прочих командиров давят владельцы и генеральные директора - снизить себестоимость, любой ценой, при этом намякивается, что если не будет снижена себестоимость, то будет снижена зарплата носителей соответствующих компетенций. А на чем проще и быстрее всего снизить себестоимость можно? Да на зарплате рабов же...
Nelli_A86; +1 Ответить
49. 1c-intelligence 12852 22.08.17 10:15 Сейчас в теме
(18)
у многих руководителей есть очень неприятная особенность - они повышают в должности, повышают зарплаты или премии только тем, кто часто к ним бегает с просьбами или кто выносит мозг день за днем

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

увы, это было не в моей власти.
48. 1c-intelligence 12852 22.08.17 10:13 Сейчас в теме
(16)
так вот же она, мечта!!! На тебя работают с диким азартом, а им ещё и платить можно меньше!

Почти. Платить немного выше рынка, а результата получать в 2-3 раза больше. И да, с диким азартом :)
20. MyPuK_OLD 22.08.17 09:06 Сейчас в теме
(14)
Какая мотивация предполагается для тех программистов на которых перекладывают чужие задачи в момент отпуска или болезни другого программиста, а в момент увольнения одного из, пока ищут нового кандидата? Тут 2 варианта, либо организация передвигает сроки и ждет пока до этой задачи доберутся те кто остался, либо бесплатно (как обычно бывает) их эксплуатируют.

А вариант оплатить "заменяющему" программисту по часовой ставке? Ведь он же сделает работу за отсутствующего. Все довольны, заказчик получил решение, "заменяющий" доп.доход.
29. PerlAmutor 155 22.08.17 09:45 Сейчас в теме
(20) Имеется ввиду по двойной часовой ставке? Или всё по той же на которой он работает?
Или программист 1С должен работать вместо 8 часов - 16? Причем он вправе отказаться работать больше 40 часов в неделю, но ведь такой отказ не понравится ни одному руководителю.
38. MyPuK_OLD 22.08.17 09:57 Сейчас в теме
(29)Имею ввиду, если программист свободен от своих задач(сделал все например), не сидеть же дальше тупо на окладе(бездельничать). Можно взять работы предназначенные для "отсутствующего" и получить за него почасовую оплату.
58. 1c-intelligence 12852 22.08.17 10:30 Сейчас в теме
(38) можно, разумеется.
Но ситуации сидения без задач не было никогда.
46. 1c-intelligence 12852 22.08.17 10:10 Сейчас в теме
(14)
Автор статьи наверное забыл, что программисты - люди, со всеми вытекающими (как бы это странно не звучало).

я об этом не забыл, я из этого исходил.

(14)
Какая мотивация предполагается для тех программистов на которых перекладывают чужие задачи в момент отпуска или болезни другого программиста

зависит от долей участия. Была возможность указывать нескольких исполнителей для задачи с разными КТУ.
Увольнений не было.
21. Goleff74 218 22.08.17 09:27 Сейчас в теме
А как с планированием быть? У нас работают неидеальные программисты. Подход "сделал медленнее - получил меньше в течении периода" не позволяет рассчитать контрольные точки. Стихийное программирование получается.
Или мы лицемерно для расчета ФОТ используем одни часы, для планирования другие? :)
22. dmpas 418 22.08.17 09:31 Сейчас в теме
(21)
Подход "сделал медленнее - получил меньше в течении периода" не позволяет рассчитать контрольные точки.

Отчего же? Есть оценка скорости каждого сотрудника - в долях от эталона. От неё и считать план + процент запаса.
34. Goleff74 218 22.08.17 09:50 Сейчас в теме
(22) Тут есть стек задач, которые разрабы дербанят. Мы не знаем, кто будет выполнять ту или иную задачу. Учитывая конкуренцию внутри команды, надеяться на "договорятся, поделят области ответственности" чересчур оптимистично.
54. 1c-intelligence 12852 22.08.17 10:25 Сейчас в теме
(34) стек задач по исполнителям делил я. Если программисты просили переделить какую-то задачу - я соглашался обычно.
50. 1c-intelligence 12852 22.08.17 10:17 Сейчас в теме
(21)
Или мы лицемерно для расчета ФОТ используем одни часы, для планирования другие? :)

планирование делал движок "планирование ресурсов". Брал за основу оценку в часах "по лучшему", умножал на коэффициент "тупежа" конкретного человека, и получался срок выполнения задачи.
Требований по срокам от заказчиков не было - за это я отвечал, как руководитель. Был только плановый срок завершения, рассчитанный системой.
51. Krasnyj 1288 22.08.17 10:19 Сейчас в теме
(50)
Требований по срокам от заказчиков не было - за это я отвечал, как руководитель. Был только плановый срок завершения, рассчитанный системой.


Нда... всем бы такой адм. ресурс.
60. 1c-intelligence 12852 22.08.17 10:39 Сейчас в теме
(51) этот ресурс создается или не создается вами, априори его нет.
Я пришел в компанию программистом, собственника увидел первый раз через полгода.
Пересказывать не буду, все есть в статье https://infostart.ru/public/622937/
61. genayo 22.08.17 10:41 Сейчас в теме
(60) А если вы приходите в компанию программистом, а там уже есть начальник отдела и ИТ-директор, через сколько вы попадете на совещание с участием собственников?
64. 1c-intelligence 12852 22.08.17 10:46 Сейчас в теме
(61) я в такой ситуации был только один раз, сразу после франча, и хотел просто отдохнуть и отсидеться, цели попасть на встречу не было. Попал через год, силой затащили.
67. genayo 22.08.17 10:49 Сейчас в теме
(64) Тоесть на совещании с собственником присутствовал ИТ-директор, начальник отдела и программист?
69. 1c-intelligence 12852 22.08.17 10:51 Сейчас в теме
(67) обычно да, формально присутствовали.