qTrack – Дневник событий
Полный блог и обсуждение на dmitrofanov.livejournal.com | Наш твиттер twitter.com/qtrack_ru
SaaS — новое явление в сфере российских интернет-технологий. Но эта тема уже успела снискать интерес заинтересованного общества и даже обрасти различными мифами. Когда мы работаем на выставках и конференциях, нам часто приходится отвечать на возражения клиентов. Мы спокойно относимся к таким вопросам, и стараемся рассказать о технологии SaaS как можно больше и доступнее. Российский менталитет вообще так устроен, что русские люди неохотно принимают нововведения, болезненно отказываются от привычного, «проверенного». Неизвестность пугает: отсюда рождаются разнообразные домыслы вплоть до страшилок. А зря.
Мы молодая (на рынке SaaS) компания, но несмотря на отсутствие «бороды» сравнительно успешно разрабатываем и продаем SaaS-ы. И мы можем с уверенностью сказать, что проверили некоторые из мифов о SaaS «на прочность». И даже главное утверждение, что SaaS в России только начинается, — готовы опровергнуть. SaaS уже начался. Его создают, пропагандируют и даже продают.
Конечно, мы не популярные «MythBusters» с Discovery Channel: мы не будем жечь грузовики, напичканные тротилом, погружаться с аквалангом на несколько километров под воду и делать прочие сумасшедшие вещи... Но свою ложку дёгтя тем, кто эти мифы выдумывает и распространяет, мы добавим.
Итак: мы открываем серию заметок о мифах вокруг SaaS.
Надеемся, что они развеют сомнения потенциальных пользователей и помогут им определиться в выборе программного обеспечения. А ещё лучше получить комментарии от вас, читателей, для развития дискуссии, чтобы, развенчивая одни мифы, мы не пополнили коллекцию новыми.
Миф первый. SaaS — только для малого и среднего бизнеса
Компаний, занимающихся разработкой сервисных бизнес-приложений по модели SaaS, на российском it-рынке пока не так много. И если пробежаться по их сайтам и блогам, становится понятно, что все они позиционируют свои продукты как приложения именно для среднего и малого бизнеса. Мы часто говорим о том, что наши проекты — для малых рабочих групп. Но мы не имеем в виду малый и средний бизнес. К малым рабочим группам мы относим как частных пользователей, представителей среднего/малого бизнеса, так и работников отделов внутри крупных компаний.
Золотая жила для SaaS-ников — рынок средних предприятий. И то, что часто крупные организации предпочитают использовать решения, обеспечивающие гибкую адаптацию под их потребности, — это понятно. Но в том случае, если деятельность компании имеет свою специфику, и кастомизация SaaS-продукта под конкретные потребности просто необходима. А если нет? Чем тогда отличаются 6-10 человек, работающих у какого-нибудь ИП, от такой же команды работников, но одного из отделов, под крышей большого здания с внушительной вывеской?
Стоит заметить, что эта тенденция сохраняется только в России. Но, думается, связано это не столько с размером компании, сколько с тем, что большие организации более недоверчиво относятся к размещению своей информации на серверах SaaS-провайдера. Почему-то они полагают, что их базы более ценны, нежели у мелких контор... Западные компании используют SaaS-сервисы в своей работе чаще и охотнее. А всё потому, что делают ставку на автоматизацию привычных бизнес-процессов.
На самом деле, пользователем SaaS-продукта может стать любая компания, независимо от её размера. Крупные организации также заинтересованы в том, чтобы эффективно автоматизировать стандартные операции и передать на аутсорсинг работу, которая не является профильной и отнимает лишнее время и ресурсы. Поэтому утверждение, что SaaS-приложения не для «больших дядей», мы считаем не совсем верным.
Не все клиенты qTrack желают распространять о себе информацию. Но если вы заходили во вкладку "Отзывы" на нашем сайте, то могли видеть некоторых из них. Обратите внимание: они все разные — от частных пользователей и команд в составе трёх человек до групп компаний. Просто каждый использует систему так, как удобно именно ему.
Продолжение следует...
Читать далее...)
Каков бы ни был бизнес, большой или малый, - им нужно управлять. Ставить, решать и отслеживать задачи. Выбор специальных программ для управления проектами на сегодняшний день велик. Но определиться с тем, что подходит именно вам, - это подчас и есть самая сложная задача. Особенно если с ней сталкивается новичок. Как не запутаться в массе сложных функций и настроек? Как освоить программу быстро? Как использовать функционал сервиса на "всю катушку" и будет ли это гарантом эффективности работы? Мы, QSOFT, и сами, в период становления, когда на наши плечи впервые ложилась работа над большими сложными проектами, задавали себе эти вопросы.
И при создании qTrack все эти моменты учитывали. Поэтому до сих пор, чтобы работа в нашем сервисе была понятной и приятной как "стреляным воробьям", так и новичкам, мы стараемся сохранять его первозданную простоту. Да-да, несмотря на все последующие доработки =)
Правда, простота - понятие относительное. То, что кажется простым одному, приводит в ужас другого. С этим тоже приходится считаться.
Но недавно наткнулись на статью на habrahabr.ru, которая нас очень порадовала. Человек с нулевым опытом работы в подобных программах смог самостоятельно разобраться в qTrack. Это похвально ему, это - приятно нам!
А еще из последних событий: мы описали принцип работы сервиса, добавив картинки в закладке Возможности. Теперь знакомство с сервисом будет еще более приятным.
Успехов!
Команда qTrack
Читать далее...)
Поздравляем Вас с наступающим Новым Годом и Рождеством!
Желаем успешного развития всех Ваших начинаний в работе, творчестве и личной жизни.
Команда qTrack
Друзья!
Наконец-то мы дождались фото и видео-материалов с финала конкурса ROI Contest, прошедшего в октябре под эгидой Cisco-2010.
Мероприятие, которое затеяли Cisco-2010, включало выставку технологически интересных проектов и финал конкурса ROI Contest - "Результат от инноваций". Этот конкурс нацелен на поддержку отечественного инновационного бизнеса в целом и предпринимательских инициатив в технологической сфере – в частности. В течение двух месяцев, начиная с августа этого года, администрация конкурса принимала онлайн-заявки, а 29 октября были подведены итоги.
Как пишут на сайте организатора, всего было подано около 220 заявок со всей России, но к участию в финале были допущены только 5 лучших проектов, по мнению жюри. qTrack вошел в их число и взял почётное 3-е место в финале. Мы считаем, это неплохой результат: войти в 5-ку самых-самых из 220 проектов.
Итак, конкурс прошёл, о нём очень много писали, а вот фото и видео почему-то долго скрывали :)
По перепискам в твиттере было ясно, что те, кому небезразлично всё, что касается технологий и инноваций, долго ждали эти кадры. Сейчас «гриф секретности» снят, и те, кто не смог присутствовать, могут посмотреть фото тут, а видео — тут
Приятного просмотра!
Читать далее...)
Недавно получили приглашение от группы ЮНОВА Медиа поучаствовать в их новом проекте — программе Шоу-рум. По идее организаторов, программа предполагает личное общение участников: пары экспертов, пары человек из команды ЮНОВА Медиа и представителей проектов. Суть её в том, чтобы дать возможность стартапам рассказать о себе и своих проектах. Действие происходит за круглым столом и транслируется на портале Unova.ru. Участником видео-конференции может стать каждый, чтобы задавать вопросы стартаперам. В каждом выпуске — по два проекта и 30 минут на обсуждение каждого. Вместе с нами в программу вошёл также проект ePythia.
Признаемся, с одной стороны, очень приятно, что выбор организаторов пал на нас, но с другой стороны, - мы немного переживали по поводу того, что будем первыми в Шоу-руме. Но согласились.
Вчера, 11 ноября в 15:00, удачно стартовали в прямом эфире. И надо сказать - получилось всё здорово. Шоу-рум приятно удивил своим форматом: это не было однобоким интервью, как это часто бывает в программах, а были приглашены эксперты, которые сразу же смогли дать нам обратную связь. Нахождение «по ту сторону баррикад» и общение с экспертами прошло продуктивно для нас: мы получили профессиональный взгляд экспертов, полезные комментарии с их стороны плюс вопросы зрителей (мы внимательно к этому относимся: обычно по вопросам можно определить, где есть огрехи в презентации, какой момент мы недостаточно осветили, что более всего интересует пользователей и т.п.).
Запись трансляции сегодня стала доступна в открытом доступе на www.unova.ru/article/5592
:)
А в картинках это выглядело примерно так: 
Читать далее...)
Спешим поделиться приятным известием:
наш клиент, компания Notamedia, победил в конкурсе собственных сайтов веб-студий и интернет-агентств! :)
Премия со странным названием «Сапожник с сапогами» прошла 20 октября на конференции «Tagline: Управление интернет-агентством». Работы участников оценивало жюри, в состав которого вошли 29 самых ярких представителей интернет-бизнеса: это руководители веб-студий, интернет-агентств и специалисты в области интернет-маркетинга. Перед жюри стояла нелёгкая задача: из 100 компаний из России, Украины, Белоруссии и Узбекистана, принявших участие в конкурсе, выделить десятку самых достойных. Notamedia стал главным "сапожником" в номинации «Лучшие коммуникации», а также вошел в short-лист номинаций «Лучший дизайн», «Лучшее техническое решение», «Лучшая презентация услуг», «Лучший сайт интернет-агентства».
Наталья Соколова, исполнительный директор Notamedia: «Мы знаем, что заявки подали чуть более 100 компаний. Результаты можно посмотреть на сайте премии, но ничего такого, с чем бы я лично была не согласна, там нет. Что касается нашей победы: мы стараемся выстраивать коммуникации должным образом, и рады, что наши работы так высоко оценены».
Вот так лаконично и скромно. Герои — они такие :)
Что нужно сделать, чтобы преуспеть в нескольких номинациях сразу и «обуть» всех остальных? Нужно суметь эффективно выстроить работу на проектом. Notamedia сумели. И мы гордимся, что эта компания, которую теперь по праву можно назвать экспертом по выстраиванию эффективных коммуникаций, выбирает для работы наш сервис.
Самвел Аванесов, технический директор Notamedia, поделился своими впечатлениями о работе в нашей системе: «Мы используем qTrack каждый день при постановке задач, отслеживании хода выполнения и общей организации работ. QTrack позволяет существенно упростить работу, дать ясную промежуточную оценку выполнению задания в целом по качеству и срокам. Нам нравится, что qTrack прост в обучении и в настройках , допускает возможность отвечать по задачам непосредственно из почты. Чего нам не хватает: возможности добавить псевдонимы почтовых адресов и присоединений нескольких файлов сразу».
Ну что ж, замечания приняты :) Смеем заверить, что работа над qTrack не стоит на месте, и мы будем дорабатывать и совершенствовать систему. Мы всегда открыты для диалога со своими пользователями, и все аргументированные советы и пожелания всегда учитываем.
Мы снова поздравляем Notamedia с заслуженной победой и надеемся на дальнейшее плодотворное сотрудничество!
Читать далее...)
Недавно открылся новый проект из серии “q” – сервис www.qFlow.ru, предназначенный для быстрого создания web-форм и процессов (для входа можно использовать тот же e-mail и пароль, что и на qTrack/qCRM).
qFlow является простым и удобным интернет-сервисом, который поможет Вам, не обладая специальными навыками:
- Получить данные от любых пользователей в интернете, создав форму с любым набором полей и разместив ее на своем сайте для общего доступа или дав ссылку на систему только нужным пользователям,
- Обработать данные, строя выборки, редактируя, удаляя,
- Привлекать к каждому этапу обработки данных отдельных людей,
- Выгрузить данные из системы для резервного хранения или дальнейшей специфической обработки.
qFlow в первую очередь предназначен для малых рабочих групп. Как для создания формы и процесса, так и для ее размещения Вам не нужно нанимать программиста, устанавливать на сервер вашей компании, достаточно просто зарегистрироваться. Традиционно, базовые возможности предоставляются бесплатно (есть ограничения на количество пользователей, форм и объемы данных). Стоимость платных версий не высока – от 600 до 3000 рублей в месяц (в соответствии с моделью SaaS доступ осуществляется по подписке).
Процессы позволяют не только собрать данные, но и организовать дальнейшую работу над каждым результатом – выдать задание на выполнение, согласовать с руководством, уведомить ответственных сотрудников. Примечательно, что при желании, обычный пользователь может разобраться с системой и настроить процесс за 5-10 минут.
Например, можно организовать прием обращений от клиентов. Можно создать форму с типовыми вопросами и разместить ее на своем сайте (варианты разнообразны – от простого заказа «обратного звонка» и заявки на полиграфию до записи на прием в мед.учреждение или записи на семинар). Например, в случае записи на семинар, после получения заявки нужно:
1. Обработать запрос и решить что клиента следует пригласить или отказать ему
2. Позвонить, для подтверждения
3. В случае успешного подтверждения записать клиента на семинар
4. Выслать клиенту письмо с подтверждением регистрации
5. Отметить, что клиент пришел на семинар
6. Выслать материалы по результатам
Мы будем рады ответить на Ваши вопросы и рассказать о наших проектах.Читать далее...)
За последнее время мы добавили немного нового функционала. Самое существенное изменение в списке дел - теперь он стал иерархическим, появилась возможность создавать текстовые задачи, раскрашивать строки и т.д., но самое интересное - это возможность обсуждать задачи из списка дел. Также мы немного доработали тикеты - появилась возможность писать сообщения, не меняя ответственного за тикет и помечать тикеты как "отложенные". Далее обо всем подробнее.
Почти все возможности на одном скриншоте
Вверху представлены «неразобранные тикеты» — это новые тикеты или непрочитанные сообщения в уже имеющихся тикетах. Из неразобранного тикет можно перенести и поставить в нужное место в списке других дел. А можно просто удалить из этого списка (сам тикет удален не будет).
Ниже идет сам список – в нем могут быть как обычные текстовые задачи, так и Тикеты (т.е. задача, которую можно открыть и обсудить). Кстати, обсудить тикет можно с любым человеком, у которого есть e-mail, никого не нужно заранее регистрировать). Тикеты отличаются от обычных задач, их название — ссылка на тикет. Простые текстовые задачи видны только автору, а к тикету могут иметь доступ другие пользователи.
Думаю, нашим пользователям будет полезно быстрое редактирование свойств тикета прямо из списка дел (дабл-клик по строке)
Иерархия и драг-н-дроп:
— нажмите на задачу и тяните вправо (а можно влево), чтобы переместить задачу вниз (вверх) по иерархии (задача, стоящая выше, станет родителем)
— при перемещении задачи с потомками, будет перенесена вся ветка (все потомки)
— при перемещении задачи по списку, будет подсвечена та задача, которая станет родителем, если положить выбранную задачу в текущее место
— При отметке о выполнении задачи-родителя будет задан вопрос — как следует поступить с потомками
— Кружочки слева показывают уровень вложенности
Прочие возможности
— Свернуть / развернуть — если у задачи есть потомки, при наведении на нее появится минус (по клику вложенные задачи свернуться). Если у задачи есть свернутые потомки, то «+» (развернуть) будет виден всегда
— Цветовая идентификация — для задач и тикетов можно задавать различные цвета подсветки, на усмотрение пользователя
— Быстрое добавление задачи — находясь в режиме добавления задачи, после нажатия enter задача будет добавлена и будет открыто поле для ввода названия следующей задачи
— Дабл-клик на поле с задачей — переход к редактированию
— Быстрый ответ — тикет это обсуждение, но не всегда, чтобы ответить, сменить ответственного или изменить свойства (приоритет, тэги, дедлайн) нужно открывать тикет полностью (там могут быть десятки и даже сотни сообщений). Для этого есть быстрый ответ
— Добавление тикетов в to-do лист – любой тикет может быть добавлен в to-do лист (в блоке свойств тикета есть чек-бокс «эта задача в моем to-do»)
— Папки — текстовые задачи можно использовать в качестве папок, в которых могут быть тикеты, которые нужно сделать (для удобства названия папок можно набирать ЗАГЛАВНЫМИ буквами, выделять цветом)
Надеюсь, новые возможности окажутся полезными для наших пользователей.Читать далее...)
Многим менеджерам проектов известен закон Парето (в общем виде формулируется как «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата»), в нашем варианте «на последние 20% проекта требуется 80% ресурсов». Проще говоря, проект по настоящему начинают делать за 3 дня до открытия. В результате: аврал, врыв сроков, низкое качество, беготня, стресс и прочие "удовольствия" менеджера проектов.
Частая ошибка – дать разработчикам ТЗ и ждать пока они все сделают, а потом начать проверять. Это работает, когда проект очень маленький. Значит, надо из одного большого проекта сделать несколько маленьких. Путем проб и ошибок для себя мы нашли решение, которое условно назвали «недельные итерации» (хотя это не итерации в полном смысле, когда каждая итерация это мини-проект, включающий все фазы, от анализа до внедрения) — задачи объединяются в итерацию так, чтобы они могли быть выполнены за неделю. Теперь самое важное — итерация должна быть сделана полностью и проверена.
Теперь по-порядку:
1) Все работы разбиваются на отдельные задачи. Когда проект разбит на задачи, можно организовать правильное управление этими задачами
2) Задачи объединяются в пакеты, объемом примерно на неделю (в зависимости от числа разработчиков размер пакета может варьироваться)
3) Главная фишка: задачи сдаются заказчику по частям (пакетами), каждую неделю — это позволяет еще в начале проекта понять многое важные вещи:
— Правильность оценки трудоемкости задач
— Адекватность и ответственность заказчика
— Насколько качественный результат выдает команда
4) Важно доводить решение задач до конца, т.к. выполненной можно считать только принятую заказчиком задачу, т.е. не просто передать пакет задач заказчику на приемку, а добиться чтобы заказчик принял работу (и соответственно, исправить баги)
Конечно, такой процесс сложнее организовать и это создает нагрузку на менеджера, но на самом деле, нагрузка нормируется и распределяется более равномерно и на менеджера проекта и на всю команду. В реальной работе ситуация, когда пакет задач передан заказчику и команда ждет ответа, вызвала бы простои. Поэтому, «итерации» должны идти с наложением, т.е.
- 1-я неделя – выполняем 1-й пакет работ и готовим (внутренние тестирование) к передаче Заказчику
- 2-я неделя – передаем 1-й пакет заказчику и выполняем 2-й пакет работ. Важно, чтобы исправление ошибок по 1-й итерации шло с наибольшим приоритетом
- 3-я неделя – закрываем 1-й пакет, исправляем ошибки по 2-му пакету, делаем 3-й пакет
Если к 4-й неделе все еще остались недоделанные задачи по 1-й и 2-й итерации, то нужно сосредоточить усилия на них и не брать в работу 4-ю итерацию.
Бонусы, которые мы получаем от такого подхода:
- Четкое понимание текущего состояния проекта и отклонение от планов, понимание, «что осталось сделать для сдачи этапа работ» (и получения оплаты)
- Понимание «баланса сил» — сколько задач на стороне исполнителя, а сколько на стороне заказчика
- Значительное уменьшение эффекта 20/80
- Снижение рисков в отношениях с заказчиком (сдача работ начинается в самом начале)
- Уменьшение количества новых требований и споров на их счет: разобрался в задаче, сделал, сдал
- Снижение себестоимости — исправлять ошибки в только что написанном коде значительно дешевле, чем по прошествии 3-х месяцев
- Наш подход вовсе не претендует на абсолютную истину и вообще, может быть, что он подходит только нам. Но возможно, эта статья будет кому-нибудь полезна. Также буду рад ответить на вопросы и обсудить другие решения «проблемы 2000», т.е. проблемы 20/80 (Читать далее...)
Обычно, большое количество усилий на внедрение средств автоматизации останавливает и менеджеров и руководителей. Но даже после внедрения системы управления проектами существенная часть - переписка с клиентом и управление требованиями - остается в почте и использование трекера становится неполноценным, многие вопросы решаются в обход учетной системы, что явно не добавляет порядка.
С qTrack все проще - чтобы начать использовать qTrack не нужно проводить долгие согласования и масштабное внедрение системы. Электронная почта есть у всех - достаточно для начала одному менеджеру начать использовать qTrack вместо почты (а теперь qTrack умеет не только отправлять и принимать ответы на свои письма, но и получать почту с любых адресов). Причем можно работать сразу и с Заказчиком и с Коллегами - они могут даже не использовать интерфейс qTrack, работая с привычной почтой!
шаг 1.
Зарегистрироваться на qTrack со своим рабочим е-mail адресом
шаг 2.
При написании всех писем использовать qTrack. Уже на этом шаге вы почувствуете преимущества системного подхода к управлению требованиями и задачами. Дальнейшие шаги - для особо продвинутых пользователей
шаг 3.
Письма, приходящие на обычную почту пересылать в qTrack (на mail@qtrack.ru) и отвечать на них из qTrack. Для удобства можно настроить редирект
шаг 4.
Завести почтовый ящик на qTrack - можно давать его клиентам и партнерам, а можно настроить редирект со своей корп. почты на ящик в qTrack
шаг 5.
Ну и наконец, настроить правила для входящих писем - например, прикреплять письмо (точнее, созданный на письмо тикет) к проекту и назначать ответственного автоматически
Для получения наибольшего эффекта не забывайте простой принцип - если какая-то задача должна быть сделана для выполнения проекта, на нее должен быть создан тикет. т.е. выполнение всех тикетов = выполнение всего проекта.
При необходимости можно легко отказаться от использования qTrack - все данные останутся в Вашей почте. Читать далее...)
У нас появилась возможность создавать свои почтовые ящики и принимать на них почту!
т.е. теперь у нас полная интеграция с почтой, а именно:
- можно написать на mail@qtrack.ru - будет создан тикет
- можно завести свои ящики и принимать на них почту
- qTrack отправляет письмо ответственному с текстом задачи
- можно отвечать на письмо из qTrack - ответ будет прикреплен к тикету, а автор тикета получит уведомление
Более того, для собственных ящиков (вида мояпочта@мойаккаунт.qtrack.ru) можно задать правила - в зависимости от отправителя тикет будет прикреплен к нужному проекту и будет назначен ответственный.
Это значит, что клиенты (и сотрудники) могут создавать тикеты не заходя в интерфейс qTrack!
Подробнее на нашем сайте http://qtrack.ru/tour/email.php
Читать далее...)
Я всегда утверждал, что люди и их отношения первичны, а процессы и средства автоматизации вторичны.
Поэтому хочу рассказать о простых приемах, которые позволят скорее достичь результата в управлении проектом.
Очень важно заниматься не только (и не сколько) общим планированием, а операционным управлением. Мы пришли к такой схеме: Планерка 1 раз в неделю для общего планирование и распределения ресурсов, Митинг каждый день для выполнения недельного плана.
Планерка – 1 раз в неделю, в пятницу.
Цель планерки – понять общее состояние проекта, оценить результаты за неделю и составить план на следующую неделю. Решить конфликты конкурентных ресурсов и составить таски – задание на человека на неделю с приоритетами задач и примерным временем выполнения.
Митинги проводится 1 раз в день (при «форсаже» проекта – 2 раза в день) – их цель сделать так, чтобы недельный план был выполнен. На митинге нужно обсуждать что было сделано с последнего митинга и что будет сделано к следующему митингу, но задачи берутся не из всего проекта, а только из плана на неделю (насколько это возможно).
Если выполняется 80% недельного плана – это хороший результат. Если же по итогам недели выясняется, что из запланировано решено только 20% задач, а остальное время выполнялись вне плановые задачи, то вам нужно либо научиться планировать, либо не тратить время зря.
Естественно, при использовании подхода Базовых тикетов планерки и митинги станут значительно эффективнее. Напомню, что Базовые тикеты это когда на одну бизнес-функцию, типа "Корзина", "Каталог товаров" создается один тикет (одна ветка обсуждения и для заказчика и для исполнителя). Читать далее...)
Мы запустили 1-ю версию Рабочего стола. Пока он состоит из 3-х "виджетов": список дел (To-Do List), диаграмма распределения тикетов по статусам и список проектов.
Конечно, самое интересное это список дел - теперь можно отобрать нужные тикеты и расставить их в порядке выполнения (простым перетаскиванием мышью). Причем, по мере появления новых сообщений или тикетов, в которых Вы ответственны, они будут появляться в блоке "неразобранные тикеты". Откуда их можно перенести в To-Do или удалить из списка неразобранного (сам тикет при этом не удаляется).
Чтобы добавить тикет в список дел, достаточно установить соответствующую галочку в блоке свойств тикета (кстати, мы объединили свойства тикета в один блок) или отметить тикеты в общем списке (меню "все задачи") и выбрать "добавить в To-Do" в выпадающем меню.
Читать далее...)
Как и обещали, мы выпустили очередное обновление, которое коснулось в основном улучшения имеющегося функционала. Следующее обновление будет с новыми возможностями - Рабочий стол и персональный To-Do list (список дел).
Итак, полностью переделаны проекты и группы - теперь проекты из всех аккаунтов, в которых участвует пользователь выводятся на одной странице.
Появилась быстрая настройка прав доступа к проектам на странице аккаунта. При добавлении нового пользователя его можно подключить к проектам не заходя в настройки каждого проекта. Соответственно есть и автоматическое удаление пользователя из команд проектов.
Выбор ответственного из списка и возможность просмотра задач на команде проекта (после выбора проекта состав меню "Ответственный" меняется и показывает команды и пользователей этого проекта)
Теперь есть возможность создавать внутренние 1-е сообщение в тикете. Это особенно важно для выполнения задач, которые инициируются внутри команды и после выполнения работы (все обсуждения скрыты от других участников) переходят к другой команде (открытое обсуждение).
Еще у нас появились подсказки - рядом с важными элементами на странице есть пиктограмма вопроса с подсказкой.
Ну и напоследок фильтр по дедлайну и приоритету.
Теперь работа с qTrack стала еще удобнее.Читать далее...)
В основе возможностей qTrack лежит определенная концепция (методология) управления задачами и проектами.
Я уже писал про внутренние (скрытые) сообщения, которые позволяют не дублировать сущности и вести скрытые обсуждение между членами команд в том же тикете (задаче), где ведется обсуждение между командами - внешние (открытые) сообщения.
Другая важная составляющая концепции (которая также усиливает эффект скрытых сообщений) - принцип: 1 задача = 1 тикет.
Наверное не многие слышали про Структурную Декомпозицию Работ (WBS) - если говорить проще, то это просто иерархический список всех работ проекта.
Но при этом почти каждый хорошо знает про диаграмму Ганта. В теории управления проектами WBS и Гант примерно равнозначны. Но использование того или иного инструмента зависит от типа проекта. Например, в строительстве крайне важны сроки и четкая последовательность поставок, причем это реально критично (в отличии от IT-проектов) - если привезти бетон, которых будет некуда заливать он просто застынет, а если привести окна со стеклами на этапе котлована, то от них ничего не останется. Поэтому Гант (или сетевой график) действительно важный инструмент для проектов строительства.
Почему-то в IT-проектах тоже очень любят Ганта, хотя диаграмма редко бывает актуальной и еще реже работы соответствуют плану. Это вовсе не значит, что в IT-проектах не нужно планирование. Но зачастую ему уделют неоправданно много времени и сил, пытаясь внести на диаграмму Ганта все задачи. Это практически бесполезно. На Ганте достаточно отметить ключевые вехи проекта и ответственность сторон (Заказчик-Подрядчик), так, чтобы список задач занимал пол-листа A4.
Но проект состоит из десятков и сотен задач - что же делать с ними?
Как раз здесь приходит на помощь Структурная Декомпозиция Работ. Суть в том, что все работы разбиваются на максимально атомарные задачи (мы рекомендуем 4-12 часов специалиста), например, в случае с сайтом 1 задача = 1 функциональная страница.
Такой подход позволяет адекватно оценивать прогресс выполнения работ - не абстрактные 80% готово, а вполне конкретные - выполнено 40 задач из 50. Но еще больший эффект можно получить, если задачи разбить на итерации (например, объем работ на одну итерацию = 1 неделе работы) и сдавать Заказчику не весь проект сразу, а итерационно. Тогда состояние проекта будет уже не выполнено 40 задач из 50, а принято заказчиком (хотя скорее всего уже будет не 40,а сильно меньше.)
Думаю теперь становится ясно, что 1 тикет это 1 задача из WBS и зачем в одном тикете нужно работать и Исполнителю и Заказчику.
Итого, какие бонусы мы получаем от такого подхода:
- четкое понимание текущего состояния проекта и отклонение от планов, понимание, "что осталось сделать для сдачи этапа работ" (и получения оплаты)
- значительно уменьшение эффекта 20/80 (когда на последние 20% надо 80% ресурсов)
- снижение рисков в отношениях с заказчиком (сдача работ начинается в самом начале)
- актуальное состояние требований (по каждой задаче видно какой была изначальная постановка, что и почему изменилось в процессе выполнения задачи
- спрямление отношений Заказчик-Исполнитель без потери контроля
А "Базовыми" мы называем такие тикеты потому, что они создаются вначале проекта и их можно отличить от других, появившихся в процессе работы. Мы например, просто указываем это в названии тикета "БТ: Интернет-Магазин. Корзина" - это значит что в этом тикете обсуждаются все вопросы связанные с работой корзины нашего интернет-магазина.
Читать далее...)
У нас появились дедлайн и приоритеты у тикета,
Мы наконец сделали возможность смены проекта (у тикета),
Теперь можно посмотреть профиль пользователя прямо из тикета,
Мы дали всем права на закрыть тикет и еще появилось
свойство "моя команда" в настройках проекта - пользователям таких групп будет доступна информация о составе всех групп проекта (при выборе ответственного из списка в тикете)
В ближайших планах:
- немного упростить работу с проектами и группами
- система подсказок
- просмотр задач на команде (а не только на отдельном пользователе)
Затем будет персональный to-do list и Рабочий стол
Может ли проект с сорванным сроком и перерасходом бюджета считаться успешным? Может и вот почему.
Для начала договоримся, что под «проектом» мы будем понимать его каноническое определение - процесс создания уникального продукта. А не продукт (результат проекта), как часто думают.
Т.е. сам результат (программа или сайт или дом) это один из пунктов успешности проекта.
Когда мы говорим об успешности или провальности проекта, мы говорим не об удобстве, креативности, посещаемости(например, сайта), а о, успешности или провальности процесса создания продукта.
Основные критерии могут быть такими:
• Проект рентабелен
• Довольный заказчик
• Продукт интересен для портфолио
• Никто из разработчиков не умер, Команда разработки стала сильнее
• Заказчик совершает вторичную покупку
Общее определение успешности очень просто – большая часть стейкхолдеров (лиц, заинтересованных в создании проекта и принимающих решения) осталась довольной.
Например, у разработчика это могут быть:
- финансовый отдел - проект должен иметь рентабельность не менее 25%
- отдел качества - должна быть актуальная документация, код должен быть документирован и т.д.
- отдел продаж - клиент подписывает следующий договор
Что это значит на практике?
Понимание правильных критериев успешности очень важно для успешного ведения проекта и бизнеса в целом.
Простой пример, проект А выполнен более-менее в срок, результат (продукт) приемлемого качества, акты подписаны, деньги получены. Казалось бы, чего еще надо – проект успешен.
Проект Б – не уложился в срок в 2 раза, результат сомнительного качества, проект убыточен – очевидно (скажет неопытный pm) проект провален.
Но в жизни не все так просто, в проекта А заказчик ушел недовольным (например потому, что менеджер проекта был неадекватно формален и заказчик получил совсем не то, что ему было нужно), рассказал об этом партнерам и компания-разработчик потеряла целый сегмент клиентов.
В проекте Б, клиент остался доволен несмотря на все трудности (например, потому, что к нему относились по-человечески, и сделали то что ему нужно на самом деле, а не то что было в договорном ТЗ). И Клиент сделал 2-й заказ за стоимость в трое большую, чем был первый проект + привел еще пару клиентов! (это не выдуманные ситуации, а истории из нашей работы).
Читать далее...)
При работе над проектом почти неизбежны обострения в отношениях с заказчиком, особенно, когда наступает момент сдачи проекта или этапа. В это время особенно важно понимать "на чьей стороне мячик", т.е. какая из сторон отвечает за задачу в каждый момент времени и сколько задач на каждой из сторон. Также очень важно избежать потерянных вопросов и "зависших" задач.
Даже если Заказчик принимает не достаточно активное участие в процессе выполнения проекта, на момент сдачи-приемки работ Заказчику все же придется принять работу. Соответственно, возникнет список замечаний, затем, список ответов на замечания и так несколько раз (Будет гораздо удобнее, если каждая задача (бизнес-функция) будет сдаваться по-отдельности).
Для того, чтобы правильно понимать "баланс сил" на проекте, в qTrack есть простой, но эффективный инструмент - индикаторы:
- если у тикета (задачи) красный или желтый индикатор, то задача на Вашей команде
- если зеленый, то на команде Заказчика
Легко сделать выборку и понять, сколько и каких задач на стороне Заказчика и попросить его принять задачи или написать замечания. А со стороны разработки появляется цель - сделать все тикеты сначала зелеными, а затем серыми (т.е. закрытыми).
Конечно, появляется соблазн написать "отписки" и таким образом "озеленить" список тикетов. Но это не может работать, т.к. Заказчик будет возмущен и просто позвонит менеджеру или руководителю и выскажет, все что думает. Зато и менеджер и руководитель всегда смогут посмотреть историю - что и когда было передано и разобраться в ситуации.
Также будет полезно оценивать время, которое задача оставалась без внимание, причем как в случае сдачи Заказчику, так и в случае приемки замечаний от Заказчика.
Например, "мы уже как неделю назад передали вам задачу, а ответа нет - давайте форсируем приемку" или наоборот, руководитель проекта может отследить "зависшие" на разработчиках задачи, по которым требуется ответ.
Такой режим работы индикаторов доступен при использовании проектов.
www.qtack.ru www.qcrm.ru
Читать далее...)
На самом деле, qTrack здорово отличается от других трекеров, отличается принципиально. Это не столько система для внутреннего использования, сколько решение ДЛЯ ВСЕХ участников проекта. Кратко суть в следующем:
Если представить людей, работающих над каким-то проектом в виде социального графа, обнаружится, что есть "некие узлы" (компания исполнитель, компания заказчик, внешний подрядчик) и связи между ними. Любой проект есть не что иное, как набор требований, которые надо выполнить, а выполнить - это получить, уточнить, разработать, внедрить и т.д.
Фактически требования сначала «живут» внутри одного узла соц.графа, потом переходят в другой, поживут там и обратно и т.д. Собственно, в основе qTrack идея создать единое пространство для требований, которые могут обсуждаться сначала внутри Заказчика, потом переходить Исполнителю, после опять обсуждаться, но уже внутри Исполнителя (скрыто от Заказчика) и т.д.
То есть и Заказчик и Исполнитель работают с одним и тем же тикетом, только у них есть "общая часть" и "части, доступные только отдельным группам".
qtrack.ru qcrm.ruЧитать далее...)
Бывают системы автоматизации, которые автоматизируют имеющиеся в компании процессы, не внося в них существенных изменений. Такую систему кажется просто внедрить, но эффект от ее внедрения сложно измерим и не всегда понятно, а был ли смысл. И самое главное - а можно ли было сделать лучше? т.е. не только автоматизировать то, что есть, но и улучшить сами процессы?
Я уже писал, что qTrack создает "единое пространство для заказчика и исполнителя", но что это меняет в самом процессе создания проектов и как получить от этого прямую выгоду?
На прибыль проектной компании большое влияние оказывает себестоимость проектов, причем чем как правило, чем больше проектов в работе, тем выше себестоимость каждого отдельного проекта - из-за роста административных издержек и снижения контроля руководителей.
т.е. получается, что расходы начинают опережать доходы, что вынуждает повышать цену и терять клиентов - получается замкнутый круг: увеличивая число проектов растет доход (оборот), но падает рентабельность и в итоге прибыль остается на прежнем уровне или даже падает. Из-за управленческих и кадровых проблем падает качество и компания начинает терять клиентов.
Отсюда мораль: нужно повышать эффективность работы и рентабельность проектов.
Может ли в этом помочь система автоматизации управления проектами - безусловно да, вопрос только в том, на сколько. Если внедрять систему управления проектами не меняя имеющиеся процессы, вряд ли можно получить прирост эффективности более 5-10%, а при неудачном выборе системы возможно даже снижение эффективности - например, если люди будут тратить слишком много времени на заполнение ненужных форм и т.д.
Значит, надо не только внедрять систему управления проектами, но и менять бизнес процессы. Но как? Экспериментировать на собственной компании может быть слишком дорого.
Есть простое решение - взять систему автоматизации, которая подразумевает определенные бизнес-процессы разработки проекта. Например, в it-проектах есть концепция гибкого подхода (agile) и множество систем автоматизации, поддерживающих такой подход. Лично мне нравится agile и мы используем его принципы в своей работе (с определенной степенью модификации ес-но), но для заказной разработки с фиксированной стоимостью, сроком и ТЗ - agile не учитывает важную составляющую - отношения с заказчиком. А как показывает опыт, влияние заказчика на рентабельность очень велико.
Наша концепция - использовать гибкий подход в негибких условия контракта с формализованным корпоратавным заказчиком. т.е. обеспечить контролируемое и ограниченное вовлечение заказчика в процесс разработки проекта и получить от этого максимальную пользу.
Для этого с одной стороны нужно спрямить отношения конкретных людей из команды заказчика и людей из команды разработки, с другой стороны, нельзя пускать процесс на самотек и позволить заказчику управлять нашими специалистами.
Если переходить к системе автоматизации, то она должна одновременно пускать заказчика к решению и обсуждению задач, и при это ограничивать его возможности. Рассмотрим простой пример: в проекте по созданию сайта, нам бы хотелось, чтобы разработчик мог напрямую получить список багов от заказчика и даже сам бы мог задать уточняющие вопросы и отписаться о выполнении, но при этом мы хотим чтобы под видом ошибок не вносились новые требования, чтобы перед ответом заказчику было проведено тестирование (несколько циклов "менеджер-разработчик", да и вообще быть в курсе происходящего.
т.е. нужно чтобы команда разработчиков проекта и заказчик пользовались одной и той же системой управления. Более того, чтобы один вопрос (например, реализация одной бизнес-функции) решался в одном месте (задаче, тикете) и заказчиком и командой исполнителя. Но при этом у команды исполнителя должна быть возможность обсудить некоторые моменты так, чтобы заказчик не видел этого обсуждения.
Для этого и нужны внутренние (скрытые от других команд) сообщения в рамках тикета.
Этот несложный технический инструмент позволяет координально изменить и оптимизировать бизнес процессы выполнения проекта. Настолько, что эффект от внедрения такого подхода может сэкономить реальные деньги.
Дополнительные бонусы, получаемые от внедрения единого пространства задач с использованием внутренних обсуждений:
- возможность сдавать работы по частям (обеспечив итерационность разработки)
- возможность вести проект при временном отсутствии менеджера (отпуск, болезнь)
- возможность оперативно реагировать на срочные обращения от заказчика даже когда менеджер занят (например, другим проектом)
- возможность сменить менеджера и даже команду проекта (например, перевести их на более важный проект) без существенных проблем (все знания по проекту и история разработки и сдачи каждой задачи зафиксированы)
Таким образом, принимая решение о выборе системы управления проектами, можно задуматься не только об автоматизации имеющихся процессов, но и о переходе к качественно новому подходу к бизнес-процессам.
ссылки по теме: qtrack.ru qcrm.ru
Читать далее...)
Функционал может быть немного сыроват (не пугайтесь), но ключевые функции работают.
Пожалуйста, пишите нам об ошибках или пожеланиях к работе системы - все сообщения рассматриваются!
В двух словах суть нашего подхода к управлению проектами с помощью qTrack.
Весь проект состоит из отдельных задач. На каждую задачу создается один тикет в qTrack (принцип "1 задача = 1 тикет"). В тикете (тикет это задача в qTrack) есть постановка задачи и ее обсуждение всеми участниками процесса.
В каждом проекте настраиваются группы, например, "Команда Исполнителя" и "Команда Заказчика".
Задача (тикет) прикрепляется к проекту.
Если один из членов команды видит тикет, то этот тикет видит вся его команда.
члены команды могут обмениваться внутренними сообщениями, которые скрыты от других команд,
таким образом, получив задачу или вопрос от заказчика, менеджер проекта может прямо в этом тикете обсудить и решить задачу с разработками (скрыто) и по результату отписать заказчику о готовности (открыто).
После этого Заказчик напишет замечания (ошибки) и они сразу будут доступны разработчикам - не нужно дублировать информацию и отслеживать выполнение задач в двух системах (в почте - от клиента и в багтрекере с разработчиками)
Причем Заказчик тоже может вести скрытые обсуждения со своей командой в рамках того же тикета! (например, советоваться с сисадминами или начальством)
И таких команд в проекте может быть сколько угодно!
www.qtrack.ru
Читать далее...)
qTrack позиционируется в первую очередь как система управления задачами (а с выходом корп.
версии - как система управления проектами). Но у qTrack есть и другие стороны, например, для
управления требованиями. Рассмотрим фрилансера или группу из 2-3 человек. Потребность в системе
управления задачи и проектами у них небольшая, поскольку можно легко поддерживать порядок в
задачах даже на листочке бумаги (для самых продвинутых - эксель).
Но есть реальная проблема - в систематизации требований заказчика и отслеживания их изменений.
qTrack как раз делает акцент на обсуждении самой задачи (что по нашему опыту гораздо важнее,
чем систематизация задач - т.к. это отностительно просто)
Самое интересное, что для наведения порядка не требует никаких дополнительных усилий,
достаточно начать использовать qTrack вместо почты и придерживаться простого принципа: 1 задача
= 1 тикет.
При этом Заказчику не обязательно использовать интерфейс qTrack - он может просто отвечать на
письма (а письма от заказчика легко превратить в тикет, сделав форвард его письма на
mail@qtrack.ru)
Таким образом, в любой время можно получить историю обсуждения конкретной задачи, понимать, где
новые требования (за которые надо бы доплатить) и какие задачи приняты, а какие нет.
Наличие индикатора, показывающего на чьей стороне задача поможет избежать потерянных вопросов и
ситуаций, когда Заказчику задан уточняющий вопрос, исполнитель ждет на него ответа, а Заказчик
думает, что задача делается.
Естественно, что потребность в управлении требованиями есть не только у фрилансеров - в данном
случае это просто пример. Управлять требованиями нужно при решении любых мало-мальски
нетривиальных задач: между компаниями, отделами одной компании и даже внутри одной команды.
Потому что если есть задача, есть ее постановщик и исполнитель, а в современных условиях,
маловероятна ситуация, когда задача может быть исчерпывающе поставлена и правильно реализована
без каких-либо уточнений.
Читать далее...)
Одной из очень полезных "фишек" qTrack является возможность вести скрытые (внутренние) обсуждения.
Но в них нет необходимости, когда Заказчик существует отдельно от процессов выполнения задачи или проекта.
Создание единой среды коммуникации команд Заказчика и Исполнителя дает увеличение эффективности
выполнения проекта до нескольких раз, конкретно:
- получив задачу или вопрос от Заказчика менеджеру не надо дублировать тикет в другой учетной системе
- при обсуждении вопросов, требующих участия специалистов, можно организовать прямое общение "Заказчик - Специалист", при этом не теряя контроля над ситуацией
- легко отслеживать статус "принято / не принято" и не нужно синхронизировать 2 списка задач: "Заказчик - Менеджер" и "Менеджер - Команда"
- руководитель в любой момент может посмотреть ситуацию на проекте: сколько задач на стороне Исполнителя, сколько на стороне Заказчика (выполненных или требующих уточнения), сколько принятых задач и принять соответствующие решения
- в случае конфликтов с Заказчиком и вообще всякого рода "разбора полетов" легко посмотреть обсуждение по конкретной теме и узнать, что, кем и когда было сделано и написано.
Самая очевидная проблема - далеко не все, что обсуждается в команде, надо знать Заказчику.
Для этого и существуют скрытые сообщения! Процесс выглядит так:
- Заказчик ставит задачу (или её ставит менеджер, открыто для заказчика)
- Команда решает задача ведя переписку в скрытых сообщениях
- Когда задача решена, пишется открытое для Заказчика сообщение
Но чтобы это работало, нужно придерживаться принципа: 1 задача = 1 тикет.
Да, и Заказчик может не использовать интерфейс qTrack, а просто отвечать на письма.
Более того (при использовании интерфейса qTrack) Заказчик также может обсудить вопросы по задаче скрыто от Исполнителя. (Читать далее...)
Как и обещали, мы внедрили единые авторизацию и профиль на наши проекты!
Теперь, пользователь, зарегистрированный на qTrack.ru сможет авторизоваться на qCRM.ru с тем же логином (e-mail) и паролем (и наоборот - с qCRM на qTrack).
Также, профиль пользователя стал единым, т.е. достаточно заполнить профиль только на одном проекте. При изменении данных (например, номера телефона или фотографии), новые данные окажутся на остальных проектах (наши новые проекты, естественно будут иметь единую авторизацию). (Читать далее...)
Немного информации о наших планах
Мы ведем работы над следующей версий проекта. Скоро у нас будет "Корпоративная" редакция с полноценной поддержкой проектов и групп пользователей.
Также, у нас есть и другие проекты (например, www.qCRM.ru), которые будут объеденены единым профилем, т.е. зарегистрировавшись на одном проекте (любом) с тем же аккаунтом (а у нас это e-mail) можно будет работать на всех проектах.
Вот :-) (Читать далее...)
