Pull to refresh

Comments 107

Первый закон Паркинсона: работа заполняет время, отпущенное на неё.

Работа это газ. Коты это жидкость.

Механизм заполнения котами любого пространства
image

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

Ключевой вопрос: влияло ли это на оценку проделанной работы с точки зрения исполнения должностных обязанностей и, следовательно, сохранение рабочего места и заработной платы? Если нет, то всё в порядке: успел, не успел - какая разница? Своя жизнь начинается после 17:00, вот там и надо думать, как бы успеть всякие крутые штуки, а работа никуда не убежит: не сделал сегодня - сделаю завтра, если дедлайн не горит, а если горит - можно отложить на постдедлайн всё, что к нему не относится: никаких претензий к сотруднику, а тем более менеджеру, который "извините, не может - срочное дело".

Если же постоянная "неуспеваемость" становится поводом для дисциплинарных мер, то нужно понять, почему так получается. Либо вы мало работаете и балду гоняете на рабочем месте, либо объём задач неадекватно высок и его надо пересмотреть.

Если я за рабочий день могу проанализировать десять задач, зачем анализировать одну?

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

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

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

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

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

Какая разница? Если есть время на работу, оно тратится на работу. Не бывает такого, что «мне тут мало платят, поэтому я работаю спустя рукава; а вот если мне будут платить много, то я сразу о-го-го!». Даже если будут платить много, то качество работы не изменится. Так уж устроен человек.
Странное желание измерять тёплое с помощью длинного — измеряется время собственной загрузки с помощью результативности и эффективности работы отдела.
Ну да ладно, фиг с ним. Чтобы сломать закон Паркинсона нужно ничего, абсолютно ничего не делать! Один раз всё делегирование автоматизировал и поехал домой с нормальными глазами.

PS. Для того, чтобы увеличить прирост эффективности и результативности работы отдела нужно пересмотреть все процессы внутри отдела, все входящие в отдел данные. Но только после того, как будет получен ответ на вопрос: Для чего повышать эффективность и результативность работы отдела более чем на 10%?
Тоже так подумал. Человек натурально стал менеджером. Заниматься только бы организацией и масштабированием, налаживанием процессов и их контролем. Вот тогда у фирмы есть шанс расти. А так получилось, что процессы настроены так, что происходит перераспределение работы внутри фирмы, но на качественном уровне она остаётся на том же уровне.
Получается устойчивый рост эффективности и результативности примерно на 10% в месяц.

Ээээ… прирост эффективности 10% в месяц? То есть, где-то через полгода каждый сотрудник работает вдвое эффективнее?
Рост не равномерный у сотрудников — кто-то больше, кто-то меньше. Результат в целом по группе.

Очень подозрительный стабильный рост: такими темпами скоро достигните сингулярность

А может, плато давно настало и ваши 10% это видимый результат усилий, а не «оно само»? То есть, без выполнения действий, которые якобы не дали результата, не было бы всех тех 10%
Экспонента в сингулярность не уходит, слишком медленная. Но закрыть своим отделом все мировые потребности в 1С — тоже неплохой результат. Дальше можно и на межпланетный уровень выходить.
Экспонента в сингулярность не уходит, слишком медленная. Но закрыть своим отделом все мировые потребности в 1С — тоже неплохой результат. Дальше можно и на межпланетный уровень выходить.

То есть результативность не только не падает, но ещё и растёт, притом весьма резвыми темпами? Так какие тогда проблемы?

Если работа предусматривает завершение объективных задач (например, к такому-то числу разработать программу), либо выполнение нормы (например, 100 стандартных процедур в неделю), то её результативность определяется столь же объективно: есть результат/нет результата. Если результата нет - надо либо лучше работать, либо оценить адекватность объёма задач. Если результат есть - всё, 100% выполнено, можно либо идти домой, либо перевыполнять план и получать бонусы, тут никаких проблем с результативностью и эффективностью нет. Выполнил план - посылай всех и т. д.

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

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

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

UFO just landed and posted this here
Хм, но число тасок на клиента — метрика работы тех отдела, а не поддержки. Поддержка работу начинает, когда проблема уже есть и её надо решить максимально быстро и эффективно.
UFO just landed and posted this here
В общем, это всё ещё больше показывает, что очень сложно найти метрику оценки работы именно для техподдержки, а не всей компании в целом (там проще: число клиентов, срений чек, прибыль и т.д.) :)
UFO just landed and posted this here

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

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

