Со школьного детства я увлекался программированием: школьные кружки по азам программирования, студии по соседству с домом и т.д. посещались мною с завидной регулярностью, все книги по программированию из серии «для чайников» были зачитаны до дыр, фильм «Матрица» стал любимым на долгие годы, я дошел даже до того, что решил сдавать ЕГЭ по информатике.
Но на семейном совете выяснилось, что иду я в местный вуз, в котором ничего похожего почему-то не было, а был вполне себе востребованный инженер КИПиА. Справедливости ради, времени на поиски работы по специальности я не тратил и устроился работать на последнем курсе, успев на тот момент еще и семьей обзавестись.
Работалось мне там вполне сносно пару лет, пока организация, в которой я работал — филиал довольно крупной фирмы, не решила свернуть все дела в нашем регионе. Был выбор: ездить на работу вахтовым методом или попытаться устроиться в другую организацию и надеяться, что уж она-то проработает долго. Вахта отпала сразу — жену пришлось бы оставить с двумя сыновьями на руках без помощи и перерывов на отдых, начал искать вакансии и, наткнувшись на зарплаты программистов, вспомнил о своей давней детской мечте. Я о ней за это время, в общем, и не забывал, новости читал, на специализированных форумах сидел, временами пытался кодить, ну под настроение получалось. А тут все обдумал и решил со второго дубля перейти в ту сферу, в которую давно хотелось.
Один из главных стимулов переходить в IT — безусловно зарплата.
Кроме того, в этой сфере много вакансий с удаленной работой, значит можно работать из дома, проводить время с семьей, не тратить время на дорогу, и холодильник, опять же, под боком. Понятно, что нужно будет многое доучить, а что-то выучить вообще с нуля, но я самонадеянно решил, что справлюсь.
Нашел вакансии, отправил резюме, пошел на собеседование. На первом же собеседовании в крупную контору угодил в компанию таких же соискателей, отдел кадров «не парился», видимо, и позвал всех на одно время. Вот именно там я и узнал о «темной стороне» программирования, я примерно все это представлял и раньше, но чтобы так.
В общем, в нашей веселой компании были и спецы с фундаментальным вузовским образованием, и народ — выпускники курсов из серии «как за две месяца с нуля стать крутым программистом» (правильный ответ — никак), и те, у кого был опыт серьезных проектов, и такие как я. Вот, что я выяснил, пока пытался наладить общение с будущими собратьями «по цеху».
Курсы: за 2 месяца из гуманитария в кодера, ничего не дадут, если гуманитарий реально начинает с нуля. С такими курсами на работу не возьмут даже джуном, если нет опыта серьезных проектов. За два месяца можно натренироваться делать сайты на конструкторе по шаблонам. Может вы на этом и сможете заработать, но уж наверняка не ту зарплату, о которой мечтали. И это не программирование, сайты на конструкторах типа Wix у нас в школе 53-летняя учительница русского и литературы делала, не напрягаясь, когда к открытым урокам готовилась.
Нужно минимум 2,5 — 3 года занятий обязательно. И только после такого периода обучения человека можно с натяжкой назвать начинающим специалистом (джуном), с зарплатой по регионам примерно 30000 рублей в месяц.
Вузовское обучение на программиста — тоже толку мало, если выпускник не работает по специальности параллельно обучению.
За 4 года обучения студента на бакалавриате в программировании все может поменяться просто глобально. К тому же в вузах зачастую преподают люди, довольно далекие от реальных разработчиков. Они не работают руководителями ИТ-компаний и вообще вряд ли принадлежат к ИТ-сообществу, они просто преподаватели, за плечами у которых скорее всего диссертации по педагогике, а не реализованные ИТ-проекты. Они не могут объяснить студентам какие-то современные понятия просто потому, что сами в них не разбираются.
Программист учится всю жизнь
Нельзя один раз и навсегда выучиться на айтишника — учиться придётся всю оставшуюся карьеру. и это не повышение квалификации, как в других специальностях, проходящее, причем, в рабочее время. Нет, программист должен все время быть в курсе происходящих в ИТ перемен за счет своего личного времени, если хочет быть востребованным. Технологии, язык, фреймворк могут устареть через пару лет, а то и раньше. Учите несколько лет, а потом в одночасье ваши знания обесцениваются.
Недавняя новость о том, что Python из лидеров внезапно вытеснил начатый забываться многими JavaScript и из-за этого британские компании перестали брать на работу программистов с Python — это привычный поворот событий для всей отрасли в целом. Один язык вытеснил другой или появился новый, тут уже не повысишь квалификацию, нужно сидеть после трудового дня и учить то, что не знаешь, иначе останешься без работы.
Источник: dzen.ru
Умный аналитик – глупый разработчик vs. глупый аналитик – умный разработчик
Как-то раз мой коллега, лид разработки, после затяжного спора о том, что должно быть в системной спецификации, подошел ко мне и спросил:
— Скажи, а зачем нам вообще нужны аналитики?
— И действительно, зачем? – подумал тогда я и написал заявление
Вопрос этот, как бы крамольно он ни звучал, очень правильный. Системный анализ, как фаза разработки приложения, присутствует всегда (даже если это системы класса «Hello, world»), а вот системный аналитик, как выделенная роль – нет.
Выделение отдельной специальной роли работает точно так же, как и разделение труда в обычном производстве: для маленьких задач не целесообразно, для больших задач – оправданно. При таком разделении системный аналитик забирает на себя часть задач и функций некоего «универсального» исполнителя задачи. Однако, подобное разделение труда имеет свою цену: это потеря знаний при коммуникации, более сложное управление процессом и др. В этой статье я хочу поделиться своим опытом: описать минусы крайностей и дать рекомендации по распределению обязанностей между системными аналитиками и разработчиками.
Итак, нам нужен системный аналитик, который формирует требования и разработчик, который эти требования реализует в коде.
Если спросить у любого разработчика, каким главным свойством должны обладать системные требования, он, скорее всего, скажет: «чтобы было понятно, что делать». И это проблема.
Заключается эта проблема в том, что между сбором и систематизацией требований (прямая и понятная задача аналитика) и непосредственно кодированием (прямая и понятная задача разработчика) есть область проектирования решения; задачи из этой области могут и должны выполнять обе роли.
Вопрос – как провести границу? Как выбрать такую степень детализации требований, при которых это будет максимально полезно разработчику и не будет содержать ненужной и избыточной информации?
Начнем с описания сложностей, которые могут возникнуть, если степень детализации будет выбрана не оптимально. Под «глупым» и «умным» участником процесса я подразумеваю не интеллект или профессиональные навыки, а степень погружения в процесс проектирования и контроля над реализуемым решением.
Глупый аналитик, умный разработчик
Аналитик формулирует только функциональные требования («система должна уметь…»), сама система для него представляется черным ящиком, она или умеет что-то, или нет. В этом случае проектирование самого решения перекладывается на плечи разработчика. К чему это может привести:
Риск высокой стоимости решения. Аналитик не знает, какое из его требований реализуется просто и дешево, а какое – сложно и дорого; у него нет возможности в процессе формирования ожиданий у заказчика/пользователя предложить и защитить решение, которое решает бизнес-задачу не хуже, но стоит сильно дешевле.
Например, желание пользователя получить автоматически обновляемые данные на форме может стоить разработки сложного и дорогого механизма по отслеживанию изменений данных, при этом реализация обновления данных по нажатию кнопки будет на порядок проще;
Риск попасть в технические ограничения. Аналитик не знает, привели ли ранее выставленные им требования к технологическим ограничениям в разрабатываемой системе. Разработчик может выбрать то решение или технологию, которые подходят для текущего набора требований; любое решение или технология накладывают ограничения – какие-то задачи решаются легко и удобно, какие-то сложно и дорого. Отсутствие понимания ограничений может привести к согласованию с заказчиком и выставлению практически нереализуемых требований;
Недостаточная проработка. Для решения ряда задач, особенно интеграционных, требований уровня «система А должна запросить у системы Б такие-то данные» недостаточны: разработчику в этом случае придется на себя взять поиск или формирование интеграционного контракта, его согласовать и распространить в каком-то виде эти знания внутри собственной команды разработки. А это – не профильные для разработчика активности, которые мог бы взять на себя аналитик;
Неудобная форма подачи. В ряде случаев, для того чтобы требования были полными и логичными, аналитик должен выбрать какую-то форму описания требований и описать их достаточно детально, фактически спроектировать решение. Если это решение не согласуется с архитектурой приложения, то, во-первых, разработчику придется тратить время и силы на перевод “писанины” в нужное ему знание, а во-вторых, сам аналитик будет тратить силы и время на те детали, которые никто не будет читать и использовать. Например, описание модели данных: аналитик описывает реляционную модель данных, создает дополнительные конструкции для связей, требования к отчетам пишет в виде SQL запросов, а разработчик, использующий объектную модель и ORM, вынужден это переводить;
Ограничения в тестировании.Тестировщик не сможет получить из требований такого уровня достаточно информации о том, как должна работать система — лишь о том, что она должна уметь, а это разные вещи. При таком подходе выше риск возникновения ситуации, при которой система требованиям формально удовлетворяет, но на практике решение не удобно или не оптимально.
Умный аналитик, глупый разработчик
Другая крайность при распределении функций – это слишком большая степень свободы для аналитика в части проектирования решения. Аналитик описывает алгоритмы на псевдокоде, пытается оперировать такими абстракциями, как слои приложения, описывает какие-то сервисные механизмы, определяет типы данных и формат обмена данными внутри приложения, суть требований скрывается за предложенными решениями. У этого подхода тоже есть серьезные минусы:
Нет возможности проверить корректность. Разработчик не видит картины в целом, не понимает, зачем он делает ту или иную задачу: ему приходит спецификация, содержащая алгоритм на псевдокоде, правильность/адекватность которого он не может проверить. Это повышает риск ошибки со стороны разработчика и не позволяет провести ревью (аналитики ошибаются и осознанное прочтение разработчиком документации позволяет это выявить);
Избыточная проработка. Системная спецификация может содержать детальное низкоуровневое описание алгоритмов работы с данными, которые разработчик не будет реализовывать. Например, не нужно описывать алгоритм вычисления количества дней между двумя датами или дня недели по дате (привет школьные олимпиады) – для большинства таких задач есть готовые решения;
Лишняя работа ради стройности описания. Хорошо и правильно, когда ТЗ или спецификация имеют примерно одинаковую глубину для всех функциональных блоков; в этом случае читающему проще понять, на какие вопросы документ может ответить, а на какие – нет. Этот подход очень быстро может затянуть аналитика в бессмысленный и беспощадный процесс описывания вообще всего на свете: как читать данные из файлов, как называть внутренние классы и т.п. Есть ряд задач, которые аналитик в большинстве случаев просто не должен описывать и сервисные/инфраструктурные функции – одна из них;
Риск потери актуальности документации. В случае если разработка решит провести рефакторинг, заменить фреймворк или какой-то модуль в приложении, слишком «близкая к коду» спецификация может стать неактуальной и неверной, причем в большом объеме. В каком-то объеме спецификации будут устаревать в любом случае, это процесс — как инфляция, но если можно не усугублять, то нужно не отказываться от такой возможности;
“Режим бога” и неадекватное восприятие границы компетенций. В ряде случаев аналитику может просто не хватить технических знаний или опыта, но так как он привык, что в его команде он «умный» и никто кроме него, он может поддаться соблазну изобрести свой собственный велосипед из костылей. Этот аспект не совсем технический, но потому он особенно важен и коварен. Проблема оценки собственной компетентности вообще довольно остро стоит перед человечеством и системный анализ — не исключение.
И что делать?
Нет на свете хуже статей, чем те, в которых поднимается проблема, а в качестве решения говорится, что все случаи разные и надо смотреть по ситуации. Я хочу привести несколько приемов и рекомендаций из своей собственной практики, которые оказались полезны и действенны.
Рекомендация первая. Она звучит настолько банально и скучно, что кажется, что в ней нет никакой магии (а она есть): спросите у своих разработчиков, что они хотят или не хотят видеть в документации. Тут штука в том, что если спросить в лоб, то в 99% случаев будет ответ «Ну, чтоб было понятно, что делать». Более эффективно будет встретиться с лидом команды (или с основными ее участниками) и проговорить несколько ключевых моментов, которые встречаются почти в каждом проекте, особенно, в корпоративной разработке.
Приведу некоторые из тех вопросов, которые я стараюсь проговорить при взаимодействии с новой командой.
- Архитектура приложения / стек технологий. Какой используется язык? Как выглядит приложение изнутри? Это монолит или набор сервисов? Если набор сервисов, то как взаимодействуют между собой? Что из себя представляет фронт-энд? Как лучше разделять логику между фронтом и беком? Нужно ли описывать REST API для фронта? …и еще десяток вопросов, которые появятся после ответов на указанные выше. Попробуйте визуализировать приложение, попросите нарисовать. Если ранее с таким не сталкивались, попробуйте вместе с разработчиком проговорить один какой-нибудь кейс. Например: «пользователь открывает форму, что-то вводит, сохраняет, получает результат. Расскажи, как это будет реализовано, какие компоненты будут задействованы, куда пойдут данные». Разбор одного такого кейса даст огромный прирост в понимании того, из каких частей состоит приложение и как их можно/нужно дорабатывать.
- Модель данных. Как построено взаимодействие с данными? Это прямые SQL запросы из кода или работа с объектами? Используется не-SQL хранилище? А как с ним работать, что там хранится? Нужно ли в спецификации описывать классы с их атрибутами максимально близко к коду или лучше использовать логические абстракции? Если абстракции, то, как быть с типами данных, нужно ли указывать? Нужен ли маппинг классов на таблицы?
- Форматы сообщений для сервисов между компонентами системы: XML или json? Нужны ли xsd и json схемы? Нужны ли описания всех возможных ошибок для REST API? Насколько детальное описание взаимодействия нужно для подключения к внешним сервисам?
- Декомпозиция функциональных блоков. Как лучше делить? Описывать бизнес сценариями или самостоятельно выделять общие куски?
- Нужно ли бизнес-описание задачи? Будет ли оно полезно? Будут ли его читать?
- Нужны ли эскизы форм? Насколько детально? Нужны ли реальные размеры? Что позволяет UI фреймворк? Можно ли использовать «модальные окна»? Можно ли использовать веб-сокеты?
Одна такая сессия с конкретными разработчиками вашей команды даст ответов больше, чем стопка книг по системному анализу, потому что это будут максимально релевантные ответы под конкретный проект с конкретными людьми. Опытный системный аналитик может очень хорошо и правильно сформулировать набор требований к системе – непротиворечивых, атомарных, исполнимых и так далее, но для того, чтобы они были реализованы, их нужно донести до разработчиков. И вот такой экспресс-опрос повысит эффективность коммуникации между аналитиком и разработчиком как мало что другое.
Рекомендация вторая. Нужно смотреть по ситуации. Точную идеальную степень вовлечения определить невозможно (даже ретроспективно, после внедрения), но есть некоторые признаки, которые позволят понять, стоит ли пытаться захватить полный контроль над проектом или достаточно будет «система должна позволять…». Речь идет, конечно, не о крайностях, а об оттенках.
На мой взгляд, следующие факторы говорят в пользу подхода «Умный аналитик – глупый разработчик»:
- Приложение или крупный функциональный блок проектируются с нуля (т.е. начало проекта), у разработчиков еще нет понимания, как все будет реализовано
- Команда разработки относительно многочисленна (>3 человек), нужна точка консолидации знаний
- Разработчики имеют низкую или среднюю квалификацию
- Разработчики работают или удаленно, или не полный день, или были привлечены только на этот проект – у них нет особой экспертизы в данной бизнес области и, возможно, нет особой мотивации ее приобрести: «внедрил – ушел»
- В проекте большое количество интеграционных взаимодействий с другими системами – нужно все это координировать
- В проекте очень часто меняются требования и нужна отдельная активность по управлению изменениями. Требования везде меняются, но иногда – настолько часто, что одно только отслеживание и учет изменений может занимать кучу времени
- Есть желание стать незаменимым членом команды и спекулировать на этом. Будем честны, это тоже аргумент.
Подход «глупый аналитик – умный разработчик» оптимален, как можно догадаться, в противоположных случаях:
- Аналитик подключается на фазе доработки или поддержки уже имеющейся системы, у команды сформирован подход и принципы разработки, они хорошо знают систему и им нужны только функциональные требования
- Разрабатываемая система довольно изолированная, каждый разработчик в команде со временем становится владельцем почти полного набора знаний о ней
- Практикуется подход итеративной/водопадной разработки, когда у команды разработки есть время спокойно спроектировать все, все новые функции аккуратно вписать в имеющуюся архитектуру. Казалось бы, как связаны методология разработки и степень вовлечения аналитика? Мой опыт показывает, что когда набор требований (хотя бы примерно) известен на целый релиз вперед, внутри команды (здесь я имею в виду и аналитиков и разработчиков) формируется некоторое общее видение решения и сильно большая и глубокая детализация не то, чтобы вредит – просто не требуется. У недостаточно детальных требований есть свои недостатки, но на подготовку релиза в такой размеренной и спокойной ситуации они имеют меньшее воздействие.
- Аналитик подключается частично, не на полное время или для решения какой-то конкретной задачи. Переделывать или ретроспективно документировать все что можно — не лучшая идея.
- Аналитик имеет низкую техническую квалификацию. В системном анализе, как в медицине, главное – не навредить. Если вы не понимаете, как на низком уровне работает какой-то механизм, не пытайтесь изобрести для него собственный алгоритм; скорее всего, разработчик не будет его реализовывать, а использует какую-нибудь готовую библиотеку. Разумеется, для вас это сигнал к тому, что хорошо бы понять принцип его работы, но если это не удается сделать быстро – то лучше в другой раз
- В проекте всего один разработчик, сильный, все знает и умеет и от вас нужны только функциональные требования. Может быть немного обидно, но если вспомнить, что миссия системного аналитика как роли – повысить эффективность разработки, то в том, чтобы вовремя остановиться, больше профессионализма, чем в попытке (пусть и успешной) доказать, что вы бы могли спроектировать не хуже, а то и лучше.
Рекомендация третья. Спросите у разработчиков по итогам некоторого периода совместной работы, все ли им понравилось и нести ли десерт. Как правило, если разработчик получает необходимую ему информацию из спеки или ТЗ, он этим остается доволен, а лишнее просто игнорирует или приспосабливается к трансформации написанного в нужное. Выяснив по итогам релиза или какой-то крупной итерации, что было удобно и полезно, что было лишним, а что лучше излагать по-другому, можно сделать взаимодействие в последующих итерациях сильно более эффективным; там, как правило, выясняется, что часть вещей, которые вы описывали каждый раз, они давно не читают, на степень детализации это не влияет и можно в будущем просто сэкономить время.
Причем, если договариваться о правилах игры надо с лидом, то получать обратную связь лучше от рядовых разработчиков, так как лид сам может всего этого не прочувствовать. Кроме того, если лиду что-то не понравится, он, скорее всего, скажет сам, а рядовой исполнитель – нет. Мне вот, после пары таких сеансов обратной связи, хотелось сказать: «что ж ты молчал все это время?»
Если история про «захватить проект и спекулировать на этом» — ваш случай, то положительная обратная связь только усилит ваши позиции: все всегда сможете сослаться на мнение команды разработки, заявив, что ваши решения проверены временем и их эффективность подтверждена командой.
На этом, пожалуй, все. Хочу еще раз обратить внимание, что как бы это ни звучало, но при разработке ПО в качестве роли системного аналитика быть полезным лучше, чем быть «умным» — как по мне, так это самый главный признак профессионализма.
- системный анализ
- процесс разработки
Источник: habr.com
Аналитик мне не нужен, я сам знаю, какой продукт хочу
Всем привет! Меня зовут Ася, я системный аналитик в ИТ-компании Amiga. Нередко приходится объяснять клиентам, зачем аналитик на проекте. Поэтому я решила раз и навсегда поставить точку в этом вопросе.
В статье расскажу, что делает аналитик, когда он действительно необходим, а когда можно обойтись без него. Думаю, будет интересно всем, кто сталкивается с заказной разработкой и хочет выпускать классный продукт. А еще приглашаю прочитать тех, кто пробует себя в системной аналитике.
Если кратко, аналитик — переводчик с человеческого языка на «разработческий». Он документирует желания заказчика так, чтобы разработчики думали только о том, как написать код, а не о том, какой функционал скрывает эта фича, какой итог должен быть при реализации этой фичи.
Что делает аналитик?
- Классифицирует желания клиента в различные требования к системе. Помогает заказчику понять, какие требования приоритетны, а какие можно отложить в стол до следующих релизов.
- Следит, чтобы заказчик и разработчики понимали, какой продукт должен получиться. Например, какая бизнес-логика прослеживается в системе.
- Не дает заказчику делать всё, что заблагорассудится. Особенно, когда бизнес-заказчик и владелец продукта — два разных человека. Эту функцию можно проиллюстрировать вот таким диалогом из практики:
— Давайте в первом релизе сделаем чат, в котором можно 1) проводить конференции, 2) публиковать истории, 3) создавать ленту, 4) с темной и розовой темой.
— Если после первого релиза сервиса пользователи скажут, что нужен чат с такими функциями — мы его реализуем. Но сейчас давайте сосредоточимся на целевой функции проекта — продажа б/у ноутбуков.
Оригинал картинки: vk.com/lepragram
4. Не дает разработчикам делать всё, что заблагорассудится. Разработчики — творческие люди, они хотят оставить свой след в проекте. Некоторые оставляют его молча, и на выходе получается странная композиция для бизнес-процесса. В нашей компании разработчики все свои мысли высказывают на командных встречах.
Аналитик собирает, отделяет зерна от плевел (программисты не так сильно погружены в бизнес-процесс). На встрече с заказчиком аналитик спрашивает, нужна ли реализация этих предложений или нет.
5. Аналитик экономит время и деньги. Заказчик может не знать, что на рынке уже существует готовое решение его проблемы, а разработчики могут подключить к системе существующий необходимый функционал за небольшую плату. Выйдет быстрее и дешевле.
6. Приводит требования к единому шаблону, используя нотации и общепринятые методики проектирования систем. Схемы, которые использует аналитик, должны быть точно поняты разработчиком. Не всегда клиенту нужно в них разбираться. Но понимать легенду схем одинаковым образом должна вся команда проекта. За этим следит аналитик.
Оригинал картинки: texterra.ru/blog
Что происходит на проектах без системного аналитика?
1. Работу аналитика берет на себя менеджер проекта. Для него это дополнительная нагрузка, поэтому страдает качество проекта: многое не протоколируется, техническая документация ведется несвоевременно, актуализацией существующей документации заниматься некогда.
Как результат: перегруженный менеджер, плавающие сроки у проекта.
2. Нет четкого понимания архитектуры сервиса и согласованной документации. Клиент не видит общую картину проекта, какая функция будет разрабатываться на каком этапе. Баз фиксированных требований любое изменение вносит хаос в проект, так как изменением нельзя управлять.
Как результат: недовольный заказчик, непопадание в изначальную оценку по срокам и стоимости, демотивированная команда — никому не хочется несколько раз переписывать код или перерисовывать макеты. Плюсом, никто не знает, что реализовано в системе, только разработчик, который непосредственно это делал.
3. Нет понятно описанных сценариев, которые учитываются при дизайне и разработке и описания проекта в целом. Поэтому возникают дополнительные вопросы и баги.
Как результат: увеличивается время на коммуникацию заказчика с исполнителем, повышается стоимость проекта при T
— проект действительно небольшой, команда разработчиков и менеджмента сильная, а заказчик точно уверен, что не захочет масштабировать свой продукт.
Во всех остальных случаях следует подключать аналитика. Он в разы уменьшает вероятность того, что проект пойдет в стол.
Ася Васильева
Системный аналитик
14 комментариев
Написать комментарий.
За такой вот диалог с заказчиком в стиле «Заткнись и не мешай нам работать, мы лучше тебя всё знаем», я бы аналитика уволил с проекта.
Развернуть ветку
Добрый день!
Спасибо за комментарии, поясняю более подробно.
Была ситуация, когда мы хотели запустить MVP и скорость была максимальна важна. А заказчик хотел добавить функции, которые не приоритеты, в первый релиз.
Таким мини — диалогом я и хотела показать, что аналитик в том числе может управлять ожиданиями заказчика.
Я считаю, что аналитик в том числе должен понимать приоритетность реализации функционала и высказывать свою точку зрения.
Конечно, делать это нужно не в таком агрессивном формате. Диалог был сокращен до нескольких уместных предложений для сноски в статье и переработан в более шуточной форме.
Если Вы считаете иначе, я была бы рада услышать Вашу точку зрения.
Развернуть ветку
Вы и сами за меня написали — «Конечно, делать это нужно не в таком агрессивном формате». Если вы делаете такую вот гайдообразную статью, а не ералаш, нет смысла создавать паттерн поведения аналитика как хама.
Развернуть ветку
Я учту подобные кейсы в следующих статьях
Это первая моя работа в подобном формате и сразу же выявлена точка роста. Благодарю!
Развернуть ветку
Аккаунт удален
Развернуть ветку
Думаю, что ключевой посыл — то, что аналитик может сказать «нет», и подготовить к такому исходу любого заказчика. Ну проиллюстрировано это кратко-лаконично-неформально, но смысл все уловили 🙂
Развернуть ветку
Ну проиллюстрировано это кратко-лаконично-неформально, но смысл все уловили
За высказывания в духе «ну всем и так всё понятно, что тут усложнять» аналитика нужно еще раз уволить
Развернуть ветку
Хорошо наверное быть анонимчиком и не отвечать за свои слова 🙂
Развернуть ветку
Работу надо работать, а не чушь писать несусветную. И это ко всем относится.
Развернуть ветку
Ссылаться на разные школы видится уклончивой идеей, дедушка Вигерс все же выстрадал основы.
В масштабных межсистемных интеграциях процесс чуть более изменчивый. В кейсах из статьи можно немного сократить процесс.
Последовательность базовых артефактов в сис./бизнес анализе:
BRD — Scope^Vision — FSD — SRS
Если на первых двух этапах написано гумно, то высок шанс получить в результате нерелевантное гумно.
И шаблон BRD, который отдаётся заказчику и позже с ним валидируется — это must have. Иначе продолжите собирать требования в чатиках.
Развернуть ветку
Аналитик — важный человек в команде. Порой очень много интересного и неожиданного раскапывает
Развернуть ветку
После первого кликбейтного абзаца было закрыл страницу, но вернулся и прочитал.
Забавно, что в мировой практике функции system analyst’а выполняют люди, именующиеся вовсе по-другому,
зато в России, где «системный аналитик» прижился, напротив — его функции сильно плавают.
Развернуть ветку
Спасибо за статью, интересно было почитать. Много информации и она по делу.
В общем и целом во мне откликнулось, что вы изложили.
Интересно было бы подискутировать про понимание разработчиком того, чего он кодит. Вы пишите:
Если кратко, аналитик — переводчик с человеческого языка на «разработческий». Он документирует желания заказчика так, чтобы разработчики думали только о том, как написать код, а не о том, какой функционал скрывает эта фича, какой итог должен быть при реализации этой фичи.
Я же наоборот, рассказываю максимум информации, и в том числе, зачем нужна та или иная задача. Более того, наша команда ознакомляется с требованиями, сценариями. И разработчики в том числе. Так мы добиваемся понимания у всей команды, что мы тут делаем; плюс выполняем проверку требований на возможность реализовывать, протестировать.
Следующее что хочется отметить, это про участие аналитик в пресейле — это когда проекта еще нет. Менеджер на старте проекта практически всегда привлекает архитектора, аналитика, разработчика, тестировщика. Привлечение может быть в разной конфигурации, в зависимости от полученных вводных от Заказчика.
И последнее, хотела бы сказать, что без аналитика нельзя. Как и без другого участника команды. Но это необязательно должны быть отдельные люди и/или отдельные команды. Невозможно без аналитика как роли в команде.
А эти роли могут совмещаться. Менеджер может быть и аналитиком. Или разработчик может выполнять роль аналитика. Или аналитик выполнять еще и роль тестировщика. Комбинаций может быть много, зависит от проекта, от людей.
Источник: vc.ru