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

... и что из этого вышло

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

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

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

Предыстория

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

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

Хакатон

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

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

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

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

Jirobot: Mission Impossible

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

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

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

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

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

Вторая попытка: визуализируем работу

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

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

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

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

Автоматизируем учет нерабочих дней

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

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

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

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

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

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

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

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

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

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

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

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

Возвращаемся к автоматическим напоминалкам

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

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

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

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

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

Чему мы научились

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

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

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

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

Дальнейшие планы

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

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

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

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

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

2626
9 комментариев

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

4
Ответить

Денис, спасибо за классную статью! И первый скрин загруженности по проектам показывает ещё аудитории vc - какой вы замечательный трудоголик ;)

2
Ответить

спасибо :)

Ответить

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

Учесть "даем ли лишние дни авансом" тоже.
А вот учесть  видение менеджера  кому нельзя пересекаться, кому "совсем нельзя", кому "нельзя но на n дней можно" гораздо сложнее.

Оттого простой итог - таблица, где сотрудник предлагает время а ответственный(ные) согласует.

Ответить

к моему удивлению, тут получилось наоборот :) В технической части определения "сколько у меня есть отпуска" оказалось достаточно много нюансов, просто перечислю несколько, чтобы дать представление:

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

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

А вот момент с определением кому можно пересекаться, а кому нет, как ни странно выглядит проще. В нашей компании это описано в корпоративной вики https://github.com/ivelum/job/wiki/Отпуск, и люди просто соблюдают это сами, не требуется никакого особого надзора. Разумеется, не у всех это так, поэтому для тех у кого правила более сложные, есть опция "статус требует утверждения" - если она включена, то менеджерам приходит уведомление о запросе отпуска или другого вида нерабочего дня с кнопками "разрешить" и "отклонить", и дальше они уже могут зайти в систему, там будут видны пересечения на графике, и принять решение.

2
Ответить

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

А как технически задавались вопросы?
Почему нельзя было создать подзадачу с вопросом и назначить сразу на исполнителя?

Ответить

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

1
Ответить