TeamWox — новый продукт нашей компании - страница 4

Новый комментарий
 

Не вопрос: оплатите все лицензии на пару сотен миллионов долларов - будут приходить (а без оплаты это мусор из дисков с тестовыми версиями). Мы несколько лет были подписаны на платный MSDN Subscription (не помню версию) - весь приходящий мусор можно было реально выкидывать.


Задумайтесь об "рабочее место = 5000 долларов" и поймете, что будущее для массового рынка у такого продукта очень туманное. Поставьте себя на место руководителя компании и Вы сделаете четкий вывод - такого не нужно в масштабах компании.


Подумайте о тысячах не ИТ компаний и поймете - они на это не согласятся. А вот на Тимвокс согласятся - это жизненно, просто, объединяет компанию и дешево.


В Тимвоксе (кроме всего прочего) есть все средства установки и отслеживания задач - это же ее основная функция. Стоимость всей системы на всю компанию равна одному-двум рабочим местам ClearDDTS.

 

Ренат, там где-то сверху, если помните, four2one писал: "И что в этой системе нового, удобного, хорошего?"

Мне показалось, что я смог выразить, что ClearDDTS, которым я сам пользовался - и в курсе масштабов применения -

благодаря определенной структуре данных - обладает некой полнотой, которая обеспечивает универсальность.

Т.е. при условии, что некая система обладает универсальностью - ничего нового, удобного и хорошего в ней нет.

.

Конкретно для ClearDDTS мы с Вами пришли к выводу - пользователи ClearDDTS... мягко сказать неправы.

Потому что условия годового лицензирования за $5000 - это натуральный грабеж.

При том, что софт достаточно примитивен - еще до знакомства с ClearDDTS -

мой коллега и я в другой компании пытались заложить возможно даже более продвинутую и удобную

для управления заданиями структуру, структуру хэлп-деска (набор полей был фиксированный,

но планировалась база клиентов, в каждой задаче - что-то типа мини-форума, дерево юзкейсов для удобства

оператора суппорта, более глубокое управление задачами), фактически, пусть в менее удобном виде,

все это настраивается и в ClearDDTS.

.

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

В связи с этим прискорбным фактом, я не могу назвать Вам тулы, которые обеспечивают выполнение

документооборота а-ля ClearDDTS. Но я подозреваю, что подобный софт может где-то существовать.

Включая open-source & продукты за разумные деньги.

 
jartmailru >>:

Ренат, там где-то сверху, если помните, four2one писал: "И что в этой системе нового, удобного, хорошего?"

К сожалению, он не перешел к конкретике.


Но я подозреваю, что подобный софт может где-то существовать. Включая open-source & продукты за разумные деньги.

Именно такой продукт за разумные деньги мы и предлагаем. Но не в режиме бездумного (экономически мертвого) опенсорса, а в виде дешевого профессионального и поддерживаемого продукта.


Тимвокс родился как раз после попыток прикручивания разного софта для управления и бегства от лицензий за рабочие места.

 

Уважаемый Ренат, я искренне хочу посоветовать Вам дополнить документацию для TeamWox SDK, если Вы хотите получить развитие продукта силами сторонних команд и разработчиков. Из профессионального интереса скачал Ваш SDK. Раздел Documentation практически пуст, если не считать файла TeamWox.SDK.Intro.pdf в одну (1) страницу.

Не хочу дразнить такими словами, как MSDN online, но вполне качественный Programming API Guide Ваша команда создала для известного терминала MetaTrader 4 - https://docs.mql4.com/ru/, и локальная контекстная в редакторе Metaeditor справка. Для TeamWox SDK пока такого нет. Можно изучить только два примера модулей - Board и HelloWorld, но всей полноты картины они явно не дают. Неясен выбор средств разработки - только MS VC++ 2005/2008, или также managed .Net code, Java, Borland Delphi и т.д. Весь список модулей, классов, методов и пр. в данный момент по документации неясен. Фактически можно читать заголовочные CPP headers папки SDK, но они всё же полноценной документации не заменяют, восстанавливать из исходников логику системы - не самый продуктивный путь понять её. Например, можно ли перебрать все документы примерно так или иначе:

foreach (SPList list in web.Lists)
{
Console.WriteLine("{0}{1} - {2} items.",
list.Hidden ? "*" : "",
list.Title, list.ItemCount);
Console.WriteLine("Created by {0}", list.Author.Name);
Console.WriteLine("{0}\n--", list.Description);
} // код кнопкой SRC почему-то вставляется в начало ответа, а не в это место. Если применить к выделенному тексту стиль Код, тогда получается верно. Браузер - IE8 native OR compatibility view.

и прочие практические знания.

