вторник, 22 июня 2010 г.

Juick vs Twitter || TrackStudio vs Jira

Обнаружил интересные параллели между Twitter/Jira и Juick/TrackStudio.
Первая пара - жутко популярные приложения, известные во всем мире. Вторая, прямо скажем, не преодолела пропасти (см. книгу "Преодоление пропасти: маркетинг и продажа хайтек-товаров массовому потребителю").
Первая пара создавалась достаточно известными в своей отрасли людьми, представителями "западного мира". Вторая - никому не известными парнями из Запорожья и Смоленска.
Первую пару отличает удобство и простота, но и достаточно ограниченная функциональность. Вторая пара - монстры возможностей, однако рассчитаны больше на гиков, чем на клерков.

Но ключевая штука, конечно, это преодоление пропасти. Мы уже закрепили канаты.

28 комментариев:

  1. А вы всерьез свой продукт позиционируете как альтернативу JIRA?

    ОтветитьУдалить
  2. Это не совсем альтернатива. Несколько разные сегменты. Мы больше ориентируемся на разделение процессов сбора информации об ошибках и их исправления, причем большее внимание уделяем именно внутренним процессам, сложным workflow. Jira больше ориентирована на open-source методы, когда система по большей части используется для сбора информации.

    ОтветитьУдалить
  3. JIRA больше подходит для общения с клиентами, TrackStudio - для всяких сложных внутренних процессов.
    Но если клиенты продвинутые, а внутренние процессы не очень сложные - то да, мы пересекаемся.

    ОтветитьУдалить
  4. А можно привести вопиющий (но живой) пример описания workflow в TrackStudio, которое нереализуемо в JIRA?

    ОтветитьУдалить
  5. Хорошие примеры, однако, не увидел какое они отношение имеют к workflow :)
    1) Управление требованиями в смысле управления жизненным циклом разделов требований наиболее близкий пример, реализуемый в JIRA, например, иерархию можно заменить связями разделов между собой. Настроить workflow по согласованию и утверждению - элементарная задача для JIRA.
    Единственный минус JIRA в том, что а) нет иерархии в нативном представлении как дерева разделов, б) наверно нет генерации ТЗ.
    2) и 3) Не увидел тут workflow, скорее это относится к уровню детализации разграничения прав доступа.
    Задача может решаться ведением двух проектов, в одном секретные данные, в другом разработка. Перемещение и дублирование issue между проектами в JIRA есть.
    Опять, же, насколько это критичные функции, что своеобразная реализация их в JIRA оттолкнет от ее использования?

    ОтветитьУдалить
  6. Фраза "управление требованиями" мне собственно ни о чем не говорит, потому что интересно именно какой смысл в нее вкладывается.
    Ну, например, есть ли в TrSt функциональность по трассировке разделов требований друг на друга, на другие артефакты проекта (тестовая и пользовательская документация), построение матриц трассируемости?
    Часто, именно наличие матриц трассируемости позволяет говорить об управляемости процесса создания требований, а не только согласование и утверждение.

    ОтветитьУдалить
  7. "Главная разница между ними с точки зрения фич: в issue tracking главное workflow (т.е. движение задач по состояниям), а в project management - gantt chart (т.е. планирование)"
    Странно, вы считаете, что в project management не нужно согласовывать и утверждать планы, вехи? Разве у обычных задач нет состояния (назначена, открыта, выполнена)?
    Если ответы утвердительные, то я не понял исходный посыл.
    "Скорее наш конкуренты по функциональности - это разного рода workflow management system, например Serena TeamTrack"
    Опять, не очень понимаю, как Вы понимаете workflow management system. В классическом смысле, это системы по управлению жизненным циклом некоторого элемента процесса.
    Данное поведение характерно для любой системы, автоматизирующей некоторые бизнес-процессы, а project management и issue tracking являются такими системами без сомнения.
    Более того, issue tracking обычно подразумевает именно трекинг, то есть отслеживание хода работ (или состояния) по issue, тикетам и . А трекинг как раз реализуется через Workflow.
    Тот же самый TeamTrack один в один тоже самое что и JIRA, вот нет практически никаких различий.

    ОтветитьУдалить
  8. А кто говорил "оттолкнет"? Никто тут вроде и не утверждает, что Jira - плохая система. Хорошая же. И интерфейс операций с задачами в версии 4.1 мне очень нравится.
    Если бы в Jira все было бы плохо - ее никто не стал бы использовать.

    ОтветитьУдалить
  9. Ну я не про крайности конечно, а скорее про то, зачем тогда использовать TrSt, если JIRA удовлетворяет 99% вариантов использования?

    ОтветитьУдалить
  10. Соглашусь, что права, оповещения, обязательность полей - это дополняющие элементы к автоматизации процесса. То есть в TrSt как раз на это сделан упор? На всеобъемлющее описание хода процесса?

    ОтветитьУдалить
  11. Думаю, разница между issue tracking и project management в фокусе.
    В ms project, например, нет состояний задачи и понятия workflow. Согласовывать/утверждать - да, надо, но это не суть планирования. Поиска кратчайшего пути, составления сетевого графика, возможностей поиграться на тему "а что будет со стоимостью если добавить ресурсов или сократить время" - это обычная функциональность для project management, но этого не найдешь в issue tracking.
    А в issue tracking обычно нет gantt chart. Более того, я не очень понимаю как можно построить gantt chart на основе информации из issue tracker-а, там же должны быть не задания для программистов, а цели. 100% rule тоже не обеспечишь, т.к. никогда нет гарантии найденные баги - это все существующие баги в проекте.
    По поводу TeamTrack - там есть много всяких интересных возможностей, полезных для автоматизации процессов. Меня там особенно впечатлила возможность наследовать процессы - может быть очень полезно, когда нужно реализовать несколько сложных и похожих процессов.
    Т.е. issue tracking и project management описывают одно и то же, но с разных сторон и в разном масштабе. Как пользовательская документация к программе и код. Интегрировать это в одном продукте - можно, но это все равно что пытаться сделать из Word-а IDE. В общем я пока хороших реализаций интегрированного bug tracking + project management не видел (хотя и не особенно искал).

    ОтветитьУдалить
  12. Матрицы и генерации ТЗ из коробки у нас тоже нет. Но ТЗ - это просто XSLT-преобразование для XML-отчета со списком требований, матрицу тоже можно сделать скриптом. То и другое доделать проще/дешевле, чем реализовать иерархию в JIRA или купить готовую систему для управления требованиями. Точно знаю, что у нас есть клиенты, которые выбрали для управления требованиями TS именно из этих соображений.
    У нас нет практически никакой специальной обработки, которая нужна для каких-то специальных областей применения, все это предполагается делать либо скриптами внутри TS, либо через SOAP API во внешних программах.

    ОтветитьУдалить
  13. Да, на описание сложных и/или часто меняющихся процессов. Клиенты, которые используют TS для обработки договоров, согласования дебиторской задолженности, слияния компаний и т.п. очень много. Специализированного софта обычно для этих целей нет, а классические issue trackers довольно сильно привязаны к разработке ПО.

    ОтветитьУдалить
  14. В мелких компаниях может и 99%, а в крупных - точно меньше :-) У JIRA "провал" как раз по функциям, которые важны при большом количестве пользователей.
    Кроме того, JIRA халявна для мелких компаний и open source организаций, а вот для крупных она значительно дороже TrackStudio. Например, считаем стоимость 2-х серверов системы, с исходниками и 3-мя годами поддержки для JIRA и TrackStudio.
    2 unlimited экземпляра JIRA будут стоить 728 тысяч (цена softkey), + 2 года поддержки - еще 728 тысяч, итого 1456 тыс. руб.
    Аналогично для TrackStudio это будет стоит 74 тысячи за лицензии и 17 тысяч за саппорт, итого 91 тыс. руб.
    Разница в 16 раз, есть о чем задуматься :-)
    Кроме того, в Atlassian считают лицензии по active users:
    "Licensing fees are quoted per number of 'active users'. An active user in JIRA is by definition any user account in the system with the "JIRA Users" global permission, i.e. anyone who can log in. Unlimited 'anonymous users' are permitted on all licenses. "
    Т.е. шароварщик в единственном лице с сотней клиентов тоже должен покупать unlimited лицензию :-)

    ОтветитьУдалить
  15. Вот это правильный вопрос. Пост, в общем-то, был именно об этом.
    Зачем использовать Ubuntu или MacOS, если Windows удовлетворяет на 99%? Зачем использовать Juick, если есть Twitter? Зачем использовать Jabber, если есть ICQ?
    Вот есть Facebook. Мировой лидер в области социальных сетей. Много там русских? Значительно меньше, чем во Вконтакте или Одноклассниках. Почему так? Русским что-то не нравится в Facebook?
    С TrackStudio та же история. В России у нас точно есть ниша. Atlassian не будет возиться с местной бухгалтерией, оформлять договора и т.п. Местные реселлеры, возможно, будут, но наценка у них немаленькая, и потом - это ведь реселлеры.
    Впрочем, наше обсуждение несколько неверно изначально. Конкурировать фичами - это неправильно. Именно потому, что фичи на очень много процентов пересекаются во всех аналогичных системах.

    ОтветитьУдалить
  16. А какие-то бесплатные варианты использования TrSt имеются?

    ОтветитьУдалить
  17. "У нас нет практически никакой специальной обработки, которая нужна для каких-то специальных областей применения, все это предполагается делать либо скриптами внутри TS, либо через SOAP API во внешних программах."
    А что за скрипт? Что оно может?
    Вообще, расширение функциональности силами пользователей это конечно здорово :) но, имхо, скользкий путь

    ОтветитьУдалить
  18. Да, я в целом соглашусь.
    Занимаясь разработкой ПО с такой проблемой, как great gap между issue tracking и project management, сталкивался постоянно.
    Кстати, если вы этого еще не сделали сами, то мне время открыть карты. Именно этот gap мы хотим закрыть в своем продукте: DEVPROM
    На наш взгляд и по отзывам, в целом это получается.
    Мы конечно в лоб не строим Gantt, это глупость, хотя есть выгрузка в MSProject, но эффект планирования достигается за счет реализации Agile-практик.
    "В общем я пока хороших реализаций интегрированного bug tracking + project management не видел (хотя и не особенно искал)."
    Если еще не видели нашей разработки, то будем признательны за вдумчивый анализ, мысли, идеи, ощущения.

    ОтветитьУдалить
  19. Список клиентов у нас на сайте висит. По поводу "в 16 раз дешевле". Это скорее Jira в 16 раз дороже. Мы начинали в одно время с ними и цены у нас были одинаковые. Потом они цены задрали, а мы - почти нет.

    ОтветитьУдалить
  20. Про специализированность - это точно. Специализированные продукты есть и с ними конкурировать трудно. (да и бессмысленно). Не согласен с тем, что мы не конкурируем с Jira. Конкурируем, и это не мы придумали. Это клиенты придумали. Они и сравнить просили, и про возможность переноса данных из Jira в TrackStudio. Чаще всего паттерн такой: конторе нужен багтрекер (issue tracker, хотя это чисто маркетинговая заморочка жирашников) - они ищут в интернетах. Сначала смотрят, что есть из бесплатного. Части хватает багзиллы или мантисса. Другие бегут к унитазу, потом умываются и продолжают поиск, третьи изначально не ищут бесплатные продукты, потому что либо служба безопасности запрещает ими пользоваться, либо бухгалтерия (бывает такое). Ищут среди платных, неизбежно находят Jira. Читают, скачивают, ставят (ха-ха, а пробную лицензию еще нужно умудриться получить, она по запросу отдается). Смотрят, пробуют, что-то нравится, что-то не нравится. После Jira ужа находят нас. А дальше выбирают между тем и тем.
    Я крайне редко видел, когда выбирали между Jira и какой-то другой коммерческой системой. В России.

    ОтветитьУдалить
  21. "Чаще всего паттерн такой: конторе нужен багтрекер (issue tracker, хотя это чисто маркетинговая заморочка жирашников) - они ищут в интернетах"
    по моему личному опыту, тут именно проблема клиентов, терминологии и несколько странным образом сложившегося рынка.
    чаще всего, они не очень понимают, что им нужно, используют JIRA не поназначению, а потом говорят, что им она не нравится, потому что в ней нет того и сего, хотя там этого по определению быть и не должно.
    короче, вариантность исходных бизнес-процессов настолько велика и плохо систематизирована, что вот случаются такие казусы.
    "Я крайне редко видел, когда выбирали между Jira и какой-то другой коммерческой системой. В России."
    Да сплошь и рядом: ClearQuest (засел как заноза), TFS, Polarion, Serena TeamTrack, HP Quality Center (эти вообще уже обнаглели :)

    ОтветитьУдалить
  22. Скрипты - это доступ к ядру системы фактически. Т.е. можно там почти все, но на простоту использования оно не ориентировано.
    По поводу скользкого пути - Atlassian на него встала гораздо раньше и вроде все ок :-)
    Цитата их разработчика от 2003 года: "In general, JIRA needs to keep a balance between simplicity for 80% who don't need advanced features, and generality for the 20% who do. Giving users the source (or just JSP source, as illustrated above) lets us err on the side of simplicity."

    ОтветитьУдалить
  23. Да, по поводу терминологии согласен. Т.к. устоявшейся нет, то обычно все называют свои продукты bug/issue tracking, defect tracker, project management и т.п., чтоб поисковики хорошо находили.

    ОтветитьУдалить
  24. 1 - и правильно, скрипты же надо один раз написать и использовать, зачем они должны быть простыми? :)))
    2 - максим, хватит уже сравнивать jira и TS, ну совершенно же разные продукты уже, да и в россии jira сейчас популярна только среди разработчиков и динозавров, остальные ниши занимают другие приложения, а т.к. на запад вы сейчас и не рветесь, то какой смысл с jira сравнивать? Сейчас не 2003 год, а уже 2010-й.....
    ---
    Samorukov Dmitry

    ОтветитьУдалить
  25. Кстати недавно столкнулся с использованием ТС в качестве системы документооборота
    никак не подходит
    именно потому что редактирования документов нет как такового
    пользователи хотят чтобы задачи - и были документами, но тот tiny-редактор что есть требованиям не удовлетворяет:
    1 - нет полноэкранного редактирования - редактор максимум 20-к строк текста поддерживает
    2 - нельзя картинки напрямую в документ вставлять, хотя и то и другое в tiny делается если использовать плагины...
    вот что мешает например это прикрутить? и чтобы редактор разворачивался при необходимости, и чтобы картинки автоматом на сервер аплоадились?
    а вообще имхо надо вам писать десяток широко используемых конфигураций для системы, и ля каждой их них небольшую обучалку для пользователей
    в дальнейшем каждый найдет себе нужное и доработка под себя займет немного времени
    возваливать же полностью настройку бизнес-процессов на пользователя - кардинально не правильно. человек увидел - попробоал - понравилось - стал использовать (не понравилось - не стал), а заморачиваться с настройкой будут единицы.
    именно в этом ваш сейчашний подход я считаю неверным.

    ОтветитьУдалить
  26. А мы сравниваем с тем, с чем пользователи хотят сравнивать. Ну, иногда пользователи хотят сравнения с mantis, bugzilla, redmine, trac, но сравнение с JIRA эти системы покрывает полностью - возможностей в этих системах меньше, а проблемы там ровно те же.
    Если брать системы типа Мегаплана, то я помню буквально 1 или 2 вопроса на эту тему. То ли пользователи, которым нравится TrackStudio исключают Мегаплан из шорт-листа, то ли наоборот (а скорее всего и то, и другое).

    ОтветитьУдалить
  27. >1 - нет полноэкранного редактирования - редактор максимум 20-к строк текста поддерживает
    есть там все, только нафига? Да, у нас не система документооборота.
    >а вообще имхо надо вам писать десяток широко используемых конфигураций для системы, и ля каждой их них небольшую обучалку для пользователей
    Я сейчас примерно этим и занимаюсь

    ОтветитьУдалить
  28. >>есть там все, только нафига? Да, у нас не система документооборота.
    а зачем тогда проскакивала такая мысль, и даже фичи делались, чтобы была возможность использовать в качестве системы документооборота? но до ума получается так и не довели
    >>Я сейчас примерно этим и занимаюсь
    а вот это замечательно, давно пора.

    ОтветитьУдалить