Как выполнить тестовое задание на вакансию ИТ-аналитика

https://medium.com/@beskov/

Источник тут https://medium.com/@beskov/%D0%BA%D0%B0%D0%BA-%D0%B2%D1%8B%D0%BF%D0%BE%D0%BB%D0%BD%D0%B8%D1%82%D1%8C-%D1%82%D0%B5%D1%81%D1%82%D0%BE%D0%B2%D0%BE%D0%B5-%D0%B7%D0%B0%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%B0-%D0%B2%D0%B0%D0%BA%D0%B0%D0%BD%D1%81%D0%B8%D1%8E-%D0%B8%D1%82-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0-f3e3e59b0e03

Меня периодически зовут помочь с подбором и отбором людей на позицию ИТ-аналитика.

Обычно в качестве задания мы просим написать ТЗ по каким-то исходным данным.

Степень разнообразия форматов того, что присылают в ответ люди, настолько велика, что хочется уже как-то на это повлиять 🙂

«Можно грабить корованы!»

На что я смотрю при оценке качества работы кандидата:

  1. Сделана попытка сформулировать цели доработки, выраженные в бизнес-показателях;
  2. Описана ролевая модель (какие категории пользователей будут пользоваться модулем);
  3. Задан контекст и объём программного модуля, через:
    — Диаграмму экосистемы и/или
    Контекстную диаграмму и/или
    Диаграмму юскейсов и/или
    Реестр юксейсов и/или
    Реестр функциональных требований и/или
    Карту пользовательских историй;
  4. Если используются функциональные требования, то они:
    — Атомарны;
    — Имеют уникальные идентификаторы;
    — Понятно действующее лицо, выполняющее/запускающее функцию (система или конкретная роль);
    — Понятен результат функции;
    — Указаны входные и выходные атрибуты функции или даны ссылки на словарь данных;
  5. Поведение программного модуля проиллюстрировано через:
    Диаграмму состояний и/или
    Сквозной неформальный сценарий использования
    (регламент бизнес-процесса) и/или
    Сценарии использования (use cases) и/или
    User stories и BDD-сценарии;
  6. Структурные аспекты программного модуля описаны через
    Диаграмму данных и/или
    Словарь данных и/или
    Диаграмму навигации;
  7. Поведение и структура проиллюстрированы макетами интерфейса;
  8. Нефункциональные свойства программного модуля описаны через:
    Ограничения (Совместимость по ОС/ПО, протоколы взаимодействия со смежными модулями/системами, разрешение экрана);
    Атрибуты качества, как минимум: производительность, надёжность.
  9. Бизнес-правила описаны отдельно, со ссылками на них из ФТ или юскейсов.
  10. По всем неоднозначным вопросам выше составлен перечень открытых вопросов.

Поражает, какое количество людей в ИТ, претендующих на позицию аналитика, не смогли дойти ногами до книжки Вигерса за 800 рублей.

P.S. Причём научиться делать руками всё то, что описано выше, можно буквально за 2 курса:

  1. Разработка ТЗ на ПО (24 часа)
  2. Разработка User Stories и планирование релизов (10 часов)