Pull to refresh

Comments 33

Успех данного проекта лишь в том, что минимальная оплата работника — текущий оклад. Тут любой будет качественно и быстро работать, что бы увеличить ЗП, но при этом «ЕслиЧё» остаться при своём.

Не хватает: Сколько программистов в компании и сколько задач в день, неделю месяц.

Есть ли у Вас аналитики, как вы проводите обследование процессов, перед реализацией.

Не понятно как вы решаете вопросы — типа сделал, нужно проверить бухгалтеру, и на этом ожидание… А проект висит.

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

Так же поясните, если у вас маленькая компания и как вы набираете столько задач, что бы увеличивать ЗП программистам.
Программистов четыре, включая меня.
Задач 100-150 в месяц.
Аналитики — мы сами.
Проекты, как сущность, мы тогда уже выкинули — был только поток.
Ожидание проверки было, до месяца — дальше сам закрывал, без проверки. Но, в целом, проблем не было, потому что не принимал от человека новую задачу, если он старую не проверил.
Если руководство скажет уменьшить ставку, то придется искать новых программистов.
А задач становилось все больше, т.к. мы делали их все быстрее.

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

В тексте перечислены «начальные» характеристики четырёх программистов:


  1. мог часами обсасывать подводные камни, набивая себе цену (непонятно, правда, зачем — оклад же).
  2. любил часами сидеть и «думать над оптимальным решением».
  3. интраверт, который… стеснялся поговорить с заказчиком.
  4. новичок, который раньше стеснялся задать коллегам вопрос.

Т.е. вы здесь номер 2?

Спасибо за статью! Интересный опыт. Благодаря подобным статьям у программистов может и отношение к 1С поменяться :)

Странными кажутся оценки задач, приведенные в статье — по 10-15 минут. Здесь речь больше про конфигурирование/администрирование, или всё-таки про разработку? Если про разработку, то как в такое в такое время влазит тестирование?
И меня тоже смутило:
Понятно, что некоторые задачи содержали в себе несколько пунктов классификатора — например, регистр, плюс несколько реквизитов, плюс отчет, плюс автозадача. Время в этом случае суммировалось.

Вот не учтено время проверки взаимодействия всего этого (тестирование). По раздельности может всё и работает, а вместе?
Я сомневаюсь, что отношение к ним может поменяться, опоздали на несколько лет)
10-15 минут вполне достаточно, чтобы сделать, например, отчет по одному регистру накопления, без понтов с оформлением. Ну и тестировать там, вроде, особо нечего.

Это ж внутренняя автоматизация, там тестирование лежит на плечах пользователей, зачем приличным людям на него время тратить особо.
Поздравляю! Вы создали схему отдела внедрения франча. Хороший внедренец всегда знает, сколько стоит час его работы. В одном крупном франче в своё время предлагалось на выбор три схемы оплаты: нулевой оклад + большой процент, небольшой оклад + средний процент, высокий оклад + низкий процент. Почти все внедренцы сидели на первой схеме, ибо считать умеют.
в статье так и написано, что схема — не наше изобретение. Половина из программистов, включая меня, работали раньше во франче.
Фишкой было применение сделки на внутренней автоматизации.
Статья конечно интересная, спасибо что поделились опытом, но оценка задачи в 15 минут, на аналитику 5 минут… про тестирование ни чего, про возврат на доработку не чего, про заказчик пердумал ни чего, про бодания на приёмо сдаточных испытаниях ни чего, учесть ваш опыт можно, но в чистом виде мне кажется не применимо

И если была такая система мотивации которая всех устраивал, то зачем её поменяли на скрам и другие не понятные слова? или вы поменяли место работы и там эта система не взлетела?

И все приятные бонусы от этой системы это следствия учёта, а учёт метрик это по моему первое дело любого руководителя, научиться ходить па приборам, а не по субъективным оценкам
о оценка задачи в 15 минут, на аналитику 5 минут… про тестирование ни чего, про возврат на доработку не чего, про заказчик пердумал ни чего, про бодания на приёмо сдаточных испытаниях ни чего


