Во многих компаниях, занимающихся заказной разработкой ПО, исторически сложилось правило вести тайм-трекинг. И эта привычка настолько укоренилась, что руководителям сложно представить:

• как ещё узнать, что люди, действительно, работают?

• как убедиться, что на проекте идёт работа?

Но в продуктовых компаниях время трекают редко. И не всегда "у них больше денег, они могут себе позволить лодырей". Как им это удаётся?

Я, как руководитель, совершал переход от парадигмы тайм-трекинга к, как мне кажется, более эффективным методам работы. И в этой статье хочу показать, как можно отказаться от жёсткого тайм-трекинга и при этом успешно делать проекты.

О причинах тайм-трекинга

Чтобы понять, как упростить эту практику, нужно вспомнить о её исторических причинах. У тайм-трекинга есть, вполне, объективные причины.

Начнём с того, что две основных формы оплаты в сфере разработки ПО — это почасовая (Time & Material) и фиксированная (Fixed Price).

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

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

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

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

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

Поэтому, со временем компания отваживается брать на себя риск выхода людей на бенч. При этом компании приходится вырастать в размере, чтобы быть способной нести эти расходы. А больше размер — больше накладных расходов на менеджмент. Зато, и бизнес — интереснее, и заказы можно брать побольше! Ставить на новый проект уже целую команду и брать проекты целиком, а не по 1-2 человека.

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

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

Давайте обсудим, зачем и как можно попробовать уйти от этой привычки.

Тайм-трекинг мешает успешно делать проекты

Тайм-трекинг — это лишняя работа, которая не повышает вероятность успешного завершения проектов, а только тратит время/деньги и снижает мотивацию людей.

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

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

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

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

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

А когда мы слишком увлекаемся тайм-трекингом и контролем часов, то это отвлекает нас от главной задачи — контроля сроков и требований по проекту. В этом его главный минус с точки зрения успешности проектов.

Бывают, конечно, "чисто почасовые" проекты. Где кажется, что сроки заказчика не интересуют, и остаётся только одна форма контроля — по часам. Но и может быть иллюзией.

Перегибы в контроле часов

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

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

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

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

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

Таким образом, в краткосрочной перспективе компании кажется, что она переложила риски на людей. Но в долгосрочной она теряет от этого.

Мыслетопливо vs часы

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

Возможно, в статье, у которой целевая аудитория — это топ-менеджмент, странно использовать в качестве аргумента трудности инженеров. Но, мы все в одной лодке, поэтому захотелось осветить здесь и этот важный фактор. Потому что именно он, на мой взгляд, является одной из главных нестыковок почасовый оплаты и инженерного труда.

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

Примеры задач, которые быстро тратят мыслетопливо:

1. Вникание в требования по новой задаче.

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

3. Планирование работы.

4. Продумывание комплексного решения, учитывающего множество факторов, интеграций, рисков.

И так далее.

На таких задачах ты быстро тратишь мыслетопливо, и за 4 часа можешь устать так, что до конца рабочего дня сможешь делать только что-то очень простое. А простые задачи есть не всегда. Если пытаешься продолжать "выжимать" из себя мыслетопливо на решение сложных задач, то рискуешь больше наделать ошибок, чем добавить полезного.

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

Есть способы экономить мыслетопливо. В этом направлении активно работает @Cartmendum(ссылка на канал). Но, всё равно, надо понимать, что работать все 40 часов в неделю только над сложными задачами — не получится. А когда по сложным задачам есть сжатые сроки, то, как это не парадоксально, может быть выгоднее недорабатывать 40 часов, чтобы успевать восстанавливаться и делать меньше ошибок.

Например, тебя поставили на задачу из новой незнакомой области и новой технологией. Можно попробовать структурировать день следующим образом:

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

• Планируем 2-3 следующих шага на день.

• Делаем ревью кода коллег — 30 минут, или сколько потребуется, .

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

• Если до конца рабочего дня ещё 1-2 часа, но чувствуем, что уже сильно устали — финализируем работу: спокойно прогоняем тесты, комитим код, пингуем коллег по открытым вопросам.

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

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

Посмотрим на это с точки зрения планирования проекта.

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

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

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

Также подчеркну, что если человек просто не хочет работать, в силу демотивации или ещё почему-то — то это уже другой случай, и выходит за рамки этой статьи.

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

