Пост по заданию ПСМ-2023: сервисы, которые я предоставляю окружающему миру
Введение
Сервисов я предоставляю много. Беру для разбора в посте один из сервисов, который я предоставляю на работе.
Моя организация применяет процедуру вычитки подготовленного тендерного пакета: перед окончательной отправкой заказчику показываем пакет своему специалисту, не принимавшему изначально участие в работе над тендером. Цель: незамыленным взглядом поискать явные ошибки, несоответствия, провалы в логике. Такой вот peer review.
Иногда такая задача приходит ко мне. Рассуждаем с использованием онтики сервиса:
- Надсистема - доставленный заказчику тендерный пакет, в сроки и с требуемым качеством.
- Моя система: проверенный пакет документации.
- Проверка - это операция::сервис меня::провайдера проверки, который изготавливает проверенный пакет документации::ГотоваяСистема.
Прозрачный ящик
В таком контексте можно рассуждать:
О характеристиках сервиса. Думаем о сроках и качестве.
Сроки проверки. Как обычно, пакет на проверку поступает в последний момент. Хорошо, когда есть на проверку день или два. Иногда же это буквально пара часов. При этом же, извините, у меня есть и другие роли (и выполняемые сервисы), приоритеты между которыми надо сбалансировать.
Качество. Есть ключевые параметры, при несоответствии с которыми заказчик признает тендерный пакет признает недействительным, а в худшем случае - еще и наложит санкции на нас как подрядчика в целом. Например, нельзя допускать упоминания никаких ценовых параметров в технической части пакета. Значит, проверку есть смысл делать в несколько проходов: первым делом, must have, искать критичные баги, а уже после, nice to have - предлагать опциональные улучшения (давайте добавим еще этот проект в описание нашего опыта работ) и косметические правки (добавим титульные листы в подразделы).
Об автоматизации. Включая любые средства, усиливающие мой мозг как проверяющего. "Парикмахерская" из учебника, если бы моей системой была прическа.
Хорошее рабочее место, с быстрым компьютером, большими мониторами, позволяющими одновременно держать перед глазами несколько документов. Доступ к корпоративным ресурсам с историческими данными (медленными переменными). Заметка на полях: точно не заниматься этим в командировках, за экраном ноутбука и через VPN туннель.
Здесь же чек-листы. Принципы DevOps на марше: опыт показывает, что лучшие чек-листы пишут те, кто изначально готовят тендерный пакет Кому, как не им, набившим все шишки на предыдущих кейсах, знать, где чаще всего бывают ошибки? Поэтому просим начинать подготовку тендера с премортем анализом в виде Excel таблички, чтобы потом использовать ее как чек-лист для проверки. Табличка, кстати, будет хорошей мета-моделью, потому что одни и те же ошибки кочуют из тендера в тендер.
О ролях и практиках. Какие роли я тут занимаю?
Базовая роль - ближе всего к контрактнику, специалисту по контрактам. Стоит ли застревать в этой позиции? Ведь могу еще "включить", осознанно или нет, роли: визионера, архитектора, проектировщика, инженера платформы разработки, оргпроектировщика. лидера. При этом понимаю, что может возникнуть конфликт интересов, а уровень мастерства в каждой роли у меня разный.
Пример: команда сборки тендера в очередной раз загоняет меня-как-проверяющего в цейтнот и оставляет два часа на проверку. Развилка: а) Контрактник: бросить все дела, сосредоточиться на проверке, найти и даже исправить самому критичные баги. Торжественно объявить, что делаю это в последний раз и в дальнейшем все должно быть по правилам (понимаем, что ничего не изменится). б) Оргпроектировщик: ничего не проверять, не податься на тендер (надсистема неуспешна!) и устроить разбор полетов. Поменяем (улучшим?) свои процессы в целом, но данный экземпляр тендера пройдет уже без нашего участия.
Черный ящик
Крутим сервисный подход. Что он нам может дать по сравнению с обычным "давайте поищем, кто там в офисе свободен и поможет с проверкой":
- Снижение когнитивной нагрузки для тендерной команды. Через стандартизацию сервиса проверки тендерного пакета, четкое прописывание интерфейсов, "контрактов". В принципе, все это есть, осталось продумать, как выбирать конкретного исполнителя, чтобы человек был доступен для этой задачи - не в отпуске, не в командировке, и т.п. Заметка на полях: к упомянутому выше вопросу о позиции - выходит, надо четко ограничиваться ролью контрактника. Если каждый проверяющий будет подключать свою роль, никакой стандартизации не будет.
- Накопление знаний: проверяющий тоже может вносить изменять чек-листы по итогами проверки. Сохраняем их и держим в базе данных.
- Сбор метрик. Nice to have: интересно посмотреть на статистику поданных тендеров, проверок, найденных и пропущенных критичных ошибок. Но еще подумать, насколько "интересно" окупится для бизнеса, можно ли из этого извлечь пользу. Способ определения: понять, могла бы такая статистика предотвратить предыдущие ошибки.
Вывод
Общий компромисс понятен: в терминах книги "Team Topologies - Organizing Business and Technology Teams for Fast Flow" или мы делаем проверки внутри stream aligned team или выносим ее в platform team. Подготовка к передаче на внешнюю проверку тут интересен именно как test-first дизайн и практики мышления письмом: описывая в чек-листе возможные ошибки, контрактник уже фокусируется, концентрирует свое внимание и тем самым исключает большинство ошибок. А сервис проверки поможет замкнуть петлю обратной связи. Тут еще вспоминается "The DevOps Handbook" с описанием автоматизации тестирования, ката совершенствования и kata, и теми самыми петлями обратной связи.
Три способа обратной связи