Comments 12
До чего отвратительная КДПВ! Это вы своих сотрудников за тараканов держите или тех компаний, которым своё поделие внедряете?
Спасибо за статью!
Есть парочка вопросов для разогрева:
1) А как же товарищ Вигерс (у него немного другой расклад)? Недавно третье издание подогнали, с эджайлом)
2) Правильно ли я понял, что системный аналитик проектирует вместо разработчиков? Не получится ли медвежья услуга им, что они разучатся сами проектировать? Или кодеры кодируют, а аналитики проектируют?
Есть парочка вопросов для разогрева:
1) А как же товарищ Вигерс (у него немного другой расклад)? Недавно третье издание подогнали, с эджайлом)
2) Правильно ли я понял, что системный аналитик проектирует вместо разработчиков? Не получится ли медвежья услуга им, что они разучатся сами проектировать? Или кодеры кодируют, а аналитики проектируют?
1) Вигерс писал: «Не существует выверенного способа написания идеальных требований, а лучший учитель это опыт, который нарабатывается со временем».
Всё зависит от продукта и команды. Делюсь тем, к чему пришли и как это помогает.
2) Проектировать вместо разработчика можно, но не нужно. Иначе получится ровно то, что Вы написали: кодеры и аналитики.
В процессе проектирования участвует команда, что позволяет не замыкать разработку и знания о продукте на одном человеке и проявлять творческие начала всем. Аналитик не блокирует разработку.
Системный аналитик — участник процесса проектирования. Он больше погружается в анализ и описание процессов, сценариев работы с системой, меньше в проектирование технической реализации, но умеет грамотно изложить ее и зафиксировать решение, анализирует взаимосвязи в продукте.
По итогам разработки аналитик у нас отвечает за сбор знаний — документирование продукта. Т.о. если результат работы разработчика — код и рабочее ПО, то результат работы аналитика — документация.
Всё зависит от продукта и команды. Делюсь тем, к чему пришли и как это помогает.
2) Проектировать вместо разработчика можно, но не нужно. Иначе получится ровно то, что Вы написали: кодеры и аналитики.
В процессе проектирования участвует команда, что позволяет не замыкать разработку и знания о продукте на одном человеке и проявлять творческие начала всем. Аналитик не блокирует разработку.
Системный аналитик — участник процесса проектирования. Он больше погружается в анализ и описание процессов, сценариев работы с системой, меньше в проектирование технической реализации, но умеет грамотно изложить ее и зафиксировать решение, анализирует взаимосвязи в продукте.
По итогам разработки аналитик у нас отвечает за сбор знаний — документирование продукта. Т.о. если результат работы разработчика — код и рабочее ПО, то результат работы аналитика — документация.
Спасибо за статью. Я так понимаю, тут представлены задачи и роли конкретно в компании «МойСклад» — оно довольно уникально во многих моментах, как и процесс проектирования. (Если сравнивать со стандартами, Вигерсом или другими компаниями).
Хочется отметить самое вопиющее: системным анализом может заниматься не любой член команды, а сотрудник, обладающий соответствующими компетенциями (это может быть и разработчик, но не все разработчики такими навыками обладают). Это отдельный вид деятельности, требующий своих hard и soft skills.
И системный аналитик как отдельная роль нужен не потому, что разработчикам лень писать документацию и учиться это делать (тут тоже есть свои скиллы и роль технического писателя). Системный аналитик нужен там, где цена ошибки высока, а система слишком сложна, чтобы разработчики помимо кода могли знать и понимать все нюансы функционала и процесса.
Хочется отметить самое вопиющее: системным анализом может заниматься не любой член команды, а сотрудник, обладающий соответствующими компетенциями (это может быть и разработчик, но не все разработчики такими навыками обладают). Это отдельный вид деятельности, требующий своих hard и soft skills.
И системный аналитик как отдельная роль нужен не потому, что разработчикам лень писать документацию и учиться это делать (тут тоже есть свои скиллы и роль технического писателя). Системный аналитик нужен там, где цена ошибки высока, а система слишком сложна, чтобы разработчики помимо кода могли знать и понимать все нюансы функционала и процесса.
Есть профстандарт, есть программы обучения (неплохая в Плехановке выпуска 2018 г.), есть Вигерс, есть OpenUP, Agile, SWEBoK.
Но, к сожалению, в большинстве компаний роль аналитика самая несчастная в плане набора задач. Т.к. аналитик — один из самых умных членов команды (не в обиду разработчикам) и при этом в идеале с высоким EQ, а также зачастую гиперответственный, то на него вешают всё что только можно.
В итоге человек вроде бы хочет и может заниматься требованиями, но занимается менеджментом, архитектурой, пишет документацию вместо тех. писателей, тестирует вместо тестировщиков и т.д. и т.п., всем, помимо непосредственно требований.
При этом вроде бы и правильно адаптировать процесс разработки под ресурсы и задачи, но ломать профиль, а иногда заодно и карьеру людей, — это вот ой.
Потом общаемся с таким человеком-оркестром, и он вообще всё знает про разработку, про микросервисы, схему базы может нарисовать, SQL на всех диалектах, XMLQuery и всё вот это вот. А кто такой Вигерс он даже не в курсе. Какие виды требований бывают и зачем, тоже может не знать. При этом старший или ведущий аналитик.
Как считаете, что делать дальше в таком случае? Переучиваться или продолжать работать в таких нишах дальше?
Но, к сожалению, в большинстве компаний роль аналитика самая несчастная в плане набора задач. Т.к. аналитик — один из самых умных членов команды (не в обиду разработчикам) и при этом в идеале с высоким EQ, а также зачастую гиперответственный, то на него вешают всё что только можно.
В итоге человек вроде бы хочет и может заниматься требованиями, но занимается менеджментом, архитектурой, пишет документацию вместо тех. писателей, тестирует вместо тестировщиков и т.д. и т.п., всем, помимо непосредственно требований.
При этом вроде бы и правильно адаптировать процесс разработки под ресурсы и задачи, но ломать профиль, а иногда заодно и карьеру людей, — это вот ой.
Потом общаемся с таким человеком-оркестром, и он вообще всё знает про разработку, про микросервисы, схему базы может нарисовать, SQL на всех диалектах, XMLQuery и всё вот это вот. А кто такой Вигерс он даже не в курсе. Какие виды требований бывают и зачем, тоже может не знать. При этом старший или ведущий аналитик.
Как считаете, что делать дальше в таком случае? Переучиваться или продолжать работать в таких нишах дальше?
Мне кажется, что надо заниматься тем, что нравится и что интересно. А как это называется и вписывается в стандарты — не важно.
Часто в компаниях такая культура анализа, что «аналитик» нужен там, где разработчики «не хотят заниматься… ». А это уже не аналитик, а помощник менеджера по техническим вопросам, а часто и заместитель менеджера по всем вопросам=)
Тут вопрос со стороны кандидата решается гуглением тех же стандартов и вообще публикаций и сообществ аналитиков. А дальше уже каждый сам решает: хочет он быть таким аналитиком или нет.
Сейчас в IT такая нехватка аналитиков, что найти работу, где пригодится и будет оплачиваться имеющийся опыт и где можно развивать и прокачивать новое и интересное — вполне реально. Главное — брать на себя инициативу и ответственность за свою карьеру. Никто, кроме тебя самого, не виноват в том, что «вешают» все подряд — «кто везет, на том и едут». Не раз видела наглядные примеры этой пословицы.
Часто в компаниях такая культура анализа, что «аналитик» нужен там, где разработчики «не хотят заниматься… ». А это уже не аналитик, а помощник менеджера по техническим вопросам, а часто и заместитель менеджера по всем вопросам=)
Тут вопрос со стороны кандидата решается гуглением тех же стандартов и вообще публикаций и сообществ аналитиков. А дальше уже каждый сам решает: хочет он быть таким аналитиком или нет.
Сейчас в IT такая нехватка аналитиков, что найти работу, где пригодится и будет оплачиваться имеющийся опыт и где можно развивать и прокачивать новое и интересное — вполне реально. Главное — брать на себя инициативу и ответственность за свою карьеру. Никто, кроме тебя самого, не виноват в том, что «вешают» все подряд — «кто везет, на том и едут». Не раз видела наглядные примеры этой пословицы.
роль аналитика самая несчастная в плане набора задачЗависит от компании. Я не считаю роль аналитика самой несчастной.
Если аналитик довел себя до состояния супер-героя на проекте, значит что-то идет не так. Очень рекомендую на эту тему посмотреть доклад analystdays.ru/ru/talk/78352
всем, помимо непосредственно требований.Есть полезный опыт. Если аналитик меньше 60% рабочего времени занимается анализом, значит что-то пошло не так. Ссылка на интересный доклад выше.
О полезном опыте
Опыт тестирования для аналитика полезен.
Когда ты приходишь на большой развивающийся проект и нужно раскопать как работает какая-то функциональность, то полезно самостоятельно дернуть запрос через Postman, проверить как UI и БД между собой связаны и т.п.
Сделать ревью тест-плана тоже хорошо.
Менеджмент — у кого-то бывает. Не самое приятное и полезное, но частенько скидывают это на аналитика (у нас не так, чему я очень рада). Из полезного — умение оценивать масштаб задачи.
Тех. писатель — аналитик должен уметь писать тех. документацию по ГОСТУ, но не 100% времени. Основная задача — проработка решения и его документирование (не оставлять же решение задачи в голове и на словах).
Когда ты приходишь на большой развивающийся проект и нужно раскопать как работает какая-то функциональность, то полезно самостоятельно дернуть запрос через Postman, проверить как UI и БД между собой связаны и т.п.
Сделать ревью тест-плана тоже хорошо.
Менеджмент — у кого-то бывает. Не самое приятное и полезное, но частенько скидывают это на аналитика (у нас не так, чему я очень рада). Из полезного — умение оценивать масштаб задачи.
Тех. писатель — аналитик должен уметь писать тех. документацию по ГОСТУ, но не 100% времени. Основная задача — проработка решения и его документирование (не оставлять же решение задачи в голове и на словах).
Как считаете, что делать дальше в таком случае? Переучиваться или продолжать работать в таких нишах дальше?Доучиваться, развиваться и искать место, где можно будет применить себя как специалиста системного анализа, а не позицию «многорукого шивы».
На собеседовании рекомендую задавать вопросы работодателю:
- А кто еще есть в команде?
- А как устроен процесс от момента получения требований до момента релиза, где подключается аналитик?
- А кто отвечает за планирование спринта?
Надеюсь, что ответ будет полезен.
Спасибо за ответ и хороший вопрос!
Хочется отметить самое вопиющее: системным анализом может заниматься не любой член команды, а сотрудник, обладающий соответствующими компетенциямиЕсли говорим о проработке тех. реализации — нужны соответствующие скилы.
Если говорим о написании сценариев работы с системой, то могут помочь тестировщики (пример: поиск альтернативных кейсов) — тоже нужны соответствующие скилы. И разработчик, и тестировщик — участники команды, которые могут помочь в проработке решения.
Системный аналитик нужен там, где цена ошибки высокаВсё так
Это был комментарий про итоги из поста:
— что все-таки не любой, а специально обученный.
Ну «Причины появления аналитика» в посте:
"
Как-то возмутили. Такое ощущение, что аналитик — это человек, на которого сбросили работу, которую не хотят делать разработчики, просто чтобы угодить этим разработчикам.
«Системным анализом для разработки ПО может заниматься как выделенный специалист, так и любой из участников команды.»
— что все-таки не любой, а специально обученный.
Ну «Причины появления аналитика» в посте:
"
- Разработчики не хотят анализировать
- Разработчики не хотят документировать
- Разработчики не хотят общаться с заказчиком
Как-то возмутили. Такое ощущение, что аналитик — это человек, на которого сбросили работу, которую не хотят делать разработчики, просто чтобы угодить этим разработчикам.
любой, а специально обученныйХотелось донести, что любой участник команды разработки может помочь.
В одном из ответов выше писала — нет желания замыкать задачу на аналитике и блокировать разработку из-за него, если он не успевает.
Причины появления аналитикаЭто действительно одни из ряда причин, когда в компании задумываются о найме отдельного специалиста. Но это не значит, что к аналитику относятся как «мы скинем на аналитика то, что не хотим делать сами».
- Не хотят анализировать: вероятно, уже наступили на ошибки анализа, т.к. не хватало скилов (о чем Вы упомянули выше — высокая цена ошибки)
- Не хотят документировать: «Код — это и есть документация», а затем через 5 лет по нему не могут вспомнить как алгоритм должен работать.
- Не хотят общаться с заказчиком: анализ требований заказчика одна из задач аналитика, но обычно бизнес-аналитика, а не системного.
Sign up to leave a comment.
О роли системного аналитика и шаблон для проектирования