Вот я тоже сразу подумал — «не может солдат два мешка брюквы в день съесть» (с)
– Мы разработали снаряд, который пробивает броневой лист толщиной в метр!
– Это уже вчерашний день, наши экспериментальные образцы пробивают броню толщиной до 135 сантиметров.
– А зато наши снайперы попадают в копейку за километр!
– Не хочу Вас огорчить, но последние модели наших снайперских прицелов позволяют уверенно попадать в пятицентовик за 1200 метров.
– А у нас, у нас… зато у нас солдат получает в день 2300 килокалорий, вот!
– Вообще-то стандартный рацион солдата НАТО гарантирует 4700 килокалорий в день.
– Врёшь, сволочь натовская! Не может ваш солдат сожрать за день два мешка брюквы!!!
Но результат никак не изменился – те же 10%


Вы создали систему, которая может функционировать без Вас. Скорее всего, в команде есть люди, которые при удобном случае могли бы Вас заменить. Возможно, Вы создали некоторую иллюзию, в которой Вы — Мастер, а все остальные — юнлинги.
Как мне кажется, вместо того, что бы упрочнять своё положение, Вы занимаетесь игрушками.
Как мне кажется, вместо того, что бы упрочнять своё положение, Вы занимаетесь игрушками.

Зачем что-то упрочнять? Если менеджер смог создать систему, которая работает на автопилоте, то он прекрасный менеджер, для которого всегда найдётся работа. Это сродни иррациональному страху некоторых системных администраторов, думающих «а вот я сейчас всё вусмерть заавтоматизирую, стану не нужен, и меня уволят!!111».
Вообще тот самый закон был шуткой. ;) Воспринимать его слишком в серьез не стоит.

Опять же прирост эффективности в ПРОЦЕНТАХ — это сложный процент, или экспонента. Если у вас реальный рост 10% в месяц — это… Ну вы же понимаете, да? К концу года производительность отдела вырастет более чем в ТРИ раза! Что бы поддерживать такой РОСТ на постоянном уровне надо очень круто вкалывать.

Т.е. вы типа перераспределили нагрузку, но все равно закрывали достаточно много — это вовсе не обязательно значит, что «от вас ничего не зависит»… )
Вообще тот самый закон был шуткой. ;) Воспринимать его слишком в серьез не стоит.

Не шуткой, хоть и первый раз появился в сатирической статье о английской бюрократии (но крупного экономического издания). Потом историк Па́ркинсон сформулировал еще несколько законов и выпустил изрядное количество книг про них.
два показателя – эффективность и результативность. Эффективность – это производимый результат на одного человека (т.е. показатель, не зависящий от количества людей в группе). Результативность – это общий показатель, который получается умножением эффективности на количество человек

Эффективность = Результат / количество_сотрудников
Результативность = Эффективность * количество_сотрудников
Результативность = Результат? Или я чего-то не так понимаю?
Почему автор решил, что можно повысить эффективность и результативность, тупо перекладывая свои дела на плечи сотрудников? По мне так процент роста вполне мог стать и ниже при таком раскладе, но никак не выше… Ведь сотрудники теперь нагружены больше, чем раньше, причём, именно тем, чем раньше занимался их начальник, то есть, автор…

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

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

Успех — это не процентуальное колебание (запросто и рост) эффективности отдельного человека (хоть и менеджера), но каждого отдельно и вместе взятых одновременно. Если удалось (я так понял, на короткое время) добавить всем работы, и всё было хорошо, то будет ли хорошо через год? Работники устанут, выгорят, уйдут, им нужно искать замену, чекать как у них с work-home балансом.
звучит так: я самоустранился от всех задач, но они меня находили.
логично — задачи-то никуда не делись. только решать их, видимо, приходилось реактивно, а не проактивно (что по умолчанию стоит бОльших усилий).
Кстати, динамика роста производительности в 10% — это совсем неплохо! Если бы еще и ЗП также пропорционально росло, так вообще супер результат!)

Вы описали свою уменьшающуюся вовлечённость в дела организации.

