Разработчик приходит в компанию для удовлетворения собственных интересов, для того, чтобы зарабатывать деньги и повышать за счёт этого качество своей жизни, для удовлетворения своих потребностей, а также профессионального роста. Если человек приходит ради войны — ему действительно не место на этой позиции.
Вы правы в том, что никакой ситуации win-win не может быть, если сотрудник относится к работодателю как к эксплуататору. Контакт в этом случае наладить действительно не представляется возможным. Любое продвижение к взаимовыгодному сотрудничеству должно быть двусторонним. Если уж и пришлось работать с такими токсичными и недальновидными разработчиками, как Вы описали, то расставаться с ними нужно немедленно и без сожалений, ведь они одновременно и тормозят самых талантливых, и готовы затянуть в своих липких сетях на дно весь коллектив.
А почему Вы считаете, что мы должны прийти к одинаковым выводам, если я с Вами не согласен, о чем и написал? В продолжении дискуссии на тему психотипа разработчиков смысла не вижу.
Предлагаю сойтись на том, что мы просто по-разному смотрим на вопрос :) Я со своей стороны считаю, что разработчики НЕ являются носителями «шизоидного» склада мышления, а любая профессиональная деформация, если она и присутствует, не всегда затрагивает аспект коммуникации.
Как я и писал, каждая из практик призвана решить целый спектр проблем, а не одну конкретную задачу, в этом Вы, безусловно, правы и я благодарю Вас за то, что упомянули и альтернативные сложности. Но!
От стереотипов
традиционно программирование было (и во много остается) вотчиной людей с особым складом ума, шизоидным
давно следует отказаться наравне с гендерными предрассудками, как от не соответствующих действительности и оскорбительных. В IT работают разные люди: интроверты и экстраверты, носители абсолютно разных поведенческих и психологических паттернов, представители разных социальных групп, командные игроки и индивидуалисты-одиночки, люди с разными, лежащими не только в профессиональной сфере, интересами.
Для бизнеса на первом месте всегда будет стоять цель извлечения прибыли. Какими пользоваться для этого инструментами управления — зависит и от сферы деятельности, и от личности собственников/инвесторов, и от большого количества других факторов. И какие бы средства ни были задействованы, цель одна — получение M рублей с N вложенных. Однако, опытный руководитель понимает, что личная заинтересованность и разумная инициатива на местах позволит зарабатывать больше, а тратить — меньше (за счет отсутствия «текучки» — найм квалифицированного сотрудника обходится в кругленькую сумму, повышения продуктивности сотрудников, их большей лояльности и т.д.). И это будет ситуация win-win, при которой все будут только в плюсе.
Если же говорить об описанной Вами ситуации, когда инструмент используется не совсем верно, то проблема, говоря иносказательно, не в молотке, а в том, кто его держит, начинает заниматься микроменеджментом, вводить странные kpi, и творить прочее «зло». Но так бывает, увы.
Мне крайне лестны Ваши слова о том, будто бы я пытаюсь кого-либо обмануть или выдать тиранию за выгодную сделку, ведь это означает лишь то, что я действительно сумел показать проблему с другой стороны, а в этом и была моя цель. Но я не выступаю в роли «адвоката дьявола».
В жизни бывают разные ситуации, однако отношение к руководству (Вы даже взяли это слово в кавычки) как к врагу, которому нужно обязательно «трезветь» лично я нахожу не вполне уместным. Я не вижу необходимости без крайней нужды ни возводить, ни рушить баррикады, основываясь лишь на делении по принципу «свой-чужой».
Спасибо за Ваш отзыв. Взращивание ответственности сотрудников — тот аспект, которым нельзя пренебрегать. Разработчик (а мы говорим именно о них) конечно же должен понимать свою значимость в рамках проекта и компании, от этого будут расти его удовлетворенность работой и продуктивность. Я не говорю, что эта цель — единственная или основная, но с точки зрения бизнеса ее достижение немаловажно.
Что касается ненависти или любви, то этот вопрос исключительно индивидуален и зависит не от самого факта использования тех или иных инструментов, а от конкретной ситуации на конкретных местах. Я намеренно не даю оценок, а предлагаю как критику, так и слова защиты в пользу каждого пункта.
И, простите за второй комментарий подряд, добавлю: успешное управление — и есть то, при котором сотрудники верят, что решения, нужные руководству, они принимают сами, так как "управление невозможно". Это прекрасно и для сотрудников, и для бизнеса, и быть таким руководителем — высший пилотаж. На что, собственно, практики из гибких методологий и нацелены.
Благодарю Вас за отзыв. Вопросы "абсолютной честности" и мнимой "горизонтальности" управления я хотел бы как раз поднять во второй статье цикла — насколько они необходимы, действительно ли честность двусторонняя, а горизонтальность — реальная, и какие проблемы они призваны решить. Никакого шаманизма, все практики — от наличия необходимости решать реальные "боли".
Благодарю за Ваш развёрнутый ответ. Ваши результаты впечатляют! Однако приведённые Вами цифры относятся к глобальным достижениям компании, а не к "самомотивации" линейных сотрудников, поэтому в контексте этого треда практической ценности не имеют.
Относительно корпоративной культуры — абсолютно с Вами согласен, образ компании и соответствующий ему стиль поведения сотрудников складывается из мелочей.
Уверен, что и эта статья обязательно сыграет свою роль и как элемент Вашего позиционирования, и как информация к размышлению для Ваших будущих разработчиков :)
Могли бы Вы объяснить подробнее как навязаное сотруднику ведение подобного лога может быть положительно связано с мотивацией? Могли бы Вы привести конкретные метрики или описать конкретные ситуации из Вашего опыта, когда описанная практика позволяла сотруднику "самомотивироваться"?
Плюс элемент корпоративной культуры.
Правильно ли я понимаю, что Ваша корпоративная культура определяет подобные описанной процедуры как ценность?
А мне особенно "понравились" тезисы про то, что руководитель может смотреть опубликованныеюй сотрудником список дел, а члены команды должны смотреть на списки друг друга и самомотивироваться. Да здравствует микроменеджмент, круговая порука и имитация деятельности!
Я не очень понимаю, почему вы думаете, что стоить умозрительную модель двух баров, различающихся только одной деталью не корректно.
Я считаю это некорректным, потому что при A/B тестировании веб-проекта невозможно представить себе две площадки, абсолютно идентичные по посещаемости, популярности, с одинаковой упоминаемостью в интернете и идентичной аудиторией. A/B тестирование — это про изменение состояния одного, в нашем случае, бара, пожалуйста, не вводите людей в заблуждение.
Случай с баром ну очень надуманный, более того, совершенно некорректно интерпретирует саму идею A/B тестов. При измерении влияния изолированного фактора необходимо полностью соблюдать принцип идентичности остальных факторов. То есть, если говорить, например, о ранжировании, то классический A/B тест предполагает не открытие двух абсолютно одинаковых площадок, а смену алгоритма выдачи для конкретного посетителя в случайном порядке. Если говорить Вашим языком, то в одном и том же баре в одно и то же время первому посетителю мы будем предлагать налить пепси, а второму — колу. Опыт нетфликса применим лишь для узкого спектра гипотез, заточен под конкретный процесс и именно поэтому даёт потрясающий результат в конкретном контексте. Копировать опыт "больших дядь" — не всегда хорошая идея.
Если говорить о работе именно линейного менеджера, а в моем комментарии речь идёт именно о нем, то его задачей как раз и является описанное Вами как "ошибки". Именно он и должен тянуть, организовывать, мотивировать, включаться, пахать, это и есть его работа. И деньги ему платят как раз за тот самый bus factor, иными словами, за степень ответственности. А если помечтать, то, конечно, хорошо полностью посвятить себя "стратегическим целям" и поплевывать в потолок пока двое из ларца вкалывают. Но так не бывает.
Разработчик приходит в компанию для удовлетворения собственных интересов, для того, чтобы зарабатывать деньги и повышать за счёт этого качество своей жизни, для удовлетворения своих потребностей, а также профессионального роста. Если человек приходит ради войны — ему действительно не место на этой позиции.
А почему Вы считаете, что мы должны прийти к одинаковым выводам, если я с Вами не согласен, о чем и написал? В продолжении дискуссии на тему психотипа разработчиков смысла не вижу.
От стереотипов
давно следует отказаться наравне с гендерными предрассудками, как от не соответствующих действительности и оскорбительных. В IT работают разные люди: интроверты и экстраверты, носители абсолютно разных поведенческих и психологических паттернов, представители разных социальных групп, командные игроки и индивидуалисты-одиночки, люди с разными, лежащими не только в профессиональной сфере, интересами.
Если же говорить об описанной Вами ситуации, когда инструмент используется не совсем верно, то проблема, говоря иносказательно, не в молотке, а в том, кто его держит, начинает заниматься микроменеджментом, вводить странные kpi, и творить прочее «зло». Но так бывает, увы.
Что касается ненависти или любви, то этот вопрос исключительно индивидуален и зависит не от самого факта использования тех или иных инструментов, а от конкретной ситуации на конкретных местах. Я намеренно не даю оценок, а предлагаю как критику, так и слова защиты в пользу каждого пункта.
И, простите за второй комментарий подряд, добавлю: успешное управление — и есть то, при котором сотрудники верят, что решения, нужные руководству, они принимают сами, так как "управление невозможно". Это прекрасно и для сотрудников, и для бизнеса, и быть таким руководителем — высший пилотаж. На что, собственно, практики из гибких методологий и нацелены.
Благодарю Вас за отзыв. Вопросы "абсолютной честности" и мнимой "горизонтальности" управления я хотел бы как раз поднять во второй статье цикла — насколько они необходимы, действительно ли честность двусторонняя, а горизонтальность — реальная, и какие проблемы они призваны решить. Никакого шаманизма, все практики — от наличия необходимости решать реальные "боли".
Благодарю за Ваш развёрнутый ответ. Ваши результаты впечатляют! Однако приведённые Вами цифры относятся к глобальным достижениям компании, а не к "самомотивации" линейных сотрудников, поэтому в контексте этого треда практической ценности не имеют.
Относительно корпоративной культуры — абсолютно с Вами согласен, образ компании и соответствующий ему стиль поведения сотрудников складывается из мелочей.
Уверен, что и эта статья обязательно сыграет свою роль и как элемент Вашего позиционирования, и как информация к размышлению для Ваших будущих разработчиков :)
В Ваших словах чувствуется опыт! :)
Могли бы Вы объяснить подробнее как навязаное сотруднику ведение подобного лога может быть положительно связано с мотивацией? Могли бы Вы привести конкретные метрики или описать конкретные ситуации из Вашего опыта, когда описанная практика позволяла сотруднику "самомотивироваться"?
Правильно ли я понимаю, что Ваша корпоративная культура определяет подобные описанной процедуры как ценность?
А мне особенно "понравились" тезисы про то, что руководитель может смотреть опубликованныеюй сотрудником список дел, а члены команды должны смотреть на списки друг друга и самомотивироваться. Да здравствует микроменеджмент, круговая порука и имитация деятельности!
Я считаю это некорректным, потому что при A/B тестировании веб-проекта невозможно представить себе две площадки, абсолютно идентичные по посещаемости, популярности, с одинаковой упоминаемостью в интернете и идентичной аудиторией. A/B тестирование — это про изменение состояния одного, в нашем случае, бара, пожалуйста, не вводите людей в заблуждение.
"Этот материал мог вызвать противоречивые чувства", как заметило НЛО. Да, вызвал.
Случай с баром ну очень надуманный, более того, совершенно некорректно интерпретирует саму идею A/B тестов. При измерении влияния изолированного фактора необходимо полностью соблюдать принцип идентичности остальных факторов. То есть, если говорить, например, о ранжировании, то классический A/B тест предполагает не открытие двух абсолютно одинаковых площадок, а смену алгоритма выдачи для конкретного посетителя в случайном порядке. Если говорить Вашим языком, то в одном и том же баре в одно и то же время первому посетителю мы будем предлагать налить пепси, а второму — колу. Опыт нетфликса применим лишь для узкого спектра гипотез, заточен под конкретный процесс и именно поэтому даёт потрясающий результат в конкретном контексте. Копировать опыт "больших дядь" — не всегда хорошая идея.
Я как раз и пишу о том, что управление удалённой командой выходит за рамки банального "дробить задачи, делегировать, контролировать результат".
Если говорить о работе именно линейного менеджера, а в моем комментарии речь идёт именно о нем, то его задачей как раз и является описанное Вами как "ошибки". Именно он и должен тянуть, организовывать, мотивировать, включаться, пахать, это и есть его работа. И деньги ему платят как раз за тот самый bus factor, иными словами, за степень ответственности. А если помечтать, то, конечно, хорошо полностью посвятить себя "стратегическим целям" и поплевывать в потолок пока двое из ларца вкалывают. Но так не бывает.