Отчёт vs. таск-трекер

clip_image002Тут в комментариях к одному моему блогу был микрообмен мнениями по вопросу замены отчётов таск-трекингом. В целом я и сам с удовольствием бы избавился от отчётов и даже сделал так однажды без особого вреда для дела. Какое-то время перед очередным повышением, с инженеров отчёт я собирал только по отдельным проектам и голосом (если попутал, пусть ребята поправят). Сначала на планёрке, а потом и вовсе в режиме «привет, как дела» (мне кое-кто сказал, что отчёт на планёрке напрягает. Спасибо, кое-кто ;) ). То есть отчёт в виде большой простыни в этой команде писал только один человек – я.

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

Мысль №1: задачи, они мелкие. Ну там поставить сервер, настроить роль, изменить настройки, расследовать инцидент. То, что подавалось от меня наверх, оно, хоть и задача, но выглядит уже совсем по-другому: создать новый экземпляр сервиса Х. Обеспечить телефонной связью офис Y.

Мысль №2: задачи, как таковые, вообще никого не интересуют. Вот такое вот откровение. Простите, друзья-инженеры. Но наше с вами «мы установили обновления на систему Z» вообще никому не интересно. Подозреваю, также, что моё «Обеспечить телефонной связью новый офис» тоже через пару уровней управления уже не интересно. И точно знаю, «создан новый экземпляр такого-то сервиса» не интересен уже даже мне – всего-то руководителю отдела.

Мысль№3: а вот бы инженеры писали так, чтобы было интересно даже генеральному. Хых… Мечты.

В итоге, менеджерам приходится служить эдакими передатчиками с нижних уровней на верхние. С транслированием смысла в сущности более высокого уровня. И обратно. Эдакая модель OSI менеджерского разлива. Кстати, да, вполне себе инкапсуляция. Нужно создавать новый стандарт ;)

Получается, что основных направлений работы два:

1) Сделать так, чтобы каждое нижестоящее звено писало Эзоповым слогом так, как нужно следующей ступени управления. Я вот учусь. Тяжело даётся. Но оно того стоит.

2) Делать так, чтобы отчётов было не нужно. Но вот тут я вообще пока не продвинулся. Я слышал идеи вроде холакратии, но пока не видел вживую ни одной более-менее крупной организации, где это бы работало у меня на глазах (чем там дело в Кнопке закончилось, BTW?). И тем более, есть сомнения, что холакратию можно построить в отдельно взятом подразделении большой компании. Может, я заблуждаюсь? Расскажете?

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

· Какое конкретно направление перегружено?

· Насколько?

· Как долго это потенциально будет продолжаться?

· Нужно ли бежать и предупреждать всех заинтересованных, что все SLA поползут или это просто флуктуация и можно пока не беспокоиться?

В общем, тоже очень нужная штука. У неё ещё много применений. Но вот отчёты по ней строить у меня не получается. У кого получается, делитесь, как делали. (товарищ kabal375 уже поделился парой примеров. Спасибо, буду думать).

Реклама