Вопрос: не может ли быть так, что организация, сами люди, скорректировали свою деятельность, чтобы компенсировать ваше исчезновение?

Вопрос 2: не может ли быть так, что вы изначально переоценивали свою значимость, и 10 процентов роста там уже были организованы владельцами проекта?

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

Если сисадмин спит, значит хороший. С управленцем тоже работает. Только у автора трудоголизм.
Для полноты эксперимента нужно еще замерить темпы роста совсем без участия автора в деятельности отдела. Как говорится замерить статистическую ошибку выжившего. Вдруг без его участия отдел станет эффективней.
>почему динамика роста в 10% не менялась в ходе эксперимента?
Потому что результат не от Вас зависит, Вы ж сами сказали, что KPI это результативность либо человека одного, либо всего отдела. А то что вы туда-сюда перекидываете функции/обязанности не особо влияет
Другими словами, вы открыли для себя, что любой человек может уйти в отпуск (то ли физически уехав на месяц, то ли на то же время начав работать в одну десятую прежнего в своих исканиях), а организация от этого не умирает, и в целом все идет как прежде (ну, может, чуть напряжнее тем, на кого та работа свалилась дополнительно).

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

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

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

Сравните когда вы собираетесь в дорогу спокойно или опаздываете. Все равно соберетесь к определенному времени, когда бы не начали сборы. Поэтому некоторые всегда опаздывают :-)

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

Это возможно следствие закона энтропии :-)
Количество суеты с увеличением скорости растет.

Вижу две ошибки:
1. Нет уменьшения отведенного времени на задачи при уменьшении количества задач. В реалиях N-часового дня не сработает.
2. Нет заполнения освободившегося времени. Для чего оно освобождалось?
3. Со временем связано планирование. Его совсем нет.

Для снижения перегрузки — нужно научится вовремя останавливаться. Вышло отведенное время на задачу, стоп. Переключаемся. Что-то типа спринта :-)

Все отведенное время человек пытается заполнить деятельностью и это нормально.

Если не хватает сил, то это не вопрос эффективности и времени…
Эмм… Тимлид скинул с себя задачи почти все, подчиненным сказал веслать упорнее, и вместо того чтоб в высвободившееся время пить смузи на терассе (лето все-таки),
стал закапываться в другие задачи. А зная что замена тимлида это супердорого внаглую написал еще и на хабр ))
и вместо того чтоб в высвободившееся время пить смузи на терассе (лето все-таки),

Развивается то что тренируется.
Ну и будет он потом экспертом по смакованию смузи, эта цель, это его мечта?
Топикстартеру важнее было не сбрасывать баласт не нужных (как ему кажется) обязанностей, а развивать (уделять больше время), что повышает его эффективность как руководителя или специалиста.
«На чем фокус, то и развивается» вот что продемонстрировал автор.
Стал экспертом по сбрасыванию с себя дел )))
У него изначально не ясные цели.
Если 1 цель «ясная голова и быть бурляще-энергичным в конце рабочего дня» то нужен один перечень действий.
Если 2 цель «пошли все на.., дайте мне почитать хабр и поиграть/почитать в рабочее время» то другой перечень действий.
А если 3 цель «Повысить эффективность отдела на n%» то третий перечень действий.
И ведь понятно, что 1 цель это внутреннее самочувствие, а 3-я результативность и автор хочет 1-ю цель, но пытается решить методами 3-й цели.
А потом недоумевает, почему он все еще выжатый лимон в конце рабочего дня, хотя все дела раскидал )))

Типичная для автора графомания.
Зачем вообще он публикует свои художественные тексты на Хабре — загадка. Есть же proza.ru.

Бывший geektimes. Может, для таких статей и не стоило объединять...

Хоть автор и называет себя программистом, но если посмотреть статьи автора, хотя бы список двух последних страниц (их там так много...), то они не содержат технических статей. В основном социологические, психологические, про то как думают программисты, и как им нужно думать. А человек если пишет, то конечно про то, что у него в голове. Слог у него несколько приторный, но ему вероятно не с кем поговорить о своих мыслях. Т.к. он все ближе к кадровикам, а находится среди программистов.
Не судите об авторе по тому, о чём он пишет. Я не пишу технические статьи, потому что сам их не читаю. Ибо искренне считаю, что приличный программист всегда, во всём, хочет разобраться сам. Если один программист пишет другому техническую статью, то считает его идиотом.

