Нам так активно навязывают эгоизм по отношению к целям компании, что получасовая задержка на работе становится одолжением.
Если такая задержка является «ожиданием» начальства на каждый день — Это ЭГОИЗМ по отношению к сотрудникам и их целям.
Работа превратилась в проституцию, т.е. продажу своих услуг, а не создание ценности.
Я продаю компании свои знания, умения и вермя. Если компания не может использовать мои услуги для создания ценности — это проблемы компании.
Надо добавить что если я занимаю руководящую должность — то в мои обязанности входит максимизировать «производство» ценности, и тогда это моя проблема.
Проходит время и дауншифтеры возвращаются, потому что осознают, что работа создана не для денег, а жизнь — не для отдыха. У нас в крови желание создать что-либо ценное. Ведь так и начинался наш путь в ИТ. Без денег, но с огромной мотивацией создать великий продукт.
Полностью не согласен.
Работа — всегда — чтобы получить деньги. Исключения — если у тебя уже денег больше чем надо тебе и твоей семье и тебе хочется заняться чем-то для души. И это не зависит от того — владелец ты или наемный рабочий.
Жизнь — уж точно не ради работы. Тут каждый для себя решает что ему в жизни важно и для чего он живет. Лично я — ради своих детей и семьи.
Запретить разговоры о зарплате. Благодаря этому, мы избежали лишних недовольств. Когда сотрудники знают, сколько зарабатывают коллеги, становится сложно избежать следующих вопросов: «Почему он зарабатывает больше, а ушел вчера на полчаса раньше?». Может это и правда, а может, он работал все выходные. В любом случае, такие вещи только вредят коллективу.
Запретить вы конечно можете — но все равно все будут это обсуждать.
Может проще сделать более прозрачную систему оплаты труда? Тогда и вопросов и обсуждений будет меньше. Но нет — тут надо думать. Запретить — думать не надо!
Клиент и не должен делать удобно разработчику.
Разработчик должен доходчиво объяснить клиенту зачем надо выделять время не рефакторинг, а не просто сказать, что надо ХХХ часов, чтобы мне стало проще поддерживать эту программу.
Приятно видеть, что есть достаточное количество ИТ-руководителей, считающих, что ITIL — это не панацея.
Ни ITIL, ни COBIT, ни <любое другое> не является панацеей — главное применять их с умом и понимать что и зачем, а не потому что так написано в этой книжке/документе.
Сам давал комментарий и также комментарии давали мне.
Очень сильно зависит:
от личного отношения к обратной связи и от желания давать ее другм
от культуры обратной связи в компании
Лично мне обратная связь помогала и помогает — я сам прошу людей, с кем я плотно работаю, давать ее мне, независимо от того требует это компания или нет. Причем прошу давать как «что и как мне стоит продолжать делать», так и «что и как мне стоит прекратить делать».
Как и любой другой инструмент обратную связь надо использовать по назначению.
Вместо Jira можно использовать TargetProcess, Trello
Вместо Confluence — нужно смотреть как именно вы сейсам ее используете, тогда можно будет что-то порекомендовать.
В колоде покера — карты с цифрами (вот это поворот!), которые обозначают часы: ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.
В данном случае цифры какраз обозначают относительную оценку, а не абсолютную, да тем более в часах.
Наиболее часто в покере планирования встречается/используется последовательность чисел Фибоначчи.
Вполне реальная ситуация.
я сам раньше тратил на дорогу по 3,5 часа в одну сторону.
Сейчас 1 час в одну сторону. Стал тратить на 5 часов в день меньше.
2. АУТ хочет выполнить ТОЧНО обозначенный участок работы (это к развитию инфраструктуры, заинтересован или нет?) — дадите АУТ задачу спланировать развитие на 3-5-10 лет — будет Вам и «развитие» (понятно, что работу НУЖНО оплачивать и в этом случае стоимость будет дороже — но ведь «развитие»?)
Основное момент развития для целей бизнеса, а цели могут и будут меняться. Поэтому спланировать развитие инфраструктуры на 3-5-10 лет невозможно.
3. ни один АУТ не хочет выполнить работу «спустя рукава» — ведь смысл АУТа в том, что он делает КАЧЕСТВЕННО и надеется на долгосрочное сотрудничество.
Сильно зависит от вашего вклада в доход АУТа. Очень часто для небольших компаний «Качество» заканчивается сразу после оплаты.
Кроме того зачастую пронятие «Качество» нигде не прописано. Кто будет проверять качетсов и поддерживаемость/расширяемость кода приложения? сам АУТ? Хорошо если заказчик понимает что именно он хочет и может это сфорулировать в виде требований (например указать какие именно параметры для него критичны и договориться с АУТ об SLA на них).
Безусловно есть и удачные примеры перевода ИТ на аутсорс и экономии при этом.
Лично мне пока не посчастливилось встретить такие примеры.
Кроме того, в период перехода на АУТ придется платить как АУТ так и внутренней команде. Об этом как-то тоже умалчивается.
8) Аутсорсинговая компания заинтересована в проектах оплачиваемых по ТМ — как результат в большинстве случаев сроки и бюджеты сильно превышены.
9) Каждый ваш чих и пожелаение == дополнительные затраты.
Кроме того, почему-то никто не упоминает про поддержку приложения/системы, разработанной аутсорсинговой компанией — либо это отдельный бюджет, либо это внутренняя поддержка. Если последняя — очень часто качество кода не позволяет внесение изменений малой кровью, выбранные технологии требуют привелечения определенных специалистов, что не помогает сократить расходы, а наоборот приводит к их росту.
10) Аутсорсер не заинтересован в развитии инфраструктуры для целей вашего бизнеса. Все изменения == дополнительный бюджет.
Так что не все так однозначно при выборе аутсорсинговых компаний. Ведь не просто так многие компании, отдавшие в свое время ИТ или его часть на аутсорс, сейчас активно возвращают все отданое обратно под свое крыло. ИТ должно быть партнером бизнеса (если не является основым видом деятельности компании), а как можно быть партнером, если любое изменения для помощи бизнесу несер незапланированные расходы.
Я инженер, не моя забота думать о бизнесе, это работа менеджеров
Думать о бизнесе — это задача каждого сотрудника, а не только менеджеров.
Вы как инжинер должны предложить оптимальное по срокам, затратам и результату решение задачи, которая пришла к вам из бизнеса. Если вы будете думать только о том что вам интересно, то для бизнеса это будет не всегда лучшим решением и скорее всего бизнес с вами расстанется.
Методы контроля постоянно менялись — начиная от контроля времени взятия обращения в работу, и заканчивая внедрением крайнего срока, планового срока, и последующей «закруткой гаек».
Метрики и должны периодически меняться/пересматриваться, так как:
1. Метрики должны быть нацелены на то что важно для компани в данный момент. Скорость назначения на админа — меряем скорость назначения, скорость закрытия заявки — меряем скорость, количество заявок — меряем количество и т.д.
2. Скажи как оценивается/изменяется моя работа, я сделаю все чтобы эта метрика было всегда отличная, наплевав на реальное качество. Всегда сотрудники будут подгонять процессы под метрики.
наказания за просрочки
Может лучше сделать премирование за хорошее качество, скорость и т.д.?
Пользователей обязали звонить только на единый телефон службы поддержки
и это правильно. Менее хорошее решение — писать в СервисДеск на почту (тотже ServiceDeskPlus умеет это из коробки).
Проекты домов будут отличаться только спецификой реальзации. Нотации описания данных проектов будут абсолютно одинаковы: Чертежи, сметы и т.д. Или вы считаете что для каждого индивидуального проекта дома будут изобретены новые правила выполнения чертежей и смет?
Поэтому вопрос по нотации и вызывает столько вопросов.
Согласен.
Но если компания ставит мне задачи, которые не создают ценности — это проблема компании.
Если такая задержка является «ожиданием» начальства на каждый день — Это ЭГОИЗМ по отношению к сотрудникам и их целям.
Я продаю компании свои знания, умения и вермя. Если компания не может использовать мои услуги для создания ценности — это проблемы компании.
Надо добавить что если я занимаю руководящую должность — то в мои обязанности входит максимизировать «производство» ценности, и тогда это моя проблема.
Полностью не согласен.
Работа — всегда — чтобы получить деньги. Исключения — если у тебя уже денег больше чем надо тебе и твоей семье и тебе хочется заняться чем-то для души. И это не зависит от того — владелец ты или наемный рабочий.
Жизнь — уж точно не ради работы. Тут каждый для себя решает что ему в жизни важно и для чего он живет. Лично я — ради своих детей и семьи.
Запретить вы конечно можете — но все равно все будут это обсуждать.
Может проще сделать более прозрачную систему оплаты труда? Тогда и вопросов и обсуждений будет меньше. Но нет — тут надо думать. Запретить — думать не надо!
Клиент и не должен делать удобно разработчику.
Разработчик должен доходчиво объяснить клиенту зачем надо выделять время не рефакторинг, а не просто сказать, что надо ХХХ часов, чтобы мне стало проще поддерживать эту программу.
Ни ITIL, ни COBIT, ни <любое другое> не является панацеей — главное применять их с умом и понимать что и зачем, а не потому что так написано в этой книжке/документе.
Очень сильно зависит:
Лично мне обратная связь помогала и помогает — я сам прошу людей, с кем я плотно работаю, давать ее мне, независимо от того требует это компания или нет. Причем прошу давать как «что и как мне стоит продолжать делать», так и «что и как мне стоит прекратить делать».
Как и любой другой инструмент обратную связь надо использовать по назначению.
Это будет работать только для сотрудников напрямую влияющих на оборот и прибыль.
Практически весь бэк-офис сюда не попадает.
Вместо Confluence — нужно смотреть как именно вы сейсам ее используете, тогда можно будет что-то порекомендовать.
В данном случае цифры какраз обозначают относительную оценку, а не абсолютную, да тем более в часах.
Наиболее часто в покере планирования встречается/используется последовательность чисел Фибоначчи.
Жил в одном подмосковье, ездил в другое через Москву.
Потом из самой Москвы в подмосковье, стало на пол часа быстрее в каждую сторону.
я сам раньше тратил на дорогу по 3,5 часа в одну сторону.
Сейчас 1 час в одну сторону. Стал тратить на 5 часов в день меньше.
Основное момент развития для целей бизнеса, а цели могут и будут меняться. Поэтому спланировать развитие инфраструктуры на 3-5-10 лет невозможно.
Сильно зависит от вашего вклада в доход АУТа. Очень часто для небольших компаний «Качество» заканчивается сразу после оплаты.
Кроме того зачастую пронятие «Качество» нигде не прописано. Кто будет проверять качетсов и поддерживаемость/расширяемость кода приложения? сам АУТ? Хорошо если заказчик понимает что именно он хочет и может это сфорулировать в виде требований (например указать какие именно параметры для него критичны и договориться с АУТ об SLA на них).
Безусловно есть и удачные примеры перевода ИТ на аутсорс и экономии при этом.
Лично мне пока не посчастливилось встретить такие примеры.
Кроме того, в период перехода на АУТ придется платить как АУТ так и внутренней команде. Об этом как-то тоже умалчивается.
9) Каждый ваш чих и пожелаение == дополнительные затраты.
Кроме того, почему-то никто не упоминает про поддержку приложения/системы, разработанной аутсорсинговой компанией — либо это отдельный бюджет, либо это внутренняя поддержка. Если последняя — очень часто качество кода не позволяет внесение изменений малой кровью, выбранные технологии требуют привелечения определенных специалистов, что не помогает сократить расходы, а наоборот приводит к их росту.
10) Аутсорсер не заинтересован в развитии инфраструктуры для целей вашего бизнеса. Все изменения == дополнительный бюджет.
Так что не все так однозначно при выборе аутсорсинговых компаний. Ведь не просто так многие компании, отдавшие в свое время ИТ или его часть на аутсорс, сейчас активно возвращают все отданое обратно под свое крыло. ИТ должно быть партнером бизнеса (если не является основым видом деятельности компании), а как можно быть партнером, если любое изменения для помощи бизнесу несер незапланированные расходы.
Думать о бизнесе — это задача каждого сотрудника, а не только менеджеров.
Вы как инжинер должны предложить оптимальное по срокам, затратам и результату решение задачи, которая пришла к вам из бизнеса. Если вы будете думать только о том что вам интересно, то для бизнеса это будет не всегда лучшим решением и скорее всего бизнес с вами расстанется.
Однако также это может быть показателем, что работать вам придется и в 2 часа ночи и достаточно часто.
Метрики и должны периодически меняться/пересматриваться, так как:
1. Метрики должны быть нацелены на то что важно для компани в данный момент. Скорость назначения на админа — меряем скорость назначения, скорость закрытия заявки — меряем скорость, количество заявок — меряем количество и т.д.
2. Скажи как оценивается/изменяется моя работа, я сделаю все чтобы эта метрика было всегда отличная, наплевав на реальное качество. Всегда сотрудники будут подгонять процессы под метрики.
Может лучше сделать премирование за хорошее качество, скорость и т.д.?
и это правильно. Менее хорошее решение — писать в СервисДеск на почту (тотже ServiceDeskPlus умеет это из коробки).
Поэтому вопрос по нотации и вызывает столько вопросов.
Релиз может включать задачи на несколько спринтов. Это логический набор новых фич или исправлений.