Отчёты — отличная вещь. Они позволяют защищать как заказчика, начальника, так и сотрудника со всем проектом. Они позволяют ими управлять и оценивать их. Вы же, в конце концов пишете код не с усердием дрессированной обезьяны тысячи раз переписывая патерн visitor, а вначале всё-таки сидите и думаете, рисуете на бумажке, планируете код и тесты (я верю в вас!)? Но с другой стороны, отчёты — вещь контроля и организации, которая всех отвлекает от непосредственной работы. И всё равно, в том или ином роде на работе нам приходиться с ними сталкиваться. Зачем и как искать компромисс? Добро пожаловать под кат всем, кому интересно моё мнение по этому вопросу и тем, кто читал мои предыдущие статьи:
От инженера до руководителя. Часть 1: Чувство справедливости
От инженера до руководителя. Часть 2: Делегирование и постановка задачи
Overflow
Все премудрости баланса и гармонии я познал не смотря на сакуру и проплывающие трупы своих начальников, а в суровой реальности. И реальность была и вправду сурова. В тёмные времена прислали нам тёмного менеджера из далёкой Африки. У него была великолепная белая улыбка, которую ночью в тёмном переулке можно было спутать с улыбкой исчезающего Чеширского Кота, но совсем немного было представления о том, что такое самолёт, который, мы, в общем-то и делали. Даже более того, улыбчивый менеджер, по-видимому, видел самолёт один раз в жизни, когда счастливый летел руководить нашим проектом. И компьютеры, к сожалению, он, по-видимому, тоже не очень давно освоил, в отличие от жестоко избитого временем велосипеда, на котором он катался с работы домой, держа в одной руке пакет из китайского ресторана, а в другой графики и планы нашего проекта.
Проект был срочный и тяжелый: надо было вылизывать и исправлять все косяки перед предстоящей сертификацией. Т.к. он был on-site, то приходилось разбираться с машинами, которых ранее в глаза не видел и не особо понимая, чего ждать от них. Много времени уходило на обучение, и поэтому важно было отслеживать прогресс, много и чётко контролировать процесс. В проекте участвовало три команды по 6-7 человек в каждой, которые были ему подотчётны. Чтобы учитывать кто и что сделал, менеджер завёл Excel-таблицу, которую каждый день должен был заполнять каждый из участников: сколько модулей проревьюировано, протестировано. Т.е. сделал, отметил в табличке. Но тут крылась проблема номер один: людей много, а файл один. Поэтому список заданий накапливался людьми в локальных файликах, а затем переносился в строчки таблицы с указанием подотчётного. За время, когда освобождался файл бились и сражались. И если кому не повезло дождаться освобождения файла, он оставался и во вне рабочее время, чтобы занести в табличку разноцветные статусы.
Менеджер каждый день проводил митинги. На них он рассказывал, как заполнять таблицу, что по часу в день съедало времени. И на одном из митингов он понял, что у людей случаются проблемы. И их тоже надо заносить в таблицу: найденный баг, проблемы у человека с запуском на симуляторе, отсутствие модуля и пр., впрочем, без проблем с смой таблицей. Так появилась второй файлик и таблица, в которую надо было заносить баги, с переносом всех проверенных статусов из первой. Однако, как выяснилось спустя неделю, что это не столь эффективно, и надо всё-таки что-то подсчитывать, а подсчитывать и пересчитывать сотни изменений менеджер не успевал. Поэтому он пришёл как-то утром и с улыбкой чеширского кота, промурлыкав: “Hi guys, how are you, guys?”; предложил заполнять и третью, в которой результатами были бы числа, посчитанных вручную результатов и их проценты же, потому что таблицы для безопасности менеджер залочил. Причём, дополнялось, чтобы была обратная связь с первой — заполнять прогресс там, что если что-то не успевалось, то указывать статус на модуль “задержан”, а во вторую вносить правку — проблемы со временем.
Надо ли говорить, что проблемы со временем появились задолго до этих нововведений? По сути в каждой из команд один из её участников только и занимался заполнением этих таблиц, безбожно путая и пропуская то, что было в куче текстовых файлов. А так как файлы таблиц ломались из-за того, что в них оказывались ошибки, для сохранения статистики их сохраняли все (каждую под отдельным именем), после критического изменения, и они размножались как на дрожжах, и понять, какая же последняя и актуальная — было проблематично.
Проект закрыли в срок. Менеджер ушёл по собственному желанию за неделю до закрытия проекта и укатил на своём аистёнке в голубую даль, оставив нам суровые будни и чёрные размышления. Которые были следующими: отчёты это хорошо, но они должны занимать минимум времени. Особенно в IT-сфере. Это должно делаться в один клик, а остальное считать и делать должны программы, причём отчёты и их составление не должно мешать работать другим людям. В идеале — это клик по чекбоксуползунку на прогресс баре с фидбеком в багтрекинговой системе при необходимости. Не всегда это возможно, и приходится выкручиваться невообразимыми костылями при отсутствии централизованной практики, но упрощать затраты на отчётность и доверять технике, а так же иметь представление о предметной области надо в первую очередь. Чтобы, как минимум, не отвлекать специалистов от работы.
Underflow
Помимо доверия к технике вычислительной, надо руководствоваться и техникой понимания людей. Наученный примером менеджера, в одном из последующих проектов я подготавливал ежедневные отчёты, в которых помимо перечисления всего, что было сделано за день, сравнивалось с запланированным автоматически, достаточно было поставить только passfail напротив актуальной задачи. Но, т.к. задание было мне, как подчинённому, запланировано на месяц, я очень был доволен, что выполняя работу быстрее и эффективнее, я это отражаю в отчёте. “Сегодня написано 5 модулей, всего готово 11 из 40 планируемых”. И в начале новой недели я хотел отчитаться, что закончил работу вдвое быстрее. Красивые графики для менеджеров «запланировано» и «сделано» оптимистично расходились и поднимусь ввысь. Отчёты проходили через тим лида, прогресс есть: видно когда и что сделано. Да вот еженедельный брифинг у руководителя проекта оказался поводом вызвать меня и задать вопрос: “Ты чего растягиваешь сроки? На месяц? Мы зачем тебя тут держим?”. Оправдания о том, что работа будет сделана завтра, мало кого интересовала, т.к. такой “запланированный” график в их лице выражал и мою мотивацию, следовательно способность к выполнению новых задач. Я остановился и подумал, что же тут не так. Во-первых, руководители, планируя, закладывают риски и сроки, зачастую руководствуясь худшим примером. И когда вместо худшего примера сотрудника оказывается ими же запланировано хороший профессионал, ему не всегда стоит спешить делать выводы и давать свои позитивные оценки за менеджера. Даже не столько из-за прерогатив и разделения ролей, а из-за того, что ему не всегда может быть видна общая картина, в которой большой позитивный скачок может быть всего лишь латанием пробоины в большом судне, возвращающий проект в изначально запланированное русло.
Когда учишься на своих ошибках, важно не потерять мотивацию и понимание того, что отчёты не просто обязанность и рутина, а действительно острый инструмент работы и руководителя, и программиста, и тестировщика, и системного администратора, и, конечно, менеджера. Надо просто правильно и к месту их доставать и применять. Квинтэссенцией моего опыта составления отчётов было составление дорожной карты одного из проектов.
Division by zero
Дорожная карта представляла собой список всех модулей, над которыми предстояло работать. В ней надо лишь было проставить статус задачи. Пара минут в день. Всё остальное система делала сама. Подсчитывала, кто и сколько чего сделал, когда, какой прогресс, какие тенденции, какие проблемы, какой план, какой скорректированный план, эффективность и прочая. Единственное, что надо было сделать члену команды — щёлкнуть по своему модулю и поставить passfail, и затем можно было сгенерировать отчёт для руководителя со всем необходимым, чтобы последнему осталось лишь передвинуть прогресс в MS Project, и при необходимости внести те поправки, которые он посчитает нужным.
Проект оказался не тривиальным, за место обычной верификации и допиливания, приходилось изучать электрические схемы, считать напряжения, силу тока, смотреть последствия разрывазамыкания цепей и переносить их логику и их влияние на код. К счастью, в это время в качестве хобби я заинтересовался электротехникой и паял платы по вечерам, так что схемы с различными манипуляциями над ADC, потенциометрами, фазами напряжений были для меня не слишком туманными. Но это следовало объяснить и моим коллегам-программистам, и, в частности одному новичку. Поэтому было очень важно оценить, как мы справляемся с такой задачей, и сколько нам надо реального времени и каких затрат против поставленных требований и сроков. И к моему счастью, в это же время подошёл мой отпуск. Без меня, по моим оценкам, коллеги бы справились за неделю или чуть больше с задачей. Дав наставление вносить обновления каждый день и держать в курсе начальника; я спокойно плавал две недели с рыбками и кормил крокодилов, полностью выкинув все проблемы из головы. Но по приезду меня ждало неожиданное. Начальник перевёл старших товарищей на другие фронты, видя, что всё идёт неплохо и лучше ожидаемого, и оставил на этом проекте только новичка. Новичок всё сделал, как я и ожидал, ещё до моего приезда и честно заполнил отчётность. Но только перед тем, как показать её начальству. Т.е. забив среднее арифметическое в данные для каждого дня, но один раз, перед показом боссу. Такие данные были абсолютно бесполезны, они лишь показывали результат, но совершенно не говорили, сколько и как (в том числе и от сложности модулей) мы делаем за деньнеделю. И это стало серьёзной проблемой. Сколько времени нужно для следующей итерации? Есть ли перспектива роста производительности? Сильно ли разнится сложность модулей? Насколько мы обучились новым методам и подходам? Весь потенциал от отчётов был потерян, и лишь примерную оценку худшего случая можно было бы предложить, как и в моём предыдущем примере.
Из этого я так же вынес урок: если нужна оценка и исследование, а не обычная статистика, то нельзя допускать изменений прошлых данных, если данные должны отражать ежедневную актуальность или чаще — значит они должны собираться именно в таких дискретах, т.е. быть актуальными. Значит этого надо требовать, ремайндерами, принудительным образом или контролем. Даже защищённая от рисков по технике, по процессу система не защищена от человеческих рисков, и их надо предугадывать и форсировать.
Что представляет собой идеальная система отчётности?
Лучшим решением, пожалуй, будет обратиться снова к SMART.
Имея поставленную конкретную цель (Specific), её измеримость (Measurable: количество модулей, поставленных задач, функций, тестов и т.п.), а так же имея гибкость в достижимости (Attainable: наличие этого модуля, возможность его вообще обработать), надо задать параметры её актуальности (Relevant: необходимость отчитываться по данному вопросу определённым образом), в зависимости от ситуации и требований по времени (Time-bound). Это то, что в багтрекинговых системах измеряется приоритетами: Low, Normal, High, Urgent. И обусловиться, как и в каком порядке будут производиться обновления.
Какая иерархичность отчётов?
Отчитываться ежедневно, затем формировать еженедельный и ежеквартальный отчёт. Для каждого уровня определить свою систему.
Уровень задачи:
как правило, задача — это атомарная величина, в которой нет других подзадач и шагов. Если у задачи выставлен приоритет, то он определяет сроки её выполнения в отдельно стоящем образе (вне зависимости от сроков проекта), и требует от неё определённого поведения и отчётности. Например, низкоприоритетные задачи могут быть растянуты по времени, а высокоприоритетные выполнены сразу в течении пары минут или часов. Однако, в случае если задача занимает время сверх дискрета отчётности, то составляется отчёт по задаче. Звучит странно, но на деле — это отписка в багтрекинговой системе типа банальной: “I’m working on it, integer conversions implemented, float still in progress”. Если нет системы, то комментарий в таблице, или текстовый файлписьмо, то, на что материально может опираться задача без финального commit. Это нужно в первую очередь для того, чтобы не заткнуться на том, что уже считается отработанным и поймать проблему до её начала влияния на весь проект. Используйте Jira, Redmine, Bugzilla, Trac, GNATS, свой почтовый скрипт, только используйте, не отговаривайтесь устно (подчас руководству не до того, и он не всегда заметит важность проблемы если его мысли заняты чем-то другим, как бы вы ни пытались её донести) или запоздалым упоминанием в финальных отчётах уже позабытых и перевранных цифр и названий.
Уровень дорожной карты:
как правило, это ежедневный отчёт вида сделано Х из Y за сегодня. НовыхСтарыхВсего. Его назначение — контроль задачи, оценки сложности задач. Представляет собой выжимку из обновлённых (Updated) заданий на сегодня. В идеале — формируется на основе изменений checkboxissues в системе автоматически. Именно анализ этих отчётов позволяет говорить о самом подотчётном лице, сотруднике, о его росте за прошедшее время, о его способностях. Это важно не только для руководителя, но и для сотрудника, когда ему при желании на основании анализа может быть предъявлена реальная его эффективность и прогресс в развитии (на основе набора таких отчётов). Помимо всего прочего — это защита самого сотрудника, т.к. формально является защитной бумагой от начальника, что он работает, а не халтурит, но это в случае терминального сверх-контроля руководства (что случается чаще, чем хотелось бы). И опять-таки на службе у вас как багтрекинговые системы, так уже и монстроподобные системы управления проектом тип Project или даже SAP, но в простейшем случае и функциональность Outlook тоже сгодиться, особенно с допиленной взаимосвязью с офисом. Не усложняйте пятиминутное дело лишними и дорогостоящими нагромождениями.
Уровень проекта:
как правило, это еженедельный отчёт. Над чем работал сотрудник(и), сколько он сделал, сколько осталось. Его назначение — оценить текущее состояние проекта, соблюдение сроков, планирование и риск-менеджмент. Представляет собой формализованный отчёт в установленной в компании форме, обычно с указанием рисков, проблем, путей решения и планов. Заимейте средство автоматизации для их генерации или шаблоны в популярном офисном приложении. Некоторые багтрекинговые системы уже имеют подобную функциональность, так что не брезгуйте и ей.
Уровень аналитики:
квартальные отчёты о проделанной работе. Это список всех проектов, затраченного времени и эффективности. Его назначение — управление и стратегическое планирование. Представляет собой зачастую наглядную визуализацию проектов в виде диаграммы Ганта, графиков для анализа и расчётов, на которых построены эти графики. Содержит рекомендации и выводы. Базу для них можно вытянуть из системы управления проектами или багтрекинговой системы, а вот инструментов для анализа, как показывает практика, всегда не хватает. Да и некоторые проблемы не впишешь в рабочий процесс, поэтому такие отчёты — сродни статье и маленькому исследованию.
Это может быть неприменимо, на первый взгляд, для стартапов, где, по сути, и отчитываться некому. Но и в них, и во фрилансе, как известно, неплохо мотивирует самоконтроль и self-managment. Да и действия удобнее сохранять не в голове, а в той же багтрекинговой системе, быть может, в облачном окружении, чтобы по прошествии времени отследить и найти свои принятые решения и их следствия. Устанавливайте там и цели — рабочие и личные, цели своего развития. Радуйтесь успехам и росту, анализируйте неудачи и трудности. Кроме того, не спрашивайте, что руководство может сделать для вас, а спрашивайте, что вы можете сделать для руководства. Каждую неделю, как заканчивался последний рабочий день недели, я составлял сводный отчёт и по привычке выделял желтым риски, связанные с недостаточной подкованностью в новой для меня платформе. Неделю. Месяц. Два. И нежданно-негаданно мне позвонил босс и прорычал в трубку: «Эй, что можно сделать для подъема эффективности? Мануала почитать недостаточно? Тулзу надо побыстрее?». Для меня этот пункт в отчёте и важен-то не был. Он кочевал из отчёта в отчёт, сообщая о том, что я работаю на собой, разбираюсь с мануалами и форумами, но всё ещё не выполняю свои задания с закрытыми глазами, и тем более в автоматическом режиме спросонья после бурных праздников. А вот для начальства это оказалось хоть мелкой, но назойливой занозой в заднице. Весь эффективный и зелёный отчёт, всё в срок, всё вроде бы и хорошо, а вот одна фраза портила идиллию райских авгиевых конюшен, с которыми я имел дело. И лёд тронулся. Просто и ненавязчиво. Мне предложили решения сверху. Истину говорят на востоке, выпивая рюмки зелёного чая: «Путь в тысячу ли начинается с одного шага». И этот путь для меня незаметно минул лишь благодаря наличию обратной связи.
Отчётность может сильно варьироваться в зависимости от стиля компании, но мой вывод один: какой бы не был формат — ежедневных Stand-up meeting’ов, отчётов в бумагах, в системах управления проектами, багтрекинговых системах, разговоров за утренним чаепитием, отчёты сильно помогают регулировать состояние проектов и жизнеспособность компании. Они в конечном итоге позволяют чувствовать даже самым мелким сотрудникам себя частью чего-то глобального. Что, впрочем, должно быть осознано как цель и как структура для эффективной работы и понимания сотрудниками от мала до велика руководителя, зачем же и для кого он отчитывается, и как этими отчётами пользоваться.
Анализ
В процессе написания этой статьи я спросил своих близких: “Зачем нужны отчёты?”. Я надеялся на примерный ответ из разряда “инструмент контроля и анализа” или, на худой конец “документация”. Но я получил ответ: “Да не нужны они. Нет, конечно понятно, что они нужны, но на практике от них никакого толка, кроме потери времени”. Дело было даже не в непонимании, а в том, что обычно ими пользоваться не умеют, разве лишь для того, чтобы показать начальнику. Но и начальник обычно не использует их далее, чем как приложение к продукту.
Тогда мне стоит привести конкретные примеры использования отчётности.
Ситуация 1. “Возродившийся баг”
Вы, наверное, знаете один из законов Мерфи: “Свойство четности ошибок. Если написанная программа сработала правильно, то это значит, что во время ее работы выполнилось четное число ошибок или программист не понял задание”. Такое, к сожалению, случается чаще, чем этого хотелось бы.
Некоторые задачи требуют значительных вложений времени, и не всегда должны быть завершены. И поэтому во время ловли багов, одна из новых ревизий вполне может стать рабочей до исправления, а баг более не проявляется. Разработчик отрапортует о том, что бага больше нет. Однако причина первоначального бага не будет решена и он спустя некоторое время проявит себя при новых исправлениях. Однако это не значит, что разработчик накосячил и что-то пропустил. У него есть точка опоры и защиты, весомый аргумент. С его точки зрения задача — убрать влияние бага — выполнена, код работает по спецификации, тесты проходят. Но для проекта эта задача может быть переоткрыта, чтобы вычистить и баги, и компенсирующие факторы, чтобы не иметь хвостов в будущем.
Ситуация 2: “Производительность”
В-общем, обычно отчёты нужны менеджерам проекта и task leader’у, который будет распределять задачи и планировать загрузку в зависимости от производительности. Её надо как-то посчитать. Но так же производительность — есть мерило эффективности и развития сотрудника. Помните, что каждый сотрудник посылает еженедельный отчёт в виде time sheet? Теперь посмотрим, сколько времени у него уходит на задания на протяжении времени.
Что мы тут видим? Выполнение задач занимало в день достаточно стабильное время, но с накоплением опыта время, затрачиваемое на задачи начало снижаться (точка А). После введения инструментов автоматизации (Б) был этап отладки, но в итоге время, затрачиваемое на задачи сократилось (В). Тут видно совершенствование и рост сотрудника, его инициативу, повлекшую улучшение работы. Пример достаточно живой, до той поры, пока сотрудник не будет приписывать себе геройства. Но наша багтрекинговая система или дорожная карта, к счастью, отслеживает реально завершенные дела. Поэтому, исключительно для абстрактного примера, можно улучшить такой анализ, просто домножив обратную величину количества выполненных задач на затраченное время для каждого дня.
График получился рваным (я схалтурил, каюсь), но по нему всё равно видна тенденция и влияние интеграции автоматизации. Анализ эмпирических данных от полученных результатов — отдельная тема, которая не является темой данной статьи. Но с привлечением механизма отчётности как работник, так и работодатель имеет неплохой инструмент оценки эффективности. Добавляя к нему оценку ресурсов, затраченных на обучение, можно сделать и другие интересные выводы. В любом случае, для анализа и оценки наличие механизма создания лога (отчёта) — отличное подспорье. Останется лишь мотивировать людей и рассказать, какие возможности представляет деятельность, связанная с отчётностью.
Выводы
Помимо объяснения пользы отчётов и нахождения путей внедрения системы логирования, замечательной практикой будет введение для каждого сотрудника личного time management’a. Если они ещё не пользуются GTD, пожалуйста, расскажите им, как это здорово и приятно вычёркивать задачи. Они делаются, у нас получается, profit! Не вбираясь в дебри этой тематики, лишь с целью, чтобы помимо сухой выжимки из issues дополнить анализ личными делами. Позвольте сотрудникам быть честными. Пусть в ежедневных отчётах они пишут: “Я работал над задачами 3 часа, и изучал Python 4 часа”. Неплохо, но, о боже, мы потеряли час! На самом деле, можно спуститься до изучения, что 20 минут были потрачены на чаепития, 30 на серфинг и 10 — на спор с коллегой. Но, по сути — это личная информация. Мусорное время, которое… Впрочем, стоп! Наша задача не уличить сотрудника в бездействии, а мотивировать его. То, чтобы он не только видел прогресс в количестве исполняемых задач, но и в ежедневной работе над собой. А по отношению к руководству — честность и открытость, чтобы был диалог, построенный доверии и делегировании полномочий с ответственностью. Чтобы в конце концов, в один момент он пришёл к вам со словами “Изучал я изучал Python, и теперь хочу взять свой проект”.
P.S. в статье принципиально не затронута финансовая отчётность, аудиты и табельная отчётность. Ни одна из этих отчётностей не должна касаться и выполняться разработчиком. Если верно обратное, это так же признак проблемы управления. Если, скажем, режим предприятия требует жесткого контроля времени, то это должно быть сделано без привлечения времени инженера-разработчика — автоматической пропускной системой или секретаршей Эллочкой. Если финансовая отчётность требует подписей инженеров-разработчиков, то это так же забота отдела корпоративной отчётности или бухгалтера Эльвиры Михайловны, но никак не повод делать из технического специалиста киборга программиста-бухгалтера-риск-менеджера 2,5 звена.
Автор: wwakabobik
