Два года в небольшой веб-студии Тбилиси дали студенту дорожностроительной специальности больше прикладных навыков, чем формальная программа по IT могла бы дать за тот же срок. История разработчика, работавшего в Integrals с 2016 по 2018 год, — не инструкция по возвращению к FTP и zip-архивам, а довольно точный снимок того, как практика веб-разработки превращает новичка в инженера, способного разговаривать с клиентом, оценивать задачу и отвечать за результат. Об этом сообщает Habr / Карьера.
Автор оригинального текста Giorgi Mgebrishvili пришёл в студию без классического IT-бэкграунда. Он учился в Грузинском техническом университете на направлении, связанном со строительством дорог, улиц и железных дорог, параллельно самостоятельно писал код и решил найти первую оплачиваемую работу. Резюме и портфолио у него не потребовали: знакомый пригласил кандидата в офис Integrals на проспекте Руставели и выдал тестовое задание — многоязычный сайт для магазина косметики с блогом, статьями и фотогалереей. Готовый проект устроил студию, после чего вчерашний самоучка оказался в команде.
Формально он начинал с поддержки, но в микрокоманде должностные ярлыки живут недолго. В Integrals работали два разработчика, которых называли бэкендерами, хотя оба брали задачи по всему стеку; дизайнер, совмещавшая дизайн и вёрстку; помощник с уклоном во фронтенд; и сам автор. Фиксированного оклада не было: платили за проект. Для студента с экзаменами это оказалось удобнее стандартной офисной схемы, а для команды — способом подключать человека к задачам по мере появления работы.
Студия продавала три базовых типа проектов: персональные сайты, многостраничные сайты с несколькими языками и галереями, а также интернет-магазины с каталогом и банковской оплатой. Клиентами были гостиницы, туроператоры, рестораны, магазины и частные заказчики. За два года автор поучаствовал в десятках работ: где-то сайт создавали с нуля, где-то приходилось исправлять ошибки, рефакторить код или разбираться с наследием предыдущего разработчика. Для начинающего специалиста это полезнее идеально выстроенной учебной задачи: продакшен быстро объясняет, что «сделать страницу» и «поддерживать сайт после запуска» — разные дисциплины.
Переводчик требований, а не только кода
Сильный английский определил ещё одну роль автора. Иностранные клиенты, в том числе предприниматели с Ближнего Востока, часто общались со студией через него. Встречи проходили не только в офисе: обсуждать будущие сайты могли в ресторане клиента, кафе быстрого питания, автомобиле или саду. Владельцы Integrals вели переговоры, а разработчик переводил разговор о цветах, логотипах, страницах, языках и нужных функциях. Это важная деталь для любой аутсорсинговой команды: требования теряются не в момент написания кода, а значительно раньше — когда участники встречи используют одинаковые слова в разном значении.
Один из эпизодов хорошо иллюстрирует проблему. Во время разговора владелец студии несколько раз спрашивал, как перевести грузинское слово со значением «показывать». Услышав ответ show, он переспрашивал вновь: для него show было знакомым существительным — «шоу», а не глаголом. Комический случай закончился быстро, но для разработки это вполне рабочий риск. Если команда не фиксирует смысл терминов, клиент может получить не ту демонстрацию, не тот экран и не ту бизнес-логику. На проектах без аналитика разработчик нередко становится последней линией защиты от такого расхождения.
Техническая сторона Integrals была предельно прагматичной: чистый PHP на сервере, HTML, CSS и Bootstrap на клиенте. Дизайнер брала бесплатный шаблон и адаптировала его под фирменные цвета и логотип заказчика. Git в процессе не использовали: исходники пересылали через Skype в zip-архивах, а изменения на работающих сайтах заливали по FTP. По нынешним стандартам такой процесс выглядит как набор предупреждений из курса по DevOps, но он отражает реальность многих небольших студий середины 2010-х. Риски частично снижались организационно: разные люди редко одновременно меняли один проект или тем более один файл.
Что из старого процесса всё ещё работает
В этой среде автор сделал два заметных для команды решения. Первое — переиспользуемую административную панель на чистом PHP, которую можно было подключать к разным сайтам вместо разработки управления контентом с нуля. По сути, это была компактная собственная альтернатива CMS для типовых задач. Второе — применение AJAX, чтобы пользователь мог получать обновления без полной перезагрузки страницы. Ни один из подходов сам по себе не был технологическим прорывом уже в 2016 году, зато оба снижали стоимость повторяющейся работы и улучшали пользовательский сценарий. Именно такие небольшие инженерные улучшения чаще всего и дают студии запас времени на следующий проект.
Большую часть задач Mgebrishvili выполнял удалённо: сначала из Гори, затем из дома в Тбилиси. Коммуникация шла через Skype и телефон, а личные визиты были нужны для офиса и встреч с заказчиками. Не было общего репозитория, ежедневных синков и привычного сегодня набора инструментов управления задачами. Была договорённость о результате и сроке. Этот опыт особенно узнаваем для русскоязычных команд: удалённая работа не создаётся календарём созвонов, она держится на ясной постановке, доступности исполнителя и понятной ответственности за сдачу.
В 2018 году автор перешёл в коммерческий банк, выбрав более формальную занятость с постоянным договором и другой инженерной средой. Но связь со студией сохранилась: позднее он помогал бывшим коллегам с переводом на встрече и JavaScript-задачей для календарного бронирования, а в 2021 году порекомендовал Integrals для переписывания старого сайта о Грузии. Главный вывод этой истории не в том, что нужно отказаться от Git, процессов или профильного образования. Скорее, практика веб-разработки остаётся ускорителем карьеры там, где у новичка есть реальные пользователи, дедлайн и право ошибиться ровно один раз — до запуска сайта у клиента.