Как мы пытались заменить менеджера небольшим скриптом на питоне

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

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

Меня зовут Денис Стебунов, и я руковожу компанией ivelum. В этой статье я расскажу, какие эксперименты мы проводили в нашей компании.

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

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

Вот и день хакатона. Что будем программировать?

После короткого брейншторма, мы решили попробовать решить проблему с зависающими коммуникациями по задачам. Мы ведем работу в Jira, и значительная часть общения происходит там в виде комментариев к задачам. Задержки в ответах на вопросы были серьезной болью во всех наших командах. Как разработчики, так и постановщики задач периодически сталкивались с отсутствием своевременных ответов на задаваемые ими вопросы. Это тормозило прогресс и требовало регулярных “пинков” для продвижения дела вперед. Иногда авторы вопросов уже и сами начинали забывать о том, что спрашивали, поэтому менеджеру приходилось следить за подобными ситуациями и вмешиваться при необходимости.

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

В итоге появился бот для Jira, которого мы назвали Jirobot. Он автоматически обнаруживал неотвеченные вопросы в задачах, пытался понять, кому они адресованы, и деликатно напоминал людям, что кто-то ждет от них ответа. Мы постарались, чтобы наш бот не был назойливым и бестактным. Он не беспокоил людей по ночам и выходным, а накопившиеся вопросы “пучковал” в одно письмо, которое отправлял человеку утром в начале его рабочего дня. Также он игнорировал вопросы, которые были заданы слишком давно, так как ответы на них, наверное, уже не были актуальны. Сергей задеплоил наше творчество на Heroku, и мы, уставшие, но довольные, отправились отсыпаться.

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

Здесь стоит пояснить, что Jira, в которой мы запустили этого бота, использовалась нами совместно с партнерами из США. Их организация в несколько раз крупнее нашей, и они ведут в Jira не только разработку программных продуктов, но также и работу над контентом, поддержку пользователей, внутренние процессы компании, работу с потенциальными контрактами и т.д. Жиробот же, как выяснилось, не разбирался в чинах, званиях и организационной структуре, поэтому он прошелся по всем проектам всех подразделений и порекомендовал большому количеству людей, включая топ-менеджеров, чем им стоило бы заняться сегодня.

Люди отреагировали по-разному. Многие действительно ответили на вопросы (ура!). Кто-то вступил в переписку с ботом и стал объяснять ему, что был в отпуске и не мог ответить раньше. А кому-то это все не понравилось, и люди стали спрашивать “что происходит” и требовать прекратить. Мы попытались внести быстрое исправление, ограничив набор проектов для бота только теми, которые непосредственно касались наших команд. В таком режиме бот прожил еще несколько дней, после чего его окончательно забанили: некоторым людям, среди которых были топ-менеджеры, не понравилось, что им внезапно, да еще и так явно, стали напоминать, что они тормозят процесс. В результате проект нам пришлось похоронить.

Стоя с непокрытой головой у могилы жиробота, я размышлял, что же привело нас к неудаче. По-видимому, наша главная ошибка состояла в том, что мы попытались провести изменение в организации, положившись исключительно на технические средства. Мы не устроили широких обсуждений на эту тему, не сделали анонса с демонстрацией будущих изменений и не дали людям возможности высказаться перед тем, как изменения вступят в силу. Стоит ли удивляться, что у некоторых из них возникло отторжение? Кажется, в этот раз мы нарушили все возможные рекомендации по внедрению изменений в организации.

Мы забыли об эксперименте с жироботом на несколько месяцев. Однако идея автоматизации менеджерской рутины продолжала жить где-то на задворках моего подсознания. В следующий раз она всплыла в контексте отчетов для продакт-менеджеров о том, что команда сделала за прошедшую неделю. Мы регулярно общались с ними по этой теме, и каждый раз информацию нужно было собрать и подготовить к митингу вручную. Я подумал: “А что если взять информацию о движениях задач в Jira, добавить к этому коммиты из Github, слегка присыпать упоминаниями обсуждавшихся задач из Slack и подать на недельном графике, на котором было бы видно работу как каждого разработчика в отдельности, так и всей команды в целом?”. У нас уже была интеграция с Jira из предыдущего эксперимента с жироботом, оставалось добавить Github, Slack и придумать, как это все будет выглядеть. К сожалению, у меня не сохранилось скриншотов, как выглядела самая первая версия (или к счастью, потому что выглядела она не очень), но сегодня эта функция имеет вот такой вид:

