Я хотів би поділитися історією того, як TTS (система управління завданнями) еволюціонувала від використання в готелі до її сучасної форми. Спочатку створена для керування запитами в технічній компанії, TTS пройшла кілька змін, адаптуючись до змін у розмірах команд та технологіях. Тепер, будучи з відкритим кодом і з можливістю самостійного хостингу, я вважаю, що простота та гнучкість TTS роблять її кращим вибором, ніж існуючі платформи на ринку.
Перш ніж перейти до хронології, давайте почнемо з того, що таке TTS.
Якщо коротко, TTS — це організований список справ для кількох користувачів.
У 90-х роках я працював із готелями, і мені вдалося потрапити в "Операторську кімнату" одного готелю. Я побачив, як вони використовували програмне забезпечення, написане на Magic, щоб відстежувати запити від гостей. Оператор отримував телефонний дзвінок від кімнати з проханням принести рушник, і вона вводила запит у систему. Інший оператор або сама, після завершення дзвінка, викликали носіїв, щоб доставити рушник. Кожне завдання містило всю необхідну інформацію: номер кімнати, запит і час подачі запиту. Коли завдання було надіслано, запускався таймер, і завдання не закривалося, поки рушник не було доставлено. Ця система гарантувала, що все працює гладко і жоден запит не буде пропущений в бурхливу зміну оператора.
Через кілька років я перейшов до компанії в сфері високих технологій, де я відповідав за переведення веб-додатків компанії в продакшн. Спочатку запитів було мало, і ми були близькими, тому електронні листи та швидкі нагадування через перегородки дозволяли нам швидко вирішувати завдання.
Як кількість запитів зростала, ми найняли більше людей, і незабаром я очолив команду з 4 системних адміністраторів (те, що сьогодні називається DevOps).
Тепер запити надходили до різних людей, і було важко відстежувати, хто що робить, і гарантувати, що жоден запит не загубиться серед потоку електронних листів.
Під час навчання Unix я натрапив на цитату, яка нагадала мені програмне забезпечення, яке я бачив у готелі. Вона була такою:
"Спробуйте встановити формальний процес для запитів на зміни в системі та надання допомоги. Якщо користувачі очікують миттєвих відповідей, вони розчаруються, коли не зможуть отримати допомогу негайно. Налаштуйте систему електронної пошти або на основі веб-системи допомоги. Це може здатися клопіткою справою, але це дозволяє організувати ваш день і дає вам запис запитів. Ви коли-небудь забували допомогти комусь, тому що були надто зайняті? Налаштуйте автоматичний список справ, щоб цього уникнути."
Натхнений цією цитатою, я створив свою першу версію TTS, використовуючи ASP та MsSQL.
Наші розробники могли надсилати квитки до "Ticket master", який відслідковував їх і призначав іншим членам команди для обробки. Так ми могли відслідковувати всі запити та легко розподіляти завдання серед членів команди.
Після кількох місяців використання цієї системи луснула бульбашка DotCom, і наша команда почала зменшуватися. На той момент я назвав систему "PMS" (Система управління проектами), але вона швидко стала "TTS" 🙂 Вона дала нам не лише завдання, але й локальну базу знань, щоб побачити, як ми обробляли подібні квитки в минулому.
Ще однією перевагою TTS було те, що ми могли запускати статистику та бачити, скільки роботи ми маємо, які завдання є більш частими та витратними за часом.
Ми дізналися, що моя команда витрачає 80% часу на запуск десктопного додатку, який я написав, щоб створювати та запускати скрипти Robocopy для копіювання файлів з наших розробницьких серверів на продакшн-сервери.
З отриманими статистичними даними та необхідністю встигати за роботою з меншою командою, я попросив допомоги, щоб перевести десктопну програму на веб-додаток, який ми розробили самостійно. Цей веб-додаток дозволяв керівникам проектів планувати свої коміти до продакшн і ставити їх в чергу для перегляду та застосування нашою командою.
На жаль, та компанія оголосила про банкрутство, але TTS залишилася в пам'яті розробників та менеджерів, які використовували її щодня.
TTS навіть допомогла мені отримати роботу, показавши систему, що працює на моєму ноутбуці, під час співбесіди.
На той час я вивчав Linux, тому переніс код на PostgreSQL та PHP.
Цього разу TTS перетворилася на систему з шаблонами та міжвідділовим потоком квитків. Вона також мала складну політику, що контролювала, хто може що робити з квитками.
TTS працювала в цьому режимі майже 3 роки, обслуговуючи базу користувачів з 600 осіб.
Коли я пішов на нову пригоду, TTS залишилася позаду.
Двадцять років потому мені знадобилася система для призначення та відстеження завдань у моїй новій команді. Перший тиждень ми просто використовували спільну таблицю в Google Drive, але незабаром зрозуміли її обмеження.
Я вирішив, що пора дати TTS ще один шанс. За вихідні я переписав її з пам'яті, цього разу використовуючи Django — добре відомий Python фреймворк.
Ми перейшли на TTS, і тепер мій клієнт хоче використовувати її для всього бізнесу.
Чому TTS, а не інша платформа, що вже існує і відома на ринку?
Ну, для мене це тому, що:
- Вона з відкритим кодом
- Вона самохоститься
- Вона має малий код і легко налаштовується
- Вона слідує принципу KISS (keep it simple, stupid)
Як тільки я отримав стабільну версію, я виклав її на GitHub, і вона доступна для всіх. Просто перейдіть за посиланням https://github.com/meirm/ticket-tracking-system та клонувати її.
Якщо ви можете запустити Docker, то вам потрібно лише виконати кілька скриптів.
У наступній статті я покажу, як працює TTS і як її налаштувати.
Перекладено з: The journey of my Ticket Tracking System (TTS)