Поддержать меня на Бусти и получить доступ к доп контенту: boosty.to/mflenov Обо мне: www.flenov.ru Мой ИТ блог www.flenov.info Телеграм: t.me/mflenov X: x.com/flenov
Самое демотивирующий случай за последние годы примерно такой: на неделе несколько дней сидел полночи дебажил, шлифовал код, чтобы задачу закрыть. А потом на дейлике: "Мы что-то буксуем, надо ускоряться". Зато с радостью помню, хоть и давно было, в другой компании, когда закончил очередную задачу примерно за час до конца рабочего дня и попросил следующую, мне сказали: "Молодец, иди домой, и так хорошо поработал сегодня!"
6:08 Особенно когда говорят: "Ты накосячил", но при этом ещё десять человек проверяло эту прошивку (я программист-железячник, пишу под микропроцессоры), пять сотрудников ОТК, три представителя заказчика (я работаю на военном предприятии), а потом два года успешной эксплуатации… а потом выясняется, что проблема не в моём коде, а в коде аппаратуры, с которой я сопрягаюсь, там обновили прошивку, меня не предупредили, а протоколы взаимодействия поломались (особенно круто, когда протоколы секретные, формы допуска у меня нет и я даже узнать, как НАДО работать не могу). А осадочек то остался!
Для меня самой уничтожающей мотивацией было то, что оказывается менеджеры получали какие то премии за сделанную нами работу, а мы про такие премии узнали только спустя 2 года. На наш вопрос, почему нам не делают таких премий как менеджерам, ответили просто "Он ведь отвечает за вашу работу, а вы ее только выполняете". Да, это прям какая то контора......
У менеджеров действительно иногда делают премии, которые могут составлять большую часть зарплаты. Я бы лучше без премий, потому что зарплату дадут всегда, а менеджеровскую премию отменяют за косяки. Потерять премию из-за ошибок программистов не очень приятно. Так что лучше просто зарплата. Когда у нас в компании отменили премии я был рад, так спокойнее и лучше
В предыдущей компании решили цели KPI наследовать от вышестоящего руководства. Процент выполнения KPI влиял на годовую премию (до 30% от годового дохода). В результате, у разработчиков (и других специалистов) были цели, на которые практически невозможно было повлиять, например: "Повышение уровня удовлетворенности пользователей на X%" или "Увеличение прибыли на Х% за счет привлечения внешних клиентов". Такие цели сильно убивают мотивацию.
за двадцатилетнюю карьеру повезло ни разу не столкнуться с неадекватным манагером. единственное, что однажды меня демотивировало - это переезд в опэнспэйс. для меня это очень стрессово. хорошо, что продлилось это пару месяцев, и нас с командой вернули в собвтенное помещение.
Это просто отвратительно, когда к тебе каждый может заглянуть. Невозможно сосредоточиться. Специально ухожу поработать куда-то за отгороженное стойкой оборудования рабочее место, чтобы никого не видеть, не слышать и просто работать. Да ещё там камера экранированная, то есть телефон никакой не ловит, благодать.
У нас тоже есть анонимные опросы, но честно говоря, писать туда реальную ситуацию вообще нет желания. И взаимоотношения на работе уровня - "друзья", как по мне, делают только хуже.
Как по мне, самые убивающие вещи: 1. Оценка и озвучивание заказчику (фиксация в договоре) сроков выполнения работы без оценки объема непосредственным исполнителем. М: - Сколько тебе нужно времени на проект? Р: - X месяцев М: - Хорошо, у нас есть X-N месяцев. 2. Делание исполнителя "единственным и не заменимым". Исполнитель не должен ощущать на себе гнет, что если вдруг возникает безотлагательная необходимость отсутствия на рабочем месте (сам заболел, ребенок заболел, трубу прорвало, в гос контору надо и т.д.), то его потраченное на это время обернется провалом сроков, потому что никто не может посередине подхватить его задачу. Типа: "Это твой проект, ты его и тащи. Умри, но сделай. Твои личные проблемы до фонаря." 3. Требование от исполнителя сроков реализации, при не выполнении собственных обязательств по предоставлению данных. Исполнитель оценивает, что ему надо X месяцев со дня предоставления исходных данных (от смежников, например). Менеджер "утверждает", что ИД дадут в дату Y и ставит с этим учетом срок реализации. Но когда сам менеджер потом затягивает (по разным причинам) с выдачей ИД исполнителю на N дней (недель, месяцев), требует реализацию в фиксированную им дату за меньший срок X-N. А если исполнитель, все же не успел, что ожидаемо в таком случае, то менеджер со всей легкостью вешает косяк по срокам на исполнителя, несмотря на то, что накосячил сам, или затянули смежники. 4. (IT-программистов это, скорее всего, в меньшей степени касается). При работе связанной с выездами для запуска "большого" объекта, нагрузку планируют без учета смены инженеров на месте. В общем делают так, что инженер живет на объекте месяцами, не видя семьи.
"без оценки объема непосредственным исполнителем" а как же вариант: - Сколько времени займёт работа А? - 1 месяц - Сколько времени займёт работа Б - Два месяца - Так почему так долго? Работа же А занимала 1 месяц! - Так потому что у меня работа А ещё не закончена, когда закончу - тогда и перейду к работе Б - Нет, надо СРОЧНО отложить работу А и сделать работу Б! - Ок, надо так надо. - Сколько времени уйдёт на работу Б! - Пять недель. - Ок, работай ----------------- проходит месяц --------- - Почему работа А не выполнена? - Так я же занимался работой Б! - Ты же сам сказал, что на выполнение работы А уйдёт месяц месяц назад! - Так вы же сами сказали, что надо переключиться на работу Б! - Да пофигу, что я тогда сказал! Надо обе работы сделать за месяц! Мы уже на полгода сроки сорвали!
Демотивирует, когда менеджер плохо делает свою работу (не помогает с организацией процесса, коммуникацией, требованиями и т.д.), а виноватым в случае провала по срокам будешь ты как исполнитель. У меня был менеджер, который похоже ожидал, что я буду делать всю его работу (по моему проекту), хорошо хоть его быстро уволили и заменили другим, повезло😅 Или когда спускают сверху жесткие сроки без учета реальной оценки, как уже писали тут.
принцип "за хорошую работу - ничего, а за что-то плохо сделанное (без разбора причин почему так вышло) - давать кнутом" это всегда для большинства людей приводит к падению мотивации ниже плинтуса
У нас например было такое что ты сделал большую систему, причем постарался, и с конечными пользователями даже поработал хорошо, а менеджеру не понравился интерфейс (причем он там был такой не просто так, а потому что подводных камней много), и вот менеджер не погружаясь в детали задачи просто взял и назвал все говном.. ну прям обрубает желание стараться
Уничтожают производительность. Менеджер внезапно заносит в спринт критические задачи. Говорит брось задачу high, скорей задачу критикал. Этим же вечером пишет бросай критикал, хватай другой критикал. И так от спринта к спринту. А в команде всего двое.
Самые демотвирующие вещи: 1. Микроконтроль, контролируют каждый шаг 2. Никакие решения невозможно внедрить, обсудим потом, назначим встречу о встрече, на который решим, что можно сделать и так по кругу. 3. Атмосфера порицания, Вася сделал говно, Вы видели, что он написал ? Это портит атмосферу в команде 4. Ошибка найма, когда сам попал или взял человека не по скилу, в итоге сеньор делает простые задачи по 2 недели. Все эти вещи дико демотивируют либо всю команду, либо конкретного участника.
к сожалению также столкнулся с таким товарищем. каждый дейли - как на допросе в прокуратуре. плюсом у него была фишечка - вымещение своих детских комплексов на подчинённых. Я по полчаса на подготовку и восстановление добавлял ко встречам с ним.
Порой менеджеры просто не понимают важности мелочей в подходах, которые они же самии выбрали. Например, зачем создавать Story, если там быстрый фикс на 1 story point, это можно и без задачи сделать. Зачем расписывать подробное описание и Acceptance критерии, если можно их накидать побыстрому. Зачем оценивать задачи вообще. Зачем создавать тикет для QA, если программист и сам может запустить и проверить, что он написал. Не думаю, что такое встречается часто и скорее встречается среди низкоквалифицированных менеджеров, но работа сильно усложняется, когда разработчики сами должны следить за соблюдением процессов.
А как у вас насчёт спринтов и дэдлайнов? На прошлой работе никто не парился если переносилась задача на следующий спринт, на текущей менеджер за**ет чтобы все было закончено под конец этого спринта и каждый раз пытается впихнуть всё больше и больше. Если честно напрягает жутко. И фичи мы никакие новые не деливерим каждый спринт. Проекты у нас распланированы и должны быть закончены целиком... индийский менеджер. Еще напрягает, что очень часто даже нет времени на то, чтобы нормально разобраться в задаче потому, что надо быстрее быстрее и менеджер подгоняет. И я не пойму это я дурак и не могу просто делать то, что надо или менеджер не очень и есть смысл попробовать в другую команду прыгнуть.
имхо - это у вас какая-то индийская шудра. они действительно выслуживаются тем, что формальные признаки сюблюдают. индийские погонщики хороши только для индусов. но люди из индусов получаются только в неиндусских командах. и то по моим наблюдениям 1 из 20-30 был у меня случай, когда на галере были погонщики индусские, которые уже в штатах жили и контора продавила нанимать индусский аутстаф. и там был какой-то головняк в индии с виртуальными машинами: они код писали на виртуалках, потому что иначе они в мир выйти не могли. и 2 индуса один за другим за полгода не смогли настроить себе доступ к нашему коду и системе для коммитов))) ни строчки кода закоммиченого - и платили им зп. и VP-шки индусские рассказывали всем, что у нас же контракт, мы должны свои обязательства перед индусской галерой выполнять... треш
Не посмотрел. Сразу. Да это полный П... ЕЦ ( простите) . пишешь пишешь. А потом говорят, ой мы тут кое-что забыли..... Или хочу вот а как не волнует. Простите наболело
Поддержать меня на Бусти и получить доступ к доп контенту: boosty.to/mflenov
Обо мне: www.flenov.ru
Мой ИТ блог www.flenov.info
Телеграм: t.me/mflenov
X: x.com/flenov
Спасибо, что показали, как можно с пользой использовать Clean Code!
Самое демотивирующий случай за последние годы примерно такой: на неделе несколько дней сидел полночи дебажил, шлифовал код, чтобы задачу закрыть. А потом на дейлике: "Мы что-то буксуем, надо ускоряться".
Зато с радостью помню, хоть и давно было, в другой компании, когда закончил очередную задачу примерно за час до конца рабочего дня и попросил следующую, мне сказали: "Молодец, иди домой, и так хорошо поработал сегодня!"
Такое бывает да?
@@umnikya7874 , бывает.
Хорошая подставка для микрофона:)
Хороший подход "хорошее при всех, плохое один на один".
6:08 Особенно когда говорят: "Ты накосячил", но при этом ещё десять человек проверяло эту прошивку (я программист-железячник, пишу под микропроцессоры), пять сотрудников ОТК, три представителя заказчика (я работаю на военном предприятии), а потом два года успешной эксплуатации… а потом выясняется, что проблема не в моём коде, а в коде аппаратуры, с которой я сопрягаюсь, там обновили прошивку, меня не предупредили, а протоколы взаимодействия поломались (особенно круто, когда протоколы секретные, формы допуска у меня нет и я даже узнать, как НАДО работать не могу). А осадочек то остался!
Для меня самой уничтожающей мотивацией было то, что оказывается менеджеры получали какие то премии за сделанную нами работу, а мы про такие премии узнали только спустя 2 года. На наш вопрос, почему нам не делают таких премий как менеджерам, ответили просто "Он ведь отвечает за вашу работу, а вы ее только выполняете". Да, это прям какая то контора......
У менеджеров действительно иногда делают премии, которые могут составлять большую часть зарплаты. Я бы лучше без премий, потому что зарплату дадут всегда, а менеджеровскую премию отменяют за косяки. Потерять премию из-за ошибок программистов не очень приятно. Так что лучше просто зарплата. Когда у нас в компании отменили премии я был рад, так спокойнее и лучше
В предыдущей компании решили цели KPI наследовать от вышестоящего руководства. Процент выполнения KPI влиял на годовую премию (до 30% от годового дохода). В результате, у разработчиков (и других специалистов) были цели, на которые практически невозможно было повлиять, например: "Повышение уровня удовлетворенности пользователей на X%" или "Увеличение прибыли на Х% за счет привлечения внешних клиентов". Такие цели сильно убивают мотивацию.
Обожаю Ваши програмысли ❤
за двадцатилетнюю карьеру повезло ни разу не столкнуться с неадекватным манагером. единственное, что однажды меня демотивировало - это переезд в опэнспэйс. для меня это очень стрессово. хорошо, что продлилось это пару месяцев, и нас с командой вернули в собвтенное помещение.
Это просто отвратительно, когда к тебе каждый может заглянуть. Невозможно сосредоточиться. Специально ухожу поработать куда-то за отгороженное стойкой оборудования рабочее место, чтобы никого не видеть, не слышать и просто работать. Да ещё там камера экранированная, то есть телефон никакой не ловит, благодать.
У нас тоже есть анонимные опросы, но честно говоря, писать туда реальную ситуацию вообще нет желания. И взаимоотношения на работе уровня - "друзья", как по мне, делают только хуже.
Так если не будешь писать, то ничего не изменится
@@programisli Как по мне, лучше лично написать
@@cppai Хорошая практика
@@programisliпроблема в том, что если описать реальную ситуацию, то это уже не анонимно
Как по мне, самые убивающие вещи:
1. Оценка и озвучивание заказчику (фиксация в договоре) сроков выполнения работы без оценки объема непосредственным исполнителем.
М: - Сколько тебе нужно времени на проект?
Р: - X месяцев
М: - Хорошо, у нас есть X-N месяцев.
2. Делание исполнителя "единственным и не заменимым". Исполнитель не должен ощущать на себе гнет, что если вдруг возникает безотлагательная необходимость отсутствия на рабочем месте (сам заболел, ребенок заболел, трубу прорвало, в гос контору надо и т.д.), то его потраченное на это время обернется провалом сроков, потому что никто не может посередине подхватить его задачу. Типа: "Это твой проект, ты его и тащи. Умри, но сделай. Твои личные проблемы до фонаря."
3. Требование от исполнителя сроков реализации, при не выполнении собственных обязательств по предоставлению данных.
Исполнитель оценивает, что ему надо X месяцев со дня предоставления исходных данных (от смежников, например). Менеджер "утверждает", что ИД дадут в дату Y и ставит с этим учетом срок реализации. Но когда сам менеджер потом затягивает (по разным причинам) с выдачей ИД исполнителю на N дней (недель, месяцев), требует реализацию в фиксированную им дату за меньший срок X-N. А если исполнитель, все же не успел, что ожидаемо в таком случае, то менеджер со всей легкостью вешает косяк по срокам на исполнителя, несмотря на то, что накосячил сам, или затянули смежники.
4. (IT-программистов это, скорее всего, в меньшей степени касается). При работе связанной с выездами для запуска "большого" объекта, нагрузку планируют без учета смены инженеров на месте. В общем делают так, что инженер живет на объекте месяцами, не видя семьи.
"без оценки объема непосредственным исполнителем" а как же вариант:
- Сколько времени займёт работа А?
- 1 месяц
- Сколько времени займёт работа Б
- Два месяца
- Так почему так долго? Работа же А занимала 1 месяц!
- Так потому что у меня работа А ещё не закончена, когда закончу - тогда и перейду к работе Б
- Нет, надо СРОЧНО отложить работу А и сделать работу Б!
- Ок, надо так надо.
- Сколько времени уйдёт на работу Б!
- Пять недель.
- Ок, работай
----------------- проходит месяц ---------
- Почему работа А не выполнена?
- Так я же занимался работой Б!
- Ты же сам сказал, что на выполнение работы А уйдёт месяц месяц назад!
- Так вы же сами сказали, что надо переключиться на работу Б!
- Да пофигу, что я тогда сказал! Надо обе работы сделать за месяц! Мы уже на полгода сроки сорвали!
Демотивирует, когда менеджер плохо делает свою работу (не помогает с организацией процесса, коммуникацией, требованиями и т.д.), а виноватым в случае провала по срокам будешь ты как исполнитель. У меня был менеджер, который похоже ожидал, что я буду делать всю его работу (по моему проекту), хорошо хоть его быстро уволили и заменили другим, повезло😅
Или когда спускают сверху жесткие сроки без учета реальной оценки, как уже писали тут.
принцип "за хорошую работу - ничего, а за что-то плохо сделанное (без разбора причин почему так вышло) - давать кнутом" это всегда для большинства людей приводит к падению мотивации ниже плинтуса
У нас например было такое что ты сделал большую систему, причем постарался, и с конечными пользователями даже поработал хорошо, а менеджеру не понравился интерфейс (причем он там был такой не просто так, а потому что подводных камней много), и вот менеджер не погружаясь в детали задачи просто взял и назвал все говном.. ну прям обрубает желание стараться
Бывает такое, у меня несколько раз подобное было в карьере
спасибо вам большое за интересный контент
Уничтожают производительность.
Менеджер внезапно заносит в спринт критические задачи. Говорит брось задачу high, скорей задачу критикал. Этим же вечером пишет бросай критикал, хватай другой критикал. И так от спринта к спринту. А в команде всего двое.
Самые демотвирующие вещи:
1. Микроконтроль, контролируют каждый шаг
2. Никакие решения невозможно внедрить, обсудим потом, назначим встречу о встрече, на который решим, что можно сделать и так по кругу.
3. Атмосфера порицания, Вася сделал говно, Вы видели, что он написал ? Это портит атмосферу в команде
4. Ошибка найма, когда сам попал или взял человека не по скилу, в итоге сеньор делает простые задачи по 2 недели.
Все эти вещи дико демотивируют либо всю команду, либо конкретного участника.
к сожалению также столкнулся с таким товарищем. каждый дейли - как на допросе в прокуратуре. плюсом у него была фишечка - вымещение своих детских комплексов на подчинённых. Я по полчаса на подготовку и восстановление добавлял ко встречам с ним.
Поделись опытом, расскажи как у тебя получилось из инжинера стать менеджером, с какими трудностями сталкивался, очень полезно будет!
ну как, все больше руководил людьми и в конце концов компания дала шанс работать менеджером
Порой менеджеры просто не понимают важности мелочей в подходах, которые они же самии выбрали. Например, зачем создавать Story, если там быстрый фикс на 1 story point, это можно и без задачи сделать. Зачем расписывать подробное описание и Acceptance критерии, если можно их накидать побыстрому. Зачем оценивать задачи вообще. Зачем создавать тикет для QA, если программист и сам может запустить и проверить, что он написал.
Не думаю, что такое встречается часто и скорее встречается среди низкоквалифицированных менеджеров, но работа сильно усложняется, когда разработчики сами должны следить за соблюдением процессов.
Это уже Бюрократия
Лайк в поддержку канала
А как у вас насчёт спринтов и дэдлайнов? На прошлой работе никто не парился если переносилась задача на следующий спринт, на текущей менеджер за**ет чтобы все было закончено под конец этого спринта и каждый раз пытается впихнуть всё больше и больше. Если честно напрягает жутко. И фичи мы никакие новые не деливерим каждый спринт. Проекты у нас распланированы и должны быть закончены целиком... индийский менеджер. Еще напрягает, что очень часто даже нет времени на то, чтобы нормально разобраться в задаче потому, что надо быстрее быстрее и менеджер подгоняет. И я не пойму это я дурак и не могу просто делать то, что надо или менеджер не очень и есть смысл попробовать в другую команду прыгнуть.
Это всё зависит от менеджера. Я без проблем переношу.
имхо - это у вас какая-то индийская шудра. они действительно выслуживаются тем, что формальные признаки сюблюдают. индийские погонщики хороши только для индусов. но люди из индусов получаются только в неиндусских командах. и то по моим наблюдениям 1 из 20-30
был у меня случай, когда на галере были погонщики индусские, которые уже в штатах жили и контора продавила нанимать индусский аутстаф. и там был какой-то головняк в индии с виртуальными машинами: они код писали на виртуалках, потому что иначе они в мир выйти не могли. и 2 индуса один за другим за полгода не смогли настроить себе доступ к нашему коду и системе для коммитов))) ни строчки кода закоммиченого - и платили им зп. и VP-шки индусские рассказывали всем, что у нас же контракт, мы должны свои обязательства перед индусской галерой выполнять... треш
Бедные книги 😢
Плохой менеджер с шестью пальцами 👀
Дурной менеджер - проекту трындец.
Задолбали такие персонажи.
Не посмотрел. Сразу. Да это полный П... ЕЦ ( простите) . пишешь пишешь. А потом говорят, ой мы тут кое-что забыли..... Или хочу вот а как не волнует. Простите наболело
Вы ни когда не ошибаетесь?
Конечно ошибаюсь, но учусь на ошибках. И от других ожидаю того, чтобы они учились на ошибках
Первый!!!
Не спасибо а благодарю
Кому як подобається, так і реалізує