Школа
Веб-разработка

Подскажите, пожалуйста, как начать понимать разработчиков?

Добрый день. По долгу моей работы менеджером проектов необходимо общаться с разработчиками, ставить и контролировать ТЗ. Если с фронтендерами ещё справляюсь, так как сам занимался дизайном интерфейсов, то с бэкендерами совсем плохо, когда начинаются разговоры про API и подобное.

Пробовал просить разработчиков описывать всё простым языком, но это особо не помогает и считаю это полумерой. Подскажите, пожалуйста, как начать понимать разработчиков?

Даниил Ш.
29 июня 2023
👁 2704   🗩1
Веб-разработка

Подскажите, пожалуйста, как начать понимать разработчиков?

Добрый день. По долгу моей работы менеджером проектов необходимо общаться с разработчиками, ставить и контролировать ТЗ. Если с фронтендерами ещё справляюсь, так как сам занимался дизайном интерфейсов, то с бэкендерами совсем плохо, когда начинаются разговоры про API и подобное.

Пробовал просить разработчиков описывать всё простым языком, но это особо не помогает и считаю это полумерой. Подскажите, пожалуйста, как начать понимать разработчиков?

Даниил Ш.
29 июня 2023
👁 2704   🗩1
Игорь Петров
Разработчик, преподаватель Школы бюро
Полезно
 10
10
Непонятно
  
Войдите в Бюросферу, чтобы голосовать

Даниил!

Прежде всего: если человек не хочет, чтобы его понимали, вы его не поймёте. Перевоспитание таких людей, вроде просьб вести аккуратную и понятную документацию, — неэффективное и неблагодарное занятие. А иногда это вообще настроит людей против вас.

В подобных ситуациях я знаю три варианта действий.

Работайте с заинтересованными людьми

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

Если вы не влияете на состав команды, попробуйте «продать» эту идею тем, кто влияет. Если из‑за проблем с коммуникацией бизнес теряет деньги — объясните это и предложите решение.

Лайфхак. Чтобы найти заинтересованных людей, сформулируйте принципы и отношение к работе, которого ждёте от кандидатов. Транслируйте и популяризируйте эти принципы, «поставьте вселенную в известность». Рано или поздно заинтересованные люди придут. Ещё можно выращивать людей с нужным отношением к работе внутри компании, организовав кузницу кадров. В бюро эти задачи решают кодекс бюрошника и школа.

Начните разбираться в предметной области

Становиться гуру разработки не нужно, даже краткий учебный курс по стеку ваших бэкендеров уже заметно повысит эффективность общения с ними. Приятный бонус — рост вашего авторитета в команде.

Это сложный и не быстрый вариант, но очень крутой в перспективе. Даже если вам придётся работать с самым неприятным разработчиком в мире, ваш опыт поможет получить более предсказуемый и качественный результат. Ну или как минимум не даст вас обмануть.

Забейте, если игра не стоит свеч

Иногда решение проблемы потребует столько усилий сейчас и в будущем, что это затмит всю пользу. Прежде чем что‑то предпринимать — посчитайте затраты и профит. Если ради красоты в задачах придётся развязать гражданскую войну в команде — может, и ну его нафиг. Мир не идеален и иногда необязательно быть лучшим ковбоем, достаточно быть живым ковбоем.

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

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

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.

Веб‑разработка
Полезно
 10
10
Непонятно
  
Войдите в Бюросферу, чтобы голосовать
Отправить
Поделиться
Поделиться
Запинить
Твитнуть

Комментарии

Оценки "плохо", "не понимаю", "простым языком" не показывают суть проблемы. Что‑то не ладится, но что именно? Автор вопроса предлагает отвечающим догадываться, выбирая из десятка возможных вариантов. Сроки от команды кажутся завышенными, но продавить свои не получается, аргументация хромает? Качество документации кажется недостаточным для передачи проекта другой команде? Характерами не сошлись, поэтому рационализируем раздражение псевдо‑причиной "непонимание"? Есть подозрение, что кто‑то бездельничает? Есть подозрение, что кто‑то пишет немасштабируемый запутанный код со множеством дыр? Команда сопротивляется попыткам ограничить доступ к чувствительным данным?

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

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

Цель рубрики — обсуждение вопросов дизайна, веб-разработки, переговоров, редактуры и управления.
Комментарии модерируются. Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры.

Рекомендуем другие советы