Привет! Меня зовут Лёша. Год назад я взялся перевести команду диджитал-агентства в таск-трекер.
У нас было 15 человек: дизайнеры, разработчики, контентщики, прожекты. Всё нужно было срочно, как в любом агентстве. До этого как-то справлялись: задачи летели в телеграм, фидбэк — туда же, синки проводили дважды в неделю.
Потом пришли крупные клиенты, и фаундер сказал, что пора наводить порядок. Меня назначили лидом и попросили внедрить систему.
Если кратко: месяц спустя мы потеряли «золотого» клиента из-за бардака в задачах. А крайним оказался я.
Почему я вообще решил, что смогу внедрить таск-трекер
В таск-трекерах я раньше уже работал — Trello, Asana, Notion, кое-где сталкивался с Jira. В некоторых проектах всё работало гладко, но бывали и случаи, когда команды забивали на систему или страдали от перегрузки и бюрократии.
Самый болезненный опыт был в бигтехе: чтобы понять, кто чем занят, собирали созвоны по расшифровке тикетов. Вот несколько особенно ярких примеров:
Поэтому, когда фаундер спросил, потяну ли я внедрение, я без раздумий ответил: конечно. Я же знаю, как не надо — значит, сделаю лучше.
В голове уже рисовалась красивая картина: задачи сами движутся по этапам, сотрудники получают напоминания, всё структурно, прозрачно, автоматизировано. А мы с фаундером проверяем дашборды и спокойно идём на пресейлы. В общем, план был красивый.
А теперь по пунктам: где именно я накосячил и к чему это привело.
Пункт 1. Я неправильно поставил цель
Начал я вроде по делу: расписал процесс, чтобы понять, где мы теряем время и срываем сроки, нарисовал пару майнд-карт.
Это процесс по созданию статьи
И вот в этот момент я упустил главный вопрос: зачем мы вообще внедряем таск-трекер?
Что я сделал. Зацепился за идею идеального порядка в процессах и попытался цифровизовать всё и сразу, что бы это ни значило. И, забегая вперёд, получил тот же хаос, но уже на дашбордах.
Что должен был сделать. Поставить чёткую и измеримую цель. Вот хорошая: «хотя бы 80% задач проходят через таск-трекер; все договоренности и информацию по этим задачам можно найти в самих задачах». Такой результат понятен для команды, и его легко проверить.
Пункт 2. Выбрал навороченный трекер
Наше агентство всегда жило в телеграме. Там клиенты, правки, мемы в час ночи. Логично было взять трекер, который сохранит такой ритм.
Что я сделал. Решил, что софт нужен с прицелом на будущее масштабирование. И выбрал систему управления, которая «умела абсолютно все»: от бухгалтерии до маркетинговой аналитики. Сделал подробные гайды и вместе с техподдержкой пошёл создавать шаблоны и «полезные» триггеры.
Вот вам спойлер: если разработчик сервиса обещает поддержку в настройке сервиса под ваши нужды — это плохой знак. Это значит, без поллит… без поддержки и дальше не разберешься.
То же самое касается всяких гайдов. Если нельзя взять и начать работать без специального обучения, готовьтесь к тому, что команда переход на новый софт проигнорирует.
И вот тому подтверждение:
Что я должен был сделать. Найти максимально простой сервис, который будет понятен тем, кто никогда не работал с трекерами (например, YouGile). Если вы не сами не можете освоить сервис за час, не рассчитывайте, что команда освоит его за месяц.
Но, как показала практика, дело было не только в сервисе. Я бы всё равно напортачил дальше.
Пункт 3. Полез в работу команды
Когда запускаешь новый софт, важно не бросать людей в жёсткие правила.
Что я сделал. С первого дня устроил тотальный контроль: заставлял переносить всё из чатов в карточки, сам правил статусы, ставил связи, ходил по личкам с вопросами «где это?» и «почему не обновлено?».
Через пару недель наши синки превратились в допросы. Я молча открывал доску и начинал:
— Эта задача ещё жива?
— Кто её делает? Где история согласования?
Я постепенно закипал, но и команда была на пределе.
Сначала нарастало раздражение, как в этом диалоге с главредом:
А затем и открытый протест. Фронтендер начал игнорировать мои сообщения, а потом просто сказал, что трекер даже открывать не будет, пока его не разгрузят или не найдут помощника.
Решил на него не давить. Естественно, это должно было вызвать вопросы у остальной команды:
Появились новые побочные эффекты. Люди знали, что писать в общий чат «не по протоколу» (о чём я периодически напоминал), и начали уносить всё в лички. Если раньше я хотя бы видел всё в общем потоке и мог вытащить нужную информацию, то так она размазывалась по разным диалогам.
По выходным я вручную собирал отчёты для клиента, потому что примерно трети задач в трекере не было, а по другой трети — стояли старые статусы.
Что я должен был сделать.
1) Спокойно провести общий созвон, объяснить, зачем нам таск-трекер, и как он упростит работу всех участников.
2) Начинать с самого простого. Создать максимально простую доску с основным процессом и позвать туда команду:
Доску без наворотов и автоматизаций, только базовые статусы: исполнитель, дедлайн, приоритет. Для удобства всех новичков можно создать шаблон задачи со всеми нужными статусами, чтобы ничего не забывали.
3) В течение недели просто понаблюдать, как двигаются задачи, ведется ли по ним обсуждение. Научиться не дергать людей по личкам, а брать инфу из системы.
Например, сейчас я просто открываю ленту событий и смотрю, как человек работает в системе. А общий прогресс команды мониторю через сводки. Это динамичные отчеты в виде колонок прямо на доске:
Я настроил три сводки, они собирают из всех нужных проектов:
новые задачи за неделю;
задачи с пропущенным дедлайном;
задачи, в чатах которых идет активное обсуждение.
Так я слежу за происходящим со всеми проектами на своей доске.
Пункт 4. Жестил и усложнял
Я понимал, что не справляюсь. Это моя первая руководящая должность, а задач было слишком много. Но отпустить контроль не мог — ведь это я всё это внедрил.
Что я сделал. Собственно, см. пункт 4.
Что должен был сделать. На планёрках обсуждать работу и планы, опираясь на трекер, а не вести разговоры и задачи отдельно, создавая две параллельные реальности.
Также, я считаю, очень важно сразу обсудить максимально простые правила:
Обсуждаем задачи только в системе. Дополнительный плюс — если в ней есть свой мессенджер, и чаты в задачах, как в YouGile — это помогает вовлекать команду.
Если договорились вне трекера, например, с клиентом— до конца дня фиксируем это в чате задачи. Как угодно, хоть копипастом, важно, чтобы не терялось.
Есть статусы, которые пропускать нельзя никому. В задаче всегда должны быть исполнители и дедлайн.
Задачи на доске должны быть примерно одного “размера”, вся мелочь уходит в подзадачи.
Пункт 5. Не вовлёк команду
Я воспринимал ведение задач в таск-трекере как обязанность людей. И каждый раз напоминал всем об этом.
Что должен был сделать. Вовлечь сотрудников еще на этапе выбора инструмента. Простая схема вроде PDCA могла бы сразу дать структуру нашим разговорам:
P (plan) — обсудили проблему,
D (do) — попробовали новый подход,
C (check) — проверили, работает ли,
A (act) — закрепили результат.
Добавить мотивацию: благодарить за идеи по работе в новой системе, отмечать инициативных. Даже мелкие поощрения вроде пива вкусняшек поддержали бы вовлечённость.
К чему это всё привело
Примерно через месяц после моего «внедрения» мы накосячили на проекте для очень дорогого клиента, где каждое слово проходило через пиар-службу.
Вечером редактор получил срочную правку — убрать из текста упоминание партнёра под NDA. Он переслал её автору в личку, а утром верстальщик взял старый текст из задачи и выложил на сайт.
Я спокойно попивал кофеёк, готовясь к очередному созвону, и тут прилетело огромное гневное сообщение от клиента.
Показывать его не буду, но моё лицо в тот момент выглядело примерно так:
Мы экстренно всё поправили, параллельно извиняясь перед клиентом. Но на следующий день заказчик поставил проект на паузу.
Шеф дал мне две недели, чтобы навести порядок, иначе — прощайся с креслом.
И вот мы закольцевали историю.
Мне пришлось упростить всё, что я наворотил. Я отключил все автоматизации, убрал 10 статусов, сократил количество обязательных полей. Покаялся перед командой. Подключил ассистента-внештатника, чтобы тот ходил по карточкам задач и уточнял статусы. Боялся лишний раз сам дёрнуть людей, которые каким-то чудом продолжали выдавать высокое качество.
Процессы немного ожили. Фаундер увидел, что система кое-как заработала, и я остался. Но это была уже не победа. Я был настолько истощён и разочарован собой, что через три месяца ушёл сам.
Со старой командой мы общаемся, даже подтянул нескольких ребят в свои фриланс-проекты. А одна коллега (уже подруга) показала мне скрин, как они тогда создавали чатики для «нормальной работы» втайне от меня.
Смеюсь, конечно, но скорее так:
Сейчас, спустя год, я считаю, что тот опыт пошёл только на пользу. И теперь я понимаю процессы и людей лучше. Но, скажу честно, я пришёл к банальной мысли: любой софт должен вписываться в работу команды, а не наоборот.
Надеюсь, мой антикейс был полезен и, возможно, дал пищу для размышлений.
Расскажите, как у вас проходили «внедрения» новых инструментов — по любви или через боль?
Комментарии (78)
ValeriyPus
05.08.2025 05:09Ну, ошибку нашли?
Как специальность называется?
Инженер-программист.
Какие пиковые загрузки? В трекере задачу передвинуть - минута дел.
Если после этого не начинается "Как задача на час?! Тут дел на 57 минут! Смотри, за 20 минут сделал!"
Не нравятся оценки в часах - делайте оценки в StoryPoint-ах.
Трекер используется для планирования, а не для "ой, а я делаю по 100 классов в день и 1к строк"!
sergey_prokofiev
05.08.2025 05:09Там походу чувак наворотил "процесс", в котором надо полдня разбираться, какую таску в какой статус надо двигать и какие каменты отписать чтобы оно корректно подвинулось.
ValeriyPus
05.08.2025 05:09Клиенту и главреду надо метаться по всем 3-м уровням (что их изматывает).
Если бы вы делали то же самое, но в стиле WaterFall (сделали N препринтов, потом N эскизов и т.д.) - нагрузка бы не ощущалась.
Переключение контекста отнимает силы.
Ну и клиентам нравится смотреть на результат, а не по 3 раза согласовывать.
Клиенты платят за "экспертность"
(т.е. они приходят, а вы делаете работу)
У вас нарисована постройка частного космического корабля.
Tim_86
05.08.2025 05:09На предыдущей работе использовали Jira, Яндекс.Трекер. На текущей используем Gitlab для создания и ведения задач - и внезапно, это так же удобно и практично (даже удобнее, в отличие от перегруженной Jira).
omichkun
05.08.2025 05:09Мы начинали с Gitlab issues, но даже на маленьком проекте поняли, что как-то все не очень удобно – чисто на тегах как-будто не удается выстроить нормальный процесс. В итоге перешли на YouTrack и там прям дело пошло получше (хоть и используем прям самую малую часть от его возможностей). Но мы люди, выросшие на Jira, поэтому у нас уже деформация к тому времени)
Ndochp
05.08.2025 05:09И как ютрек после жиры? Я с ютрека на жиру - бесит местами. Интересно, это реальная оценка, или что первое увидел, то и правильно?
qeeveex
05.08.2025 05:09У меня опыт такой же. Работал в компании с YouTrack - все было классно. Работает шустро, поддерживает markdown, все обновляется в real time (в том числе доска). Красотень.
Сейчас работаю в компании с Jira. Работает медленно, сама доску не обновляет, надо нажать "обновить". Про markdown можно забыть, тут что-то свое и кривое.
losse_narmo
05.08.2025 05:09пользовались долгое время веб-джирой, попробовали перейти на Ютрек. Промучались месяца 3 и в итоге подняли локальную джиру, после чего все выдохнули
Leenominai
05.08.2025 05:09Пользуюсь каждый день Гитлабом, ютреком и реже джирой (раньше была вместо ютрека). Вижу проблему в том, что все эти таск-трекеры внедряют самые худшие практики конкурентов, чтобы не отличаться.
Гитлаб: Завезли открытие задач по 2 кликам вместо 1 (как в джире, если не нажимать на колёсико), потом туда завезли скрытие части тачки, если она длинная, а размер страницы не меняли! В итоге при скролле длинной тачки вниз там 80% будет занимать пустое место.
Ютрек: то же самое с предпросмотром такое. Сам экран тачки перегружен разделениями разных элементов, из-за чего адекватно можно пользоваться только на экранах 27+ дюймов. А с этих скроллов только части таски схожу с ума, ещё хуже, чем в джире, когда она длинная - ты не можешь увидеть название, панель инструментов тоже в заднице (в джире для каждого поля она отдельная хотя бы).
Короче, если команда до 20 человек - гитлаб хорош, если большая и куча сторей - ютрек заходит. Только у нас проблемы с доступами, что у меня и прокси не работает, только серьезный ВПН. Джира - просто не люблю, интерфейс перегружен. Как человек, который пишет тачки и баги десятками, самый простой редактор в гитлабе - нравится больше всех. Есть куча разных мелочей, все зависит от вашего использования. Для меня критично, условно, то что в вики ютрека нельзя делать ссылки на строку как в notion, но Вики гитлаба - это вообще как заметки на телефоне. Встроенные элементы создания ссылок самого хрома спасают ситуацию.
vedmed007
05.08.2025 05:09Как настраивать.
В жиру всегда можно докинуть ресурсов и проинтегрировать все что угодно
В ютреке частенько многое "недоступно", а на больших проектах - надо потихоньку отключать фичи, чтобы не тормозило, сколько туда не закидывай железа
benjik
05.08.2025 05:09Классика!
Наблюдал когда-то давно в одной и той же компании переезд с почты+экселя на HP Service Desk, с HP SD на самописный таск-трекер, с самописного на что-то опенсорсное, с чего-то опенсорсного на что-то встроенное в SAP в течение примерно 5 лет. Потом я уволился, но коллеги сказали что с SAP'а ещё на что-то переезжали пару раз.
На каждом из "переездов" был новый менеджер, т.к. старый куда-то девался, и каждый новый менеджер совершал одни и те же ошибки. Иногда забегали старые менеджеры и слегка истерично смеялись, радуясь что не придётся опять этим заниматься. Пользовались этими штуками люди, которые сидели на местах по многу лет и все уже давно перестали удивляться этой дичи. Даже ведение задач в двух (иногда в трёх) системах одновременно в середине переезда уже никого не удивляло.
belav
05.08.2025 05:09Как обычно, приходит очередной "я знаю как", ломает всё и сливается)
benjik
05.08.2025 05:09Не, там грамотные ребята продавали свои продукты топам, топы записывали себе в kpi успешное внедрение и назначали ПМ'а это внедрять. Грамотные ПМы, которые "смогли бы" внедрить, от этой чести грамотно уворачивались, а молодые-зеленые были недостаточно грамотными, чтоб увернуться и/или успешно внедрить.
Pusk1
05.08.2025 05:09Вот лично меня дико бустит отсутствие досок, дейликов и прочих ритуалов. Прямо впахиваю и думаю о бизнес ценностях и их воплощениях в коде и процессах, а не о списании времени в трекере, статусе карточек и пр. Вот сейчас сходил на дейлик, а после него отвлёкся хабр почитать. Чтобы обратно в поток попасть, который поутру поймал 40+ мин нужно, а там обедать пора. Период с 11:30 до 15:00 на 80% потерян.
Идеальная доска для меня как исполнителя с 3-мя стстусами. Бэклог, в работе, готово. И я не хочу заводить на ней карточки.
Я не совсем серьёзно. Просто появилась возможность поработать в таком режиме несколько месяцев и меня это просто мега бустит. Попробуйте. Хотя бы день без созвонов, чатов и совещаний.
kirakirap
05.08.2025 05:09Было дело, пришла в IT-компанию, которую только что купила госкорпорация. Там люди каким-то образом умудрялись согласовывать документы в почте. А доки — это комплексные договоры на внедрение программно-аппаратных комплексов+ поставку лицензий на много миллионов рублей.
Через месяц предложила всем перейти в 1С (потому что гос+завязана бухгалтерия). Инициатива была наказуема, и мне пришлось сопровождать весь процесс вместе с IT департаментом. Очень тяжелый, но крутой опыт, потому что оно того стоило.
Потом работала в Платруме, Кайтене, Вике, Яндекс.Трекере. С последними двумя лично у меня возникали сложности. Но я в диджитале, а ребята из IT сидели в Jira. Ругали, но пользовались.
Сейчас работаю только на фрилансе и прыгаю между бесплатными Todoist, YouGile и, внезапно, календарём в iOS. Когда проектов не оч много, последнего хватает за глаза, если настроить напоминания.Но если команда небольшая + ты с новым софтом в целом ладишь, подключить людей не так сложно, особенно если этапов работы условно 4-5. Основным врагом остаётся лень, причем в основном моя.
Mirzapch
05.08.2025 05:09Работнику, как исполнителю, задачи со статусом "готово" вообще не должны показываться.
PerroSalchicha
05.08.2025 05:09Это даже с точки зрения производительности плохая идея - когда у тебя есть возможность видеть результат своей работы, это мотивирует. А так, просто технически, у работника вполне себе часто может возникать потребность заглянуть в выполненные смежные задачи, или что-то решить аналогичным образом. Зачем их скрывать-то?
mayorovp
05.08.2025 05:09Идеальная доска для меня как исполнителя с 3-мя статусами. Бэклог, в работе, готово.
При таком подходе бэклог быстро забивается непонятными плохо сформулированными задачами, за которые никто не берётся потому что не знает что вообще с ними делать.
Fox_exe
05.08.2025 05:09Тоже работал в паре компаний, где в одной была Jira, в другой - 1С.
Ежедневный (А иногда и ежечасный) ритуал с написанием тонн текста и выставлением всяких статусов дико бесил, т.к. сильно отвлекал и требовал кучу времени.
А потом устроился в другую компанию, где задачи ставятся через чат - я их просто себе в текстовой файл выписывал чисто чтобы не забыть (если что-то не очень срочное) и всё. Никаких статусов, никаких отчётов. Сделал, отчитался (отписался в чате), занялся следующей задачей. Ни секунды впустую потраченного времени и полная свобода в планировании (многие задачи ставятся сразу "глобально", на пару дней выполнения, а мелкие правки делаются сразу на месте, через общий чат).С таким подходом и мотивация, внезапно, появилась и производительность заметно выросла... Такие дела...
randomsimplenumber
05.08.2025 05:09Никаких статусов, никаких отчётов
Менеджер, который этим управляет - герой каптруда.
fulvert
05.08.2025 05:09Попробуйте. Хотя бы день без созвонов, чатов и совещаний.
Плавали, знаем! Не контролировать сотрудника, всё равно что отпустить руль у автомобиля в движении. Ещё смотря какая дорога. Если к примеру у разработчиков реально не получать обратную связь каким-либо образом, то они уходят в дебри исследования или оптимизации, что стоит по времени в разы больше времени чем сделать здесь и сейчас. К примеру: чтобы не писать какую-либо функцию, разработчик может потратить время на поиски фреймворков содержащую эту функцию, выложить в общий репозиторий и потом все должны таскать этот фреймворк у себя тоже. Конкретно один умник добавил в проект фреймворк boost. А он весил несколько сот мегабайт. Вот крику то от его коллег было. Аргумент-это новое и прогрессивное, надо начинать использовать.
randomsimplenumber
05.08.2025 05:09день без созвонов, чатов и совещаний.
Отпуск. Пробовал, нраицца ;)
Bushmelev_aa
05.08.2025 05:09Спасибо что поделился, успешный успех не так интересен ;) однозначно лайк
LekserEE
05.08.2025 05:09Забавно, что все типовые ошибки совершил, так ещё и выводы опять "не те". Рефлексия вообще некорректно проведена).
Долгое время в том числе как и внедрением занимался, так и оптимизацией (и процессов и коммуникаций). От трелло до жиры
Советов и комментариев вроде просили):
Внедрение всегда идёт от сотрудника к руководителю, начинать сверху - самая главная ошибка. Что делать и как это реализовать? Первое - берём плюс минус неделю (для небольших коллективов до 30-40 человек) и по часу в день интервьюируем каждого сотрудника - коммуникации, задачи и сами процессы их движения, сценарии. Параллельно между делом вытягиваем текущие боли спецов - факапы по времени и по содержанию задач, их причины. Потом собираем настоящую структуру, а не которую "придумал руководитель". Сама работа уже располагает к позитивной оценке внедрения новой системы.
Из полученной структуры собираем уже типовые и уникальные задачи. Для типовых пишем шаблоны оформления (зачастую шаблоны уже у сотрудников уже есть, либо их можно быстро набросать ещё на первом этапе). Уникальные просто закидываем в базу знаний. Самое главное - убрать пустые задачи.
После обкатываем неделю-две на лёгком проекте, фиксим косяки, расширяем шаблоны/описания. Дальше потихоньку готовимся к переносу на все проекты.
После в уже привычном темпе прикручиваем систему приоритетов, рисков и бэклог (по ним кста тоже есть нюансы).
Самая главная ошибка таких внедрений - идти от руководства к спецам, "спуская сверху ЦУ". Вторая - обязывать сотрудников самих заполнять описания и шаблоны. Внедрение всегда проводится для сотрудников, чтобы облегчить им задачу, а не добавить лишней рутины.
Самый мой запоминающийся опыт - когда сотрудники от переписки в телеге сами перешли к позиции - нет задачи в жире, ничего делать не буду.
Готов пообщаться, если есть вопросы
ITDiver77
05.08.2025 05:09Ну да, спецы же все как один одну точку зрения имеют, диаметрально противоположных не найти)
Внедрение проводится не для облегчения задачи. А для повышения прозрачности, облегчения планирования, повышение качества и проч. И в том числе, для снижения нагрузки и выгорания, так как появляется понимание ёмкости команды, чего нет только в чатегах.
Те же таймшиты с одной стороны всегда отнимают ресурсы на своё заполнение, особенно когда задач сильно больше одной за день. С другой, позволяют и стоимость посчитать, и прогнозировать точнее схожие работы в будущем.
Ndochp
05.08.2025 05:09Спецы в готовой команде уже довольно притерлись, чтобы найти то, что почти и так работает и автоматизировать.
Таймшиты зло боль и ненависть. Я знаю, какие задачи я сегодня делал, обычно знаю какой занимался больше всего. А вот сколько времени я писал код, а сколько времени теребил в чатах по своим вопросам и был тереблен по чужим - уже сильно хуже. В итоге таймшиты у меня кончались именно этим: в экселе был список задач с весами, в аутлуке список встреч. Из 8 часов сначала вычитались встречи, потом остаток раскидывался по задачам в соответствии с весами. Если задачей нельзя было заниматься, но время на нее уходило - значит ее не было в списке. Вроде примерно все вокруг так же раскидывали чтобы и 8 часов было в сумме (даже если до 21 засиделся) и задачи примерно соответствовали тому что надо.
ИМХО точность примерно такая же, как если перекладывать по трем колонкам.
LekserEE
05.08.2025 05:09Я разве утверждал, что они одну точку зрения имеют)? Буквально написал, что в процессе интервью стоит как раз поговорить о факапах. Задача внедренца как раз выявить проблемы, а не самому их придумывать.
"Внедрение проводится не для облегчения задачи". Буквально вам нужно из удобного и оперативного инструмента (чатег) вытащить человека в доп. инструмент. В котором нужно разобраться, привыкнуть. В котором возможно нет мобильной версии, или уведомления не падают пушем, пока не зайдешь и не проверишь. Ещё раз - главная ошибка и почти гарантированный провал внедрения это игнорировать сотрудников. Тех, кто и будет на 95% работать с ним. А про планирование, прозрачность на встречах руководителей поговорите.
У вас опять сквозит - и в том числе снизить выгорание и нагрузку. Это не в том числе, это буквально первоочередная задача. Иначе внедрения не будет. Ваш сервис проболтается полгода на паре энтузиастов, но потом сдадутся и они.
О таймшиты. Хотите вызвать ненависть сотрудников к вам - внедрите таймшиты. Хотите чтобы вас на вилы подняли - сделайте их обязательными, ежедневными. Хотите массовых увольнений - введите штрафы на их незаполнение. Буквально худший инструмент. У вас интервью и дальнейшая работа над структурой и так даст всю информацию по типовым и уникальным задачам, времени их выполнения. Реальные данные по срокам выполнения. Таймшиты это буквально первый признак эффективного менеджера.
Все таки попробуйте рефлексию "от сотрудника" построить. Ситуацию вроде пережили, но вот выводы в итоге все таки ошибочные
SerjV
05.08.2025 05:09Самая главная ошибка таких внедрений - идти от руководства к спецам, "спуская сверху ЦУ". Вторая - обязывать сотрудников самих заполнять описания и шаблоны. Внедрение всегда проводится для сотрудников, чтобы облегчить им задачу, а не добавить лишней рутины.
Вот не соглашусь... Не того чтобы "совсем всё неправильно", но есть нюансы.
Во-первых, есть такая штука, как сопротивление инновациям. А потому любое внедрение дойдёт до конца только в случае, если его будет продавливать сверху руководство.
Ну или другими словами - внедрение проходит методом кнута и пряника. Причём кнутом не обязательно пользоваться, достаточно понимания всеми участниками, что он может быть применён.
И да, проще сначала завести систему и под неё изначально организовывать работу персонала, чем внедрить её в уже сложившейся рабочей среде.
Во-вторых, есть классическая схема "обследование - проект - реализация - опытная эксплуатация - устранение замечаний - продуктивная эксплуатация".
Потому что внедрение системы там, где до этого обходились без неё - это всегда появление новых затрат времени у сотрудников. И польза от него будет, это эти затраты компенсируются чем-то другим. Например, снижением переработок, или снижением времени на поиск "кто кому когда чего сказал, кто и как его неправильно понял, потом сделал и что теперь переделывать".
Потому что таки да, это может делаться и просто ради метрик для руководства и самосоздания им для себя иллюзии контроля ситуации.
Ну и да, на обследовании можно сказать, что делают то, что написано у вас в первом пункте списка. А можно сказать, что выявляются и описываются фактически сложившиеся бизнес-процессы, а также предпочтения, пожелания и жалобы участников. Не суть важно, как назвать - главное, что получен результат в виде материалов для следующего шага.
На проекте можно сказать, что делают то, что у вас написано во втором пункте. Но надо добавить, что помимо этого еще:
- выбирают систему, в которой это будут делать (да, именно тут выбирают, понимая, чего от неё хотеть надобно).- И создают план внедрения, в т.ч. решают вопросы, на каких группах сотрудников и каких задачах обкатывать (чтобы не похерить всю работу конторы сразу же), в какие сроки, как проводить обучение, как разрабатывать регламенты и т.п.
В опытной эксплуатации - ну да, в том числе делают то, что у вас в третьем пункте. Но не только - потом еще и "почти как в продуктиве" (то есть и ваш четвёртый пункт), но с возможностью в любой момент откатиться на старую схему работы (это как минимум не должно караться) с фиксацией причин и устранением вызвавших это недостатков в системе. И длиться это может какое-то достаточно долгое время - потому что на "лёгких проектах" может не всплыть что-то важное.
И вот только потом уже закручивать гайки, вводить кары за неиспользование и нарушения регламентов, использование экстренных каналов в обход системы без необходимости и без последующей фиксации в системе того, что сделали в обход неё. Ну.... Ну потому что бывают ситуации, что в конечном итоге плюсы перевесили минусы и сотрудники сами "перешли к позиции - нет задачи в жире, ничего делать не буду", а бывает, что кого-то мутная ситуация вполне устраивала... Всё может всплыть к этому моменту.
PereslavlFoto
05.08.2025 05:09интервьюируем каждого сотрудника
При этом сотрудники постараются ничего не сказать.
вытягиваем текущие боли спецов
Постоянная недоплата, постоянная перегрузка, непонятные задания, нежелание начальника что-либо объяснять.
собираем настоящую структуру
Тем самым мы показываем ключевые позиции, с которых надо уволить сотрудников, получивших слишком много власти в обход начальника.
Mr_Qwerty
05.08.2025 05:09Описаны характерные болезни коллективов воспитанников детских садов от 3 до 30 лет. Обратная сторона стартапов, собранных из однокурсников сразу после выпуска. Где, если я боль-мень пишу код по заветам дяди Боба, то уже и в социальном управлении разбираюсь. Где же мотивация сотрудников в этой истории? Почему производственный процесс не закреплён в ЛПА? Почему санными тряпками фронтера не прогнали? Как будто хвост крутит собакой /рукалицо/
David_Osipov
05.08.2025 05:09Вот коммент хороший. Имхо, я продакт и в b2b на сложном продукте и я даже не представляю, как бы мы обходились без Jira. Когда создаётся логика сложнее нажатия на кнопку, то уже надо трекер и документацию создавать, иначе вся логика пойдёт лесом, а ребята будут перегружены.
sergeykonshin
05.08.2025 05:09Работал с одним фронтендером, так ему даже в отпуск уйти не давали. Так и работал периодами день через день
AnyVic
05.08.2025 05:09Есть неудачный опыт, в котором руководство отказывается воспринимать здравый смысл.
Третий год требует у подчиненных обязательные задачи в битрикс, но само ставит и принимает работу исключительно на словах и в чатиках.
Как итог, задачи ставятся только для проформы и трекер нужен сотрудникам, как собаке пятая нога.
Между тем:
Перевел госслужащих на ОТРС одним вопросом, на любую просьбу техподдержки в чате "Скажите, пожалуйста, номер заявки в ОТРС?"
Также успешный опыт внедрения трекера задач.
Локальная Азура для небольшой команды программистов - незаменимый инструмент потому, что любая задача может быть поставлена, выполнена и принята только в Азуре.randomsimplenumber
05.08.2025 05:09Если у задачи нет номера, значит это не задача, а пожелание. Или жалоба на несовершенство мира.
CmpeJ1ok
05.08.2025 05:09Итог можно подвести простой: если для задач, вроде прибить или приклеить - создаются сотни чатов, команды, созвоны, митинги, а в итоге одни гребут, а другие загребают на совещаниях - вы получите закономерно неуд в решении ваших задач
Serfox200
05.08.2025 05:09К адекватному использованию Obsidian я пришел через 2-3 года упорной работы. И каждый раз основной проблемой было чрезмерное усложнение системы, попытка впихнуть в нее все и вся.
Пришел к тому, что нормальная система планирования - это по сути большой набор шпаргалок и напоминалок, иногда конспектов. Самой главной вещью является скорость. Скорость навигации, скорость поиска нужного материала, скорость создания и скорость удаления материала.
Diversantos
05.08.2025 05:09Поделитесь, как решаете проблему с нарастающим комом мелких заметок?
Какие функции используете чаще всего?
vmalyutin
05.08.2025 05:09Вы уж меня простите, что не стал до конца читать. На 15 человек Excel-я должно хватить. Ну или Google Sheets.
as1984
05.08.2025 05:09Нам на 7 не хватает. А Б24 в самый раз. Причем при внедрении я ожидал сопротивления, а вышло наоборот. Программист на третий день внедрения требовал задачи в Б24 со словами: нет в Битрикс, значит вообще нет.
venanen
05.08.2025 05:09Первое, главное и основное что каждый человек, занимающийся внедрением чего угодно, будь то закон, программа, новый стек и т.д. - это первенство цели. Мы все живем в полубезумном мире, где нет цели, но есть задача, под которую уже надо будет придумать цель. Получается телега впереди лошади едет. Всегда: сначала цель. Ясно, четко и адекватно сформированная, затем декомпозиция, затем задачи.
MEGA_Nexus
05.08.2025 05:09Я понимал, что не справляюсь. Это моя первая руководящая должность, а задач было слишком много.
Это основная проблема. Всё остальное из этого вытекает.
С опытом приходит понимание, что сначала необходимо навести порядок в бизнес-процессах, а уже потом внедрять новые инструменты.
Построение конвейера создания ценности.
Выкидывание из процесса всех лишних людей и стандартизация процесса.
Когда люди привыкли к новому процессу и точно знают, какую информацию они получают, как её нужно обработать и какой результат по итогу нужен, вот тогда можно внедрять новые инструменты, которые закрепят текущий результат. Начать сначала с внедрения для одного проекта\клиента и потом по мере привыкания людей можно будет постепенно масштабировать результат на другие проекты.
Надо помнить, что после внедрения нового инструмента выгоду должны получить не только собственники бизнеса, но и сами люди, иначе будет отторжение любых новых изменений.
aeder
05.08.2025 05:09Классический пример, когда систему управления задачами/дефектами внедряли не для того, чтобы людям было легче - а для того, "чтобы начальство видело".
И самая первая ошибка - безумная схема переходов между статусами с 15 отдельными статусами.
Статусов должно быть 4-5 максимум (считая "новая" и "закрыто"), и переходы между ними - произвольные или почти произвольные. Потому что в реальности очень мало задач решается "по схеме".
Дальше - людей надо:
а) научить работать в системе - и лучше, чтобы система была действительно простая.
б) категорически все задачи ставить только через систему. Лично, самому.
в) проверять результаты - тоже только через систему.
K0styan
05.08.2025 05:09Есть ещё одна ошибка - можно сказать, что предшествующая, можно - что параллельная, не суть. Это мысль, что надо сделать сразу всё.
Вот в таких случаях метод итеративных приближений отлично работает. Затягивание задач в трекер просто в наглядном виде - уже первый шаг. Дальнейшие тонкости - уже по ходу дела. Даже если есть точная и адекватная схема процесса. Особенно если есть точная и адекватная схема процесса.
tenzink
05.08.2025 05:09Прочитал переписку с главредом и ужаснулся. Автор наобещал клиенту с три короба, загрузил всех малоосмысленной работой, и требует от сотрудников работы в выходные для покрытия своих косяков. Камон, вас там полкоманды наверное тихо ненавидели
kinall
05.08.2025 05:09шаблон задачи со всеми нудными статусами
В контексте статьи - опечатка года, не меньше)
Daddy_Cool
05.08.2025 05:09Хм. Вставлю пять копеек. Есть подозрение, что такие штуки работают когда процессы типовые. А появляется что-то новое - и вся структура взаимодействия летит нафиг. Еще момент - человеческая память. Когда люди помнят все задачи, кто чем занимается - то всё просто. И еще копейка. Время выполнения/обновления задачи и время привыкания к новой структуре взаимодействия. Если они сравнимы - то в структуре смысла нет, единый хаотичный чат из которого каждый выхватит то, что ему нужно + лички и всё работает.
PerroSalchicha
05.08.2025 05:09Есть подозрение, что такие штуки работают когда процессы типовые.
Такие штуки плохо работают, когда люди загружены работой. Писать в мессенджере, это практически бесплатно (по трудозатратам, в смысле), это самый быстрый способ коммуникации. Вести таски в трекере, это уже требует некоторого времени, как на собственно внесение данных, так и на коммуникацию. Мессенджер, он вот у вас, перед глазами. Увидели, прочитали, если что-то срочное, сразу ответили. В трекере - вам пришло уведомление, вы ещё даже не знаете, срочная таска там или может подождать, открываете когда у вас есть время/желание проверить обновления.
alx_mgr Автор
05.08.2025 05:09Именно поэтому я предпочитаю таск-трекеры с мессенджерами. Если общение в одном месте, а таски в другом - это трудно соединять в головах людей
QweLoremIpsum
05.08.2025 05:09Странно зачем люди создают отдельные секретные чаты для работы, почему бы не использовать для этого комментарии к таске в качестве чата?
kinall
05.08.2025 05:09Потому что в чате можно говорить свободно, как в курилке. А комменты видят все. И объясняй потом HR-ам, что это ты так остроумно пошутил «для тех кто понял», и вообще ничего плохого не имел в виду.
nronnie
05.08.2025 05:09Команда небольшая и можно было просто начать с того что повесить доску с бумажными стикерами, а позже, когда бы процесс прижился, то переходить на что-то более продвинутое. А задачи в телеге, по телефону, или по почте - нынче это давно вообще какая-то невиданная жесть. Возможно, просто, в данной конторе и всё остальное на таком же уровне.
alexandr_domanskiy
05.08.2025 05:09До этого я работал в маленьких стартапах. Где все было в телеге/вотсапе. Это АД!
Но РАЙ, для тех кто делает вид что работает и типа всегда ОЧЕНЬ занят )
Если отсутствовал 2-5 дней, то собрать информацию по конкретной задаче из переписки с 3-5 людьми - та ещё морока. А выставить приоритеты? А передать задачу новому разрабу?
Юзаем "свою" джиру. И это божественно. Спринты, задачи. Коммиты из гитлаба автоматом привязываются к таскам джиры.
Бухгалтерия сама автоматом собирает отчёты.
У нас полно легаси сервисов. Без особых трудностей, можно собрать информацию/историю реализации определенного кода/фичи/костыля. Найти по нему задачи. Восстановить картину.
GBR-613
05.08.2025 05:09Я бы начал с демократии. Спросил бы у команды, кто какую систему рекомендует? И выбрал бы то, что рекомендуют больше всего: даже если это и хуже, чем то, что выбрали бы Вы, то ненамного. А отношение у команды с самого начала было бы другим.
alx_mgr Автор
05.08.2025 05:09согласен насчет сбора мнений! тут такой момент, что часто люди рекомендуют не хорошее, а к чему сами привыкли. но так легко узнать, что точно даже пробовать не стоит
Deathgar
05.08.2025 05:09Сразу видно, что сам никогда не, либо крайне редко работал с досками и трекерами...
Axelaredz
05.08.2025 05:09Есть кстати интересный опенсурс тасктрекер #Taiga https://taiga.io
Его юзают достаточно крупные компании, наподобие HP, AirBus, Mozilla, RedHat и другие.
opusmode
05.08.2025 05:09Ну, как-то я прочитал и что-то такое себе. В смысле я не то, что бы не согласен, просто кажется идеи не очень полно вынесены
В общем, из моего опыта:
Есть 2 принципиально разных подхода - "ресурсы под систему" и "система под ресурсы". В первом случае мы придумываем идеальную систему и ищем подходящее под неё, в том числе персонал. Во втором случае мы анализируем имеющиеся ресурсы и выстраиваем систему относительно них.
Автоматизации и внедрения, это не про инструменты, а про людей и процессы. Инструмент не имеет ценности сам по себе никогда, он призван улучшать что-то. Сначала выстраиваются или изучаются процессы, а потом туда добавляются инструменты, которые помогают, упрощают и ускоряют работу. Иначе это всегда камень на шею
Старт должен быть лёгкий. Не надо пихать пользователю панель управления межзвездным крейсером. Трекер и любой другой инструмент, в первую очередь должны давать пользователю базово необходимый ему функционал. Закладывать расширение это хорошо, но расширятся надо постепенно и не всем.
А если говорить проще - не навязывайте хрень из своей головы другим, а анализируйте и ищите реальные проблемы и решайте их постепенно, параллельно думайте, как организовать это в систему. Ну и не забывайте с людьми разговаривать. Не надо им рассказывать, как очередная ваша гениальная идея сделает всё хорошо, найдите проблемы, решите их, проверьте, что вы реально их решили, а не просто закрыли KPI, проверьте, что не создали новых проблем, только потом продолжайте
epliner
05.08.2025 05:09У меня был немного схожий опыт в рационализации процессов. Правда, в моем случае коллективу в 50 человек было сложнее организовать тайные чатики, да и задач было значительно меньше, что мне явно помогло ) Глобальные задачи вот так с наскока, как мне кажется, в 99% случаев обречены, зато какой опыт
alx_mgr Автор
05.08.2025 05:09я думаю, что тайные чатики есть почти во всех компаниях. просто иногда про них знают все, кроме руководителя, а иногда они "более тайные"
discoverer-official
05.08.2025 05:09Классика!
"и я там был, мед-пиво пил.."
Не переживай, это был полезный опыт!
Я бы добавил в качестве совета только:
Внедряй инструменты и методологии которые соответствуют зрелости команды
В моей практике встречаются ситуации, когда надо сперва взрастить команду(в том числе самоидентификацию) и процессы. А затем уже предлагать улучшения и инструменты.
К сожалению, внедрение улучшений опережающих свое время (в team life cycle) встречают не оправданное сопротивление. Некоторые звезды сгорают...
PereslavlFoto
05.08.2025 05:09Это вы рассказали про пессимизм. Будьте так добры, расскажите теперь про оптимизм. Это легко, просто надо ответить на несколько простых вопросов.
Таск-трекер означает, что вместе с прежней работой надо вдобавок ещё и записывать задачи, а потом записывать решения в таск-трекер. То есть добавляется новая работа. Как увеличение объёма работы уменьшит объём этой самой работы?
У вас нет времени на организацию трекера. Поэтому вы сначала организовали максимально простой трекер, а потом, когда нет времени, организовали вдобавок ещё и нормальный трекер. Откуда возьмётся время на всю эту дополнительную работу?
Чтобы брать информацию из системы, надо её туда сначала поместить. Сотрудникам некогда это делать. Кто же сделает эту работу, кто же соберёт всё по личкам и чатам, не увеличивая расходов на свою зарплату?
Вы считаете нужным вовлечь сотрудников при выборе инструмента. Однако у сотрудников нет времени на это. Сотрудники уверены, что трекер не нужен, и предлагают избавиться от него. Сотрудники видят, что это не их обязанность и что за новую работу им не платят. Как справиться с тотальным саботажем? Дальше вы пишете, что трекер должен вписываться в работу команды, хотя работа команды вовсе не допускает никаких трекеров.
Вы пишете, что наняли внештатного ассистента. Получается, что ваше решение слишком дорогое. Как сделать всё то же самое, однако не тратя времени, а наоборот, экономя его?
Вы пишете, что через три месяца ушли. Это вот самое интересное! Как жить, не получая зарплату?
Спасибо!
alx_mgr Автор
05.08.2025 05:09Отвечу по пунктам)
1. Работа над задачами всегда предполагает, что нужно задачу сформулировать, где-то вести, фиксировать промежуточные шаги и затем отдавать и фиксировать результат. Выбор между тем, чтобы делать это как попало и где придется, или делать это с помощью подходящего инструмента. Выбор каждый делает сам))
2. Тут вы правы, много времени на долгую организацию нет. Поэтому я и советую выбирать простой инструмент.
3. Когда сотрудники видят, что им самим стало удобнее, они это делают. Особенно радуются те, кому сложно было в личках добиваться всяких согласований промежуточных этапов. Трекер должен облегчать работу всей команды, а не только лидов.
4.Я понял, что вообще важно вовлекать сотрудников. Никакой таск-трекер не будет заменой нормальному отношению с командой. Вся моя статья про то, какие ошибки тут лучше не совершать. Если коротко: подготовить, помочь увидеть преимущества (это не сложно), сделать переход понятным и простым, выбрать оптимальный трекер.
5. см выше
6.В этом мире очень много разной работы)
PereslavlFoto
05.08.2025 05:09Где попало и как придётся, это ведь намного быстрее и дешевле. А в вашем примере пришлось нанимать ассистента, то есть не доход, а расход.
SteveJacobs
05.08.2025 05:09Целая команда разработчиков держалась на сообщениях в Телеграме? Ну ребята, честно? Я в это должен поверить? У меня тут уровень скепсиса зашкаливает, надо же быть таким креативным. Разработчики, по-настоящему работающие на больших проектах, в командах более пяти человек, точно поймут, о чём речь. Без таск-трекера — просто никак.
Заглядывая за завесу утверждений, обращая внимание на полностью субъективное протестное отношение автора к сабжу, я вижу не объективный разбор, а болезненный, почти провальный опыт — выучить новый инструмент. То ли из-за нежелания, то ли по другим причинам. Это я тоже понимаю. Бывали моменты, когда у меня у самого кровь вскипала, если заставляли менять привычный инструмент, а менеджеры довольно однозначно заявляли: "The ones who fail to use BLABLABLA fail to do their job." Приходилось изучать. Приходилось использовать.
Например, в Agile: там daily meetings — все кратко рассказывают, что делали, с какими проблемами сталкивались. Покосить не получится. Ведь не скажешь, что весь день читал Хабр, смотрел YouTube, лазил по LiveJournal или по ОК. Я видел что близится момент митинга, и я что-то должен сделать. Как обычно, именно в момент митинга я так сильно хотел работать, и конечно же митинг меня прерывал всегда именно в тот момент когда я сильнее хотел работать, ну вы понимаете, голимые отмазки. Именно дейли митинги как раз и заставляли пошевелиться. Я автора понимаю — и многие девелоперы тоже поймут. Но в данном рассказе я не вижу попытки информировать. Я вижу попытку повлиять на мнения.
Caraul
05.08.2025 05:09Я был настолько истощён и разочарован собой
Это нормально и даже хорошо - это обратная связь действует.
ryo_oh_ki
"Люди гибнут за канбан" (c) опера Гуно "Фауст" (почти)
MEGA_Nexus
Канбан, тут кстати, не причём. Автор допустил кучу ошибок, т.к. это его первая руководящая должность и первый такой серьёзный проект. Так что он собрал все шишки своей головой. До Канбан там дело даже не дошло.
Reposlav
Тут была ошибка руководства, что неопытного сотрудника оставили без контроля. По-хорошему, у ТС должен был быть наставник