System Analysis and Design
IT career
Programming
Personnel Management
Project management
Comments 33
-2
Успех данного проекта лишь в том, что минимальная оплата работника — текущий оклад. Тут любой будет качественно и быстро работать, что бы увеличить ЗП, но при этом «ЕслиЧё» остаться при своём.

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Тяп-ляп и в продакшен. Кому захочется бесплатно обдумывать как сделать адекватный, масштабируемый проект, если ему платят непосредственно за написание кода. Сколько часов уйдет на сопровождение и развитие таких слабых решений неизвестно. Возможно поэтому
Задачи не могли кончиться
Only logged in users are able to leave comments. , please.