TrackStudio - це не тільки управління завданнями.
У той же час Atlassian JIRA не дозволяє управляти документами і файлами, для цих цілей потрібно використовувати Confluence. TrackStudio пропонує інтегроване рішення, що дозволяє спростити інсталяцію та позбавляє від необхідності синхронізувати системи.
Оскільки JIRA не призначена для управління документами і файлами, то подальше порівняння відноситься тільки до використання Atlassian JIRA і TrackStudio Enterprise з точки зору управління завданнями.
"Великі" і "маленькі" системи управління завданнями.
Розвиток систем управління завданнями останні 10-20 років відбувалося в двох протилежних напрямках. З одного боку, "маленькі" open source системи постійно ускладнювалися і поліпшувалися. Успіх open source систем породив комерційні продукти, які були засновані на тій же архітектурі, але мали набагато більш розвинену функціональність. Одночасно в таборі "великих" систем зміни йшли в протилежному напрямку - спочатку складні і дорогі системи зберігали свої архітектурні особливості, але ставали простіше і дешевше.
Перетину функціональності "маленьких" і "великих" систем до сих пір не відбулося. Продукти (в тому числі комерційні) на базі open source систем так і не змогли реалізувати базовий функції "великих" систем, а "великі" системи стали схожі на "маленькі" лише з точки зору користувача, але не адміністратора.
Розглянемо особливості "великих" і "маленьких" систем на конкретному прикладі. Як приклад "маленької" системи візьмемо Atlassian JIRA. Чому саме JIRA. Справа в тому, що JIRA створювалася як заміна Bugzilla, повторює архітектурні особливості open source систем (Bugzilla, Mantis, Trac, Redmine), але значно перевершує інші "маленькі" системи. Якщо якась функціональність потрібна користувачам JIRA і не реалізована там, то швидше за все на це є серйозні архітектурні причини, в інших "маленьких" системах цієї функціональності теж не буде. Як приклад "великий" візьмемо TrackStudio, адже нашою метою було зробити легку, недорогу і зручну заміну типовою "великий" системи - IBM Rational ClearQuest.
Спочатку "великі" і "маленькі" системи створювалися в різних умовах і для різних завдань. Великі системи призначалися для управління завданнями в комерційних організаціях. Для цих умов характерні велика кількість проектів, завдань, безліч різних процесів, обмеження доступу до інформації. Фактично, "великі" системи були орієнтовані на обробку завдань всередині організації і не були призначені для спілкування з зовнішніми користувачами.
З іншого боку, open source системи створювалися саме для спілкування з користувачами в open source проектах. В таких проектах величезна кількість зовнішніх користувачів поєднується з простотою внутрішніх процесів. Команда розробників, як правило, плоска і однорідна, всі завдання відкриті всім, внутрішні процеси прості, а один екземпляр трекера часто використовується лише для одного проекту. Архітектура "маленьких" систем спочатку створювалася для роботи в саме таких умовах, але для комерційних організацій такі умови не характерні, при використанні навіть дуже потужних "маленьких" систем там виникає ряд типових складних проблем.
У цьому списку можна виділити наступні групи однотипних проблем:
Чому ж при всіх недоліках "маленькі" системи настільки популярні зараз? Причин кілька:
- Перераховані вище проблеми "маленьких" систем не видно при формальному порівнянні систем і не проявляються при тестуванні системи на 1-2 проектах. Проблеми стають очевидними при збільшенні кількості проектів, або коли виникає необхідність змінити конфігурацію одного проекту, не чіпаючи інші проекти. Зазвичай до цього часу система управління завданнями вже настільки тісно інтегрована з іншими системами в компанії, що можливий "переїзд" стає занадто дорогим.
- Через високу ціну "великі" системи раніше використовувалися лише в крупних компаніях, а значить досвід їх адміністрування є лише у невеликої кількості користувачів (хоча піратство зробило цю проблему менш актуальною для Росії). У більшості користувачів є досвід роботи з "маленькими" системами, але архітектура "великих" систем відрізняється, інтуїція підказує невірні рішення, а система справляє враження »не інтуїтивної". Примітно, що проблема не вирішується спрощенням інтерфейсу: в цьому випадку виникає навіть більше схожих ситуацій і інтуїція частіше підказує невірні рішення. Приховати за інтерфейсом іншу архітектуру системи можна від користувача, але не від адміністратора.
- Маленьку систему можна запустити на LAMP-хостингу, великі системи написані зазвичай на Java / C ++ і вимагають виділеного або віртуального сервера. Для багатьох open source проектів цей критерій є вирішальним.
Вартість і умови поставки
Цінова політика розробників TrackStudio і JIRA відрізняється, для деяких варіантів використання різниця у вартості буде мінімальна, для інших може відрізнятися в десятки разів. Хоча Atlassian JIRA значно дешевше TrackStudio для команд в 6-10 користувачів, для компаній з великою кількістю серверів, користувачів цінову перевагу TrackStudio може бути до 40 разів і навіть більше. Така різниця викликана наступними особливостями ліцензування продуктів:
- Вартість Atlassian JIRA швидко зростає при збільшенні кількості користувачів, в той час як для TrackStudio необмежена ліцензія доступна вже за 45 950 рублів. Це дає велику цінову перевагу TrackStudio для великих компаній і для компаній з великою кількістю зовнішніх клієнтів.
- На кожен сервер Atlassian JIRA потрібно купувати окрему ліцензію, в той час як для TrackStudio доступна ліцензія на необмежену кількість серверів та користувачів за 114 950 рублів. Це дає велику цінову перевагу TrackStudio при використанні декількох серверів.
- Підтримку і поновлення для Atlassian JIRA необхідно купувати для кожного сервера, в той час як для TrackStudio доступна ліцензія Global, де продовження ліцензії не залежить від кількості користувачів і серверів. Це дає велику цінову перевагу TrackStudio при використанні трекера протягом декількох років.
Переваги TrackStudio особливо помітні в наступних ситуаціях: