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