Как стать автором
Обновить

Комментарии 12

До чего отвратительная КДПВ! Это вы своих сотрудников за тараканов держите или тех компаний, которым своё поделие внедряете?
А что отвратительное тут?
Странно, у меня автоматом совсем другая ассоциация. Она прямо следует из текста перед картинкой. На всякий случай: это ж ошибки (баги), стремящиеся проникнуть на этапе проектирования.
Хотя было бы интереснее комментить содержание статьи, а не творческие изыски автора. Слишком длинное вступление. Очень много слов в целом
Спасибо за статью!
Есть парочка вопросов для разогрева:
1) А как же товарищ Вигерс (у него немного другой расклад)? Недавно третье издание подогнали, с эджайлом)
2) Правильно ли я понял, что системный аналитик проектирует вместо разработчиков? Не получится ли медвежья услуга им, что они разучатся сами проектировать? Или кодеры кодируют, а аналитики проектируют?

1) Вигерс писал: «Не существует выверенного способа написания идеальных требований, а лучший учитель это опыт, который нарабатывается со временем».
Всё зависит от продукта и команды. Делюсь тем, к чему пришли и как это помогает.

2) Проектировать вместо разработчика можно, но не нужно. Иначе получится ровно то, что Вы написали: кодеры и аналитики.
В процессе проектирования участвует команда, что позволяет не замыкать разработку и знания о продукте на одном человеке и проявлять творческие начала всем. Аналитик не блокирует разработку.
Системный аналитик — участник процесса проектирования. Он больше погружается в анализ и описание процессов, сценариев работы с системой, меньше в проектирование технической реализации, но умеет грамотно изложить ее и зафиксировать решение, анализирует взаимосвязи в продукте.
По итогам разработки аналитик у нас отвечает за сбор знаний — документирование продукта. Т.о. если результат работы разработчика — код и рабочее ПО, то результат работы аналитика — документация.
Спасибо за статью. Я так понимаю, тут представлены задачи и роли конкретно в компании «МойСклад» — оно довольно уникально во многих моментах, как и процесс проектирования. (Если сравнивать со стандартами, Вигерсом или другими компаниями).

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

Есть профстандарт, есть программы обучения (неплохая в Плехановке выпуска 2018 г.), есть Вигерс, есть OpenUP, Agile, SWEBoK.

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

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

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

Потом общаемся с таким человеком-оркестром, и он вообще всё знает про разработку, про микросервисы, схему базы может нарисовать, SQL на всех диалектах, XMLQuery и всё вот это вот. А кто такой Вигерс он даже не в курсе. Какие виды требований бывают и зачем, тоже может не знать. При этом старший или ведущий аналитик.

Как считаете, что делать дальше в таком случае? Переучиваться или продолжать работать в таких нишах дальше?
Мне кажется, что надо заниматься тем, что нравится и что интересно. А как это называется и вписывается в стандарты — не важно.

Часто в компаниях такая культура анализа, что «аналитик» нужен там, где разработчики «не хотят заниматься… ». А это уже не аналитик, а помощник менеджера по техническим вопросам, а часто и заместитель менеджера по всем вопросам=)
Тут вопрос со стороны кандидата решается гуглением тех же стандартов и вообще публикаций и сообществ аналитиков. А дальше уже каждый сам решает: хочет он быть таким аналитиком или нет.

Сейчас в IT такая нехватка аналитиков, что найти работу, где пригодится и будет оплачиваться имеющийся опыт и где можно развивать и прокачивать новое и интересное — вполне реально. Главное — брать на себя инициативу и ответственность за свою карьеру. Никто, кроме тебя самого, не виноват в том, что «вешают» все подряд — «кто везет, на том и едут». Не раз видела наглядные примеры этой пословицы.
роль аналитика самая несчастная в плане набора задач
Зависит от компании. Я не считаю роль аналитика самой несчастной.
Если аналитик довел себя до состояния супер-героя на проекте, значит что-то идет не так. Очень рекомендую на эту тему посмотреть доклад analystdays.ru/ru/talk/78352

всем, помимо непосредственно требований.
Есть полезный опыт. Если аналитик меньше 60% рабочего времени занимается анализом, значит что-то пошло не так. Ссылка на интересный доклад выше.
О полезном опыте
Опыт тестирования для аналитика полезен.
Когда ты приходишь на большой развивающийся проект и нужно раскопать как работает какая-то функциональность, то полезно самостоятельно дернуть запрос через Postman, проверить как UI и БД между собой связаны и т.п.
Сделать ревью тест-плана тоже хорошо.

Менеджмент — у кого-то бывает. Не самое приятное и полезное, но частенько скидывают это на аналитика (у нас не так, чему я очень рада). Из полезного — умение оценивать масштаб задачи.

Тех. писатель — аналитик должен уметь писать тех. документацию по ГОСТУ, но не 100% времени. Основная задача — проработка решения и его документирование (не оставлять же решение задачи в голове и на словах).


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


Надеюсь, что ответ будет полезен.
Спасибо за ответ и хороший вопрос!
Хочется отметить самое вопиющее: системным анализом может заниматься не любой член команды, а сотрудник, обладающий соответствующими компетенциями
Если говорим о проработке тех. реализации — нужны соответствующие скилы.
Если говорим о написании сценариев работы с системой, то могут помочь тестировщики (пример: поиск альтернативных кейсов) — тоже нужны соответствующие скилы. И разработчик, и тестировщик — участники команды, которые могут помочь в проработке решения.

Системный аналитик нужен там, где цена ошибки высока
Всё так
Это был комментарий про итоги из поста:
«Системным анализом для разработки ПО может заниматься как выделенный специалист, так и любой из участников команды.»

— что все-таки не любой, а специально обученный.

Ну «Причины появления аналитика» в посте:
"
  • Разработчики не хотят анализировать
  • Разработчики не хотят документировать
  • Разработчики не хотят общаться с заказчиком
"
Как-то возмутили. Такое ощущение, что аналитик — это человек, на которого сбросили работу, которую не хотят делать разработчики, просто чтобы угодить этим разработчикам.
любой, а специально обученный
Хотелось донести, что любой участник команды разработки может помочь.
В одном из ответов выше писала — нет желания замыкать задачу на аналитике и блокировать разработку из-за него, если он не успевает.

Причины появления аналитика
Это действительно одни из ряда причин, когда в компании задумываются о найме отдельного специалиста. Но это не значит, что к аналитику относятся как «мы скинем на аналитика то, что не хотим делать сами».
  1. Не хотят анализировать: вероятно, уже наступили на ошибки анализа, т.к. не хватало скилов (о чем Вы упомянули выше — высокая цена ошибки)
  2. Не хотят документировать: «Код — это и есть документация», а затем через 5 лет по нему не могут вспомнить как алгоритм должен работать.
  3. Не хотят общаться с заказчиком: анализ требований заказчика одна из задач аналитика, но обычно бизнес-аналитика, а не системного.

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