Привет, меня зовут Денис, и я работаю руководителем отдела проектирования в компании SSP SOFT.

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

Начну с того, что я сам числюсь системным аналитиком всего два года. Я сразу попал в «ведущие системные аналитики», пропустил стадии junior, middle. Спустя год работы ведущим системным аналитиком, меня назначили руководителем отдела проектирования, доверили развитие аналитиков в компании. С этого момента я стал обращать внимание на то, как работают аналитики в разных проектах, чем они занимаются. В компании работает около 30 аналитиков, они заняты в проектах, связанных с разработкой программного обеспечения для бизнеса. Продукты и рабочие процессы в проектах сильно отличаются, это позволяет увидеть всё разнообразие типовых задач, которые выполняет аналитик в команде.

Хотя я не получал специализированного образования в области системного анализа, я знаком с понятиями «требование» и «техническое задание» с самого начала своей карьеры. За плечами 18 лет опыта в ИТ, разнообразные проекты и продукты, есть и успешные, которыми я очень горжусь.

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

Прежде чем перейти к проблематике, зафиксируем несколько вводных:

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

Привет, уважаемые Хабровчане. Я — Алена Зорина, профдеформированный тестировщик и руководитель отдела обеспечения качества SSP. Предлагаю обсудить инструменты, которые помогают выстроить адекватную коммуникацию в команде, и при чем здесь тестировщики.

Привет, Хабр.

Меня зовут Владимир Евсеев, я Senior Java developer, Teamlead в SSP SOFT.

Наша команда приступила к масштабному проекту: системе, обеспечивающей транспортный уровень документооборота банка. Сегодня я расскажу, как мы справились с первым этапом: выстроили магистраль, способную передавать около 150 000 файлов в сутки, или 1,5 терабайта информации. Поделюсь, что получилось и что еще предстоит  довести до совершенства.

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

Здравствуй, Хабр. Меня зовут Михаил Вакорин, я ведущий системный аналитик компании SSP SOFT. Сегодня расскажу о неочевидном инструменте, который больше пяти лет применяю в своей работе. Он помогает систематизировать информацию от заказчика и избежать множества неприятных ситуаций. Статья точно будет полезна джунам в сфере аналитики и другим коллегам, желающим прокачать аналитическое мышление.