Хабрахабр

Байки про суровое российское ИТ и жертв цифровизации

Есть правильные практики, есть сто раз ощупанные грабли, но всё равно с завидным постоянством случается что-то эпическое. Россия иррациональна. Возможно, в генах. Иногда по причине: «Ну уж меня-то точно пронесёт», иногда: «Всегда так делали, и работало», иногда просто из-за ошибок.

Заказчик занимается капитальным строительством. Первый яркий пример невероятной дичи (детали немного изменены по требованию безопасников). Система была установлена на десятке немаленьких объектов, внедрена. Заказал несколько лет назад у подрядчика систему, которая управляет всем этим (в частности, сметными работами). Как оказалось, у их имеющегося подрядчика были планы на то, что они проведут разработку софта, а потом будут продавать результат как SaaS по рынку. Внезапно заказчик решил потребовать выдать ему исходный код. Поругались. В договоре про код ничего не сказано.

9 до 2. Когда позвали нас разбираться, там было примерно 10 разных версий ПО (релизы от 0. Есть исходники 1. 4). Документации нет. 5, эта версия собиралась когда-то из них. Посчитали «переписать всё заново» и «доработать 1. А систему надо дорабатывать и развивать. Научили собирать спецов поддержки, поправили исходники, свели кодовые базы, сделали инфраструктуру, организовали одну «разливочную», куда принимается исходник, там собирается и дистрибутируется. 5» и остановились на втором — TtM три-четыре месяца против года. Это стоило нам и заказчику большого количества геморроя.

Заходите, покажу ещё примерно то, как можно поошибаться с процессом разработки, и к каким интересным последствиям это приводит.

Ещё пример

Заказчик — тоже немаленькая компания — накатывает релизы ERP. А прикол в том, что система такая здоровая, что на полной базе или чём-то похожем её тестировать негде. Просто нет инфраструктуры. Точнее, есть, но нельзя сделать нагрузочный тест, только мелкие локальные вещи проверяются. Релиз встаёт — и никто не знает, как он себя поведёт на деле. Один раз всё знатно так упало, когда релиз повёл себя не так, как хотелось. В итоге позвали нас смотреть, что можно сделать. Мы обсудили, что они хотят посмотреть HP Perfomance Center, сделали пилот, потом интегрировали, обучили, поставили. Теперь релизы — через него. Эти нормированные операции тестируются, сводная аналитика по SLA по операциям.

Бизнес приходит к нам и говорит: нам наши айтишники сказали, что заменить базу Оракл на Постгресс очень сложно. Или вот у госзаказчика наступило импортозамещение. Две недели разбирательств — и результат: «Ну да, поменять базу несложно. Мы им не верим, проконсультируйте. Немного. Просто потом весь прикладной уровень придётся переписать. У вас огромные пакеты, нужно переносить слой бизнес-логики — и приехали. Примерно на 90%. Поверили ИТ-команде. Разработчиков, которые писали ядро, уже не найти, потому что системе восемь лет». Оказалось, просто недостаточно понятно аргументировали.

К счастью, этот ещё простой, там просто никто ничего пять лет не делал, и бизнес не федерального масштаба всё же. Где-то безопасность смотрим, вот эпический пример.

Идеальная ситуация: сторонний подрядчик пишет код, передаёт его на тестирование, проходит тесты, кладётся всё это в репозиторий, оттуда собирается и дистрибутируется. Следующий пример. Ставим ту же историю с приёмкой релизов. Красиво. Красиво? А вот у заказчика — «фонд алгоритмов и программ». Мы так внутри своей компании уже года три живём без исключений (до этого были не все отделы и команды). Они там тлеют. Туда каждый исполнитель отгружает болванку или распечатку исходного кода. И даже если де-факто код в фонде есть, то толку нет. Как оказалось в процессе аудита, на одну болванку вообще аниме записано.