TIL: авторы хабра считают читателей идиотами

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

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

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

Нужно читать статьи по технике, чтобы развиваться. Например, откуда узнаешь про AOP, если все задачи решаеются и без него (но с большим количеством копипасты). Этакое закукливание в «отстаньте со своими растами и хаскелами, я и так могу решить любую задачу на языке 1с, а больше мне и не надо».

Да, наверное, вы правы.

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

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

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

С ребенками я много разговариваю, т.к. у меня своя школа программистов. Там я и статьи технические пишу, и видео снимаю, и т.п. Но там именно ребёнки, их идиотами считать странно.

А тут же хабр. Тут ребенков нет.

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

Могут ли такие интересующие сами в этом разобраться? Вероятно могут. Будет ли это быстрее, чем если им это кто-то будет объяснять? Зависит от объясняющего во многих криетриях, в том числе от того, какой смысл вкладывает объясняющий в свои объяснения.
И как Вам заметили на мероприятии в Челябинске (14:15), порой даже взрослым нравятся простые объяснения в картинках и схемах. Идиотами они от этого не становятся.
>Тут ребенков нет.

А вот и есть.

Ну как по мне, то проблема как раз в претензии на техничность. То есть если бы всё описанное в статье происходило в реальности, а не в воображении автора, то это была бы прекрасная статья на Хабр. А получилась как обычно — графомания. Потому что даже самих законов автор не понял, поскольку они относятся к очень специфической области человеческой деятельности — государственному управлению (В которой сэр Сирил и проработал всю жизнь). А в бизнесе начинают работать в компаниях с количеством сотрудников 100+, а в полную силу входят уже только в больших корпорациях.

Что за «претензия на техничность»?
поскольку они относятся к очень специфической области человеческой деятельности

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

Эксперименты ставить и смотреть на реальные результаты — одно. "Экстраполировать" мысленно — совсем другое. Выдавать второе за первое — третье.

Писать комментарии - четвёртое.

А жить и отдыхать то когда? Вся эффективность труда уходит в ноль и на задачи не остается заряда, если нет ресурсного состояния и энергии.
Почитала вашу статью про возрождения Феникс птички и смысл понятен — цели, возможности, удовольствие от самого процесса и в конечном итоге желаемый результат, поймав 2-х или даже 3-х зайцев)) Достигнуть своей цели, получить результат в работе и конечно внутренний рост, кайф от проделанного, это и есть заниматься любимым делом.
Только не соглашусь в одном, что если кантора в которой работаешь не нравиться, то как-то заставить себя увидеть некие возможности и использовать их во благо — это уже все же про ломание себя, а значит и про благо нету речи, по крайне мере для своего внутреннего состояния…
Кмк, искать контору, которая понравится — как солнце догонять. Может, когда-нибудь, повезёт. А может и нет. Надёжнее научиться, как кошка, всегда на ноги вставать — находить в любой среде что-то интересное для себя.

Быть может, в KPI закрался показатель "месячный прирост эффективности = 10%"? И сотрудники нашли простой способ выдавать ту цифру, которую нужно.

UFO just landed and posted this here
А почему стабильные 10%? Почему не 9% или 15%?
Как измеряли?
Функция ПовышениеЭффективности(Количество_месяцев)
    Возврат 10 * Количество_месяцев;
КонецФункции
ну, так я тоже могу ;)
Нужно быть недалеким, чтобы уволить человека который может целенаправленно проворачивать такие трансформации, и доводить их до логического завершения, просто потому что «ему так захотелось». Такие вовлеченные и деятельные люди на дороге не валяются. Представляете, что будет, если ему поставить правильную производственную задачу*?

*) — При условии, что изложенная ситуация тут не приукрашена чуть более чем на половину

так это же всё происходит во вселенной 1С наверняка.

Да, в статье так и написано.

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

смотрите, Иван.

Реуепт прост. Вы пытаетесь влиять эффективность и результативность косвенными методами.

А надо - прямыми.

Делать только то, что прямо влияет на ващи циферки, хоть бы и ыормулу менять.(кстати, а сеолько процентов хотите?)

Прямыми можно только когда у тебя 2-5 человек. А у меня их 13. Поэтому только косвенно.

