Всем привет! Я Татьяна Маркина, руковожу направлением системного анализа в 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, притом неважно, есть он или нет. Аналитики не знали особенностей операционных систем и не учли их.
Если бы изначально были все вводные, если бы аналитик обладал нужными знаниями, то в этой ситуации у него и всей команды разработки ушло бы меньше времени, чем у нас ушло только на первоначальный вариант. То есть вместо двух месяцев нам бы хватило всего месяца. А это довольно большая разница, не так ли?
Пускай этот случай выглядит несколько банально, но этот пример показателен и наверняка некоторые аналитики продолжают допускать подобные ошибки?♀️
Вместо заключения
Важно помнить о разграничении зон ответственности: аналитик не может просто брать и отметать все на корню, ссылаясь на какие-то ограничения, потому что он не может (и не должен) знать все. В конце концов, есть команда разработки, которая понимает свои ограничения, есть архитекторы ПО и железа, которые понимают свои. Иными словами, когда аналитик проектирует какую-то систему, его первая обязанность — разбираться в доменной модели, а потом уже необходимо задать все правильные вопросы всем заинтересованным экспертам, архитекторам, разработчикам, техническим специалистам.
Надо ли аналитику разбираться в девайсах? Делитесь своими мыслями в комментариях, буду рада обсудить!
Комментарии (9)
Thomas_Hanniball
29.10.2024 11:22Если вы аналитик, то лучше потратьте это время на развитие soft скиллов, чтобы эффективнее общаться с исполнителями, их руководителями, сотрудниками из других групп и отделов.
Это поможет людям лучше понять задачу бизнеса, быстрее прийти к согласию во время обсуждения рабочих моментов, уменьшит количество конфликтов и сократит количество бюрократии. В совокупности всё это и будет вашим весомым вкладом в развитие проекта и значительно улучшит комфорт работы сотрудников в компании.
beskov
29.10.2024 11:22Какая-то путаница между доменной областью бизнеса, знанием технологий и hard skills
a3aquB
29.10.2024 11:22Мне несколько не понятно, почему знание особенностей железа перевешивается на аналитиков
Аналитики не знали особенностей операционных систем и не учли их
Разработчики же тоже принимали участие в работе с требованиями - мозговой штурм, согласовывали их? Можно сказать:
Разработчики не знали особенностей операционных систем и не учли их
Можно продолжить дальше:
Архитекторы не знали особенностей операционных систем и не учли их
Я бы предложил смотреть, что "Было бы лучше, если бы аналитик знали", но не уходить в крайность "Аналитик должен знать"
Задача аналитика - верифицировать об экспертов
Tmark Автор
29.10.2024 11:22Жаль, что так прочиталось, я не хотела возложить всю ответственность на аналитиков, а хотела подчеркнуть, что им тоже эти знания необходимы
tik4
Как сотрудник возможно той же самой компании с "телевизионными приставками" безусловно соглашусь, что разбираться нужно :) Действительно, оборудование (и не только оно) часто имеет ограничения, которые оказывают огромное влияние на архитектуру всей системы.
Для спутникового ТВ это жёсткие ограничения на весь служебный трафик и отсутствие обратной связи от клиентских устройств.
Для автомобилей - автономная работа, резервирование, безопасность и тд и тп
Верно и то, что это все эти знания могут оказаться ненужными, тк такой специфики в проекте просто нет)
Но кажется, что именно этими знаниями, опытом и кругозором преимущественно и можно оценить "синьорность" аналитика.
Tmark Автор
Приятная встреча, коллега) Речь не только о таких специфичных областях, но и о приложениях для мобильных телефонов.
К сожалению почему-то не все аналитики понимают необходимость знания принципов работы операционных систем, для которых пишут требования, что тоже относится к хард скилам.