Комментарии 24
Во многих проектах, если в них навести порядок, то всё сломается. Причина? Проект живёт не благодаря руководству и задачам, а вопреки, на инициативе снизу. Сломали инициативу или затруднили "самоволку" — и проект перестаёт жить, сколько бы его не пытались потом поправить.
Грустно, конечно, но самоорганизация — великая вещь.
Да, такое бывает. В гос компаниях чаще, в коммерческих реже. Чем-то напоминает ситуацию: внедрили CRM и продажи упали.
Это всегда вопрос открытого диалога внутри команды и плавного перехода к новым правилам, если они нужны. В малых компаниях где все работает, редко кто-то задумывается о систематизации. Если большая команда (50 человек) держится только на инициативе — это чудо.
Это всегда вопрос открытого диалога внутри команды и плавного перехода к новым правилам, если они нужны. В малых компаниях где все работает, редко кто-то задумывается о систематизации. Если большая команда (50 человек) держится только на инициативе — это чудо.
Бывает так, что в основе бизнес-процесса чьё-то очень удачное решение, которое
а) не вербализировано
б) распределено между несколькими людьми
в) включает в себя критичные и нетривиальные этапы, отсутсвующие в ТЗ или проигнорированные при обсуждении
г) являющееся центральной частью решения. Администрирование фокусируется на известных вещах, которые являются второстепенными, а первичным (по генерируемому результату или стабильности процесса) является этот "ad-hoc" бизнес-процесс.
Напоминаю рассказ про ракетные двигатели, где старый дядечка на ощупь мог проверить правильность детали, а (существавшие) приборы не справлялись.
Типовые проблемы с которыми сталкивался я:
1)Прерывания от вышестоящего руководства. Звонок ген. директора — иди туда и сделай то.
Почему не через систему? Допустим, он сидит в другом городе на переговорах среди таких же топов и информация ему нужна срочно. Во-первых, он будет очень глупо выглядеть «Ща подождите, мне в мобилке надо потупить — задачу поставить.» Во-вторых, между мной и им цепочка людей… пока задача будет делегирована по всей ветке — пройдет много времени (время задержки = оперативности всей цепочки).
2)Возможность в единицу времени поставить 2 и более задач. Т.е. Цепочка подчинений Руквовдитель А -> Руководитель Б -> сотрудник. Т.е. проблема возникает в момент когда руководитель А ставит задачу сотруднику. У сотрудника возникает во-первых конфликт приоритетов, во-вторых смещение одной из задач по времени. Можно конечно решать это правами, но попробуйте объяснить генеральному, что ему теперь напрямую подчиняются только вот эти 3-5-10 человек, а остальные шлют нфиг. И третье. Руководитель Б, может не увидеть что его сотрудника чем-то заняли.
Отсюда вывод — я не встречал систем которые 1)блокировали ли постановку задачи, если сотрудник уже (или в дальнейшем будет) чем-то занят. 2)Если кто-то ставит доп. задачу сотруднику, то оповещались все причастные.
3)Все таск системы приходят к тому что сотрудник должен быть постоянно занят решением как-то задачи. Если у кого-то не светится задача, значит он бездельничает, надо лишать премии, грузить больше, вот он свободный ресурс. А потом оказывается, что работа носит всплесковый характер или что люди начинают размазывать таски, придумывать абы что лишь бы не засветиться «бездельником».
P.s.Опыт основан на реалиях российских компаниях.
1)Прерывания от вышестоящего руководства. Звонок ген. директора — иди туда и сделай то.
Почему не через систему? Допустим, он сидит в другом городе на переговорах среди таких же топов и информация ему нужна срочно. Во-первых, он будет очень глупо выглядеть «Ща подождите, мне в мобилке надо потупить — задачу поставить.» Во-вторых, между мной и им цепочка людей… пока задача будет делегирована по всей ветке — пройдет много времени (время задержки = оперативности всей цепочки).
2)Возможность в единицу времени поставить 2 и более задач. Т.е. Цепочка подчинений Руквовдитель А -> Руководитель Б -> сотрудник. Т.е. проблема возникает в момент когда руководитель А ставит задачу сотруднику. У сотрудника возникает во-первых конфликт приоритетов, во-вторых смещение одной из задач по времени. Можно конечно решать это правами, но попробуйте объяснить генеральному, что ему теперь напрямую подчиняются только вот эти 3-5-10 человек, а остальные шлют нфиг. И третье. Руководитель Б, может не увидеть что его сотрудника чем-то заняли.
Отсюда вывод — я не встречал систем которые 1)блокировали ли постановку задачи, если сотрудник уже (или в дальнейшем будет) чем-то занят. 2)Если кто-то ставит доп. задачу сотруднику, то оповещались все причастные.
3)Все таск системы приходят к тому что сотрудник должен быть постоянно занят решением как-то задачи. Если у кого-то не светится задача, значит он бездельничает, надо лишать премии, грузить больше, вот он свободный ресурс. А потом оказывается, что работа носит всплесковый характер или что люди начинают размазывать таски, придумывать абы что лишь бы не засветиться «бездельником».
P.s.Опыт основан на реалиях российских компаниях.
Удваиваю предыдущий комментарий, но вопрос у меня попроще: каким образом вы достигаете того, что общение по задачам ведётся в вашей системе, а не в постели курилке?
На 100% мы этого не достигаем. Можем только сказать, что мы перетягиваем больше диалогов по задачам, чем самые популярные в мире системы (тестировали и смотрели с клиентами). Причина — интерфейс. У нас задача — это как чат в Телеграмме, когда общение затухает карточка спускается в низ с писке того, на что ты подписан.
когда общение затухает карточка спускается в низ с писке того, на что ты подписан
Весь мой опыт говорит о том, что когда общение затухает, карточка должна подниматься максимально наверх, и быть уже отдана разработчику для выполнения. Иначе получается, что мы все обсудили — и хорошо, можно обсудить что-нибудь еще :)
Offtopic: я понимаю, что уже поздновать, но будьте готовы к тому, что нейтивы считают название компании как аллюзию на fragile вместо (так вижу) задуманного agile, и это может быть прямо шоу-стоппером.
На мой взгляд, главная проблема всех таск-трекинг систем находится на стыке взаимодействия отделов. Приведу пример.
Отдел маркетинга решает внедрить новую систему сбора статистики. Предположим, у компании имеются 3 продукта, куда это следует сделать. Соответственно, руководитель отдела маркетинга создаёт у себя 1 задачу:
Статистика-1 — Внедрить систему сбора статистики Ы в продукты компании
и в ней — три подзадачи:
Статистика-1.1 — Внедрить систему сбора статистики Ы в Продукт № 1
Статистика-1.2 — Внедрить систему сбора статистики Ы в Продукт № 2
Статистика-1.3 — Внедрить систему сбора статистики Ы в Продукт № 3
Корневую задачу он назначает на выделенного сотрудника своего отдела, который будет коммуницировать с продуктовыми командами, а подзадачи — на руководителей соответствующих проектов.
Все коммуникации с продуктовыми командами отдел маркетинга желает вести в соответствующих подзадачах. Мы использовали asana — так что обсуждения были доступны всем заинтересованным лицам.
Но вся проблема в том, что у продуктовых команд своя система работы с задачами. То, что для отдела маркетинга выглядит, как задача и три подзадачи, для каждой продуктовой команды выглядит, как проект (ну или мини-проект). Должны быть сформулированы и обсуждены критерии успешного завершения этого проекта, разработаны тесты для проверки критериев, задачи разбиты на подзадачи и распределены между разными специалистами (клиентскими программистами, серверными программистами).
Да, обсуждать условия задачи удобно в маркетинговых подзадачах. Но управлять через них разработкой — нет.
Можно, конечно, в маркетинговых подзадачах обсудить условия, а затем — вынести их в виде отдельных задач для продуктовой команды. Но после этого потеряется связь между маркетологом и отдельными программистами, т.к. программисты будут работать по своим задачам, а маркетолог — не будет иметь доступа к ним (а даже, если и будет, то ему будет неудобно давать ответы во множестве разработческих задач, и он в них запутается).
Отдел маркетинга решает внедрить новую систему сбора статистики. Предположим, у компании имеются 3 продукта, куда это следует сделать. Соответственно, руководитель отдела маркетинга создаёт у себя 1 задачу:
Статистика-1 — Внедрить систему сбора статистики Ы в продукты компании
и в ней — три подзадачи:
Статистика-1.1 — Внедрить систему сбора статистики Ы в Продукт № 1
Статистика-1.2 — Внедрить систему сбора статистики Ы в Продукт № 2
Статистика-1.3 — Внедрить систему сбора статистики Ы в Продукт № 3
Корневую задачу он назначает на выделенного сотрудника своего отдела, который будет коммуницировать с продуктовыми командами, а подзадачи — на руководителей соответствующих проектов.
Все коммуникации с продуктовыми командами отдел маркетинга желает вести в соответствующих подзадачах. Мы использовали asana — так что обсуждения были доступны всем заинтересованным лицам.
Но вся проблема в том, что у продуктовых команд своя система работы с задачами. То, что для отдела маркетинга выглядит, как задача и три подзадачи, для каждой продуктовой команды выглядит, как проект (ну или мини-проект). Должны быть сформулированы и обсуждены критерии успешного завершения этого проекта, разработаны тесты для проверки критериев, задачи разбиты на подзадачи и распределены между разными специалистами (клиентскими программистами, серверными программистами).
Да, обсуждать условия задачи удобно в маркетинговых подзадачах. Но управлять через них разработкой — нет.
Можно, конечно, в маркетинговых подзадачах обсудить условия, а затем — вынести их в виде отдельных задач для продуктовой команды. Но после этого потеряется связь между маркетологом и отдельными программистами, т.к. программисты будут работать по своим задачам, а маркетолог — не будет иметь доступа к ним (а даже, если и будет, то ему будет неудобно давать ответы во множестве разработческих задач, и он в них запутается).
Новое правило из законов Мерфи: если обсуждение задачи в СУ будет видеть руководство, то никакого обсуждения там не будет.
Вот это не совсем так. Например, slack (и тем более e-mail) вообще-то позволяет владельцу компании получить все диалоги. И ничего, весь мир общается.
Если люди работают в одном офисе/заводе, то 80% общения по работе у них будет идти мимо официальных каналов связи.
Инфа сотка? А если люди — адекватные профессионалы?
Быть адекватными профессионалами недостаточно — надо чтобы еще и руководство было таким. То есть уже далеко не 100% случаев.
Зачем адекватному профессионалу работать под управлением неадекватного непрофессионала?
Жизнь немного сложнее, чем простые логические построения. И хорошо, когда CRM может это учитывать. А для этого надо давать возможность руководству компании контролировать не всё и вся, а только самые важные (для них) процессы. Остальные вещи тоже могут быть автоматизированы, но «мягко» (без возможности контроля сверху). Тогда рядовые работники смогут пользоваться CRM-кой не только по приказу руководства, но и потому что им это удобнее (чем встречаться в курилках или коридорах)
На все без исключения обсуждения, которые вообще заслуживают обсуждения, а не могут быть решены мной в одно рыло — я всегда зову CTO. Потому что лишний умный человек никогда не помешает.
А если приходит CEO, всегда можно вежливо намекнуть ему, чтобы он пошел пообсуждал бизнес, или посидел тихо в уголке.
На все без исключения обсуждения, которые вообще заслуживают обсуждения, а не могут быть решены мной в одно рыло — я всегда зову CTO. Потому что лишний умный человек никогда не помешает.Везет вам.
А если приходит CEO, всегда можно вежливо намекнуть ему, чтобы он пошел пообсуждал бизнес, или посидел тихо в уголке.И везёт всё больше и больше.
Это все так олдово. Сейчас же компании постепенно отходят от жесткой иерархичности и постановки задач сверху-вниз. Может, система и хорошая, но рынок у нее постепенно самоустранится из за неэффективности.
Superslon А там возможна постановка задач только сверху вниз?
Ну нет, конечно. По умолчанию ставим настройку, что все отделы открытые — все могут ставить всем в рамках отдела. И да, есть тенденция к «демократии» в компаниях. Руководители крайне редко просят строгую иерархию и если просят, это всегда грозит провалом внедрения.
Закрытые отделы чаще всего используются для команд, без внутреннего общения, например, для фрилансеров на мелкие подряды.
Немного статистики с облака, выгрузка по 10 000 последних тасков:
74% — задач ставится админами компаний и руководителями отделов или проектов
25% — сотрудниками внутри команд
1% — регулярные автоматические задачи
Закрытые отделы чаще всего используются для команд, без внутреннего общения, например, для фрилансеров на мелкие подряды.
Немного статистики с облака, выгрузка по 10 000 последних тасков:
74% — задач ставится админами компаний и руководителями отделов или проектов
25% — сотрудниками внутри команд
1% — регулярные автоматические задачи
Самые важные задачи:
— Формировать бизнес-процесс, если его нет.
— Корректировать бизнес-процесс, если он не отвечает реальности. Сейчас это называется модным словом workflows, утвержденные цепочки работ с зафиксированными требованиями к результатам. И средства для оптимизации этих workflows — на чем затыки, на какие действия тратится много времени и т.д.
— Дробить клиентскую (абстрактную) задачу по разным отделам, проектам и сотрудникам.
— Дробить задачу для сотрудника, если он тупит — и контролировать выполнение малыми шагами.
— Ведение обновляемой документации, базы знаний.
— Формировать бизнес-процесс, если его нет.
— Корректировать бизнес-процесс, если он не отвечает реальности. Сейчас это называется модным словом workflows, утвержденные цепочки работ с зафиксированными требованиями к результатам. И средства для оптимизации этих workflows — на чем затыки, на какие действия тратится много времени и т.д.
— Дробить клиентскую (абстрактную) задачу по разным отделам, проектам и сотрудникам.
— Дробить задачу для сотрудника, если он тупит — и контролировать выполнение малыми шагами.
— Ведение обновляемой документации, базы знаний.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фокус на управлении задачами. Как мы делаем свою систему управления