во-во, так программисты и говорили поначалу. А потом поняли, что и 15 минут — много, если сопли не жевать.
Значит специфика задач такая что для творчества в ней места нет :) и всё что программисты делают это применяют наработанные навыки и шаблоны. Я от такой работы сбежал при первой возможности.
Задачи разные бывают же. И на 15 минут, и на 15 дней.
Здесь даже самоменеджмент можно проявить: с утра для разогрева пощёлкал пару мелочевок, а потом взял рыбу покрупнее.
Возможно я идеалист, но что, если все задачи закончились? Ну вот так вышло, что все задачи выполнены и их больше нет, или поток задач намного медленнее, чем их скорость их выполнения. Тогда получать выше одного оклада — не получится, да ещё и будешь уходить в минус из месяца в месяц. Т.е. просидишь 1-2 месяца совсем без задач, и следующие месяца будешь работать на минус, который был не по твоей вине, таким образом выбраться из чистого оклада будет очень сложно.
задачи могут закончиться только в идеальноммире где люди значют что им надо и как им надо. Программистов грузят работой просто потому что могут, а не потому что это надо предприятию, такое отношение к программистам не только у линейных сотруджников и менеджеров среднего звена, но и у директоров.
Я бы даже конкретизировал: как быть, если в результате ввода описанной «полусдельной» оплаты окажется, что на отдел из, например, трёх программистов, идёт поток задач такой, что загружены будут не все три, а 2,5? То есть одного не уволишь – оставшиеся будут перегружены, но в текущем составе постоянный недогруз (а значит, падание доходов, грызня за приходящие задачи и прочие признаки безработицы).
Задачи не могли кончиться, потому что темы автоматизации инициировал я сам. А их было уже тогда на несколько лет вперед.
Этот комментарий удивительно коррелирует с фразой из статьи:

Апофеозом стал доклад на стратегической сессии с неутешительным итогом — больше половины денег компания тратит на бессмысленную автоматизацию.
ну, все честно. То, что инициировал я — полезное, остальное — вредное :)
Вот это по нашему! Так и должно быть. :D
*пошел чекаться с Наполеоном из соседней платы*
Прекрасная статья. Но у вас очень доброе руководство.
Иное руководство с характерным прищуром и интонацией у вас бы спросило не много ли у вас людей в отделе. Если вместо работы вы можете себе позволить системы мотивации разрабатывать. :)

Ну и… если оклад отмерен 60тр. То с чего бы платить 100? Общее количество работы 1Сшников на предприятии то не меняется. А по вашей же статье — упало.

Хотя можно зачесть в «экономию» то что выявилось в «приятном бонусе». Вот это действительно результат.
Хорошая статья, как впрочем и все Ваши публикации. В качестве дружеского замечания, оклад Зам. гл. бух. получается меньше 25, это если вся техподдержка оказывается ему. Хотя, наверно объем техподдержки существенно вырос с ростом выработки отдела.
Жестковато.
Люди после 3-6 месяцев не потянулись на выход?
Как по мне, в таком режиме можно выполнять только простейшие, разжованнейшие задачи. Возьми там, положи туда, умножь и сложи. И то возможны конфликты типов данных, проблемы масштаба, скорости работы и т.п.

Где-то читал, что достижимый результат для программиста — работать 5 часов в день, час через час, большинство либо работает меньше, либо не то чтобы программирует. Программирование != только написание кода, большая часть работы — его обдумывание, в т.ч. неявное. Плюс оформление, тесты, приемка, доработка ТЗ, доставка до прода.
Один из неочевидных плюсов переменной ЗП в том, что она помогает побороть синдром самозванца. Об этом косвенно есть в статье (в отзывах и переменах программистов), но я бы хотел подробнее подчеркнуть.

Потому что обычный программист «на окладе» нет-нет да и начнёт сравнивать себя с мужиком, который за 15-20 т.р. работает на заводе или ЖД, со школьным учителем с 12-часовым рабочим днём и т.д. И сравнение явно будет не в свою пользу (получает в разы больше, а работает в разы меньше, в более «тепличных» условиях).

Кто-то, боясь «разоблачения», начинает работать максимально втихую — мол, если не отсвечивать, то может, начальство не заметит и не уволит. Кто-то наоборот, начинает громко набивать себе цену, спуская на это кучу рабочего времени.

А с переменной ЗП необходимость в этом пропадает — всем сразу видно, за что и сколько платят, всё по-честному, а не по недосмотру.

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


