Всем привет! Я Татьяна Маркина, руковожу направлением системного анализа в Positive Technologies. У каждой области, в которой мне доводилось работать, была своя специфика, и в каждой надо было разбираться с нуля. Сперва это были телевизионные приставки, потом мультимедийные устройства для автомобиля, сейчас это информационная безопасность. О каждой области я могу говорить часами. Но хотелось бы определить, какие именно hard skills на каких продуктах и проектах нужны.

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

С чем едят hard skills аналитика?

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

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

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

Если онбординга в компании нет (или вас туда пригласить не могут), пофантазируйте: а как бы вы погрузили нового аналитика в эту сферу? ?

Про важность тестирования и обратной связи

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

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

Получив обратную связь, можно будет обратить внимание на те моменты, над которыми вы и не задумывались. Это тоже даст понимание того, какие hard skills вам необходимы.

Помним и про типы устройств. Многие аналитики не пишут отдельные требования для iOS и Android, не задумываются о диагонали устройства. Так как я работала и с планшетами, и с телевизорами, и с ноутбуками и ПК, и с мобильными телефонами, я понимаю, что у них не только разные экраны, диагонали, но и разные манипуляторы. Телевизоры, автомобили и даже навигаторы (устройства, которыми продолжают пользоваться!) — вообще другая стихия. У каждого устройства свои особенности. Есть люди, которым комфортно использовать технику, отличную от нашей, поэтому, просчитывая возможные сценарии использования и составляя требования, надо думать и о них.

Помощь архитекторов и инженеров

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

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

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

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

«Большой факап»

Расскажу про личный неудачный опыт. У нас было банальное IoT-устройство — видеорегистратор, такой же, как пылесос или колонка, которые работают по сети Wi-Fi. DVR был с Wi-Fi: мы могли подключиться к нему с мобильного телефона как к точке доступа. При этом в DVR была доступна функция подключения к мобильному интернету.

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

В результате представили разработку и начали тестирование. Во время тестирования мы обратили внимание на один интересный момент (не спрашивайте, почему он не был затронут раньше): пока мы разрабатывали новые функции, нам просто повезло, что мы взяли нужную версию Android, на которой одновременно можно подключиться к устройству по Wi-Fi и раздавать мобильный интернет на то же устройство. Но как известно, не на всех версиях Android это возможно, а на iOS невозможно в принципе: вы либо только раздаете мобильный интернет, либо ваше устройство только может быть подключено к Wi-Fi, притом неважно, есть он или нет. Аналитики не знали особенностей операционных систем и не учли их.

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

Пускай этот случай выглядит несколько банально, но этот пример показателен и наверняка некоторые аналитики продолжают допускать подобные ошибки?‍♀️

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

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

Надо ли аналитику разбираться в девайсах? Делитесь своими мыслями в комментариях, буду рада обсудить!