Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 100
KPI могут быть разными.
Если мерить количество строк кода, это бред, а не KPI.
Нормальны KPI разработчика ( команды) в обязательном порядке содержит взаимоотношения следующих параметров:
Параметров много. Но бизнесу разработчики не нужны, которые вечно делают идеальный мир. Бизнесу нужны качественные результаты, помогающие дальнейшему развитию компании и решающие конкретные «боли» клиентов.
Если мерить количество строк кода, это бред, а не KPI.
Нормальны KPI разработчика ( команды) в обязательном порядке содержит взаимоотношения следующих параметров:
- количество выполненных требований
- степень участия в проекте
- Количество багов разработчика
- Соответствие соблюдения сроков работ, заявленным самим разработчиком
Параметров много. Но бизнесу разработчики не нужны, которые вечно делают идеальный мир. Бизнесу нужны качественные результаты, помогающие дальнейшему развитию компании и решающие конкретные «боли» клиентов.
Спокойно и легко. Пример — любая крупная аутсорсинговая компания.
Но для этого необходимо поставить соответствующие процессы в компании, а не работать по бригадно-подрядному принципу в состоянии вечного хаоса.
Если же распределение задач происходит на утреннем митинге «Вася делает А, Ваня делает Б, а Коля тестирует их результат», то да, все метрики не нужны
По факту, все измерения очень легко сделать ( супер-упрощённо):
Если все данные заносить в соответсвующие системы или хотя бы Excel, то всё легко вычисляется
Но для этого необходимо поставить соответствующие процессы в компании, а не работать по бригадно-подрядному принципу в состоянии вечного хаоса.
Если же распределение задач происходит на утреннем митинге «Вася делает А, Ваня делает Б, а Коля тестирует их результат», то да, все метрики не нужны
По факту, все измерения очень легко сделать ( супер-упрощённо):
- Владелец продукта вместе с бизнес- и системными аналитиками готовит требования для реализации ( с оценкой разработчиками трудоёмкости) и отмечает в любой полезной ИС, что требование готово к передаче команде ( в спринт, в этап проекта и т.п.)
- Тимлид/менеджер готовит план работ команды на неделю с учётом заявленной трудоёмкости для КАЖДОГО сотрудника
- Сотрудник работает по плану задач и коммитит исходный код, отмечая, какой коммит относится к какому требованию
- Тестер проверяет билд из многих коммитов ( привет, CI ) и заносит в информационную систему информацию о баге
- Разработчик правит баги
- Готовится релиз со всеми исправлениями
Если все данные заносить в соответсвующие системы или хотя бы Excel, то всё легко вычисляется
Это все едет по швам при первом же хитром баге в стороннем софте, фреймворке, старой имплементации, ОС и тд.
Или если ваша задача зависит от предоставления данных/аналитики клиентом.
Или клиент вдруг захотел на красное, а круглое.
Или А зависит от Б, а Ваня заболел/сидит с ребенком и тд.
Такие процессы вообще редкость и я сталкиваюсь с негативным отношением к такой формализации процесса у тех же скандинавских компаний.
Или если ваша задача зависит от предоставления данных/аналитики клиентом.
Или клиент вдруг захотел на красное, а круглое.
Или А зависит от Б, а Ваня заболел/сидит с ребенком и тд.
Такие процессы вообще редкость и я сталкиваюсь с негативным отношением к такой формализации процесса у тех же скандинавских компаний.
Это все едет по швам при первом же хитром баге в стороннем софте, фреймворке, старой имплементации, ОС и тд.
Для каждого проекта можно применять удобный процесс и всё . А по поводу имплементации, ОС и т.д. — в чём именно всё падает? При разумно описанном процессе, всё ОК
Или если ваша задача зависит от предоставления данных/аналитики клиентом.
Или А зависит от Б, а Ваня заболел/сидит с ребенком и тд.
Для этого и есть менеджеры, которые должны управлять рисками.
Или клиент вдруг захотел на красное, а круглое
Это проблема менеджера продукта или проекта, чтобы доносить до команды нормальные требования
Такие процессы вообще редкость и я сталкиваюсь с негативным отношением к такой формализации процесса у тех же скандинавских компаний.
Скандинавские компании слишком суровы. Я, наоборот, в России сталкивался и сталкиваюсь с достаточным количеством компанией, у которых внутренние процессы отлично формализованы и они достаточно гибкие. В качестве примера ( не реклама) могу привести Яндекс, Лаборатория Касперского
1. KPI метрики то как подбирать? MS вот отказался нафиг от этого.
2. Интересно посмотреть на управление риском — заболел ребенок и сижу дома с ним неделю.
3. Требования могут меняться заказчиком. Проблема не в донесении, а в перзистентности.
4. Ничего сурового. Наобород очень расслабленная стартап атмосфера у достаточно серьезных компаний. Я когда работу искал — первым делом говорили — мы не Российские компании, у нас неформальный процесс и готов ли я работать без лишней формализации. И работать в самом деле приятно.
2. Интересно посмотреть на управление риском — заболел ребенок и сижу дома с ним неделю.
3. Требования могут меняться заказчиком. Проблема не в донесении, а в перзистентности.
4. Ничего сурового. Наобород очень расслабленная стартап атмосфера у достаточно серьезных компаний. Я когда работу искал — первым делом говорили — мы не Российские компании, у нас неформальный процесс и готов ли я работать без лишней формализации. И работать в самом деле приятно.
1. Не совсем понял вопрос. MS не отказался — он сказал — «вот вам инструменты для отчётов и делайте свои метрики сами», тот же Burndown может дать много полезного
2. А также, другого разработчика сбила машина, а девушка-тестер ушла в декрет. Управление хотя бы самое простое — заранее предусмотреть некоторую вероятность переброса другого человека на Вашу работу ( если проект большой, естественно). А если проект ОЧЕНЬ большой ( на 150-300 человек, то даже половина отдела может внезапно исчезнуть и на проекте это скажется не очень сильно)
3. Для этого и есть процесс подписания ТЗ заказчиком, а также актов работ и вообще построения взаимоотношений с заказчиком. Команду разработки такие вопросы вообще не должны волновать. Если менеджер продукта/проекта докупускает кардинальные изменения проекта в процессе — значит он плохой менеджер. А если заказчик продавливает изменения — то меняются и сроки проекта и его цена для заказчика.
4. Мне такие, к сожалению, не встречались. А вообще — это правильны подход — оградить от формализации всех специалистов. Это всё задача менеджеров. Ну и всё зависит от того, как работает компания и её размер.
С точки зрения здравого смысла — для меня компания со штатом 1000+ и слабо формализованная — это утопия и идеальный мир, которого не существует
2. А также, другого разработчика сбила машина, а девушка-тестер ушла в декрет. Управление хотя бы самое простое — заранее предусмотреть некоторую вероятность переброса другого человека на Вашу работу ( если проект большой, естественно). А если проект ОЧЕНЬ большой ( на 150-300 человек, то даже половина отдела может внезапно исчезнуть и на проекте это скажется не очень сильно)
3. Для этого и есть процесс подписания ТЗ заказчиком, а также актов работ и вообще построения взаимоотношений с заказчиком. Команду разработки такие вопросы вообще не должны волновать. Если менеджер продукта/проекта докупускает кардинальные изменения проекта в процессе — значит он плохой менеджер. А если заказчик продавливает изменения — то меняются и сроки проекта и его цена для заказчика.
4. Мне такие, к сожалению, не встречались. А вообще — это правильны подход — оградить от формализации всех специалистов. Это всё задача менеджеров. Ну и всё зависит от того, как работает компания и её размер.
С точки зрения здравого смысла — для меня компания со штатом 1000+ и слабо формализованная — это утопия и идеальный мир, которого не существует
3. За два года ни разу не встречался проект на котором требования бы не менялись в самый неподходящий момент, бывало на такие изменения недели разработки уходят, хотя в первоначальной формулировке задача на пару дней была. И не помню ни одного случая когда это увеличило бы для заказчика стоимость проекта. Но это 1с-франчайзи, возможно за пределами 1с мир светлее.
1. Может. Но только по нему определять эффективность не всегда корректно.
2. Есть нюанс. Такие проекты обычно бьются на маленькие команды по 6-8 человек. Если требуется какая-то специфичная специализация — тяжело просто взять и перекинуть кого-то.
3. Заказчики они такие… А менеджер может хоть ухотеться — поставят вопрос ребром и быстро на все согласится ;)
4. А зачем формализация в отделе разработки? :) Часть компании может быть формальной — разработка быть отдельной единицей. Плохо когда всю тысячу пытаются подогнать под один стандарт без учета специфики(начиная от дресскодов и заканчивая жестким крафиком).
2. Есть нюанс. Такие проекты обычно бьются на маленькие команды по 6-8 человек. Если требуется какая-то специфичная специализация — тяжело просто взять и перекинуть кого-то.
3. Заказчики они такие… А менеджер может хоть ухотеться — поставят вопрос ребром и быстро на все согласится ;)
4. А зачем формализация в отделе разработки? :) Часть компании может быть формальной — разработка быть отдельной единицей. Плохо когда всю тысячу пытаются подогнать под один стандарт без учета специфики(начиная от дресскодов и заканчивая жестким крафиком).
Для этого и есть менеджеры, которые должны управлять рисками.
Какие риски? «А» не набил свои KPI, потому что Ваня, от которого зависит часть работы, заболел.
И дальше 2 варианта — наказать «A», честно засчитав низкий KPI, либо сделать «дыру» — исключение в правилах, но тогда вечно будут отговорки: вот тогда сделали исключение, а у меня сейчас тоже проблемы, и мне сделайте.
Степень участия в проекте это очень субьективный парметр. Ну если не считать его по числу коммитов в код. Вот Вася коммитит много, а Петя за чаем объясняет джуниорам разные полезные вещи. А Серега вроде и коммитит мало, и джунов троллит, зато поднимает дух всей команде, да еще и находит самые хитровывернутые баги.
Кто из них лучше а кто хуже?
Про количество багов туда же. В команде большинство багов общие. Во-первых код обычно проходит ревью у других разрабов, во-вторых баги часто сложные, когда совпала фаза луны, два недобага и недоработка конфигурации. На кого это повесим? Тут виноват и архитектор который придумал не идеальную схему изначально, и три исполнителя сразу же. Причем по отдельности каждый не винтоват, и ничего страного не сделал.
Соотвествие сроков работ. Ну тут сразу 99% получат жирный минус. Удобная штука.
Кто из них лучше а кто хуже?
Про количество багов туда же. В команде большинство багов общие. Во-первых код обычно проходит ревью у других разрабов, во-вторых баги часто сложные, когда совпала фаза луны, два недобага и недоработка конфигурации. На кого это повесим? Тут виноват и архитектор который придумал не идеальную схему изначально, и три исполнителя сразу же. Причем по отдельности каждый не винтоват, и ничего страного не сделал.
Соотвествие сроков работ. Ну тут сразу 99% получат жирный минус. Удобная штука.
О степени участия — это человеко-часы( в любой проектной компании по другому и нельзя).
А об оценке — опять же, я и говорю -взаимосвязь показателей.. Да и оцениваться Вася и Петя должны по разному. Да и в целом, ещё раз повторю — это ОДИН из показателей, но не единственный
Количество багов — клиенту без разницы, кто виноват — ему нужен работающий продукт, решающий его проблемы. И это командный показатель.
По срокам — опять же, всё зависит от того, как считать.
Если в проекте на 1000 человеко-часов зафейлить 3 дня — так даже снимать никто ничего не будет.Это нормально и укладывается в риски.
А если в проекте на 40 человеко-часов зафейлить 3 дня — это разработчик где то не прав.
А об оценке — опять же, я и говорю -взаимосвязь показателей.. Да и оцениваться Вася и Петя должны по разному. Да и в целом, ещё раз повторю — это ОДИН из показателей, но не единственный
Количество багов — клиенту без разницы, кто виноват — ему нужен работающий продукт, решающий его проблемы. И это командный показатель.
По срокам — опять же, всё зависит от того, как считать.
Если в проекте на 1000 человеко-часов зафейлить 3 дня — так даже снимать никто ничего не будет.Это нормально и укладывается в риски.
А если в проекте на 40 человеко-часов зафейлить 3 дня — это разработчик где то не прав.
По-моему KPI — это то, что демотивирует работников (особенно IT-шников). Т.к. чаще всего KPI — это не стимулирующий, а карательный инструмент. К тому же разжигающий конкуренцию и вражду в коллективе. Лучше уж просто премии выписывать за успешный выпуск продукта в срок/за окончание проекта и т.д. (Т.е. быть ориентированным на результат, а не на достижения сомнительных цифр, которые не принесут пользы ни работникам, ни бизнесу.
А предложенными вами KPI очень легко довести разработку до абсурда и имитации бурной деятельности. Вот примеры:
1. Количество выполненных требований. (Работники будут заносить в требования абсолютно всё. К тому же количество требований и их сложность — разные вещи, и можно выполнить 1 требование за период, но которое координально улучшает продукт, а можно 1000, но это просто будет перестановка кнопок местами.
2. Степень участия в проекте — не соответствует SMART. Этот показатель субъективен и его нельзя измерить.
3. Количество багов разработчика — Зависит от сложности задачи и работы отдела тестирования. Разработчики будут стараться спихнуть сложные задачи на других и отдать свою работу самому бездарному тестировщику, чтобы тот нашёл как можно меньше багов.
4. Соответствие соблюдения сроков работ, заявленным самим разработчиком — С момента внедрения этого требования оценки разработчиков вырастут в разы. Освободившееся время будет тратиться на KPI номер 3 из списка. В результате имеем продукт с вылизанным существующим функционалом, но огромное отставание по реализации новых фич.
А предложенными вами KPI очень легко довести разработку до абсурда и имитации бурной деятельности. Вот примеры:
1. Количество выполненных требований. (Работники будут заносить в требования абсолютно всё. К тому же количество требований и их сложность — разные вещи, и можно выполнить 1 требование за период, но которое координально улучшает продукт, а можно 1000, но это просто будет перестановка кнопок местами.
2. Степень участия в проекте — не соответствует SMART. Этот показатель субъективен и его нельзя измерить.
3. Количество багов разработчика — Зависит от сложности задачи и работы отдела тестирования. Разработчики будут стараться спихнуть сложные задачи на других и отдать свою работу самому бездарному тестировщику, чтобы тот нашёл как можно меньше багов.
4. Соответствие соблюдения сроков работ, заявленным самим разработчиком — С момента внедрения этого требования оценки разработчиков вырастут в разы. Освободившееся время будет тратиться на KPI номер 3 из списка. В результате имеем продукт с вылизанным существующим функционалом, но огромное отставание по реализации новых фич.
1 и 2 — взаимосвязанные. Трудоёмкость проекта на выходе — 100 часов. 10 требований по 1 часу и 1 требование на 90 часов.
3.Я имею ввиду баги после РЕЛИЗА, найденные клиентами. И команда одна — не тестеры отдельно, разработчики отдельно, а они вместе накосячили. Клиенту без разницы
4. А это уже вопрос к руководителю. производства отдельно и к менеджеру продукта отдельно
3.Я имею ввиду баги после РЕЛИЗА, найденные клиентами. И команда одна — не тестеры отдельно, разработчики отдельно, а они вместе накосячили. Клиенту без разницы
4. А это уже вопрос к руководителю. производства отдельно и к менеджеру продукта отдельно
Соглашусь про баги после выпуска продукта — вполне разумное измерение. (При условии, что баги не «разработчика», а «команды» (в первом коментарии было именно «разработчика»).
Степень участия проекта даже в изменённой интерпретации всё равно неизмерима. Если мерить только по задачам, то остаётся неучтёным менторинг и помощь коллегам, внедрение новых технологий и методов разработки в проект, организация процессов и т.д.
Вообще KPI — это для менеджеров. А для разработчиков — это лишнее. Тем более когда это отражается на зарплате.
Мне как разработчику важно получать стабильный доход, который не зависит от внешних факторов/настроения руководства/зафейлившего проект проектного менеджера и т.д.
Другое дело что приятно получить что-то по результатам своей работы раз в год/квартал или по окончанию проекта/выпуску билда. (Вот для этих целей можно и KPI использовать для создания видимости справедливости)
Степень участия проекта даже в изменённой интерпретации всё равно неизмерима. Если мерить только по задачам, то остаётся неучтёным менторинг и помощь коллегам, внедрение новых технологий и методов разработки в проект, организация процессов и т.д.
Вообще KPI — это для менеджеров. А для разработчиков — это лишнее. Тем более когда это отражается на зарплате.
Мне как разработчику важно получать стабильный доход, который не зависит от внешних факторов/настроения руководства/зафейлившего проект проектного менеджера и т.д.
Другое дело что приятно получить что-то по результатам своей работы раз в год/квартал или по окончанию проекта/выпуску билда. (Вот для этих целей можно и KPI использовать для создания видимости справедливости)
Соглашусь, изначально я выбрал неправильную формулировку, под понятием разработчик понимая команду.
По поводу степени участия — а для этого есть и другие метрики и правила.
По стабильности дохода — я придерживаюсь «белых» принципов начисления:
1. Зарплату по закону нельзя уменьшать — всё согласно договору. И платиться она ежемесячно в полном объёме в соответствии с требованиями рынка.
2.Квартальная премия, которую надо заработать в размере хотя бы 1 оклада. И отсюда как раз и вытекают показатели качества, эффективности и т.д. Пример «с потолка» по распределению 100% премии: 30% — количество багов после релиза, 30% — целевые задачи ( та же помощь остальным, менторинг и т.д.), 30% — соблюдение внешнего SLA при багфиксе. 10% — за конкретные улучшения в проекте/процессе.
Итого — у сотрудника всегда есть хороший оклад и он может заработать больше, делая что то, чуть больше или чуть лучше в рамках своего рабочего времени.
По поводу степени участия — а для этого есть и другие метрики и правила.
По стабильности дохода — я придерживаюсь «белых» принципов начисления:
1. Зарплату по закону нельзя уменьшать — всё согласно договору. И платиться она ежемесячно в полном объёме в соответствии с требованиями рынка.
2.Квартальная премия, которую надо заработать в размере хотя бы 1 оклада. И отсюда как раз и вытекают показатели качества, эффективности и т.д. Пример «с потолка» по распределению 100% премии: 30% — количество багов после релиза, 30% — целевые задачи ( та же помощь остальным, менторинг и т.д.), 30% — соблюдение внешнего SLA при багфиксе. 10% — за конкретные улучшения в проекте/процессе.
Итого — у сотрудника всегда есть хороший оклад и он может заработать больше, делая что то, чуть больше или чуть лучше в рамках своего рабочего времени.
Убивают не за KPI, а за неадекватные KPI. У сотрудника должно быть понимание, что он получает некую «плюшку» за чёткий, достижимый и прозрачный показатель. Если премию дают или не дают в зависимости от настроения руководства, без всяких KPI/КПЭ/Целей/Вклада/Оценки, то вот за это можно начинать «убивать».
Я буду удивлён, если мне скажут, что в ТОП-100 компаниях не будет KPI для разработчиков ( если в компании более 80-100 человек )
В Enterprise — мире KPI есть всегда.
Если это стартап, то да, там может не быть этого
В Enterprise — мире KPI есть всегда.
Если это стартап, то да, там может не быть этого
ALGN, более 4000 сотрудников (более 300 девелоперов), один из лидеров рынка. Лучшая фирма где я когда-либо работал.
KPI (в понимании по количеству багов и т.п.) нет.
И уходить скажем к kaspersky отсюда мне ну воообще не хочется. Именно из-за паршивого отношения к девелоперам, по слухам, сопровождающего «хорошо отлаженный бизнес-процесс» Касперского.
KPI (в понимании по количеству багов и т.п.) нет.
И уходить скажем к kaspersky отсюда мне ну воообще не хочется. Именно из-за паршивого отношения к девелоперам, по слухам, сопровождающего «хорошо отлаженный бизнес-процесс» Касперского.
Ммм… очень интересно. То есть вообще нет KPI у 300 девелоперов? Голый оклад? Вы что-то недоговариваете. Может назвали другими словами? Цели квартальные или бонусные баллы или ачивки или ещё как? А формулировки KPI они разные бывают, количество багов как раз пример плохого KPI (сугубое IMHO).
Там есть естественно Performance Evaluation по итогам года, постановка целей в начале года, список формальных критериев «что хорошо а что нет» с градациями позволяющими примерно оценить результат по соответствию ожиданиям, но сам процесс проходит в форме довольно неформального общения и только один раз в год. Т.е. KPI вообще говоря есть, но он совсем не такой как его описывает pan_KOST, если судить по комментариям.
То есть KPI всё же есть. Я не вполне согласен с pan_KOST в формулировках и в статье также не упоминал о формальных и вредных KPI. В статье я указал, что они должны соответствовать SMART и не быть догмой. В этом случае они принесут пользу. К сожалению, во многих российских компаний их вводят в качестве «карающего меча», для среза надбавок или премий и они приносят один вред. Основной же их смысл — давать объективную оценку труда сотрудника и мотивировать его. Часто про это забывают, превращая их в инструмент демотивации.
Как я понял, речь не о формальных оценках, а о субъективных.
Например, руководитель может сказать по итогам года: Вася — молодец, потому что сделал А, Б, Ц (и это не все пункты из таск-трекера, которых можно набивать побольше, руководитель сам выбирает, что отметить, а что игнорировать), а Петя — вола пинал весь год (и опять это субъективно, по ощущениям оценщика).
Может, это и плохо, если с оценкой Петя не согласится и будет обижен, но это не KPI.
Например, руководитель может сказать по итогам года: Вася — молодец, потому что сделал А, Б, Ц (и это не все пункты из таск-трекера, которых можно набивать побольше, руководитель сам выбирает, что отметить, а что игнорировать), а Петя — вола пинал весь год (и опять это субъективно, по ощущениям оценщика).
Может, это и плохо, если с оценкой Петя не согласится и будет обижен, но это не KPI.
Еще бы эти плюшки были осязаемыми и весомыми, а не абстрактной фигней :)
Обычно это рассчитывается в виде премии )
Обычно когда начинаешь впахивать на адекватный размер премии, ее начинают резать ;)
Могу я поинтересоваться, а повышать сотрудников Вы предлагаете по каким критериям? Личным ощущениям?
P.S. Не забывайте про картинку в заголовке поста — просто не будьте м… и и не работайте с такими людьми.
Одна из немногих книг, которую я бросил, не дочитав. Сплошное нытьё автора и ничего дельного.
А еще вставьте куда-нибудь в текст, пожалуйста, про опен спейс :) Это реально напрягает. Или пусть их делают так, чтобы хоть какое-то было ощущение личного пространства.
Я бы сам не отказался от вариантов сложения опен спейса и личного пространства ( но не как в клерки в фильмах и не индивидуальные кельи )
У опенспейса есть преимущество — всех знаешь, кто чем занимается и у кого что болит. А то бывает такое, что узнаешь об изменении состава компании только на тимбилдингах раз в год.
Ну если например ПМ узнает о том кто чем занят только исходя из наблюдений в опенспейсе — гнать таких спецов надо. Для других эта информация тоже непонятно зачем нужна. Короче не довод ни разу.
Опенспейс тот еще кошмар. У консалта постоянно телефоны звонят, постоянно какие то разговоры, по теме и нет, одновременно по 3 группы совещающихся пытающихся друг друга перекричать. Даже наушники не спасают.
Мне, как разработчику, совершено всё ровно на изменения состава компании. Есть люди, с которыми я пересекаюсь в рамках своих задач, а есть еще больше десятка, которые я даже не знаю чем занимаются и на какой должности. И все мы сидим в одной комнате.
И, по-моему, то, что Вы сказали, это и есть самое ужасное в опен спейсе — ты еще в добавок ко всему шуму знаешь у кого что болит… О ужас, зачем мне еще чужие проблемы знать ?!
И, по-моему, то, что Вы сказали, это и есть самое ужасное в опен спейсе — ты еще в добавок ко всему шуму знаешь у кого что болит… О ужас, зачем мне еще чужие проблемы знать ?!
Сейчас просто тенденция такая — ходить на работу за задачей и зарплатой. Работодатель тоже относится к сотруднику не как к человеку, а как к записи в базе данных. Всех всё устраивает. Место работы не воспринимается как коллектив, все равно все каждый год разные в среднем сотрудник-аутсорсер на одном месте проводит около двух лет. И от социальной функции, которой как раз опенспейс и способствует, почти ничего и не осталось.
Я так и думал, что кто-нибудь подобное начнет писать.
Ну вот я интраверт. Я хоть и люблю общаться и всё такое, но очень устаю от большого кол-ва людей на протяжении долгого времени. К работе я отношусь совершенно не так, как Вы описали.
Вы понимаете, что люди разные бывают. У нас вот есть такие, кто любит понудеть, есть высоко патриотичные люди, есть низко технологичные люди, есть те, кто любит ООП, есть те, кто любит функциональщину, кто-то визжит в истерике, когда хвалят мак или айфон, кто-то ненавидит андроид… Понимаете, я не хочу близко общаться с некоторыми людьми. И не потому, что я не люблю их, а просто ну слишком у нас разные ценности. Зачем нас садить рядом и пытаться подружить? Мы так только врагами сможем стать. При том, что мы по работе вообще не пересекаемся.
На мой взгляд, намного лучше проводить тематические встречи, на которых будут сближаться сотрудники по интересам. Это намного продуктивнее и интереснее.
Ну вот я интраверт. Я хоть и люблю общаться и всё такое, но очень устаю от большого кол-ва людей на протяжении долгого времени. К работе я отношусь совершенно не так, как Вы описали.
Вы понимаете, что люди разные бывают. У нас вот есть такие, кто любит понудеть, есть высоко патриотичные люди, есть низко технологичные люди, есть те, кто любит ООП, есть те, кто любит функциональщину, кто-то визжит в истерике, когда хвалят мак или айфон, кто-то ненавидит андроид… Понимаете, я не хочу близко общаться с некоторыми людьми. И не потому, что я не люблю их, а просто ну слишком у нас разные ценности. Зачем нас садить рядом и пытаться подружить? Мы так только врагами сможем стать. При том, что мы по работе вообще не пересекаемся.
На мой взгляд, намного лучше проводить тематические встречи, на которых будут сближаться сотрудники по интересам. Это намного продуктивнее и интереснее.
> Вы понимаете, что люди разные бывают. У нас вот есть такие, кто любит понудеть, есть высоко патриотичные люди, есть низко технологичные люди, есть те, кто любит ООП, есть те, кто любит функциональщину, кто-то визжит в истерике, когда хвалят мак или айфон, кто-то ненавидит андроид…
Совершенно верно. Именно поэтому интровертам, таким как я (может даже и Вы), куда уместней краем уха послушать, о чем говорят представители того, с чем я добровольно никогда не пересекусь, и тем более не пойду на тематические встречи. Потому как быть слишком узким специалистом это хорошо для карьеры только пока есть на такую специализацию спрос, но мне даже в голову не придет задавать специфические для несмежной отрасли вопросы без соответствующего контекста, а откуда контексту взяться, если все пути для его проникновения закрыты?
Кстати о разных людях. Имел удовольствие работать в широко известной в узких кругах компании, где опенспейс это принцип (у нас — 80+ человек в одном помещении). Безусловно, там были вот эти все:
> У нас вот есть такие, кто любит понудеть, есть высоко патриотичные люди, есть низко технологичные люди, есть те, кто любит ООП, есть те, кто любит функциональщину, кто-то визжит в истерике, когда хвалят мак или айфон, кто-то ненавидит андроид…
Никто. Никогда. Ни с кем. Не конфликтовал.
ИМХО это уже совсем должно быть дно — лезть в ссоры из-за разногласий. Обычно таких людей отсекали еще на собеседованиях. Если же каким-то образом такой человек получил оффер, независимо от его уровня квалификации надолго он не задерживается, потому что сложные задания требуют командной работы, а с ним вся команда разбежится в течение месяца. Возможно Вам просто не везло с коллективом.
Совершенно верно. Именно поэтому интровертам, таким как я (может даже и Вы), куда уместней краем уха послушать, о чем говорят представители того, с чем я добровольно никогда не пересекусь, и тем более не пойду на тематические встречи. Потому как быть слишком узким специалистом это хорошо для карьеры только пока есть на такую специализацию спрос, но мне даже в голову не придет задавать специфические для несмежной отрасли вопросы без соответствующего контекста, а откуда контексту взяться, если все пути для его проникновения закрыты?
Кстати о разных людях. Имел удовольствие работать в широко известной в узких кругах компании, где опенспейс это принцип (у нас — 80+ человек в одном помещении). Безусловно, там были вот эти все:
> У нас вот есть такие, кто любит понудеть, есть высоко патриотичные люди, есть низко технологичные люди, есть те, кто любит ООП, есть те, кто любит функциональщину, кто-то визжит в истерике, когда хвалят мак или айфон, кто-то ненавидит андроид…
Никто. Никогда. Ни с кем. Не конфликтовал.
ИМХО это уже совсем должно быть дно — лезть в ссоры из-за разногласий. Обычно таких людей отсекали еще на собеседованиях. Если же каким-то образом такой человек получил оффер, независимо от его уровня квалификации надолго он не задерживается, потому что сложные задания требуют командной работы, а с ним вся команда разбежится в течение месяца. Возможно Вам просто не везло с коллективом.
Вы толи сам маркетолог, толи находитесь под их влиянием… Зачем Вы мне пытаетесь доказать, что опен спейс так хорош и помогает нам всем общаться друг с другом и сближаться? Причем… на работе(!) в рабочее время(!!).
Вот опен спейс представляяет из себя именно мешанину всего в одно — работа, личные беседы десятков людей, которые слышат зачем-то все, попытка всех сдружить, сблизить, плюс увеличить коммуникативность команды, плюс еще какая-нибудь неведомая хрень.
Мне, как сотруднику программисту тим-лиду, опен спейс создает массу неудобств в работе и в общении. Когда я хочу пошутить или пообщаться на личные темы, то мне не комфортно, потому что это слышат еще десятки непонятных людей. Когда я хочу поделиться прочитанным про новинки в ИТ, то опять опасаюсь это сделать, а то услышит какой-нибудь нудила, влезет в разговор и обломает всю нашу беседу. Когда я хочу сосредоточиться и решить сложную задачу, то кто-то рядом неожиданно хочет пошутить или поболтать.
Вообщем, дискуссия ни о чем. Вы пытаетесь навязать какую-то неведомую теоритическую мысль про опен спейс, в которую очевидно верите, или хотите верить.
Но я не могу её принять, потому что не хочу логически для себя обдумывать почему мне это должно нравится. Мне это просто не нравится и я себя чувствую в этом не комфортно.
Только не думайте, что я прям работаю и мучаюсь в этом. Я работаю за большие деньги, у меня интересные задачи, замечательный коллектив, отличный директор. Я работал в крупных компаниях, в прогрессивных командах и т.д. и т.п. Но если убрать опен спейс, то просто будет на 1 плюсик больше ко всему, а пока это минус.
Вот опен спейс представляяет из себя именно мешанину всего в одно — работа, личные беседы десятков людей, которые слышат зачем-то все, попытка всех сдружить, сблизить, плюс увеличить коммуникативность команды, плюс еще какая-нибудь неведомая хрень.
Мне, как сотруднику программисту тим-лиду, опен спейс создает массу неудобств в работе и в общении. Когда я хочу пошутить или пообщаться на личные темы, то мне не комфортно, потому что это слышат еще десятки непонятных людей. Когда я хочу поделиться прочитанным про новинки в ИТ, то опять опасаюсь это сделать, а то услышит какой-нибудь нудила, влезет в разговор и обломает всю нашу беседу. Когда я хочу сосредоточиться и решить сложную задачу, то кто-то рядом неожиданно хочет пошутить или поболтать.
Вообщем, дискуссия ни о чем. Вы пытаетесь навязать какую-то неведомую теоритическую мысль про опен спейс, в которую очевидно верите, или хотите верить.
Но я не могу её принять, потому что не хочу логически для себя обдумывать почему мне это должно нравится. Мне это просто не нравится и я себя чувствую в этом не комфортно.
Только не думайте, что я прям работаю и мучаюсь в этом. Я работаю за большие деньги, у меня интересные задачи, замечательный коллектив, отличный директор. Я работал в крупных компаниях, в прогрессивных командах и т.д. и т.п. Но если убрать опен спейс, то просто будет на 1 плюсик больше ко всему, а пока это минус.
Ваша точка зрения слишком субъективна и авторитарна. Доказательством тому служат непонятно откуда взятые выводы:
> на работе(!) в рабочее время(!!)
> Вы толи сам маркетолог, толи находитесь под их влиянием
Впрочем вам конечно же виднее. Я всего лишь старался объяснить, что не так страшен опенспейс, как о нем любят рассказывать, особенно те, кто в нем никогда не работал. Точно так же субъективно у меня после данной работы в опенспейсе остались только самые лучшие впечатления, не в последнюю очередь благодаря такой организации пространства.
> на работе(!) в рабочее время(!!)
> Вы толи сам маркетолог, толи находитесь под их влиянием
Впрочем вам конечно же виднее. Я всего лишь старался объяснить, что не так страшен опенспейс, как о нем любят рассказывать, особенно те, кто в нем никогда не работал. Точно так же субъективно у меня после данной работы в опенспейсе остались только самые лучшие впечатления, не в последнюю очередь благодаря такой организации пространства.
Когда вижу в вакансии слово «тимбилдинг» — становится тошно. Обычно вместо того, чтобы решить реальные проблемы (например заменить дырявые окна, или сделать вентеляцию в помещении, вонючий ленолеум заменить, монитор нормальный поставить, купить удобную клавиатуру и мышку) — начинается тимматьегобилдинг…
А если все окна сделали, ремонт месяц назад закончили, все компы на уровне?
Поднять зарплату или дать премию. Кому надо — сами сбилдядтся в баре/на шашлыках ;)
Всем подряд одинаково тоже нельзя поднимать — иначе будут разговоры — «я же лучше, чем он работаю, а подняли нам одинаково».
А премию надо давать, как и писали выше, не потому, что так захотелось — а на основе заранее известных правил, которые всеми приняты
А премию надо давать, как и писали выше, не потому, что так захотелось — а на основе заранее известных правил, которые всеми приняты
Вопрос зарплаты в любой компании сотрудниками обсуждаться не должен. Если ко мне приходит сотрудник и говорит, что у Пети зарплата выше, будет уволен Петя. Это прописывается в договоре.
Приходим к боссу и спрашиваем, почему у него зарплата выше. Босс сам себя увольняет :)
Простите, но разве договор может быть выше законов страны? Зарплату можно говорить всегда, как бы обратного не хотелось определенным руководителям.
Если Вы собираетесь воевать с руководством, а не сотрудничать с ним, то конечно.
Но я Вас уверяю что гораздо приятнее работать в компаниях где с руководством хочется сотрудничать
Но я Вас уверяю что гораздо приятнее работать в компаниях где с руководством хочется сотрудничать
Гораздо приятнее работать в компаниях, где зарплата формируется прозрачно.
Поясню: грош цена руководству, если оно не в состоянии объяснить, почему Ивана повысили в должности и зарплате, или почему у двух разработчиков зарплаты отличаются на 20%.
Неподдельная радость работать там, где не надо выбирать, с кем «сотрудничать» и где сам понимаешь, что Вася крут и заслуженно получил свою надбавку.
И отвратительно работать там, где руководство боится собственных работников и старается их разобщить.
Поясню: грош цена руководству, если оно не в состоянии объяснить, почему Ивана повысили в должности и зарплате, или почему у двух разработчиков зарплаты отличаются на 20%.
Неподдельная радость работать там, где не надо выбирать, с кем «сотрудничать» и где сам понимаешь, что Вася крут и заслуженно получил свою надбавку.
И отвратительно работать там, где руководство боится собственных работников и старается их разобщить.
Я думаю, в таких случаях руководство не старается разобщить работников, а банально сэкономить.
Например, одному разработчику не хватает денег на оплату кредита, он приходит к руководству — так и так, или повышайте, или пойду в другое место. Куда деваться, повышают. Но если всё в компании прозрачно, тут же прибежит толпа коллег, которые и не задумывались о повышении, и отказать им будет нельзя — почуствуют несправедливость.
Например, одному разработчику не хватает денег на оплату кредита, он приходит к руководству — так и так, или повышайте, или пойду в другое место. Куда деваться, повышают. Но если всё в компании прозрачно, тут же прибежит толпа коллег, которые и не задумывались о повышении, и отказать им будет нельзя — почуствуют несправедливость.
Объяснить — можно. Только обиженные все равно будут. Даже в идеальном случае когда начальство назначает оценки абсолютно объективно.
Про разобщение вообще не понял. Как незнание зарплаты соседа разобщает коллектив? Вот обида на несправедливую зарплату запросто может коллектив разобщить. А незнание зарплаты-то как?
Про разобщение вообще не понял. Как незнание зарплаты соседа разобщает коллектив? Вот обида на несправедливую зарплату запросто может коллектив разобщить. А незнание зарплаты-то как?
Незнание зарплаты, кроме того, что это нарушение законов нашей страны, которые позволяют делиться этой информацией с кем угодно, делает самое главное — ставит работников в неравные условия с руководством. Руководство знает условия работы работников, а работники не знают всех условий работы.
В итоге получаем такое положение дел: каждый считает, что зарплата более-менее у всех одинаковая, а на деле у Коли, который клево говорит, но фигово работает, зарплата на 40% выше. Руководству же весьма удобно делать любые «непрозрачные» дела, пользуясь разобщенностью сотрудников. Да хоть откровенную дискриминацию по возрасту, полу, происхождению. Все думают, что на одной должности у всех доход более-менее одинаков, хотя на деле у одной категории работников доход может сильно отличаться, просто за «красивые глаза».
На мой взгляд, любые попытки врать про то, что разглашение зарплаты противозаконно — это грязный трюк и работодатель это чувствует, ведь как правило идет не объяснение в стиле «я, ваш руководитель, считаю, что это разобщит нас, как коллектив», а вранье про «разглашать свои зарплаты запрещено договором!».
Если побуждения руководства благородны и продиктованы заботой о коллективе, то зачем использовать подобные хитрые и нечистоплотные трюки?
В итоге получаем такое положение дел: каждый считает, что зарплата более-менее у всех одинаковая, а на деле у Коли, который клево говорит, но фигово работает, зарплата на 40% выше. Руководству же весьма удобно делать любые «непрозрачные» дела, пользуясь разобщенностью сотрудников. Да хоть откровенную дискриминацию по возрасту, полу, происхождению. Все думают, что на одной должности у всех доход более-менее одинаков, хотя на деле у одной категории работников доход может сильно отличаться, просто за «красивые глаза».
На мой взгляд, любые попытки врать про то, что разглашение зарплаты противозаконно — это грязный трюк и работодатель это чувствует, ведь как правило идет не объяснение в стиле «я, ваш руководитель, считаю, что это разобщит нас, как коллектив», а вранье про «разглашать свои зарплаты запрещено договором!».
Если побуждения руководства благородны и продиктованы заботой о коллективе, то зачем использовать подобные хитрые и нечистоплотные трюки?
Работники всегда были, есть и будут в неравных условиях с руководством в отношении доступа к информации. Они разные задачи решают, им не надо знать многие вещи специфичные для руководителей (а руководству — не надо знать многие вещи специфичные для разработчиков). Есть и просто закрытые проекты где я, к примеру, и с другими девелоперами определенной информацией о новой разработке делиться до анонса этой разработки не имею права. Вы говорите здесь о бессмысленном анархизме: «незнание плохо потому что все должны знать все».
Возьмите свой пример и предположите что зарплата Коли станет известна. И что дальше? Руководство снизит зарплату Коле? Нет конечно, оно искренне считает что Коля ее заслуживает. И возникнет конфликт. Нафига? Плохие аспекты я здесь явно вижу, а положительных — ни одного. Разве нет?
Сотруднику, по большому счету, достаточно знать три простые вещи: собственную зарплату, то как она изменяется, и средний уровень по индустрии (сколько денег он получит если уйдет работать в другое место). ВСЁ. Эти три величины уже дают адекватное понимание своего положения в компании. Зачем знать во всех подробностях сколько получает сосед?
И где Вы видите вранье-то? Соглашение о неразглашении зарплаты — это договор и есть, самый натуральный, подписываемый на этапе заключения трудового соглашения. Там четко и понятно объясняется все правила игры. Причем этих правил там, как правило, много, и неразглашение зарплат — лишь одно из них. Я не знаю конечно с кем Вам приходилось иметь дело, но сомневаюсь что кто-то говорил именно что-то о «противозаконности» подобных действий, а не о банальном «нарушении заключенного ранее договора который Вы читали и подписывали».
Возьмите свой пример и предположите что зарплата Коли станет известна. И что дальше? Руководство снизит зарплату Коле? Нет конечно, оно искренне считает что Коля ее заслуживает. И возникнет конфликт. Нафига? Плохие аспекты я здесь явно вижу, а положительных — ни одного. Разве нет?
Сотруднику, по большому счету, достаточно знать три простые вещи: собственную зарплату, то как она изменяется, и средний уровень по индустрии (сколько денег он получит если уйдет работать в другое место). ВСЁ. Эти три величины уже дают адекватное понимание своего положения в компании. Зачем знать во всех подробностях сколько получает сосед?
И где Вы видите вранье-то? Соглашение о неразглашении зарплаты — это договор и есть, самый натуральный, подписываемый на этапе заключения трудового соглашения. Там четко и понятно объясняется все правила игры. Причем этих правил там, как правило, много, и неразглашение зарплат — лишь одно из них. Я не знаю конечно с кем Вам приходилось иметь дело, но сомневаюсь что кто-то говорил именно что-то о «противозаконности» подобных действий, а не о банальном «нарушении заключенного ранее договора который Вы читали и подписывали».
этот пункт договора не имеет законной силы. Думаю, каждый руководитель должен это знать.
Эта информация НЕ относится к перечню того, что указано в ФЗ о коммерческой тайне, кроме того ограничивает работника в законных правах, таких как право на обращение в суд, поскольку при иске о, например, взыскании зарплаты, величину этой самой зарплаты придется огласить третьим лицам, то есть нарушить договор.
Достаточно известный факт с легконаходимой судебной практикой по нему.
Касательно остального, то у такому работодателю просто не надо идти, коль он ставит свое величество выше законов. Тут стоит отсылка к обозначенной в статье книге.
Эта информация НЕ относится к перечню того, что указано в ФЗ о коммерческой тайне, кроме того ограничивает работника в законных правах, таких как право на обращение в суд, поскольку при иске о, например, взыскании зарплаты, величину этой самой зарплаты придется огласить третьим лицам, то есть нарушить договор.
Достаточно известный факт с легконаходимой судебной практикой по нему.
Касательно остального, то у такому работодателю просто не надо идти, коль он ставит свое величество выше законов. Тут стоит отсылка к обозначенной в статье книге.
Кто спорит-то, простите, с тем что в РФ этот пункт не имеет законной силы (во многих других странах, что характерно — имеет)? Я говорю про то что это часть контракта. Не хотите его заключать — пожалуйста не заключайте. Идите к другому работодателю. Но обман-то работника где Вы в этом увидели или апелляцию работодателя к законодательству? Вы упорно апеллируете к букве закона специфичного для РФ (что вообще говоря сомнительный плюс) тогда как я пытаюсь обратить Ваше внимание на а) целесообразность и практическую пользу таких ограничений и б) то что сотрудник с ними заранее знакомится и добровольно дает на них свое согласие
Прикольная индульгенция для работодателей для подсовывания незаконных контрактов.
Собственно вопрос свелся к тому что важнее для каждого: выгода предприятия любой ценой и плевать на общие законы или все же подпись под незаконным контрактом никакой силы не имеет, поскольку контракт силы не имеет в силу своего противорения с законами.
На мой взгляд, если в контракте есть пункт о рабстве или согласии на опыты по превращению в человеческую многоножку, то подпись под ним ничего не значит. Если для кого-то значит, то выгода явно прощает все.
Собственно вопрос свелся к тому что важнее для каждого: выгода предприятия любой ценой и плевать на общие законы или все же подпись под незаконным контрактом никакой силы не имеет, поскольку контракт силы не имеет в силу своего противорения с законами.
На мой взгляд, если в контракте есть пункт о рабстве или согласии на опыты по превращению в человеческую многоножку, то подпись под ним ничего не значит. Если для кого-то значит, то выгода явно прощает все.
Тут вопрос не в запрете, а в том, какие санкции следуют за его нарушение, законны ли эти санкции.
Например, выше написано: «Если ко мне приходит сотрудник и говорит, что у Пети зарплата выше, будет уволен Петя». Если будет уволен на законных основаниях, со всеми причитающимися выплатами, то почему бы и нет. А если без выходного пособия, то такой договор — способ в любой момент не платить по желанию левой пятки.
Например, выше написано: «Если ко мне приходит сотрудник и говорит, что у Пети зарплата выше, будет уволен Петя». Если будет уволен на законных основаниях, со всеми причитающимися выплатами, то почему бы и нет. А если без выходного пособия, то такой договор — способ в любой момент не платить по желанию левой пятки.
Ответ на вопрос «почему бы и нет» опять-таки лежит в ТК РФ, где есть очень точный перечень причин для увольнения.
На мой взгляд, обсуждаемый пункт при его наличии в договоре уже говорит, что работодатель оставляет место для маневра своей левой пятки и строит отношения работник-руководитель на обмане.
На мой взгляд, обсуждаемый пункт при его наличии в договоре уже говорит, что работодатель оставляет место для маневра своей левой пятки и строит отношения работник-руководитель на обмане.
Ответ на вопрос «почему бы и нет» опять-таки лежит в ТК РФ, где есть очень точный перечень причин для увольнения
Разве работодатель не может уволить людей по причине сокращения штатного расписания? Разумеется, с выплатой средней з/п за 3 месяца. Все хитрованы не хотят выполнять последний пункт, но если он выполнен, то что не так?
Может, но после он не может нанять новых. Сокращение штатного расписания, так сокращение.
Есть пути обойти и это, конечно.
Проводят же тренинги для HR-директоров по темам «как уволить беременную сотрудницу или сотрудницу в декретном отпуске». Но все эти случаи прекрасно подходят к названию обозначенной в статье книги.
Есть пути обойти и это, конечно.
Проводят же тренинги для HR-директоров по темам «как уволить беременную сотрудницу или сотрудницу в декретном отпуске». Но все эти случаи прекрасно подходят к названию обозначенной в статье книги.
Разве частота изменения бизнес-планов (и вместе с ним, штатного расписания) ограничена законом?
Хотел бы я такой ошейник на особо креативных менеджеров. А то прибегают с горящими глазами: срочно! всё бросаем и делаем новую идею. Через 3 дня — ну, сделал, принимай. А они — а, отстань, сейчас голова другим занята. Сами как-нибудь внедряйте…
Хотел бы я такой ошейник на особо креативных менеджеров. А то прибегают с горящими глазами: срочно! всё бросаем и делаем новую идею. Через 3 дня — ну, сделал, принимай. А они — а, отстань, сейчас голова другим занята. Сами как-нибудь внедряйте…
Дабы не быть голословным про вранье:
вот выдержка из hh странички одной компании, где, как понятно по нашей с вами беседе, подобные хитрости в договоре — это нормально:
«Работа в соответствии с ТК РФ в стабильно развивающейся компании.»
вот выдержка из hh странички одной компании, где, как понятно по нашей с вами беседе, подобные хитрости в договоре — это нормально:
«Работа в соответствии с ТК РФ в стабильно развивающейся компании.»
Если Вас интересуют юридические детали, то контракт там единый для всей компании (а компания, на минуточку, американская), оригинал его составляется на английском языке и в нём есть пункт о том что национальное законодательство (российское в данном случае) в случает расхождений с контрактом имеет приоритет. И таки да, ТК в компании соблюдается — в отличие от всех остальных российских компаний в которых мне (и моей жене) доводилось работать. В числе прочего я не знаю ни одного человека которого как либо карали бы за разглашение этой информации. Тем не менее о зп в компании говорить не принято в силу добровольного согласия на то сотрудников. Потому что компания блин нормальная. Я Вас читаю и такое впечатление складывается, что с нормальными компаниями Вы никогда не имели дело. Полное ощущение того что Вы видите в работодателе персонажа который спит и видит как бы Вас, эм, обмануть. А я вот пишу сейчас эти строки из Норвегии куда поехал на конференцию. Я здесь раньше никогда не был, мне интересно здесь побывать и я попросил остаться здесь на лишнюю пару дней за свой счет (компания оплачивает дорогу и мое пребывание в дни конференции, остальное оплачиваю я). И никаких проблем. Компания не обязана была мне этого разрешать в рамках всех Ваших ТК РФ, но мне без малейших возражений пошли навстречу. Нафига мне вот это дословное следование букве закона если я работаю в компании в которой отношения лучше чем это регламентирует законодательство? К примеру по ТК РФ я имею право на отгул только если отработал ранее выходной день и дата отгула определяется заранее на усмотрение работодателя. У нас это не так. Нужен отгул — просто берешь его. Без необходимости предварительной отработки (и в пределах 5 дней в год вообще без необходимости отработки). Даже в тот же день. Плохо себя чувствуешь — позвонил, предупредил, в пределах трех дней больничного не нужно. Рабочий график свободный хотя опять же ТК РФ подразумевает от сотрудника несколько иное поведение. Идея понятна? Компания идет навстречу сотрудникам, сотрудники идут навстречу компании. И получается действительно здорово. А Вы конечно можете искать свою идеальную контору где работодатель нагибает своих сотрудников по ТК РФ в рамках которого опоздание на 10 минут на работу есть достаточный повод для написания объяснительной, а неоднократное опоздание — достаточный повод для увольнения, а работники в ответ организуют итальянскую забастовку, но стоит ли?
Вот этого я никак не понимаю, почему так неистово стараются держать зарплату в секрете и всем говорят «никогда и никому не говори, сколько ты получаешь, это ай-яй-яй».
Я за оклады, которые позволяют не думать о премии, а думать о проекте. Ну и общегодовой перфоманс бонус всей компании :)
или заменить людей с которыми даже здороваться не хочется
Отмечу, что у хорошего руководителя никогда не бывает не запланированных уходов сотрудников. Поэтому он даёт задание HR службе заранее и у него, к моменту ухода специалиста, уже есть несколько претендентов на освобождающееся место.
Это как, простите? Под словосочетанием «несколько претендентов на освобождающееся место.» имеется в виду «есть несколько e-mail'ов человек, с которыми вроде бы можно поговорить на эту тему»? Или HR натурально при работающем сотруднике приглашает людей собеседоваться на его место и втирает им «Наш начальник считает, что через некоторое время у нас появится вакансия. Как вы отнесетесь к тому, чтобы через неопределенное время начать работать у нас? Только, пожалуйста, говорите шепотом и выходите через черный вход, вас никто не должен здесь видеть»
Возможно я не ясно выразился. У меня сейчас живой пример — один сотрудник при проведении квартального ревью предупредил, что он отработает в компании ещё год и уйдёт (так сложились обстоятельства). Он же сам участвует в собеседованиях с кандидатами на его должность. И это норма — предупреждать заранее о своём уходе, помогать в подборе и передавать свои знания преемнику. Так должно быть, если у компании нормальные отношения с сотрудниками. Если же у вас сотрудник пишет просто заявление и уходит через две недели или вообще уходит в отпуск с последующим увольнением, то значит надо что-то менять.
Это говорит об исключительной добродетельности сотрудника, а не о том какой у него хороший или плохой руководитель.
Тут две стороны медали: то, что сотрудники предупреждают заранее об уходе — это очень мило ( с их стороны ), но как только руководитель начнет считать про себя «Я такой хороший, меня все любят и об уходе предупредят за год» реальность жестоко разобьет его розовые очки. Случаи разные бывают — вот прямо сейчас гендиректор «Вымпелкома» уволился одним днем. И никого-то он об этом не предупреждал, мне кажется.
Тут две стороны медали: то, что сотрудники предупреждают заранее об уходе — это очень мило ( с их стороны ), но как только руководитель начнет считать про себя «Я такой хороший, меня все любят и об уходе предупредят за год» реальность жестоко разобьет его розовые очки. Случаи разные бывают — вот прямо сейчас гендиректор «Вымпелкома» уволился одним днем. И никого-то он об этом не предупреждал, мне кажется.
Уже третья статья, читая обсуждения которой, подчёркиваешь не меньше, чем из самой статьи.
И несколько грустно видеть, как аудитория, которая была на мегамозге в лице менеджеров, управленцев и просто предпринимателей размывается
огромным числом специалистов со сформировавшимся взглядом и очень сложно рассматривающих любые управленческие вопросы. Особенно много таких среди молодых специалистов, у которых ещё много сил, времени и желания сделать мир лучше и твёрдо делящие мир на белое и чёрное.
Конечно, это несколько неправильно делить всех на слои, но взгляд на систему с точки зрения участника системы и управляющего системой всегда будет различный ( специалист- менеджер).
Лично я — сторонник сбалансированного, прозрачного и справедливого управления.У меня есть своя точка зрения и я буду её отстаивать, при этом оставаясь в готовности внести в неё изменения при наличии аргументов или информации, доказывающих, что я не прав в целом. И одновременно признаю, что существует множество других также правильных точек зрения — они просто ДРУГИЕ.
По KPI — как их не называй, они есть у всех. Но они могут быть разным — хорошими или плохими, простыми или сложными, но они всегда должны быть SMART.
А если о показателях в целом — всегда должно быть больше 3-4 показателей, оценивающих РАЗНОЕ и по разному ( т.е. смешение объективных и субъективных, статистических и экспертных и т.д. ).
НУ и не стоит забывать — что для каждой компании и цели, есть разные средства: не стоит забивать отбойным молотком один гвоздь, как и не стоит использовать лопату там, где нужен карьерный экскаватор.
И несколько грустно видеть, как аудитория, которая была на мегамозге в лице менеджеров, управленцев и просто предпринимателей размывается
огромным числом специалистов со сформировавшимся взглядом и очень сложно рассматривающих любые управленческие вопросы. Особенно много таких среди молодых специалистов, у которых ещё много сил, времени и желания сделать мир лучше и твёрдо делящие мир на белое и чёрное.
Конечно, это несколько неправильно делить всех на слои, но взгляд на систему с точки зрения участника системы и управляющего системой всегда будет различный ( специалист- менеджер).
Лично я — сторонник сбалансированного, прозрачного и справедливого управления.У меня есть своя точка зрения и я буду её отстаивать, при этом оставаясь в готовности внести в неё изменения при наличии аргументов или информации, доказывающих, что я не прав в целом. И одновременно признаю, что существует множество других также правильных точек зрения — они просто ДРУГИЕ.
По KPI — как их не называй, они есть у всех. Но они могут быть разным — хорошими или плохими, простыми или сложными, но они всегда должны быть SMART.
А если о показателях в целом — всегда должно быть больше 3-4 показателей, оценивающих РАЗНОЕ и по разному ( т.е. смешение объективных и субъективных, статистических и экспертных и т.д. ).
НУ и не стоит забывать — что для каждой компании и цели, есть разные средства: не стоит забивать отбойным молотком один гвоздь, как и не стоит использовать лопату там, где нужен карьерный экскаватор.
Хотя вру, очки розовые подразбились, после написания этой статьи ))) Карму кто-то слил. Даже плюсовать комментарии не могу теперь )))
Я не удивлен. У меня сложилось впечатление, что вы не в IT работаете, а бюрократичной гос-конторе… которая может сколько угодно пилить какой-нить код, только IT от этого она не станет.
«Начну с того, что это нормально, когда человек уходит из компании через 3-4-5 лет работы» — Я бы начал с того что в IT нормально если разработчик меняет работу раз в год. Если он конечно не lead.
Самое главное, что некоторые идеи из статьи верны, но наверно вам надо было в начале написать, что эти советы только валидны только для компаний которые управляют более чем 200 разрабочиками. Для малых отделов и современных методик разработки они ну никак не пригодны.
«Начну с того, что это нормально, когда человек уходит из компании через 3-4-5 лет работы» — Я бы начал с того что в IT нормально если разработчик меняет работу раз в год. Если он конечно не lead.
Самое главное, что некоторые идеи из статьи верны, но наверно вам надо было в начале написать, что эти советы только валидны только для компаний которые управляют более чем 200 разрабочиками. Для малых отделов и современных методик разработки они ну никак не пригодны.
Моё личное мнение — это не нормально, если разработчик меняет работу раз в год. Пример из личного опыта: 3 месяца уходит, чтобы новый девелопер прошёл процесс передачи знаний и влился в компанию, примерно через 4-6 месяцев он начинает выдавать улучшения в существующих системах и коде, а не просто делать рутинные задачи. Получается, что если такой девелопер уйдёт через год, то продуктивно он поработает максимум 8 месяцев, и надо снова начинать всю эту карусель. Если знать стоимость подбора нормального девелопера, так мало кто будет делать из более-менее серьёзных игроков, таких «попрыгунчиков» просто не берут в штат. Сколько угодно пилить код моему подразделению инхаус-разработки никак нельзя, они выдают новый функционал владельцам каждые 10 дней (скрам не даёт сильно расслабиться :-) )
Может джуниор и вливается 3 месяца. Или человек который вообще не знаком с процессами в IT или работал раньше с другими языками. Но любой senior developer, который работал в смежной сфере адаптируется за 2 недели. А то и меньше. Но вы говорите про своих «серьезных игроков», не знаю какие именно вы имеете ввиду компании, но очевидно совершенно не те которые знаю я. А я знаком и с Российским с Европейским рынком IT. Так что еще раз бы вам советовал учитывать, что то что вы считаете за истину существует только в вашей песочнице, а других все по другому. Только тимбилдинг будет полезен возможно всем. (кроме отметившихся выше интровертов, которые могут просто на него не ходить).
Я вам искренне завидую :-) Ваша категоричность в суждениях не особо к месту — не находите? Я везде указываю, что всё что пишу — моё личное мнение. Вы можете написать Свою статью, о Вашем опыте, когда адаптируются за две недели и меньше и опыте удержания сотрудников в компании. Мне, да и многим другим, это было бы очень интересно. Основная цель моей статьи — донести до начинающих менеджеров необходимость работать со своими сотрудниками, слышать их и быть лидерами команд, а не «боссами и начальниками». Мериться у кого опыт больше я не очень жажду, не красиво это и ни к чему. Все вроде взрослые люди.
Наоборот, джуниор вливается быстрее. Потому что к нему меньше ожиданий.
А чтобы писать «сеньорский» код, нужно знать не только язык, платформу и фреймворк, но и специфику предметной области и все вспомогательные классы/функции проекта.
Иначе будут вопросы:
— Почему ты этот метод заново написал, когда у нас уже есть метод для этого, причём у тебя только частный случай?
— Зачем ты вычисляешь это значение, когда оно у нас для скорости использования уже закешировано вон в той таблице?
А чтобы писать «сеньорский» код, нужно знать не только язык, платформу и фреймворк, но и специфику предметной области и все вспомогательные классы/функции проекта.
Иначе будут вопросы:
— Почему ты этот метод заново написал, когда у нас уже есть метод для этого, причём у тебя только частный случай?
— Зачем ты вычисляешь это значение, когда оно у нас для скорости использования уже закешировано вон в той таблице?
1. Если по вашей организации кода тяжело найти какой-то метод — вопрос не к сеньору ;) Нормальный кстати спросит как минимум.
2. Очень спорный тезис. Если оно закешировано -то это должно быть в описании задачи(обсуждении) и опять же — можно просто спросить.
Все сводится к коммуникациям и просто наввыку анализа чужого кода :)
2. Очень спорный тезис. Если оно закешировано -то это должно быть в описании задачи(обсуждении) и опять же — можно просто спросить.
Все сводится к коммуникациям и просто наввыку анализа чужого кода :)
Я думаю, всё зависит от сложности проекта/продукта и длительности его истории.
В старом продукте с длинной историей — сотрудник хорошо, если через 6 месяцев сможет выйти на уровень своего предшественника.
А в случае типовых задач/проектов с длительностью 3-6 месяцев да, всё будет быстро.
PS. При наборе специалистов, я также, как и it_manager обращаю внимание на то, сколько человек работал на предыдущих местах работы. Если он каждый год меняет работу и это были не стартапы, то с высокой долей вероятности, я его не возьму — т.к. считаю, что реальная отдача сотрудника начинается примерно ко второму году его работы в компании.
В старом продукте с длинной историей — сотрудник хорошо, если через 6 месяцев сможет выйти на уровень своего предшественника.
А в случае типовых задач/проектов с длительностью 3-6 месяцев да, всё будет быстро.
PS. При наборе специалистов, я также, как и it_manager обращаю внимание на то, сколько человек работал на предыдущих местах работы. Если он каждый год меняет работу и это были не стартапы, то с высокой долей вероятности, я его не возьму — т.к. считаю, что реальная отдача сотрудника начинается примерно ко второму году его работы в компании.
Если по вашей организации кода тяжело найти какой-то метод — вопрос не к сеньору
MSDN отлично организован, но чтобы хорошо знать WinAPI, нужно прочитать хотя бы заголовки всех разделов, чтобы знать что в принципе есть, и какими способами что делается. И это документация, код читать подряд «от и до» тяжелее
Нормальный кстати спросит как минимум
Есть ли у вас в проекте ф-ция валидации e-mail?
Есть ли у вас в проекте ф-ция расчёта суммы контракта с учётом скидок клиента на его дисконт-карте?
Есть ли у вас…
Если оно закешировано -то это должно быть в описании задачи(обсуждении)
В тасках вы пишете требования или способ реализации с точностью до обращения к каждому кешу? Заодно и алгоритмы напишем, чтобы вдруг за N2 не стали делать, если есть способ N·logN
и опять же — можно просто спросить.
Нельзя, потому что заранее не предугадаешь что может быть где закешировано (только при наличии опыта в конкретно в этом проекте понимаешь, что это поле используется часто, поэтому неплохо бы считать отдельно). Или это превратиться в постоянные вопросы с 99%-м ответом «нет».
Валидация — поиск по Validate(or,es) + Email не? :) — найдет либо коммент либо сам валидатор…
При корректном именовании вполне реально найти. Ну на самый край спросить. В большинстве случаев это будет пачка стратегий или вариаций на тему.
С инструментами типа решарпер можно искать дубликаты достаточно быстро.
А чем плохо требование на алгоритмическую сложность? Это между прочим может быть критичное требование.
Кеш вообще то проговаривается, так как это может иметь огромное значение. Например нужен ли прогрев кеша, как будет использоваться кеширование, где будет кеш, стратегия инвалидации и тд.
При наличии опыта можно запускать инструмент для анализа производительности, смотреть hot paths и делать выводы.
У меня просто как раз пример лида перед глазами. Меньше чем за месяц разобрался в приличном по размерам codebase. Периодически спрашивает высокоуровневые вопросы или обсуждает варианты реализации. С джуниором года через 3 можно было бы что-то обсуждать так же. Хотя зависит от проекта, задач и качества кода. Я повидал ужасов и возможно при очень низком качестве кода джуниору будет проще с чистого листа, чем человеку, который будет осознавать весь тлен и тщетность бытия :)))
Пока не убедили в общем:)
При корректном именовании вполне реально найти. Ну на самый край спросить. В большинстве случаев это будет пачка стратегий или вариаций на тему.
С инструментами типа решарпер можно искать дубликаты достаточно быстро.
А чем плохо требование на алгоритмическую сложность? Это между прочим может быть критичное требование.
Кеш вообще то проговаривается, так как это может иметь огромное значение. Например нужен ли прогрев кеша, как будет использоваться кеширование, где будет кеш, стратегия инвалидации и тд.
При наличии опыта можно запускать инструмент для анализа производительности, смотреть hot paths и делать выводы.
У меня просто как раз пример лида перед глазами. Меньше чем за месяц разобрался в приличном по размерам codebase. Периодически спрашивает высокоуровневые вопросы или обсуждает варианты реализации. С джуниором года через 3 можно было бы что-то обсуждать так же. Хотя зависит от проекта, задач и качества кода. Я повидал ужасов и возможно при очень низком качестве кода джуниору будет проще с чистого листа, чем человеку, который будет осознавать весь тлен и тщетность бытия :)))
Пока не убедили в общем:)
WinApi кстати не совсем корректный пример. Таких codebase в большинстве проектов нет даже близко. Плюс на таких проектах команды занимаются изолированной частью проекта, соответственно их скоуп ограничен, а вопросы можно найти в доке, если вы документируете то что вы делаете и ваш проект структурирован так, что бы было понятно что и где искать, или спросить в слаке/групчате в скайпе :)
Это мои субъективные ощущения. Если у вас есть пример, спорить конечно бессмысленно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как сделать, чтобы они не уходили