Комментарии 81
А куда отнести «в прошлый раз оптимизировал, так хоть бы спасибо сказали, не говоря о премии — чего опять буду выделяться?»?
У меня было еще веселей — указывал на недостатки, в ответ начальство оправдывалось, что все норм. В итоге вся команда разбежалась.
А иногда руководство начинает обрастать снизу теми, кто также оправдывается — образуется дибилоидно-костный спрут-кальмар и чем ниже по иерархии, тем вранья больше и больше. Конечно такой организм работает на 0% КПД, и его в один прекрасный момент казнят — но до этого времени сколько талантов можно загубить, согласен :-)
А потом еще нач-во удивляется, что люди уходят не смотря на предложение повысить зарплату. А потом по тихому гадит в отзыв прошлого места работы «сотрудник ушел, когда предложили бОльшие деньги».
Кстати важная тема, да. Обидно. Но это начальство было такое значит дохлое — актеры, играющие роль что все хорошо и втихоря кормящие монстра человеческими жертвоприношениями. Сильный человек никогда не выстрелит в спину.
Страшный преподаватель, валящий студентов на экзамене по информатике оказался плохим менеджером. Просто редко появлялся в зоне доступности. «Валить» подчиненных кстати, видимо стеснялся, — они не студенты, трясущиеся за оценку, ответить-таки могут, а очереди на работу не стоит.
Ну да ладно. Наболело, извините. Теперь у него идет набор на «неоплачиваемую летнюю стажировку».
Ну да ладно. Наболело, извините. Теперь у него идет набор на «неоплачиваемую летнюю стажировку».
Валить легче, даже удовольствие можно получать от этого — начитался стандартов по ночам и вперед. Гораздо труднее с командой достичь цели, когда каждый день несет новые риски, когда люди впадают в панику и временную ненависть к тебе, и когда нужно сделать часть работы самостоятельно, чтобы успеть в срок :-)
сделать часть работы самостоятельно
Доделал, когда все ушли. Сейчас выкатят на рынок.
А когда народ был — так не было времени на code review даже. Всего на моей памяти за два года их было 2-3 и то, я был их инициатором («посмотри, это не гадость ли я накодил»)
Впрочем, качество кода и полученного опыта легко оценить в комментариях к моему первому и единственному посту.
Я тоже сталкивался в этому юности с откровенно скотским отношением к разработчикам — особенно в крупных компаниях, не связанных непосредственно с разработкой. Да, возможно там будут платить больше — но отношение к разработчику, который реально является умным человеком, голубой кровью, элитой и мозгами нации — как к дворнику/сантехнику…
Останутся в такой компании профессиональный говнокодеры, причем талантливые — после которых как после получения специальности «гинеколог» страшно к коду и женщинам подходить
Останутся в такой компании профессиональный говнокодеры, причем талантливые — после которых как после получения специальности «гинеколог» страшно к коду и женщинам подходить
Тут даже не проф компания — а кооперация фирмы и вуза, для привлечения студентов к работе. Инновационный проект, на который деньги государство дает немаленькие.
Итого имеем 5 студентов 3-4 курса, для которых это первое место работы и у которых надо стоять за спиной и бить по рукам за плохой код. И это надо делать, чтобы помочь вырасти специалисту.
Но вместо этого — почти постоянное отсутствие рядом с командой. В результате и студенты опыт не получают и проект делают лебедь рак и щука.
Итого имеем 5 студентов 3-4 курса, для которых это первое место работы и у которых надо стоять за спиной и бить по рукам за плохой код. И это надо делать, чтобы помочь вырасти специалисту.
Но вместо этого — почти постоянное отсутствие рядом с командой. В результате и студенты опыт не получают и проект делают лебедь рак и щука.
Да уж. На первое время после ВУЗа нужен коуч, который будет с ребятам постоянно — а не для галочки работать.
Грант получен, зачем напрягаться?
Когда в проектном плане написан первый пункт «разработка документации», срок — два месяца, в графе «результат» — «первая глава методологии ХХХ», в графе средства на первый пункт стоят десятки миллионов — становится не по себе.
Когда в проектном плане написан первый пункт «разработка документации», срок — два месяца, в графе «результат» — «первая глава методологии ХХХ», в графе средства на первый пункт стоят десятки миллионов — становится не по себе.
Ну да, онанизм проектирования… А знаем же, что проектировать более недели очень опасно, требования начинают протухать и рынок и клиенты меняют, причем совершенно объективно, свои требования.
Никакого онанизма, сам такой план один раз делал. Смысл прост: есть сумма субсидии, есть срок, есть план-рыба. Надо взять и максимальную сумму субсидии размазать на весь срок. А после выигрыша финансирования — да хз куда эти деньги идут.
Там этих «разработок документаций», к слову, было на год вперед запланировано. По крайней мере, для студентов этот план не имел статуса руководящего документа. У нас были раз в две недели встречи с представителями заказчика (на которых, к слову нам не давали ничего спросить, говорил только ночальнег), а потом мы туда перестали ездить — ездил только он, о чем там говорилось — хз. Да и задача была рыхлая.
Оценивать работу менеджера снизу неблагодарное занятие. Кто знает какие установки он получил от топов или владельцев (если сам топ).
Согласен, сильно может измотать. Ну так от него зависит, будет от прокси-без-мозгов или все таки возьмет удар на себя, присядет немного от ответственности, и, набравшись достоинства выстроит с коллегами профессиональные, открытые и справедливые отношения.
Я говорил с топом заказчика. Он дал сдержанную оценку «Отсутствие стиля руководства».
Я один раз общался с топом, который пояснил, что назначенные на ключевые посты люди — там останутся навсегда. При том, что это были аморальные, слабые и поразительно бестолковые представители нашей планеты. Знаете почему он их держал? За преданность :-) Я был в шоке и до сих пор не могу понять как можно так ненавидеть людей?
Смотря какая преданность. Если «не сбежит в фирму B потому, что там на 5 тыс р больше», — то это хорошая преданность.
Но и проф качества тоже должны быть.
Но и проф качества тоже должны быть.
Не сбежит, т.к. вряд ли ему там предложат пост директора дирекции по закупке средств гигиены первой необходимости — а скорее всего должность менеджера. Некоторых «слава» и ощущение того, что жизнь состоялась — держит в болоте (жаль, т.к. профессиональный рост давно закончился).
А проф качества такие — нанять, проконтролировать, выжать все до капли, уволить и нагадить в портфолио. Задачи простые, схема работает.
А проф качества такие — нанять, проконтролировать, выжать все до капли, уволить и нагадить в портфолио. Задачи простые, схема работает.
Если «не сбежит в фирму B потому, что там на 5 тыс р больше»
… ему никто не даст. Ну или, как минимум, на руководящую должность не поставят, а для многих власть более значимый стимул чем деньги или саморазвитие. Зачастую в таких фирмах и топы, и владельцы бизнеса тоже могут идти на уменьшение или хотя бы неувеличение прибыли ради власти.
Конкретно этим «руководилам» — никто не даст. Этот критерий перебегания, скорее для обычных людей, несущих полезную нагрузку.
И эти «умеющие быть преданными» (а проще — имеющие тонкий длинный язык цилинрической формы для ...) запросто начнут подгребать под себя созданный вами эффективный бизнес-процесс, а создателя могут попытаться устранить как свидетеля их недальновидности и глупости. Будем осторожны и со снисхождением воспримем это как проявление человеческой слабости :-)
Это скорее исключение из правила. Те, кто имеет язык цилиндрической формы редко, имхо, способны подгрести под себя бизнес (или хотя бы попытаться). Карьеру делать мелкими шажками, основываясь не на профессионализме — да. Рискнуть текущим положением — очень редко. Они стремятся к вознаграждениям, привилегиям, власти, но не к ответственности. Субъективно. А вот слить бизнес конкуренту за очень значимое вознаграждение — на это они способны.
Все таки хорошо, что встречаются Люди — наставники, ведущие себя достойно в подобных ситуациях. На них хочется равняться — в кризисной ситуации, когда все начинает гореть и дымиться, они делят ответственность с подчиненными, пытаются мотивировать коллег и никогда потом не тычат в проявленную тобой слабость. И к ним питаешь уважение всю жизнь.
Жаль, что мне таких не встречалось :( По крайней мере среди непосредственного начальства, а не коллег или топов. Для топов, там где была хотя бы трехуровневая иерархия, я просто был винтиком, назначение которого они может и помнят, и даже «сленговое обозначение» (имя), а вот точное название «по ГОСТу» (ФИО полностью)- нет, но это объяснимо.
Похожее было. Указывал на архитектурные проблемы и к чему они приведут, когда пришло время и все встало, начальство решило не сменить подход а сменило игровой движок. Пришлось уволится.
Ну, я не увольнялся, а, будучи последним работником, аккуратно дотянул до конца окончания договора. И сказал, что продлевать не буду.
Потом еще шутил при встрече: «Привет, сам себе IT директор!».
Позже узнал от него, что архитектурных и иных проблем после 5 студентов осталось дофига — вот что значит «забить болт на code review».
Потом еще шутил при встрече: «Привет, сам себе IT директор!».
Позже узнал от него, что архитектурных и иных проблем после 5 студентов осталось дофига — вот что значит «забить болт на code review».
Обычно делается для своего же спокойствия.
Например, пришла мысль поднять CI, и каждый день она тебя гложет: «Ну как же без build-сервера». Нашёл 2 часа, сделал — гора с плеч.
Например, пришла мысль поднять CI, и каждый день она тебя гложет: «Ну как же без build-сервера». Нашёл 2 часа, сделал — гора с плеч.
Но бывает когда как только сделал важную задачу, ключевую — то не сразу, а может часика через 2 — денька через 2 — возникает видение риска с иной стороны, появляются новые задачи и цели, видишь глубже и дальше — они я думаю даются как прозрение, как награда за то, что предварительно приложил усилие и выложился на полную.
Это всё равно, что вести ещё один проект.
Плюс в том, что сроки не жмут и можно не торопиться.
Минус — не платят ))
Плюс в том, что сроки не жмут и можно не торопиться.
Минус — не платят ))
Уровень ответственности возрастает :-) Помню есть такая пословица: «Ответственность для мужчины, как крылья для орла». Можно попробовать не брать проект на себя (чтобы инициатива была не наказуемой) — а открыто проинформировать о имеющихся открывшихся задачах, рисках, трендах — тоже добавляет эффективности и приносит пользу компании.
Спокойствие — это когда речь идёт о повышения качества. А вот когда о производительности или экономии материальных ресурсов… То тут или любопытство (типа обучение для работодателя за его же счет, только он об этом не знает), или просто желание освободить рабочее время для других дел (тоже без ведома работодателя).
Когда хотят повышения производительности или экономии ресурсов — то разговор имхо один: садимся и рисуем текущий бизнес-процесс ( удивление? :-) ) и рисуем как его будем улучшать и как мерить — что стало лучше. И не включать сверху дурачка. Чтобы без обид, математически и объективно. А если это эмоциональное требование в стиле: «дорогой, мне чего-то не хватает в жизни постоянно» — то искренне сочувствую :-(, видел как-то давно такое, ужас, дикая демотивация и осадок, обостряющийся к утру.
Так в том-то и дело, что начальство не хочет — в лучшем случае для него это экономия на спичках — а хочет перфекционистский ум работника :)
Все эти спички складываются в итоге в коробки и блоки.
Поставил build-сервер и QA больше не бегает раз в день с просьбой «Вась, собери мне версию» (даже если сборка занимает 2 мин.)
Отрефакторил что-то за 2 часа, но потом на 3 последующих доработках сэкономил время.
Поставил build-сервер и QA больше не бегает раз в день с просьбой «Вась, собери мне версию» (даже если сборка занимает 2 мин.)
Отрефакторил что-то за 2 часа, но потом на 3 последующих доработках сэкономил время.
Да, нужно сначала научиться всем считать и анализировать. Чтобы было текущее состояние параметра А, проект по переходу к бизнес-процессу или его модернизации и оценка состояния Б. Все честно и объективно. Проблема, когда сверху включают дурачка — т.к. привыкли говорить сотрудникам что они работают плохо и НЕ ДАЮТ делать хорошо :-) Метод удержания контроля такой — держать людей в вечных неудачниках :-)
Справедливости ради, зачастую некоторые предлагаемые оптимизации невозможно объективно обсчитать. Проще говоря, вроде объективные предложения типа «если наступит такое-то событие, то трата сейчас N рублей и часов нам позволит сэкономить в будущем сэкономить N*M часов и рублей» часто глохнут на попытках оценки вероятности этого события — обычно такие оценки субъективны, в лучшем случае на глобальной статистике основаны.
Ну как нить исхитрится. Я долгое время не понимал, так так и не понял — почему нельзя посчитать эффект от маркетинговой активности и узнать, что работает лучше: радио, тв, интернет-банеры, листовки и т.п. Но верю, что можно — просто не думал в этом направлении. А можете привести пример, интересно подумать.
Можно посчитать эффект постфактум и то достаточно грубо: я лично банально иной раз теряюсь, когда нужно ответить на вопрос «откуда вы о нас узнали?» (даже если список ответов не ограничен и я искренне хочу ответить искренне :) — часто срабатывает эффект достижения критической массы сведений из разнообразных источников в подсознании.
Вот, например, возникла речь в комментах о проектировании, костылях, оптимизациях, рефакторинге (подразумевающем обычно автоматическое тестирование) и т. п., что непосредственно касается качества и производительности кода софтверных продуктов. Хоть на планерках (не люблю слова типа «митинг»), хоть при обсуждении ТЗ непосредственно с заказчиком, хоть при ревьюировании (в любой форме) возникают вопросы функциональной расширяемости и горизонтального масштабирования (или пределов вертикального :). Редко когда можно объективно сказать, что та или иная особенность кода в будущем поможет сильно сэкономить ресурсы, либо, наоборот, приведет к их сильным затратам, которые можно было бы предупредить. В общем, «знал где бы падать — соломку бы подстлал», «знал бы прикуп — жил бы в Сочи» и т. п., но в отличии от прикупа теория вероятностей не работает (да и с ним не очень хорошо: «и тут мне карта как попёрла..)», решении о включении тех или иных фич в код (не путать с фичами продукта — не всегда это синонимы) принимаются чисто по субъективным оценкам вероятностей понадобится или нет.
А чисто конкретный пример из недавней практики, не касающийся даже разработки, а чисто бизнес-процессов — предложил как-то своему давнему «партнеру» (то он мой клиент, то я его) навести хоть-какой-то порядок у него фирме в плане документооборота обного бизнес-процесса — бронирование номеров в мини-отеле. Предложение заключалось в качественном понижении теоретической вероятностью, что один и тот же номер может быть забронирован дважды на разных людей одновременно. Говоря техническим языком, предложил механизм блокировок разделяемого ресурса при начале процесса. Он отказался, аргументируя крайне низкую вероятность коллизии статистическими данными («за почти десять лет ни разу такого не было»). Правда не учел, что у них появился новый механизм бронирования в Интернете, где люди могут жать F5, в надежде что появится свободный номер где-то в городе. Я тоже такой кейс не имел в виду конкретно, но лишь видел теоретическую вероятность. В итоге в начале месяца он потерял одного клиента и оставил в неудовольствии постоянного (даже скидку, которую ему сделали за неудобства, была в разы дешевле того, что он мне заплатил бы за, максимум, 8 часов работы, включая обучение персонала). И всё равно мне заплатил, но уже потеряв деньги.
Вот, например, возникла речь в комментах о проектировании, костылях, оптимизациях, рефакторинге (подразумевающем обычно автоматическое тестирование) и т. п., что непосредственно касается качества и производительности кода софтверных продуктов. Хоть на планерках (не люблю слова типа «митинг»), хоть при обсуждении ТЗ непосредственно с заказчиком, хоть при ревьюировании (в любой форме) возникают вопросы функциональной расширяемости и горизонтального масштабирования (или пределов вертикального :). Редко когда можно объективно сказать, что та или иная особенность кода в будущем поможет сильно сэкономить ресурсы, либо, наоборот, приведет к их сильным затратам, которые можно было бы предупредить. В общем, «знал где бы падать — соломку бы подстлал», «знал бы прикуп — жил бы в Сочи» и т. п., но в отличии от прикупа теория вероятностей не работает (да и с ним не очень хорошо: «и тут мне карта как попёрла..)», решении о включении тех или иных фич в код (не путать с фичами продукта — не всегда это синонимы) принимаются чисто по субъективным оценкам вероятностей понадобится или нет.
А чисто конкретный пример из недавней практики, не касающийся даже разработки, а чисто бизнес-процессов — предложил как-то своему давнему «партнеру» (то он мой клиент, то я его) навести хоть-какой-то порядок у него фирме в плане документооборота обного бизнес-процесса — бронирование номеров в мини-отеле. Предложение заключалось в качественном понижении теоретической вероятностью, что один и тот же номер может быть забронирован дважды на разных людей одновременно. Говоря техническим языком, предложил механизм блокировок разделяемого ресурса при начале процесса. Он отказался, аргументируя крайне низкую вероятность коллизии статистическими данными («за почти десять лет ни разу такого не было»). Правда не учел, что у них появился новый механизм бронирования в Интернете, где люди могут жать F5, в надежде что появится свободный номер где-то в городе. Я тоже такой кейс не имел в виду конкретно, но лишь видел теоретическую вероятность. В итоге в начале месяца он потерял одного клиента и оставил в неудовольствии постоянного (даже скидку, которую ему сделали за неудобства, была в разы дешевле того, что он мне заплатил бы за, максимум, 8 часов работы, включая обучение персонала). И всё равно мне заплатил, но уже потеряв деньги.
Для расширяемости, ну как я делаю обычно:
1) просим немного больше времени на анализ и выкручивание генеталий у экспертов предметной области, чтобы копнуть поглубже, подальше
2) паттерны проектирования. многие созданы были с возможностью расширяемости
3) минимальная иерархия сущностей, лучше один всезнающий медиатор (в нем вся изменяемость)
В общем дайте больше подумать и мы задействуем паттерны. Немного помогает :-)
С проектированием крайних редких случаев есть риск очень сильно в них провалиться и застрять, не решив ключевые фичи и не запустив в короткий срок сначала работающий прототип, а затем проект в паблик. Сейчас вот стало модно в бетах запускать сервисы в сети — хрен с ними с крайними случаями, либо бы выйти быстрее конкурентов и понравится пользователям — главное написать крупно что это БЭТА :-)
1) просим немного больше времени на анализ и выкручивание генеталий у экспертов предметной области, чтобы копнуть поглубже, подальше
2) паттерны проектирования. многие созданы были с возможностью расширяемости
3) минимальная иерархия сущностей, лучше один всезнающий медиатор (в нем вся изменяемость)
В общем дайте больше подумать и мы задействуем паттерны. Немного помогает :-)
С проектированием крайних редких случаев есть риск очень сильно в них провалиться и застрять, не решив ключевые фичи и не запустив в короткий срок сначала работающий прототип, а затем проект в паблик. Сейчас вот стало модно в бетах запускать сервисы в сети — хрен с ними с крайними случаями, либо бы выйти быстрее конкурентов и понравится пользователям — главное написать крупно что это БЭТА :-)
Вот в «дайте нам немного подумать» и заключен камень преткновения. говоришь «прототип (читай — говнокод) я напишу за день/неделю/месяц, но расширять или изменять не по мелочам (в техническом, а не пользовательском смысле) будет сложно, а возможность предусмотреть наиболее вероятные по моему опыту пользовательские изменения займет раза больше времени (и, между строк, ваших денег)».
Мало денег просил значит.
Производительность → качество.
С рабочим временем хуже. Как бы не влетело за то, что процессы улучшал вместо того, чтобы рутиной заниматься.
С рабочим временем хуже. Как бы не влетело за то, что процессы улучшал вместо того, чтобы рутиной заниматься.
Микроменеджмент, когда меряют не по результату, а по процессу — жуткий идиотизм, но к сожалению, распространен. Бывает чрезвычайно невозможно доказывать что ты думал/рисовал/делал схему на стене для визуализации проблемы 3 часа блондинке, делящей одну извилину с школьной подругой — и подозревающей тебя в прожигании рабочего времени.
Рост производительности далеко не всегда означает рост качества. Абстрактный пример — внедрил инкрементальные бэкапы вместо полных. Суммарно гораздо меньше времени стало уходить (и ресурсов на носители), а результат тот же.
Здесь даже не знаю. Я думал о качестве конечного продукта. Когда происходит факап с общей производительностью и в неоптимальные места, ранее не исправленные, начинают срочно вставлять костыли.
Хотя, в принципе, к бекапам это тоже относится. Полный бекап сильнее кладёт сервера, чем инкрементальный
Я имел в виду рост производительности труда, а не продукта (софта и/или железа) :) Производительность продукта — одна из метрик качества труда. Грубо говоря, если продукт сделан по всем стандартам и лучшим практикам, но совершенно неюзабельно тормозит, то это хреновое качество труда.
Все должно быть в меру, без извращений, оптимально. Т.е. не углубляться далеко в совершенствование если есть риск что оно останется как есть еще год. Есть крайность, когда начинают заниматься перфекционизмом 3 месяца и чик, поменялись требования и все на смарту — и смысл был перфекционировать.
Но соглашусь, что код и система в целом не должны «вонять». Это признак приближающейся беды, нужно срочно решать.
Но соглашусь, что код и система в целом не должны «вонять». Это признак приближающейся беды, нужно срочно решать.
Я скорее про бизнес-процессы, а не про код. Тупо видишь, что неоптимально расходуется время сотрудников или ресурсы фирмы. Или локально (по времени) оптимально, но очень велики риски глобально (при проверке или иске) получить большой фэйл, вплоть до лишения свободы (если считать, что за фэйлы убивать перестали).
Постараться может выразить в цифрах, придумать формулу, замерить результат до и после и вывести на графике. Могут не доверять словам, мудрым и правильным — но увидят циферки и согласятся.
Аргументы типа «а чем они тогда будут заниматься?», «этого не может быть никогда, потому что не может быть никогда» или «у меня всё схвачено, ко мне проверка не придёт, по крайней мере без предупреждения заранее» циферками и графиками не прошибаются. И если на незнающих теорвер и матстат ещё хоть как-то можно давить на эмоции, то от знающих часто слышишь вопрос «а откуда ты эту вероятность взял?».
Так нужно продолжать, в этом хитрость — и прокачивать себя до 77 уровня черного эльфа. Оценили, не оценили — опыт достижения результата получен, он дает силы и дерзость в следующий раз, может в другой компании, выстрелить сразу и в десятку.
Как правило, это опыт в лучшем случае смежный с профессией (например, программист по своей инициативе внедряет то, что должен был внедрять системный администратор по указанию менеджмента), а то и вообще в другой области лежащий (программист занимается юридическими или финансовыми вопросами).
Ну да. Постигать мир юникс, C — тоже прокачивает отлично, там дофига копать не перекопать Но если сотрудник вынужден заниматься непрофильной чертовней всякой — то конечно грустно. По опыту многие разработчики хотят стать сначала ведущими, затем руководителями отделов и техдирами — но просто не понимают, что каждый день проведенный с бумажками, отпускными и декретными очень резко отбрасывает назад и квалификация льется сквозь пальцы. И даже получая возможно повышенную зарплату ты фиг устроишься потом как профессионал — и придется вести бои с «чиновниками-актерами» в кадровых агентствах. Хотя есть исключения, конечно, если манагер занимается профразвитием в свободное время вместо семьи.
Копать там, конечно, дофига и даже можно утверждать, что администрирование повышает скилл программирования в целом, но речь не о «вынуждены», а о «хочется не тратить время на фигню всякую, а чисто на программирование», пускай даже речь идёт о нажатии двух клавиш в IDE вместо одной в ОС (или о нажатии одной вместо перевода взгляда на второй монитор).
Никогда не понимал таких разработчиков :) Как мне кажется, что те деньги, что в открытых вакансиях предлагают за должность ведущего/senior'а по сравнению с «обычным»/«миддлом» не стоят того, если эти деньги вопрос не жизни и смерти, а комфорта. Особенно перестал понимать после того как я пару лет поучился на менеджера и прослушал курсы типа «управление персоналом», да и обычная «психология» была на это ориентирована. В отличии от психологии на технической специальности на экономической (пускай, а может знаменательно, что на техноориентированной) нам давали, прежде всего, как эффективно вести переговоры (пускай и неформальные, типа как в курилке разговаривать), как произвести хорошее впечатление как человек (а не как специалист), как использовать чужие слабости, а не как эффективно работать, как не производить плохое впечатление и как стараться компенсировать свои слабости своими сильными сторонами.
Никогда не понимал таких разработчиков :) Как мне кажется, что те деньги, что в открытых вакансиях предлагают за должность ведущего/senior'а по сравнению с «обычным»/«миддлом» не стоят того, если эти деньги вопрос не жизни и смерти, а комфорта. Особенно перестал понимать после того как я пару лет поучился на менеджера и прослушал курсы типа «управление персоналом», да и обычная «психология» была на это ориентирована. В отличии от психологии на технической специальности на экономической (пускай, а может знаменательно, что на техноориентированной) нам давали, прежде всего, как эффективно вести переговоры (пускай и неформальные, типа как в курилке разговаривать), как произвести хорошее впечатление как человек (а не как специалист), как использовать чужие слабости, а не как эффективно работать, как не производить плохое впечатление и как стараться компенсировать свои слабости своими сильными сторонами.
Ну смысл такого подхода в том, что люди оптимизируют именно потому что получают удовольствие от самой оптимизации, а не от внешних стимулов.
Со временем удовольствия это доставляет всё меньше и меньше, а то и конфликты с коллегами возникают по типу «тебе что, больше всего надо? или перед начальством выслуживаешься?».
Ну так разгадка проста — вы безумно много вкалываете, вам за это денег и прочих благ не добавляют,
но при этом утверждаются во мнении, то так же вкалывать должны остальные (с соответствующим ростом нагрузки без добавки печенек),
что приводит к тому, что через полгода все пашут по 14 часов в день без выходных с лишением премий и под окрики, какие они все ничего не успевающие дебилы.
Я не утверждаю, что у вас так, но это очень распространенный паттерн (на котором ваши коллеги могли обжечься у предыдущих работодателей).
Есть работодатели, у которых оптимизировать полезно,
есть — у которых опасно.
но при этом утверждаются во мнении, то так же вкалывать должны остальные (с соответствующим ростом нагрузки без добавки печенек),
что приводит к тому, что через полгода все пашут по 14 часов в день без выходных с лишением премий и под окрики, какие они все ничего не успевающие дебилы.
Я не утверждаю, что у вас так, но это очень распространенный паттерн (на котором ваши коллеги могли обжечься у предыдущих работодателей).
Есть работодатели, у которых оптимизировать полезно,
есть — у которых опасно.
Соглашусь. К сожалению есть слепые компании, которые могут уволить человека за его критику, даже если он сэкономил 30% бюджета в прошлом году внедрив идею. В этих компаниях полезно прокачивать твердость воли и мозоли на нервах — но временно :-)
Разгадка понятна, хотя скорее речь немного о другом процессе — вкалываешь меньше или так же как остальные, а производительность заметно больше других даже для начальства :) Скажем, написал пару скриптиков и благодаря им могу себе позволить уходить домой строго по ТК. Ну или тупо больше делаешь за день.
Что должен делать руководитель? Заниматься рисками, читать новости отрасли, ездить на конференции. Т.е. вся рутина должна быть автоматизирована, систематизирована — занимаешься только рисками и развитием, чтобы эффективнее заниматься рисками :-)
В какой-то мере это можно даже не считать сарказмом. Но вот кто будет это всё автоматизировать и систематизировать, если даже добрым словом не поощрять тех, кто проявил в этом инициативу, чтобы избавиться от своей рутины? Есть подозрение, что многим некоторым руководителям такая инициатива смерти подобна, поскольку по готовым агрегатам от инициативных исполнителей рисками сможет заниматься и вышестоящий руководитель, причем с большей эффективностью для бизнеса в целом.
Так для себя же работаешь в конце концов. Время, потраченное на пользу компании, без выслуживания — именно на пользу бизнеса — вернется наградой и внутренней уверенностью в себе в любой момент жизни.
Ну да. И от того, что растут профессионально и как по критерию ответственности, и приобретая смежные знания. Да и как управленцы тоже, с определенном смысле. Проще будет свое дело развивать потом.
В том-то и дело, что профессионального роста минимум — грубо говоря, мало кого в крупных фирмах интересует твоё умение настроить с нуля тестовый сервер, максимально соответствующий продакшену, а потом, разворачивать одним кликом для разных бранчей. Или умение внедрить TDD на фоне внедрения CI. По крайней мере если претендуешь на должность рядового разработчика и не более, а о своем бизнесе мечтаешь только в ключе как одновременно и инвестор с бизнес-идеей, и рядовой работник, а твое руководство как работника должно быть нанятым и не подозревать, что один из рядовых работников их наниматель :)
Дайте угадаю, вы корпоративные соцсети продаете?
Мы используем подобную корпоративную социальную сеть внутри. Но инструмент — дело десятое и не хотелось бы в личном посте травить читателей маркетинговым булшитом. Скажу честно, пару-тройку лет назад я искренне считал соцсети, а тем более корпоративные соцсети — разновидностью гей-культуры :-) Однако когда увидел какую пользу для прокачки сотрудников приносит открытое пространство и поощрение желание улучшить процессы — с конкретными результатами и внедрениями — офигел и понял, что заблуждался. Главное конечно чтобы был все таки некий контроль уровня тусни — 2-3 менеджера должны показать как это работает и как внедряются идеи, и будет ок.
> если… внедрить корпортал и/или аналог корпоративной социальной сети… тогда сотрудники будут думать как улучшить общее дело
Не думаю так. Где прозрачность, если эта связь будет только в одну сторону?
Думаю, доверие строится на доверительных отношениях. Вы верно пишете, что недоверие начинается с фраз типа «не держим». Но доверие не от портала начинается. Это отношения. Это не процессы и не просто обратная связь, хотя она немного помогает.
Не думаю так. Где прозрачность, если эта связь будет только в одну сторону?
Думаю, доверие строится на доверительных отношениях. Вы верно пишете, что недоверие начинается с фраз типа «не держим». Но доверие не от портала начинается. Это отношения. Это не процессы и не просто обратная связь, хотя она немного помогает.
Согласен полностью. Прозрачность должна быть в обе стороны. Ну вот например я эксалирую риск или проблему или идею и пишу о ней в корпоративном блоге:
— время не вычитается из ЗП :-) а можно же делать так
— в большинстве случаев я получаю обратную связь от коллег
— очень часто, от вышестоящих руководителей
— выводим резюме и, чтобы прелюдия завершилась результатом, а не просто слова ради слов — фиксируем достигнутый результат в конце топика
— у нас нет кнопки «не понравилось», есть только «понравилось» или можно не нажимать лайк :-)
Портал это лишь инструмент, можно с таким же успехом на доске рисовать и проводить планерки стоя.
— время не вычитается из ЗП :-) а можно же делать так
— в большинстве случаев я получаю обратную связь от коллег
— очень часто, от вышестоящих руководителей
— выводим резюме и, чтобы прелюдия завершилась результатом, а не просто слова ради слов — фиксируем достигнутый результат в конце топика
— у нас нет кнопки «не понравилось», есть только «понравилось» или можно не нажимать лайк :-)
Портал это лишь инструмент, можно с таким же успехом на доске рисовать и проводить планерки стоя.
nice try
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бизнес-процессы и мотивация — обгоняя время