Скачал evaluation этого замечательного тула - первого совмещенного issue-трекера и PM Tool, из тех, что мне попадались. Уже можно кое-что сказать. Буду сравнивать с JIRA
( Read more... )
Re: интегрированный pm + issue trackingmaximkrApril 30 2008, 17:12:15 UTC
А они не могут со всем интегрироваться, даже если очень захотят. Пока они поддерживают только SVN - они могут закладываться на тонкие фичи SVN и делать красивую интеграцию. Если нужен еще и CVS - придется интегрироваться с общим знаменателем и чем больше продуктов поддерживается - тем сложнее и хуже интеграция.
У нас аналогично с поддержкой СУБД было: сначала мы затачивали продукт под ORACLE и там были запросы по 4 КБ, триггера и хитрые ораклячие конструкции типа START WITH/CONNECT BY. А потом возникла необходимость и другие СУБД поддерживать, в итоге остались INSERT/UPDATE/DELETE и SELECT по ключевому полю :-)
Еще момент: у всех продуктов есть какая своя "идея" как правильно делать софт. Пока вам эта идея нравится - все замечательно, а шаг влево-вправо - начинаются грабли. Например,
1) В Polarion считают, что все должны использовать SVN.
2) Мы считаем, что с клиентами нужно общаться неформально, а issue tracker нужно использовать для организации внутренней работы. В возможность планирования на основе issue tracking не верим (слишком мелкий уровень), а wiki вообще считаем ошибкой природы :-)
3) В Atlassian считают, что багтрекер - это для общения с клиентами, а планировать, учитывать время и назначать задачи нужно путем развешивания бумажек по стенам. Иерархии для общения с клиентами не нужны - поэтому их там нет и не будет. Field-level security, кастом-поля для версий или проектов - аналогично, для общения с клиентами все это просто не надо.
Главная разница между нами/Polarion и JIRA - в очевидности этой "идеи" продукта. Скажем, понять что у Polarion нет поддержки CVS очень просто, достаточно посмотреть на сайте. Что TrackStudio не заточена под случайных внешних клиентов - тоже, они просто не разберутся с интерфейсом, это очевидно после первого запуска :-) Но JIRA за счет customer-driven development поддерживает базовую реализацию самых разных "идей", поэтому понять, что она не очень хорошо подходит для планирования или управления требованиями многие просто не успевают, ведь базовая функциональность настраивается очень легко и клиенты ожидают того же в дальнейшем.
Re: интегрированный pm + issue trackinggapertonMay 1 2008, 00:47:46 UTC
> Что TrackStudio не заточена под случайных внешних клиентов - тоже, они просто не разберутся с интерфейсом, это очевидно после первого запуска :-)
Это преимущество, Максим? То, что "случайные" внешние клиенты не разберутся с вашим интерфейсом - это не недостаток вашего интерфейса, а особенность позиционирования?
> Но JIRA за счет customer-driven development поддерживает базовую реализацию самых разных "идей", поэтому понять, что она не очень хорошо подходит для планирования или управления требованиями многие просто не успевают, ведь базовая функциональность настраивается очень легко и клиенты ожидают того же в дальнейшем.
То есть, наличие плагинов типа GreenHooper - это слабая cторона JIRA, и по вашему многие клиенты глядя на них не успеют понять, что планировать у них не выйдет?
Максим, в большинстве областей JIRA превосходит вас на порядок. По сути, единственное ваше преимущество перед JIRA - это иерархические задачи и низкая цена. В остальном вы проигрываете. Почему вы просто не признаете сильных сторон конкурента, и не примете мер по их обходу, я не пойму? Вот загадка, натурально. Думаете, так никто не догадается?
Re: интегрированный pm + issue trackingmaximkrMay 1 2008, 07:01:24 UTC
> Это преимущество, Максим? То, что "случайные" внешние клиенты не > разберутся с вашим интерфейсом - это не недостаток вашего > интерфейса, а особенность позиционирования?
Конечно, недостаток. И мы работаем над этим - в 4.0 должно все стать сильно лучше. Но для проектов типа заказной разработки этот недостаток не так критичен (случайные люди доступ к системе не имеют), а вот field level security - очень важна.
Аналогично у JIRA: отсутствие field level security мешает клиентам, использующим JIRA для внутренних процессов, но абсолютно некритично для использующих JIRA как продвинутый форум.
> То есть, наличие плагинов типа GreenHooper - это слабая cторона > JIRA, и по вашему многие клиенты глядя на них не успеют понять, > что планировать у них не выйдет?
Ну, вы в первом посте написали, что project management функциональность JIRA даже с GreenHooper не дотягивает до MS Project :-) Почему тогда GreenHooper - это правильно, а простенький build server или wiki в Polaris - нет ? Ведь в обоих случаях к issue tracker-у прилепляется какая-то несвойственная им функциональность, заведомо недотягивающая до уровня аналогичных отдельных продуктов.
> Максим, в большинстве областей JIRA превосходит вас на порядок. > По сути, единственное ваше преимущество перед JIRA - это > иерархические задачи и низкая цена. В остальном вы проигрываете.
А можно подробности ? Вот смотрю на список most popular issues - людям в JIRA не хватает совершенно базовой для issue tracking функциональности, не имеющей отношения к wiki или планированию (field level security, time zone для пользователей, кастом-полей для всего, неограниченной вложенность задач), а у нас все это есть.
А вот планирование, wiki, форум и прочее - это все нетипично для issue tracker-ов. Мы делаем принтер, а Atlassian - МФУ.
Re: интегрированный pm + issue trackinggapertonMay 1 2008, 09:07:45 UTC
> Ну, вы в первом посте написали, что project management функциональность JIRA даже с GreenHooper не дотягивает до MS Project :-) Почему тогда GreenHooper - это правильно, а простенький build server или wiki в Polaris - нет ? Ведь в обоих случаях к issue tracker-у прилепляется какая-то несвойственная им функциональность, заведомо недотягивающая до уровня аналогичных отдельных продуктов.
Потому, что MS Project и подобные совершенно не пригоден для планирования выпуска релизов, Максим. А вот JIRA c GreenHooper - вполне пригодна. Вы можете считать это свойственной функциональностью для трекера или несвойственной - ваше дело. Но людям это требуется, потому что у них в трекерах проходят задачи для этих релизов - именно поэтому и JIRA и Polarian это умеют.
Наличие wiki и build server в трекере - не принципиально, его можно и сбоку пустить. А вот планирование, элементами которого и являются issue, "сбоку" не запустишь.
> А можно подробности ? Вот смотрю на список most popular issues - людям в JIRA не хватает совершенно базовой для issue tracking функциональности, не имеющей отношения к wiki или планированию (field level security, time zone для пользователей, кастом-полей для всего, неограниченной вложенность задач), а у нас все это есть.
Совершенно базовой функциональности, говорите? Как я могу добавить закладки для кастомных полей issue? Хочу чтоб выбрасывался отдельный экран на переход состояния - где это у вас? Кастом-поля "для всего" у меня в JIRA есть. А насчет задач - есть, например, еще и понятие Releases и куча специальных отчетов для их планирования и проведения Triage. Чего у вас нет, и надо как-то выдумывать самому и на коленке собирать.
Мы с вами общались достаточно подробно, вообще-то. У вас тулза "из коробки" не умеет практически ничего, ее надо допиливать и "внедрять". JIRA - поддерживает все основные юз-кейсы из коробки.
Re: интегрированный pm + issue trackingmaximkrMay 1 2008, 09:57:27 UTC
> Потому, что MS Project и подобные совершенно не пригоден для > планирования выпуска релизов, Максим. А вот JIRA c GreenHooper - > вполне пригодна. Вы можете считать это свойственной > функциональностью для трекера или несвойственной - ваше дело. Но > людям это требуется, потому что у них в трекерах проходят задачи > для этих релизов - именно поэтому и JIRA и Polarian это умеют.
Боюсь, я тут аргументированно спорить не смогу - мы планированием практически не занимались. В качестве внешней тулзы для планирования релизов клиенты хотят видеть скорее MS Project, чем GreenHooper от Atlassin, может быть это дело привычки, не знаю. Каких-то принципиальных проблем с планированием релизов в MS Project я тоже не вижу (чисто теоретически, мы им не пользуемся) - просто не нужно детализировать список работ в MS Project до уровня отдельных задач на 15-20 минут, это должны быть гораздо более крупные куски. Если строительство дома планировать в MS Project с типичной для issue tracker-а детальностью типа "Вася 15 минут мешает раствор, Петя в это время крутит шуруп N2 и N4", то тоже ничего хорошего не выйдет. Ну,в общем мы это тоже обсуждали :-)
> Мы с вами общались достаточно подробно, вообще-то. У вас тулза > "из коробки" не умеет практически ничего, ее надо допиливать и > "внедрять". JIRA - поддерживает все основные юз-кейсы из коробки.
Ну, у нас есть примеры конфигураций, там есть и ITIL, и управление требованиями, и классический bug tracking. У нас же "допиливание" - это не правка XML-конфигов и переписывание исходников, это на 95% настройка мышкой через web-интерфейс, документированное, с flash-мультиками.
А от допиливания я не знаю куда деться - сам подход business process management подразумевает, что система сначала настраивается под имеющийся бардак, потом анализируется и меняется в сторону уменьшения бардака: http://en.wikipedia.org/wiki/Business_Process_Management
Re: интегрированный pm + issue trackinggapertonMay 3 2008, 11:55:36 UTC
> Каких-то принципиальных проблем с планированием релизов в MS Project я тоже не вижу (чисто теоретически, мы им не пользуемся) - просто не нужно детализировать список работ в MS Project до уровня отдельных задач на 15-20 минут, это должны быть гораздо более крупные куски.
А я вот планированием занимаюсь профессионально, Максим. Дефекты и фичреквесты, которые проходят именно в issue tracker, и из которых релиз может процентов на 60-80 состоять, мне тоже прикажете в MS Project учитывать, да?
> просто не нужно детализировать список работ в MS Project до уровня отдельных задач на 15-20 минут, это должны быть гораздо более крупные куски.
Спасибо за дельный совет по планированию :). В прошлый раз вы, помнится, пытались меня убедить, что планировать вообще невозможно, приводя в доказательство блог-пост какого-то идиота, который основываясь на школьных знаниях теории вероятности рассуждая о планировании, пытался опровергнуть центральную предельную теорему.
Короче, Максим - не хотите делать - это ваше дело, вы управляете своими приоритетами и позиционированием как считаете правильным - это ваш бизнес и ваша обязанность. Убеждать в чем-то я вас не собираюсь, вам виднее. Только не надо меня убеждать, что мне нужно и как надо планировать, хорошо? :) Это виднее мне.
И еще один момент. Нормальная продажа от впаривания отличается тем, что вы честно признаете как сильные так и слабые стороны вашего продукта при сравнении с конкурентами, и не пытаетесь скрыть их от своих клиентов. Ваши сравнения с JIRA при всем желании нельзя назвать объективными - это бьет прежде всего по вам. Ну по крайней мере мне так кажется - вам опять же виднее.
> А от допиливания я не знаю куда деться - сам подход business process management подразумевает, что система сначала настраивается под имеющийся бардак, потом анализируется и меняется в сторону уменьшения бардака:
У меня другие данные. По моим данным, если вы автоматизируете бардак, то получите в лучшем случае автоматизированный бардак, а в худшем - вообще ничего не получите, потому что бардак трудно описать системно в виде требований . При внедрении системы практически всегда перетряхивают существующие бизнес-процессы сразу, за редкими исключениями. Но это неважно.
Важно то, и это глупо отрицать, что JIRA для целей управления разработкой софта юзабельнее и функциональнее, чем ваше решение "из коробки". А если чего нет из коробки, то многое решается доставкой плагинов - чего у вас опять же нет.
Если вы оказываете сервис по настройке (а вы оказываете - у вас другая бизнес модель, не такая как у Atlassian), то вам наоборот - неважно, насколько у вас система готова к работе из коробки. Скорее наоборот. Но тогда не надо мерятся с Atlassian - это продуктовая а не сервисная компания. Сервис там партнеры оказывают.
Re: интегрированный pm + issue trackingmaximkrMay 3 2008, 15:29:35 UTC
> А я вот планированием занимаюсь профессионально, Максим. Дефекты > и фичреквесты, которые проходят именно в issue tracker, и из > которых релиз может процентов на 60-80 состоять, мне тоже > прикажете в MS Project учитывать, да?
Не стоит, это явно плохая идея. Скорее, на основе информации в issue tracker-е, информации о том, кто именно уже тестировал этот модуль, насколько он важен для пользователя и т.п. можно сделать оценку (в голове) и занести ее в MS Project.
Т.е. в нашем случае issue tracker - это средство для огранизации внутренней работы, а ms project - средство для общения с клиентом. Но наш случай не единственный, в Atlassian, например, считают, что issue tracker стоит использовать для общения с клиентами, а внутри организации можно использовать доску, распечатки и фломастеры. А кто-то еще может считать, что и project management, и issue tracking должны использоваться внутри команды для планирования, а клиенту прогнозы нужно сообщать обычным письмом, например.
Какой путь самый правильный - я не знаю, наверное, каждый выбирает что ему ближе.
> И еще один момент. Нормальная продажа от впаривания отличается > тем, что вы честно признаете как сильные так и слабые стороны > вашего продукта при сравнении с конкурентами, и не пытаетесь > скрыть их от своих клиентов. Ваши сравнения с JIRA при всем > желании нельзя назвать объективными - это бьет прежде всего по > вам. Ну по крайней мере мне так кажется - вам опять же виднее.
Да, честно признаю: 1) У нас продукт более сложный, а интерфес - не интуитивный. 2) У нас меньше клиентов и меньше community. 3) У нас хуже интеграция прямо из коробки.
> Важно то, и это глупо отрицать, что JIRA для целей управления > разработкой софта юзабельнее и функциональнее, чем ваше решение > "из коробки". А если чего нет из коробки, то многое решается > доставкой плагинов - чего у вас опять же нет.
А я и не отрицаю - стандартная конфигурация JIRA "богаче" стандартной конфигурации TrackStudio.
Re: интегрированный pm + issue trackinggapertonMay 3 2008, 20:43:32 UTC
> Не стоит, это явно плохая идея. Скорее, на основе информации в issue tracker-е, информации о том, кто именно уже тестировал этот модуль, насколько он важен для пользователя и т.п. можно сделать оценку (в голове) и занести ее в MS Project.
Заносите, Максим - флаг Вам в руки :). Электричку навстречу вы себе сами при таком подходе обеспечите. Интересно, вот почему вы сами не пользуетесь Project, и планирования не ведете, а мне рассказываете, как мне надо делать? :)
> ...в Atlassian, например, считают, что issue tracker стоит использовать для общения с клиентами, а внутри организации можно использовать доску, распечатки и фломастеры.
Утешайте себя этим, Максим. :) Долго еще будете сказки рассказывать, как в Atlassian ружья кирпичом чистят? Блин, вам от этого ни жарко ни холодно, продукт ваш от этого лучше не станет, а JIRA не станет хуже - зачем вы это повторяете все время? Давайте и я вам в третий раз повторю, что для JIRA есть плагин GreenHooper, плагин для проведения Triage, и двухсторонняя интеграция с MS Project. Которые превращают JIRA в зрелое решение для планирования. У вас нет ничего подобного даже близко. При этом как там они сами в Atlassian планируют - да пусть хоть на заднице себе маркерами рисуют, мне все равно, честно :).
> Да, честно признаю: > 1) У нас продукт более сложный, а интерфес - не интуитивный. Это вы себе льстите. Продукт ваш существенно проще JIRA, он обладает только базовой функциональностью трекера по сути. JIRA по сравнению с вашим продуктом просто злобнонавороченный монстр. А вот что интерфейс у вас не интуитивный - это вы зря. Он вполне интуитивный, я сразу разобрался. Он, как бы это сказать помягче, простоват. Видно, что сил на него раз в 10 меньше затрачено, чем на интерфейс JIRA.
> 2) У нас меньше клиентов и меньше community. Ну это никакого отношения к качеству продукта не имеет. Это следствие, а не причина.
> 3) У нас хуже интеграция прямо из коробки. Ой, если бы только это, то и проблем бы никаких не было. Я бы вам эту интеграцию тупо заказал, а вы бы мне ее сделали.
Плохо у вас получается быть честным. Ну да ладно. Вам виднее. Главное - классно вы Atlassian со сравнением развели. Зря они, дурачки, отвечать начали на своем сайте. Бесплатную рекламу вам сделали.
У нас аналогично с поддержкой СУБД было: сначала мы затачивали продукт под ORACLE и там были запросы по 4 КБ, триггера и хитрые ораклячие конструкции типа START WITH/CONNECT BY. А потом возникла необходимость и другие СУБД поддерживать, в итоге остались INSERT/UPDATE/DELETE и SELECT по ключевому полю :-)
Еще момент: у всех продуктов есть какая своя "идея" как правильно делать софт. Пока вам эта идея нравится - все замечательно, а шаг влево-вправо - начинаются грабли. Например,
1) В Polarion считают, что все должны использовать SVN.
2) Мы считаем, что с клиентами нужно общаться неформально, а issue tracker нужно использовать для организации внутренней работы. В возможность планирования на основе issue tracking не верим (слишком мелкий уровень), а wiki вообще считаем ошибкой природы :-)
3) В Atlassian считают, что багтрекер - это для общения с клиентами, а планировать, учитывать время и назначать задачи нужно путем развешивания бумажек по стенам. Иерархии для общения с клиентами не нужны - поэтому их там нет и не будет. Field-level security, кастом-поля для версий или проектов - аналогично, для общения с клиентами все это просто не надо.
Главная разница между нами/Polarion и JIRA - в очевидности этой "идеи" продукта. Скажем, понять что у Polarion нет поддержки CVS очень просто, достаточно посмотреть на сайте. Что TrackStudio не заточена под случайных внешних клиентов - тоже, они просто не разберутся с интерфейсом, это очевидно после первого запуска :-)
Но JIRA за счет customer-driven development поддерживает базовую реализацию самых разных "идей", поэтому понять, что она не очень хорошо подходит для планирования или управления требованиями многие просто не успевают, ведь базовая функциональность настраивается очень легко и клиенты ожидают того же в дальнейшем.
Reply
Это преимущество, Максим? То, что "случайные" внешние клиенты не разберутся с вашим интерфейсом - это не недостаток вашего интерфейса, а особенность позиционирования?
> Но JIRA за счет customer-driven development поддерживает базовую реализацию самых разных "идей", поэтому понять, что она не очень хорошо подходит для планирования или управления требованиями многие просто не успевают, ведь базовая функциональность настраивается очень легко и клиенты ожидают того же в дальнейшем.
То есть, наличие плагинов типа GreenHooper - это слабая cторона JIRA, и по вашему многие клиенты глядя на них не успеют понять, что планировать у них не выйдет?
Максим, в большинстве областей JIRA превосходит вас на порядок. По сути, единственное ваше преимущество перед JIRA - это иерархические задачи и низкая цена. В остальном вы проигрываете. Почему вы просто не признаете сильных сторон конкурента, и не примете мер по их обходу, я не пойму? Вот загадка, натурально. Думаете, так никто не догадается?
Reply
> разберутся с вашим интерфейсом - это не недостаток вашего
> интерфейса, а особенность позиционирования?
Конечно, недостаток. И мы работаем над этим - в 4.0 должно все стать сильно лучше. Но для проектов типа заказной разработки этот недостаток не так критичен (случайные люди доступ к системе не имеют), а вот field level security - очень важна.
Аналогично у JIRA: отсутствие field level security мешает клиентам, использующим JIRA для внутренних процессов, но абсолютно некритично для использующих JIRA как продвинутый форум.
> То есть, наличие плагинов типа GreenHooper - это слабая cторона
> JIRA, и по вашему многие клиенты глядя на них не успеют понять,
> что планировать у них не выйдет?
Ну, вы в первом посте написали, что project management функциональность JIRA даже с GreenHooper не дотягивает до MS Project :-) Почему тогда GreenHooper - это правильно, а простенький build server или wiki в Polaris - нет ? Ведь в обоих случаях к issue tracker-у прилепляется какая-то несвойственная им функциональность, заведомо недотягивающая до уровня аналогичных отдельных продуктов.
> Максим, в большинстве областей JIRA превосходит вас на порядок.
> По сути, единственное ваше преимущество перед JIRA - это
> иерархические задачи и низкая цена. В остальном вы проигрываете.
А можно подробности ? Вот смотрю на список most popular issues - людям в JIRA не хватает совершенно базовой для issue tracking функциональности, не имеющей отношения к wiki или планированию (field level security, time zone для пользователей, кастом-полей для всего, неограниченной вложенность задач), а у нас все это есть.
А вот планирование, wiki, форум и прочее - это все нетипично для issue tracker-ов. Мы делаем принтер, а Atlassian - МФУ.
Reply
Потому, что MS Project и подобные совершенно не пригоден для планирования выпуска релизов, Максим. А вот JIRA c GreenHooper - вполне пригодна. Вы можете считать это свойственной функциональностью для трекера или несвойственной - ваше дело. Но людям это требуется, потому что у них в трекерах проходят задачи для этих релизов - именно поэтому и JIRA и Polarian это умеют.
Наличие wiki и build server в трекере - не принципиально, его можно и сбоку пустить. А вот планирование, элементами которого и являются issue, "сбоку" не запустишь.
> А можно подробности ? Вот смотрю на список most popular issues - людям в JIRA не хватает совершенно базовой для issue tracking функциональности, не имеющей отношения к wiki или планированию (field level security, time zone для пользователей, кастом-полей для всего, неограниченной вложенность задач), а у нас все это есть.
Совершенно базовой функциональности, говорите? Как я могу добавить закладки для кастомных полей issue? Хочу чтоб выбрасывался отдельный экран на переход состояния - где это у вас? Кастом-поля "для всего" у меня в JIRA есть. А насчет задач - есть, например, еще и понятие Releases и куча специальных отчетов для их планирования и проведения Triage. Чего у вас нет, и надо как-то выдумывать самому и на коленке собирать.
Мы с вами общались достаточно подробно, вообще-то. У вас тулза "из коробки" не умеет практически ничего, ее надо допиливать и "внедрять". JIRA - поддерживает все основные юз-кейсы из коробки.
Reply
> планирования выпуска релизов, Максим. А вот JIRA c GreenHooper -
> вполне пригодна. Вы можете считать это свойственной
> функциональностью для трекера или несвойственной - ваше дело. Но
> людям это требуется, потому что у них в трекерах проходят задачи
> для этих релизов - именно поэтому и JIRA и Polarian это умеют.
Боюсь, я тут аргументированно спорить не смогу - мы планированием практически не занимались. В качестве внешней тулзы для планирования релизов клиенты хотят видеть скорее MS Project, чем GreenHooper от Atlassin, может быть это дело привычки, не знаю.
Каких-то принципиальных проблем с планированием релизов в MS Project я тоже не вижу (чисто теоретически, мы им не пользуемся) - просто не нужно детализировать список работ в MS Project до уровня отдельных задач на 15-20 минут, это должны быть гораздо более крупные куски. Если строительство дома планировать в MS Project с типичной для issue tracker-а детальностью типа "Вася 15 минут мешает раствор, Петя в это время крутит шуруп N2 и N4", то тоже ничего хорошего не выйдет.
Ну,в общем мы это тоже обсуждали :-)
> Мы с вами общались достаточно подробно, вообще-то. У вас тулза
> "из коробки" не умеет практически ничего, ее надо допиливать и
> "внедрять". JIRA - поддерживает все основные юз-кейсы из коробки.
Ну, у нас есть примеры конфигураций, там есть и ITIL, и управление требованиями, и классический bug tracking. У нас же "допиливание" - это не правка XML-конфигов и переписывание исходников, это на 95% настройка мышкой через web-интерфейс, документированное, с flash-мультиками.
А от допиливания я не знаю куда деться - сам подход business process management подразумевает, что система сначала настраивается под имеющийся бардак, потом анализируется и меняется в сторону уменьшения бардака:
http://en.wikipedia.org/wiki/Business_Process_Management
Reply
А я вот планированием занимаюсь профессионально, Максим. Дефекты и фичреквесты, которые проходят именно в issue tracker, и из которых релиз может процентов на 60-80 состоять, мне тоже прикажете в MS Project учитывать, да?
> просто не нужно детализировать список работ в MS Project до уровня отдельных задач на 15-20 минут, это должны быть гораздо более крупные куски.
Спасибо за дельный совет по планированию :). В прошлый раз вы, помнится, пытались меня убедить, что планировать вообще невозможно, приводя в доказательство блог-пост какого-то идиота, который основываясь на школьных знаниях теории вероятности рассуждая о планировании, пытался опровергнуть центральную предельную теорему.
Короче, Максим - не хотите делать - это ваше дело, вы управляете своими приоритетами и позиционированием как считаете правильным - это ваш бизнес и ваша обязанность. Убеждать в чем-то я вас не собираюсь, вам виднее. Только не надо меня убеждать, что мне нужно и как надо планировать, хорошо? :) Это виднее мне.
И еще один момент. Нормальная продажа от впаривания отличается тем, что вы честно признаете как сильные так и слабые стороны вашего продукта при сравнении с конкурентами, и не пытаетесь скрыть их от своих клиентов. Ваши сравнения с JIRA при всем желании нельзя назвать объективными - это бьет прежде всего по вам. Ну по крайней мере мне так кажется - вам опять же виднее.
> А от допиливания я не знаю куда деться - сам подход business process management подразумевает, что система сначала настраивается под имеющийся бардак, потом анализируется и меняется в сторону уменьшения бардака:
У меня другие данные. По моим данным, если вы автоматизируете бардак, то получите в лучшем случае автоматизированный бардак, а в худшем - вообще ничего не получите, потому что бардак трудно описать системно в виде требований . При внедрении системы практически всегда перетряхивают существующие бизнес-процессы сразу, за редкими исключениями. Но это неважно.
Важно то, и это глупо отрицать, что JIRA для целей управления разработкой софта юзабельнее и функциональнее, чем ваше решение "из коробки". А если чего нет из коробки, то многое решается доставкой плагинов - чего у вас опять же нет.
Если вы оказываете сервис по настройке (а вы оказываете - у вас другая бизнес модель, не такая как у Atlassian), то вам наоборот - неважно, насколько у вас система готова к работе из коробки. Скорее наоборот. Но тогда не надо мерятся с Atlassian - это продуктовая а не сервисная компания. Сервис там партнеры оказывают.
Reply
> и фичреквесты, которые проходят именно в issue tracker, и из
> которых релиз может процентов на 60-80 состоять, мне тоже
> прикажете в MS Project учитывать, да?
Не стоит, это явно плохая идея. Скорее, на основе информации в issue tracker-е, информации о том, кто именно уже тестировал этот модуль, насколько он важен для пользователя и т.п. можно сделать оценку (в голове) и занести ее в MS Project.
Т.е. в нашем случае issue tracker - это средство для огранизации внутренней работы, а ms project - средство для общения с клиентом.
Но наш случай не единственный, в Atlassian, например, считают, что issue tracker стоит использовать для общения с клиентами, а внутри организации можно использовать доску, распечатки и фломастеры.
А кто-то еще может считать, что и project management, и issue tracking должны использоваться внутри команды для планирования, а клиенту прогнозы нужно сообщать обычным письмом, например.
Какой путь самый правильный - я не знаю, наверное, каждый выбирает что ему ближе.
> И еще один момент. Нормальная продажа от впаривания отличается
> тем, что вы честно признаете как сильные так и слабые стороны
> вашего продукта при сравнении с конкурентами, и не пытаетесь
> скрыть их от своих клиентов. Ваши сравнения с JIRA при всем
> желании нельзя назвать объективными - это бьет прежде всего по
> вам. Ну по крайней мере мне так кажется - вам опять же виднее.
Да, честно признаю:
1) У нас продукт более сложный, а интерфес - не интуитивный.
2) У нас меньше клиентов и меньше community.
3) У нас хуже интеграция прямо из коробки.
Собственно, Atlassian написали свое сравнение, ссылка на него и обсуждение тут:
http://maximkr.livejournal.com/9378.html
> Важно то, и это глупо отрицать, что JIRA для целей управления
> разработкой софта юзабельнее и функциональнее, чем ваше решение
> "из коробки". А если чего нет из коробки, то многое решается
> доставкой плагинов - чего у вас опять же нет.
А я и не отрицаю - стандартная конфигурация JIRA "богаче" стандартной конфигурации TrackStudio.
Reply
Заносите, Максим - флаг Вам в руки :). Электричку навстречу вы себе сами при таком подходе обеспечите. Интересно, вот почему вы сами не пользуетесь Project, и планирования не ведете, а мне рассказываете, как мне надо делать? :)
> ...в Atlassian, например, считают, что issue tracker стоит использовать для общения с клиентами, а внутри организации можно использовать доску, распечатки и фломастеры.
Утешайте себя этим, Максим. :) Долго еще будете сказки рассказывать, как в Atlassian ружья кирпичом чистят? Блин, вам от этого ни жарко ни холодно, продукт ваш от этого лучше не станет, а JIRA не станет хуже - зачем вы это повторяете все время? Давайте и я вам в третий раз повторю, что для JIRA есть плагин GreenHooper, плагин для проведения Triage, и двухсторонняя интеграция с MS Project. Которые превращают JIRA в зрелое решение для планирования. У вас нет ничего подобного даже близко. При этом как там они сами в Atlassian планируют - да пусть хоть на заднице себе маркерами рисуют, мне все равно, честно :).
> Да, честно признаю:
> 1) У нас продукт более сложный, а интерфес - не интуитивный.
Это вы себе льстите. Продукт ваш существенно проще JIRA, он обладает только базовой функциональностью трекера по сути. JIRA по сравнению с вашим продуктом просто злобнонавороченный монстр. А вот что интерфейс у вас не интуитивный - это вы зря. Он вполне интуитивный, я сразу разобрался. Он, как бы это сказать помягче, простоват. Видно, что сил на него раз в 10 меньше затрачено, чем на интерфейс JIRA.
> 2) У нас меньше клиентов и меньше community.
Ну это никакого отношения к качеству продукта не имеет. Это следствие, а не причина.
> 3) У нас хуже интеграция прямо из коробки.
Ой, если бы только это, то и проблем бы никаких не было. Я бы вам эту интеграцию тупо заказал, а вы бы мне ее сделали.
Плохо у вас получается быть честным. Ну да ладно. Вам виднее. Главное - классно вы Atlassian со сравнением развели. Зря они, дурачки, отвечать начали на своем сайте. Бесплатную рекламу вам сделали.
Reply
Leave a comment