За технологиями будущее, но как его изучить? Общение с разработчиками — хорошее начало

Кажется, что у маркетологов, которые хотят узнать True Digital (секреты серверов, API, SDK и других программных артефактов), нет другого пути, кроме как подружиться с разработчиками . Хотя здесь нет легких путей — вам нужно строить и поддерживать отношения — я собрал несколько советов о том, как заложить основу для связи с разработчиками программного обеспечения.

А если вы друзья, ваш набор технических навыков вырастет в десять раз, прежде чем вы это заметите.

Естественная среда обитания разработчиков

На первый взгляд инженеры кажутся особым типом. Вид, который якобы нуждается в особом обращении, некоторые даже говорят, сварливый вид. Я полностью не согласен с этим утверждением. У меня нет степени магистра социологии или психологии, но я кое-что знаю об этом. Раньше я был инженером-программистом, а также надел шляпу маркетолога. Более того, сегодня я живу, продавая программную платформу, которая помогает маркетологам и разработчикам зарыть топор войны.

Итак, что я узнал об упрощении взаимодействия между маркетологом и разработчиком? С точки зрения маркетолога, речь идет о понимании естественной среды обитания разработчиков — неизведанной территории для людей, начинающих свою карьеру.

Вот почему я составил карту рутины и желаний разработчиков, и я надеюсь, что она поможет вам ориентироваться в них, что в конечном итоге приведет к процветанию отношений.

Это не так просто, как кажется. Как сами разработчики признаются, у них есть репутация тех, кто говорит «нет», педантично обсуждает детали и думает, что мы знаем, как сделать работу каждого лучше, чем они. Но если вы сделаете это правильно, разработчики станут вашим основным источником знаний — как мы можем узнать от Кейт в ее истории о цифровом маркетологе, который стал менеджером по ИТ-продуктам.

Итак, давайте начнем с устранения одного из самых популярных препятствий на пути к дружбе с разработчиками.

Почему разработчики часто сварливы?

Основная причина сварливой репутации разработчиков нуждается в более подробном объяснении. Если вы хотите разобраться в этом подробно, вы должны прочитать эту длинную форму Николаса (просто посмотрите, сколько разработчиков согласились с его утверждением в разделе комментариев). Если у вас мало времени, я попытаюсь обобщить это явление в 8 пунктах:

1. Разработчики — это переводчики ваших идей в реальность . Они заставляют это работать. Они заставляют работать быстро. Они делают его надежным и надежным для ваших пользователей. Инженеры-программисты — это масло цифровой экономики.
2. И за это им хорошо платят, уникальное умение сочетать креативность и логическое мышление.
3. Но другие отделы часто относятся к ним как к создателям воспроизводства, а не как к творцам.
4. Называть их строителями несправедливо. Оставаясь метафорой строительной отрасли, девелоперы на самом деле являются архитекторами , а не строителями. Их работа заключается не в том, чтобы физически поднять здание (или здания), а в том, чтобы собирать требования . Требования в виде кода.
5. А теперь представьте этап проектирования чего-то столь же сложного, как Сиднейская опера или Сподек в Катовицах, но с небольшим отличием: заинтересованные стороны могут изменить почти все, пока здание находится в стадии строительства. Несмотря на это, застройщики могут гарантировать, что здание будет использоваться и не рухнет.
   
6. Но где настоящие строители? Они полностью автоматизированы . Разработчики были достаточно умны, чтобы создавать такие инструменты, как компиляторы, серверы непрерывного развертывания или серверы в облаке, которые делают процесс создания быстрым и предсказуемым.
7. Если вы когда-нибудь задумывались, почему разработчики не могут оценить, сколько времени займет фаза строительства, то теперь вы видите, что на самом деле вы спрашиваете об архитектурной фазе. Вы спрашиваете, сколько времени займет написание программного обеспечения, это все равно, что спрашивать у строительного подрядчика, сколько времени потребуется, чтобы спроектировать каждую деталь городского квартала, включая сбор всех требований.
8. И фактическая часть здания проста . После того, как вы записали требования, их можно оценить с точностью до секунды.

Таким образом, разработка программного обеспечения на самом деле является исследованием, замаскированным под проектирование.

Вы никогда не должны смотреть на разработчиков как на поваров в отрасли. Как говорит Николас, « инженеры-программисты берутся за программирование не потому, что хотят, чтобы кто-то сказал им, что делать, они берутся за это, потому что обнаруживают, что могут создать что-то полезное. Каждый инженер-программист влюблялся в программирование, потому что она рано написала небольшую полезную программу и увлеклась. ”

Как только вы поймете это и измените свой подход к разработчикам, вы начнете им нравиться.

Но ладить с разработчиками — это не только образ мышления. Есть кое-что более практичное, что вы можете сделать, чтобы получить настоящего друга-разработчика.

Слушайте и позвольте им отправить

Знание того, что разработчики влияют на жизнь людей, является самым мощным стимулом для разработчиков. Будь то внутренний скрипт, помогающий маркетинговым командам достигать своих целей, или полноценная серверная часть, обслуживающая миллиарды транзакций каждый день, это код, работающий «на производстве», который заставляет разработчиков приходить в офис каждый день.

Разработчики любят тяжелую работу . Они могут часами сидеть перед клавиатурой, решая проблемы людей — особенно если времени на задачу, которую они оценили, мало (да и недооценивают , но это тема для отдельной статьи).

Чего они терпеть не могут, так это директив о переменах по ветру, а не доставки .

Разработчики не грузят, когда их прерывают. Как говорит Николай, это происходит, когда:

• Запрос поступает с опозданием во время разработки, и не хватает времени, чтобы уложиться в него до крайнего срока.
• Запрос делает недействительным одно или несколько предположений, которые были сделаны в начале процесса, чтобы запустить проект.
• Запрос является изменением предыдущих требований .
• В противном случае запрос увеличивает объем работы , которую необходимо выполнить до крайнего срока.

Имея это в виду, вот что вы можете сделать, чтобы обеспечить бесперебойную доставку:

• Раннее понимание инженерных ограничений.
• Будьте полны ваших требований (первые два — это то, чему мы хотим научить вас здесь, в 200 OK).
• Очень тесно сотрудничайте с инженером.
• Помогите им понять , насколько окончательным является дизайн на любом этапе — признайтесь, когда вы в чем-то не уверены и хотите что-то протестировать.
• Будьте милы — (и не только в этом случае) люди часто забывают об этом, а анализ, начатый Google, показал, что это ключ к хорошей командной работе.

В общем, без причины программисты не сердятся. Дело не в том, что они ненавидят тяжелую работу или долгие часы; они ненавидят, когда это не окупается (и я не говорю здесь о деньгах). Поэтому, когда вы позволяете им делать свою работу , они становятся менее сварливыми и становятся более полезными.