Несколько лет активно идет процесс интеграции SHLTOOLS 4.0 с разными системами разных заказчиков, а значит — взаимодействие с IT-командами заказчиков или их подрядчиков. Опыт показывает, что для успешной реализации проектов нужны не просто айтишники с какими-то знаниями, а разные виды айтишников. IT-директор Рубен Арутюнян рассказывает три реальных истории, чтобы показать, насколько важен точный подбор IT-специалистов.
История первая
Когда только вышла версия ST4, мы настроили доступ одному крупному заказчику, все проверили, все работало прекрасно. Через неделю этот заказчик вернулся с вопросом: через 2 недели нужно будет за 34 часа прогнать через два теста 80 000 человек, система выдержит? Я ответил, что выдержит, почти не задумываясь.
Заказчик фактически попросил нас увеличить производительность в несколько раз по сравнению с тем, о чем договаривались на старте и считали достаточным. А у нас на тот момент таких нагрузок еще никогда не было. Предстояло не только проверить, что система будет достаточно быстро выдавать результаты тестов, но и обеспечить круглосуточную техподдержку всего процесса. Было сложно, но мы в итоге успешно реализовали этот проект.
Мои коллеги, которые отвечали за инфраструктурное обеспечение, потом признались, что на моем месте не решились бы взяться за эту задачу. Они отличные специалисты, но оба люди достаточно пессимистичные, всегда ожидают худшего, поэтому всегда четко следят, чтобы все всегда работало, решают проблемы до их появления и не склонны рисковать. Но возможность реализовать такой масштабный проект они бы упустили. Поэтому так важно диагностировать виды айтишников при найме.
Проект был срочный, мы придумали решение и увеличили производительность, пришлось также адаптировать инфраструктуру. С этим помог подрядчик заказчика, хотя он не очень верил, что мы успеем развернуть все в срок. С нами работали очень профессиональные люди, делали все оперативно. Это второй критерий отбора айтишников — готовность качественно работать в жестких временных рамках. Иногда приходится, как на этом проекте, делать что-то 36 часов подряд, на скорость проводить нагрузочное тестирование, иногда докручивать что-то уже в процессе.
Айтишник должен быть готов к риску и понимать: при шансе 5%, что все «упадет», нужно собраться и просто сделать свою работу.
Профессиональные навыки и знания — это прекрасно, но хороший результат в срочном проекте будет только при условии, что специалист может сделать большой объем работы в сжатые сроки и не «развалиться» в процессе. Есть айтишники другого склада, которые сделают так же хорошо, но за три месяца при графике с 9 до 18, они со своим подходом нужны для решения других задач.
Это был, пожалуй, единственный очень стрессовый технологически сложный проект для нашей команды. Благодаря ему мы поняли, что можем делать практически все и практически в любые сроки, если надо.
Как IT-директор я тогда в очередной раз убедился, насколько важно понимать, с кем ты работаешь.
Зная, что может делать, а то что не может делать каждый из членов команды, проще распределять обязанности и прогнозировать результаты. Гораздо лучше узнать про особенности поведения своих сотрудников в стрессовых ситуациях заранее (из тестов и опросников), чем в ходе критически важного и срочного проекта.
История вторая
Однажды мы делали интеграцию систем для очень большой компании и столкнулись с целым букетом разных граблей. У них были большие объемы людей, много подразделений и невероятно сложная оргструктура. Финансовые взаимодействиями между частями этой компании тоже были довольно сложными. Не буду подробно рассказывать и о юридических дебрях, через которые пришлось продираться. Пожалуй, проще всего было выстроить взаимодействие со службой безопасности. Они выдали список требований, которые мы должны были учесть. И отдельный вызов — разные часовые пояса с командой разработки заказчика. К этому пришлось адаптироваться, они начинали отправлять запросы в 6 утра по Москве. В проект было вовлечено много людей со стороны заказчика, мы начинали взаимодействие в формате zoom-встреч на 12 человек. Если на встречу не приходил человек, владеющий информацией по обсуждаемому вопросу, приходилось откладывать решение на потом, тормозился весь процесс.
В ходе реализации проекта удалось «победить» не все перечисленные проблемы. Юридические документы оформили так, как требовал заказчик. Служба безопасности проверила выполнение требований и больше не задавала вопросов. Самым сложным оказался процесс выстраивания взаимодействия с представителями заказчика.
Сначала мы начали переписываться с программистами заказчика, приходилось ставить в копию большое количество людей, всем было не очень удобно. Потом я предложил срочные вопросы задавать мне через Телеграм. Потом там появился чат на двух программистов и начал расти, туда пришли руководитель программистов, руководитель проекта и многие другие. Этот процесс закономерно повлиял на частоту встреч в zoom. Многие вопросы решались в чате, не было смысла выносить их на встречу. Количество участников zoom-встреч тоже стало уменьшаться, пока в итоге встречи не прекратились совсем.
Телеграм стал инструментом, который всем экономил время. Повысилась скорость взаимодействия, скорость реакции, в чате сразу всем видно, что проблема решена.
И я могу сказать, что переписка в мессенджере по техническим вопросам удобна еще и тем, что можно в любой момент посмотреть историю: кто и когда писал, кто кому отвечал. Так были «побеждены» совещания.
Общий чат с проедставителями заказчика решил еще одну проблему. Когда подразделений много, информация довольно долго идет, люди находятся на разных стадиях понимания того что происходит. Поначалу и в нашем проекте так было: мы с программистами уже решаем проблему, а другое подразеление только звонит аккаунт-менеджеру, чтобы о ней сообщить. В чате все участники процесса могли видеть одну и ту же информацию одновременно, многие вопросы отпали сами собой.
История третья
В одном проекте по интеграции мы работали исключительно с подрядчиком нашего заказчика. Заказчик был крупный, пришел с запросом «у вас всего две недели», но на этот раз проблема была не в срочности запроса.
Во-первых, на старте нашего проекта они поменяли своего программиста, который уже практически все сделал, но решил уйти в другую компанию. Нам достался новый специалист, которому было поручено все доделать за первым. Это привело к проблемам.
Во-вторых, как же хорошо, что после первых больших интеграционных проектов мои пессимистичные коллеги разработали наш собственный инструмент, с помощью которого можно выгрузить все данные по любому проекту, если со стороны клиента что-то пошло не так. У нас был универсальный «План Б» на тот случай, если вдруг на стороне заказчика, например, все сервера упадут, и в этом проекте такой план понадобился. В какой-то момент программист ошибся и поставил системе цикличную задачу, сначала она делала один запрос в минуту, потом два, потом три, а потом дошло и до трех запросов в секунду, лавина запросов перестала обрабатываться. Интегратор не отследил проблему, а мы увидели, что эта проблема не на стороне системы, и оперативно отключили клиента. При этом пользователи продолжали проходить тесты, переходить по ссылкам.
Интегратор устранил проблему буквально за 1,5 минуты, выгруженную информацию мы оперативно передали, пользователи ничего не заметили и получили свои отчеты. А мы с командой сделали вывод, что та часть процесса интеграции, которую мы не контролируем, в любой момент может «сломаться», на случай проблем с инфраструктурой нужен «План Б». Подготовили его мои коллеги, которые привыкли решать проблемы до их появления.
Желаю всем IT-директорам научиться набирать программистов и технических специалистов под разные задачи. Не стоит забывать, что менеджеры проектов, системные администраторы и служба техподдержки тоже важны для успеха вашей команды. Перечитайте наши истории и не повторяйте наших ошибок.
***
27 апреля в 11:00 состоится вебинар «HR и IT: осмысленная автоматизация». Рубен Арутюнян, руководитель IT департамента, и Мария Лапикова, менеджер по программным продуктам, расскажут о своем видении оценки в современном мире, представят возможности SHLTOOLS 4.0.
