Стоит ли вообще заводить опенсорсную систему тикетов для команды из 8 человек, или это будет сплошная головная боль?

Посчитайте стоимость часа вашего программиста. Даже если этот человек будет тратить всего 4 часа в месяц на установку, настройку и решение проблем системы, внутренние затраты компании сравняются с годовой облачной лицензией. К тому же если он однажды уволится, кто займётся этим сервером? Однозначно берите готовое облачное решение.

Не впадайте в опенсорсный фанатизм. Программисты любят запускать всё на своих серверах, потому что для них это весёлая игрушка. Но когда письма клиентов падают в спам или сервер ложится, счёт оплачиваете вы. Если основная деятельность компании — не управление серверами, опенсорсная тикетница — лишняя обуза.

Мы в агентстве из 10 человек поставили опенсорс. В первый год из-за падения сервера, сбоя синхронизации входящих и обновления софта весь поток обращений в поддержку обрывался 3 раза. Было стыдно перед клиентами. В итоге перешли на готовую облачную систему, платим 200 EUR в месяц, зато уже два года голова совсем не болит.

а если вместо того, чтобы ставить опенсорсную систему самим, взять её у хостинг-компании как готовый установочный пакет — нагрузка по обслуживанию всё равно останется на нас?

В том что надо уходить от общего почтового ящика вы абсолютно правы, вести почту на 8 человек — это полный хаос. Но у готовых систем есть начальные тарифы планы по 12-15 EUR за человека тоже справятся с задачей. Заложите бюджет 100-120 EUR в месяц на 8 человек и не мучайтесь.

в германии штрафы за нарушение приватности данных очень жёсткие. если не сможете нормально настроить опенсорсную систему и утекут переписки с клиентами проблем не оберётесь. честно облачные системы эти требования уже из коробки закрывают.

В общем, общая мысль всего написанного ясна: хотя софт опенсорсной системы бесплатный, операционная работа и расходы на обслуживание выходят дороже готовых облачных систем. Если ваш основной бизнес — не управление серверами, разумнее всего взять готовое решение.

На что обратить внимание при выполнении этого. Внедрение процесса управления изменениями не замедляет работу, а ускоряет её.

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

В этом пункте я с вами не согласен. Если скоуп растет, должен расти либо срок, либо бюджет. Третьего не дано.

Абсолютно. Если добавить к этому: При принятии решений записывайте и худший сценарий, а не только лучший.

На этом всё, извините, если затянул.

Спасибо за ваш пост.

я сталкивался с тем же.

В прошлом году мы столкнулись практически с тем же самым. Если скоуп растет, должен расти либо срок, либо бюджет. Третьего не дано.

Самое дорогое в унаследованной системе — неизвестные зависимости. Если напишете результат здесь, это поможет и другим.

Взял на заметку, спасибо. Больше всего времени у нас уходило на то, что было непонятно, кто принимает решения.

Пытаться сделать это в одиночку — самый дорогой путь.

Если углубиться в детали: Если делаете впервые, начните с малого, масштабирование потом.

Первые три месяца все идет хорошо, проблемы всплывают на четвертом. Это мое мнение, не утверждаю, что оно единственно верное.

У меня есть возражение. График платежей должен быть привязан к этапам работ а не к датам.

Это мое мнение не утверждаю, что оно единственно верное.

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

Каждое «посмотрим позже» на встрече означает неоплаченную работу. Это мое мнение, не утверждаю, что оно единственно верное.

В прошлом году мы столкнулись практически с тем же самым. Чем сложнее отменить решение, тем медленнее его принимайте.

Проверено опытом.