Михаил Протасов, М Про Системс
- Как легче поддерживать и развивать систему
- Как обеспечить стабильность работы
- Как проводить обновление без лишних усилий
- Что значит прозрачность и почему она важна
- Какие подходы ценят бизнес-заказчики
Как легче поддерживать и развивать систему
Одна компания (сеть магазинов) пригласила меня помочь им с такой задачей. Когда новый человек приходил в компанию, ему назначался трек обучения. Человек видел, какое обучение ему нужно пройти в первый день работы в магазине, во второй и так далее, когда тестирование сдать, когда с руководителем встретиться. Все было наглядно и прозрачно. Треки адаптации были разными для разных должностей: в торговом зале одно обучение, у кассира – другое. Функционально все было отлично. Была проблема, которая в тот момент казалась небольшой: небольшие изменения занимали достаточно много времени. Например, нужно один курс поменять на другой или добавить еще один день обучения, и такие правки требовали нескольких дней работы разработчика.
Я стал изучать исходный код и обнаружил множество проблем, которые привели к усложнениям.
- Во-первых, ничего не использовалось из стандартных возможностей платформы для этой задачи. Все было полностью сделано с нуля. Оказалось, что в самом начале хотели сэкономить на покупке лицензии. На мой взгляд, это анти-экономия, наоборот, таким образом компания гораздо больше денег потратила.
- Код не оптимален с точки зрения архитектуры. Такое иногда бывает: функционально все устраивает бизнес-заказчика, а под капотом большие проблемы. Без компетенций в IT-технологиях, в программировании, в архитектуре информационных решений их не увидеть и не понять. Какие там были проблемы? Информация о том, какой конкретно курс какой человек проходит в какой день, задублирована в разных местах (несколько шаблонов, несколько библиотек, несколько агентов). Получается, чтобы поменять информацию о том, какой курс человек проходит в определенный день, нужно зайти в кучу разных мест и везде это поправить. Сама структура кода сильно увеличивает трудозатраты.
В этой ситуации можно было либо продолжить развивать то, что есть, либо перейти на стандартную функциональность и частично отказаться от кастомизации. У каждого решения свои плюсы и минусы, заказчик выбрал перейти на стандартные механизмы адаптации.
Какие выводы стоит сделать из этого кейса, чтобы не попасть в похожую ситуацию? Я рекомендую соблюдать три принципа:
1 Баланс коробки и кастомных решений. Часто я вижу, что баланс перекошен в сторону кастома. Многие делают то, что в системе уже существует и настроено.
Кто-то говорит: в коробке есть баги, мы не хотим с этими ошибками сталкиваться, мы лучше сделаем что-то свое. Да, такое бывает, в стандартном функционале могут встречаться ошибки. Моя рекомендация: не отказываться совсем от стандартной функциональности.
- Время на разработку часто сильно недооценивают. Кажется, что кастомное решение можно сделать за один срок, а в действительности получается другой, гораздо больше.
- Кроме того, от ошибок никто не застрахован, и в кастомных решениях тоже могут возникать ошибки. С ошибками все равно нужно учиться работать.
- Если ошибка в стандартном функционале, то вы можете обратиться к вендору, они исправят ее и вам пришлют исправленное решение. Если вы платите за лицензию, то исправление ошибки не будет вам стоить дополнительных денег. Если ошибка в кастоме, придется править силами своих сотрудников или обращаться к подрядчикам.
Некоторые говорят, что в коробке некрасивый интерфейс или не совсем так бизнес-процесс выстроен. Здесь я рекомендую следовать такому принципу: использовать то, что устраивает в коробке, и кастомизировать только в тех составляющих, которые не устраивают. В коробке в новых версиях может появиться новая функциональность, которая может пригодиться. Можно использовать наработки и не тратить свое время, чтобы все заново сделать самостоятельно.
2. Аудит архитектуры и кода. Важно, чтобы был кто-то, кто перепроверяет – насколько качественный код. Нужно смотреть не только функциональность, но и погружаться в код. Кто может это делать?
- Кто-то в штате вашей компании – сотрудник, который достаточно компетентен.
- Это может быть и подрядчик. Можно обратиться к подрядчику проверить код внутреннего сотрудника или другого подрядчика. Это нормальная практика, она не говорит о недоверии или о непрофессионализме кого-то из разработчиков. Это разумный принцип: лучше, чтобы несколько экспертов подтвердили одно и то же решение. У нас в компании есть проекты, где мы проводим аудит, а есть проекты, где нас аудируют. А внутри в своейкоманде мы проводим и внутренний аудит – одна команда делает проект, а другая команда проверяет.
3. Команда поддержки. В нашем кейсе сотрудник работал один, и он единственный понимал, что и как работает. В какой-то момент он уволился, и возникла сложность. Важно, чтобы у вас было несколько человек, которые понимают, как все работает. Как минимум двое. Я вообще не рекомендую стартовать внутреннюю разработку, если у вас только один разработчик. Хорошо, если у вас есть и внутренние разработчики, и подрядчик тоже. Хорошо, когда у вас одновременно есть подрядчик, которому вы можете отдавать заказы – может быть, и небольшие заказы, но регулярно. Тогда в сложной ситуации у вас будет к кому обратиться за поддержкой.
Как обеспечить стабильность работы
Однажды клиент (пищевое производство) обратился ко мне с такой ситуацией. Долгие годы работали с одним и тем же подрядчиком, развивали свою систему, сделали очень много кастомизаций, переписали все пользовательские интерфейсы, переписали много всего в бэкенде. Был довольны тем, как все идет, но в какой-то момент возникло несколько проблем. Каких?
- Стало появляться гораздо больше багов, как в новых процессах, так и в старых. И баги стали появляться в том числе в критически важных бизнес-процессах. Это грозило очень неприятными последствиями, например, по обучению было много процессов, связанных с госрегулированием – какое должно быть обучение, какой должна быть отчетность по нему.
- Время и на правку этих багов, и на внедрение какой-то новой функциональности тоже увеличилось. Причем не только на правку багов, но и на внедрение новой функциональности.
- Подрядчик предупредил, что он планирует постепенно отказываться от оказания услуг в этой области.
Необходимо было перенять все процессы у прежнего подрядчика, разобраться со сложностями и развивать систему дальше.
Решение.
Прежде всего я спросил, есть ли техническая документация – описание, что конкретно делали и как это устроено в системе, какие объекты используются, какие настройки выполнены, какие еще можно выполнять при администрировании процессов. Документация оказалась неполной. Некоторые процессы вовсе не были отражены, в некоторых были пропущенные места.
Я предложил провести в качестве первого шага короткий базовый аудит – проверить по наиболее важным процессам, насколько они отражены в документации.
После такого аудита выяснилось, что из всех кастомизаций документировано порядка 30%.
Следующий шаг – мы провели более объемный аудит (он занял от 50 до 100 часов), в ходе которого мы восполнили документацию по недостающим 70%.
Какие выводы дает возможность сделать этот кейс?
Много кастомизаций – усложняется процесс поддержки системы. В том месте, где больше всего болело, мы предложили перейти со стопроцентной кастомизации на уровень «50 на 50»: 50% использовать из коробки, 50% кастомизировать. Это и сделали, и это помогло избавиться от багов в наиболее значимых процессах.
Нужна команда поддержки. Должен быть еще кто-то, кроме одного единственного подрядчика/разработчика, кто понимает, как все работает.
Важно следить за тем, как описывается все то, что разработано. Важно разбирать полноту документации. Для этого можно заказывать аудит документации.
Как проводить обновление без лишних усилий
Однажды нам снова довелось перенимать проект у предыдущего подрядчика. В этом кейсе клиент обратился ко мне с тем, чтобы обновиться на новую версию. Их версия устарела уже на несколько лет, было выполнено очень много кастомизаций, а предыдущий подрядчик затруднился оценить объем и сложность работ и предлагал оставить все как есть, не обновляться. Я с таким подходом не согласен, наоборот – рекомендую как раз пользоваться последними версиями любых систем.
Длительная эксплуатация старых версий приводит к проблемам:
Безопасность. В любых системах есть уязвимости. Они находятся, вендор выпускает новые версии и закрывает эти уязвимости. После обновления ваша система становится более безопасной. Если вы пользуетесь старой версией, то злоумышленник может взломать систему. Многим кажется, что их это не коснется: нас ни разу не ломали, кому мы нужны. Но так кажется до первого взлома. Я рекомендую его не дожидаться.
Баги. В новых версиях выпускают исправление багов.
Устаревание функциональности. В новых версиях новая функциональность. Кто-то этим пренебрегает, на мой взгляд – зря. Я рекомендую смотреть, что новое добавляется, чтобы как раз формировать баланс коробки и кастома. Готовые решения позволяют быстрее внедрять новую функциональность.
Несовместимость. Выходят новые версии различного софта, не только системы, с которой вы работаете, – операционных систем, баз данных, браузеров, мобильных телефонов. Если ваша система заточена под устаревшие браузеры, устаревшие базы данных, начнутся проблемы с пользователями или с инфраструктурой. Например, потребовалось обновить базу данных, а это невозможно. Система не умеет работать с новой версией. Или в браузере перестала работать какая-то функциональность, а в старой системе она использовалась, и в новых браузерах у людей что-то не работает. Использовать старую версию браузера неудобно. Нужно обновляться, чтобы не отставать от всех остальных технологий, чтобы не возникало проблем с совместимостью и чтобы это не создавать сложностей в администрировании и в работе пользователей.
Многие говорят, что обновляться это сложно и занимает много времени. Но если качественно выстроить процессы, качественно вести разработку, то обновление не такой сложный процесс, за 2-4 недели можно обновлять систему регулярно: неделю на тестовом сервере, проверить поправить ошибки, потом запланировать регламентные работы, и в течение еще одной недели провести обновление на продуктивном сервере.
В кейсе мы предложили несколько вариантов решения задачи. Опишу тот, на котором остановились. Мы развернули тестовый сервер и его обновили до последней версии. После этого стали искать, что сломалось. Поломки, которые находили, исправляли. Когда все нашли и исправили – начали обновлять основной сервер. Первый этап занял около 60 часов, на второй мы заложили около 40 часов и в итоге все обновили. Даже в сложной ситуации можно найти выход – да, возможно, нужно будет потратить какое-то время, но при этом создать себе задел на будущее, чтобы следующие обновления проходили легче и быстрее.
Дополнение, а не редактирование коробки
Что заняло большую часть времени в этом проекте? Когда разработчик дорабатывает систему, вместо того чтобы скопировать какую-то стандартную функциональность и дальше скорректировать скопированное, он вносит изменения прямо в стандартную функциональность. Это неправильно. Важно не редактировать стандартную функциональность, а дополнять ее. Сначала сделать копию и править уже копию.
В этом проекте мы большую часть времени занимались тем, что находили, где внесены правки в стандартную функциональность, откатывали эти правки обратно, делали копию и эти правки вносили в скопированную функциональность. Подавляющее большинство ошибок, возникающих при обновлении, были связаны с этим. Все такие случаи мы искали и вычищали.
В любой момент у вас должна оставаться возможность вернуться к стандартной функциональности. Это помогает при обновлении – во первых, меньше ошибок, во-вторых, можно быстро понять, где ошибка, если она возникла – в стандартной функциональности или в ваших доработках.
Что значит прозрачность и почему она важна
Мы вели переговоры с потенциальным клиентом, у которого была очень интересная ситуация. Штатный разработчик уволился из компании. И с платформой стали происходить неожиданные и странные вещи. То рассылка уйдет на всю компанию, то на главной странице появится какой-то новый шаблон. В компании уже не знали, что портал еще может выкинуть, что еще может произойти.
Что делать, чтобы с вами такого не случилось?
Нужно соблюдать те принципы, которые уже назвали. И есть еще ценный совет: в момент проведения работ делать регулярные демонстрации: регулярно бизнес-заказчику показывать, что разработали (еженедельно или раз в две недели, раз в месяц – реже не рекомендую). Эти демонстрации записывать на видео и хранить видеозаписи. Это не заменяет документацию, но в ряде случаев облегчает ситуацию. Наличие демонстраций, где разработчик показывает, что он сделал, сильно облегчает работу, обеспечивает бОльшую прозрачность как на время проекта, так и потом при возникновении вопросов после завершения проекта.
Какие подходы ценят бизнес-заказчики
Я спрашивал наших клиентов, что для них важно в наших проектах, и фиксировал то, что разные компании чаще всего упоминают.
Что оказалось важным?
Гибкость. У заказчика могут возникнуть изменения, может оказаться, что не все на старте предусмотрели. Гибкость означает, не действуете по жестко раз и навсегда заданному техническому заданию, а можете договориться, что в этом случае будете делать, что готовы пересмотреть и поменять.
Прозрачность. Всем понятно, что происходит в проекте, какой статус по тем или иным задачам, как работает функциональность.
Человеческий подход. Это атмосфера сотрудничества, а не соперничества, а еще инициатива и предложение различных вариантов со стороны исполнителя. Когда исполнитель вникает, разбирается, пытается понять глубже и сам предлагает, как можно реализовать задачу разными способами.