Почему артефакты являются важным критерием для оценки ИТ-специалиста

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

Однако встает вопрос: как отличить хорошего специалиста от плохого? В данной статье мы выделяем следующий критерий: специалист высокого уровня регулярно предоставляет качественные артефакты как результат своего труда. 

В контексте ИТ-отрасли артефактами могут быть файлы с исходным кодом от разработчика, требования системного аналитика или автотесты от QA-инженера и т.д.

Артефакты служат двум главным целям:

1. Снижение энтропии и неопределенности.
2. Снижение когнитивной нагрузки.

Путем достижения первой цели артефакт помогает перевести абстрактные бизнес-требования на язык, понятный разработчику, который в итоге создает основу будущего продукта. Вторая цель связана с оптимизацией времени, сокращением циклов встреч для согласования и уточнения деталей.

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

Из этих фактов вытекают два ключевых вывода:

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

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

Легкость переиспользования

Давайте рассмотрим критерии, которые следует учесть при оценке качества артефакта. Создание артефакта специалистом не является самоцелью. Любой артефакт должен быть передан другим специалистам, чтобы они могли использовать результат «творца» для создания своего труда. И так по всей цепочке создания программного продукта.

Для примера, бизнес или системный аналитик формирует сценарии использования (Use case), на основе которых дизайнер разрабатывает прототипы, а QA-инженер создает тест-кейсы.

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

Легкость восприятия

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

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

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

Четкая структура

Описание объекта или процесса требует от специалиста не только усилий, но и структурного мышления, навыка, далеко не всегда развитого у всех.

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

Для облегчения понимания чужого артефакта эффективными приемами являются разбиение информации на логические блоки, следование принципу от общего к частному или от частного к общему, а также использование метода описания по пирамиде Минто. Эти подходы значительно снижают когнитивную нагрузку при чтении.

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

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

Соответствие нотациям

Для улучшения взаимопонимания схем специалисты пришли к соглашению использовать общепринятые условные обозначения. Например, для описания бизнес-процессов применяются такие нотации, как BPMN, EPC и IDEF0. Этот подход способствует эффективному обмену информацией между участниками команды.

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

Справедливости ради, следует отметить, что такие ситуации часто возникают из-за недостаточного владения некоторыми специалистами знаниями и навыками использования общепринятых нотаций.

Ревизия и поддержка

Любой артефакт имеет срок времени, когда отраженная в нем информация является актуальной. Некоторые артефакты, такие как модель C4 или ERD, подвергаются лишь незначительным изменениям в процессе разработки программного обеспечения, в то время как другие, например, OpenAPI-спецификация, могут потребовать постоянных модификаций.

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

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

Руководитель проекта и артефакты

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

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