Уменьшаем рутину тайм-трекинга

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

Но самое главное то, что компания продолжает работать в парадигме тайм-трекинга: менеджмент продолжает контролировать проекты, прежде всего, по отработанным часам.

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

Сначала о простом: как можно уменьшить бремя тайм-трекинга для людей?

Во-первых, чтобы снизить нагрузку на людей, можно разрешить им трекать время с меньшей гранулярностью. Например, не с точностью до часа, а с точностью до дня. Если вы перейдёте при этом на форму контракта с FTE (см. ниже) то это было бы идеально. Но и с обычным почасовым контрактом тоже можно трекать время по дням.

Во-вторых, заполнение таймшитов можно переложить на РМа или специального администратора. Идея здесь такая: трекинг времени, если мы его используем для выставления счетов, а не контроля отработки — это не работа инженеров, а административная функция. Грубо говоря, нет смысла нагружать этим дорогих инженеров, главная задача которых делать проекты, если это можно сделать дешевле.

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

В идеале, хорошо бы, соответственно, изменить форму контракта с заказчиками: в качестве формы оплаты прописывать не явное количество часов в месяц для каждого члена команды, а FTE. И сколько эта позиция стоит в месяц. Например:

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

Настоящий контроль за проектом — это контроль сроков, а не бюджета

При обсуждении ухода от тайм-трекинга, многие руководители спрашивают: "Как я узнаю, что человек действительно работает?"

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

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

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

• Что считать "выполненной" задачей или достигнутой вехой?

• Как оценить, сколько работы по проекту предстоит?

• Как походу проекта убедиться на цифрах, что мы укладываемся в срок?

Ответить на эти вопросы не так просто.

Приходится изучать методы оценки проектов, строить Ганты или пользоваться методами контроля сроков на основе исторических данных (aka Reliable Scrum). Это требует на порядок больше экспертизы от менеджмента.

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

Как убедиться, что человек работает?

Следующий частый вопрос: как убедиться, что человек работает 40 часов в неделю?

Ответ такой: на самом деле, вам не должно быть важно, работает ли он 40 часов. Вам должно быть важно, чтобы работа делалась, проект укладывался в сроки, и люди при этом не сбежали из компании по завершении очередной фазы проекта.

Но должен быть Лид, должен быть какой-то оперативный руководитель. У него должно быть понимание того, двигаются ли задачи по доске, работают ли над ними люди. Это — его основная обязанность. Если руководитель не знает, двигаются ли задачи — то он не тот руководитель, который вам нужен. Если же у вас есть оперативный руководитель, то он знает: кто работает, а кто нет.

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

А для людей, которые хотят работать и работают, тайм-трекинг — лишняя нагрузка и оверконтроль. Я видел много случаев, когда ответственные от природы инженеры выгорали и увольнялись из-за того, что тайм-трекинг в них развивал синдром самозванца и повышенную тревожность: "я не буду трекать эти часы, потому что я плохо здесь справился, доработаю 40 часов на выходных".

Как узнать, что оценка по задаче не превышена?

Это ещё одна ловушка. Вас не должно интересовать, укладываетесь ли вы в оценки по отдельным задачам. Если вы правильно оценили проект, то по отдельным задачам у вас всегда будут либо превышения, либо раннее завершение. Просто в силу вероятностной природы оценки. Нужно следить не за отдельными оценками, а за общим состоянием проекта на большем масштабе — идёте ли вы вцелом по плану:

• Что вцелом на Ганте (если вы используете Гант)? Успевает ли компенсироваться отставание по одним задачам опережением по другим? Не накапливается ли оно?

• Что прогнозирует Burndown Chart? Какова вероятность уложиться в срок?

• Что показывает Reliable Scrum? Делается ли работа быстрее, чем добавляется?

• Достаточно ли у вас Stretch-требований, которые можно отложить в случае проблем с Must Have требованиями (см. тут)?

• Какие проектные риски сработали, а каких удалось избежать?

Если человек попросит поднять зарплату, то как убедиться, что он стал продуктивнее?

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

1. Что самое важное он сделал?

2. Показал ли он на каких-то задачах навыки, достойные следующей позиции?

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

Поэтому и нет смысла переживать — оценивайте человека вцелом, а не то, сколько часов он затрекал.

Итоги

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

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