Отчёт vs. таск-трекер: 6 комментариев

  1. Kirill Nikolaev

    >Мысль№3: а вот бы инженеры писали так, чтобы было интересно даже генеральному
    >Эдакая модель OSI менеджерского разлива.

    Тут ведь ещё как — не все задачи вообще имеет смысл, даже переформулированными, отправлять выше, т.е. некоторая информация в этом процессе теряется вообще. И инженер по многим задачам не сможет сформулировать красиво, т.к. он выполняет только часть того, что будет в более высокоуровневом отчете описано единым пунктом.

    Нравится

  2. kabal375

    >Мысль№3: а вот бы инженеры писали так, чтобы было интересно даже генеральному
    >Эдакая модель OSI менеджерского разлива.

    Про модель OSI классно подмечено! Вот только в модели OSI сетевые интерфейсы не пытаются формировать дейтаграммы на втором уровне так чтобы они были понятны приложениям.

    Беда с трекерами в том, что их возводят либо чисто формально (ну у всех есть и у нас пусть будет) или лоу-левел менеджеры типа меня насаждают их на своём уровне по своей же инициативе а выше система не растёт. А коль нет интеграции с высшими слоями, то и никакой модели OSI нет.
    Если бы инициатива или хотя бы принятие интеграции системы отчётов с трекером исходила сверху, при должном проектировании и допиливании системы можно было бы автоматизировать процесс (отчётности) контроля процессов.
    Инженеры отчитываются по задачам.
    Менеджер первого уровня получает свою сводку по загрузке, просрочкам и качеству. И пишет свои комментарии по проектам, в которые эти задачи входят.
    Менеджер второго уровня видит куда и как движутся проекты и куда и сколько (осваивается) тратится бюджетов. В свою очередь оформляет состояние дел по направлениям.
    И так до прикладного уровня.

    Нравится

    1. Alexander Trofimov Автор записи

      Ну же! Все аналогии ложны и используются либо для иллюстрации чего-то либо для развлечения. Если поймаешь меня когда-то за попыткой обосновать что-то аналогией, можешь меня смело в это ткнуть мордой =)
      Всё, что ты написал это такие же мечты, как мои о том, чтобы инженер сразу писал на уровне CEO. Каждому свой уровень, для этого, наверное, и существует институт руководства. CEO не может тебе сказать внедрить таск-трекер, для него это большая абстракция, чем для нас с тобой стратегия развития компании на 10 лет. Задача такого линка это, как мне сейчас кажется (не дорос ещё до знания ;) ), задача среднего менеджмента.

      Нравится

      1. kabal375

        Я, пожалуй, некорректно выразился. Мечты мои не в том, что руководство уровня директора компании будет допиливать и использовать трекер, или координировать его установку, или даже вообще будет в курсе его существования.
        Верно, модель OSI тут лишь аналогия. Аналогия иерархической абстракции. Где каждый следующий уровень оперирует данными предыдущего, преобразуя в приемлемый для следующего формат, отбрасывая лишнюю служебную информацию и навешивая необходимую.
        И мечты мои, что когда-то в организации будет существовать система, не требующая, следуя аналогии, чтобы транспортный уровень запрашивал у сетевого разные форматы не просто IP-пакетов, а вообще представления данных, потому что каждое приложение хочет их по разному видеть.
        Пока же получается, что разных систем получения и передачи информации в любой компании используется масса (например, есть Сервисдеск, куда надо регистрировать заявки, но статус запрашивается по почте и телефону, конфигурации надо вести в какой-то инвентаризационной базе, документацию в шарепоинте, а раз в неделю писать отчёт в экселе с цветными кубиками.) В итоге достоверную и полную информацию найти очень непросто.
        В моём опыте просто был случай использования единой системы и я знаю, как это может облегчить жизнь всех участников. Правда, в компании от инженера до директора был только один уровень посредников — начальники отделов.
        По сути, это не обязательно должна быть одна программная среда, это может быть интеграция разных, главное чтоб без разнообразия интерфейсов и необходимости дублирования действий и данных на каждом уровне.

        Нравится

      2. Alexander Trofimov Автор записи

        Ой, нескоро это будет. Потому что, по сути, руководство тоже не всегда может чётко сформулировать, как нужно. Вот просто видно, что вот это вот неубедительно. Хорошо, если есть пример, тогда понятно более менее. По сути, занимаемся подбором протокола на лету. Потому что сегодня работаешь в одной компании, а завтра она вышла на другой рынок, или прошла реорганизация, и — вуаля — уже нужно совсем другое. Загнать себя в прокрустово ложе автоматизации в таком случае тоже верная смерть. Вот и приходится тратить чёрт знает сколько денег на менеджеров. И никакой холакратии =)
        Но, опять-таки, я очень хорошо понимаю, о чём ты говоришь, и тоже хотел бы, чтобы всё было прозрачно, тогда не было бы этих потерь на передачу и трансляцию информации.

        Нравится

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s