Мы всё время убиваем время? Про (бес)полезные созвоны
Сегодняшняя статья не входит в цикл по организации команд разработки, а является неким изложением мыслей тимлида. А запустил поток этих самых мыслей один из комментариев к предыдущей статье, который в общих чертах обрисовывал, что созвоны это трата времени, и не более. Обсудим?
Время не вернешь
Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь беречь время команды. Иногда даже получается. А еще у меня есть канал, где можно обсудить эту и другие статьи. Подписывайтесь, там интересно. Наверное.
Довольно часто разработчики (почему-то именно они, а не аналитики и не дизайнеры) выдвигают забавный тезис — созвоны бесполезны, они тратят очень дорогое время разработчика, и получается, что специалисты вместо работы о чем-то постоянно разговаривают. Что уж там, когда я был разработчиком, я и сам так думал, и очень злился на подобную потерю времени. Но всё кардинально меняется, когда ты становишься ответственным не за свой конкретный код, а за результат команды в целом. Велком ту хелл, нью тимлид!
В идеальном мире программиста он сам вообще может ни с кем не общаться, а только брать тикеты в джире и писать код согласно задаче. Если по итогу получается не то, что нужно — он не виноват, это задача была плохо поставлена. И вообще, к пуговицам претензии есть?
В реальном мире при такой ситуации тимлиду приходится пояснять на демо перед заказчиком, как же так получилось, что сделано не то, что было нужно, потом собирать команду на ретро и долго выяснять, кто не прав — аналитик, который якобы криво поставил задачу, или программист, который читать не умеет. И очень редко бывает, что виноват кто-то один, обычно есть и косяки в постановке, и программист попался из непонятливых. Чтобы избежать подобного эффекта, тимлид собирает аналитика и программиста на созвон, где все втроем совместно решают, что нужно сделать по задаче. Делать это нужно непосредственно перед выполнением, потому что в текст всего не вложишь (да и писать его обычно лень, это внезапно выясняется, когда просишь самого программиста написать себе задачу со слов аналитика). Поэтому в тикете ВСЕГДА будут лишь основные тезисы, и аналитику с программистом ПРИДЕТСЯ общаться для лучшего понимания задачи. Тимлид проследит.
Реальный кейс, который произошел не в моей, но в соседней команде. Фронту поставили задачу на срочную правку какой-то страницы, и указали вставить какую-либо тематическую картинку. Он поставил туда фото женских половых органов, и это ушло на прод — срочный багфикс же. Со стороны программиста это просто шутка с подтекстом «ставьте задачу конкретнее», но представляете реакцию бизнеса? При этом программист формально прав, картинку ему не выдали, он вставил ту, что посчитал нужным вставить. А кто остался виноват? Конечно же тимлид, потому что именно он отвечает за результат работы команды.
А вот произошел бы созвон для уточнения задачи, всё сложилось бы иначе.
И это мы еще никак не рассмотрели вариант вполне сознательного «непонимания» задачи разработчиком с какими-то своими личными целями. На удаленке стало очень модно взять задачу, пару часов её «читать», а потом внезапно «не понять» и отдать на уточнение. Так как аналитик очень вряд ли возьмется сразу её уточнять, полдня освободить на личные нужды очень даже можно. И кто скажет, что так не бывает?
Это раньше, когда сфера программирования еще только зарождалась, и туда шли действительно увлеченные люди, практически уникальные профессионалы, одержимые идеей сделать мир лучше, подобного практически не наблюдалось. А сейчас разработчики — просто наёмный персонал, и в их среде всё чаще встречаются люди, желающие ничего не делать за большие деньги. Отсюда возникают различные способы недопущения подобных выкрутасов и методы контроля разработчиков. Один из таких методов — регламентированные созвоны с конкретно установленной целью понимания поставленной задачи.
Поделитесь в комментариях, проводятся ли у вас созвоны для уточнения задач, или вы надеетесь на тикеты и текст?
Тот самый комментарий