Это моё личное, стороннее мнение, надеюсь, оно поможет Вам расширить рынок продукта.

И ещё вопрос - Вы позиционируете TeamWox как систему делового документооборота и CRM? Не технического продукта для жизненного цикла разработки ПО? Т.е. систему контроля версий он не заменяет, хотя интеграция с таким ПО возможна сторонними модулями? И опять же в свете упоминания выше о миллиардах выброшенных долларов за подписку MSDN ;) - если Вы пересядете с VS Team Suite на VS Prof или Standard (разница от Suite в стоимости существенна), то как раз версионника и не будет хватать в этом цикле?

 

С документацией все будет в порядке - у нас большой опыт в этом деле. Просто 1 февраля был публичный релиз системы и мы банально не успеваем подготовить документацию. С 1 апреля за нее возьмемся.


TeamWox - это в первую очередь средство групповой работы в компании. Не очередная тулза для программистов, а средство работы для абсолютно всех сотрудников. Позиционирование - GroupWare, где CRM - это лишь часть общей системы. Это очень удобная система для совместной работы удаленных офисов (у нас совместно работают офисы в России, Кипре, Англии и Сингапуре).


Модули для TeamWox рекомендуем писать только на Visual Studio С++ 2005/2008. Потому как использование других (особенно managed) языков неминуемо приведет к мелким и не очень проблемам. Писать конечно можно на чем угодно, но результат может напоминать секс в гамаке, стоя и не снимая ласт.


Для программистов итак очень много систем управления наделали. Правда платные системы совершенно неадекватные по ценам, что не мешает программистам использовать бесплатные аналоги. VS Team Suite - реально бредовый проект, мы пользуемся обычными Visual Studio 2005/2008 Prof + Subversion + TeamWox + собственные серверы LiveUpdate.


В Тимвокс можно написать любой модуль интеграции, сейчас у нас в разработку запущены модули Service Desk (Bugtrack) и Business Processes. Интеграцию в Subversion (и другие бесплатные системы контроля версий) написать несложно, только сначала нужно обосновать необходимость.

 
Renat писал(а)

С документацией все будет в порядке - у нас большой опыт в этом деле. Просто 1 февраля был публичный релиз системы и мы банально не успеваем подготовить документацию. С 1 апреля за нее возьмемся.

Спасибо за пояснения. Я посмотрел ранее ролик по Teamwox, поэтому представлял, что это не среда управления разработкой ПО, а больше коллективная платформа управления бизнес-данными предприятия. Прямо скажем, конкурент MS SharePoint (который платный MOSS 2007 поверх WSS сервисов), MS Dynamics CRM и систем типа Directum, Documentum, DocsVision, в разных частях функциональности.

По поводу коллективной работы именно проектов разработки - у Borland есть продукты, Caliber и Togever, но я их лично не юзал, видел только на презентациях года 3 назад. Порадовала (на картинках) интеграция баг-трекинга с IDE разработки, т.е. можно в задаче трекинга сослаться прямо на файл исходника, и в каком-то из них был кажется и версионный контроль. Сколько стоят, тоже не знаю. Из бесплатных продуктов для себя с удовольствием использую Mantis BugTracker, как говорится, по соотношению цена/качество бесплатное пиво вне конкуренции ;)

А что касается интеграции с версионным контролем. Если Вы решите позиционировать Teamwox и как программерское управление разработкой ПО, то это будет одна из самых актуальных задач. Куда ж без хранения версий исходников. Тот же CVS легко управляется парамерами командной строки, например, WinCVS этим пользуется, как и терминалом MetaTrader можно управлять своими ключами, на основе этого и делать интеграцию.

 

А вот на программеров (в TeamWox) мы никак не ориентируемся и даже открещиваемся.


Надо четко понимать свою целевую аудиторию. И программеские компании никаким образом в нашу целевую область не попадают, так как:

  1. девелоперские компании хотят только бесплатное (это можно утверждать абсолютно точно)
  2. девелоперы итак имеют вокруг настолько много софта для групповой и багтрек работы, что делать для них еще одно решение - это экономическое самоубийство

Хотя, конечно же, никто не запрещает и не против использования Тимвокса у девелоперов. Например, мы отлично уже 3 года живем в своей системе.

Мы ориентируемся на компании:

  1. у которых нет никаких средств групповой работы

  2. они не хотят покупать кусочную автоматизацию в виде поюзерных лицензий

  3. хотят (вернее, им реально лучше подходит) простую донельзя систему, которой смогут пользоваться все 100-200 человек, включая дремучих пользователей (коих в компаниях больше всего), с минимальным уровнем саботажа.

  4. хотят сразу получить интегрированное и цельное решение (бухгалтерия вида 1С за рамками) для управления своими делами

  5. получить эффект уже через неделю, а не через год внедрения
 