Как выяснилось, такая картинка может быть интересна сразу для нескольких целей: и для демонстрации, чем команда занималась в течение недели, и для выявления “затыков” у разработчиков, и в более долгосрочной перспективе — для проведения Performance review. Немного неожиданным оказалось, что интерес к новому инструменту проявили не только менеджеры и тимлиды, но и многие разработчики, которые тоже захотели взглянуть, как их работа выглядит со стороны.

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

Несколько лет назад ситуация с отпусками и другими нерабочими днями у нас выглядела так:

• Бухгалтер обладала тайным знанием, как рассчитывается отпуск, и у кого сколько доступных дней отпуска есть;

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

• Официальная рекомендация, как сотруднику взять себе отпуск, выглядела так: нужно уточнить у бухгалтера, сколько отпуска ему доступно, потом пойти к менеджеру с желаемыми датами, чтобы получить одобрение, и потом пойти обратно к бухгалтеру с заполненным заявлением на отпуск, чтобы она внесла эти даты в график;

• Мы регулярно забывали о праздниках в США, а наши американские коллеги соответственно забывали о наших. Поэтому в задачу менеджера также входило предупреждать все команды о праздниках заранее, чтобы люди могли учесть это при планировании задач.

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

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

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

(Disclaimer: ни одного зайца в результате этой работы не пострадало)

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

Но результат того стоил! Мы наконец получили явную, общедоступную и достоверную картину присутствия людей на работе, а любой сотрудник теперь мог самостоятельно добавить себе отпуск или больничный, не отвлекая бухгалтера или менеджера. Все это интегрировано со Slack в виде автоматических напоминалок и с возможностью добавления отпуска/больничного прямо из Slack. Визуализация работы команды также стала гораздо более достоверной: теперь прямо на графике видно, какие дни у каждого человека являлись или будут являться рабочими.

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

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

В итоге в дополнение к напоминалкам про нерабочие дни у нас появились еще несколько, касающихся непосредственно рабочего процесса:

• Дедлайны. Очень простая и крайне эффективная напоминалка. Оказалось, достаточно за несколько рабочих дней напоминать команде, что по какой-то задаче надвигается дедлайн, чтобы жалобы на пропущенные дедлайны полностью прекратились. Не потребовалось даже никакой хитрой логики с вычислением времени напоминания в зависимости от объема задачи: простая настройка “заранее за 3 рабочих дня” прекрасно работает в наших условиях.
• Неотвеченные вопросы в задачах. Та самая напоминалка, с которой все начиналось, но теперь переписанная на новый лад. Иногда, правда, ошибается с определением адресата, и я даже знаю почему. Скоро поправим.
  
• Обновления задач. Сигнализирует о том, что по задаче, взятой в работу, давно не было никакого движения, и просит отписать комментарий, как идут дела.
  
• Наличие задачи в in progress. Следит за тем, чтобы у каждого разработчика в команде была какая-то задача в работе, и чтобы такая задача была ровно одна. Помогает поддерживать прозрачность работы, чтобы в любой момент времени было понятно, кто чем занимается.
  

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

• Командный отчет о проделанной работе за неделю. Подводит итоги для продакт-менеджеров. Комбинирует автоматически собранную информацию с вручную написанными комментариями.

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

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

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

Конечно, мы не рассчитывали всерьез “заменить менеджера небольшим скриптом на питоне”. Да и скрипт, честно говоря, получился большой. Однако проект прижился и экономит наше время и нервы уже третий год. Изначально задуманный как помощник для менеджера, он в итоге превратился в помощника для всей команды. Сегодня уже даже сложно представить, как бы мы жили без него.

Идей по развитию множество. Например, мы хотим интегрировать Zoom. Телемосты (да и “обычные” оффлайновые митинги) могут быть как мощным инструментом для продвижения проекта вперед, так и не менее мощным убийцей рабочего времени, если используются неправильно. Мы хотим понимать, что применяем их правильно, и для этого было бы полезно, как минимум, видеть, какую часть рабочего времени они у нас занимают.

Еще одна большая идея, которую мы уже начали внедрять — предложить наш инструмент другим компаниям. Если он так хорошо работает для нас, может быть, будет полезен кому-то еще? Разумеется, с названием “жиробот” такого сделать было нельзя по очевидным причинам, да и сам проект уже давно был не только про Jira. Поэтому мы переименовали его в более благозвучное Teamplify и попробовали рассказать о нем друзьям и знакомым. То, что происходило дальше, наверное, уже выходит за рамки этой статьи. Отмечу только, что между внутренним проектом компании и публичным продуктом оказалась пропасть, но вроде мы выкарабкиваемся, и у нас уже появились первые постоянные пользователи — около десятка компаний.

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