Все верно. Мы не позиционируем Asana как софт для управления разработкой. Скорее, это платформа, в которой можно организовать единое информационное поле компании. Часто отдел разработки в компании является отдельным миром, с которым трудно найти контакт другим подразделениям. И когда нужна помощь разработки, нужно пройти 9 кругов ада. В лучшем случае — всей команде освоить Jira, чтобы их задачи сдвигались с места. В худшем — вообще перестать рассчитывать на участие разработчиков в проектах компании)
Хорошее замечание про то, что изменения не затронули производственную часть компании. Но мы не можем принять решение за компанию. Переход в Asana еще продолжается, в крупных компаниях из 1500 человек сложно и опасно менять все по щелчку пальцев.
Мы многое не можем показать. В кейсе всего один скриншот и, действительно, не очень много конкретики, так как процессы и конкретные методологии являются закрытыми данными компании. Но производство чаще всего — уже хорошо поставленный процесс. И удаленка его практически не коснулась. Поэтому там формат взаимодействия остался прежним, в режиме офлайн.
А вот управление компанией перенесено в Asana. Хороший пример — с протоколами, которые раньше велись на бумаге. Руководители департаментов получали задачи и должны были собрать их из десятков разных протоколов, расставить приоритеты, ничего не потерять. Объем задач был настолько большим, что у идей без пометки «Срочно» почти не было шансов на реализацию. Теперь все иначе. Нам кажется, это большое достижение нашего клиента. Кроме поставленного процесса производства есть стратегия, бухгалтерия, IT, коммуникации с подрядчиками, клиентами, PR и GR, юристы — в общем, довольно большое количество департаментов, которые влияют на финансовый успех компании. Над их эффективностью мы и работали в этом проекте.
Это не реклама Asana, хотя мы ее очень любим и активно используем. Восточная горнорудная компания — наш клиент. Мы же занимаемся построение систем продаж и облачных инфраструктур для разных бизнесов в нашей стране) Компания RocketSales, рады знакомству.
По поводу недостатков Asana. Я много лет тестировал разный софт для проджект менеджмента. И на Asana мои поиски остановились. Работает у нас быстро, писем не шлет, URL не меняет, если прикрепить еще к нескольким проектам, но не откреплять от первоначального.
Мы еще написали бота, который при отправке в Телеграм ссылки на таск в Asana меняет ссылку на название задачи и становится понятно, по какому поводу тебе задают вопрос. В общем, в Asana работают все отделы нашей компании, включая разработку, маркетинг, проектный отдел, бухгалтерию. Если интересно — могу скинуть обзор, как это работает и как мы допилили Asana, чтобы учитывать время по задачам. В общем, свою Asana мы активно дорабатываем под себя)
Когда люди ушли на удаленку, офисов стало не 2, а 100) У каждого офис был в пределах его дома. Если раньше можно было хотя бы примерно регулировать деятельность сотрудников, коммуницируя с ними лично, то теперь руководитель мог только написать или позвонить сотруднику. Отстутствие единого информационного пространства блокировало общение сотрудников. Если маркетологу нужно было подключить к задаче разработчика, он обращался к своему руководителю, сколько-то ждал, напоминал, его руководитель обращался к руководителю отдела разработки, руководитель отдела разработки передавал задачу сотруднику. Все это через чаты, скайпы, письма. Задача могла дойти совсем в другом виде и через много-много времени.
Людей, который используют один софт стало примерно на 350 больше. И это дало очень сильный эффект для всей компании.
что помешает удаленному сотруднику смотреть сериалы на телефоне или планшете? Если система не способна этому помешать, что зачем она нужна? Скриншоты приходится просматривать, сколько рабочего времени уходит на это?
Ничего не помешает. Если цель сотрудника — смотреть сериалы, мы, вероятнее всего, увидим низкую эффективность в выполнении задач и все равно с ним распрощаемся. Хотя, когда смотришь сериал, вряд ли получится активно использовать клавиатуру и переключаться между вкладками браузера, например. Тайм Доктор при получасовой низкой активности спрашивает, точно ли сотрудник занят делом. И запускает минутный обратный отсчет. Не нажал «Да» за минуту — Доктор обнулил полчаса работы. Но вообще, конечно, это больше психологический инструмент, чем контролирующий. Сотрудник знает, что за ним присматривают, и правильно планирует время. Мы редко просматриваем скриншоты, только если есть вопросы к сотруднику.
что вы понимаете под эффективностью выполнения задач разработчиком? И как оцениваете качество выполненной разработчиком задачи?
Я говорил не только про задачи разработчиков, а про задачи всей команды в целом. Эффективная работа в нашем понимании — это когда:
— у всех задач в Asana проставлены сроки и дедлайны,
— задачи закрываются в срок и принимаются руководителем (принимает он, соответственно, только хорошо сделанную работу),
— нагрузка распределена равномерно, нет дней, в которые нечего делать и дней, когда невозможно успеть все, что запланировано,
— отработано минимум 95% установленного регламентом времени (8 часов в день),
— в задачах (в комментариях, в статусах, в описании) видна динамика, есть прогресс, есть коммуникации внутри команды.
В случае с разработкой любой результат проходит тестирование нами, клиентом, проверяется на наличие багов или на возможности доработок. Если задача выполнена в срок на высоком уровне и результат нравится клиенту, то она была выполнена эффективно.
Из каждого правила есть исключения, не так ли? Как вы имеете дело с такими сотрудниками?
Конечно, у нас на этот случай 2 решения:
1) Рабочий процесс — это часть нашей корпоративной культуры. В него входит использование тайм доктора на постоянной основе. Менять работающий и дающий плоды процесс ради сотрудника мы не будем. Ты либо принимаешь наши правила игры, либо нет. Во втором случае — мы просто не будем работать вместе)
2) Мы честно и открыто поясняем как и для чего используем тайм доктор. Он помогает сотруднику управлять своей деятельностью, планировать рабочее время. Скриншоты без повода никто не просматривает. Нет цели поймать на чем-то или, не дай бог, изучать переписки. Обычно именно за переписки больше всего переживают. Что они попадут на скрин и мы о них узнаем. Переписываться не по работе можно после раб дня, гадости про нас писать нет смысла — мы открыты к переменам и диалогам, всегда можно прийти и сказать прямо, что не нравится. В общем, за все время не было ни одной неприятной истории из-за тайм доктора.
Кто же определяет сложность задач? На что он ориентируется? Может ли способный сотрудник брать себе только сложные? В итоге оклад сотрудника определяется количеством сложных задач, которые компания может ему предоставить? Крайне любопытно, как задачи распределяются по сложности между сотрудниками.
Сложные задачи у нас являются премиальными. Сложность определяет руководитель, исполнителя тоже. Он это делает на основе набора задач, которые нужно решить в проекте. Подбирает команду, опираясь на нужные и имеющиеся компетенции. Тут мы Америки вам не откроем) Нет сотрудников, которым достаются только сложные задачи. Но способные сотрудники могут выполнять больше премиальных в силу того, что работают эффективнее остальных. Так можно влиять на свой ежемесячный доход)
Будем называть ее ERP RocketSales) мы в статье не говорили о том, как управляем закупками и пр. Хотели рассказать именно про опыт управления человеческими и временными ресурсами, а также стоимостью и длительностью проектов.
Спасибо вам за то, что сделали акцент на бухгалтерию и управ.учет.
Главная задача ERP в нашей компании — управление ресурсами (финансовыми и человеческими). Мы видим все проекты компании, время, затраченное на их реализацию, их себестоимость и прибыльность. Видим какие сотрудники задействованы в каждом из проектов и в какой объеме. Отдельно можем посмотреть срезы по каждому сотруднику: над чем работал, сколько нам, как работодателям, это стоило. По отделам, по месяцам, по проектам — срезать можно как угодно. Эти данные, как раз, позволяют управлять персоналом (мы такое слово не используем в компании) и ресурсами компании в целом. Может быть, на скриншотах, которые мы показали, это не совсем понятно… Или в чем-то другом вопрос?
Цепочки поставок, закупки и запасы — не про нашу сферу деятельности. Мы больше за адаптированные инструменты, которые помогают бизнесу, а не вынуждают впихивать свои потребности в рамки классических процессов)
Да, наивность в то время точно была нам присуща. Но, с другой стороны, если бы мы знали, что разработка займет год и не закончится до сих пор, может и не решились бы на нее вовсе.
Мы много времени уделяем организации процессов. Всегда уделяли. Тестировали платформы для управления проектами, пробовали разные методы управления. И, конечно, даже без ERP справлялись неплохо. Но был большой пробел — мы видели сколько работаем, видели над какими проектами работаем, сколько зарабатываем, но не могли понять, как долго мы работали над конкретным проектом и сколько денег он принес. Нужен был интерфейс, которые соединит пазлы.
Это которые выглядят а-ля 1124785706319289? Такие ID крайне неудобно использовать в обсуждении, именах веток и описаниях PR.
Теперь поняли, о каких именно вы идентификаторах. Когда дойдём до плотной интеграции Asana и Gitlab, скорее всего будем генерировать короткие легкочитаемые коды (в Asana есть возможность присваивать таскам кастомные поля). Хотя, перед проектированием ещё раз подумаем о целессообразности этого, в тех же PR можно просто оставить линк на задачу в Asana. Или вовсе организовать работу из Asana (прокидывать туда уведомление со ссылкой на PR, чтобы главным агрегатором информации и «побуждений к действию» всё-таки оставалась Asana)
Было бы очень интересно почитать детальнее, как именно Вы это настраиваете. Именно в разрезе интеграции с репо/ветками/PR/мержами.
Статусы меняются автоматически между связанными проектами, например, между проектом тех. поддержки и бэклогом разработки. В разрезе интеграции с гитом автоматической смены статусов нет, так как нет и самой интеграции. Это наши следующие шаги по автоматизации, ведь мы и сами понимаем, сколько человеческого фактора сейчас имеется в текущей схеме
Так у всех. Но вот разработчикам нужны другие задачи, более мелкие и относящиеся ровно к одному репо — потому что изменения кода они ведь отправляют в один репо за раз.
В ситуации, когда нет плотной интеграции с Git’ом, не всегда есть смысл делить задачи например на «Сделать форму конфигурации для чат-бота», «Реализовать аутентификацию в чат-боте», «Реализовать бизнес-логику чат-бота», когда всеми задачами занимается один и тот же исполнитель и отвечает за весь результат целиком (ему и время трекать удобнее, ведь не нужно «скакать» между задачами в тайм-трекере, не всегда возможно делать связанные задачи «строго по очереди»)
Но это всё равно не отменяет того, что к такой интеграции мы идём, просто при проектировании нужно понять, какая схема будет удобна всем (начать хотя бы с вопроса о том, всегда ли стоит разбивать задачи, возможно стоит привязывать несколько веток из разных репо к одной задаче в Asana). Мы хотим автоматизировать процессы и меньше бегать между двумя интерфейсами (Asana, GitLab). Но при этом не хотим, чтобы какое-либо решение вносило «многословность», перегружало другие отделы информацией и плодило задачи только потому, что плохо продуманная интеграция диктует свои правила и вставляет палки в колеса.
Может быть у вас есть статьи/материалы по успешным кейсам интеграции между системой управления проектами и системой контроля версий, в компаниях, которые используют тайм-трекер и это не «компании одного продукта»? Мы будем очень благодарны!
powerman спасибо за содержательный комментарий. Согласен, что у разработки свои серьезные требования к трекеру. Мы сильно заморочились со статусами, видами досок, бизнес-процессами в Asana. Поработали над мотивацией сотрудников работать вместе в одном инструменте. Пока выходит неплохо, хотя, безусловно, ещё осталось пространство для автоматизации. Мы продолжаем проектировать процесс так, чтобы это было удобно всем
Из перечисленных вами фич, которыми должен обладать трекер, в Asana есть добрая половина. ID задачи мы получаем в адресной строке. Статусы меняются автоматически. Уведомления работают. Есть процессы, которые позволяют автоматически отправлять задачи на оценку разработчикам, на оплату в бухгалтерию, подробности запросов автоматически подтягиваются в описание задачи.
Мы, преимущественно, работаем с бизнес-задачами. И далеко не всегда они связаны с одним репозиторием. Это бывает 2, а то и 3 репозитория. Мы не организовываем бэк, фронт (+ иногда расширение) в монорепозиторий.
Так как Asana используется всеми отделами нашей компании, а не только разработчиками, то острой нужды уведомлять постановщика (менеджер проекта в случае с клиентской разработкой, сотрудник технической поддержки в случае бага, руководство в случае разработки какой внутренней фичи) о том, что коммит исполнителя сейчас находится на ревью или его «слили» в мастер — нет, ему это не очень интересно и от отдела разработки он ждёт условного «Готово, принимайте».
Asana довольно гибкий инструмент, поэтому мы верим, что его получится довести до совершенства.
Мы многое не можем показать. В кейсе всего один скриншот и, действительно, не очень много конкретики, так как процессы и конкретные методологии являются закрытыми данными компании. Но производство чаще всего — уже хорошо поставленный процесс. И удаленка его практически не коснулась. Поэтому там формат взаимодействия остался прежним, в режиме офлайн.
А вот управление компанией перенесено в Asana. Хороший пример — с протоколами, которые раньше велись на бумаге. Руководители департаментов получали задачи и должны были собрать их из десятков разных протоколов, расставить приоритеты, ничего не потерять. Объем задач был настолько большим, что у идей без пометки «Срочно» почти не было шансов на реализацию. Теперь все иначе. Нам кажется, это большое достижение нашего клиента. Кроме поставленного процесса производства есть стратегия, бухгалтерия, IT, коммуникации с подрядчиками, клиентами, PR и GR, юристы — в общем, довольно большое количество департаментов, которые влияют на финансовый успех компании. Над их эффективностью мы и работали в этом проекте.
По поводу недостатков Asana. Я много лет тестировал разный софт для проджект менеджмента. И на Asana мои поиски остановились. Работает у нас быстро, писем не шлет, URL не меняет, если прикрепить еще к нескольким проектам, но не откреплять от первоначального.
Мы еще написали бота, который при отправке в Телеграм ссылки на таск в Asana меняет ссылку на название задачи и становится понятно, по какому поводу тебе задают вопрос. В общем, в Asana работают все отделы нашей компании, включая разработку, маркетинг, проектный отдел, бухгалтерию. Если интересно — могу скинуть обзор, как это работает и как мы допилили Asana, чтобы учитывать время по задачам. В общем, свою Asana мы активно дорабатываем под себя)
Людей, который используют один софт стало примерно на 350 больше. И это дало очень сильный эффект для всей компании.
Ничего не помешает. Если цель сотрудника — смотреть сериалы, мы, вероятнее всего, увидим низкую эффективность в выполнении задач и все равно с ним распрощаемся. Хотя, когда смотришь сериал, вряд ли получится активно использовать клавиатуру и переключаться между вкладками браузера, например. Тайм Доктор при получасовой низкой активности спрашивает, точно ли сотрудник занят делом. И запускает минутный обратный отсчет. Не нажал «Да» за минуту — Доктор обнулил полчаса работы. Но вообще, конечно, это больше психологический инструмент, чем контролирующий. Сотрудник знает, что за ним присматривают, и правильно планирует время. Мы редко просматриваем скриншоты, только если есть вопросы к сотруднику.
Я говорил не только про задачи разработчиков, а про задачи всей команды в целом. Эффективная работа в нашем понимании — это когда:
— у всех задач в Asana проставлены сроки и дедлайны,
— задачи закрываются в срок и принимаются руководителем (принимает он, соответственно, только хорошо сделанную работу),
— нагрузка распределена равномерно, нет дней, в которые нечего делать и дней, когда невозможно успеть все, что запланировано,
— отработано минимум 95% установленного регламентом времени (8 часов в день),
— в задачах (в комментариях, в статусах, в описании) видна динамика, есть прогресс, есть коммуникации внутри команды.
В случае с разработкой любой результат проходит тестирование нами, клиентом, проверяется на наличие багов или на возможности доработок. Если задача выполнена в срок на высоком уровне и результат нравится клиенту, то она была выполнена эффективно.
Конечно, у нас на этот случай 2 решения:
1) Рабочий процесс — это часть нашей корпоративной культуры. В него входит использование тайм доктора на постоянной основе. Менять работающий и дающий плоды процесс ради сотрудника мы не будем. Ты либо принимаешь наши правила игры, либо нет. Во втором случае — мы просто не будем работать вместе)
2) Мы честно и открыто поясняем как и для чего используем тайм доктор. Он помогает сотруднику управлять своей деятельностью, планировать рабочее время. Скриншоты без повода никто не просматривает. Нет цели поймать на чем-то или, не дай бог, изучать переписки. Обычно именно за переписки больше всего переживают. Что они попадут на скрин и мы о них узнаем. Переписываться не по работе можно после раб дня, гадости про нас писать нет смысла — мы открыты к переменам и диалогам, всегда можно прийти и сказать прямо, что не нравится. В общем, за все время не было ни одной неприятной истории из-за тайм доктора.
Сложные задачи у нас являются премиальными. Сложность определяет руководитель, исполнителя тоже. Он это делает на основе набора задач, которые нужно решить в проекте. Подбирает команду, опираясь на нужные и имеющиеся компетенции. Тут мы Америки вам не откроем) Нет сотрудников, которым достаются только сложные задачи. Но способные сотрудники могут выполнять больше премиальных в силу того, что работают эффективнее остальных. Так можно влиять на свой ежемесячный доход)
Надеюсь, на все ответил.
Спасибо вам за то, что сделали акцент на бухгалтерию и управ.учет.
Цепочки поставок, закупки и запасы — не про нашу сферу деятельности. Мы больше за адаптированные инструменты, которые помогают бизнесу, а не вынуждают впихивать свои потребности в рамки классических процессов)
Мы много времени уделяем организации процессов. Всегда уделяли. Тестировали платформы для управления проектами, пробовали разные методы управления. И, конечно, даже без ERP справлялись неплохо. Но был большой пробел — мы видели сколько работаем, видели над какими проектами работаем, сколько зарабатываем, но не могли понять, как долго мы работали над конкретным проектом и сколько денег он принес. Нужен был интерфейс, которые соединит пазлы.
Теперь поняли, о каких именно вы идентификаторах. Когда дойдём до плотной интеграции Asana и Gitlab, скорее всего будем генерировать короткие легкочитаемые коды (в Asana есть возможность присваивать таскам кастомные поля). Хотя, перед проектированием ещё раз подумаем о целессообразности этого, в тех же PR можно просто оставить линк на задачу в Asana. Или вовсе организовать работу из Asana (прокидывать туда уведомление со ссылкой на PR, чтобы главным агрегатором информации и «побуждений к действию» всё-таки оставалась Asana)
Статусы меняются автоматически между связанными проектами, например, между проектом тех. поддержки и бэклогом разработки. В разрезе интеграции с гитом автоматической смены статусов нет, так как нет и самой интеграции. Это наши следующие шаги по автоматизации, ведь мы и сами понимаем, сколько человеческого фактора сейчас имеется в текущей схеме
В ситуации, когда нет плотной интеграции с Git’ом, не всегда есть смысл делить задачи например на «Сделать форму конфигурации для чат-бота», «Реализовать аутентификацию в чат-боте», «Реализовать бизнес-логику чат-бота», когда всеми задачами занимается один и тот же исполнитель и отвечает за весь результат целиком (ему и время трекать удобнее, ведь не нужно «скакать» между задачами в тайм-трекере, не всегда возможно делать связанные задачи «строго по очереди»)
Но это всё равно не отменяет того, что к такой интеграции мы идём, просто при проектировании нужно понять, какая схема будет удобна всем (начать хотя бы с вопроса о том, всегда ли стоит разбивать задачи, возможно стоит привязывать несколько веток из разных репо к одной задаче в Asana). Мы хотим автоматизировать процессы и меньше бегать между двумя интерфейсами (Asana, GitLab). Но при этом не хотим, чтобы какое-либо решение вносило «многословность», перегружало другие отделы информацией и плодило задачи только потому, что плохо продуманная интеграция диктует свои правила и вставляет палки в колеса.
Может быть у вас есть статьи/материалы по успешным кейсам интеграции между системой управления проектами и системой контроля версий, в компаниях, которые используют тайм-трекер и это не «компании одного продукта»? Мы будем очень благодарны!
Из перечисленных вами фич, которыми должен обладать трекер, в Asana есть добрая половина. ID задачи мы получаем в адресной строке. Статусы меняются автоматически. Уведомления работают. Есть процессы, которые позволяют автоматически отправлять задачи на оценку разработчикам, на оплату в бухгалтерию, подробности запросов автоматически подтягиваются в описание задачи.
Мы, преимущественно, работаем с бизнес-задачами. И далеко не всегда они связаны с одним репозиторием. Это бывает 2, а то и 3 репозитория. Мы не организовываем бэк, фронт (+ иногда расширение) в монорепозиторий.
Так как Asana используется всеми отделами нашей компании, а не только разработчиками, то острой нужды уведомлять постановщика (менеджер проекта в случае с клиентской разработкой, сотрудник технической поддержки в случае бага, руководство в случае разработки какой внутренней фичи) о том, что коммит исполнителя сейчас находится на ревью или его «слили» в мастер — нет, ему это не очень интересно и от отдела разработки он ждёт условного «Готово, принимайте».
Asana довольно гибкий инструмент, поэтому мы верим, что его получится довести до совершенства.