да ну как нельзя.

напишите в этом месяце 15% и посмотрите, кто проверит то

ну там где вы считаете эту эффективность

Неважно, как проголосовали поработали, — важно, как подсчитали?

Там приход денег от клиентов. Как туда написать?

Значит, вы либо продажник, либо приписываете себе рост эффективности продажников.

Продажники в процессе почти не участвуют, только акты выставляют. Это рынок 1С, тут продавать не нужно, только делать успевай.

То есть можно почти бесконечно масштабироваться, нанимая программистов?

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

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

Суммарная прибыль - это эффективность умножить на количество человек. Важны оба ингредиента.

Если немного подумать, может быть автор грамотно перераспределяет обязанности (хотя это под вопросом), но при этом его эффективность снижается. Например, автоматизировал какой-то процесс, который занимал Х времени, а стал занимать Х / 2 времени, при этом высвободившиеся время стал тратить больше на те же задачи (раньше решал вопросы за условно 5 мин, а стал за 10). Аналогично при обучении. Отдал решение каких-то вопросов сотрудникам, которые стали тратить на это меньше времени, чем сам автор, но сам автор в высвободившиеся замедлил свои задачи. Таким образом, с точки зрения руководства, все правильно сделал (если не перегрузил сотрудников). И то, что стал тратить время на те же вопросы больше времени, это не плохо потому, что общая результативность не пострадала. Если вместо того, чтобы тратить больше времени на те же задачи — решать новые задачи, то общая результативность вырастит, или если всех все устраивает можно оставить как есть.
По тексту создалось впечатление, что вы замкнулись на себе. Из-за чего, возможно, не видите причин низкой работоспособности и усталости.
Первое: хроническая усталость — это болезнь. И ее надо лечить. Это следить за питанием, сном, принимать бады, добавить физической активности.
Второе: как вы измеряете объем проделанной работы? Какой-то есть такс-менеджер? Вот вы сделали сегодня 2 задачи, завтра 5. В среднем за месяц выполняете 60. Но в этом месяце выполнили только 30. При отклонениях начинаете анализировать, на каком типе задач у вас произошла задержка и почему. Понятное дело, когда задача долгосрочная, или многоуровневая, тогда нужно ввести планирование (под)проекта в целом. Сюда же и управлением персоналом относится.
И последнее: поймите правильно — вы либо менеджер, либо программист. Да, я в курсе, что чаще всего программисты становятся начальниками, продолжая при этом программировать, а не управлять. В итоге это выливается в хаос, недопонимание и прочее. То есть должно быть разумное распределение задач.
Не, усталости у меня нет. Только ощущение, что я не всё успел сделать.
Вообще, я решил с ним смириться.
«Работу свою оцениваю по результатам моей группы, там два показателя – эффективность и результативность. Эффективность – это производимый результат на одного человека (т.е. показатель, не зависящий от количества людей в группе). Результативность – это общий показатель, который получается умножением эффективности на количество человек (т.е. показатель масштабирования эффективности).»
вот больная тема лично для меня, раньше требовало руководство сейчас дорос сам, что нужно как-то измерять эффективность. и никак не могу придумать как же измерять эффективность разработчика, аналитика? тут человек пишет об этом, как о чем-то элементарном, но как всегда без конкретики. вот как вы измеряете эффективность? в чем?
прошу пошлятину про количество строк кода или количество реализованных задач не упоминать )
https://habr.com/ru/post/343910/
У нас с эффективностью просто, т.к. все работы клиент оплачивает, по часам. Поэтому всё в деньгах измеряется.
кто определяет количество требуемых часов на ту или иную задачу? из моей практики это в 99.9% случаев — исполнитель, а значит эффективность в этой модели регулируется лояльностью заказчика, но не объективными показателями )… с баллами из «скрама» та же история, по сути.
Количество часов — предмет договорённости клиента с исполнителем, или менеджером, или начальником. Часть работ (типовые) по стандартной цене. Часть — по факту.
UFO just landed and posted this here
UFO just landed and posted this here
Хорошая статья. Вывод вот только другой для себя сделал.
Что это пример хорошего лидерства, когда нужно, наоборот, идти на повышение.
ИМХО, оказался не нужен именно функционал начальника. Все со всем сами справятся.
Начал читать статью — подумал, о, кто ж это про меня то пишет :)