Я бы свалил подальше от таких оценок, удивительно, что программисты согласились так работать. Это вдвойне странно, учитывая, что оцениваются задачи по "идеальному программисту", а таковых в вашем коллективе нет, кроме вас)) то есть люди заранее соглашаются с недооценкой задачи, у них гарантировано уйдёт больше времени? При этом оценка в полтора-три раза ниже, чем у внешних оценщиков… Или все так стремились стать идеальными, или где-то подвох.

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

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

Вроде — сядь и разберись, чего такого-то, всегда так делали»

Стоп… Программисту поставлена конкретная задача «сделать заполнение субконто Склад». Зачем ему лезть в изучение схемы по переработке?
Или это тупое транслирование бездумной хотелки какого-то бухгалтера «хочу видеть субконто на 003 счете»? Тогда проблемы на фирме очень большие, и не в программистах и их мотивации, а в отсутствии на фирме грамотного постановщика задач, а вся дальнейшая суета — смысла не имеет, ибо задачи ставятся черт-те как.
Вообще-то Фредерик Тейлор на тему хронометража рабочего времени уже отписался...100 лет назад. Плюсы и минусы станут очевидны через какое-то время, когда у руководства появится соблазн злоупотребить.
У нас была одно время схожая система, но с другим подходом к оценке. Нас было 4 человека и ЛПР. В пятницу мы просматривали задачи на следующую неделю и ставили свои оценки — ту я сделаю за полчаса, эту за час и т.д. Оценки видны только оценивающему и ЛПР, чтобы оценки были независимы. Это была наша сторона.
Со стороны ЛПР использовалась корелляция оценки с учетом опыта — один занижал время, считая что сделает на раз-два, другой наоборот всегда брал резерв «на всякий случай». И уже на основании этого принималось решение — сколько каждая задача должна решатся. Это время и шло в зачет, вне зависимости от рельно затраченного.
мы все прекрасно знаем, что одну и ту же задачу можно решить путем создания 15 регистров и 20 отчетов или правильной настройки типового функционала и обучения пользователей. Ваша система мотивирует людей на первый вариант, много кода бессмысленного и беспощадного.
На первый взгляд вы разработали потогонную систему, которая взяла худшие черты от автоматизации, отданной на аутсорс, и от автоматизации силами фикси. В итоге ваши программисты не мотивированы решать задачи качественно, а мотивированы на «тяп-ляп-и-в-продакшен» аля франч, но при этом несут куда меньшую ответственность (только в рамках своей надбавки). Что из этого выйдет — покажет время, потому что в начале пути люди полны оптимизма, а вот потом придет усталость и выгорание от потогонки. Франчи с этим борются постоянной ротацией кадров. Если ваш ИТ-отдел не превратится в проходной двор, и сохранит высокую производительность, не будет регулярно возвращаться к одним и тем же автоматизированным задачам, значит у вас все получилось. Было бы интересно прочитать на Хабре отчет через полгода-год.
Опыт, описанный в статье, случился года 4 назад, если я правильно помню.
эх! как приятно и легко мотивировать людей на автоматизации — там и задачи более-менее типовые, и отчеты ясные, и задачи сформулированные.
Я сам с автоматизации начинал. Через пару лет автоматизировали даже автоматизацию, чтобы можно было сразу из ТЗ генерировать скелеты будущей системы и отчеты по ней.

А потом я ушел к игроделам. Это не программисты. Это алхимики\физики-ядерщики. Какие оценки проектов, если никто раньше не делал это?
«Ребята, вот новый телевизор из Кореи, его еще не выпустили на продажу, подпишите НДА. Там внутри вроде бы линукс. Надо разобраться и портировать на него вот эту игру. Скажите, сколько вам надо на это времени, но только нужно успеть до старта его продаж 25 декабря» — вот почти типичная постановка задачи.
Но главное — в нашу часовую ставку входила только непосредственная работа. В ней не было раздумий, моделирования, анализа решений и т.д.

Тяп-ляп и в продакшен. Кому захочется бесплатно обдумывать как сделать адекватный, масштабируемый проект, если ему платят непосредственно за написание кода. Сколько часов уйдет на сопровождение и развитие таких слабых решений неизвестно. Возможно поэтому
Задачи не могли кончиться
Sign up to leave a comment.

Articles