Форум сервиса Планфикс

Здравствуйте.

Мы небольшая проектная команда (~8 человек), занимающаяся разработкой и внедрением IT продуктов. В основном, штат состоит из Разработчиков, Аналитиков различного уровня, Тестировщиков и Менеджеров (РП). С недавнего времени был начат большой проект в связи с чем резко увеличилось число сотрудников, задач, образовалось довольно сложная орг структура с вытянутой вертикальной иерархией. Более того, часть сотрудников перешла на режим удаленной работы. Все вышеперечисленное полностью упразднило привычные для коллектива (а особенно для руководства) формы коммуникаций: совещания, обсуждения задач на обедах. Под натиском количества новых задач на скорую руку было  решено использовать excel для фиксации работ (выпадающие списки со статусами, исполнителями и т.д). Уже через пару дней процесс вышел из под контроля: кто-то из сотрудников создал свои версии экселя и работал в них, кто-то выдумал свои статусы, кто-то забыл менять статусы... Настоящий excel hell. В тот момент тимлидом было принято решение, что так не пойдет и после поисков возможных вариантов решений мы остановились на planfix. 

На данный момент около 3-4 недель наша команда в лице двух человек активно пытается настроить его "под себя". Решительности у нас много, вплоть до изменения собственных бизнес-процессов. Но вот что-то все никак не получается создать четкую и прозрачную систему по управлению задачами. Сотрудники продолжают жаловаться, что им неудобно (у многих опыт работы в redmine и  они противопоставляют его простоту перегруженности планфикса). Я могу очень долго расписывать сложившуюся ситуацию, но думаю будет продуктивнее, если я опишу цели, которые мы ставим перед внедрением planfix и несколько стандартных кейсов, которые никак не получается нам решить.

От внедрения нужно следующее:

• возможность полного отказа от сторонних общалок и файлообменников (почта, скайп, дропбоксы и т.д.)
• возможность сотруднику на каждом уровне иерархии в любой момент получить список своих дел (ToDo) и список задач, обновления по которым могут быть ему интересны (FYI)
• возможность сотруднику на каждом уровне иерархии видеть задачи своих подчиненных, статус их выполнения и сообщения о возникших основные проблемы
• возможность реализация продолжительных задач с участием 8-10 исполнителей в разных ролях (консультации, разработка, тестирования, согласование  и т.д.)
• в случае пропажи одного из сотрудников (ну вот не стало его резко. и нет, мы не мафия) без проблем продолжать его задачи
• накапливать базу знаний по проекту, предметной области
• довести бизнес-процессы до такого уровня, чтобы сотрудник, вооруженный лишь планфиксом и системой (рабочей) будучи в абсолютно изолированной комнате, абсолютно один и без телефона мог без потери производительности достигать установленной цели

(это не полный перечень, но ведь и пишу я не ТЗ)

Неразрешимые проблемы возникли у нас, когда мы пытались решить следующие кейсы:

1. Задача - Баг
У нас часто случаются задачи, в рамках которой аналитику надо выявить причины обнаруженной системной ошибки, сформулировать постановку разработчику, разработчику закодить, тестировщику протестировать. На любом этапе задача может быть переброшена на архитектора или руководителя направления с целью консультации. Причем, процесс может повторяться несколько раз, и разработчики и аналитики могут меняться. Пытались сделать жизненный цикл общего вида Новая-В очереди-В работе- Выполнена чтобы исполнители перекидывали ее между друг другом. Задумка была в том, что после того, как например, разработчик закончил кодирование, он ставил в исполнителя Тестировщика и переводил задачу в статус Новая. Тестировщик видел новую задачу и при нажатии на Принять она бы попадала в очередь его работ (статус Очередь). Или сразу, или после выполнения других задач, тестировщик принимает задачу уже В работу и выполняет. И т.д. Возникли следующие проблемы:

•  нельзя просто заменить исполнителя. Если ты удаляешь себя из исполнителей, как разработчик в примере, он теряет доступ к задаче. Т.е. ему надо добавлять себя еще в участники. А еще менять статус. Слишком много действий. А если он забывает добавить себя в участники то доступ будет окончательно потерян (у нас так было несколько раз)
• Исполнитель, который перевел с себя задачу, по факту перестает быть в курсе дел. Но ведь задача может вернуться. И ему необходимо иногда просматривать прогресс по ней, следить за новостями, но тем же временем отделять ее от тех задач где он участник, но никогда не был исполнителем (т.е. задачи FYI )
• Нельзя сказать сколько задач в момент t находятся в очереди разработки, сколько ждут согласования и т.д. Пробовали добавить доп поле Тип работ = Разработка, Тестирование и т.д. И тогда «сорт» задачи определяется двумя полями: статус, тип. Но это лишнее поля и еще тяжелее работать пользователям. Делать В очереди разработки – разработка, в очереди тестирования – тестирования, то же не вариант.

 2. Задача – обучение
Для сотрудника есть задача, в рамках которой он проходит самостоятельное обучение по специальной литературе и выполняет практические уроки в системе. Периодически у него возникают сложности и он должен советоваться со своим наставником (не всегда является постановщиком). Но после задания вопроса, он вполне может продолжать обучение, пропустив место, в котором возникла сложность. У нас это реализовано как Новая – В работе – Требуется Консультация – Выполненная. Есть отдельно поле в задаче «Консультант». Соответственно все консультанты должны иметь фильтр по «статус = Требуется консультация, консультант = я». Имеются следующие проблемы:·

• Не уверен, что использование лишнего поля целесообразно. Очень тяжело работать пользователям когда есть Исполнитель, Участник, Консультант, Аудитор, Постановщик.
• После того как он переводит задачу в Требуется консультация, он может продолжать работу. Но получается этот момент никак не отражается в системе? Так же как случай, если возникнет сразу второй вопрос.
• (это не далеко не все кейсы. Остальное потом)

И есть ряд вопросов:

1. Как я могу задать для всех пользователей одинаковый список фильтров слева?
2. Как находясь на задаче я сразу могу увидеть все ее подзадачи?
3. Как я могу получить список задач, в которым отписывался за последнюю неделю?
4. Очень часто встречаю ссылки вида ...planfix.ru/?action=planfix&task=619528. Как номер 619528 связан с номером задачи? И как по ссылке получить номер задачи?

 Спасибо за предоставляемый сервис! Надеюсь у нас с успехом получиться внедрить planfix с Вашей помощью ;)

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

Чтобы ускорить процесс, задам пару вопросов, которые возникли в процессе чтения:

Нельзя сказать сколько задач в момент t находятся в очереди разработки, сколько ждут согласования и т.д. Пробовали добавить доп поле Тип работ = Разработка, Тестирование и т.д. И тогда «сорт» задачи определяется двумя полями: статус, тип. Но это лишнее поля и еще тяжелее работать пользователям. Делать В очереди разработки – разработка, в очереди тестирования – тестирования, то же не вариант.

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

Не уверен, что использование лишнего поля целесообразно. Очень тяжело работать пользователям когда есть Исполнитель, Участник, Консультант, Аудитор, Постановщик.

Тут разверните чуть подробнее, пожалуйста - в чем именно сложность работы?