Комментарии 27
Однако второго способа недостаточно в случае проектирования алгоритмов действий, когда один или несколько исполнителей - это люди, которые могут забыть, передумать, ошибиться и т.п.
Можно добавить механизм генерации помех и его влияние на алгоритм(ы) на разных этапах.
Сторонники: умение/владение языком программирования позволяет делать более качественные ТЗ
Голосую обеими руками за. Кто-то сказал (уже не помню кто): "Аналитик - это непрограммирующий программист".
умение/владение языком программирования позволяет делать более качественные ТЗ
ТЗ и язык вообще должны быть ортогональны. Одно и то же ТЗ должно быть реализуемо на любом современном промышленном языке.Чтобы этого добиться, нужно знать не языки, а стандарты и лучшие практики. Я в свое время досыта наелся аналитиков, которые не вдупляли разницу например между синхронным и асинхронным взаимодействием. Писали жуткую ахинею в ТЗ. Знание синтаксиса какого-нибудь питона помогло бы им примерно никак.
Мне так видится, хорошие специалисты вообще должны бы обладать кругозором и иметь представление о работе смежников. Но глубокие знания конкретного языка, который используется для реализации по спекам, не обязательны. Это хлеб разрабов. Более того, при написании ТЗ как уже упоминали в комментариях, надо ориентироваться на стандарты, лучшие практики и собственное, полученное из опыта, представление о гармоничной системе. А попытка сделать "удобно" для реализации в конкретном ЯП может увести в сторону от этих позиций.
Программист без труда может быть аналитиком, аналитик вряд ли сможет программировать.
Вообще программист и должен общаться с заказчиком. То что программисту нужно это бюрократ 20 уровня, что б не забивать голову административной ерундой. Из за того что аналитики общаются с "боссами" у них начинает неимоверно расти чсв, перехватывают управление и начинается дичь.
К сожалению, далеко не каждый программист может стать аналитиком. Большинство программистов думают "как это запрограммировать", а аналитики думают "зачем это нужно и как можно это не программировать". Программисту каждая задача кажется "гвоздем", грубо говоря.
Ну знаете, аналитики тоже разные бывают, по границам своих должностных обязанностей на проекте. У некоторых такая ограниченная роль, что в своей работе они сконцентрированы на том, "как" нужно покрыть требования; а вот "что" и тем более "зачем" продумали ещё до того, как задача дошла до них. Вероятно, программисту было бы проще войти в такую роль... но возникает вопрос "Нафига?!"
про "без труда" это конечно хорошая шутка. Учитавая что в среднем у аналитика обычно примерно 4 часа в день - это митинги и разговоры с разными стейкхолдерами, нормальных программистов от такого обычно тошнит
Спасибо за статью!
Верно подмечено, что под "системным аналитиком" в разных компаниях понимают разное, поэтому ответ на вопрос надо ли уметь программировать зависит от совокупности факторов
- зона ответственности аналитика
- какие вообще роли есть в команде
- специфика разрабатываемого продукта
- насколько опытные разработчики в команде
- и т.д. и .т.п.
Но с точки зрения профессионального развития системного аналитика, даже если сейчас и работаешь в компании где нет потребности знать программирование, было бы здорово хотя бы на базовом уровне изучить, дабы быть конкурентоспособным на рынке труда.
Вообще немного спорный конечно момент, но должен ли аналитик прогать тут скорее ответ нет, ибо эту роль выполняют разрабы которые явно опытнее в этой области, да и в целом диктовать аналитику как писать код разрабу немного дико как по мне, ну по крайней в моей команде так, как и пытаться писать алгоритмы на том или ином япе (ещё и в ТЗ/СТ это указывать) , другое дело правильно описать его схематично, чтобы любой человек глянул ст/тз и понял его смысл, да в том же бпмн вполне ок, проектирование апи и бд тоже маст хэв для аналитика это не какой то супер сложный навык, тут скорее важно понимание почему так надо и для чего это, но и опять же надо исходить из задач и самого проекта, условно мои разрабы пишут на шарпе/реакте внутренние инструменты с порой сложной логикой и алгоритмами и моя задача просто правильно интерпретировать требования бизнеса и что они вообще хотят, а в код я вообще не лезу, ну разве что по фронту и то исключительно в целях саморазвития
Напишите, пожалуйста, комментарии к содержанию статьи, а не к названию.
А зачем же вы дали статье такое название, что оно не точно соответствует её содержанию? ;)
Мой опыт работы в роли системного аналитика в разных проектах показывает, что понимать принципы программирования (объектно-ориентирование / структурное, типы данных, алгоритмистика и пр.) способствует повышению качества процесса и результата той самой работы. Но, согласитесь, понимать принципы не то же самое, что знать какой-то язык программирования и тем более уметь на нём программировать!
Очевидно, что на некоторых проектах есть потребность в аналитике, который бы сам писал код для специфических задач - как в вашем примере, для разработки моделей данных и алгоритмов, - но это скорее исключение, которое не вписывается в типовой набор задач аналитика в ИТ.
Мне кажется, подвох здесь кроется в том, что означает - быть программистом. Должен ли аналитик собственноручно писать программы, и оттачивать нюансы использования библиотек? На мой взгляд - нет. Безусловно, аналитик должен хорошо знать очень много вещей, но не так глубоко как программист. Хорошие программисты, специалисты своего дела - постоянно углубляют свои знания в выбранной области специализации, в то время как от аналитика, требуется не столько глубина, сколько широта знаний. Хороший аналитик ценен тем, что способен находить решения на стыке множества областей и технологий. И недостаток знаний специфики той или иной области компенсируется умением получать нужную информацию, в том числе и у тех кто лучше всего в этом разбирается. Но для того чтобы понимать, что отвечают специалисты, аналитик должен погружаться в каждую исследуемую область. Здорово если аналитик вырастает из программиста, но очень плохо, если аналитик тянет в свою работу наработанные подходы и продолжает следовать им не пытаясь выйти из колеи. Ну и из личного опыта, колоссальный рост для аналитика и архитектора дает изучение парадигмы функционального программирования. Сама идеология фп заставляет в первую очередь думать над функциями верхнего уровня и обеспечивающими их структурами данных, не отвлекаясь на нюансы конкретных реализаций. Фактически фп заставляет самостоятельно формировать язык описания предметной области в терминах которого решается задача. Это сильно способствует развитию аналитического восприятия задачи. И вовсе не обязательно реализовывать проект на фп. Ведь аналитик не пишет программы, его задача максимально подробно формировать для пользователя и разработчика непротиворечивую модель предметной области.
Публикации
Нужно ли ИТ-аналитикам уметь программировать