Чтобы не стать историей, бизнесу необходимо идти в ногу с технологическим прогрессом. Так, важно внедрять элементы цифровизации во все внутренние процессы, однако многие до сих пор работают по старинке, вручную.
Александр Азаров, старший вице-президент по разработке ПО в WaveAccess, рассказывает, почему компаниям уже пора переходить на «цифру» и с чем им придется столкнуться на этом пути.
Отрасли российской экономики стремительно трансформируются, создаются новые амбициозные программы. «Цифровая экономика» разработана в 2017 году, ее цель – создать условия для системного развития и повсеместного внедрения digital-технологий. «Электронное правительство» оказывает услуги госорганам, бизнесу, обычным пользователям: документооборот между гражданами и органами власти переводится «в цифру», улучшаются системы поиска по государственным порталам.
Выполняя ИТ-проекты для регионально распределенных компаний в России, мы приобщились к этому прогрессу: занимались модернизацией федерального инвестпортала, создавали и интегрировали подсистемы и целые решения для портала Госуслуг РФ.
В частности, недавно мы участвовали в разработке мобильного приложения для сбора биометрических данных при проведении верификации пользователя в Единой биометрической системе. С его помощью можно дистанционно получать банковские услуги, авторизуясь путем сопоставления голоса и изображения лица с ранее созданным цифровым образом.
Но на пути цифровизации корпораций остаются препятствия: состояние инфраструктуры, сложные интеграции с существующими системами, объем работ (например, тестирования), необходимость использования только «разрешенного» стека технологий, зачастую – неготовность к цифровизации со стороны кадров и процессов заказчика.
Я хотел бы поделиться своим опытом и рассказать, почему бизнесу стоит решаться на обновления и что стоит учитывать, чтобы этапы разработки проходили гладко.
Возможности и преимущества перехода «в цифру»
У технологий машинного обучения (Machine Learning, ML) и искусственного интеллекта (AI), Интернета вещей (IoT), виртуальной и дополненной реальности (VR/AR) есть большой потенциал: автоматизация принятия простых решений освободит время дорогостоящих кадров, повысит оперативность, предсказание затратных событий сократит издержки.
Подобные системы имеют значение не только для повышения качества продукции, но и для безопасности: система позиционирования персонала, например, позволяет определять опасные зоны на производстве, отслеживать передвижения сотрудников и движущихся объектов в реальном времени, предотвращать несчастные случаи, анализировать эффективность работы на разных участках.
Благодаря IoT-системе для диспетчеризации промобъектов, инженеры могут удаленно следить за состоянием промышленных систем и обеспечивать прогностическое техобслуживание, что продлевает срок службы техники. Эта же технология позволяет специалистам выполнять большее количество задач.
Конечно, сохраняется большой пласт компаний, в которых с задачами справляются ручным способом и не видят смысла что-то менять. Но вряд ли кто-то устоит перед заметным снижением издержек. Тогда начинается процесс поиска подрядчика. Но я убежден, что грамотный проактивный менеджмент в решении задач по цифровизации процессов играет роль никак не меньшую, чем экспертные технические команды. Именно об управлении и расскажу в первую очередь.
Препятствия при цифровой трансформации
Одним из препятствий для успешного внедрения технологий может стать неготовность адаптировать корпоративную культуру к изменениям.
Еще встречается проблема недостаточно высокого уровня организации работы внутренней ИТ-службы и нехватки специалистов. А ведь для реализации высокотехнологичного проекта требуется вовлечение целого ряда профессионалов:
– архитекторов,
– дата-сайентистов,
– hardware-инженеров,
– QA-инженеров,
других специалистов с редкими компетенциями.
Лучше всего с проектом справится подрядчик, у которого в распоряжении достаточное число специалистов в разных областях программирования: от NET-разработчика до редкого ученого по данным.
На случай нехватки у заказчика специалистов для успешного старта проекта, подбора технологий или оценки сроков разработан подход «гибридных» команд.
Технические специалисты заказчика получают в свое распоряжение эксперта, который работает наравне с ними, буквально в одной команде, передавая знания и двигая проект. Когда он выполняет свою задачу, или если требуется другая редкая экспертиза, состав команды меняется. К этому подходу можно присмотреться, если не хватает толчка для продвижения проекта.
Я считаю, что заказчика нужно развивать, передавать ему свою экспертизу. Так общий уровень проектов будет повышаться.
Сюрприз часто ждет разработчиков при столкновении с трудовым распорядком заказчика. У многих ИТ-компаний – гибкий график. Крупные компании, далекие от ИТ, следуют более традиционному распорядку: например, начинают работу ровно в девять утра. А это дает два-три часа разницы во времени между заказчиком и исполнителем, даже если они находятся в одном городе.
Несложно догадаться, что будет, если прибавить к этому наличие у заказчика региональной технической команды, которая должна проверить релиз.
Центр тестирования клиента может вообще находиться в другой части России. Скажем, вы сдали релиз в 11:00 в четверг. У технической команды заказчика уже пять-шесть вечера – почти конец рабочего дня, а завтра – пятница. Но пятница, как известно, не лучший день для релиза. Хорошим тоном будет показать результат хотя бы в середине недели, давая заказчику люфт для ответа.
Порой требования безопасности кажутся нелогичными: скажем, команда заказчика уже протестировала релиз, но обязана оставить его «отлежаться» на три дня. Почему? Таков регламент тестирования.
Стандарты безопасности – это не только про защиту данных. Они могут замедлить темп цифровизации.
Многие компании хранят настолько ценные данные, что у них есть только внутренняя сеть, и передать им что-то онлайн совершенно невозможно. Релизы проходят в закрытой среде: продукт загружается на защищенный физический носитель, инсталлируется на территории заказчика.
Если при этом нужно присутствие исполнителя, то при определении сроков нужно закладывать еще несколько дней на получение пропуска на территорию. Впрочем, сегодня уже существуют и успешно применяются практики DevOps, которые могут решить часть этих проблем: например, непрерывная доставка обновлений.
Фраза, которая не может не вызвать стресс, – «у проекта есть скрытые требования». Это значит, что заказчик еще не решил, что ему нужно от определенной части проекта (какая технология, какая архитектура).
И если решение принимается уже в тот момент, когда та самая часть проекта готова (а такое случается), то предстоит значительный рефакторинг реализованных технологических решений без изменения сроков. К этому следует быть готовым:
– иметь дополнительные ресурсы,
– закладывать и оговаривать увеличение сроков,
– иметь грамотную команду DevOps, которая сможет реализовать непрерывную интеграцию, ускорить тестирование и передачу версий проекта заказчику.
Коммуникация между проектными командами
Мы нередко получаем проекты для восстановления после других команд, так и не подошедших к желанному релизу. И самая частая причина провала – непонимание подхода к планированию и разработке, а также завышенные ожидания.
Чтобы проект не превратился в подобие империи Александра Македонского, которая пережила распад из-за невозможности скоординировать регионы, нужно грамотно организовать общение.
Так, технические команды необходимо по максимуму освободить от поиска контактов, согласования звонков и прочей отвлекающей коммуникации: они должны получать конкретные задачи.
Часто на стороне клиента присутствует много компетентных специалистов, которые могут дать консультацию по использованию уникальных технологий, но не участвуют в проекте. Наше правило: разработчик не должен «ловить» спецов заказчика за счет своего рабочего времени.
Да, из-за этого менеджеру приходится вести десятки чатов с различными специалистами в разных мессенджерах, зато на выходе это дает один важный звонок тимлида с заказчиком и двигает проект вперед.
Зачастую проекты разваливаются из-за некорректных ожиданий: риск растет пропорционально количеству вовлеченных ЛПР (а их в крупных корпорациях может быть много).
У технологии машинного обучения на этот счет есть отличное решение: на этапе пилотной версии можно заранее, до масштабной разработки, увидеть потенциал технологии, а главное – буквально определить, сколько в денежном выражении принесет внедрение проекта.
Создав пилотную версию подобной системы, можно заранее увидеть ее потенциал именно в приложении к конкретной задаче. С учетом стоимости полноценного проекта около 15 миллионов рублей, выделить один-три миллиона на «пилот» означает вполне осознанное капиталовложение с предсказуемой отдачей (Return on Investment, ROI) и прогнозируемыми сроками.
Цепочка согласований
Чем крупнее компания, тем сложнее прохождение цепочки согласований, даже если задача – всего-навсего поправить слово на кнопке прототипа. Мы сталкивались и с тем, что согласование проектов у заказчика поручены отдельной службе, а некоторые проекты согласовывали несколько департаментов.
Есть и такой момент как согласование стека технологий. На одном из наших недавних проектов по компьютерному зрению согласование заняло три недели, включая время на формирование, обоснование, демонстрацию работы и проверку совместимости с существующими сервисами.
В дальнейшем свой регламент будет для большинства технических операций: открытие порта, получение доступа к базе данных, длительность тестирования.
Здесь важно обращать внимание разработчиков на регламенты команд заказчика и планировать время заранее так, чтобы его хватило на все согласования.
Производство большого объема документации
Время команды потребуется еще и на изучение специфики документации: мало того, что у нее большой объем, он дополняется не самыми прозрачными правилами оформления и нетривиальными задачами. Это значит, что на изучение этой специфики потребуется время. Кстати, документация зачастую требуется к каждой контрольной точке проекта.
Перед тем как погружаться в проект, нужно задать себе вопрос: а хватит ли у нас ресурсов, чтобы подготовить документацию? Ведь порой разработчиков на проекте может быть ровно столько же, сколько технических писателей!
Для релизов готовится несчетное количество графиков, таблиц, диаграмм взаимодействия, детальных описаний способов реализации, которые, как правило, требуются крупным корпорациям по ГОСТу и внутреннему регламенту.
Самый длинный список документации, что мы готовили, – порядка 16 развернутых документов к одному релизу.
Чтобы покрыть эту необходимость, команде нужны пишущие люди, хорошо разбирающиеся в своей части проекта.
Выводы
Управленческие ошибки зачастую ведут к гораздо более серьезным последствиям, нежели непонимание принципов работы той или иной технологии. Во многом успех цифровой трансформации зависит от грамотного планирования и своевременной корректировки завышенных или неверных ожиданий (расчет на мгновенный результат, ожидания по точности работы системы, ожидания по прибыли).
Мы уже более 19 лет работаем на рынке, в том числе выполняя масштабные проекты для российских заказчиков. В последнее время мы с удовольствием наблюдаем возросшее стремление к цифровизации среди крупных бизнесов. Это благотворно сказывается на уровне жизни, так как с продуктами и услугами таких компаний мы имеем дело почти каждый день.
