Одним из самых сложных аспектов ведения бизнеса и поддержания отношений в целом является общение. Сложность только возрастает, когда вы сглаживаете разрыв в знаниях между разработчиками и их коллегами по бизнесу.
Почему я говорю об этом?
Я разработчик с управленческим опытом, который ежедневно общается с нетехническими людьми в рамках моей консультации. Кроме того, мне сказали, что я хорошо умею передавать информацию из нетехнических разговоров технической команде в форме решения. Поэтому я хотел бы уделить минутку анализу того, что я делаю, чтобы сделать этот процесс менее болезненным, в надежде, что другие бизнес-профессионалы смогут лучше общаться со своими техническими активами.
Простой. Сложный. Легкий. Жесткий. Слова имеют значение!
Разница между правильным словом и почти правильным словом — это разница между молнией и светлячком. - Марк Твен
При общении со своими техническими сотрудниками вам действительно нужно понимать жаргон, который вы используете, чтобы объяснить свои ожидания и потребности. Давайте разберем очень стандартный пример, с которым я сталкивался много раз в своей карьере.
Бизнес-специалист (BP) предлагает разработчику новую функцию для своего программного обеспечения…
BP: Привет, разработчик! Мне нужно, чтобы вы создали функцию X. Позвольте мне объяснить, что такое функция X…. [вставьте здесь длинное расплывчатое объяснение]. Это должно быть легко, верно?»
Разработчик: "Я имею в виду, что это не так сложно, но это займет некоторое время".
BP: "Вы можете подготовить его за 1 неделю?"
Разработчик: "Это будет сложно, так как сроки очень сжаты..."
БП: "Круто. Не могу дождаться следующего понедельника».
Разработчик: "Э... хорошо... где мой степлер..."
(BP уходит и делает вид, что не слышит разработчика.)
Если вы какое-то время занимали должности разработчиков или технических специалистов, вы, вероятно, сталкивались с такой ситуацией. Это часто списывают на то, что BP не понимают, чего они просят у разработчика, но, на мой взгляд, это просто отговорка. Уважение не зависит от понимания. Поэтому я думаю, что настоящая проблема заключается в словах, которые BP использует для выражения своих потребностей.
Слова и понятия нетехническим людям следует исключить из своего делового лексикона:
- Просто / Легко ←Эти слова обычно преуменьшают задачу, не зная уровня усилий или сложности, связанных с ее выполнением. Они также приписывают уровень интеллекта, необходимый для выполнения задачи. Это ставит разработчика в неловкое положение.
- Сложный / сложный ← Эти слова обычно используются в контексте «Это не должно быть так сложно…» или «Это не так сложно, не так ли?» Опять же, это делает предположение о том, насколько сложна задача без полного понимания.
Улучшенные способы общения:
- Какой уровень усилий связан с этой задачей? «Уровень усилий» — это не качественное предположение, а скорее количественная оценка, которая вменяет очень мало предубеждений и ставит мяч на сторону разработчиков, не заставляя их чувствовать себя приниженными.
- Дайте вашему разработчику время для точной оценки задачи, которую его просят выполнить. У многих разработчиков есть определенный тип личности, который делает их замкнутыми людьми из-за характера их работы, и поэтому они не очень хорошо работают, когда их ставят на место.
- Не останавливайтесь на достигнутом. Узнайте, почему это потребует усилий или времени. Понимание того, в чем заключается задача — будь то исследование, разработка или создание прототипа, — важно для будущих запросов. Без контекста прошлого опыта мы остаемся с бесконечным циклом вопросов или, что еще хуже, с задницамиумениямиs.
Уважать и ценить
Уважайте знания. Разработчики — это не инструменты (ну, по крайней мере, не все — wink). Несмотря на то, что у них, вероятно, другой образ мышления, чем у среднего делового сотрудника, они очень опытные люди. Вам следует понять, как они думают, как и любому другому сотруднику, и приспособить свой способ общения / руководства к их тенденциям, чтобы обеспечить успешные деловые отношения.
Разработчики… это тоже ваша вина!
Как разработчик или технолог, вы должны высказываться, когда считаете, что вас поставили в положение, которое не позволит вам оправдать ожидания. Сказать, что вы интроверт или что вам не нравится общаться с людьми, — ужасное оправдание, и его будет недостаточно в реальном мире. Общение не одностороннее. Вы обязаны сообщать о своих потребностях и хорошо выполнять свою работу.
Советы для разработчиков
- Увеличьте частоту общения. Slack проделал потрясающую работу по созданию инструмента, который позволяет нам выйти из почтового ящика и действительно сообщить о своих потребностях в увлекательной форме. Делай это чаще! Деловые люди не любят удивляться больше, чем вы.
- Задавайте вопросы! Зачем мы создаем эту функцию? Для кого эта функция? Какова цель функции? Чтобы продать больше продукта/исправить ошибку? Каждый из этих вопросов может помочь вам как разработчику оценить важность задачи. Если функция предназначена для продажи большего количества продукта, а человек, который просит вас разработать эту функцию, является продавцом, вы можете быстро оценить их мотивацию. Вы должны знать "почему" не меньше, чем "как".
- 5 рабочих дней != 60 часов. Если вы говорите, что на выполнение задачи у вас уйдет 5 рабочих дней, а вы работаете по 12 часов в день, на самом деле у вас ушло 7,5 обычных «рабочих дней». Ваш деловой партнер должен знать эту информацию, иначе у него будет неточное представление о вашей способности выполнить задачу в реалистичные сроки.
Заверните
- Не используйте речь, которая умаляет чьи-то навыки.
- Помните о словах, которые вы используете, когда просите кого-то выполнить работу/задачу.
- Убедитесь, что вы слишком много говорите о потребностях, ожиданиях и причинах вашего запроса.
Если вы хотите больше поболтать на эту тему (или на любую другую, если на то пошло), вы можете найти меня в Твиттере или написать бузербилли по адресу gmail точка com
