Как стать автором
Обновить

Самописное решение или «коробка»: сравниваем два подхода к автоматизации service desk в молодых компаниях

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров1.7K
Всего голосов 1: ↑1 и ↓0+1
Комментарии2

Комментарии 2

Нет никакого оправдания изготовлению собственной поделки там, где есть типовое отработанное и стандартное решение, причём массовое. Этих сервисдесков готовых навалом, все делают почти одно и то же, кому нужен очередной аналоговнетный велосипед? Вы даже велосипед готовый покупаете, а не клепаете в своём гараже.

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

Есть важный момент: если вы делаете продукт для клиентов, которые им пользуются напрямую (интернет банкниг, онлайн магазин) - еще можно поверить в то, что у вас есть какая-то идея, которая реально является конкурентным преимуществом. Ну как минимум, можно придумать, как отбить инвестиции на нее. Хотя надо понимать, что делая решение, которое уже сделано до вас 100500 раз, вряд ли стоит рассчитывать на то, что вот именно вы придумали что-то новое. По опыту, выбранная платформа может реально не поддерживать все идеи рынка, и вам ее надо кастомизировать, чтобы реализовать уже известную идею, которой просто нет на этой платформе.

Если же решение для внутреннего пользователя, то возникает вопрос. А точно вам стоит строить "свой" процесс, а не воспользоваться наработанным опытом. Тут ведь уже нет ваши клиентов, который заценят удобный UI, броский дизайн и все такое.

Сервис деск мне видится крайне типовой задачей. Ну что вы там можете придумать? Ну понятно, есть интеграция с тем что есть. Это всегда и везде. Но в самой логике системы?

---------------

С точки зрения затрат - плафторма часто выгоднее, так как:

  • вы получаете код, отработанные на сотне (а может и на десятках тысяч) внедрений

  • вы можете в рамках поддержки получать патчи, фиксы и прочие плюшки (даже новые фичи)

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

  • возможность на шару получить консалтинг для производителя, который поделится опытом других

В случае разработки с нуля вы на ровном месте получаете просто тонну гемороя, связанную с необходимостью растить свои компетенции, как ИТ компания разработчик. При этом имея свой код, который никому не интересен на рынке и со временем станет legacy решением (если не стало им сразу), на которое без слез не взглянешь

------------

Еще про "гибкость". Заказчики часто это хотят. Вот мы ща построим систему, которая будет настраиваемой и все такое. И есть проблема. Это можно сделать. И часто делается. Но проблема в том, что эта гибкость реально уникальна.

Да, есть куча JSON/XML, таблиц, можно даже в UI сделать. Но это уникальный продукт. И компетенции человека, который делает настройку также уникальны. На рынке нельзя взять готового спеца под ваш продукт. В принципе. А вот разраба - всегда пожалйста :) И часто получается так, что делается хороший продукт, гибкий, настраиваемый. А потом "идеолог" гибкости увольняется. И все. А за ним пустота и никто не знает, как им правильно пользоваться. И проблема не в тех, кто делал этот продукт. Они сделали под виденье "идеолога", как он просил.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории