Я, как СА, могу ответить так: доступ, конечно, получить можно, и ошибку найти, и локализовать тоже (в некоторых вакансиях это как раз и требуется от СА), но чаще всего (по моему опыту, 6 лет в на банковских проектах) аналитик не лезет в код и не читает его, дабы не тратить своё время и не отнимать хлеб у разработчика - проще отдать дефект в руки самого автора кода.
Для примера, будучи джуном, я так однажды пыталась разобраться в дефекте, просто потому что мне это было интересно, а потом случайно проговорилась своему руководителю об этой деятельности, за что и получила выговор. Суть его примерно такая: первоочередная задача аналитика - следить на качеством требований и документации, все остальные активности - факультативно и не во вред команде.
Конечно, навык чтения кода полезен для СА, но насколько это будет эффективно для самого разработчика работать с таким вот аналитиком, который по сути (как мне кажется) принесёт кодерскую задачу типа "поправь вот ту строчку, она криво написана"? У меня нет такого опыта с того выговора от рука, поэтому интересно послушать о чужом опыте работы с таким СА.
Как считаете, рекомендации с прошлых мест работы работают? Как Вы писали в статье - кандидат может заучить теорию и на собесе показать себя невероятным специалистом, а по факту работать в команде не умеет. Как таких "зайцев" отсеивать на этапе собеса?
почему обыденная тема коммуникации оказалась настолько болезненной?
Здесь я бы подумала над термином "обыденной коммуникации" и копала именно в него.
Моё мнение банально: у всех людей разный опыт общения, и правила общения на работе тоже разные. Попытаться прописать универсальные правила прям для всех - на мой взгляд, относительно бессмысленно, и всё сведётся к тому, чтобы "будь человеком и попытайся понять всех", но может быть есть кто-то умнее меня и сделал это. Можно, наверно, писать правила для похожих секторов, например, для банков, но я бы привлекла к этому несколько коллег с опытом работы в разных банках, чтобы не встретить ответ "а у нас не так".
Вот мы приходим в новую компанию и мы сразу начинаем подмечать особенности корп.культуры (как пример далее): 1) общаемся с теми на "Вы", а вот с этими на "ты" 2) все деловые письма только в почте, в мессенджерах только со своей командой 3) по началу верифицируем все письма со своим начальником 4) (не) общаемся на личные темы во время перерывов в работе 5) и главное (!) "того Васю не отвлекай, он сейчас делает суперкритичную задачу", а тебе вот прям надо именно этого Васю спросить о чём-то
Общение в компании (тем более компании с какой-то историей на рынке) складывалось годами разными людьми, которые, возможно, уже и не работают в компании, но вот свой незримый след оставили. Чтобы поменять корп.культуру - это надо менять людей изнутри, а автор уже понял на своём опыте, что это может встретить сопротивление. А главное зачем? Если спринты запускаются, зачем менять правила коммуникаций, тем более если руководство устраивает текущее положение дел?! Поэтому новым коллегам только и остаётся, что адаптироваться к уже существующим правилам.
Главное помнить, что у всех разный опыт и к каждому человеку нужен свой подход, и чем больше человек работает в определенной компании, тем больше он с ней срастается в плане культуры коммуникаций.
Для начала выражаю искреннее поздравление автору: первая статья на Хабре залетела с ноги и подняла такое бурное обсуждение! Уух!
Я, системный аналитик с общим опытом 6 лет на банковских проектах, сталкивалась с такой же проблемой, когда была джуном, поэтому решила поделиться своим опытом ниже.
На самом деле накал страстей в коммуникациях зависит от самого проекта: на каких-то проектах все коллеги идеально последовательны и нет никакой напряженности, и ответы не надо выбивать, но вот где-то просто мрак (вот вроде и договорились, и письма о сроках есть, но вот реальных дел нет, - и эти проекты самые зубодробительные).
Каждый новый случай молчания со стороны коллег - это новый челлендж, и обычно он упирается в задачу "Выясни причину молчания и предложи такое решение, чтобы выиграли обе стороны обмена информацией". Посмотри на это с системной точки зрения: ты - сервис А, а твой получатель - сервис Б, сервис А запрашивает у сервиса Б информацию, но в ответ получает ошибку по таймауту. Как решить эту задачу?
Мой подход на текущий момент (сорри, буду уходить в подробности, чтобы подсветить все острые углы, которые всплывали походу письма):
1) Понять формат работы своих коллег. Например, если сроки горят у всех и все перерабатывают, то, наверно, не у всякого будет время вчитываться в письма. Люди просто могут не открывать почту, чтобы успеть сделать тот пул задач, который запланирован в их спринте. Или же другая причина: разработчики просто не пользуются почтой, потому что задачи им ставит аналитик или манагер (зачем пользоваться ненужным инструментом?!). И это классика, и с этим надо считаться, поэтому всегда уточняю формат работы смежников, даже если работаешь с ними в одной крупной компании, формат взаимодействия с почтой/мессенджерами может отличаться у других команд. И иногда получается интересная ситуация: ты пишешь письмо, а оно не дошло до адресата, т.е. письмо ушло в никуда. Некоторые мои коллеги ставят ещё функцию "уведомить при прочтении", чтобы снять этот риск, но я этим не пользуюсь, хотя ничего против этого не имею.
2) Написать информативное письмо
Это целое искусство и этому надо учиться (я не читала книжки на эту тему, училась у коллег "по подобию", но наверняка уже много полезного издано): пишешь коротко/информативно, убираешь канцеляризмы (Ильяхов в помощь и этот навык нарабатывается с опытом), ставишь Имя и выделяешь жирным, срок само собой или просьбу к получателю сориентировать по сроку. Если не знаешь, к кому обратиться - иди к PM, а он сориентирует, не знает PM - к лиду. Поиск ответственного иногда тоже тяжкая задача и тут надо быть готовым перелопатить половину отдела, потратить на это дни, чтобы найти этого "ответственного".
Красный цвет не использую совсем (только крайний случай, когда ничего не работает, и по согласованию с PM/PO). По мне это агрессивно изначально, потому что вопрос не приобрёл такой статус, чтобы сходу агрессировать на получателя. Я думаю, что красный у всех ассоциируется с ошибками в школьных тетрадях, и поэтому у этого цвета в письме априори негативный оттенок: вот ты только получил письмо, а уже в чём-то виноват; ещё ничего не сделал, а уже где-то ошибся. Как решение, использую форматирование: жирность, курсив, буллеты или нумерацию - это менее агрессивно, но подчёркивает именно те мысли и те слова, за которые будут цепляться мои коллеги. Если письмо важное, есть метка "Важно" у письма - так было в аутлуке. Если же PM настаивает на красном - ууух, кажется, мы переходим в абьюзивные отношения с коллегами и это нехороший знак... Я как-то на старте своей карьеры читала книжку про шрифты и их форматы и была в полном восторге, как за счет шрифта передать скрытые смыслы через форматирование ("О шрифте", автор Эрик Шпикерманн - может кому-то пригодится).
Важно помнить, что моя задача, как аналитика - сэкономить время на прочтение моих "опусов", поэтому лаконичность и краткость наше аналитическое "всё". Я отмечу ещё, что важно также ставить в подписи к письму "С уважением, Имя Фамилия", а не просто "Имя Фамилия". Вроде бы замыленный стандарт по-умолчанию, но меня, как человека, который постоянно читает деловые письма, всегда коробит подпись без уважения. «Ты приходишь и просишь что-то у меня, но ты просишь без уважения», да-да-да, именно эта мысль и приходит на ум.
3) Что делать, если не отвечают на вопросы
И вот письмо написано вроде бы идеально и нужным людям, но игнор... Первое, что приходит на ум - письмо не прочитали. Решение: ищем мессенджер коллеги и пишем ему нейтрально "Здравствуйте, я такая-то, писала Вам тогда-то с таким-то вопросом. Вы видели моё письмо?" - далее пытаюсь выяснить причины задержки с ответом (опять же нейтрально, с желанием искренне помочь наладить коммуникацию).
Идём по негативным сценариям и обычно причины такие:
а) я не читаю почту, сейчас открою и посмотрю;
б) я этим не занимаюсь, но у меня было много своих задач, чтобы сообщить об этом в ответном письме;
в) у меня много задач, иди к моему манагеру за выделением ресурса.
Дальнейшие шаги по кейсам:
а) договариваемся о дальнейшем формате взаимодействия, чтобы в дальнейшем не задерживать ответы (см. 1 пункт про почту и загруженность): i) можем ли обращаться по мелким вопросам или обращаемся всегда к манагеру команды, и ii) потом обязательно информируем своего манагера о формате взаимодействия, потому что он может подсветить риск, что "так не пойдёт, надо обязательно общаться в почте и никак иначе";
б) пытаюсь дальше найти реального ответственного через PM/лида;
в) иду к своему манагеру, чтобы он "на манагерском" объяснил другому манагеру о включении вопроса в пул задач нужного мне человека. Ошибка здесь: уговаривать ответственного быстро посмотреть вопрос, если ты и твоя команда не знает формат взаимодействия с этим человеком или по каким-то причинам нужно именно с этой командой "всегда и всё фиксировать в письмах". Это деловое письмо, и нужно делать всё чисто, т.е. без скрытых потерь времени со стороны получателя, иначе это может вылезти в неприятный выговор лида/PM к аналитику. Думаю, что выговор рождается так - манагер на дейли спрашивает X: "Почему ты не сделал то-то?", X: "Ну мне там написала вот такая-то, я целый час смотрел, как оно работает и потом думал, как объяснить", манагер: "Ясно-понятно, поговорю с таким-то, чтобы все вопросы решали через меня и никак иначе, у нас сроки горят, а они отвлекают..." Я не раз на это наталкивалась: и вроде бы с душой к человеку и он к тебе с душой отвечает, а по факту жестокая реальность разбивает эти душевные отношения.
4) Немного слов про зубодробительные проекты
Был у меня проект в синем банке давно ещё, до трансформации, где в одни из моих обязанностей, как аналитика, как раз входило выбивать сроки и следить за договоренностями всех сторон. Эдакий "коллектор" в мире банковского IT. Опыт незабываемый: постоянно держишь руку на пульсе, когда истечет срок дачи ответа, чтобы начать эскалировать и подключать руководителей подразделений (иначе ай-яй-яй, ты не выполняешь свои обязанности, как аналитика). У тебя инструкция от своего лида, как действовать в таких ситуациях, и ты действуешь чётко по инструкции - подключаешь руков, каких-то стейкхолдеров, о которых ты вообще ничего не знаешь, и постоянно пишешь эти бесконечные письма... Я по началу бесилась (ну как так?! только мне надо и больше никому?!), а потом смысл этих вопросов пропал, т.к. проблема в том, что на проекте не налажен комфортный формат коммуникации между подразделениями, и (главное!) это не моя вина. Что здесь можно сделать, если такой формат превратился в паттерн? Правильные действия - это эскалировать, т.е. поговорить со своим менеджером или лидом и спросить, можно ли поменять ситуацию в лучшую сторону, потому что эти непродуктивные коммуникации влияют на сроки проекта, твоих задач и мотивацию. В моём случае формат коммуникаций чуть улучшился (не из-за моей эскалации, а потому что проблема была явно видна всем без эскалаций), но не стал идеальным; проект запустили, но моя злость к нему осталась. Надо всегда держать в уме, что такие проекты, где руководство по каким-то своим причинам не может организовать каналы коммуникаций, 1) влияют на твою самооценку и отношение к текущим и, возможно, к будущим коллегам 2) дают тебе возможность прокачать свои скиллы. Я оставалась на проекте, потому что училась у других стрессоустойчивости и решению конфликтных ситуаций, написанию писем и ТЗ, работе в команде. Потом уволилась, т.к. нарастила нужную мне экспертизу и оставаться уже не было смысла (получаемый негатив перетягивал позитив).
Я, как СА, могу ответить так: доступ, конечно, получить можно, и ошибку найти, и локализовать тоже (в некоторых вакансиях это как раз и требуется от СА), но чаще всего (по моему опыту, 6 лет в на банковских проектах) аналитик не лезет в код и не читает его, дабы не тратить своё время и не отнимать хлеб у разработчика - проще отдать дефект в руки самого автора кода.
Для примера, будучи джуном, я так однажды пыталась разобраться в дефекте, просто потому что мне это было интересно, а потом случайно проговорилась своему руководителю об этой деятельности, за что и получила выговор. Суть его примерно такая: первоочередная задача аналитика - следить на качеством требований и документации, все остальные активности - факультативно и не во вред команде.
Конечно, навык чтения кода полезен для СА, но насколько это будет эффективно для самого разработчика работать с таким вот аналитиком, который по сути (как мне кажется) принесёт кодерскую задачу типа "поправь вот ту строчку, она криво написана"? У меня нет такого опыта с того выговора от рука, поэтому интересно послушать о чужом опыте работы с таким СА.
Как считаете, рекомендации с прошлых мест работы работают? Как Вы писали в статье - кандидат может заучить теорию и на собесе показать себя невероятным специалистом, а по факту работать в команде не умеет. Как таких "зайцев" отсеивать на этапе собеса?
Здесь я бы подумала над термином "обыденной коммуникации" и копала именно в него.
Моё мнение банально: у всех людей разный опыт общения, и правила общения на работе тоже разные. Попытаться прописать универсальные правила прям для всех - на мой взгляд, относительно бессмысленно, и всё сведётся к тому, чтобы "будь человеком и попытайся понять всех", но может быть есть кто-то умнее меня и сделал это. Можно, наверно, писать правила для похожих секторов, например, для банков, но я бы привлекла к этому несколько коллег с опытом работы в разных банках, чтобы не встретить ответ "а у нас не так".
Вот мы приходим в новую компанию и мы сразу начинаем подмечать особенности корп.культуры (как пример далее): 1) общаемся с теми на "Вы", а вот с этими на "ты" 2) все деловые письма только в почте, в мессенджерах только со своей командой 3) по началу верифицируем все письма со своим начальником 4) (не) общаемся на личные темы во время перерывов в работе 5) и главное (!) "того Васю не отвлекай, он сейчас делает суперкритичную задачу", а тебе вот прям надо именно этого Васю спросить о чём-то
Общение в компании (тем более компании с какой-то историей на рынке) складывалось годами разными людьми, которые, возможно, уже и не работают в компании, но вот свой незримый след оставили. Чтобы поменять корп.культуру - это надо менять людей изнутри, а автор уже понял на своём опыте, что это может встретить сопротивление. А главное зачем? Если спринты запускаются, зачем менять правила коммуникаций, тем более если руководство устраивает текущее положение дел?! Поэтому новым коллегам только и остаётся, что адаптироваться к уже существующим правилам.
Главное помнить, что у всех разный опыт и к каждому человеку нужен свой подход, и чем больше человек работает в определенной компании, тем больше он с ней срастается в плане культуры коммуникаций.
Для начала выражаю искреннее поздравление автору: первая статья на Хабре залетела с ноги и подняла такое бурное обсуждение! Уух!
Я, системный аналитик с общим опытом 6 лет на банковских проектах, сталкивалась с такой же проблемой, когда была джуном, поэтому решила поделиться своим опытом ниже.
На самом деле накал страстей в коммуникациях зависит от самого проекта: на каких-то проектах все коллеги идеально последовательны и нет никакой напряженности, и ответы не надо выбивать, но вот где-то просто мрак (вот вроде и договорились, и письма о сроках есть, но вот реальных дел нет, - и эти проекты самые зубодробительные).
Каждый новый случай молчания со стороны коллег - это новый челлендж, и обычно он упирается в задачу "Выясни причину молчания и предложи такое решение, чтобы выиграли обе стороны обмена информацией". Посмотри на это с системной точки зрения: ты - сервис А, а твой получатель - сервис Б, сервис А запрашивает у сервиса Б информацию, но в ответ получает ошибку по таймауту. Как решить эту задачу?
Мой подход на текущий момент (сорри, буду уходить в подробности, чтобы подсветить все острые углы, которые всплывали походу письма):
1) Понять формат работы своих коллег. Например, если сроки горят у всех и все перерабатывают, то, наверно, не у всякого будет время вчитываться в письма. Люди просто могут не открывать почту, чтобы успеть сделать тот пул задач, который запланирован в их спринте. Или же другая причина: разработчики просто не пользуются почтой, потому что задачи им ставит аналитик или манагер (зачем пользоваться ненужным инструментом?!). И это классика, и с этим надо считаться, поэтому всегда уточняю формат работы смежников, даже если работаешь с ними в одной крупной компании, формат взаимодействия с почтой/мессенджерами может отличаться у других команд. И иногда получается интересная ситуация: ты пишешь письмо, а оно не дошло до адресата, т.е. письмо ушло в никуда. Некоторые мои коллеги ставят ещё функцию "уведомить при прочтении", чтобы снять этот риск, но я этим не пользуюсь, хотя ничего против этого не имею.
2) Написать информативное письмо
Это целое искусство и этому надо учиться (я не читала книжки на эту тему, училась у коллег "по подобию", но наверняка уже много полезного издано): пишешь коротко/информативно, убираешь канцеляризмы (Ильяхов в помощь и этот навык нарабатывается с опытом), ставишь Имя и выделяешь жирным, срок само собой или просьбу к получателю сориентировать по сроку. Если не знаешь, к кому обратиться - иди к PM, а он сориентирует, не знает PM - к лиду. Поиск ответственного иногда тоже тяжкая задача и тут надо быть готовым перелопатить половину отдела, потратить на это дни, чтобы найти этого "ответственного".
Красный цвет не использую совсем (только крайний случай, когда ничего не работает, и по согласованию с PM/PO). По мне это агрессивно изначально, потому что вопрос не приобрёл такой статус, чтобы сходу агрессировать на получателя. Я думаю, что красный у всех ассоциируется с ошибками в школьных тетрадях, и поэтому у этого цвета в письме априори негативный оттенок: вот ты только получил письмо, а уже в чём-то виноват; ещё ничего не сделал, а уже где-то ошибся. Как решение, использую форматирование: жирность, курсив, буллеты или нумерацию - это менее агрессивно, но подчёркивает именно те мысли и те слова, за которые будут цепляться мои коллеги. Если письмо важное, есть метка "Важно" у письма - так было в аутлуке. Если же PM настаивает на красном - ууух, кажется, мы переходим в абьюзивные отношения с коллегами и это нехороший знак... Я как-то на старте своей карьеры читала книжку про шрифты и их форматы и была в полном восторге, как за счет шрифта передать скрытые смыслы через форматирование ("О шрифте", автор Эрик Шпикерманн - может кому-то пригодится).
Важно помнить, что моя задача, как аналитика - сэкономить время на прочтение моих "опусов", поэтому лаконичность и краткость наше аналитическое "всё". Я отмечу ещё, что важно также ставить в подписи к письму "С уважением, Имя Фамилия", а не просто "Имя Фамилия". Вроде бы замыленный стандарт по-умолчанию, но меня, как человека, который постоянно читает деловые письма, всегда коробит подпись без уважения. «Ты приходишь и просишь что-то у меня, но ты просишь без уважения», да-да-да, именно эта мысль и приходит на ум.
3) Что делать, если не отвечают на вопросы
И вот письмо написано вроде бы идеально и нужным людям, но игнор... Первое, что приходит на ум - письмо не прочитали. Решение: ищем мессенджер коллеги и пишем ему нейтрально "Здравствуйте, я такая-то, писала Вам тогда-то с таким-то вопросом. Вы видели моё письмо?" - далее пытаюсь выяснить причины задержки с ответом (опять же нейтрально, с желанием искренне помочь наладить коммуникацию).
Идём по негативным сценариям и обычно причины такие:
а) я не читаю почту, сейчас открою и посмотрю;
б) я этим не занимаюсь, но у меня было много своих задач, чтобы сообщить об этом в ответном письме;
в) у меня много задач, иди к моему манагеру за выделением ресурса.
Дальнейшие шаги по кейсам:
а) договариваемся о дальнейшем формате взаимодействия, чтобы в дальнейшем не задерживать ответы (см. 1 пункт про почту и загруженность): i) можем ли обращаться по мелким вопросам или обращаемся всегда к манагеру команды, и ii) потом обязательно информируем своего манагера о формате взаимодействия, потому что он может подсветить риск, что "так не пойдёт, надо обязательно общаться в почте и никак иначе";
б) пытаюсь дальше найти реального ответственного через PM/лида;
в) иду к своему манагеру, чтобы он "на манагерском" объяснил другому манагеру о включении вопроса в пул задач нужного мне человека. Ошибка здесь: уговаривать ответственного быстро посмотреть вопрос, если ты и твоя команда не знает формат взаимодействия с этим человеком или по каким-то причинам нужно именно с этой командой "всегда и всё фиксировать в письмах". Это деловое письмо, и нужно делать всё чисто, т.е. без скрытых потерь времени со стороны получателя, иначе это может вылезти в неприятный выговор лида/PM к аналитику. Думаю, что выговор рождается так - манагер на дейли спрашивает X: "Почему ты не сделал то-то?", X: "Ну мне там написала вот такая-то, я целый час смотрел, как оно работает и потом думал, как объяснить", манагер: "Ясно-понятно, поговорю с таким-то, чтобы все вопросы решали через меня и никак иначе, у нас сроки горят, а они отвлекают..." Я не раз на это наталкивалась: и вроде бы с душой к человеку и он к тебе с душой отвечает, а по факту жестокая реальность разбивает эти душевные отношения.
4) Немного слов про зубодробительные проекты
Был у меня проект в синем банке давно ещё, до трансформации, где в одни из моих обязанностей, как аналитика, как раз входило выбивать сроки и следить за договоренностями всех сторон. Эдакий "коллектор" в мире банковского IT. Опыт незабываемый: постоянно держишь руку на пульсе, когда истечет срок дачи ответа, чтобы начать эскалировать и подключать руководителей подразделений (иначе ай-яй-яй, ты не выполняешь свои обязанности, как аналитика). У тебя инструкция от своего лида, как действовать в таких ситуациях, и ты действуешь чётко по инструкции - подключаешь руков, каких-то стейкхолдеров, о которых ты вообще ничего не знаешь, и постоянно пишешь эти бесконечные письма... Я по началу бесилась (ну как так?! только мне надо и больше никому?!), а потом смысл этих вопросов пропал, т.к. проблема в том, что на проекте не налажен комфортный формат коммуникации между подразделениями, и (главное!) это не моя вина. Что здесь можно сделать, если такой формат превратился в паттерн? Правильные действия - это эскалировать, т.е. поговорить со своим менеджером или лидом и спросить, можно ли поменять ситуацию в лучшую сторону, потому что эти непродуктивные коммуникации влияют на сроки проекта, твоих задач и мотивацию. В моём случае формат коммуникаций чуть улучшился (не из-за моей эскалации, а потому что проблема была явно видна всем без эскалаций), но не стал идеальным; проект запустили, но моя злость к нему осталась. Надо всегда держать в уме, что такие проекты, где руководство по каким-то своим причинам не может организовать каналы коммуникаций, 1) влияют на твою самооценку и отношение к текущим и, возможно, к будущим коллегам 2) дают тебе возможность прокачать свои скиллы. Я оставалась на проекте, потому что училась у других стрессоустойчивости и решению конфликтных ситуаций, написанию писем и ТЗ, работе в команде. Потом уволилась, т.к. нарастила нужную мне экспертизу и оставаться уже не было смысла (получаемый негатив перетягивал позитив).