Трекать задачи что это
Корпоративный трекинг: методология быстрых результатов
Профессия трекера появилась в России в 2013 году, когда Фонд развития интернет-инициатив начал активно инвестировать в IT-стартапы. Нужны были специалисты, которые помогали бы молодым компаниям развиваться быстрее. С тех пор трекинг оброс методологией, инструментами и стал просачиваться во взрослый бизнес. Как и зачем его используют корпорации, рассказал руководитель направления корпоративного трекинга «Акселератора ФРИИ» Дмитрий Губкин.
В целом, трекинг — это микс нескольких методик, таких как Lean Startup, теория ограничений (TOC) и других. Его цель — ускорить рост бизнеса через рост навыков в команде, что также зачастую влечет за собой экономию ресурсов. В роли трекеров обычно выступают действующие либо бывшие предприниматели, консультанты или эксперты в какой-то из ключевых областей — маркетинге, продажах, продакт-менеджменте. Это специалисты с высокой продуктовой насмотренностью и большим опытом работы с командами.
Уже несколько лет мы активно применяем инструменты трекинга в корпоративной среде, и они приносят результаты. Секрет в том, что проблемы и у стартапов, и у зрелых компаний, запускающих новые продукты, одни и те же — найти клиентов, подтвердить ценность, разобраться с аналитикой, настроить продажи. Но специфика корпоративной среды часто подразумевает очень медленные процессы и долгое принятие решений, что противоречит целям внутренних корпоративных предпринимателей.
Внедряя трекинг, мы подсвечиваем проблемные зоны, определяем с каждой командой понятную цель и сроки, синхронизируемся с бизнес-заказчиком по ожиданиям, и в результате даже тяжеловесные бюрократические машины начинают двигаться быстрее, появляется нетерпимость к старым методам. В компаниях внедряются новые продуктовые сервисы в помощь командам, повышается уровень продуктовых навыков и, как следствие, растет выручка.
С точки зрения применения инструментов трекинга большой разницы между корпорациями и стартапами нет, но она зачастую проявляется в формате. Работа с молодыми командами менее формализованная, трекер часто находится в непосредственном контакте с CEO и может быть максимально прямолинейным. В крупных компаниях у трекера добавляется контур работы с бизнес-заказчиком, у которого мотивация и цели могут быть отличны от целей команды. И здесь трекер может выступать фасилитатором, помогая совместить мотиваторы участников с метриками и потенциалом продукта.
Корпоративный трекинг позволяет рассмотреть каждый продукт под микроскопом и объективно оценить его рыночный потенциал и потенциал команды. Главный kpi здесь – рост бизнеса. Чтобы оценить пользу трекера для продукта на ранней стадии, когда продаж еще нет, нужно сформировать набор артефактов, на базе которых можно принимать управленческое решение: «закрыть нельзя инвестировать».
В случае с продуктами на стадии масштабирования ценность от работы трекера более наглядна: это прирост выручки, конверсия в платящего пользователя, снижение оттока клиентов и тд.
Тем не менее работая с корпорациями мы периодически встречаем закономерный вопрос — зачем компании со своим штатом продакт-менеджеров, Agile-коучей и аналитиков еще и трекер? В первую очередь, из-за дефицита продуктовой экспертизы в текущей команде компании. По оценке ФРИИ, в российских корпорациях 85% продакт-менеджеров — «новички» и «середнячки» и только 15% — опытные специалисты. То есть у подавляющего большинства специалистов нет опыта запуска и развития продуктов, в то время как за плечами опытного трекера — сотни успешных кейсов.
Метафорически трекинг — это экзоскелет, т.е. временная поддержка для команд, у которых не хватает внутренних компетенций. С этой поддержкой они начинают бежать быстрее, но что еще важнее — в ускоренном темпе развивают навыки и тренируют продуктовую насмотренность, чтобы дальше бежать уже самостоятельно.
Рост бизнеса всегда происходит только через рост навыков команды. Работая с трекером, видимый прогресс достигается уже через 3 месяца работы.
Трекеры могут работать как c продуктами ранних стадий, когда есть только гипотезы о клиентах и ценности, так и с продуктами на стадии масштабирования, когда выручка составляет сотни миллионов рублей. В первом кейсе ценность от работы трекера обычно в формировании набора артефактов, на основе которого можно принимать решение о пролонгации либо закрытии продукта. Примером артефактов могут быть анализ рынка, расчет юнит-экономики, оценка потенциала продукта и тд. На поздних стадиях запросы более прикладные: рост ключевых метрик продукта, увеличение выручки, запуск продукта в новом клиентском сегменте или рынке.
Чтобы приступить к работе с командами, трекер проводит диагностику бизнеса, в рамках которой анализируются 5 ключевых компонент:
На базе диагностики трекер формулирует гипотезы узкого места в бизнесе и дорожную карту работ по достижению цели команды через формирование новых продуктовых навыков в командах. А дальше начинается регулярная работа с еженедельными спринтами, пошаговым выполнением задач и отгрузкой в команду новых инструментов.
Результат внедрения процесса трекинга в корпорации — это:
Также важно, что после внедрения процесса трекинга корпорации меняют сам подход к работе с новыми продуктами — команды начинают проверять больше гипотез за меньшее время. В среднем, работа команд ускоряется в 2-5 раз, а это значит, что каждая проверенная гипотеза становятся в 2-5 раз дешевле.
Ценность инструментов трекинга подтверждают лидеры рынка — Сбер, Мегафон, Ростелеком и тд. Для них это «допинг», дающий мгновенный результат, в то время как любые внутренние изменения в корпорациях могут продолжаться годами.
Трекинг времени в разработке? Вы просто не умеете его внедрять
Типичная история тимлида. Съездил на конференцию, узнал новые вдохновляющие идеи и загорелся. Начал сходу внедрять то, что (по его мнению) точно сработает, и получил ожидаемый отпор команды: «Зачем нам вообще что-то менять?»
И что же теперь, обходить конференции стороной? Не внедрять изменения в рабочие процессы, пока команда этого не захочет? Совсем нет. На личном примере расскажу, как правильно внедрять новые идеи в работу команды и можно ли собрать целый «фреймворк» для улучшений.
Этот кейс был еще на заре моей карьеры тимлида. Я был молод и не опытен. На одной конференции услышал доклад про метрики эффективной команды и понял, что нам не хватает трекинга времени в задачах. Без этих данных было сложно делать выводы об эффективности. Мы делали много задач, но тонкий fine-tuning в условиях нашей Jira был невозможен.
В докладе, подтолкнувшем к изменениям, готового рецепта не было, поэтому я перешел к самостоятельному изучению теории. Выяснил, что изменения — это досконально изученный и довольно управляемый процесс. А еще они неизбежны: команда вырастет и изменится, сам проект изменится.
Есть множество книг по теории управления изменениями. Придумано много разных методов, метрик и способов их отобразить. Рабочей для меня стала формула успешности изменений Бекхарда, которая выражается простым неравенством:
Заметьте, что в левой части показатели перемножаются, а не складываются. Если мы не работаем с каким-то элементом, он превращается в ноль. И тогда, даже если мы хорошо проработали остальные части неравенства, итоговый эффект будет нулевым.
Здесь нужно рефлексировать: а в чем мое недовольство текущей ситуацией?
Это не про то, что «горит» прямо сейчас, а про потенциальные риски — что-то где-то идет не так и может привести к проблеме. Главное — не натягивайте сову на глобус, не придумывайте проблему. Даже если вам очень хочется внедрить крутой инструмент.
Важно ответить для себя на простые вопросы:
Если ответы есть, это добавит силы вашему изменению. Определившись с болевыми точками, вы поймете, как воздействовать на показатель D, который говорит о вашем недовольстве ситуацией.
После саморефлексии пришло время поговорить с командой. Расскажите, как вы видите проблему, четко, без воды: «Есть наблюдение, мне это не нравится. Что вы сами думаете по этому поводу?»
Выслушайте мнение команды, желательно каждого человека. Вполне возможно, они не видят проблему так же, как вы. Разговор может вылиться в дискуссию, но он даст вам новое видение на ваши опасения, поможет сформулировать, что же на самом деле является проблемой. Здесь мы не только до конца формулируем недовольство ситуацией (D), но и работаем с сопротивлением (R). Уменьшаем его за счет появления точки синхронизации, из которой все одинаково смотрят на проблему.
Как это было в моей ситуации.
Я хотел быть увереннее в долгосрочном планировании, но мне не хватало контекста: сколько мы реально что-то делаем. Плюс хотел удачнее закрывать спринты — на тот момент 40-50% от взятых задач не закрывались.
У команды было желание не таскать задачи из спринта в спринт и не гореть в овертайме. Процесс переноса задач между спринтами или отказ от них сильно демотивировал.
В результате мы пришли к одной боли: мы хотели уменьшить страх от неизвестности объемов задач.
Это очень общее понимание проблемы, но оно неплохо у всех отозвалось. Оказалось, мы испытывали боль не от того, что не успеваем. А потому, что не понимали, какой объем займет работа — было бесконечное месиво из задач, которое сложно объять и понять.
Я тогда выскочил на белом коне: «У нас есть непонимание, так давайте трекать время! Это классная идея!» На что получил реакцию: «А зачем?»
Объясняя эту реакцию, я понял, что трекинг времени — это абсолютно контринтуитивная вещь, которую непросто привнести в мир IT. В заказной разработке эта история еще плюс-минус понятна, потому что заказчик выставляет бюджет и вы в рамках этого бюджета тратите время на решение поставленных задач. В продуктовой же команде вообще нет прямой связи, как работать с оценками времени.
Я вернулся к формуле: наступил момент, когда мы предлагаем решение, выдвигая гипотезу.
Мы не говорим, что точно знаем секрет успеха. Мы делаем предположение: «Вот это, скорее всего, даст нужный результат и решит нашу проблему. Наверное». Ключевое слово — наверное. Это очень важный момент — честно сказать об отсутствии 100% уверенности, что идея сработает.
Так звучала моя гипотеза: «Может, попробуем отмечать затраченное время в задачах? Это даст нам статистику, необходимую для будущего планирования».
После выдвижения гипотезы собираем первичный фидбэк и опасения. Это может быть как «Точно не сработает!», так и техническая мантра, которую мы часто себе повторяем: «Работает – не трогай!»
Часто на реакцию влияет негативный опыт, который был в другой компании или в этой же команде. Вспомнятся все вьетнамские флешбэки. Еще мы склонны возводить дурной опыт в абсолют: «Тогда пробовали, и это не сработало. Было так плохо, что повторять не хочется!»
Будет и страх изменений. Нашему мозгу энергозатратно выстраивать новые нейронные связи, создавать другие паттерны для действий, поэтому мы интуитивно избегаем изменений.
Страхи — это то, с чем нужно работать. Поэтому важно выслушивать и фиксировать все опасения. Делайте это максимально прозрачно, четко проговаривайте: «Так, я услышал это опасение и записал его».
Это уменьшает сопротивление изменения (R) просто за счет того, что человек понимает, что к нему прислушиваются.
Мы с командой выявили три опасения:
Мне эти опасения тоже откликались. Но на тот момент я прекрасно осознавал, что у меня нет решения, которое бы их снизили. Чисто интуитивно я предложил просто попробовать.
Удивительно, но команда согласилась. Я всего-то заменил «нужно трекать время» на «давайте попробуем трекать время». В чем же тут разница?
Я снова обратился к теории и выяснил, что «давайте попробуем» воспринимается как «интересно, безопасно и не навсегда». Мы не обязываем людей что-то делать, а проводим эксперимент. Всем интересно, каким будет результат. Некоторых подстегивает возможность доказать лиду, вернувшемуся с конференции, что он ошибается.
Здесь мы начинаем делать первые шаги (F). Волшебство работает, потому что мы проработали проблематику, Vision, и у нас еще остался большой запас инерции.
Но, конечно, без конкретного плана действий ничего не выйдет.
Во-первых, важно четко описать инициативу и зафиксировать этапы внедрения. В чем цель эксперимента, какие у него сроки? Необходимо установить контрольные точки внутри и определить метрики успеха эксперимента. Опирайтесь на ранее зафиксированные опасения — подтверждаются ли они в ходе эксперимента или нет.
Для синхронизации хорошо подходят ретроспективы. Если у вас SCRUM-like мир или просто SCRUM, который работает на 100%, такие периодические встречи очень удобны. Вам не придется проводить дополнительные мероприятия для обсуждения внедренного изменения.
Здесь вы работаете на Vision (V), потому что есть конкретный план внедрения изменения. Также мы уделяем время первым шагам (F): мы услышали существующие опасения и рассмотрели их на первом этапе синхронизации. Все это также уменьшает сопротивление (R). Люди видят, что все ими сказанное было учтено, что их мнение важно.
В результате у нас с командой получился следующий план:
Цель: проверяем гипотезу, что трекинг времени даст нам статистику для планирования, то есть мы сможем собирать аналитику и делать выводы.
Контрольные точки: ретроспективы каждого спринта.
Метрики: Количественная — более 80% задач, взятые в спринт, выполняются. Качественная — ощущение страха перед неизвестным уменьшилось. Страх практически невозможно измерить объективно, но можно оценить по ощущениям.
Мне бы хотелось написать, что после старта все было весело и прекрасно, но это не так. Все трудности вскрылись на первом же этапе.
На первой ретроспективе я получил фидбек, что «все ломается, рушится и ничего не работает». Из трех опасений не сработало только первое, про недоработку часов. Два других проявили себя во всей красе: половина команды забывала трекать время, а множество переключений лишь ухудшали ситуацию.
Проблемы точно будут. Это единственное, в чем можно быть уверенным на 100%. Важно не останавливаться.
Опасения сбывались, появились первые предложения забросить эксперимент. Здесь важно поддержать первоначальную идею: «Мы же хотим проверить нашу гипотезу. Мы столкнулись с проблемами, которые подтвердили некоторые опасения. Но давайте попробуем что-то с этим сделать».
Это «Давайте попробуем» будет с вами на протяжении всего пути внедрения изменений. Результаты можно получить, только реально пытаясь что-то сделать.
Важно друг друга поддерживать. У некоторых ребят получалось трекать время, и они делились своим опытом. Их пример помогал разрушать опасения коллег — все поддерживали и были готовы услышать друг друга.
Мы не изобретали сложных инструментов. Попробовали Toggle, который позволял быстро переключаться между задачами. Немного помогла техника Pomodoro.
Очень важно не пропускать контрольные точки, чтобы не упустить момент, когда что-то пошло не так. Не скипайте ретроспективы, иначе у вас накопится такой ворох нерешенных вопросов, что вы его не сможете разгрести и сдадитесь.
Ведите процесс прозрачно. Это не должно быть исследование, которое вы ведете в секретных дневниках, как тайный гуру. Все договоренности и зафиксированные опасения должны быть максимально публичными.
Будьте честны с командой и с самим собой. Важно озвучить, что вы сами не знаете, что получится в итоге. Повторяйте, что эксперимент безопасный, потому что он конечный и короткий по времени. Мы просто проверяем, получится или нет, и сделаем какие-то выводы по итогу.
Такая работа над снижением сопротивления (R) должна быть на всех этапах эксперимента. Важно, чтобы команда вам доверяла. Вы как лид этот процесс фасилитируете, но не ведете людей за ручку к целям, которые интересны только вам. Потому что проект — не лида, а команды. Вы делаете что-то вместе и меняете команду к лучшему. Дополнительные бенефиты достигаются за счет того, что вы сплачиваете команду не вокруг рабочих процессов (выполнения задач и реализации продукта), а вокруг идеи «самонастройки».
В конце мы проверяем, сработало или нет. Для этого замеряем целевые метрики, которые можно собирать как в процессе, так и в конце эксперимента. Если сработало, забираем в работу.
Если не сработало, то рефлексируем почему. Здесь может возникнуть соблазн продавить изменение (мы же уже начали), но боритесь с ним. Запишите результат и отложите изменение. Дайте команде понять, что держите слово.
Так мы работаем и с сопротивлением (D), и с недовольством текущей ситуацией (R): проблема осталась, но конкретно это решение для нас не сработало.
Конкретно эта история завершилась успешно, но опыт был разный.
Что у нас получилось:
И самое главное (лично для меня): я понял, что изменения в любом случае происходят. Но есть выбор: слепо им отдаваться или же управлять этим процессом. Пробуйте, экспериментируйте, не стесняйтесь что-то менять. Это интересно!
Видео моего выступления по этой теме на конференции TeamLead Conf 2021 можно посмотреть здесь.
Хотите поучаствовать в разработке облачной платформы Selectel?
Как трекают на удалёнке. Отвечают компании
Коронавирус, разогнав ИТ-компании по домам, заставил задуматься об эффективности распределённой работы. И о том, как сохранить контроль над процессами, не превращаясь в надсмотрщиков и не вгоняя сотрудников в излишний стресс. Пример VironIT показал, что это не так-то просто. Критиковать работодателя за попытки удержать управление — легко, руководить в кризисных условиях — не очень. dev.by предложил вопросы 30 компаниям из списка тех, что перешли на удалёнку.
Коронавирус, разогнав ИТ-компании по домам, заставил задуматься об эффективности распределённой работы. И о том, как сохранить контроль над процессами, не превращаясь в надсмотрщиков и не вгоняя сотрудников в излишний стресс. Пример VironIT показал, что это не так-то просто. Критиковать работодателя за попытки удержать управление — легко, руководить в кризисных условиях — не очень. dev.by предложил вопросы 30 компаниям из списка тех, что перешли на удалёнку.
Конверсия ответов оказалась ниже средней, а значит, проблема актуальна. EPAM и Wargaming от комментариев воздержались. Дюжина компаний не ответила вовсе, парочка пообещала и пропала. Ниже — ответы тех, кто не уклонился. Из 14 компаний 10 время так или иначе трекают, но — уверяют — не злоупотребляют.
Те, кого мы не спросили, но кто хочет ответить, добавляйте ответы в комментариях или присылайте на [email protected]
CactusSoft
Оксана Остапович, СEO:
— CactusSoft частично перешёл на удаленку с 10 марта, полностью — с 18 марта. При этом офис остаётся доступным для сотрудников: кому-то неудобно работать из дома из-за маленьких детей, кто-то работает с документацией, даже приезжали бесстрашные заказчики из Дубая — соответственно команде пришлось работать один день в офисе. Но удалёнщиков большинство, примерно 90%.
На время удаленки действуют простое правило: обеспечение своей доступности по всем каналам связи в рабочее время. Все митинги проходят в режиме онлайн, вместо внутренних митапов — вебинары. Разработчики трекаются в Jira, как обычно; сейлы, маркетинг, эйчары работают на себя и на результат — тут мотивация важнее трекинга.
Наблюдаем даже, что сотрудники «приходят» на работу на удалёнке раньше, уже после 8 утра оживают чаты. В обычное время у нас гибкий график, обязательно прийти в офис нужно до 11.
Я два года работала удалённо на американскую компанию, была единственным сотрудником в Беларуси. Стать человеком-офисом в четырёх стенах поначалу было сложно, пришлось приложить усилия, чтобы поставить на рельсы тайм-менеджмент. Это заняло какое-то время. Поэтому сейчас в ситуации вынужденной удалёнки больших надежд на улучшение KPI мы не возлагаем, однако и ухудшения тоже не прогнозируем. Работа кипит, время трекается, заказчики в основном тоже работают удалённо и реагируют быстро. Flexible working place является одним из HR трендов-2020, для многих сотрудников удалёнка — это дополнительный бенефит. В «Кактусе» уже задумывались глобально о введении удалёнки для определенного слоя сотрудников. Надеюсь, вынужденный эксперимент поможет определиться.
Smart IT
Компания Smart IT работает удалённо с 13 марта. На такой формат работы ушли абсолютно все сотрудники, ребята забрали из офиса технику, руководители помогли обеспечить условия для работы из дома. Все адекватно приняли вводимые меры. В чатах обсуждают, какую еду заказать, какие сериалы скачать, созваниваются по скайпу во время чаепитий.
Сообщение о контроле рабочего времени, которое прислали руководители, прикрепляю скриншотом.
Трекинг времени не изменился — добавили лишь таймер, чтобы понимать, кто сейчас доступен, а кто отошёл.
Значительных изменений в продуктивности не ожидается, в компании и так принято ответственно выполнять свои задачи и работать головой, независимо от условий и места. Такая культура.
SpurIT
Евгений Томашевич, СЕО:
— В связи с переходом на удалёнку новые процессы вводить не пришлось. У нас небольшая часть сотрудников и ранее работала удалённо, никакого контроля за ними нет — они просто указывают в Jira отработанное время. Команда у нас мотивирована на результат, поэтому если кто-то будет халтурить, то получит критические замечания от людей, с кем непосредственно соприкасается по работе.
Ухудшение производительности вполне допускаю, но не ожидаю, что оно будет существенным.
Playtika
— Мы не трекали рабочее время людей до перехода на работу из дома, не трекаем и сейчас. Для нас важны не часы, проведённые за монитором, а результат, выполнение рабочих задач в срок.
На данный момент мы видим повышение эффективности работы сотрудников, тем не менее со временем допускаем некоторое её снижение.
Всё это находится на постоянном контроле менеджеров: мы проводим ежедневные митинги с командами, а также дополнительные с каждым из сотрудников. Цель таких митингов — определить проблемы, мешающие эффективной работе: плохой интернет, отсутствие условий, мебели и т. д.
On The Spot Development
— Системы трекинга рабочего времени у нас нет. С переходом на удалённую работу в этом плане ничего не изменилось. И всё-таки вопрос выполнения задач в срок для нас важен и находится на контроле. В этом помогают ежедневные митинги лидов с командами. Пока продуктивность команд не упала.
iTechArt
— Мы перевели на удалённый формат работы примерно 1000 сотрудников.
Это не карантин, не больничный и точно не каникулы. Ситуация для мировой экономики и бизнеса крайне неспокойная, для нас важно перестроиться и на 100% выполнить договорённости с заказчиками.
Мы не вводим жёсткие системы трекинга рабочего времени и рассчитываем на ответственность и дисциплинированность команды.
ScienceSoft
— Изменений в трекинге времени нет. Как обычно, сотрудник отчитывается о проделанной работе, указывая, сколько времени ушло на каждую задачу. Единственное отличие: раньше отчёты можно было делать за несколько дней, вплоть до недели, а сейчас мы требуем ежедневной отчётности. Изменения больше коснулись руководителей проектов: им нужно внимательно следить за качеством, синхронностью работы сотрудников и производительностью.
Удалённая работа требует большей самодисциплины и самоорганизованности. Если сотрудники не имеют опыта удалённой работы, первые несколько дней уйдут на адаптацию. В дальнейшем, однако, мы ожидаем выхода на прежние показатели.
К тому же удалёнка экономит время — не надо перемещаться между офисом и домом. Поэтому мы ожидаем как минимум сохранения производительности, а в отдельных случаях даже улучшения.
EffectiveSoft
— Сейчас практически вся компания работает в удалённом режиме, но это не сказывается на нашей продуктивности. Большинство сотрудников даже на ремоуте придерживаются стандартного восьмичасового графика. Тем более что у разработчиков всё ещё много митингов — просто они перешли в онлайн (Zoom/Skype). Команды постоянно созваниваются и обсуждают процессы внутри проектов. Это позволяет им держать себя в тонусе и сохранять собственную эффективность. Репортинг времени осуществляется как и раньше. Дополнительных мер по контролю персонала пока вводить не планируем.
Andersen
— Сейчас удалёнщики в рабочее время подключаются через VPN, наш или заказчика, на проекте которого работают.
Время трекаем. Каким образом — коммерческая тайна.
По KPI пока сложно строить прогнозы, но не думаем, что удалёнка сильно скажется [на продуктивности]. Все ведь взрослые люди, у всех есть задачи, которые должны быть сделаны. Сотрудник, задайся он такой целью, точно так же мог бы и в офисе ютубчик смотреть, а не работать.
Qulix System
— Как и раньше, на большинстве проектов время фиксируется через таск-трекинговые системы (Jira, Redmine, GitHub, Trello и др.). Команды работают в общих чатах, проводят митинги, обсуждают вопросы. Основной контроль — качественное выполнение задачи в срок. Также сотрудники фиксируют в своем time sheet, сколько времени на какой проект затратили. Это не нововведение, то же самое они делали и раньше.
Некоторое снижение KPI возможно, пока сотрудники адаптируются к новым условиям работы.
Дома у многих значительно больше отвлекающих факторов. Своих близких тоже нужно адаптировать к новой ситуации, чтобы они понимали, что присутствие дома мамы/папы/супруга/супруги не равно отдыху.
Но мы ожидаем, что спустя некоторое время при правильной самоорганизации производительность вернётся на прежний уровень. У нас не все сотрудники перешли на удалённую работу. Есть те, кто продолжает приезжать в офис — это их личный выбор, они сразу сообщили, что не смогут работать из дома по разным причинам.
Gismart
Евгений Нагель, директор минского офиса:
— В Gismart сейчас больше 300 сотрудников в четырёх офисах (Минск, Лондон, Киев, Пекин), поэтому работа в распределённых командах для нас привычна. Конечно, в условиях массового перехода на удалённый режим работы количество онлайн-митингов увеличилось, но эффективность работы осталась на прежнем уровне. У нас работает линейная структура управления. С одной стороны, она предполагает достаточно большую свободу и даёт возможность влиять на продукт, процессы и реализовывать свои идеи. С другой — это высокая ответственность за результат. Мы не пользуемся тайм-трекингом, а ориентируемся на выполнение поставленных задач. И можем с уверенностью сказать, что система работает.
В конце 2019 года, например, мы всей компанией выезжали на неделю во Вьетнам, чтобы совместить работу с отдыхом. Отсутствие привычного офиса и процессов не стало помехой.
Наоборот, результатом поездки стал прототип нового мобильного продукта, который в случае успешных тестов будет реализован.
К слову, наш офис в Пекине уже возвращается к привычному формату работы, ситуация в Китае стабилизируется.
ID Finance
— В нашей компании процессы отлажены и могут вестись удалённо в любое время, не только в периоды всеобщей необходимости. Для эффективной работы самих сотрудников у нас разработана система в Jira, в которой сотрудники могут трекать свое рабочее время по каждой задаче и где отмечается прогресс.
Мы ввели удалённый режим работы по желанию. Кому-то удобнее находиться дома, а кто-то по-прежнему приезжает в офис. Лид изначально распределяет задачи и обязанности каждого сотрудника своей команды и далее контролирует их выполнение. Ребята заточены на то, чтобы всё было сделано в срок, без отставания от плана. Внутреннее чувство ответственности у наших ребят есть по умолчанию, поэтому удалёнка никак не влияет на эффективность работы.
Expert Soft
— С введением remote у нас ничего не изменилось. Наша цель, как и раньше, реальные результаты работы (качественно выполнить задачи в те сроки, которые согласованы с тимлидом, PM или клиентом в рамках плана). Наши сотрудники должны быть на связи в рабочее время и присутствовать на всех плановых проектных митингах и стендапах. Но для них это само собой разумеется, одно из проявлений личной ответственности. Поэтому внедрение каких-либо трекингов и систем контроля не планируется.
Конечно, удалённая работа отличается от офисной, мы впервые столкнулись с remote для всей компании, и игнорировать это нельзя. Но у нас профессиональные и ответственные ребята, и эти качества не меняются с переменой локации. Могут возникать какие-то моменты, которые потребуют больше времени на анализ и разбор ситуации, но мы к этому готовы.
Наша компания и до эпидемии COVID-19 всегда гибко подходила к рабочему графику сотрудников. Если требовали обстоятельства, сотрудники и раньше могли работать вне офиса по согласованию со своим непосредственным руководителем. Поэтому не думаем, что KPI сотрудников ухудшатся. Если же улучшатся, то будем только рады.
Lunas
— Глобально в системе контроля почти ничего не изменилось, разве что текущие обсуждения перешли в онлайн. Время 3D визуализаторов трекаем так же, как делали это в офисе; время менеджеров не трекаем. Дело в том, что, мы занимаемся не совсем ИТ-разработкой (хоть у нас и есть софтверные продукты), а 3D-визуализацией и VR-турами, поэтому у нас более короткие и интенсивные проекты, и даже без трекинга рабочего времени мы можем судить о KPI сотрудников. Мы ежедневно отправляем превью 3D-изображений и анимации, вносим правки, общаемся с заказчиками и т. д.
Таким образом, ухудшения KPI мы не ожидаем. К тому же у большинства наших визуализаторов в прошлом есть опыт работы фрилансерами, это позволяет им грамотно и эффективно использовать и распределять время дома, в привычной обстановке.