Comments 33
Не хватает: Сколько программистов в компании и сколько задач в день, неделю месяц.
Есть ли у Вас аналитики, как вы проводите обследование процессов, перед реализацией.
Не понятно как вы решаете вопросы — типа сделал, нужно проверить бухгалтеру, и на этом ожидание… А проект висит.
Что вы будите делать, если руководство скажет — давайте уменьшим минимальную оплату, что бы Не скакал ФОТ.
Так же поясните, если у вас маленькая компания и как вы набираете столько задач, что бы увеличивать ЗП программистам.
Задач 100-150 в месяц.
Аналитики — мы сами.
Проекты, как сущность, мы тогда уже выкинули — был только поток.
Ожидание проверки было, до месяца — дальше сам закрывал, без проверки. Но, в целом, проблем не было, потому что не принимал от человека новую задачу, если он старую не проверил.
Если руководство скажет уменьшить ставку, то придется искать новых программистов.
А задач становилось все больше, т.к. мы делали их все быстрее.
Ну и, если честно, большинство тем по автоматизации я сам инициировал, поэтому задач было много.
В тексте перечислены «начальные» характеристики четырёх программистов:
- мог часами обсасывать подводные камни, набивая себе цену (непонятно, правда, зачем — оклад же).
- любил часами сидеть и «думать над оптимальным решением».
- интраверт, который… стеснялся поговорить с заказчиком.
- новичок, который раньше стеснялся задать коллегам вопрос.
Т.е. вы здесь номер 2?
Странными кажутся оценки задач, приведенные в статье — по 10-15 минут. Здесь речь больше про конфигурирование/администрирование, или всё-таки про разработку? Если про разработку, то как в такое в такое время влазит тестирование?
Понятно, что некоторые задачи содержали в себе несколько пунктов классификатора — например, регистр, плюс несколько реквизитов, плюс отчет, плюс автозадача. Время в этом случае суммировалось.
Вот не учтено время проверки взаимодействия всего этого (тестирование). По раздельности может всё и работает, а вместе?
Это ж внутренняя автоматизация, там тестирование лежит на плечах пользователей, зачем приличным людям на него время тратить особо.
И если была такая система мотивации которая всех устраивал, то зачем её поменяли на скрам и другие не понятные слова? или вы поменяли место работы и там эта система не взлетела?
И все приятные бонусы от этой системы это следствия учёта, а учёт метрик это по моему первое дело любого руководителя, научиться ходить па приборам, а не по субъективным оценкам
о оценка задачи в 15 минут, на аналитику 5 минут… про тестирование ни чего, про возврат на доработку не чего, про заказчик пердумал ни чего, про бодания на приёмо сдаточных испытаниях ни чего
во-во, так программисты и говорили поначалу. А потом поняли, что и 15 минут — много, если сопли не жевать.
Иное руководство с характерным прищуром и интонацией у вас бы спросило не много ли у вас людей в отделе. Если вместо работы вы можете себе позволить системы мотивации разрабатывать. :)
Ну и… если оклад отмерен 60тр. То с чего бы платить 100? Общее количество работы 1Сшников на предприятии то не меняется. А по вашей же статье — упало.
Хотя можно зачесть в «экономию» то что выявилось в «приятном бонусе». Вот это действительно результат.
Люди после 3-6 месяцев не потянулись на выход?
Как по мне, в таком режиме можно выполнять только простейшие, разжованнейшие задачи. Возьми там, положи туда, умножь и сложи. И то возможны конфликты типов данных, проблемы масштаба, скорости работы и т.п.
Где-то читал, что достижимый результат для программиста — работать 5 часов в день, час через час, большинство либо работает меньше, либо не то чтобы программирует. Программирование != только написание кода, большая часть работы — его обдумывание, в т.ч. неявное. Плюс оформление, тесты, приемка, доработка ТЗ, доставка до прода.
Потому что обычный программист «на окладе» нет-нет да и начнёт сравнивать себя с мужиком, который за 15-20 т.р. работает на заводе или ЖД, со школьным учителем с 12-часовым рабочим днём и т.д. И сравнение явно будет не в свою пользу (получает в разы больше, а работает в разы меньше, в более «тепличных» условиях).
Кто-то, боясь «разоблачения», начинает работать максимально втихую — мол, если не отсвечивать, то может, начальство не заметит и не уволит. Кто-то наоборот, начинает громко набивать себе цену, спуская на это кучу рабочего времени.
А с переменной ЗП необходимость в этом пропадает — всем сразу видно, за что и сколько платят, всё по-честному, а не по недосмотру.
Обычно у задачи есть ещё накладные расходы — переключение контекста, изучение связей и возможных влияний и зависимостей, тестирование. 15 минут на задачу — разве что для совсем элементарных случаев, где можно вообще не думать.
Я бы свалил подальше от таких оценок, удивительно, что программисты согласились так работать. Это вдвойне странно, учитывая, что оцениваются задачи по "идеальному программисту", а таковых в вашем коллективе нет, кроме вас)) то есть люди заранее соглашаются с недооценкой задачи, у них гарантировано уйдёт больше времени? При этом оценка в полтора-три раза ниже, чем у внешних оценщиков… Или все так стремились стать идеальными, или где-то подвох.
И еще:
«Вот одному программисту поставлена задача — сделать заполнение субконто Склад в проводке по счету 003 (в типовой УПП, почему-то, не заполняется). А он в переработку не знает, ни на стороне давальца, ни на стороне переработчика.
Вроде — сядь и разберись, чего такого-то, всегда так делали»
Стоп… Программисту поставлена конкретная задача «сделать заполнение субконто Склад». Зачем ему лезть в изучение схемы по переработке?
Или это тупое транслирование бездумной хотелки какого-то бухгалтера «хочу видеть субконто на 003 счете»? Тогда проблемы на фирме очень большие, и не в программистах и их мотивации, а в отсутствии на фирме грамотного постановщика задач, а вся дальнейшая суета — смысла не имеет, ибо задачи ставятся черт-те как.
Со стороны ЛПР использовалась корелляция оценки с учетом опыта — один занижал время, считая что сделает на раз-два, другой наоборот всегда брал резерв «на всякий случай». И уже на основании этого принималось решение — сколько каждая задача должна решатся. Это время и шло в зачет, вне зависимости от рельно затраченного.
Я сам с автоматизации начинал. Через пару лет автоматизировали даже автоматизацию, чтобы можно было сразу из ТЗ генерировать скелеты будущей системы и отчеты по ней.
А потом я ушел к игроделам. Это не программисты. Это алхимики\физики-ядерщики. Какие оценки проектов, если никто раньше не делал это?
«Ребята, вот новый телевизор из Кореи, его еще не выпустили на продажу, подпишите НДА. Там внутри вроде бы линукс. Надо разобраться и портировать на него вот эту игру. Скажите, сколько вам надо на это времени, но только нужно успеть до старта его продаж 25 декабря» — вот почти типичная постановка задачи.
Но главное — в нашу часовую ставку входила только непосредственная работа. В ней не было раздумий, моделирования, анализа решений и т.д.
Тяп-ляп и в продакшен. Кому захочется бесплатно обдумывать как сделать адекватный, масштабируемый проект, если ему платят непосредственно за написание кода. Сколько часов уйдет на сопровождение и развитие таких слабых решений неизвестно. Возможно поэтому
Задачи не могли кончиться
В погоне за лучшим