#успехи_и_неуспехи_автоматизации

На одном из вебинаров мы с нашим коллегой и партнером Михаилом Протасовым разобрали, чему могут научить неудачи в HR-автоматизации. Продолжаем делиться успешными и неуспешными кейсами с этого вебинара, рассматривая их с точки зрения главных принципов автоматизации: целеполагание, возможность доработок, интеграция, устойчивость, agile и сохранение компетенций.

Устойчивость

❌ История неудачи

В одной компании не меньше четырех раз за десять лет полностью меняли систему для автоматизации HR-процессов. Каждый раз все переделывалось заново с нуля, а прошлые наработки терялись. Дважды шли по пути собственной разработки, но каждый раз забрасывали.

✔️ История успеха

"Это было достаточно давно, и сейчас за этот проект я испытываю одновременно и гордость, и стыд, – признается Михаил Протасов. – Стыд – потому что это был один из первых проектов, которые я вел как фрилансер, и там было довольно много неудач. Но проект был все-таки реализован и доведен до конца. Спустя несколько лет ко мне опять обратился этот же заказчик и попросил сделать некоторые доработки. Тогда я все же испытал некоторую гордость. То, что я сделал (хоть и были сложности во взаимодействии), потом точно служило этой организации несколько лет. И я рад, что получилось создать такую устойчивую систему".

На что Михаил Протасов рекомендует обращать внимание?

Когда у вас стартует проект по автоматизации, подумайте, насколько он будет устойчивым, насколько эффективными будут инвестиции, которые вы вкладываете сейчас. Для этого смотрите на следующее:

1️⃣ Максимум готовых решений

Чем больше используете готовых наработок, тем устойчивее будет ваш проект. Доработки лучше вести точечно в местах, где есть несоответствия вашим бизнес-процессам.

2️⃣ Минимум технологий

Есть заказчик (руководитель подразделения или HR), есть IT-департамент и есть внешний подрядчик. Бизнес-заказчик часто не обращает внимания, какие технологии будут использованы в доработке системы, но это надо делать. Чем меньше разнообразие технологий, тем проще вам будет в дальнейшем найти людей, которые смогут поддерживать систему.

3️⃣ Качество кода и архитектуры

HR-специалисту сложно оценить качество кода и архитектуры, но IT нужно это всегда учитывать. Какими могут быть последствия некачественного кода? Возможная доработка потребует гораздо больше времени. Это же касается поддержки: то, сколько времени понадобится, чтобы найти причину поломки, зависит от качества кода и качества архитектуры.

Что можно сделать?

📌 Найти того, кто будет перепроверять. Есть такая практика — code rewiew: один разработчик написал, а другой, независимый, оценили или предложил доработки. С такой практикой устойчивость разработки резко возрастает.
📌 Сохранять имеющиеся разработки. Очень часто программисты хотят все переделать. Это распространенное и понятное желание, но все-таки более опытные разработчики стоят за то, чтобы максимально сохранять сделанное, чтобы не тратить лишних ресурсов и не терять накопленный опыт. Даже если старый код кривой – возможно, он решает прежнюю ошибку, если переделывать все с нуля – есть вероятность повторно наступить на те же самые грабли.

Ищите все посты на эту тему по тегу #успехи_и_неуспехи_автоматизации. Также вы можете найти оглавление в закрепленных постах.