Они сделали внутриотраслевого интегратора, они проверяют, что подрядчик приносит корректный софт. Другой похожий заказчик. У них типовая боль — много подрядчиков. В случае опенсорса ещё можно как-то заныкать проблему, но иногда попадаются и коммерческие библиотеки. Там проблемы были в том, что есть права третьих лиц (библиотеки опенсорса с вирусными открытыми лицензиями, например) — нечистоплотные подрядчики могут поставить всё это без лицензирования по порядку. Потом один их подрядчик ещё и обанкротился, а заказчику с этим кодом жить. Виноват кто будет — угадайте с трёх раз. Мы помогли настроить процесс правильно. Такие ситуации надо ловить на ранней стадии. Техническая документация, версии, исходники, договоры и все ссылки на тендеры. У нас есть решение типа автоматизации фонда алгоритмов и программ. При среднем сроке жизни ИТ-директора два-три года это очень помогает следующему разбираться сразу.

Почти каждый раз это начинается как модная история по цифровизации бизнеса. Ещё у нас в России внедряют аджайл. Я теперь в цирке не смеюсь. Но никто не понимает. Главное, все пытаются понять, что это за слова. Они говорят слова «кажется», «гипотеза», стартаперов приглашают, акселерацию мутят, смузи пьют — в общем, это всё имеет внешние признаки какой-то долины. Концепции заказывают, нанимают странных людей. Если делаешь серьёзную систему, надо её долго проверять. Потом аджайл начинают применять, а он не взлетает. А это всё обычно забывают. Если не поставить процессы, то спринты будут долгие (месяц-два), если ставить процессы, то нужно начинать с инфраструктуры тестирования, девопса, делать конвейер поставки, процессы работы между командами и внутри команд. В итоге потом нам разгребать и запускать. Если процессы старообрядческие — 98%, что проект не будет сделан. Но иногда просто хочется как-то объяснить, что ли, что ИТ — это сначала инфраструктура, а потом уже — быстрый TtM. В целом мы не жалуемся: тоже хлеб. А не наоборот.

Что обычно идёт не так? Набор примеров

Мы с коллегами собрали вот такой не очень объективный, но очень хорошо описывающий ситуацию набор ярких проблем. Понятное дело, мы ездим только туда, где плохо, и экстраполировать это на состояние отрасли не надо. Но всё же, уверен, вы узнаете что-то и от своей компании. Небольшую часть. В целом всё описывается словами: «неэффективность процессов, немотивированные сотрудники, плохие инструменты или плохо используемые инструменты». Ну а теперь — примеры.

Штраф за ошибки в ПО, внесённом разработчиками. 1.

Просто штраф за выявленные баги. Я даже не знаю, как это рационально описать. Естественно, любой релиз (даже мелкий) выпускается в десятки раз медленнее, чем мог бы. Живите теперь с этим знанием.

Собрания с утра до вечера. 2.

Он молчит и кивает головой в трубку. Разработчик должен на них присутствовать. Нельзя не прийти. Это те самые встречи, когда на совещании нужна вся проектная команда и плюс руководитель отдела, чтобы контролировать. Это традиционная ошибка руководителя проекта, называется «избыточный контроль». Но смысла от участия почти нет.

Карго-культ. 3. Берём гибкие методологии и жёстко их внедряем.

Только заставили разработчиков приходить на ежедневный стендап. Лучшее, что я видел: внедрили аджайл, но работали, как раньше. Это происходит изо дня в день. Они строятся и рассказывают: я ничего не сделал.

Инструменты: внедряем, чтобы отчитаться, что внедрены. 4.

«У нас внедрили хранилище бинарных сборок, а там очень маленький диск, надо удалять старые, и там только последние три версии». «У нас есть Continious Integration-сервер, а задачу может добавить только администратор». Так бэклог часто ведут даже в больших компаниях, при том, что есть и Jira. Или вот: система ведения задач в эксель-файле на пошареном диске. Он официальный. При этом пока задача не попадёт в этот файл, никто делать не будет.

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

Стандарты кодирования: написаны без понимания или не обновлялись 10 лет. 5.

В частности, всех сторонних библиотек. Просто пара примеров: требуем 100% покрытия кода тестами и документацией. Недавно видел, как инженер развернул систему, а пользователь не может войти, потому что ключ с теста на прод не поменяли. Обратная сторона — отсутствие стандартных тестов.

Он с перфокарт ещё учился. Ещё один раз видел, как руководитель писал код в Notepad.exe, потом кидал в компилятор без ошибок. Но только до тех пор, пока эта профдеформация не начинает влиять на стандарты для остального отдела разработки. Такой навык, конечно, заслуживает уважения.

Ошибки регламента. 6.

