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

Меня зовут Евгений Шалаев. Я Frontend-разработчик в команде СберЗдоровье. В этой статье я расскажу о теханализе в разработке, его пользе, принципах выполнения и своем опыте проведения подобных исследований.

Что такое теханализ

Технический анализ (теханализ) — это способ оценки сложности и сроков выполнения задач. Результатом теханализа является документ, который содержит подробное описание всех этапов разработки нового функционала или доработки уже внедренных функций. Кроме этого, к проведению теханализа также прибегают, когда нужно изучить возникшие проблемы и найти их источник. То есть, теханализ — аналог небольшого исследования, который помогает «распутать клубок связей и зависимостей» при доработке продукта или его дебаггинге.

Зачастую теханализом занимается разработчик, который:

• хорошо знает проект;

• может самостоятельно разобраться с реализацией;

• способен детально описать все этапы разработки, не вдаваясь глубоко в технические подробности.

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

Для чего писать теханализ

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

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

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

На какие вопросы отвечает теханализ

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

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

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

Также важно, что теханализ предполагает подробное документирование, в том числе с комментированием непосредственно в коде. Это позволяет также использовать его и для согласования плана действий на всех этапах разработки. Например:

• провели анализ — получили план действий;

• показали план действий автору задачи — убедились, что алгоритм действий удовлетворяет требованиям;

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

Как написать теханализ

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

• в каталоге нужна новая панель, которая на десктопе будет с двумя кнопками: одна будет сортировать по цене, другая по популярности у юзеров;

• на мобилке нужна панель с 4 кнопками;

• надо использовать предоставленный макет кнопки для открытия модального окна поиска (теперь и модалка поиска отличается от того, что уже есть на сайте);

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

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

Есть два подхода к проведению теханализа:

• первый — сначала делать наброски предстоящей работы;

• второй — сразу проводить аналитику.

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

Второй подход — для специалистов с компетенцией. Чтобы качественно провести теханализ «с коленки» надо отлично знать продукт со всеми его особенностями, в том числе неочевидными, и понимать пути решения разных задач. 

Аналогично есть два подхода к написанию документа теханализа:

• первый — делать описание максимально подробным, прописывать код с вариантом реализации, добавлять комментарии и другую сопутствующую информацию;

• второй — верхнеуровневое описание действий, необходимых для решения задачи.

Практика, в том числе мой личный опыт, показывает, что первый вариант — хождение по битым стеклам. Это сложно, кажется отнимает все время и не имеет никакого практического смысла. Более того, часто это просто контрпродуктивно — время, потраченное на написание такого анализа, заметно больше, чем на написание кода для первоначальной задачи.

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

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

Например, теханализ может выглядеть так:

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

Дополнительные проверки и согласования

Говоря о процессе написания теханализа, нельзя не упомянуть процессы, которые сопутствуют его написанию.

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

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

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

Вместо заключения

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

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

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

Поэтому пробуйте, ошибайтесь, находите свой оптимальный вариант для написания и да пребудет с вами сила