Только я директор во франче 1С.

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

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

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

С ключевыми клиентами общаюсь (примерно раз в месяц). В основном, там где нужны знания из разных отраслей: УТ, БП, РТ, свой сайт, торговые площадки.

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

Сотрудников учу сам.
Программисты. Вижу старые кода тех кого учил раньше, и тех кого не учил. Когда у клиента изменилась задача у первых доработка это «подправили две строки кода», у вторых «проще, @#$, с нуля все это переписать».
Консультанты. Одни клиенты — «мы вам в почту прислали ТЗ, пришлите нам счет пожалуйста». Вторые — «раньше ваш сотрудник нам все делал, поэтому разбирайтесь, быстро, почему у нас тут отрицательные остатки». Где обученные а где необученные думаю поймете сами :)

Помощь.
Да. Выглядит примерно так — «вот здесь почитай хорошая статья по этой теме» или «здесь посмотри делали аналогичную задачу». Есть правило «3-х часов» — если не получилось за три часа, спроси, вдруг это ошибка платформы и эта задача в принципе так не решается.

Программирование.
Если изучаем новую отрасль, например привязать электронные деньги к типовой 1С, или новое оборудование в мобильной рознице — однозначно сам погружаюсь, вникаю, читаю теорию, читаю википедию (чтобы понять, например, чем отличаются веб сокеты от вин сокетов), и даже сам пишу кода. Потому что надо быть в «тренде» и потому что банально не получается держать в штате программиста 5 лет, чтобы у него был методический опыт в нашей сфере (автоматизация розничной торговли).
Текущие задачи, руки конечно чешутся когда попадается что то необычное, но сдерживаюсь.
Задачи которые могу сделать «только я» — или не беру, или беру если есть уже сделанное на 80 % аналогичное решение.

Так чем же я занят, и какие выводы.

Изучаю новые темы.
Причем основательно, с анализом рынка, с анализом доходности. Если, например, мы понимаем что кто то из франчей написал хороший модуль ЗУП для БП (а мы такой не напишем в приемлемые деньги и сроки), то мы покупаем модуль у этого франча и продаем.

Если мы знаем что Программная касса — это ближайшее будущее, то мы разбираемся как работает java + 1С, потому что программная касса написана на java. И т.к. это наша тема, то мы пишем связку 1С с Программной кассой.

Новые ключевые клиенты.
Когда приходит сеть на 15, 20, 100 магазинов я лично погружаюсь в его специфику продаж, читаю методические решения по такому типу товара. Чтобы потом запуск магазинов происходил уже без моего участия, и чтобы на 30 магазине мы вдруг не поняли, что мы что то важное забыли :)

Сотрудники, сотрудники и еще раз сотрудники. Обучаю их так, как будто бы они всю жизнь будут работать рядом со мной :)

Результат = Истина;

Наш основной финансовый показатель — это количество заработанных денег на одного сотрудника (уже конечный результат, после выплаты, налогов, ЗП, прочих затрат и т.д.). Вот он растет в 1.5 — 2 раза в год.

И самое главное — мои дети сейчас говорят «ай, ты все время на работе», уже только из вредности, потому что на вопрос «а когда я последний раз был поздно на работе», они как правило уже и не могут ничего сказать :)

Первый закон Паркинсона: работа заполняет время, отпущенное на неё.

Вот и отпускайте на работу не 8 часов, а 4.

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

Такие комментарии сами по себе справедливы, но никак не связаны с законом Паркинсона, который, со слов самого Паркинсона, подразумевает неизменное качество работы. Иначе ничего интересного в его законе не было бы))

Вот по Паркинсону:
Если есть время на работу, оно тратится на работу.
Сотрудники, по мере увеличения количества сгружаемых им задач,… делают задачи за 3 мин, вместо двух часов.
Вот и отпускайте на работу не 8 часов, а 4.

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

Возможно, автору статьи будет интересно провести еще один эксперимент — теперь увеличив количество выполняемых работ. Возможно, войдя в цейтнот, удастся найти что-то воистину выдающееся. И тогда «ощущения, что везде не успеваю и надо что-то менять» исчезнут просто уже из-за осознания новизны. Во всяком случае, за это не уволят)
Sign up to leave a comment.