Как-то давно я приезжал на одну конференцию, и рассказывал об опыте ускорения работы программистов. Всем понравилось, многие захотели повторить этот опыт у себя. Начали задавать вопросы — и методические, и технические, по оптимизации собственной системы управления задачами.
Потом на другую конференцию съездил, еще раз рассказал. Опять навалились с вопросами, загорелись желанием что-то изменить.
Я отвечал — пф, в чем проблема-то? Вы же программисты, возьмите и сделайте! Добавьте измерение задач, правильную систему приоритетов, учет компетенций и т.д.
Но, как ни странно, почти никто не кинулся менять свою систему. Сейчас, занимаясь несколькими проектами по ускорению команд, я продолжаю удивляться — блин, в чем проблема-то? Я же обо всем написал, что и как надо делать. Например, в «1С, не болей». Но нет, сидят, ничего не делают, только говорят — хотим ускориться, хотим больше денег зарабатывать, хотим прогресса.
В общем, я расстроился и решил сам эту систему сделать. Получилось управление задачами Flowcon. Спешу похвастаться — может, это вас подтолкнет к изменению своей системы?
Управление задачами в Flowcon – это два в одном: конфигурация для платформы 1С и облачный сервис. Они могут работать как в паре, так и по отдельности. Конфигурация может, и должна ставиться на любую другую корпоративную информационную систему, используемую на предприятии. Потому что задачи в отрыве от данных намного менее эффективны.
Конфигурация растет, как снежный ком, в хорошем смысле. Чем дальше, тем она полезнее и функциональнее. Мы сами ее используем, и постоянно обогащаем новыми идеями – и своими, и пользователей.
Ключевое отличие управления задачами Flowcon в том, что это конфигурация, реализованная по методике. Это не очередное решение, в котором «вы сможете настроить свои бизнес-процессы».
Вы наверняка знаете простую истину: проблема в процессе, а не в его автоматизации.
Методику управления задачами и проектами, которая повышает эффективность работы, мы нарабатывали несколько лет. И на внутренней автоматизации, когда работали на заводах, и на разработке массовых продуктов, и на проектах внедрения для внешних заказчиков.
Эта методика и стала основой Flowcon, а конфигурация управления задачами просто автоматизирует ее применение.
Соответственно, хочу предостеречь тех, кто захочет повторить мой путь: если вам принципиально важно работать так, как вы привыкли, то подобные решения могут вам не подойти. Может, поэтому никто свою систему не дорабатывает?
Что-то, конечно, получится, может станет прозрачнее, или проще, или интереснее, но вы не получите главного – повышения эффективности.
Если ваша эффективность не растет, или вообще не измерена (оценка «да все нормально вроде» — не измерение), то проблема в процессе, в методике управления задачами. Какой тогда смысл брать или создавать очередное решение, подстраивать его под свои процессы, и получать тот же результат?
Поэтому будьте готовы к изменениям. Иначе вас ждет разочарование – эффективность не вырастет.
Повышение эффективности – главное назначение Flowcon, и как методики, и как автоматизированной системы.
Краткая история методики Flowcon – не такая уж и краткая, потому что продолжалась более 10 лет. Но мы старались подсократить, как могли – вот статья.
Процесс движения задачи очень простой, состоит из трех участников – инициатора, ответственного и исполнителя. По нашей практике, это самый распространенный случай.
Инициатор – тот, кто ставит задачу. Это может быть внутренний заказчик, вроде главбуха, или начальник, или человек может сам себе поставить задачу. Ответственный – это координатор, который распределяет задачи. Может быть руководитель подразделения, или тимлидер, или просто координатор – такие должности тоже встречаются.
Исполнитель – тот, кто непосредственно реализует то, что написано в задаче. Исполнителя выбирает ответственный.
Разумеется, все эти роли может выполнять один человек – я сам, в основном, так и делаю, т.к. использую флакон для себя. Чтобы не тратить много времени на выбор самого себя, мы приделали быстрые кнопки.
В методике Flowcon крайне важен жизненный цикл задачи. По каждой из них, в любой момент времени, должно быть понятно – кто и что должен сделать. Принять в работу, выполнить, проверить результат, назначить исполнителя и т.д.
Выглядит жизненный цикл так:
1. Инициатор создает задачу, указывает ответственного, пишет чего хочет;
2. У ответственного два варианта – принять задачу в работу, или отправить на доработку, если постановка не годится:
3. В любой момент, пока задача не прошла весь цикл, инициатор может ее отменить;
4. Если ответственный отправляет задачу на доработку, инициатор может или пойти ему навстречу, или отменить задачу:
5. Когда задача, наконец, принята в работу, надо назначить исполнителя – этим занимается ответственный;
6. У исполнителя вариантов не много – он может только выполнить задачу
7. Когда исполнитель закончил, задача улетает инициатору, у которого два разумных варианта действий:
8. Если результат устраивает инициатора, то жизненный цикл задачи завершается. Если же что-то не так, то задача возвращается исполнителю.
История смены статусов, то есть жизненный цикл задачи, сохраняется:
История нужна для того, чтобы оценивать потери времени на этапах согласований, и соотносить ее со временем выполнения в соответствующих отчетах.
Текущий статус задачи отображается как в форме документа:
Так и в форме списка всех задач:
Принципиально задача может находиться в трех ипостасях:
1. Нужно чье-то решение;
2. Ее нужно выполнять;
3. Про нее нужно забыть.
Про выполнение поговорим дальше, а пока – про принятие решений. Прием в работу, назначение исполнителя, уточнение постановки, проверка результата, доработка – все это состояния, в которых кто-то должен принять какое-то решение.
Методика Flowcon говорит, что решения надо принимать, по возможности, быстро, потому что пока нет решения, задача зависает на соответствующем участке жизненного цикла.
Чтобы не мучить пользователей, мы разделили список задач на три принципиальных раздела: принять решение, выполнить и просто список всех задач.
На закладке «В работе» собираются все задачи, по которым надо принять решение текущему пользователю системы:
Прелесть в том, что не надо ничего искать. Зашел в форму списка задач и сразу увидел, где нужно твое решение. Все раскидал, и занялся исполнением. Нормальное состояние списка «Принять решение» — пустое.
Но флакон не было бы флаконом, если бы не контролировал принятие решений. На каждый вид решения есть норматив времени в настройках Flowcon:
Понятно, что в реальной жизни одним и тем же нормативом всех пользователей не опишешь – кто-то ведь реально не может принимать решение в течение часа? Поэтому есть возможность задавать индивидуальные цифры, в расширении пользователя:
Соответственно, в списке «Принять решение» отображается срок реагирования, чтобы человек не переживал:
Параметры задачи – это оценка в баллах, срочность/важность и срок выполнения:
Оценка задачи в баллах – это самое главное. В методике Flowcon этому посвящен целый раздел, поэтому повторяться не буду.
Ставить задаче срок, или нет, решает инициатор. У меня нет однозначной рекомендации на счет того, нужен задачам срок, или нет. Важно правильно понимать, что этот срок означает.
Единственное, что хочется отметить: какой-то срок все-таки должен быть, иначе система приоритетов (см. ниже) сделает так, что задача не решится никогда. Поэтому у нас в настройках есть две опции:
Разумный срок – это некий срок по умолчанию, который ставится всем задачам, если инициатор не указал точную дату. Флажок «Всегда ставить срок выполнения» — чисто интерфейсный, он взводит флажок «Нужно выполнить к сроку» в каждой новой задаче.
Срочность и важность – это приоритеты по матрице Эйзенхауэра. Понимая, что мнение у инициатора и ответственного может различаться, мы возможность расстановки приоритетов для каждого. Заполнять эти реквизиты не обязательно.
Система приоритетов – одна из важнейших частей флакона. В методике много написано о том, почему важно максимально убрать возможность выбора задачи для исполнителя – эффективность от этого только выиграет, а человек мучиться не будет.
Мы долго думали, как устроить систему приоритетов, и пришли к самому простому решению – суммированию отдельных оценок каждого фактора, влияющего на приоритет. Сейчас таких факторов пять (будет больше):
Вы просто ставите баллы приоритета каждому фактору, а система смотрит на задачу, и если фактор присутствует, добавляет их к общей цифре приоритета. Например, если вы выбрали только один фактор – срочность инициатора, и поставили ему 2 балла, то срочная задача будет иметь приоритет 2, а не срочная – 0.
Чуть подробнее скажу про статус буфера. Буфер – это длина отрезка времени от даты принятия задачи в работу до установленного срока исполнения. Например, пусть это будет 10 дней.
В любой момент времени мы находимся в какой-то точке этого отрезка. Прошел один день – значит, позади 10 % отрезка. Прошло три дня – 30 %, и т.д.
Соответственно, есть и обратная цифра – сколько времени осталось до срока. Если прошел один день, то осталось 90 %. Если прошло три дня, то осталось 70 %, и т.д. Это и есть статус буфера.
Ну а дальше все просто. Вы в настройке приоритетов ставите цифру, которая называется «Предел статуса буфера» — это сумма, добавляемая к приоритету, когда статус буфера равен нулю, т.е наступил срок выполнения задачи. А пока срок не пришел, эта цифра умножается длину пройденного участка времени.
Например, вы поставили оценку 10. Если прошло 30 % времени, то к приоритету добавится 3. Если задача только-только поставлена, то прибавится 0. Если времени совсем не осталось, то добавиться 10.
А если срок уже прошел, то добавится больше 10. Например, если прошло 150 % времени, то добавится 15. Таким образом, никакая задача не пропадет, и не затеряется.
Настройки приоритетов хранятся в справочнике «Настройки очередей». Раз это справочник, то понятно – настроек можно быть сколько угодно. Основная, работающая по умолчанию, указывается в настройках Flowcon. Для конкретного исполнителя можно переопределить, в расширении пользователя.
Главный смысл, который мы вкладывали в систему приоритетов – простота. И настройки, и использования. Систему приоритетов нужно настроить один раз, и надолго о ней забыть – она будет работать сама.
Если приоритеты по матрице Эйзенхауэра – статические, то по статусу буфера – динамические. Система не забудет, что время идет, и будет автоматически двигать задачи в очереди, чтобы не допустить просрочку.
Каждой задаче присваивается, и автоматически пересчитывается номер в очереди. Очередь привязана к текущему исполнителю, т.е. она у каждого своя.
Текущий номер в очереди и приоритет можно увидеть как в форме задачи:
Так и в списке задач к исполнению:
Список задач, разумеется, сортирован по номеру в очереди. Исполнитель должен просто брать их по порядку, и делать. А если не делает, то флакон об этом покажет.
Соблюдает исполнитель очередность, или нет, видно в отчете «График отклонений от очереди»:
Когда исполнитель закрывает задачу, как выполненную, система запоминает, на какой позиции в очереди она была. Ну и рисует на графике сумму отклонений за период. Отклонение – это разница между позицией в очереди на момент закрытия, и единицей.
Как видите, у нас в Окнософте с очередью большие проблемы. А когда перешли на флакон, и увидели, то схватились за голову и стали исправляться – график пошел вниз.
Второй отчет – «График эффективности». Это самый главный отчет, в котором будет видеy рост эффективности исполнителей. На графике выводится количество баллов выполненных задач, в привязке к периоду.
Например, вот что происходило с нашей эффективностью:
Отчетливо видно, когда мы ходили в отпуск – март и август, был провал в сумме баллов. Хотя, в целом, тренд положительный и очень впечатляющий.
Не менее важный отчет, необходимый, в первую очередь, координатору каждый день – это «Контроль исполнителей».
Этот отчет – все в одном окне. Не надо никого дергать, спрашивать, кто как работает, кто сколько сделал. Зашел, и посмотрел.
Что важно – исполнение задач поделено по периодам, чтобы избежать влияния «вспышек» — например, если исполнитель закрыл сегодня одну большую задачу, а с начала месяца ничего не делал. Тут видно сразу и месяц, и неделю, и сегодняшний день. А подсветка красным поможет понять, у кого динамика нормальная, а у кого – трудности. Отличный повод поговорить.
Количество отчетов будет расти, пока – только те, без которых нельзя обойтись.
Важнейшим направлением развития системы являются мгновенные оценки. Раз мы знаем, с какой скоростью работают исполнители, как они соблюдают очередь, как укладываются в сроки, то мы можем делать прогнозы. Например, сколько реально времени займет выполнение задачи.
Функциональность мгновенных оценок еще не закончена, пока есть только один параметр – текущая скорость, т.е. сколько баллов задач человек выполняет в день.
Видно ее в форме выбора исполнителя:
Ответственный, зная оценку задачи, может сразу прикидывать, кому ее лучше поручить, исходя из текущей скорости.
Какая система управления задачами без прений? У нас тоже есть – комментарии.
Комментарии иерархические, поэтому видно, кто кому и на что отвечает. Ведется учет прочтения комментариев, поэтому в списке задач жирным выделяются те, где есть что почитать:
Методика флакон говорит, что люди должны сотрудничать. Часто бывает так, что один человек помогает другому решить задачу. Нам важно, чтобы вклад каждого был учтен, поэтому в задаче можно уточнить список исполнителей, и определить для каждого коэффициент трудового участия (КТУ):
Баллы за задачу будут поделены между исполнителями, в пропорции КТУ. Так, вроде, честнее.
Кстати, пока писал статью, весь мой список задач для принятия решения покраснел:
Пока, вроде, все.
Потом на другую конференцию съездил, еще раз рассказал. Опять навалились с вопросами, загорелись желанием что-то изменить.
Я отвечал — пф, в чем проблема-то? Вы же программисты, возьмите и сделайте! Добавьте измерение задач, правильную систему приоритетов, учет компетенций и т.д.
Но, как ни странно, почти никто не кинулся менять свою систему. Сейчас, занимаясь несколькими проектами по ускорению команд, я продолжаю удивляться — блин, в чем проблема-то? Я же обо всем написал, что и как надо делать. Например, в «1С, не болей». Но нет, сидят, ничего не делают, только говорят — хотим ускориться, хотим больше денег зарабатывать, хотим прогресса.
В общем, я расстроился и решил сам эту систему сделать. Получилось управление задачами Flowcon. Спешу похвастаться — может, это вас подтолкнет к изменению своей системы?
Управление задачами в Flowcon – это два в одном: конфигурация для платформы 1С и облачный сервис. Они могут работать как в паре, так и по отдельности. Конфигурация может, и должна ставиться на любую другую корпоративную информационную систему, используемую на предприятии. Потому что задачи в отрыве от данных намного менее эффективны.
Конфигурация растет, как снежный ком, в хорошем смысле. Чем дальше, тем она полезнее и функциональнее. Мы сами ее используем, и постоянно обогащаем новыми идеями – и своими, и пользователей.
Методика
Ключевое отличие управления задачами Flowcon в том, что это конфигурация, реализованная по методике. Это не очередное решение, в котором «вы сможете настроить свои бизнес-процессы».
Вы наверняка знаете простую истину: проблема в процессе, а не в его автоматизации.
Методику управления задачами и проектами, которая повышает эффективность работы, мы нарабатывали несколько лет. И на внутренней автоматизации, когда работали на заводах, и на разработке массовых продуктов, и на проектах внедрения для внешних заказчиков.
Эта методика и стала основой Flowcon, а конфигурация управления задачами просто автоматизирует ее применение.
Соответственно, хочу предостеречь тех, кто захочет повторить мой путь: если вам принципиально важно работать так, как вы привыкли, то подобные решения могут вам не подойти. Может, поэтому никто свою систему не дорабатывает?
Что-то, конечно, получится, может станет прозрачнее, или проще, или интереснее, но вы не получите главного – повышения эффективности.
Если ваша эффективность не растет, или вообще не измерена (оценка «да все нормально вроде» — не измерение), то проблема в процессе, в методике управления задачами. Какой тогда смысл брать или создавать очередное решение, подстраивать его под свои процессы, и получать тот же результат?
Поэтому будьте готовы к изменениям. Иначе вас ждет разочарование – эффективность не вырастет.
Повышение эффективности – главное назначение Flowcon, и как методики, и как автоматизированной системы.
Краткая история методики Flowcon
Краткая история методики Flowcon – не такая уж и краткая, потому что продолжалась более 10 лет. Но мы старались подсократить, как могли – вот статья.
Процесс
Процесс движения задачи очень простой, состоит из трех участников – инициатора, ответственного и исполнителя. По нашей практике, это самый распространенный случай.
Инициатор – тот, кто ставит задачу. Это может быть внутренний заказчик, вроде главбуха, или начальник, или человек может сам себе поставить задачу. Ответственный – это координатор, который распределяет задачи. Может быть руководитель подразделения, или тимлидер, или просто координатор – такие должности тоже встречаются.
Исполнитель – тот, кто непосредственно реализует то, что написано в задаче. Исполнителя выбирает ответственный.
Разумеется, все эти роли может выполнять один человек – я сам, в основном, так и делаю, т.к. использую флакон для себя. Чтобы не тратить много времени на выбор самого себя, мы приделали быстрые кнопки.
Жизненный цикл задачи
В методике Flowcon крайне важен жизненный цикл задачи. По каждой из них, в любой момент времени, должно быть понятно – кто и что должен сделать. Принять в работу, выполнить, проверить результат, назначить исполнителя и т.д.
Выглядит жизненный цикл так:
1. Инициатор создает задачу, указывает ответственного, пишет чего хочет;
2. У ответственного два варианта – принять задачу в работу, или отправить на доработку, если постановка не годится:
3. В любой момент, пока задача не прошла весь цикл, инициатор может ее отменить;
4. Если ответственный отправляет задачу на доработку, инициатор может или пойти ему навстречу, или отменить задачу:
5. Когда задача, наконец, принята в работу, надо назначить исполнителя – этим занимается ответственный;
6. У исполнителя вариантов не много – он может только выполнить задачу
7. Когда исполнитель закончил, задача улетает инициатору, у которого два разумных варианта действий:
8. Если результат устраивает инициатора, то жизненный цикл задачи завершается. Если же что-то не так, то задача возвращается исполнителю.
История смены статусов, то есть жизненный цикл задачи, сохраняется:
История нужна для того, чтобы оценивать потери времени на этапах согласований, и соотносить ее со временем выполнения в соответствующих отчетах.
Текущий статус задачи отображается как в форме документа:
Так и в форме списка всех задач:
Регулярный менеджмент
Принципиально задача может находиться в трех ипостасях:
1. Нужно чье-то решение;
2. Ее нужно выполнять;
3. Про нее нужно забыть.
Про выполнение поговорим дальше, а пока – про принятие решений. Прием в работу, назначение исполнителя, уточнение постановки, проверка результата, доработка – все это состояния, в которых кто-то должен принять какое-то решение.
Методика Flowcon говорит, что решения надо принимать, по возможности, быстро, потому что пока нет решения, задача зависает на соответствующем участке жизненного цикла.
Чтобы не мучить пользователей, мы разделили список задач на три принципиальных раздела: принять решение, выполнить и просто список всех задач.
На закладке «В работе» собираются все задачи, по которым надо принять решение текущему пользователю системы:
Прелесть в том, что не надо ничего искать. Зашел в форму списка задач и сразу увидел, где нужно твое решение. Все раскидал, и занялся исполнением. Нормальное состояние списка «Принять решение» — пустое.
Но флакон не было бы флаконом, если бы не контролировал принятие решений. На каждый вид решения есть норматив времени в настройках Flowcon:
Понятно, что в реальной жизни одним и тем же нормативом всех пользователей не опишешь – кто-то ведь реально не может принимать решение в течение часа? Поэтому есть возможность задавать индивидуальные цифры, в расширении пользователя:
Соответственно, в списке «Принять решение» отображается срок реагирования, чтобы человек не переживал:
Параметры задачи
Параметры задачи – это оценка в баллах, срочность/важность и срок выполнения:
Оценка задачи в баллах – это самое главное. В методике Flowcon этому посвящен целый раздел, поэтому повторяться не буду.
Ставить задаче срок, или нет, решает инициатор. У меня нет однозначной рекомендации на счет того, нужен задачам срок, или нет. Важно правильно понимать, что этот срок означает.
Единственное, что хочется отметить: какой-то срок все-таки должен быть, иначе система приоритетов (см. ниже) сделает так, что задача не решится никогда. Поэтому у нас в настройках есть две опции:
Разумный срок – это некий срок по умолчанию, который ставится всем задачам, если инициатор не указал точную дату. Флажок «Всегда ставить срок выполнения» — чисто интерфейсный, он взводит флажок «Нужно выполнить к сроку» в каждой новой задаче.
Срочность и важность – это приоритеты по матрице Эйзенхауэра. Понимая, что мнение у инициатора и ответственного может различаться, мы возможность расстановки приоритетов для каждого. Заполнять эти реквизиты не обязательно.
Система приоритетов
Система приоритетов – одна из важнейших частей флакона. В методике много написано о том, почему важно максимально убрать возможность выбора задачи для исполнителя – эффективность от этого только выиграет, а человек мучиться не будет.
Мы долго думали, как устроить систему приоритетов, и пришли к самому простому решению – суммированию отдельных оценок каждого фактора, влияющего на приоритет. Сейчас таких факторов пять (будет больше):
Вы просто ставите баллы приоритета каждому фактору, а система смотрит на задачу, и если фактор присутствует, добавляет их к общей цифре приоритета. Например, если вы выбрали только один фактор – срочность инициатора, и поставили ему 2 балла, то срочная задача будет иметь приоритет 2, а не срочная – 0.
Чуть подробнее скажу про статус буфера. Буфер – это длина отрезка времени от даты принятия задачи в работу до установленного срока исполнения. Например, пусть это будет 10 дней.
В любой момент времени мы находимся в какой-то точке этого отрезка. Прошел один день – значит, позади 10 % отрезка. Прошло три дня – 30 %, и т.д.
Соответственно, есть и обратная цифра – сколько времени осталось до срока. Если прошел один день, то осталось 90 %. Если прошло три дня, то осталось 70 %, и т.д. Это и есть статус буфера.
Ну а дальше все просто. Вы в настройке приоритетов ставите цифру, которая называется «Предел статуса буфера» — это сумма, добавляемая к приоритету, когда статус буфера равен нулю, т.е наступил срок выполнения задачи. А пока срок не пришел, эта цифра умножается длину пройденного участка времени.
Например, вы поставили оценку 10. Если прошло 30 % времени, то к приоритету добавится 3. Если задача только-только поставлена, то прибавится 0. Если времени совсем не осталось, то добавиться 10.
А если срок уже прошел, то добавится больше 10. Например, если прошло 150 % времени, то добавится 15. Таким образом, никакая задача не пропадет, и не затеряется.
Настройки приоритетов хранятся в справочнике «Настройки очередей». Раз это справочник, то понятно – настроек можно быть сколько угодно. Основная, работающая по умолчанию, указывается в настройках Flowcon. Для конкретного исполнителя можно переопределить, в расширении пользователя.
Главный смысл, который мы вкладывали в систему приоритетов – простота. И настройки, и использования. Систему приоритетов нужно настроить один раз, и надолго о ней забыть – она будет работать сама.
Если приоритеты по матрице Эйзенхауэра – статические, то по статусу буфера – динамические. Система не забудет, что время идет, и будет автоматически двигать задачи в очереди, чтобы не допустить просрочку.
Каждой задаче присваивается, и автоматически пересчитывается номер в очереди. Очередь привязана к текущему исполнителю, т.е. она у каждого своя.
Текущий номер в очереди и приоритет можно увидеть как в форме задачи:
Так и в списке задач к исполнению:
Список задач, разумеется, сортирован по номеру в очереди. Исполнитель должен просто брать их по порядку, и делать. А если не делает, то флакон об этом покажет.
Отчеты
Соблюдает исполнитель очередность, или нет, видно в отчете «График отклонений от очереди»:
Когда исполнитель закрывает задачу, как выполненную, система запоминает, на какой позиции в очереди она была. Ну и рисует на графике сумму отклонений за период. Отклонение – это разница между позицией в очереди на момент закрытия, и единицей.
Как видите, у нас в Окнософте с очередью большие проблемы. А когда перешли на флакон, и увидели, то схватились за голову и стали исправляться – график пошел вниз.
Второй отчет – «График эффективности». Это самый главный отчет, в котором будет видеy рост эффективности исполнителей. На графике выводится количество баллов выполненных задач, в привязке к периоду.
Например, вот что происходило с нашей эффективностью:
Отчетливо видно, когда мы ходили в отпуск – март и август, был провал в сумме баллов. Хотя, в целом, тренд положительный и очень впечатляющий.
Не менее важный отчет, необходимый, в первую очередь, координатору каждый день – это «Контроль исполнителей».
Этот отчет – все в одном окне. Не надо никого дергать, спрашивать, кто как работает, кто сколько сделал. Зашел, и посмотрел.
Что важно – исполнение задач поделено по периодам, чтобы избежать влияния «вспышек» — например, если исполнитель закрыл сегодня одну большую задачу, а с начала месяца ничего не делал. Тут видно сразу и месяц, и неделю, и сегодняшний день. А подсветка красным поможет понять, у кого динамика нормальная, а у кого – трудности. Отличный повод поговорить.
Количество отчетов будет расти, пока – только те, без которых нельзя обойтись.
Мгновенные оценки
Важнейшим направлением развития системы являются мгновенные оценки. Раз мы знаем, с какой скоростью работают исполнители, как они соблюдают очередь, как укладываются в сроки, то мы можем делать прогнозы. Например, сколько реально времени займет выполнение задачи.
Функциональность мгновенных оценок еще не закончена, пока есть только один параметр – текущая скорость, т.е. сколько баллов задач человек выполняет в день.
Видно ее в форме выбора исполнителя:
Ответственный, зная оценку задачи, может сразу прикидывать, кому ее лучше поручить, исходя из текущей скорости.
Комментарии
Какая система управления задачами без прений? У нас тоже есть – комментарии.
Комментарии иерархические, поэтому видно, кто кому и на что отвечает. Ведется учет прочтения комментариев, поэтому в списке задач жирным выделяются те, где есть что почитать:
Сотрудничество
Методика флакон говорит, что люди должны сотрудничать. Часто бывает так, что один человек помогает другому решить задачу. Нам важно, чтобы вклад каждого был учтен, поэтому в задаче можно уточнить список исполнителей, и определить для каждого коэффициент трудового участия (КТУ):
Баллы за задачу будут поделены между исполнителями, в пропорции КТУ. Так, вроде, честнее.
Кстати, пока писал статью, весь мой список задач для принятия решения покраснел:
Пока, вроде, все.
