От автора
Тема противоречивая и есть огромное количество разработчиков и менеджеров, которые не задумываются про правила и способы коммуникации друг между другом, а тем более про коммуникацию разработчиков и клиентов.
Но для меня и моих команд подобные барьеры преодолевались (и не раз) и давали отличные результаты, поэтому не могу не поделиться успешным опытом:
Видел статью о том, как подружить кошку с собакой. Лайфхак от мамкиных бихевиористов:
«Положить собаку на бок и к ее спине спиной приложить кошку. Они не будут видеть друг друга, а только чувствовать запах. Такое упражнение поможет вызвать доверие у животных. Начинайте гладить обеих под расслабляющую музыку.»
Решение годное для нишевого 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 в неделю, а для новичков можно и чаще.
Дайте разработчику понять, что он может получать удовольствие не только от зарплаты или написания кода. Но и от осознания пользы, которую он несет другим людям. От неизбежных кайфа и боли, которые присутствуют при решении бизнес задач вместе с другими способными людьми.
Да, есть замкнутые в себе товарищи, которые не хотят ни с кем взаимодействовать. Им даже общение с коллегами дается с трудом. Причем это не про стеснительность, это про агрессивную замкнутость, милую мизантропию. Полезная черта характера, но не для совместной работы на сложных проектах.
Я предпочитаю таких программистов не нанимать, поскольку командная работа важнее таланта отдельного человека.
Вместо вывода
Разработчики и бизнес – не кошка и собака, что радует. Начните их постепенно знакомить и будет вам
Что работает для вас? Какую профилактику выгорания разработчиков используете? Как сглаживаете непонимание программистов и представителей бизнеса?
