Россия иррациональна. Есть правильные практики, есть сто раз ощупанные грабли, но всё равно с завидным постоянством случается что-то эпическое. Иногда по причине: «Ну уж меня-то точно пронесёт», иногда: «Всегда так делали, и работало», иногда просто из-за ошибок. Возможно, в генах.
Первый яркий пример невероятной дичи (детали немного изменены по требованию безопасников). Заказчик занимается капитальным строительством. Заказал несколько лет назад у подрядчика систему, которая управляет всем этим (в частности, сметными работами). Система была установлена на десятке немаленьких объектов, внедрена. Внезапно заказчик решил потребовать выдать ему исходный код. Как оказалось, у их имеющегося подрядчика были планы на то, что они проведут разработку софта, а потом будут продавать результат как SaaS по рынку. В договоре про код ничего не сказано. Поругались.
Когда позвали нас разбираться, там было примерно 10 разных версий ПО (релизы от 0.9 до 2.4). Есть исходники 1.5, эта версия собиралась когда-то из них. Документации нет. А систему надо дорабатывать и развивать. Посчитали «переписать всё заново» и «доработать 1.5» и остановились на втором — TtM три-четыре месяца против года. Научили собирать спецов поддержки, поправили исходники, свели кодовые базы, сделали инфраструктуру, организовали одну «разливочную», куда принимается исходник, там собирается и дистрибутируется. Это стоило нам и заказчику большого количества геморроя.
Заходите, покажу ещё примерно то, как можно поошибаться с процессом разработки, и к каким интересным последствиям это приводит.
Ещё пример
Заказчик — тоже немаленькая компания — накатывает релизы ERP. А прикол в том, что система такая здоровая, что на полной базе или чём-то похожем её тестировать негде. Просто нет инфраструктуры. Точнее, есть, но нельзя сделать нагрузочный тест, только мелкие локальные вещи проверяются. Релиз встаёт — и никто не знает, как он себя поведёт на деле. Один раз всё знатно так упало, когда релиз повёл себя не так, как хотелось. В итоге позвали нас смотреть, что можно сделать. Мы обсудили, что они хотят посмотреть HP Perfomance Center, сделали пилот, потом интегрировали, обучили, поставили. Теперь релизы — через него. Эти нормированные операции тестируются, сводная аналитика по SLA по операциям.
Или вот наступило импортозамещение. Бизнес приходит к нам и говорит: нам наши айтишники сказали, что заменить базу Оракл на Постгресс очень сложно. Мы им не верим, проконсультируйте. Две недели разбирательств — и результат: «Ну да, поменять базу несложно. Просто потом весь прикладной уровень придётся переписать. Немного. Примерно на 90%. У вас огромные пакеты, нужно переносить слой бизнес-логики — и приехали. Разработчиков, которые писали ядро, уже не найти, потому что системе восемь лет». Поверили ИТ-команде. Оказалось, просто недостаточно понятно аргументировали.
Где-то безопасность смотрим, вот эпический пример. К счастью, этот ещё простой, там просто никто ничего пять лет не делал, и бизнес не федерального масштаба всё же.
Следующий пример. Ставим ту же историю с приёмкой релизов. Идеальная ситуация: сторонний подрядчик пишет код, передаёт его на тестирование, проходит тесты, кладётся всё это в репозиторий, оттуда собирается и дистрибутируется. Красиво? Красиво. Мы так внутри своей компании уже года три живём без исключений (до этого были не все отделы и команды). А вот у заказчика — «фонд алгоритмов и программ». Туда каждый исполнитель отгружает болванку или распечатку исходного кода. Они там тлеют. Как оказалось в процессе аудита, на одну болванку вообще аниме записано. И даже если де-факто код в фонде есть, то толку нет.
Другой похожий заказчик. У них типовая боль — много подрядчиков. Они сделали внутриотраслевого интегратора, они проверяют, что подрядчик приносит корректный софт. Там проблемы были в том, что есть права третьих лиц (библиотеки опенсорса с вирусными открытыми лицензиями, например) — нечистоплотные подрядчики могут поставить всё это без лицензирования по порядку. В случае опенсорса ещё можно как-то заныкать проблему, но иногда попадаются и коммерческие библиотеки. Виноват кто будет — угадайте с трёх раз. Потом один их подрядчик ещё и обанкротился, а заказчику с этим кодом жить. Такие ситуации надо ловить на ранней стадии. Мы помогли настроить процесс правильно. У нас есть решение типа автоматизации фонда алгоритмов и программ. Техническая документация, версии, исходники, договоры и все ссылки на тендеры. При среднем сроке жизни ИТ-директора два-три года это очень помогает следующему разбираться сразу.
Ещё у нас в России внедряют аджайл. Я теперь в цирке не смеюсь. Почти каждый раз это начинается как модная история по цифровизации бизнеса. Главное, все пытаются понять, что это за слова. Но никто не понимает. Концепции заказывают, нанимают странных людей. Они говорят слова «кажется», «гипотеза», стартаперов приглашают, акселерацию мутят, смузи пьют — в общем, это всё имеет внешние признаки какой-то долины. Потом аджайл начинают применять, а он не взлетает. Если делаешь серьёзную систему, надо её долго проверять. Если не поставить процессы, то спринты будут долгие (месяц-два), если ставить процессы, то нужно начинать с инфраструктуры тестирования, девопса, делать конвейер поставки, процессы работы между командами и внутри команд. А это всё обычно забывают. Если процессы старообрядческие — 98%, что проект не будет сделан. В итоге потом нам разгребать и запускать. В целом мы не жалуемся: тоже хлеб. Но иногда просто хочется как-то объяснить, что ли, что ИТ — это сначала инфраструктура, а потом уже — быстрый TtM. А не наоборот.
Что обычно идёт не так? Набор примеров
Мы с коллегами собрали вот такой не очень объективный, но очень хорошо описывающий ситуацию набор ярких проблем. Понятное дело, мы ездим только туда, где плохо, и экстраполировать это на состояние отрасли не надо. Но всё же, уверен, вы узнаете что-то и от своей компании. Небольшую часть. В целом всё описывается словами: «неэффективность процессов, немотивированные сотрудники, плохие инструменты или плохо используемые инструменты». Ну а теперь — примеры.
1. Штраф за ошибки в ПО, внесённом разработчиками.
Я даже не знаю, как это рационально описать. Просто штраф за выявленные баги. Живите теперь с этим знанием. Естественно, любой релиз (даже мелкий) выпускается в десятки раз медленнее, чем мог бы.
2. Собрания с утра до вечера.
Разработчик должен на них присутствовать. Он молчит и кивает головой в трубку. Это те самые встречи, когда на совещании нужна вся проектная команда и плюс руководитель отдела, чтобы контролировать. Нельзя не прийти. Но смысла от участия почти нет. Это традиционная ошибка руководителя проекта, называется «избыточный контроль».
3. Карго-культ. Берём гибкие методологии и жёстко их внедряем.
Лучшее, что я видел: внедрили аджайл, но работали, как раньше. Только заставили разработчиков приходить на ежедневный стендап. Они строятся и рассказывают: я ничего не сделал. Это происходит изо дня в день.
4. Инструменты: внедряем, чтобы отчитаться, что внедрены.
«У нас есть Continious Integration-сервер, а задачу может добавить только администратор». «У нас внедрили хранилище бинарных сборок, а там очень маленький диск, надо удалять старые, и там только последние три версии». Или вот: система ведения задач в эксель-файле на пошареном диске. Так бэклог часто ведут даже в больших компаниях, при том, что есть и Jira. При этом пока задача не попадёт в этот файл, никто делать не будет. Он официальный.
В другой компании есть внутренняя база знаний, но всё подряд хранят прямо в системе контроля версий: менеджеру так удобнее. Дистрибутивы операционки туда даже складывают. Когда нет ответственного за систему контроля версий, менеджеры могут положить гигабайтные файлы, чтобы передавать их контрагенту, потому что в Дропбоксе место кончилось.
5. Стандарты кодирования: написаны без понимания или не обновлялись 10 лет.
Просто пара примеров: требуем 100% покрытия кода тестами и документацией. В частности, всех сторонних библиотек. Обратная сторона — отсутствие стандартных тестов. Недавно видел, как инженер развернул систему, а пользователь не может войти, потому что ключ с теста на прод не поменяли.
Ещё один раз видел, как руководитель писал код в Notepad.exe, потом кидал в компилятор без ошибок. Он с перфокарт ещё учился. Такой навык, конечно, заслуживает уважения. Но только до тех пор, пока эта профдеформация не начинает влиять на стандарты для остального отдела разработки.
6. Ошибки регламента.
Например, фиксированное время обеда, которое выгуливается полностью. Это симптом. Спрашиваю, почему. Объясняют: если ты на рабочем месте сидишь в обед, то ты мишень. Должен отвечать на письма за пять минут и так далее.
Излишняя бюрократизация: частое следование документированным процедурам, которое ведёт к куче бумаги. Те же тестпланы на каждый чих. А это описание каждого фильтра, в том числе типы данных в каждом поле интерфейса, длина поля и так далее. Обычно это решается примерами, а не полной детализацией.
В одной компании не было человека с ответственностью за актуальный релиз, иногда срывались сроки по выпуску продуктов на две недели.
Коммуникации: приходит что-то от заказчика в почте. Причём пишет он тому, кто последний с ним общался. Даже если хочется это сделать, комментарии к задаче могут быть в разных местах, включая мессенджеры. Потом кто-то ушёл, кто-то пришёл, кому-то удалили почту — всё.
7. Борьба с безопасниками.
Сюда входят ручные обновления всех систем (а надо автоматически разливать, это экономит кучу времени), физические обходы с флешкой по узлам сети, выделение портов по три недели и так далее.
8. Не налажены коммуникации между разработчиками и аналитиками.
Это настолько детский косяк, что повторяется на каждом пятом проекте. Просто аналитик написал, что нужно, разработчик разработал и через месяц показал готовое. Аналитик бегает в ужасе, потому что он имел в виду не это. Три недели из этого месяца разработчик работал зря, хотя мог бы показать часть проекта, а аналитик мог бы поинтересоваться, как там дела. Есть методологии, которые это просто закрывают, но проблема в том, что в данной ситуации обе стороны не понимают, зачем нужен проект, и как он идёт.
9. Конференц-дривен девелопмент.
Руководитель увидел что-то крутое на конференции, и это без оглядки внедрили. Через три месяца повторили. В итоге в отчёте красиво, а работа стоит.
Из-за внутренних конференций ещё бывает доведение до результата по схеме «Всегда на 80% готово». На публичных отчётах — «Почти готово», и это бесконечно. Доведение до 100% никогда не случается. Почему? Ну, например, смотрите пункт 1.
Отдельно отмечу недообследование сторонних систем. Читаешь статейку — вау, круто, давайте использовать, а потом только изучаешь, как. И сталкиваешься с массой ограничений, потому что вендор мёд в уши лил только на первых двух встречах. Мы тут сами наступили на грабли. Было внутреннее внедрение системы для интернет-магазинов документации по проектированию инфраструктур, в т.ч. ЦОДов для очень интересных объектов. Обнаружился кейс ограничения стоимости товара в 100 миллионов. Фишка в том, что по предметной области цены на единицу документа выше. И там же система должна была перелопатить для поиска индекс, а у нас есть вложения по 1 гигабайту в документы. И ожидаемое время индексации — один месяц. Вендор про такое не предупреждал.
10. Страшно вносить изменения.
Есть такое состояние проекта: нужен рефакторинг, приходите через месяц. Но при этом ни тестов, ни документов, ничего нет. И разработчики сидят: «Мы боимся вносить изменения, мы боимся всё поломать».
Ещё я видел, как в одной компании разработалась интеграция с системой, которую нельзя развернуть на стороне разработчика, потому что она очень тяжёлая. Тестировщики тестируют на передачу данных сервисом (насколько можно). Выход на стенды заказчика перед сдачей — и ещё две недели доработок, потому что модель транзакций была неправильная. Правильная практика — сделать заглушку для этой системы, которая возвращала бы какие-то ответы. В итоге так и сделали, стало проще тестировать и принимать.
Ещё заказчик может писать экономические описания на привычном ему языке. На том проекте мы дали некий псевдоязык-конструктор (набор стандартов), который потом конвертируется в данные аналитиков. В духе «Если Ваня на больничном, то он не сможет пойти на производство».
И финальный аккорд. Кто-то ещё в одной компании кодит прямо на проде. «Тут один маленький скриптик, я знаю, что делаю». Спасибо тебе, милый человек, но если я тебя найду, то даже не знаю, что с тобой сделаю.
В общем, высказался. Если узнали свои проблемы — пишите в почту oeremeev@croc.ru. У нас для крупного бизнеса есть почти бесплатные пилоты с экспресс-диагностикой (поиски бутылочных горлышек за 3-5 дней). Если кому-то у вас из бизнеса надо объяснить, что с техдолгом мириться нельзя, — тоже пишите, мы умеем это нормально считать.
