Слушайте). Иногда «рискованное поведение» — это возвращаться домой поздно. При этом я как потенциальный объект насилия не готова всю жизнь соблюдать превентивную меру «перестать жить свою жизнь и лишний раз из дома не выходить, чтобы вдруг чего не произошло». Или перестать носить красивую одежду тоже не готова из-за того, что кто-то при виде меня в красивой одежде ну просто не может сдержать себя. >в вопросах безопасности лучше использовать превентивные меры, а не рассуждать постфактум "кто виноват?" Потому что как-то это в виктимблейдинг превращается незаметно (или заметно?): «сама превентивные меры не соблюдала!».
>другие леденящие душу подробности об искусстве управления людьми намного умней тебя
Думаю, люди намного умнее меня заранее подумали бы, что хабр читают люди разного уровня развития — и если писать сравнительную характеристику «умнее», то нужно быть уверенным, что ты самый умный на свете. В такой убежденности есть много зон роста, поздравляю вас!
Сходила по ссылке, после нее 5 постов подряд — анализ, сколько рейтинга набрали те или иные посты на хабре. В искусстве управлять людьми не разобралась )
Ну с одной стороны, да: кто несет ответственность (в том числе за финансовые потери), тот и принимает решение. А еще может оказаться так, что исполнитель не видит каких-то ограничений, потому что не смотрит на ситуацию «сверху». Часто управленцы принимают решение не по принципу «чтобы стало чотко и хорошо», а по принципу «как-нибудь решить проблему и не уронить все вокруг, что можно случайно уронить».
Но с другой стороны, если ты среди подчиненных считаешь себя самым умным — зачем тебе подчиненные :)
У вас какие-то очень нежные разработчики, которым эмоции клиента работать не дают.
выглядит так, будто «потерпи некоторое дерьмо, а то че как неженка» для вас является нормой. А в реальности работать там, где приходится что-то терпеть и не налажены конструктивные отношения — стремно, и не нужно на такое соглашаться. И если не соглашаешься — ты обычный и адекватный, а не неженка.
люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом не способны осознавать свои ошибки в силу низкого уровня своей квалификации
Гендиру нужно было решить какую-то проблему, вот и решал. Но было недостаточно знаний, чтобы понимать, как такие проблемы уже решались и какая вообще есть практика решения проблем: поэтому начал изобретать свой велосипед.
А теперь фокусы: есть некомпетентный человек, которому нужно решить проблему, но возможно он решает ее неоптимальным способом.
А есть компетентные люди — инженеры.
Задача компетентных людей: понятно и корректно объяснить, как лучше решать проблему. А не соглашаться на всё, что предложат люди которым нужно решать проблему, а потом переживать, что «ващет по-другому нужно было сделать, я это всегда знал, но молчал!»
Имею ввиду менеджеров проектов / продукта — руководитель команды разработки может выполнять широкий спектр обязанностей. И понятно, что если «лезть в код и давать фидбэк» прямая обязанность, то руководитель разработчика должен это делать.
А когда в код лезет руководитель, но не разработчика а проекта (которому нужно чтобы проект был сделан, а не разработчик научен) то возникают проблемы.
смешивание этих двух ролей как раз таки много конфликтов и создае
верно, лучше не смешивать — на эти роли нужны люди с разным стеком компетенций
В статье обе эти проблемы: и что говорит, и что таск под это не планируется. А еще (в случае, если после решения вопроса разработчик не покидает чат) есть проблема, что пошатнуть мотивацию исполнителя на проекте очень просто, если оставлять ему доступ к нефильтрованной информации от клиента.
это самый верный способ довольно быстро потерять или клиента или разработчика
не прям САМЫЙ, но да, способ довольно эффективный (если цель — кого-то потерять)
при этом давайте будем реалистами, иногда нужно показать разработчика клиенту — когда клиент «шарит» и им проще напрямую договориться. Или наоборот, когда клиент не шарит и из-за этого робеет перед авторитетом разработчика.
Но эффективнее это делать на встречах, а не в общих чатах: в чатах решаются коммуникационные задачи, и лучше бы это делать ПМу
В этот раз дело даже наверное не в отсутствии общего слэка, а в стратегическом решении: договорились, что раз доверия нет, то и помочь мы не сможем: это будет какая-то помощь через сопротивление, очень неправильная.
Большинство трагедий было в голове клиента и наших косяков было объективно мало (а те, что были, можно было разрешить разговорами, если бы мы обсуждали что-то, а не «я сказал — вы делайте»), поэтому решение не работать — самое экологичное, что можно было сделать по отношению друг к другу.
Да, советы местами очевидные. Но практика показывает, что вот это вот все понятно на берегу, а когда на тебя клиент орет и отжимает твою команду, то сходу выкинуть установку «клиент всегда прав» сложновато. Вот мемес на эту тему.
А кто-то не знает, что клиент не всегда прав.
А кто-то не в курсе, как дорого стоит рекрутинг.
А кто-то что-то еще.
А потом все поувольнялись, а менеджер даже не в курсе, что именно пошло не так и что ответственный за увольнения именно он, а не «клиент сложный попался» или «а че такого взяли вообще».
Про общий слак писала выше: мы верим в людей и в 99% случаев они это оправдывают. Часто такой метод все упрощает. Конкретно в этом кейсе общий слак не случился, к счастью.
Про метод «поиск виновного» тоже согласна. Это нужно делать очень аккуратно и четко видеть грань, где ты охлаждаешь клиента, а где уже подставляешь коллегу. Я эту грань всегда видела.
Про п.3 неистово плюсую. Было давно, молодые и горячие — конвертировали эту ошибку в опыт.
Есть небольшое упражнение, которое показывают вначале каждого тренинга про переговоры. Ставят друг напротив друга двоих и дают задачу сдвинуть оппонента с места. Побеждает всегда не тот, кто сильнее давит, а тот, кто делает шаг назад.
Когда клиент орет и называет вас мудаками, то с точки зрения спортивных переговоров вести с ним диалог нельзя: он на эмоциях, доказать ему, что на самом деле никто не мудак, невозможно — никакие доводы не воспринимаются.
Если продолжать давить, что мы молодцы, то клиент разбесится еще больше: с его-то точки зрения это не так, поэтому вы не только мудаки, но еще и врете. Допускать такого нельзя.
Поэтому я делала «шаг назад» и говорила:
— так, а почему вы считаете, что мы мудаки? Потому что нашли в первой сборке баги, которых не было в отчете от QA? Вы правы, это неприятно. Несмотря на то, что в первых сборках обычны баги, нашему QA стоит вносить в отчет даже мелкие недочеты. Мы с ним серьезно поговорим, чтобы такого больше не повторялось.
С точки зрения клиента это было жертвоприношение. Репутация команды при этом не страдала, никто никого не опускал.
НО! Есть важное примечание, которое нужно было добавить в статью:
1. Когда я подыгрывала и делала жертвоприношение, разговор всегда шел о поведении наших сотрудников, а не об их компетенциях или личности.
Хорошо: да, наш сотрудник не внес баг, в следующий раз стоит вносить даже такие баги. Я с ним поговорю, чтобы вносил.
Плохо: у нас невнимательный тестировщик, поэтому не внес.
2. Как только разговор переходил на личности, ни о каких «шагах назад» разговор даже не шел. Пример:
— вы что там, считать вообще не умеете?
— выражайтесь корректно, пожалуйста. Мы умеем считать. Если вы будете допускать такие выражения, то у нас не получится сотрудничества.
Вывод: если внедрять этот совет, то нужно быть внимательным и думать головой. Но если думать, то он классно работает.
По-моему, это должен быть первый пункт по умолчанию, если, конечно, вы не «дружите компаниями».
Иногда подход с общим чатом действительно здорово облегчает задачу: мы пилим мобильные приложения для e-commerce, и в таких проектах часто бэкэнд на стороне клиента, да и логика фильтраций-каталогов-корзин у многих мудреная, и лишнее звено искажения информации в виде менеджера порсто ни к чему.
Сейчас мы проверяем клиентов на старте и понимаем, что наши клиенты классные и коммуникацию с командой им доверить можно.
общение только по электронной почте, по крайней мере, с новыми или такими проблемными клиентами
Здесь соглашусь в пункте «логировать изменения чертовски важно». У нас на уровне процессов выстроено так: коммуникация в чате (потому что это быстрее в разы), но обязательное дублирование договоренностей по email или в basecamp. И в договоре прописано, что изменения фиксируются там. С любыми клиентами, иначе никак.
Слушайте). Иногда «рискованное поведение» — это возвращаться домой поздно. При этом я как потенциальный объект насилия не готова всю жизнь соблюдать превентивную меру «перестать жить свою жизнь и лишний раз из дома не выходить, чтобы вдруг чего не произошло». Или перестать носить красивую одежду тоже не готова из-за того, что кто-то при виде меня в красивой одежде ну просто не может сдержать себя.
>в вопросах безопасности лучше использовать превентивные меры, а не рассуждать постфактум "кто виноват?"
Потому что как-то это в виктимблейдинг превращается незаметно (или заметно?): «сама превентивные меры не соблюдала!».
>другие леденящие душу подробности об искусстве управления людьми намного умней тебя
Думаю, люди намного умнее меня заранее подумали бы, что хабр читают люди разного уровня развития — и если писать сравнительную характеристику «умнее», то нужно быть уверенным, что ты самый умный на свете. В такой убежденности есть много зон роста, поздравляю вас!
Сходила по ссылке, после нее 5 постов подряд — анализ, сколько рейтинга набрали те или иные посты на хабре. В искусстве управлять людьми не разобралась )
Ну есть же другие люди вокруг, кроме клиентов. :)
и
считайте, повезло! По вашему описанию ситуации кажется, что хуже было бы, если бы оставили и заставили еще какое-то время это терпеть
Ну с одной стороны, да: кто несет ответственность (в том числе за финансовые потери), тот и принимает решение. А еще может оказаться так, что исполнитель не видит каких-то ограничений, потому что не смотрит на ситуацию «сверху». Часто управленцы принимают решение не по принципу «чтобы стало чотко и хорошо», а по принципу «как-нибудь решить проблему и не уронить все вокруг, что можно случайно уронить».
Но с другой стороны, если ты среди подчиненных считаешь себя самым умным — зачем тебе подчиненные :)
К тому же вы сами пишете, что скилл коммуникации ОТ синьора.
А мидлам и джунам нафига без таких скиллов в чатах сидеть? И чем в этот момент занят менеджер, если команде приходится разруливать коммуникацию?
я не ставила минус, но эта фраза
выглядит так, будто «потерпи некоторое дерьмо, а то че как неженка» для вас является нормой. А в реальности работать там, где приходится что-то терпеть и не налажены конструктивные отношения — стремно, и не нужно на такое соглашаться. И если не соглашаешься — ты обычный и адекватный, а не неженка.
ну это по классике Даннинга-Крюгера:
Гендиру нужно было решить какую-то проблему, вот и решал. Но было недостаточно знаний, чтобы понимать, как такие проблемы уже решались и какая вообще есть практика решения проблем: поэтому начал изобретать свой велосипед.
А теперь фокусы: есть некомпетентный человек, которому нужно решить проблему, но возможно он решает ее неоптимальным способом.
А есть компетентные люди — инженеры.
Задача компетентных людей: понятно и корректно объяснить, как лучше решать проблему. А не соглашаться на всё, что предложат люди которым нужно решать проблему, а потом переживать, что «ващет по-другому нужно было сделать, я это всегда знал, но молчал!»
Обняла! Держитесь там (от них подальше)
Имею ввиду менеджеров проектов / продукта — руководитель команды разработки может выполнять широкий спектр обязанностей. И понятно, что если «лезть в код и давать фидбэк» прямая обязанность, то руководитель разработчика должен это делать.
А когда в код лезет руководитель, но не разработчика а проекта (которому нужно чтобы проект был сделан, а не разработчик научен) то возникают проблемы.
верно, лучше не смешивать — на эти роли нужны люди с разным стеком компетенций
Интересны ваши аргументы. Я как руководитель менеджмента нанимаю менеджеров только без технического бэкграунда.
АААААААААА!!!!!!!!!!!
В статье обе эти проблемы: и что говорит, и что таск под это не планируется. А еще (в случае, если после решения вопроса разработчик не покидает чат) есть проблема, что пошатнуть мотивацию исполнителя на проекте очень просто, если оставлять ему доступ к нефильтрованной информации от клиента.
не прям САМЫЙ, но да, способ довольно эффективный (если цель — кого-то потерять)
при этом давайте будем реалистами, иногда нужно показать разработчика клиенту — когда клиент «шарит» и им проще напрямую договориться. Или наоборот, когда клиент не шарит и из-за этого робеет перед авторитетом разработчика.
Но эффективнее это делать на встречах, а не в общих чатах: в чатах решаются коммуникационные задачи, и лучше бы это делать ПМу
Большинство трагедий было в голове клиента и наших косяков было объективно мало (а те, что были, можно было разрешить разговорами, если бы мы обсуждали что-то, а не «я сказал — вы делайте»), поэтому решение не работать — самое экологичное, что можно было сделать по отношению друг к другу.
А кто-то не знает, что клиент не всегда прав.
А кто-то не в курсе, как дорого стоит рекрутинг.
А кто-то что-то еще.
А потом все поувольнялись, а менеджер даже не в курсе, что именно пошло не так и что ответственный за увольнения именно он, а не «клиент сложный попался» или «а че такого взяли вообще».
Про общий слак писала выше: мы верим в людей и в 99% случаев они это оправдывают. Часто такой метод все упрощает. Конкретно в этом кейсе общий слак не случился, к счастью.
Про метод «поиск виновного» тоже согласна. Это нужно делать очень аккуратно и четко видеть грань, где ты охлаждаешь клиента, а где уже подставляешь коллегу. Я эту грань всегда видела.
Про п.3 неистово плюсую. Было давно, молодые и горячие — конвертировали эту ошибку в опыт.
Когда клиент орет и называет вас мудаками, то с точки зрения спортивных переговоров вести с ним диалог нельзя: он на эмоциях, доказать ему, что на самом деле никто не мудак, невозможно — никакие доводы не воспринимаются.
Если продолжать давить, что мы молодцы, то клиент разбесится еще больше: с его-то точки зрения это не так, поэтому вы не только мудаки, но еще и врете. Допускать такого нельзя.
Поэтому я делала «шаг назад» и говорила:
— так, а почему вы считаете, что мы мудаки? Потому что нашли в первой сборке баги, которых не было в отчете от QA? Вы правы, это неприятно. Несмотря на то, что в первых сборках обычны баги, нашему QA стоит вносить в отчет даже мелкие недочеты. Мы с ним серьезно поговорим, чтобы такого больше не повторялось.
С точки зрения клиента это было жертвоприношение. Репутация команды при этом не страдала, никто никого не опускал.
НО! Есть важное примечание, которое нужно было добавить в статью:
1. Когда я подыгрывала и делала жертвоприношение, разговор всегда шел о поведении наших сотрудников, а не об их компетенциях или личности.
Хорошо: да, наш сотрудник не внес баг, в следующий раз стоит вносить даже такие баги. Я с ним поговорю, чтобы вносил.
Плохо: у нас невнимательный тестировщик, поэтому не внес.
2. Как только разговор переходил на личности, ни о каких «шагах назад» разговор даже не шел. Пример:
— вы что там, считать вообще не умеете?
— выражайтесь корректно, пожалуйста. Мы умеем считать. Если вы будете допускать такие выражения, то у нас не получится сотрудничества.
Вывод: если внедрять этот совет, то нужно быть внимательным и думать головой. Но если думать, то он классно работает.
Иногда подход с общим чатом действительно здорово облегчает задачу: мы пилим мобильные приложения для e-commerce, и в таких проектах часто бэкэнд на стороне клиента, да и логика фильтраций-каталогов-корзин у многих мудреная, и лишнее звено искажения информации в виде менеджера порсто ни к чему.
Сейчас мы проверяем клиентов на старте и понимаем, что наши клиенты классные и коммуникацию с командой им доверить можно.
Здесь соглашусь в пункте «логировать изменения чертовски важно». У нас на уровне процессов выстроено так: коммуникация в чате (потому что это быстрее в разы), но обязательное дублирование договоренностей по email или в basecamp. И в договоре прописано, что изменения фиксируются там. С любыми клиентами, иначе никак.
Больше так не делайте.