От автора
Тема противоречивая и есть огромное количество разработчиков и менеджеров, которые не задумываются про правила и способы коммуникации друг между другом, а тем более про коммуникацию разработчиков и клиентов.
Но для меня и моих команд подобные барьеры преодолевались (и не раз) и давали отличные результаты, поэтому не могу не поделиться успешным опытом:
Видел статью о том, как подружить кошку с собакой. Лайфхак от мамкиных бихевиористов:
«Положить собаку на бок и к ее спине спиной приложить кошку. Они не будут видеть друг друга, а только чувствовать запах. Такое упражнение поможет вызвать доверие у животных. Начинайте гладить обеих под расслабляющую музыку.»
Решение годное для нишевого interspecies threesome, наверное. Попробовал — чуть не лишился глаза и кошки.
Примерно такие же потери и чувства у меня вызывает вопрос знакомства «бизнеса» и «разработки».
Но в этом контексте мой кейс менее травмоопасен. Я считаю, что знакомить бизнес и разработку нужно дозированно и ненавязчиво.
Часто у разработчика нет даже поверхностного понимания вашего бизнеса или бизнеса клиента. И тогда у него включается инструкция:
Шаг 1. Прийти и потребовать переписать все на RUST.
Шаг 2. Выгореть, так как вы не будете давать переписать все на RUST.
Так почему же разработчик не хочет понимать ваш бизнес?
Цель у любого бизнеса одна — принести пользу другим людям. За эту цель платят фиатными деньгами и социальным капиталом.
Мой опыт говорит о том, что разработчик часто не видит пользы, которую приносит другим людям.
Поэтому ему сложно оценить свой вклад — он видит только код и деньги за этот код.
Соответственно, его мотивация (переписать все на RUST) основана на «писать топовый код», а не «выпускать фичи (синоним «приносить пользу») для пользователей».
Обычно в фирмах есть разные отделы: маркетинг, тех-поддержка, аналитика, продажи, стратегия. А вдалеке от всех, существует полу-автономная резервация под названием «отдел разработки», с которыми общаются через специального дипломата-переводчика (PM, Team Lead).
На практике не принято допускать разработчика к клиенту или к бизнесу. Сегрегация, изоляция разработчиков от бизнес процессов не позволяет им шире понимать задачи. Иногда это оправдано, иногда нет.
Вот именно такой апартеид отделяет разработчиков от тех, кому они приносят пользу. Со временем разработчики все больше уходят от бизнес реальности в страну чистой разработки. Которая часто игнорирует простые человеческие радости и боли.
Чтобы ваши разработчики не превратились в аутичных специалистов, говорящих на смеси матана и Haskell, постепенно знакомьте их с клиентами, с бизнесом. Важно, чтобы разработчик время от времени слышал напрямую от заказчика «спасибо, это же огнина!» и «ну епт, это никуда не годится».
(Тут что-то еще про доверие, разумную автономию, здоровый микроклимат в команде хотел написать. Но сегодня без сентиментальности, в другой раз.)
У меня это получилось так:
Важно отметить! Я всегда против, чтобы кто-то, кроме ответственного человека, мог ставить задачи разработчикам напрямую, но пункты выше не противоречат этому правилу.
Все это, несомненно, происходит в рабочие часы и указывается, как личные задачи разработчика в таск-трекере. Такие активности стоит делать не менее 1-2 в неделю, а для новичков можно и чаще.
Да, есть замкнутые в себе товарищи, которые не хотят ни с кем взаимодействовать. Им даже общение с коллегами дается с трудом. Причем это не про стеснительность, это про агрессивную замкнутость, милую мизантропию. Полезная черта характера, но не для совместной работы на сложных проектах.
Я предпочитаю таких программистов не нанимать, поскольку командная работа важнее таланта отдельного человека.
Разработчики и бизнес – не кошка и собака, что радует. Начните их постепенно знакомить и будет вамскорость счастье.
Что работает для вас? Какую профилактику выгорания разработчиков используете? Как сглаживаете непонимание программистов и представителей бизнеса?
Тема противоречивая и есть огромное количество разработчиков и менеджеров, которые не задумываются про правила и способы коммуникации друг между другом, а тем более про коммуникацию разработчиков и клиентов.
Но для меня и моих команд подобные барьеры преодолевались (и не раз) и давали отличные результаты, поэтому не могу не поделиться успешным опытом:
Итак
Бизнес есть Бизнес, Разработка есть Разработка, и не встретиться им никогда, пока…
Видел статью о том, как подружить кошку с собакой. Лайфхак от мамкиных бихевиористов:
«Положить собаку на бок и к ее спине спиной приложить кошку. Они не будут видеть друг друга, а только чувствовать запах. Такое упражнение поможет вызвать доверие у животных. Начинайте гладить обеих под расслабляющую музыку.»
Решение годное для нишевого interspecies threesome, наверное. Попробовал — чуть не лишился глаза и кошки.
Примерно такие же потери и чувства у меня вызывает вопрос знакомства «бизнеса» и «разработки».
Но в этом контексте мой кейс менее травмоопасен. Я считаю, что знакомить бизнес и разработку нужно дозированно и ненавязчиво.
Сложности перевода
Часто у разработчика нет даже поверхностного понимания вашего бизнеса или бизнеса клиента. И тогда у него включается инструкция:
Шаг 1. Прийти и потребовать переписать все на RUST.
Шаг 2. Выгореть, так как вы не будете давать переписать все на RUST.
if (переписать_все_на_RUST == false) then разработчик.выгореть({immediately: true})Так почему же разработчик не хочет понимать ваш бизнес?
В поисках смысла и цели
Цель у любого бизнеса одна — принести пользу другим людям. За эту цель платят фиатными деньгами и социальным капиталом.
Мой опыт говорит о том, что разработчик часто не видит пользы, которую приносит другим людям.
Поэтому ему сложно оценить свой вклад — он видит только код и деньги за этот код.
Соответственно, его мотивация (переписать все на RUST) основана на «писать топовый код», а не «выпускать фичи (синоним «приносить пользу») для пользователей».
Поясним
Обычно в фирмах есть разные отделы: маркетинг, тех-поддержка, аналитика, продажи, стратегия. А вдалеке от всех, существует полу-автономная резервация под названием «отдел разработки», с которыми общаются через специального дипломата-переводчика (PM, Team Lead).
На практике не принято допускать разработчика к клиенту или к бизнесу. Сегрегация, изоляция разработчиков от бизнес процессов не позволяет им шире понимать задачи. Иногда это оправдано, иногда нет.
Вот именно такой апартеид отделяет разработчиков от тех, кому они приносят пользу. Со временем разработчики все больше уходят от бизнес реальности в страну чистой разработки. Которая часто игнорирует простые человеческие радости и боли.
Рекомендация
Чтобы ваши разработчики не превратились в аутичных специалистов, говорящих на смеси матана и Haskell, постепенно знакомьте их с клиентами, с бизнесом. Важно, чтобы разработчик время от времени слышал напрямую от заказчика «спасибо, это же огнина!» и «ну епт, это никуда не годится».
Удовольствие быть нужным и важным участником бизнес процессов родит желание повторить ситуацию и сместит акцент внутренней установки с «писать топовый код» на «приносить пользу» что, в свою очередь, ускорит выпуск и качество фич, а не кода.
(Тут что-то еще про доверие, разумную автономию, здоровый микроклимат в команде хотел написать. Но сегодня без сентиментальности, в другой раз.)
Как этого добиться
У меня это получилось так:
- Иногда вожу разработчика на встречи с бизнесом.
- Время от времени приглашаю на созвоны с клиентами.
- В конце каждого месяца устраиваю планерку, на которой рассказываю каких показателей добились, какую пользу принесли.
- Даю возможность клиенту / бизнесу напрямую поработать над задачей с программистом.
Важно отметить! Я всегда против, чтобы кто-то, кроме ответственного человека, мог ставить задачи разработчикам напрямую, но пункты выше не противоречат этому правилу.
Все это, несомненно, происходит в рабочие часы и указывается, как личные задачи разработчика в таск-трекере. Такие активности стоит делать не менее 1-2 в неделю, а для новичков можно и чаще.
Дайте разработчику понять, что он может получать удовольствие не только от зарплаты или написания кода. Но и от осознания пользы, которую он несет другим людям. От неизбежных кайфа и боли, которые присутствуют при решении бизнес задач вместе с другими способными людьми.
Да, есть замкнутые в себе товарищи, которые не хотят ни с кем взаимодействовать. Им даже общение с коллегами дается с трудом. Причем это не про стеснительность, это про агрессивную замкнутость, милую мизантропию. Полезная черта характера, но не для совместной работы на сложных проектах.
Я предпочитаю таких программистов не нанимать, поскольку командная работа важнее таланта отдельного человека.
Вместо вывода
Разработчики и бизнес – не кошка и собака, что радует. Начните их постепенно знакомить и будет вам
Что работает для вас? Какую профилактику выгорания разработчиков используете? Как сглаживаете непонимание программистов и представителей бизнеса?
skyeff
Заработать денег. Принесет это кому-то пользу, кроме владельцев бизнеса — ну замечательно. Принесет это кому-то вред — ну бывает, мир не совершенен. Главное чтоб деньги у владельца бизнеса появлялись.
Заработать денег, точно такая же как и у владельца бизнеса. А еще у него мотивация снизить издержки процесса зарабатывания денег, если это конечно хороший специалист. Соответственно его желание переписать вот этот вот кусок коричневой субстанции обусловлено, не отсутствием понимания целей бизнеса, а пониманием что сейчас мы тратим на внедрение любой новой функции 40 часов и потом еще 80 на исправление багов, а могли бы тратить 20 часов на внедрение фич и 20 часов на исправление тех немногих багов, которые в любом случае будут появляться. Но для этого надо потратить 200 часов на рефакторинг. Но рефакторинг не приносит денег бизнесу.
А вот эти вот рассказы о том какую пользу приносит человечеству разработчик от того что решает проблемы вот этого вот бизнеса, они нужны ровно для одного — платить меньше разработчику, чтоб у владельца бизнеса оставалось больше денег.
Поэтому подружить бизнес с разработкой нельзя.
Dionid Автор
Да, несомненно, НО дело в том, что платят деньги только за «пользу». Начиная от пылесоса, которые ускоряет работу по дому (= польза), заканчивая астрологией / инфобизнесом, которая успокаивает / мотивирует человека (= польза, какая бы странная она не была).
Поэтому, если копнуть глубже деньги – это средство обмена, польза – это причина воспользоваться деньгами.
Заметьте, я специально написал: «переписать все на RUST» – и это не про грамотный рефакторинг, о котором написал iit ниже и с чем я согласен, а я писал про «неадекватный» рефакторинг, который делается во имя «написания топового кода».
Уточнение: Rust — прекрасный язык и в этой статье используется как аллюзия на «сложная и неподходящая под контекст технология».
Мне кажется, можно найти гораздо более грамотные способы снижать ставку разработчику) Чем и как будет снижать ставку нанимающая сторона – это ее личный вопрос и сюда можно притянуть любую причину. Я никогда не снижал ставку разработчика таким образом.
skyeff
Сигареты, алкоголь, наркотики, уничтожения излишков товаров для сохранения цены, реклама всяких «фуфломицинов», уничтожение промышленных линий, ради быстрого заработка на распродаже «металлолома» и сдачи в аренду торговых площадей — это все приносит деньги. Какую пользу это приносит кому-либо кроме владельца бизнеса?
Зачем, если этот работает и не требует практически никаких усилий? Рассказал разработчику о важности миссии компании, пригласил на совещание о следующем этапе внедрения продукта, чтоб он молча постоял в сторонке, глядишь и человек уже считает себя не просто наемным сотрудником, а частью команды. А как же можно подвести команду, потребовав прибавки или вообще уйдя с проекта — это же не справедливо по отношению к остальным участникам команды? Затрат ноль, а на некоторых все еще действует. Вот когда это перестает действовать, тогда уже идут в ход разные грейды, которые еще обосновывать надо, актуализировать, если разработчик внезапно решил прокачать скилы, силы свои тратить, время.
Не надо держать разработчика за идиота, не надо ему рассказывать о громадной пользе производимого продукта. Разговаривайте с ним как с взрослым человеком, если он реально взрослый. Объясняйте почему вот все переписать на RUST мы не можем, у нас на это нет бюджета, нам за это никто не заплатит. Но вот если ты предложишь план постепенного улучшения продукта, мы включим его в общий план разработки перемежая с фичами, необходимыми бизнесу. А уж коли включили, то не говорить: ну ты же понимаешь что у нас сейчас сроки горят, вот давай все разгребем, а потом вернемся к твоему плану.
Dionid Автор
Мне кажется, что вы рассматриваете слово «польза» как благотворное влияние на всех людей одновременно, но «польза» имеет также трактовку «выгода», поэтому: «Сигареты, алкоголь, наркотики» – самая распространенная выгода: «побег от проблем из-за неимения возможности их решить»; «реклама всяких «фуфломицинов»» – кому-то надо успоить свой невроз, он покупает фуфломицил и ему становится спокойнее, что и является для него выгодой; «уничтожение промышленных линий...» – выгода тем, кто купит металлолом и снимет торговую площадь и так далее.
Даже если по итогу это вредит людям, бизнес по-прежнему будет демонстрировать «выгоду» и продает он «выгоду».
Опять же, это выбор лично ваш, я не использую данный инструмент как понижение ставки, кто-то использует.
Но ваш текст подразумевает, что «все так делают», а значит вы говорите о том, что я своими действиями пытаюсь манипулировать людьми. Поэтому попрошу вас уточнить: вы говорите о том, что я написал эту статью, чтобы научить людей манипулировать другими? Или вы имеете ввиду, что существуют разные люди и разные ситуации и кто-то использует «причастность к фирме», как манипуляцию, а кто-то повышает вовлеченность и мотивацию человека во имя общего блага?
В случае, если это всегда манипуляция получается: «Нельзя знакомить бизнес и разработчиков» – а это поддерживает мои слова про очень плохую тенденцию сегрегации отдела разработки от остальной фирмы.
С этим согласен, этот диалог никак не противоречит тому, чтобы знакомить человека с ценностями фирмы и тоже должен присутствовать.
skyeff
Однако это не основное значение слова «польза». Кроме того два этих слова имеют абсолютно разный эмоциональный окрас. Именно поэтому когда пытаются манипулировать, то говорят о некой абстрактной пользе. А вот когда хотят реально вовлечь, говорят о конкретной выгоде.
У меня есть только личный опыт, я не могу обобщать на всех. Могу даже допустить, что есть такие работодатели, которые не используют этот прием для манипулирования сотрудниками.
Да почему же, знакомьте на здоровье, только не в стиле розовых пони и давайте все обнимемся и дружно зашагаем в светлое будущее. Знакомьте разработчиков с процессами, на которых построен бизнес, показывайте разработчикам как ваше приложение позволяет решать реальные задачи бизнеса, например, ускоряет документооборот, повышает скорость принятия решений. Привлекайте разработчика к анализу и оптимизации этих процессов. Дайте ему в конце концов посмотреть на ваше ПО с точки зрения пользователя, чтоб он увидел что его отрефакторенный поиск, который подгружает значения на 20% быстрее, проблемы пользователя не решает, потому что ему надо ручками заполнить 20 полей. А вот функция автозаполнения связанных данных, на которую он забил ради рефакторинга, позволила бы заполнять 3 поля вместо 20.
Dionid Автор
Давайте так: глобально, я с вами согласен.
Вообще, каждый раз, когда я пишу статью о приемах созидательного менеджмента, приходят люди и рассказывают о своем негативном опыте в этом же ключе, потому что им попался менеджер-ублюдок, который использовал тот же самый инструмент, но со своими извращенной мотивацией. А таких гораздо больше, чем нормальных менеджеров.
Поэтому появляется ощущение, что автор (я) такой же, как они, и прием этот только для манипуляций.
Наверное, главный мой посыл: «Есть места, где умеют грамотно управлять людьми и где #{тема статьи} используется во благо, а не для манипуляции.» – стоит написать отдельный пост и давать на него ссылку во всех статьях «от чистой души и сердца», которые я пишу.
Любой инструмент в руках «негодяя» (как же сложно не материться)) будет использован во имя деструкции.
Поэтому, я надеюсь, что люди, у которых был негативный опыт, увидят, что есть альтернативы и что от одной и той же темы можно страдать на рабочем месте, а можно получать удовольствие.
VolCh
Одно из определений манипуляции — склонение людей к принятию того или иного решения путём вызова того или иного эмоциональное состояния. Другое уточняет, что только скрыто вызывая его.