В процессе поиска работы мы привыкли к тому, что компании тестируют наши навыки. Но редко задумываемся, что тестовое задание — это не экзамен с единственно верным ответом, а прежде всего уникальная возможность заглянуть за внешний фасад компании.

Тестовое задание это результат работы её внутренних структур, культурных механизмов, ценностей и страхов, явно и неявно сформулированных в набор требований к новому идеальному сотруднику. Это её ДНК, упакованное в текст.

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

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

И вот случилось — я увидел вакансию (стажировка), которая идеально подходила мне по требованиям, оформил заявку и получил тестовое. В момент открытия документа я чувствовал себя как заряженный боксер перед главным поединком своей карьеры.

Тестовое не разочаровало, это был плотный трёхсоставной бриф, от проектирования ИС до анализа верификации сертификата сервера. Так что время заваривать кофе, открывать ИИ‑шку и запускать VS‑code для первых заметок.

Первым звоночком для меня стало отсутствие в контексте задачи трёх ключевых категорий для начала разработки любого (технического, либо другого) решения: «ответственные и заинтересованные стороны», «исторические» предпосылки и ресурсные рамки решения.

3. Формулировка боли.

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

4. Итоговое решение.

Задав десять вопросов, которые бы ограничили варианты решений уже до этапа проектирования, я создал себе систему координат. В зависимости от конфигурации метрик контекста были предложены три варианта (карточки, PIN — код и таймер печати).

Первая рефлексия

Вроде бы задание завершено, но вот в чём шутка — ни одно решение в данном задание не облегчает жизнь обычному сотруднику. И безопаснику в рамках компании тоже жить не проще. Хорошие ли это решения, была ли альтернатива? Не знаю, в контексте сказано не было.

1. Суть второго задания: разбор и составление списка проверок, которые совершаются браузером при проверке сертификата сервера в рамках протокола TLS v1.2.

2. Выбор уровня абстракции и представления.

Задача по большей мере техническая, и поэтому техническому специалисту достаточно открыть мануалы (можно даже две статьи на хабре, по TLS v1.2 и сертификатам x509.v3).

Но ведь это не решение в рамках системного анализа. Так что я решил, раз низкоуровневое представление (достаточно плотное) уже есть, а ко всему тестовому есть приписка «углубляться в технические детали не нужно», то можно (и корректно) декомпозировать алгоритм проверки не на уровни проверок (слои TLS, PKI, x509.v3), а составить список групп проверок для незнакомого с технической спецификой читателя.

3. Итоговое решение.
Я "прокурил" мануалы (протоколы описывают в очень специфичной манере), сделал представление в виде кода (мне лично так удобней разбивать сущности и абстракции в рамках ответственности и этапов), составил UML диаграмму (посмотрел и ужаснулся, но как уровень "дна" сложности вариант подошёл). В итоге, после всей этой работы, получилась разбивка на четыре вида проверок:

• Проверки соответствия синтаксического формата

• Проверки доверия

• Проверка целостности

• Проверка актуальности
  

В итоге, получилась разбивка по базовой тройке ИБ + проверка на актуальность.

Вторая рефлексия
Для чего мне понадобится разбирать протоколы обмена данными и подтверждения доверия вообще без упоминания контекста? Кому мне бы пришлось объяснять этот протокол?

«Ничего, справимся» подумал я и начал с классического уже разбора контекста. Но вдруг оказалось, что боли то нет. В рамках задачи нет мотивации (и истории и стейкхолдеров). т. е. нет главного вопроса, на который я должен был бы ответить при проектировании ИС: «А нафига?».

Пришлось формулировать последующую из задания мотивацию:

«Мотивация заключается не в автоматизации существующих задач, а в создании нового центрального актора — „Процесс‑Системы“. Его внедрение преобразует сеть из слабо связанного набора разрозненных активностей в устойчивую, управляемую и предсказуемую конфигурацию, способную гарантированно достигать заданного бизнес‑результата и соответствовать регуляторным требованиям. Сквозной процесс является не целью, а следствием — внешним проявлением внутренней логики этого нового актора.»

3. Промежуточное решение с использованием методологии акторно‑сетевой теории.

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

Дальше дело осталось за формальными (но важными) этапами — формирование различных представлений в рамках диаграмм, составления списков use case и user story для формализации взаимодействия человеческого взаимодействия с системой и ER‑диаграмму для выбора формата хранения отражения акторов в рамках системы. Но я этого не сделал, потому что споткнулся о...

Последний абстрактный вопрос в рамках решения задач.

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

И тут я призадумался. Осмотрел уже проделанную работу над тестовым в полной совокупности и выделил несколько общих элементов в рамках заданий. Спасибо предварительному анализу контекста, который позволил явно зафиксировать «неизвестное», т. е. по мнению составителя тестового «неважное».

Вот итоговый список моих сомнений:

1. Проектируемые и разбираемые системы не облегчают жизнь использующим их людям. Они, наоборот, усложняют её или заменяют людей.

2. Отношение к человеку, как к точке риска. Замещение личной ответственности и доверия на автоматизированную.

3. Отсутствие этической или культурной рефлексии, замещение её рефлексией технической в рамках задачи.

Именно совокупность этих трёх пунктов убедила меня в том, что стоит остановиться и проанализировать доступную информацию о компании N.

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

Нашёл отзывы сотрудников компании, но не встретил в них опровержение гипотез. Подтверждения находил и это был не один отзыв.

1. Посмотрел на то, какие продукты создаёт компания, какие исследования проводит. Ни одного опровержения.

2. Посмотрел, с кем сотрудничает данная компания.

3. Изучил страницу компании «почему мы».

4. Изучил вакансию на СА, а не на стажировку.
   

В итоге, опровержение не нашлось. Может плохо искал, может предвзято отнёсся.
Но как аналитик, по заветам Латура, я был обязан пройти цепочку акторов, куда бы она меня не завела. Как итог — тестовое отправлено не было.