Ренат, я думаю, над документацией и подачей этой новой на рынке системы Вашей команде нужно серьёзно поработать. Позволю себе конструктивную критику того материала, который увидел на www.teamwox.com, прошу воспринять её положительно.

Меня несколько лет учили руководители говорить с ними на понятном _им_ языке, без технического ИТ-сленга, в конце концов я понял, что топ-менеждер имеет на это право - общаться с руководителями подразделений и специалистами разных областей (финансовые, юридические и пр.) на понятном ему языке. Это мой комментарий к увиденному ролику "Видео: Опыт организации технической поддержки клиентов в TeamWox" на http://www.teamwox.com/ru/teamwox/tutorials/7, которое провёл Мажит Мугаттаров. Мажит, как указано перед роликом, относится к категории руководителей (не специалистов), и мне не совсем ясна аудитория ролика из-за обильно мелькающих терминов, понятных разве что техническому персоналу уровня сис. админа, DBA или разработчика. Я бы заменил в ролике фразы:

"типа" - на "вида", "наподобие", "таких, как";

"приаттачивается" - "присоединяется", "добавляется";

"task появляется" - "появляется задача";

"скриншоты" - "снимки экранов";

и т.д. И учёл при создании новых видео.

У Вас в информационной ИТ-компании руководитель (т.е. Вы) технически достаточно развит (наверняка у Вас техническое прошлое), самостоятельно общается на форуме, сам пишет ИТ-шные сленговые выражения, но, поверьте, на многих предприятиях реальных секторов экономики это не так. Ими руководят люди в возрасте, далёкие от ИТ, компании в целом достаточно бюрократичны, и я с трудом представляю, что эти принимающие решение руководители поймут такой стиль презентации, эти выражения. Кстати, на http://www.teamwox.com/ru/demo/ написано также: "создавать собственные таски". Что за таски?? Создавать задачи. Это первое замечание.

Второе. В этом ролике интерфейс системы показан английский, и может сразу возникнуть вопрос - русский-то есть? На http://www.teamwox.com/ru/teamwox/tutorials/24 он есть, но это _другой_ ролик в другом месте. Мне кажется, стоит разделить их явно, ролики на RU и EN аудиторию. Даже имена Smit John с трудом воспринимаются в русскоязычной презентации, то ли дело какой-нибудь Михаил Петрович или фрезеровщик Иван Дулин ;)

Третье. В ролике "Видео: TeamWox. Анти-Бумажная Промышленность" на http://www.teamwox.com/ru/teamwox/tutorials/21 при согласовании договора сотрудник - инициатор договора, самостоятельно выбирает тех лиц, которые должны его согласовать. В реальности на предприятии (например, где я работаю) у каждого типа документа (договор, докладная записка, заявление и пр.) есть определённый политикой компании маршрут согласования. Т.е. договор должен зарегистрировать договорной отдел, затем завизировать планово-экономический, производственный отделы, бухгалтерия, юридический, ..., затем заместители генерального директора, и в конце на подпись в необходимом числе экземпляров. Т.е. инициатор договора не может произвольно выбирать, как ему вздумается, тех людей, которые должны завизировать этот договор. При этом должен быть прописан в маршруте алгоритм движения, если кто-либо в цепочке отказал в визе и отправил документ на доработку, куда он вернётся. Отсюда потенциальные технические вопросы, которые могут возникнуть у заказчика по системе - есть ли справочник типов документов, которые система может обрабатывать, можно ли его изменять и дополнять, возможно ли для кадого типа документа задавать визуально (или программно) маршрут согласования, ставить типовые сроки исполнения (например, согласование договора на каждом этапе визирования - 2 рабочих дня, согласование договора с срочным приоритетом - 6 рабочих часов и т.д.). Я думаю, у людей, работавших с другими системами документооборота или CRM, такие вопросы возникнут в большом количестве. Их тоже нужно отразить в документации или роликах для ясности при принятии решения о выборе системы.

Надеюсь, Вы восприняли мои замечания с пониманием. Они, хоть и критичны, но доброжелательны.

 
chv >>:

Надеюсь, Вы восприняли мои замечания с пониманием. Они, хоть и критичны, но доброжелательны.

Большое спасибо - я сам постоянно бьюсь над человечностью представления информации. Шаг за шагом все будем тюнить.

 
Renat >>:

Большое спасибо - я сам постоянно бьюсь над человечностью представления информации. Шаг за шагом все будем тюнить.

Улучшать :)

12345
Новый комментарий
Причина обращения: