Все знают, что планирование – священная корова бизнеса. А для священной коровы не жалко ничего. Как далеко можно зайти ради неё?
В предыдущие десятилетия была распространена практика ежедневных письменных отчетов – сколько часов занимался этим, сколько – тем. Сейчас это уже не так распространено, но всё еще широко в ходу – в виде ежедневных планерок, где это же самое описывается устно, но без четких цифр. Другая форма такого сверхконтроля – это требовать правильных трудозатрат в каждой таске Jira, чтобы затраты по каждому багу были видны.
«И это правильно!» - воскликнут менеджеры всех мастей, - «мы не можем контролировать процессы без понимания затрат». Тут не поспоришь, затраты надо знать.
Давайте в дальнейшем называть такие цифры затрат телеметрией планирования, или просто телеметрией.
Не будем обсуждать, полезна ли телеметрия на самом деле, а если полезна, то для чего именно. Поверим им, тысячи менеджеров не могут ошибаться! Но прежде, чем закрывать дискуссию и открывать Jira для списания времени, попробуем понять, какими именно свойствами эта телеметрия должна обладать, чтобы не быть (хотя бы) явно небесполезной и даже вредной:
· Телеметрия должна быть точной, иначе планирование будет на основе случайных цифр.
· Программисты должны понимать правила, по которым должна получаться итоговая цифра затрат и они должны понимать эти правила одинаково. Например, надо ли включать времязатраты на совещания по этой задаче или включать только написание кода?
· Телеметрия должна поступать вовремя. Нет смысла описывать трудозатраты один раз в месяц за весь месяц – в данных будет чистое враньё, так как никто не помнит деталей того, что было даже на прошлой неделе.
· Телеметрия должна быть дешевой для донора. Если сбор телеметрии каждый вечер отнимает 30 минут, то вы останетесь без команды.
· Не должно быть злокачественного использования этих данных. Как только программисты заподозрят (даже не имея доказательств), что предоставленная ими телеметрия используется им же во вред, забудьте про её точность, телеметрия будет оптимизирована не по точности, а по безопасности для донора.
У телеметрии также есть детальность, с которой вы хотите получать данные. Одних менеджеров устроит детальность в трудодень, другим хочется видеть получасовую детальность.
Противоречия
И тут начинаются противоречия. Например, вы хотите точных данных с детальностью в 30 минут, и просите предоставлять эти данные каждый день вечером. Получается 16 временнЫх диапазонов каждый день. Вряд ли нормальный программист сможет предоставить вам такие чистые данные. Никто не будет записывать каждые 30 минут, чем он занимался последние полчаса. И дело не только в том, что люди будут просто забывать сделать это, но, даже если настроить программу-напоминалку, это будет постоянный разрыв потока, и честная телеметрия превратится в таком случае в «9:00 – 12:00, 13:00 – 18:00 – вхождение в состояние потока из-за прерывания на списание трудозатрат».
Таким образом, вы не можете повысить детальность телеметрии на практике выше определенного (очень невысокого) порога. Противоречие «детальность – стоимость» вполне очевидно.
Существует также противоречие «точность – доверие»: только наивные или запуганные люди будут указывать, что с 12:30 до 13:00 не делали ничего, ждали обеда и смотрели на часы, так как забыли позавтракать.
Противоречие «детальность+точность – комфорт» тоже вполне ясно: сообщать о том, чем занимался каждые 15 минут в течение рабочего дня – чистый ад, ни о каком комфорте на работе не может идти и речи.
Наверное, есть и другие.
Некоторые из этих противоречий можно решить, некоторые можно ослабить, а некоторые только усугубятся, когда вы успешно решите другие.
Телеметрия из среды разработки
Что, если сама среда разработки (например, Visual Studio) будет посылать некую телеметрию на корпоративный сервер оценки трудозатрат?
Например, в вашей компании могут разработать специальное vsix-расширение (плагин) для Visual Studio, которое каждые N минут отправляет определенную телеметрию.
Что это нам даст? Это даст многое:
· Вы можете устанавливать правила, с какой детальностью собирать данные, хоть каждые 15 секунд, это не окажет на программиста отрицательного воздействия, так как работу делает код в фоне, а программист не отвлекается.
· Вы можете решать, что именно собирать. Например, полезно собирать: активно ли окно Visual Studio, запущена ли отладка разрабатываемого приложения, открыт ли в Visual Studio солюшен с проектом, заблокирован ли компьютер, как давно фиксировалась активность клавиатуры и мыши в окне IDE (но НЕ записи нажатий клавиш! см. ниже).
· Ну, и разумеется, вам надо собирать имя ветки, над которой работает программист.
Если в процессах производства принято в имени ветки указывать номер таски Jira, то по имени ветки можно выйти на таску, а по прочей телеметрии понять, ведется ли активная разработка или просто студия висит в фоне. На сервере трудозатрат вы можете обрабатывать и агрегировать эти данные, и после в самой задаче Jira инкрементировать трудозатраты хоть каждые полчаса.
Такая схема позволяет снять противоречия «детальность – стоимость» и «детальность+точность – комфорт», так как программисту вообще не нужно помнить ни о чем, он просто работает, как и работал раньше и ни о чем дополнительно не беспокоится.
Нулевая дополнительная когнитивная нагрузка на команду! Так, как и надо! Идеальное решение?
Шпионское программное обеспечение
Нет, не идеальное. И да, программист беспокоится.
Всё это выглядит как установка шпионского программного обеспечения прямо в «нежнейшие внутренности» ваших разработчиков – в среду, где они проводят бОльшую часть рабочего времени. Это само по себе может вызывать такое отторжение, что команда распадется за несколько месяцев. Что можно сделать с этим?
В первую очередь понять, насколько вообще для вас проблема телеметрии стоит остро. Может быть, и не стоит ввязывать в эту реформу, тем более она не бесплатна.
Оценить, насколько Ваша среда подходит именно для такого плагина. Может быть, вы разрабатываете что-то для военных и в вашей среде уже установлено шпионского ПО больше, чем полезного. Тогда небольшое добавление не вызовет у ваших программистов никаких эмоций.
А может быть, вам удалось создать на проекте такую атмосферу доверия, что, если вы предложите команду эту реформу, они отнесутся с пониманием. Такое бывает, правда редко.
Другие способы снижения вреда от внедрения такого инструмента:
· Откройте кодовую базу этого плагина для любого программиста в компании, чтобы он мог убедиться, что ПО делает (отправляет на сервер) только то, что заявлено и ничего лишнего.
· Вместо распространения бинарных файлов, предложите каждому программисту самому скомпилировать этот плагин из исходников и установить его в свою среду разработки самостоятельно.
· Ведите подробный и легкодоступный для программиста лог всего, что плагин отправляет в сеть.
· Отправляйте минимум. Зачем отправлять сырые данные, если можно агрегировать прямо внутри плагина и отправлять уже готовую телеметрию? Чем меньше раскрытых (покинувших компьютер) данных, тем психологически комфортнее разработчикам.
· Позвольте программисту временно отключать плагин, если он того хочет, и не задавайте вопросов, почему он это делал.
· В конце концов, предложите программистам выбор – устанавливать плагин или нет, и платите им небольшую премию ежемесячно, ведь точная телеметрия наверняка будет ценней.
Ни в коем случае не пытайтесь как-то обмануть команду, правда всё равно выйдет на свет (в конце концов, вы работаете с программистами!) и тогда вы навсегда потеряете доверие, будете получать ложную телеметрию, и даже не знать этого.
Ядерная бомба
И самое главное, что надо помнить – никогда, никогда, НИКОГДА не используйте этот инструмент (плагин) и данные, которые он предоставляет, для грейдирования программистов, и принятия решений по их бенефитам.
Одно дело, когда вы используете данные, что Иванов перекрасил кнопку за 2 часа для бюджетирования (будущей или этой де-факто) перекраски кнопки, а другое дело, когда вы говорите Иванову, что ему стоит поискать работу, ведь Петров перекрашивает кнопку за 30 минут.
Как только доноры заподозрят (даже ошибочно), что вы используете телеметрию им во вред, всё разрушится, вы уничтожите и доверие и процессы. Сбросите ядерную бомбу на команду. Призываем никогда не делать этого.
Именно тут критически выступает фактор доверия менеджера и команды. Оценивайте критически и внимательно, как команда воспринимает вас, разговаривайте с людьми (инициативно! не ждите «входящих»), обсуждайте их беспокойства и дискомфорт.
С организационной точки зрения, наверное, лучшее, что тут можно сделать, это разделить людей, которые принимают решение о заработной плате и «плюшках» от тех, что планируют трудозатраты, и административно и технически запретить первым получать доступ, изучать и принимать во внимание данные телеметрии.
Одним словом, здесь (как и всегда), основная валюта не рубли, доллары, трудодни, а доверие. И доверие всегда должно стоять у вас на первом месте при любых реформах.
Но зачем, Холмс?!
Менеджер воскликнет: «Но если я не могу использовать эти данные для премирования и грейдирования, зачем мне вообще эта информация?!». Вопросы оценки программистов мы затронем в другой заметке. Как сказано выше, крайне нежелательно использовать эту телеметрию для грейдирования, так как она быстро будет сфальсифицирована командой в таком сценарии.
Но вы можете использовать телеметрию для будущего планирования или предъявления затрат постфактум за уже сделанную работу.
Если в будущем поступит похожая задача (или ее часть при хорошей декомпозиции) вы, как менеджер, сможете делать уже обоснованные оценки трудозатрат и бюджета, а не пытать программиста, чтобы он придумал оценку, которая его голове кажется реальной (читай – случайную цифру). Как часто приходят похожие задачи - зависит от проекта.
На самом деле, обоснованная оценка – это крайне ценный артефакт, с которым трудно спорить любым держателям бюджетов. Если теоретическую оценку от программиста легко поставить под сомнение («ну он что-то неправильно понял, это не может стоит столько», или «я давно считаю, что он накручивает трудозатраты, сын моей подруги в другой компании делает это же в три раза быстрее»), то фактуру подвергать сомнению уже гораздо сложнее и опаснее для репутации.
В крайнем случае, вы можете использовать телеметрию для выбора исполнителя. Если телеметрия покажет, что Иванов делает бизнес-логику быстрее Петрова, но Петров лучше и быстрее решает задачи, связанн��е с БД, то это однозначно укажет, какие задачи кому лучше отдавать. Только ради всего святого, это – точка неустойчивого равновесия, не скатывайтесь в ранжирование, кто из них лучше другого.
Недостатки метода
Как и любой другой, этот метод имеет недостатки:
· Работа не в IDE не видна. Если ваши программисты тратят много времени на работу за пределами IDE, вы будете получать систематическую погрешность. С другой стороны, процент утилизации программистов всё же зависит от того, какую часть рабочего времени они пишут код (а не, например, участвуют в совещаниях). Так что, если ваши программиста много времени тратят вне IDE, возможно вам стоит обратить внимание на это и исправить такое положение дел.
· Конечно, есть и другие погрешности. Например, проект открыт в IDE, но программист ищет какую-то настройку или изучает новый модный плагин, или общается с LLM ни о чем внутри IDE. Всё это погрешности, которые можно пробовать устранять, собирая больше телеметрии и создавая бОльший психологический дискомфорт для команды. Выбирайте, что вам важнее, как говорится., Но все же метод точнее субъективной оценки исполнителя.
· Есть соблазн применять метод для грейдирования. Святым из клики ИТ менеджеров пока никого не объявили, так что всегда остается соблазн «втихую» использовать телеметрию для грейдирования. С нашей точки зрения, это малополезно (грейдировать надо другими методами), но бывает всякое. Решайте сами, что важнее – гадание грейдирование по телеметрии или доверие команды.
· Неясно, насколько ценна телеметрия для прогностических затрат (будущих задач). Зависит от проекта. Здесь можно посоветовать декомпозировать задачи, чтобы повысить шанс будущей применимости трудозатрата хотя бы для подзадач.
Прототип-демонстратор
В качестве proof-of-concept, некоего технического демонстратора, что это реализуемо, представляем вам проект автора – расширение SauronEye для Visual Studio 2022.
Это не готовое решение, но может быть полезно для проведения экспериментов. Вам надо лишь реализовать серверную часть, которая превращает ветку git в идентификатор таски и агрегирует затраты по каждой таске отдельно.
Удачи в отслеживании затрат у доверчивых доверенных вам программистах и не забудьте списать рабочее время на эту статью.
