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

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

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

Это плохая практика. Ставить задачи голосовым в ТГ - очень плохая идея, но иногда действительно либо так, либо 14-часовой рабочий день.

В моей практике один такой разработчик стоит половины команды. Зависимость простая: время - деньги. Время = время менеджера (м) на анализ задачи, постановку задачи, проверку задачи + время разработчика (р) на понимание задачи, уточнение, исправление. В плохом варианте это работает так: Время = м понимает задачу, м ставит задачу, р уточняет требования, р выполняет задачу, м проверяет, м выдает и оформляет правки, р переделывает задачу, м проверяет (последний цикл может повторяться бесконечно).

В хорошем - так: Время = м понимает задачу, м ставит задачу, р выполняет задачу, м проверяет и одобряет задачу.

В первом варианте проблема в постановке задачи? Возможно да. А возможно и нет. У меня были миддлы, которым я на скрине красным рисовала, куда и какой элемент нужно добавить, и они все равно добавляли не туда. Иногда это действительно зависит от способности разработчика не только выполнить, но еще и понять задачу.

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

И плохая новость для разрабов: если вы можете разработать все, что угодно, но никогда не задаетесь вопросом, нафига и зачем, то до sinior developer еще не нужно расти ✍️