Это симптом. Например, фиксированное время обеда, которое выгуливается полностью. Объясняют: если ты на рабочем месте сидишь в обед, то ты мишень. Спрашиваю, почему. Должен отвечать на письма за пять минут и так далее.

Те же тестпланы на каждый чих. Излишняя бюрократизация: частое следование документированным процедурам, которое ведёт к куче бумаги. Обычно это решается примерами, а не полной детализацией. А это описание каждого фильтра, в том числе типы данных в каждом поле интерфейса, длина поля и так далее.

В одной компании не было человека с ответственностью за актуальный релиз, иногда срывались сроки по выпуску продуктов на две недели.

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

Борьба с безопасниками. 7.

Сюда входят ручные обновления всех систем (а надо автоматически разливать, это экономит кучу времени), физические обходы с флешкой по узлам сети, выделение портов по три недели и так далее.

Не налажены коммуникации между разработчиками и аналитиками. 8.

Просто аналитик написал, что нужно, разработчик разработал и через месяц показал готовое. Это настолько детский косяк, что повторяется на каждом пятом проекте. Три недели из этого месяца разработчик работал зря, хотя мог бы показать часть проекта, а аналитик мог бы поинтересоваться, как там дела. Аналитик бегает в ужасе, потому что он имел в виду не это. Есть методологии, которые это просто закрывают, но проблема в том, что в данной ситуации обе стороны не понимают, зачем нужен проект, и как он идёт.

Конференц-дривен девелопмент. 9.

Через три месяца повторили. Руководитель увидел что-то крутое на конференции, и это без оглядки внедрили. В итоге в отчёте красиво, а работа стоит.

На публичных отчётах — «Почти готово», и это бесконечно. Из-за внутренних конференций ещё бывает доведение до результата по схеме «Всегда на 80% готово». Почему? Доведение до 100% никогда не случается. Ну, например, смотрите пункт 1.

Читаешь статейку — вау, круто, давайте использовать, а потом только изучаешь, как. Отдельно отмечу недообследование сторонних систем. Мы тут сами наступили на грабли. И сталкиваешься с массой ограничений, потому что вендор мёд в уши лил только на первых двух встречах. ЦОДов для очень интересных объектов. Было внутреннее внедрение системы для интернет-магазинов документации по проектированию инфраструктур, в т.ч. Фишка в том, что по предметной области цены на единицу документа выше. Обнаружился кейс ограничения стоимости товара в 100 миллионов. И ожидаемое время индексации — один месяц. И там же система должна была перелопатить для поиска индекс, а у нас есть вложения по 1 гигабайту в документы. Вендор про такое не предупреждал.

Страшно вносить изменения. 10.

Но при этом ни тестов, ни документов, ничего нет. Есть такое состояние проекта: нужен рефакторинг, приходите через месяц. И разработчики сидят: «Мы боимся вносить изменения, мы боимся всё поломать».

Тестировщики тестируют на передачу данных сервисом (насколько можно). Ещё я видел, как в одной компании разработалась интеграция с системой, которую нельзя развернуть на стороне разработчика, потому что она очень тяжёлая. Правильная практика — сделать заглушку для этой системы, которая возвращала бы какие-то ответы. Выход на стенды заказчика перед сдачей — и ещё две недели доработок, потому что модель транзакций была неправильная. В итоге так и сделали, стало проще тестировать и принимать.

На том проекте мы дали некий псевдоязык-конструктор (набор стандартов), который потом конвертируется в данные аналитиков. Ещё заказчик может писать экономические описания на привычном ему языке. В духе «Если Ваня на больничном, то он не сможет пойти на производство».

Кто-то ещё в одной компании кодит прямо на проде. И финальный аккорд. Спасибо тебе, милый человек, но если я тебя найду, то даже не знаю, что с тобой сделаю. «Тут один маленький скриптик, я знаю, что делаю».

Если узнали свои проблемы — пишите в почту oeremeev@croc.ru. В общем, высказался. Если кому-то у вас из бизнеса надо объяснить, что с техдолгом мириться нельзя, — тоже пишите, мы умеем это нормально считать. У нас для крупного бизнеса есть почти бесплатные пилоты с экспресс-диагностикой (поиски бутылочных горлышек за 3-5 дней).

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть