Изготовление сценического оборудования (фермы , арки , крепежи и прочее).
Восхитительно, какие разнообразные профессии представлены на Пикабу, особый привет всем коллегам, занятым в строительной сфере.
Радует видеть в ленте Ваши усталые и счастливые лица, потому присоединяюсь:
инженер, архитектор, специалист зоологического планирования.
Самые лучшие моменты в работе - выезды на объекты.
Мужчина 35 лет
— Мой отец - очень тяжелый человек: как он решил, так и будет. Если кто-то пытался сопротивляться - применял любые методы, чтобы заставить делать как он хотел. Собственно говоря, у него имелось определенное представление о том, как я должен был жить и он всеми силами удерживал меня в «нужном» направлении.
— Полагаю, им двигали самые благие намерения.
— В этом сомневаться не приходится: он всегда хотел, чтобы я крепко стоял на ногах, обзавелся семьей и мог противостоять жизненным невзгодам, - нахмурившись, ответил клиент. - Поэтому он отправил меня получать рабочую профессию – сварщика. Еще тогда он предвидел, что такие специальности станут дефицитными.
— Действительно мудрое решение. А что по этому поводу говорила ваша мать?
— Она всегда поддерживала мужа, - глухо произнес Дмитрий. - Не помню ни одного случая, когда бы она говорила что-то поперек него, даже когда мы оставались одни. Наверное, поэтому я всегда был на нее обижен - пока другие ребята учились на юристов или программистов, я должен был по колено в грязи с красными глазами варить очередную трубу.
— Вы были рассержены на родителей и винили их за эту несправедливость.
— Именно так я и думал многие годы, - горько усмехнулся мужчина. - После училища, я попал в армию, нормально отслужил, вернулся и пошел работать в управление городским хозяйством. Работа была собачья, так что я бросил это дело и в конец разругался с отцом, дело даже до драки дошло. Плюнул на все и снова пошел в армию, на этот раз по контракту, отслужил весь срок, но понял, что это тоже не мое и, вернувшись обратно, крепко задумался о том, что же делать дальше.
— Но на этот раз у вас уже имелся довольно большой жизненный опыт.
— Только вот его не хватило на то, чтобы не наделать глупостей. Пришлось покататься по стране, работать в разных местах, прежде чем судьба дала мне еще один шанс: знакомый позвал с собой поработать вахтовым методом на севере. Терять мне было нечего, я и отправился, а там меня спросили, что умею, сказал, могу варить - так я снова стал сварщиком. Но теперь мне за это неплохо так платили, а заодно уважали - чего раньше не было.
— Возможно, дефицит квалифицированных рабочих стал еще больше?
— И это тоже, - кивнул Дмитрий. - Но думаю тут дело в том, что я возмужал - кто же будет с уважением относиться к юнцу, только выпустившемуся из лапшака? Я неплохо заработал, снова вернулся в Питер и открыл тут небольшую мастерскую. Это, конечно, не полет фантазии, но на хлеб с маслом хватает. Даже сумел найти себе хорошую женщину - пару лет назад она родила сына, и мы никак ему не нарадуемся. И все, потому что у меня есть хорошая профессия.
— Получается, ваш отец был прав?
— Марк Твен однажды сказал: "Когда мне было восемнадцать лет, мой отец был дурак дураком. После тридцати я заметил, что старик здорово поумнел". Так у меня та же самая история, вот только к тому времени как я это понял, его уже не стало, - в глазах мужчины стояли слезы. - Мы не общались целых десять лет, и я столько гадостей ему наговорил перед уходом, что теперь мне так горько…
— Уверена, несмотря на то что вы перестали общаться, он все равно гордился вами, - после этих слов Дмитрий закрыл лицо руками и беззвучно заплакал. - Вы стали именно таким человеком, каким он хотел вас видеть.
— А я даже не пришел к нему на похороны, - сквозь рыдания, выдавил он. - Мог прийти, но решил, что не хочу видеть никого из родственников. Но совсем недавно, когда у меня начались серьезные проблемы на работе, мне так не хватало его совета, его стойкости и жизненной мудрости, что я пошел к нему на могилу, сел на землю и стал разговаривать с портретом на памятнике. Изливал ему все, что накопилось в моей душе за все эти годы. Просил прощения и лил слезы как мальчишка…
— Вернуть его вы уже не сможете, но можете стать хорошим отцом своему собственному сыну.
— В том то и дело, что я такой же, как и мой отец: жесткий и непримиримый. Боюсь, что с моим ребенком повторится та же история и от этой мысли, мне становится еще горше.
— Не переживайте на этот счет — уже тот факт, что вы сейчас говорите со мной об этом, не даст вам допустить ту же ошибку. Никто из нас не идеален...
Всем привет.
Настала пора наконец закончить с прелюдиями и перейти к рассказу про один из самых важных навыков системного аналитика - REST. Больше важны навыки практического применения\проектирования, но и теория тоже важна. Как минимум для прохождения собеседования, потому что значительная часть вопросов приходится как раз на интеграцию и знание REST в том числе.
В следующем посте разбавлю серию только теоретических - практикой. Приведу шаблон того, как можно описывать API.
REST
Representational State Transfer (REST) в переводе — это передача состояния представления.
Сам по себе REST – это архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Архитектурный стиль – это набор согласованных ограничений и принципов проектирования, позволяющий добиться определённых свойств системы.
И у него есть определенные принципы, которые важно понимать и применять при проектировании системы.
В рамках данного принципа самое важное - это отделение клиента и сервера. Клиент - это интерфейсная часть (уровень представления), сервер - это центральное звено системы, на котором реализованы все основные функции системы (наш backend). Более подробно рассмотрено в части 6 этой серии.
Это понятие означает, что сервер не должен хранить информацию о состоянии клиента, в том числе информацию о предыдущих запросах клиента, а клиент не должен знать ничего о текущем состоянии сервера.
Это не значит, что у них вообще нет состояния, но они не отслеживают состояние друг друга (что очень удобно, т.к. избавляет нас от необходимости держать постоянное неразрывное соединение между двумя системами).
Поэтому каждый запрос рассматривается индивидуально, как будто бы не было ничего до, и не будет после. Соответственно клиент в этом случае, обязан предоставить все необходимые данные для успешного выполнения запроса. Это, пожалуй, почти единственная логика, которая должна быть на клиенте.
Принцип гарантирует, что между клиентом и сервером существует общий язык (интерфейс), с помощью которого они будут понимать друг друга. Т.е. клиент посылает понятные серверу запросы, использую конкретные HTTP-методы, сервер посылает ответ в понятном клиенту формате.
Это достигается через несколько субограничений:
Идентификация ресурсов
В терминологии REST что угодно может быть ресурсом — HTML-документ, изображение, информация о конкретном пользователе - то, чему можно дать имя. Каждый ресурс должен быть уникально обозначен постоянным идентификатором. «Постоянный» означает, что идентификатор не изменится за время обмена данными, и даже когда изменится состояние ресурса. Если ресурсу присваивается другой идентификатор, сервер должен сообщить клиенту, что запрос был неудачным и дать ссылку на новый адрес.
Тут важно понимать, что в REST (в идеале, по крайней мере), ресурс может быть только существительным, а не глаголом. Потому что за "глагол", т.е. действие - отвечает конкретный метод.
2. Управление ресурсами через представления
Второе субограничение «унифицированного интерфейса» говорит, что клиент управляет ресурсами, направляя серверу представления, обычно в виде JSON-объекта, содержащего контент, который он хотел бы добавить, удалить или изменить. В REST у сервера полный контроль над ресурсами, и он отвечает за любые изменения.
Когда клиент хочет внести изменения в ресурсы, он посылает серверу представление того, каким он видит итоговый ресурс (а для этого, сервер сначала должен предоставить эту информацию клиенту). Сервер принимает запрос как предложение, но за ним всё так же остаётся полный контроль.
3. Самодостаточные сообщения
Самодостаточные сообщения — это ещё одно ограничение, которое гарантирует унифицированность интерфейса у клиентов и серверов. Только самодостаточное сообщение содержит всю информацию, которая необходима для понимания его получателем. В отдельной документации или другом сообщении не должно быть дополнительной информации.
В данных запроса должно быть указано, нужно ли кэшировать данные (сохранять в специальном буфере для частых запросов). Если такое указание есть, клиент получит право обращаться к этому буферу при необходимости.
Это нужно для того, что максимально ускорить обработку запроса от клиента. Для примера, если нам нужно часто получать информацию о пользователе (а сама информация о пользователе меняется достаточно редко, что важно), то мы можем закэшировать эту информацию.
Т.е. стандартный запрос выглядит условно так: Фронт -> микросервис адаптер к фронту -> какой-нибудь микросервис MDM системы пользователей -> база где лежат пользователи и потом обратный путь. Это не прям мгновенно всё происходит. Что мы делаем - например, наш фронт прислал запрос GET /user/121, мы проделали этот путь, описанный выше, но еще и сохранили эти данные в кэше на уровне микросервиса-адаптера. В следующий раз, когда фронт вызовет метод GET /user/121, наш путь будет намного короче и быстрее - всего лишь от фронта к нашему же микросервису в кэш и сразу обратно.
Тут есть множество нюансов, которые нужно учесть - но в целом полезный инструмент.
Система слоев предполагает наличие большего количества компонентов, чем клиент и сервер. В системе может быть больше одного слоя. Тем не менее, каждый компонент ограничен способностью видеть только соседний слой и взаимодействовать только с ним.
Но что самое замечательное, при добавлении новых слоев между клиентом и сервером - их не нужно дорабатывать. Т.е. не важно, если у нас архитектура выглядит как просто "Клиент" -> "Сервер", или "Клиент" -> "Прокси" -> "Балансировщик" -> "Несколько серверов" - их логика не меняется (тут разработчики могут меня поправить или дополнить, буду благодарен).
Что-то вроде того:
Еще есть отдельный принцип "Код по требованию", который подразумевает то, что клиент может получить с сервера прям "кусок кода" (условно), который ему необходимо выполнить у себя.
Звучит интересно, но честно, ни разу не сталкивался, поэтому не могу что-то детальное рассказать.
P.S.: В следующих постах расскажу про best practices, связанных с именованием эндпоинтов и прочими полезными штуками для проектирования своих апишек.
По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Всем привет.
В прошлом посте рассказал про HTTP в целом и много раз упоминал различные методы, но еще не рассказал что это такое - разбираемся.
Как я уже писал, метод - это название запроса, которое определяет то действие, которое будет совершаться в результате его выполнения.
Их всего 6 основных:
Метод GET предназначен для получения информации о каком-то конкретном ресурсе или массиве ресурсов. Он никак не изменяет эту информацию.
Похож на GET, но не возвращает тело ответа, а только стартовую строку и заголовки. Используется для получения метаданных, а также проверки и валидации ресурса.
Честно говоря - ни разу не приходилось использовать его на практике или даже просто видеть. Но могу предположить, что его можно использовать в том случае, когда нам нужно ткнуть какой-то ресурс палочкой и спросить - а ты вообще существуешь? Ну и, возможно, получить по нему какую-то метаинформацию.
Условно, можно вызвать HEAD /users/127 - мы получим в ответе HTTP 200, в том случае, если этот пользователь с идентификатором = 127 существует. И 404 - если нет.
Если же вызвать GET /users/127 - то мы получим HTTP 200 + тело ответа, в котором будет содержаться вся информации о пользователе с идентификатором 127 (ну тут смотря как реализовать, но по дефолту будет так).
Создает новый ресурс из переданных данных в запросе. Но это лишь по дефолту.
На самом деле POST самый универсальный метод и им возможно делать всё - и получать информацию, и создавать, и редактировать, и удалять, и запускать какие-то процессы. Тут важно понимать - почему именно так.
Например, мы можем использовать POST для поиска в том случае, если нам нужно зашифровать поисковые параметры в теле запроса, а не оставлять их в открытом виде в query-параметрах (прям в строке запроса). Либо использовать для поиска в том случае, если поисковых параметров слишком много и строка запроса получается слишком огромной - а у нее есть определенное ограничение по длине (очень больше, но всё-таки есть).
Можно использовать для запуска различных команд в оркеструющих микросервисах или коммандерах. Т.е. напрямую у нас никакой объект не создается, физических и лежащий в БД - но у нас создается (запускается) какой-нибудь бизнес-процесс.
Применений у этого метода очень много.
Изменяет содержимое ресурса по-указанному URI. PUT полностью заменяет существующую сущность.
Похож на PUT, но применяется только к фрагменту ресурса (заменяет точечно только часть ресурса)
Для понимания: Например, у вас есть объект user, у которого 5 атрибутов - Ф, И, О, дата рождения и пол. Если у вас поменялась информация о пользователе №5, например изменилась фамилия - и вы вызовете метод PUT /users/5, и передадите в теле запроса только фамилию, то на выходе у вас останется объект user с id = 5, и фамилией = тому, что вы передали в запросе. Все остальные атрибуты затрутся. Поэтому для обновления необходимо передавать все объект целиком, включая те атрибуты, которые не менялись.
Если же вы вызовете метод PATCH /users/5 с таким же запросом, то у вас обновится только фамилия, остальной объект останется не тронутым.
Логичный вопрос - а зачем тогда вообще использовать PUT? Ответ достаточно простой - он намного проще в реализации. Куда проще передать объект целиком ценой нескольких байт трафика и подменить его, чем обновлять каждый атрибут по отдельности, маппить их и т.д. Особенно если у вас какой-нибудь огромный объект, типа "Заявка на кредит", у которой под тысячу атрибутов, а вам нужно обновить 200 из них.
Тут разработчики могут меня поправить, но объясняли мне в свое время так.
Удаляет конкретный ресурс по-указанному URI.
Интересное: на самом деле нет никаких проблем с тем, чтобы заставить метод GET создавать какой-нибудь ресурс или заставить метод DELETE обновлять. Т.е. это не технические ограничение, это "лишь" концептуальная идеология того, как правильно (и для чего) использовать различные методы.
Чтобы на всех проектах, все участники разработки были в едином контексте. И когда вы будете видеть какой-нибудь метод, типа POST /loanApplication//offers - вы явно поймете, что это метод предназначенный для добавления новых офферов конкретной заявке на кредит.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Всем привет.
Сегодня рассмотрим такой важный протокол, как HTTP. Важный потому, что именно его используют в качестве протокола передачи данных современные технологии интеграции (REST, gRPC).
HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». Изначально этот протокол использовался для передачи гипертекстовых документов в формате HTML. Сегодня он используется для передачи произвольных данных - c помощью него можно передавать хоть JSON, хоть XML.
В основе HTTP - клиент-серверная структура передачи данных․ Клиент формирует запрос (request) и отправляет на сервер; на сервере запрос обрабатывается, формируется ответ (response) и передается клиенту.
HTTP не шифрует передаваемую информацию. Для защиты передаваемых данных используется расширение HTTPS (Hyper Text Transfer Protocol Secure), которое “упаковывает” передаваемые данные в криптографический протокол SSL или TLS. Но это совсем другая история)
HTTP запрос состоит из трех основных частей: строка запроса (request line), заголовок (message header) и тело сообщения (entity body). Тело сообщения не является обязательным параметром. Между заголовком и телом есть пустая разделительная строка.
В строке запроса указывается:
Метод – название запроса (определяет действие), одно слово из стандартного списка, заглавными буквами;
URI определяет путь к запрашиваемому ресурсу;
Версия – пара разделённых точкой цифр. Например: 1.0.
Пример HTTP запроса:
Заголовок запроса добавляет некоторую дополнительную информацию к сообщению запроса, которое состоит из пар «имя / значение», по одной паре на строку, а имя и значение разделяются двоеточием.
Обычно в заголовках передается какая-либо мета информация. Например, токен.
Последней частью запроса является его тело. Оно бывает не у всех запросов: запросы, собирающие (fetching) ресурсы, такие как GET, HEAD, DELETE, или OPTIONS, в нем обычно не нуждаются и тела запроса у них быть не должно (так реализовать метод можно, но это не правильно).
В то же время для методов POST, PUT, PATCH - тело использовать можно и нужно.
Структура ответа, в целом, идентична структуре запроса. Также есть строка статуса, заголовок и тело.
Стартовая строка ответа HTTP, называемая строкой статуса, содержит следующую информацию:
Пример строки статуса: HTTP/1.1 404 Not Found.
Более подробно про коды состояния и как их использовать расскажу как-нибудь в другой раз.
Пример ответа:
Заголовки ответов HTTP имеют ту же структуру, что и все остальные заголовки: не зависящая от регистра строка, завершаемая двоеточием (':') и значение, структура которого определяется типом заголовка. Весь заголовок, включая значение, представляет собой одну строку.
Тело присутствует не у всех ответов. Например, если мы вызываем метод DELETE, чтобы удалить какую-либо сущность, то в ответ нам вернется лишь строка статуса с HTTP-кодом 204.
Как правило тело ответа используется в том случае, когда нам нужно вернуть вызывающей стороне информацию о ресурсе. Например, если мы вызываем метод GET /users/25, то в ответе вернется полная информация о пользователе с идентификатором = 25.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Всем привет.
Сегодня продолжим погружаться в системный анализ, в его техническую часть.
Перед тем как начать изучать REST, API и все что с этим связано - нужно изучить, хотя бы верхнеуровнево, архитектуру, на базе которой строятся все современные приложения. Для этого рассмотрим клиент-серверную архитектуру.
Архитектура «клиент-сервер» определяет общие принципы организации взаимодействия в сети, где имеются серверы, узлы-поставщики некоторых специфичных функций (сервисов) и клиенты, потребители этих функций.
В клиент-серверной архитектуре одним из основных вопросов является вопрос о том, как разделить клиентов и серверы. Так, приложения типа клиент-сервер разделяют на три уровня:
уровень представления - на уровне представления обеспечивается взаимодействие с пользователем приложения с помощью пользовательского интерфейса. Его основное предназначение состоит в отображении информации (все формочки, кнопочки и т.д.) и получении информации от пользователя. Этот уровень может работать в веб-браузере или как графический пользовательский интерфейс компьютерного или мобильного приложения.
уровень бизнес-логики - центральное звено приложения, на котором реализованы все основные функции системы. Обрабатывается вся информация, собранная на уровне представления согласно бизнес-правилам для выполнения конкретных бизнес-целей системы. Кроме того, уровень приложения может добавлять, изменять и удалять данные, расположенные на уровне данных;
уровень данных - функции управления ресурсами. На данный момент в современных приложениях его роль зачастую выполняет реляционная (или нереляционная) система управления базами данных.
Т.е. система реализована таким образом, что собирает всю ту информацию, которую пользователь ввел на интерфейсном уровне, затем передает ее на уровень бизнес-логики, каким-то образом обрабатывает с учетом всех бизнес-правил и затем либо возвращает обогащенную информацию обратно, либо сохраняет ее в базу.
Клиент-серверная архитектура делится на двухзвенную и трехзвенную.
Двухзвенная архитектура
Двухзвенной (two-tier, 2-tier) она называется из-за необходимости распределения трех базовых компонентов между двумя узлами (клиентом и сервером). Двухзвенная архитектура используется в клиент-серверных системах, где сервер отвечает на клиентские запросы напрямую и в полном объеме, при этом используя только собственные ресурсы. Т.е. сервер не вызывает сторонние сетевые приложения и не обращается к сторонним ресурсам для выполнения какой-либо части запроса.
В двухзвенной клиент-серверной архитектуре используется так называемый «толстый» клиент, который выполняет отображение информации и обработку всех данных (порядка 80 % всех работ). Сервер осуществляет только хранение и предоставление данных (порядка 20 % работ).
Толстый клиент - это когда приложение напрямую запущено через условный .exe файл на вашем компьютере и работает в отдельном окне (всякие ERP\WMS системы, те же клиенты 1С и пр. не облачные штуки). Собственно их основной минус в том, что т.к. нет выделенного сервера - все функции реализуются на уровне клиента, который потребляет только те ресурсы, которые доступны компьютеру, на котором это приложение установлено.
А большинство офисных компьютеров, как известно, не отличаются большой производительностью, поэтому необходимость сформировать условный отчет даже из относительно небольшого количества данных заставляет их сильно задуматься. Это если не говорить о необходимость формировать или отображать какие-нибудь таблицы, состоящие из нескольких миллионов строк.
Трехзвенная архитектура
Собственно именно эти недостатки в большей степени послужили толчком к появлению трёхзвенной клиент-серверной архитектуры с отдельно выделенным сервером приложений.
Выглядит это всё схематично следующим образом:
Также в этой архитектуре мы уже можем позволить себе использовать "тонкий клиент", т.е. просто страницу в вашем веб-браузере или мобильное приложение. И с учетом этого, мы просто обязаны вынести из него всю логику (даже простейшую валидацию желательно перенести на уровень бизнес-логики, либо, как минимум, дублировать), потому что у него не остается почти никаких ресурсов для ее выполнения.
Всё, на что способен тонкий клиент - это отображать интерфейс, взаимодействовать с пользователем, посылать запросы на сервер по любому чиху и обрабатывать ответы от него. Ну и иногда, по мере какой-то острой необходимости, горящих сроков или чего-то в этом духе можно запихнуть в него какую-то логику, но стараемся этого избежать.
Но при этом мы получаем монструозный (в плане его мощностей) сервер, который способ обслуживать огромное количество клиентов одновременно, в многопоточном режиме обработки данных и выполнять необходимую бизнес-логику за какие-то доли секунд, даже при большом объем данных.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.S. Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Всем привет.
Сегодня вернемся немного назад. Если про сами требования мы уже поговорили, про то, что это вообще такое, какими они бывают и какими качествами обладают, то вот про то, а как вообще их собирать - еще не проговорили.
Для этого придумали и сформулировали не мало методологий - давайте в них разберемся.
Интервью - это один из самых базовых и понятных способов сбора требований. Казалось бы, что в этом такого - просто взял заказчика под руку, отвел его в сторону и как давай спрашивать про всё подряд. Но тут кроются определенные тонкости.
Вообще, если говорить прям по теории-теории, то перед тем, как начать интервьюировать - надо определиться с теми лицами, которым нужно задавать вопросы.
Выглядит это так, что сначала нужно сформировать полный перечень заинтересованных лиц и потенциальных (или уже текущих) пользователей системы (тут важно понимать, что цели реальных пользователей системы могут сильно отличаться от целей бизнес-заказчиков, т.к. именно им работать с системой, а не заказчикам). Из каждой группы выделить одного или двух специалистов, чтобы избежать однобокого взгляда на проблему.
После этого уже требуется согласовать календарь встреч и желательно заложить время сразу на повторное интервью, обязательно заложив время между ними для того, чтобы вы могли осмыслить те ответы, которые вам были даны.
Это что касается теории. Однако на практике - в большинстве случаев это уже устарело, потому что у вас, почти всегда, будет ровно одна точка входа в бизнес-требования в виде PO или просто выделенного человека, достаточно высокой должности (уровня зам или руководителя определенного направления компании), которые сами ответят вам на все вопросы, без привлечения толпы лиц. И именно этот человек будет тем самым рупором, через который идет трансляция целей бизнеса на команду разработки.
Другой подход может быть, если вы внедряете какую-нибудь ERP\WMS систему на какое-нибудь предприятие, в этом случае я готов поверить, что та самая базовая теория будет актуальна для такого случая.
Пара важных моментов:
Всегда готовьтесь к интервью. Я не знаю почему, но даже опытные аналитики это не всегда делают, к моему сожалению. Не должно быть такого, что вы приходите на встречу, вам предлагают начать диалог и задавать вопросы, а вы такой: "Ой, да я даже не знаю, давайте вы расскажете просто что вам нужно". Очень желательно, заранее подготовить список вопросов или просто понять концепцию разговора, т.к. именно вы должны быть его драйвером.
Это нормально, когда после интервью у вас появляется больше вопросов, чем ответов - в этом случае, необходимо взять определенное время на проработку информации и потом собрать следующую встречу. Повторять до тех пор, пока не наступит достигните желаемой степени определенности в задаче.
Еще один распространенный и интересный подход - это первичное создание прототипов системы. Прототип - это модель, позволяющая продемонстрировать интерфейс или поведение проектируемой системы. Сбор и уточнение требований прототипированием гораздо эффективнее проводить после выявления первичных требований любым другим способом, как минимум потому, что люди в большинстве своём визуалы и не особо готовы воспринимать большие полотна текста (как этот пост), но достаточно легко готовы идти на контакт и общаться, если вы показываете им картинки.
Тут важно понимать, что необходимо создать прототип, который отражает идеи реализации, близкие пользователям и заказчикам, которые они высказали при первичном обсуждении. Это поможет замотивировать их еще активнее вовлекаться в процесс диалога.
Прототип может быть:
Статическим, показывающим положение элементов в интерфейсе или структуры данных;
Динамическим - с возможностью демонстрации поведения системы по наступлению определенных событий;
Интерактивным - позволяющим пользователям и участникам заинтересованных сторон выполнять реальные действия так, как это будет работать в разрабатываемой системе.
Но у такого подхода есть и ряд минусов:
Сильно увеличивает трудозатраты, особенно если не удастся переиспользовать интерфейс для экономии времени разработки, т.к. стоит понимать, что сам процесс прототипирования отнимает достаточно большое количество времени, если это не на салфетке на встрече нарисованный макет интерфейса;
Заказчики могут акцентировать фокус своего внимания на красоту и дизайн прототипа их системы вместо обсуждения действительно важных вопросов реализации. Поэтому важно постоянно уводить нить их рассуждения от "Блин, тут кнопка не в наших корпоративных цветах, надо это поправить", к обсуждению того, как эта кнопка должна работать и что должно происходить по ее нажатию.
Не менее основной подход к выявлению требований (особенно для системного аналитика), чем интервью, в случае если у заказчика уже есть какая-то система (или несколько), которые вам нужно доработать.
Данный подход выполняет сразу несколько целей:
Сократит время последующего анализа потребностей и проблем заказчика. Кроме этого облегчит взаимодействие с заказчиком и другими членами команды разработки, т.к. вы больше вникните в процесс и будете разговаривать на одном языке;
Возможно вы сможете получить ту информацию, которой уже (или еще) из представителей заказчика не обладает.
Для начала требуется определить с какой документацией необходимо и желательно работать. Это можно сделать у представителя заказчика, который может предоставить нам список необходимой “литературы”, релевантной относительно текущих процессов. Либо, если вам предоставили доступ к каким-либо информационным ресурсам заказчика - поискать такие документы самостоятельно.
Мозговой штурм - наверно это метод, про который слышали все. Но как его правильно применять? Обычно, рекомендуется его использовать среди команды или в связке с командой и заказчиком, в случае, если нужно определить первичный набор идей.
Такой формат не позволит вам выбрать что-то наилучшее или оптимальное, однако позволит по накопившимся идеям получить быструю обратную связь, отследить реакцию заказчика на них, выбрать несколько наиболее подходящих и далее “копать” в том направлении, развивая эти идеи.
Перед тем как проводить такой штурм, в любом случае требуется определить цель. Без чёткой цели идеи будут предлагаться уж совсем несуразные. Возможно, вам будет весело, но вот продуктивно ли? Сомневаюсь.
Однако в процессе фонтанирования идеями нельзя сразу отбрасывать даже самые безумные и фантастичные на первый взгляд идеи. Как показывает практика, некоторые из них при более детальном рассмотрении оказывается совсем уж не сумасшедшими, а вполне даже дельными и гениальными.
И еще один принцип работы с таким подходом - ни в коем случае нельзя критиковать возникающие идеи, т.к. после этого человек, подвергнутый критике, вряд ли будет предлагать другие идеи (да, да, в IT люди очень нежные в большинстве своем). Просто в определенный момент, когда закончится поток идей - уже записанные идеи должны быть оценены, возможно проведением голосования и в следующий этап перейдут только наиболее популярные идеи.
Кроме всех вышеперечисленных способов - можно применить еще один, достаточно интересный. Если вы не разрабатываете что-то совсем новое и уникальное, не делаете “rocket science”, то скорее всего у вашего продукта или системы уже есть аналоги. И очень не глупой идеей будет проанализировать их, посмотреть на отзывы пользователей, самому попользоваться данной системой (если это возможно) и сделать на основании этого выводы о преимуществах и недостатках данного продукта.
И конечно же, чтобы не натыкаться на те же грабли - заранее исправить недостатки, которые уже не нравятся пользователям и позаимствовать удачные и интересные решения, которые каким-либо образом можно использовать в вашем продукте.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.S. Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Пост о том, как НЕ НАДО делать! Немножко длинновато, но того стоит.
Скажите, дорогие Очкобушники, кто ломал очки? Правильно, ВСЕ!)))
Иногда, когда ремонт невозможен, люди переставляют оптические линзы из одной оправы в другую. Порой это можно сделать безболезненно (когда оправа 1-в-1 такая же как и предыдущая). Иногда это не приводит к серьёзным последствиям. Иногда приводит к развитию глазных заболеваний. А иногда заказчик в оптике сознательно идёт на то, что-бы потратить деньги в пустую.
Приходит к нам в оптику дама и приносит "поломашку" (поломанные очки).
И просит переставить линзы в другую оправу, т.к. муж без них как без рук. Осматриваем очки. Понимаем, что это сложные линзы на все расстояния (прогрессивные). Их можно переставлять только в ТОЧНО ТАКУЮ ЖЕ оправу, т.к. устанавливаются такие линзы в оправу с целой кучей измерений положения КОНКРЕТНОЙ оправы на лице и, если линзы поставить в другую, то... волшебства не будет. Даже если хорошенечко дунуть))) Плюс к тому, линзы зацарапаны до такой степени, что разглядеть что-то через них можно только имея потрясающее воображение, ну или ...дунуть тут уже не поможет. Тут грибы нужны)))
Отказываем даме в услуге, мотивируя это тем, что это бесполезная трата денег. Чисто физически мы это сделать можем, а вот пользы от этого не будет никакой корме вреда. Дама настаивает на том, что замену оправы всё же следует произвести. Трижды (как в сказке) доходчиво объясняем, что это деньги "на ветер". Трижды (как в сказке) Заказчица стоит на своём. Ну что же, по закону мы не можем отказать Потребителю в услуге. Делаем.
Вот такую оправку выбрали.
Демонтируем линзы из поломашки. Грязь, это норма. Не может человек вымыть самостоятельно грязь из-под ободка.
Чистим-моем, дезинфицируем спиртом!
И получаем результат всё с тем же недостатком. Что по сути сводит всю нашу работу к "мартышкиной".
Получать приезжает супруг. Надевает очки, поднимает два больших пальца вверх и сообщает: "Ну, круто же! Молодцы!" Ещё раз объясняем, что он ничего не видит в этих очках, но куда там, мужчина доволен и счастлив!)))
Просто он привык почти ничего не видеть. Ему на данный момент и этого достаточно. Мозг выключил требование лучшей картинки. А к доктору он в ближайшее время пойдёт вряд ли. Зато когда попадёт, то реально офигеет от разницы качества зрения.
Так вот! Не доводите, пожалуйста, свои очки до такого состояния и слушайте специалистов. На то они и специалисты, что знают КАК нужно. И как Вам не тратить деньги на бесполезные вещи.
Во время очередного двухчасового совещания вновь навалились размышления о демократии и "свободе слова" в строительстве. Тема весьма неоднозначна, как по мне.
С одной стороны, это, конечно, правильно, когда каждый имеет право выразить свое мнение и быть услышанным, принятым. С другой, часто наблюдаю картину, когда сам факт «продавливания» своего мнения становится важнее его содержания. И спрашиваю себя, а действительно ли нужно, чтобы КАЖДОЕ мнение имело право быть высказанным.
И я даже сейчас не поднимаю острые гендерные темы, от которых чуть ли не у каждого бомбит. Хватает рабочих моментов.
Делаю небольшой проект благоустройства в одном захолустном немецком городке. Ничего особо выдающегося, малая архитектура – небольшая станция проката великов с интегрированным в нее общественным туалетом (читай, бетонный навес и два помещения под ним), немного брусчатки и скамеечек. Я в проекте с 2016, до меня еще несколько месяцев другие коллеги занимались. На дворе 2022 (а сейчас уже 2023), начали строить, повезет – к концу года закончим. Больше 5 лет, КАРЛ!
Проект городской, решает Город, а Город – это совет партий, каждая со своим мнением. Часто мнение одних будет забанено другими, не потому что оно плохое, а потому что оно исходит от «конкурентов». У Города много мнений – с одной стороны, нужно закрыть дыру в пространстве и создать объект, который улучшит городской облик. С другой, ему не нужно никаких дополнительных мест, где будут тусить подростки с вандальными наклонностями.
Согласовывали, пересогласовывали. Кое-как согласовали, получили разрешение, но пока вся эта бюрократия тянулась сменились и представители от партий и их процентное соотношение. Приходят новые люди, приносят мнения в портфелях. Мнения у них есть, а времени изучать старые мнения нет, да и зачем, ведь те люди уже ушли. Каждый из них – житель этого города, каждый видит его со своей стороны, каждый хочет улучшить то, чего ему не хватает. Один ездит на работу на машине, и каждый день мучается с парковками и односторонним движением, а другой на велике, и ему неудобно ездить по исторической брусчатке, а вот по ровной плитке или асфальту было бы норм. И тому и другому улицы жмут. Третий ходит пешком, и любуется стенами, а хотел бы больше зелени. Четвертый любит детей, а пятого раздражают шумные компании. У каждого из них в голове образ идеального Города. Нет, не так – идеальных Городов. Каждый тянет одеяло на себя. Каждое мнение услышивается и рассматривается отдельным собранием, протоколируется, рабочее время оплачивается. Проект пылится на полке. Baulücke bleibt Baulücke. (Нем.: место для строительства остаётся местом для строительства)
Делаю большой проект, бюджет около 50 млн. евро. Сумма большая, и из одного кошелька не подъемная. Финансируется будущими пользователями и Городом. Про Город уже все всё поняли, а вот пользователи делят площади. И вроде как они вместе и у одного без другого дело не пойдет, но и у них у каждого свое мнение в портфеле, каждый из них бывалый моряк, построил свой бизнес и знает как лучше.
Сумма большая, ответственность еще больше, в одиночку такое комплексное планирование не потянуть. Привлекаются разные специалисты узкого и очень узкого профиля, у каждого свои суперспособности и специальные знания в голове, а на них основывается мнение в портфеле. Узкий специалист по экологии говорит: «Давайте строить экологичней», узкий специалист по конструкциям говорит: «Давайте строить долговечней». Еще даже строить не начали а 2,5 млн ушло на гонорары очень и не очень узких специалистов.
Вот, поди-реши как правильно – чтобы каждый «право» и голос имел, терять время и деньги из бюджета проекта, ответственность на всех и ни на ком. Или чтоб пришел один, и за всех все решил, а обиженных заткнул, но с риском, что решение в итоге неправильное и только хуже сделали. А может и лучше. Это же вкус и свобода мнений.
Всем привет.
Сегодня продолжим наш экскурс в глубины системного анализа. Перед тем, как мы перейдем к интеграциям - логично было бы поговорить об XML\JSON.
XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Отличается простотой синтаксиса и универсальностью. XML позволяет описывать документы с помощью тегов, которые можно задавать самостоятельно. Так что увидеть его использование можно и в API в том числе (хотя и намного реже, чем JSON).
XML позволяет:
записывать иерархию — «один подчиняется другому»;
размечать текст по смыслу от важного к второстепенному;
хранить типовые данные — скрипты, настройки программ, названия чего-либо;
размечать текст для машинного обучения;
хранить результаты работы текстовых редакторов.
У XML-файлов древовидная структура. Это значит, что в них используется набор тегов, внутри которых могут находиться другие теги со своими значениями. Самый верхнеуровневый узел называется корнем, а все, что находится внизу, — листьями.
В XML каждый элемент должен быть заключен в теги. Тег — это некий текст, обернутый в угловые скобки:
<tag>
Текст внутри угловых скобок — название тега.
Тега всегда два:
Открывающий — текст внутри угловых скобок
<tag>
Закрывающий — тот же текст (это важно!), но добавляется символ «/»
</tag>
С помощью тегов мы показываем системе «вот тут начинается элемент, а вот тут заканчивается».
В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа.
Для примера давайте опишем объект Task нашей системы (см. первую практику) в формате XML.
<task type="issue"> (открывающий тег и корневой элемент заодно)
<topic> Не работает принтер</topic>
<priority> high</priority>
<isMass> false </isMass>
<description> Сломался принятер. Выключился ибольше не включается. Нужно срочно распечатать много документов, а не получается. Что делать? Просьба помочь</description>
</task> (закрывающая тег)
Пара особенностей, помимо перечисленных:
Все теги являются регистро-чувствительными. Это значит, что если, например, тег <user> закрыт </User>, документ будет оформлен некорректно;
Значения атрибутов должны быть заключены в кавычки. Атрибут — характеристика тега. Любые теги могут иметь атрибуты;
Вложенность тегов контролируется, поэтому важно следить за порядком открывающих и закрывающих тегов.
JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.
JSON обладает рядом преимуществ. К ним относят:
компактность;
простое чтение предложений, написанных подобным образом – актуально и для машины, и для человека;
легкость преобразования в структуры данных для разнообразных языков программирования;
наличие у большинства языков программирования функций и библиотек, которые помогут создавать и читать структуры JSON.
JSON-объект — это неупорядоченное множество пар «ключ:значение», которые разделены ",".
Давайте теперь тот же объект Task опишем в формате JSON и я думаю, что на этом примере сразу станет понятна структура, потому что она намного более простая и наглядная, чем XML
{ (открывающая скобка - начало объекта, закрывающая скобка - конец объекта)
"type" : "issue", (Слева - ключ, справа - значение)
"topic" : "Не работает принтер",
"priority" : "high",
"isMass" : "false",
"description" : "Сломался принятер. Выключился ибольше не включается. Нужно срочно распечатать много документов, а не получается. Что делать? Просьба помочь"
}
JSON на данный момент наиболее распространен и повсеместно используется в REST, например.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
В следующей части расскажу базовую теорию про интеграцию и начнем плавно переходить к REST'у.
Пикабу познавательный и образовательный. Вот и теперь, очередной гуру бизнеса делится с нами своими ценными мыслями про бизнес. Поскольку в строительстве или там барбершопах я не сильно разбираюсь, глаз зацепился за металлообработку. Ну и в камментах попробовал поуточнять, что же имеется в виду.
Итак. Гражданин рекомендует входить в токарное дело имея:
"Универсальный набор это дип в состоянии на 3- + любой заводской новый или с консервации или после восстановления + Фрезер. Но надо быть умнее. Открой фирму ндс20% и закинь рекламку на авито, сайт сделай. Также найди токарей в своём городе и области. Поработай перекупом в ноль, тогда поймешь какая оснастка нужна. Может и самому точить не придется."
Для тех, кто не знает, ДИП300 производился с 34 по 68 годы, имеет массу от 4 тонн и длину от 4 метров. Стоят такие нынче от 200К в состоянии "ушатан в хлам". Основное у этого станка - диаметр обработки над станиной в 600мм.
Следующим предлагается взять любой заводской новый или с консервации. Ну тут, поскольку конкретики нет, будем считать, что это аналог 16К20, например. Это миллиона 2,5-3 готовить надо. Шешнашка весит от 3 тонн и имеет длину от 3 метров. Это для понимания размеров помещения важно. Т.к. если станов у нас 4 в длину и 1,2 в ширину, но на самом деле, с учётом рабочего пространства вокруг это 6 в длину и 2,5 в ширину. Т.е. 15 квадратов на один станок.
Пока остановимся на этом и осмотримся. Вот, допустим, у нас таки есть деньги на 2 станка. Это уже 2,5 ляма, надо отметить, включая такелажные работы и перевозку. Что же мы можем сделать на этом наборе прям сразу после включения в розетку? Ничего. Вот да. Вот так вот, прям НИ ЧЕ ГО.
Поясню. Даже для того, чтобы просто выточить "палку" длиной 500мм и диаметром пусть будет 138мм, нужно:
взять заготовку. Пруток стали диаметром 150мм. и отрезать 500мм +припуск на торцевую обработку. Чем? Очевидно, ленточной или мехпилой. Об этом не сказано ни слова. А без этого, магии скорее всего не получится. И если 50мм ещё можно перерезать отрезным, то болванку на 100мм+ диаметром уже не получится... если рационально, конечно. Ленточная пила (с гидроразгрузкой и подачей СОЖ) стоит от 150 бу хор.сост и занимает внезапно примерно 3 кв.м.
ежели у нас на хозяйстве есть ДиП с диаметром в 600, значит надо на нём обдирать хотя бы 300-миллиметровые брёвна? Кстати, ленточная пила для такого размера уже будет стоить 250+. Ну ладно. А как это бревно ворочить? Скажем так, масса заготовки Ф150х500 составит 70 килограмм. Т.е. в одну каску ваще никак (на регулярной основе), учитывая, что рабочая область станка находится примерно на уровне низа рёбер, но к ней надо тянуться вперёд... Нужна кран-балка, портальный кран или хотя бы гаражный.
окей, заготовка есть. Отпилили, на кранбалке перевезли к ДиПу, поставили в патрон. А чем обрабатывать то? Резцов надо много. Прям вот очень много... Прям вот десятки килограмм. Разных! Причём я не уверен, что на ДиП можно купить современный резец с мехкреплением. Скорее всего, такие "лопаты" как на этом монстре только напайные. Т.о. надо заводить газовый пост: баллон пропана, баллон кислорода, шланг, горелка, серебряно-латунный припой...
окей, вот мы припаяли пластинку к резцу. Но она же тупая. Её надо точить. Для этого нужен заточной станок или точило. А лучше два. А на них - камни разные повесить. На одном обычные "кирпичи", а на втором алмазные. Чтобы удобно было. Потому что менять камни - это ещё и балансировать их. Т.е. по-быстренькому не сделаешь.
отлично, вот мы сделали первый проход... ага, пока только первый, а уже у нас внезапно 2-3 вспомогательных станка есть +грузоподъёмное оборудование. А чем измерить? Надо измериловку закупать. Обычный штангель подойдёт только для заготовительных операций. Для частого, быстрого и точного измерения нужен цифровой, желательно не с алика (они так себе). А если хотя бы иногда делать детали не под сварку, а с полем допуска в 5 соток (очень частая задача у практикующего токаря) - это нужно иметь комплект микрометров. А они идут интервалами по 25мм. Т.е: 0-25, 25-50, 50-75 и т.д. У меня их, например, до 300мм. Нужно иметь нутромеры. Они опять же идут интервалами, но по 50мм. Но и стоят гораздо дороже. Чтобы проверить штангель перед работой (прикиньте, это нужно!) - нужно иметь хотя бы один набор концевых мер длины. А для проверки микрометров - плоскопараллельные меры. А чтобы выставить заготовку не на глаз, кстати, неплохо бы иметь индикатор на стойке. А лучше парочку. В измериловку можно закопать вообще любые деньги. Это не фигура речи. У меня потрачено уже больше 150 тыщ на всё это и конца-края не видать... Постоянно нужно то и это.
Это мы рассмотрели изготовление просто цилиндрической детали заданного размера. Но таких задач мне лично за годы работы приходило от силы несколько раз... А для изготовления таки изделий с несколькими диаметрами, расточками, канавками и т.д. понадобятся планшайбы обычные и универсальные, патрон четырёхкулачковый, люнеты подвижные и неподвижные, комплект свёрл минимум штук на 50, комплект развёрток, резьбонарезной инструмент, оснастка для задней бабки всякая... как минимум живой конус и живой гриб, а лучш ещё иметь и центр-патрон... переходников с разных конусов на разные конуса много не бывает опять же. Т.е. чисто только токарной оснастки у меня более 700 килограмм. Ну эта та, которая больше никуда особо не применяется.
Но ведь наш гуру предлагал ещё и фрезерок заиметь. Помимо денег (это от 300К) это так же тащит за собой кучу оснастки. Т.е. на фрезер у меня килограмм 400-500 точно будет. Это и фрезы и расточные головки и тиски разные и прижимы\прихваты, параллелек и домкратиков только два ящика! И, кстати, фрезу на точиле уже не заправишь. Это надо иметь универсально-заточной станок и уметь им пользоваться. Комплектный будет стоить от 300К. И к нему, кстати, тоооооже нужна гора оснастки.
В целом, получается так: станок сам по себе это как автомобиль без колёс. Он полностью работоспособен, за одним маленьким нюансом. Он никуда не поедет... Короче, это я к чему, прежде чем кидаться в "бизнес по металлообработке" сперва хотя бы чуток поймите о чем там речь.
Всем привет.
Сегодня поговорим о таком прикладном инструменте системного аналитика, как UML.
Зачастую у многих возникает вопрос - а зачем вообще рисовать любые диаграммы и схемы? Мы все такие замечательные, уже научились писать требования, оформлять разными способами (даже красивыми) - в общем-то, по этим требованиям же и так всё понятно?
И отчасти это так. Глобально - качественно собранных и поставленных требований к системе за глаза хватает для того, чтобы система была нормально разработана, без каких-либо проблем. Но зачем останавливать себя в желании "прибраться" в голове или наглядно объяснить что-нибудь команде - ведь наличие наглядной схемы позволяет решить все эти задачи и заметно упрощает жизнь.
Это я подвожу к тому, что если у тебя есть свободное время на создание схемы (а это бывает не так часто), то лучше ее сделать. А возможно и в целом начать аналитику именно с нее. Это поможет структурировать твои собственные мысли, увидеть возможные неточности или не проработанные моменты в том или ином процессе.
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования систем.
UML использует в основном графические обозначения для выражения дизайна проектов. Использование UML помогает проектным группам лучше взаимодействовать между собой и легче вникать в проекты.
Основные цели дизайна UML:
Предоставить пользователям готовый, выразительный язык визуального моделирования, чтобы они могли разрабатывать и обмениваться осмысленными моделями;
Быть независимым от конкретных языков программирования и процессов разработки (важно);
Обеспечить формальную основу для понимания языка моделирования;
Поддержка высокоуровневых концепций разработки, таких как совместная работа, структуры, шаблоны и компоненты.
Преимущества и недостатки проектирования диаграмм:
Начнем с недостатков:
Дополнительная трата времени, которого может и не быть;
Необходимость знать и понимать различные нотации.
Преимущества:
Возможность посмотреть на задачу с разных точек зрения;
Другим членам команды (включая заказчиков) легче понять суть задачи и способ ее реализации;
Диаграммы сравнительно просты для чтения после достаточно быстрого ознакомления с их синтаксисом.
В UML диаграммы подразделяют на два типа — это структурные диаграммы и диаграммы поведения.
Структурные диаграммы показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь. Элементы в структурной диаграмме представляют значимые понятия системы и могут включать в себя абстрактные, реальные концепции и концепции реализации. Существует семь типов структурных диаграмм:
Диаграмма составной структуры
Диаграмма развертывания
Диаграмма пакетов
Диаграмма профилей
Диаграмма классов
Диаграмма объектов
Диаграмма компонентов
Диаграммы поведения показывают динамическое поведение объектов в системе, которое можно описать, как серию изменений в системе с течением времени. А к диаграммам поведения относятся:
Диаграмма деятельности
Диаграмма прецедентов
Диаграмма состояний
Диаграмма последовательности
Диаграмма коммуникаций
Диаграмма обзора взаимодействия
Временная диаграмма
Все мы рассматривать не будем (при желании это можно сделать самостоятельно) - разберем лишь основные, которые наиболее часто используются (по крайней мере в моей практике).
Диаграмма классов — это центральная методика моделирования, которая используется практически во всех объектно-ориентированных методах. Эта диаграмма описывает типы объектов в системе и различные виды статических отношений, которые существуют между ними.
Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:
Ассоциация - представляет отношения между экземплярами типов. Например, человек работает на компанию, у компании есть несколько офисов;
Зависимость — это форма отношения использования, при которой изменение в одном классе - влечёт за собой изменение другого, причём обратное не обязательно.
Агрегация - это ассоциация типа «целое-часть». При этом обе части могут жить отдельно друг от друга (машина - колесо).
Композиция – это такая агрегация, где объекты-части не могут существовать сами по себе (дом - комната).
Пример:
Стоит еще рассказать про такую вещь как "Кратность". По сути между объектами может быть всего 3 типа кратности, которые уже могут варьироваться:
1 к 1. Это значит, что ровно одному объекту соответствует ровно один объект. Например - у одного человека может быть только один паспорт (не берем загранник);
1 ко многим. Одному объекту может соответствовать множество объектов (множество это может быть и 0). Например - один автор написал много книг;
Многие ко многим. Множеству объектов может соответствовать множество других объектов. Например - много поставщиков поставляют много товаров (в том числе пересекающихся).
При этом могут быть частные варианты, такие как, как 1 : 0..* (1 объекту соответствует множество объектов или ни одного. Например, у одного покупателя может быть множество заказов, но их может и не быть совсем). Или 1 : 3..*, т.е. одному объекту соответствует минимум три других и в целом любые возможные комбинации.
Диаграмма прецедентов - описывает функциональные требования системы с точки зрения того, как она будет использоваться людьми и/или взаимодействовать с другими системами.
Сущности, с которыми система должна взаимодействовать, называются actor’ами (эктор, актер), при этом каждый из них ожидает, что система будет вести себя строго определенным образом.
Актер - если упростить, то это какой-то конкретный пользователь или роль, или другая система, подсистема или класс.
Другой участник данный диаграммы - прецедент. Это описание отдельного аспекта поведения системы с точки зрения пользователя (да, это те самые UC, которые рассматривали в прошлой части).
Прецеденты и актеры соединяются с помощью линий. Часто на одном из концов линии изображают стрелку, причем направлена она к тому, у кого запрашивают сервис, другими словами, чьими услугами пользуются. Прецеденты могут включать другие прецеденты, расширяться ими, наследоваться и т. д.
Пример диаграммы:
В языке UML несколько стандартизированных видов отношений между актерами и вариантами использования:
Отношение ассоциации - самая обычная закрашенная стрелочка, которой можно соединять только актера и варианты использования. Она означает, что актер может выполнять действия, описанные вариантом использования.
Отношения обобщения - показывает, что определенный актёр или вариант использования может быть обобщён до другого актёра или варианта использования. Как на примере выше - UC "открытие счета ФЛ" и "открытие счета ФЛ" обобщены в UC "Открыть счет".
Отношение включения - показывает, что включенный UC должен быть обязательно выполнен, при выполнении другого варианта использования, в который он входит.
Например, при предоставлении кредита в банке всегда происходит проверка платежеспособности клиента.
Отношение расширения - показывает, что расширенный UC может быть выполнен в составе того UC, в который он входит, а может и не выполняться. Обязательности уже нет.
Например, при предоставлении кредита в банке может происходить с предоставлением налоговых льгот, при определенных условиях, но это не обязательно.
Диаграмма состояний - это тип диаграммы, используемый в UML для описания всех состояний системы и переходов между ними. Она отображает разрешенные состояния и переходы, а также события, которые влияют на эти переходы. Кроме этого помогает визуализировать весь жизненный цикл объектов и, таким образом, помогает лучше понять системы, основанные на состоянии.
Другими словами - такая диаграмма показывает то, как сущность переходит из одного состояния в другое.
На самом деле очень интересный тип диаграммы и их неплохо использовать для определения статусной модели ваших сущностей, для того, чтобы спроектировать какие у них могут быть статусы и при каких условиях они будут в эти статусы переходить.
Если рассматривать схему из примера, то это работает примерно так:
Стартовый статус нашей системы = "Бездействие". Дальше, если срабатывает триггер (допустим, получаем сообщение от датчика температуры, что она превысила установленную норму) - то система начинает переходить к общему статусу "Охлаждение". Он в свою очередь состоит из нескольких процессов - запуск компрессора, готовность и работа вентилятора.
Система находится в этом состоянии, до тех пор пока снова не срабатывает определенный триггер, например - получение сигнала от датчика температуры о том, что она вернулась в норму. В этом случае вентиляторы останавливаются и система снова переходит в статус = "Бездействие".
Или, например, случился сбой - система перешла в соответствующее состояние и, допустим, не может выйти из него без ручного вмешательства техника.
Могу из своего опыта сказать, что диаграммы очень важны на проекте и желательно, чтобы при его документировании они использовались. Потому что одно дело бросить взгляд на диаграмму, прочитать ее и понять что происходит в нужном тебе процессе, другое дело вчитываться в пространное ТЗ с техническими подробностями, которые тебе, возможно, сейчас и не нужны.
Плюс, многие разработчики очень просят, чтобы диаграммы добавлялись в ТЗ, потому что им так намного проще осознавать что нужно сделать и что за чем идет (особенно актуально для интеграций). Да и в целом большинство людей визуалы.
P.S. Про UML это еще не всё, но пост получается очень большим, поэтому разобью на две части и добью остаток про UML в следующей. Заодно там же начну рассказывать про BPMN.
P.P.S: Завтра (25.02.2023 в 12.00 московского времени) у меня в телеграмме пройдет эфир где я буду отвечать на разные вопросы про карьеру/профессию/перспективы/развитие и т.д. В общем на все вопросы, которые мне будут задавать участники эфира.
Ничего продавать не буду, поэтому если хотите поболтать\послушать или даже есть какие-то вопросы на указанные темы - приходите, буду рад всем. Ссылка на телеграмм в моем профиле.
Всем привет.
Сегодня у нас небольшая практика и мы продолжим дополнять "ТЗ" нашей ITSM-системы сценариями использования и пользовательскими историями, которые рассмотрели в прошлом посте.
Второй:
Итого, с помощью этих двух UC мы покрыли те же самые функции, которые мы описывали в первой части практики. Само собой, это получилось менее детально и продуманно, потому что сам формат этого не подразумевает.
Однако, для верхнеуровневых требований он вполне подход (и для согласования с заказчиками в том числе).
Как пользователь, я хочу иметь возможность отменять ранее созданные заявки, если проблема потеряла актуальность;
Как пользователь, я хочу изменять приоритет заявки;
Как сотрудник поддержки, я хочу иметь возможность перевести заявку на другую рабочую группу, если проблема вне моей зоне ответственности;
Как руководитель, я хочу иметь возможность выгружать отчет по своем отделу в разрезе сотрудников, чтобы отслеживать их эффективность;
Как заказчик услуг, я хочу иметь возможность просматривать статистику вовремя закрытых заявок в разрезе отделов поддержки, чтобы отслеживать их попадание в SLA;
Как пользователь, я хочу иметь несколько быстрых фильтров, выбрав один из которых - я смогу найти сразу все заявки из нужной категории;
Как пользователь, я хочу иметь возможность вернуть заявку обратно в работу, если меня не устроило предлагаемое решение.
P.S.: Думаю, что еще 2-3 поста займет рассказ про различным инструменты необходимые системному аналитику и после этого можно будет уже наконец перейти к самой мякотке - интеграциям.
P.P.S: Уже по традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
Всем привет.
Продолжим наше погружение в теоретические знания, необходимые системному аналитику (это применимо также и для бизнес-аналитика, первые три части моих лекций - точно).
В первую очередь поговорим про Use case (далее используются термины «варианты использования», «сценарии», «юзкейсы»).
Use case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни.
Чтобы ответить на вопрос “как их писать” - приведу пример, после которого всё станет понятно. Допустим, разберем простейший сценарии самой стандартной авторизации пользователя в систему:
Сам по себе UC должен описывать только успешный сценарий. Если же есть какие-то ответвления от него, то они описываются отдельно в расширениях - как в данном примере. Также, если альтернативный сценарий слишком большой - то он описывается отдельным сценарием использования, как, например, для варианта с "Напомнить пароль". Потому что по сути, это отдельный и самостоятельный сценарий, который еще даже больше текущего.
Т.к. варианты использования является набором требований более высокого уровня абстракции, чем набор отдельных функциональных требований - только с помощью них глубокий системный анализ провести невозможно. Но для некоторых проектов (где системный аналитик, или просто аналитик не глубоко погружен в технические дебри) и компаний - очень даже подходит, когда нужно описать для разработчиков верхнеувровневые требования.
И кроме этого, UC это естественный способ описывать диалог, он понятен человеку без подготовки и поэтому с помощью них очень удобно согласовывать задачу с заказчиком, без необходимости показывать всё своё сложное и большое ТЗ.
User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
Особенности:
Не являются детальным описанием требований, а представляют собой обсуждаемое намерение (нужно сделать что-то, вроде этого);
Короткие, легко читаемые и понятные всем (как разработчикам, так и пользователям);
Описывают небольшую часть функциональности, которая может быть реализована за короткий промежуток времени;
Не занимают больших, громоздких документов. Как правило сгруппированы в списки.
Структура - Как, <роль/персонаж пользователя>, я <что-то хочу получить>, <с такой-то целью> .
Примеры:
Как пользователь, я хочу иметь возможность добавить комментарий к заявке для предоставления дополнительной информации;
Как сотрудник поддержки, я хочу иметь возможность перевести заявку в статус "Отложено";
Как пользователь, я хочу видеть все заявки, созданные мной, чтобы отслеживать их статус.
В этих пожеланиях есть один actor, одно действие и одна ценность (value, impact).
C актером все более-менее просто. Вы выделили персонажей, или у вас есть роли, и вы легко их вписываете в начало истории.
Действие
Наверное, здесь сложно ошибиться - это суть истории, “что нужно сделать”. Что можно улучшить. Действие должно быть одно - основное. Нет смысла описывать “авторизуется и выполняется поиск”. Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне “ЧТО?” делает, а не “КАК?” Это главное в истории. Опишите проблему, а не ее решение. То, "Как" сделать - вы потом опишите в других документах, в том же ТЗ или постановке.
Ценность
Главная проблема с User Story. Вы всегда знаете первую часть истории,но всегда сложно указать для чего это делается. Но, все должно быть указано как User story согласно шаблону, и потому вы пишите “чтобы …” и какую-то чушь, в которую сами не верите.
Уберите эту часть из истории. Если ничего не потеряли - значит формализация ценности в истории была бесполезна. Что же можно сделать?
Отказаться от формулировки “чтобы”. Это корень зла. Да, для каких-то историй можно указать ценность истории в таком формате, но не для большинства.
Также можно перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на того актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.
Кроме этого, есть хороший инструмент оценки пользовательских историй - INVEST (лично мне, импонируют люди, которые придумывают такие зашифрованные вещи в словах. Сразу вспоминается система S.P.E.C.I.A.L и подобные ей):
P.S.: Удивлен, что пост с практическим пояснением лекционного материала зашел хуже, чем сама лекция) Дайте фидбэк - нужны вам вообще практика с примерами?)
P.P.S: Уже по традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.P.S: Если я не путаю - Пикабу мне в самом начале предлагал создать пост-опрос для пикабушников. Но сейчас я в упор не вижу этого функционала. Тыкните носом в него, пожалуйста (если мне не померещилось) - есть хорошая идея для опроса)
Всем привет.
Штож, обойтись без того, чтобы тебя обозвали душнилой (пусть и косвенно, спасибо за это), когда ты рассказываешь теорию про что-нибудь - невозможно.
Именно поэтому на своих обучениях, я очень настаиваю на том, чтобы мои менти делали домашние задания (а у меня их много, больше, чем многим хотелось бы) - потому что без практики чтение теории бесполезно (хотя всё также необходимо, как минимум ее спрашивают на собеседованиях - поэтому уж простите, но буду душнить и дальше).
Как это происходит - мы выбираем какую-нибудь систему, на которую менти хотел бы написать ТЗ и после каждой пройденной темы закрепляем ее на практике. Прошли виды требований - написали требования, прошли UC\US - написали UC\US, прошли REST - описали пару микросервисов и всё это для одной системы, а не на рандомные темы. По итогу получается очень даже неплохой документ для портфолио.
Поэтому буду тут делать тоже самое. Давайте в качестве системы, которую мы будем описывать, возьмем ITSM-систему (ближайшие аналоги: JIRA, NAUMEN service desk). Это такой подвид систем, которые позволяют управлять IT-услугами.
Обычно, они предоставляют возможность заказчику заводить бизнес-инициативы/запросы на улучшения системы/запросы на устранение багов в качестве заявок в системе и отслеживать их жизненный путь. Также они позволяют самой команде разработки заводить задачи для себя, отслеживать их, приоритезировать, управлять и так далее.
Сейчас напишем небольшое ТЗ для такой системы.
Не пренебрегайте этим разделом, пожалуйста. ТЗ вы пишете не для себя, помните это.
Заявка – сущность системы, которая содержит информацию о запросе пользователя (как заказчика, так и члена команды разработки). Основная бизнес-сущность системы.
SLA (Service Level Agreement) - договор между заказчиком услуги и ее поставщиком, определяющий права и обязанности сторон и согласованный уровень качества предоставления услуги.
В формате service desk системы, как правило, это количество времени, за которое должна быть решена заявка в разрезе приоритетов. Условно, баг с критичным приоритетом должен решиться за 24 часа.
На данный момент связь с командой разработки осуществляется посредством почты, через которую отправляются запросы на внедрения нового функционала, либо исправления различных дефектов. Нередкий случай - когда такое письмо теряется\игнорируется и задача долго не решается. Отсутствует прозрачность процесса и понимание того, на каком этапе сейчас находится запрос.
БТ1: Увеличить прозрачность процесса внесения изменений в систему\исправления дефектов.
В каждый момент времени заказчик должен понимать на каком этапе жизненного цикла находится заявка. Должна быть возможность оставлять комментарии\вопросы внутри сущности "Заявка", для оперативной коммуникации с командой разработки.
БТ2: Система должна вести статистику и отчетность по всем заявкам с целью отслеживания количества выполненных вовремя\просроченных\отмененных\отложенных заявок для определения результативности команды разработки. Необходимо для проверки того, выполняет ли она заявки в срок, согласно SLA.
... Что-то еще.
Тут миллион возможных фичей, мы возьмем для примера парочку из них:
Краеугольный камень такого рода систем - создание заявки;
И поиск заявок по различным фильтрам.
Требуется реализовать процесс создания заявки следующим образом: по нажатию на кнопку "Создать заявку", открывается диалоговое окно создания заявки, согласно макету:
Я максимально не дизайнер, поэтому если у вас это вызывает кровотечение из глаз - просьба не вызывать археологов и не кидаться тапками.
Пикабу не умеет в таблицы, да?
Таблица 1. Состав элементов формы диалогового окна создания заявки.
По нажатию на кнопку "Создать" требуется проверять были ли заполнены все обязательные поля:
Если нет, то не заполненные обязательные поля подсвечиваются красным и отображается подсказка с стандартным текстом.
Если все обязательные поля были заполнены, то инициируется процесс создания заявки (когда будем проходить интеграцию front-to-back распишем детально этот момент. Так же опишем модель данных объекта task (заявка) и всё остальное необходимое, для разработчиков).
Требуется реализовать возможность поиска заявок по различным параметрам фильтрации, таким как (тут я уже фронт и фильтры рисовать не буду):
Приоритет;
Исполнитель;
Описание заявки;
Статус;
Дата создания с\Дата создания по;
Просроченные заявки
Куча других вариантов
Если был выбран фильтр по приоритету, то найти все заявки, у которых priority (приоритет) = выбранному значению.
Если был выбран фильтр по исполнителю, то найти все заявки, у которых assignee (исполнитель) = выбранному значению (представим, что там выпадающий список всех сотрудников).
Если был выбран фильтр по описанию заявки, то требуется выполнить поиск по подстроке и найти все заявки, у которых в полях topic, shortDescription и description найдено введенное значение.
Описание логики фильтрации для кучи других вариантов)
Все фильтры могут работать одновременно через условие ИЛИ. Если в результате поиска не было найдено ни одной заявки, то отобразить сообщение с текстом "По вашему запросу ни одной заявки не найдено".
Примерно в таком формате за несколько человекодней можно описать вполне себе хорошее ТЗ на различные функции нашей предполагаемой системы.
Само собой, я учел не все моменты, не все ограничения\необходимые требования и вот это всё - поэтому приветствую критиков в комментариях.
Однако, это и не было целью - целью было показать то, как нужно писать ТЗ и требования (чтобы показать тем, кто их не видел - как они вообще выглядят). Ну и для закрепления на практике примером рассказанный ранее материал - чтобы это не было просто очередной "скучной лекцией или рефератом".
P.S. Спасибо @himen.ru, за дельные и конструктивные комментарии.
P.P.S.: Уже по традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
Всем привет.
Сегодня перейдем к более прикладной и конкретной теории, без которой нельзя обойтись хоть бизнес-, хоть системному аналитику (к слову, один из самых частых вопросов, который задают на собеседовании начинающего аналитика - какие виды требований ты знаешь? Какими качествами требование должно обладать?).
Не буду душнить и писать сухую теорию про то, что требование - это совокупность утверждений относительно атрибутов, свойств или качеств программной системы... бла-бла-бла. Я думаю, что все понимают - что такое требование к системе. Теперь давайте разберемся, какими они бывают.
Общепринято делить требования на следующие категории:
Функциональные требования, которые включают в себя:
Бизнес-требования - что система должна делать с точки зрения бизнеса. Т.е. содержат в себе высокоуровневые задачи и цели заказчика. Как правило их формулируют именно те люди, которые заказывают какой-либо продукт. Они описывают те цели, которые заказчик намеревается достичь с помощью системы (ПО). В 90% случаев эти требования направлены на получение дополнительной прибыли заказчика:
Либо через внедрение доработки\системы, которая будет приносить прямую прибыль через, допустим, привлечение новых клиентов (привет ДБО и различные мобильные приложения);
Либо через сокращение издержек и оптимизацию процессов, что тоже приводит к увеличению прибыли;
Либо по необходимости. Например, когда центробанк выдал на-гора очередное распоряжение по необходимости считать ПДН (показатель долговой нагрузки) клиента - банкам ничего не остается делать, кроме как внедрять соответствующие доработки. Ну тут тоже есть косвенная финансовая выгода: ты делаешь доработку > не получаешь штрафы и не теряешь лицензию > профит.
Пример бизнес-требования: “Требуется уменьшить время работы над одной заявкой сотрудником колл-центра на 50%” (чувствуете прямую выгоду? Быстрее обработка > больше заявок будет обработано в единицу времени > дешевле стоимость обработки или просто выше КПД).
Пользовательские требования описывают цели и задачи, которые пользователи смогут решить с помощью системы. Их часто представляют в виде сценариев использования (Use case, о которых поговорим позже).
Функциональные требования (системные) - определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что должны сделать разработчики, чтобы по итогу получилась система, позволяющая пользователь выполнять их функционал и выполняющие бизнес-требования заказчика.
Например, “Требуется реализовать возможность поиска товара по продавцу, категории, диапазону сумм и рейтингу”.
Нефункциональные требования описывают характер поведения системы и атрибуты качества и также делятся на несколько категорий:
Бизнес-правила - описывают почему система должна работать именно так в разрезе внутренних корпоративных правил, требований закона и различных стандартов.
Например, многие табачные компании и компании, производящие алкоголь, требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability;
Атрибут качества - описывают дополнительные характеристики продукта в различных измерениях, важных для пользователя или разработчиков. Эти характеристики включают практичность, портабельность, целостность, эффективность, устойчивость;
Ограничения - это формулировка условия, которое модифицирует требование или набор требований сужая выбор возможных решений.
Например, "Требуется ограничить загрузку файлов размером более 20мб", "Ограничить работу приложения только на IOS" или только в браузере Chrome и т.д.
Внешние интерфейсы - описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или системы, а также требования к API других систем, с которыми осуществляется интеграция.
Именно такую классификацию требований предложил и описал Вигерс в своей книге "Разработка требований к программному обеспечению" и сейчас, в целом, все придерживаются ее.
На схеме это выглядит примерно вот так:
С видами требований разобрались. Теперь нельзя обойти стороной вопрос о том, а какими они должны быть, эти требования? Вот список качеств, которыми требование, очень желательно, должно обладать:
Атомарность - требование является атомарным, если его нельзя декомпозировать на несколько требований. Например, “Требуется ограничить загрузку файлов размером более 20мб” является атомарным, т.к. его нельзя разделить на несколько частей;
Завершенность и полнота - требование содержит полный набор информации для однозначного понимания;
Краткость - чем лаконичнее требование, тем лучше;
Консистентность - требование не должно противоречить самому себе и другим требованиям;
Выполнимость - требование возможно реализовать в рамках проекта (его сроков и бюджета);
Проверяемость - реализованность требования может быть определена через один из четырёх возможных методов: осмотр, демонстрация, тест или анализ;
Однозначность - разработчик, тестировщик (или любой другой человек) должен понять это требование также, как и вы. Соответственно требование не должно быть расплывчато, размыто, не должно содержать непонятных аббревиатур.
Понятно, что на практике далеко не все требования обладают каждым из этих качеств. Где-то из-за спешки, где-то из-за ошибки или даже нежелания. У кого-то просто своеобразный стиль и он любит писать длинный сложносочиненные требования - и это неплохо, там где уместно. Самое главное, чтобы требование было консистентным, завершенным, выполнимым и однозначным.
У меня, как и у многих на самом деле, в начале моей карьеры аналитика были проблемы с тем, что я просто физически сопротивлялся тому, чтобы писать кратко. Мне казалось, что если я написал одно предложение и этого будто бы хватало - что-то не так и нужно налить воды и чего-нибудь еще придумать. Но на самом деле, если вы уместили решение задачи в одно предложение и оно полностью покрывает всё что необходимо - эт круто и не нужно этого пугаться (но перепроверить, что ничего не упущено не помешает =) )
P.S.: Опять получился длиннопост, но скорее всего все последующие будут примерно такими же, т.к. на самом деле темы объемные и уместить все что хочется (и необходимо) рассказать в одном посте достаточно тяжело.
P.P.S.: Буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
Всем привет, меня зовут Сергей, я ведущий системный аналитик в IT с опытом более 7 лет, в основном, в различных крупных ФинТех проектах и в заказной разработке. Хочу поделиться своим опытом тут, на Пикабу (видимо, наступила пора не только читать, но и писать и постараться принести этим пользу сообществу).
Сегодня расскажу в целом про профессию системного аналитика (СА), чем мы занимаемся, какую пользу приносим и насколько это сейчас востребовано на рынке.
Системный аналитик - это связующее звено между заказчиком, каким бы он не был, и технической частью команды разработки. Если очень коротко - то его главная цель преобразовать обширный, и порой такой непонятный язык бизнес-заказчика в конкретные, выверенные требования. Т.е. уйти от "Я хочу получить свой сайт с функционалом маркетплейса.. ну как вон там, у ОЗОН" и прийти к "Требуется разработать систему.." и тут ТЗ на *дцать страниц.
Т.е. результатом работы СА становятся формализованные требования в формате ТЗ или любом другом принятом на проекте виде (это могут быть просто набросанные в Jira или Confluence предложения, являющиеся требованиями. Т.е. не нужно пугаться, что это прям всегда огромные, сложные и зубодробительные документы по ГОСТу, как дипломная работа - как раз этого почти и нет, разве что на каких-то госпредприятиях).
Кроме этого отвечаем за улучшение работы системы, обеспечиваем её эффективную работу для успешного выполнения целей заказчика и пользователей. Обязаны понимать тонкости и нюансы работы своих систем и возможные ограничения реализации вызванный ими, чтобы подсвечивать это заказчикам, корректировать их пожелания и требования с учетом особенности системы.
И что самое интересное и важное лично для меня в этой профессии, что тут можно (и нужно) реализовать как свои творческие, так и свои технические способности, потому что она находится на стыке этих двух сфер. И hard skills очень важны, но и без soft skills совсем никуда (кстати, если вы вдруг собираетесь сменить профессию и\или войти в IT с нуля, если у вас есть хорошие soft skills, то даже при минимальных хардах - вам будет проще. Потому что последним научиться можно и не так уж сложно, а вот взрастить в себе "мягкие" заметно тяжелее, хотя тоже возможно).
И что больше всего меня радует в последние 2-3 года - с нами, как с аналитиками в частности и с командой разработки в целом, наконец научились работать заказчики. Они уже знают, чего хотят, знают как эти хотелки формализовать таким образом, чтобы нам было проще понять и реализовать (некоторые заказчики настолько крутые, что в целом могут и сами ТЗ на раз-два написать). Плюс почти на всех проектах собрались полностью укомплектованные команды со всеми закрытыми позициями. Т.е. теперь системному аналитику не приходится выполнять функцию и бизнес-аналитика и проектировщика, и тестировщика и еще специалиста второй линии поддержки для полного счастья. Есть возможность полностью сконцентрироваться на том, что тебе нравится - для меня это, например, описание технической части, интеграции между системами. Можно даже не общаться с заказчиками, если нет такого желания, так как для этого есть бизнес-аналитик и PO от которых тебе и поступают требования, прошедшие первую стадию формализации.
Всё вышесказанное применимо, опять-таки, к сфере ФинТех (банки, страховые, прочие крупные финансовые организации). Про другие сферы мало что могу сказать, знаю, что и там подвижки есть в этом направлении.
По поводу востребованности - на данный момент ощущается сильная нехватка квалифицированных специалистов, уровня хотя бы middle\middle+ даже среди известных мне проектов. Если говорить по поводу джуниорских или стажерских позиций, то тут ситуация заметно хуже, не буду скрывать, и войти сейчас в разы тяжелее, чем пару лет назад.
Солидную часть в это положение внесли бесконечные (и не всегда очень полезные) курсы, да простят меня geekBrains'ы и иже с ними, которые за последний только год подготовили несколько тысяч начинающих специалистов, а суммарно по всем образовательным площадкам вырисовывается очень большое число людей, которым пообещали работу после курсов и теперь они в поиске. Поэтому на позиции начального уровня конкуренция большая, действительно. Однако! Если хорошо подготовиться, изучить те темы, которые почти нигде не освещаются (в основном это как раз техническая часть, различные виды интеграции), составить качественное резюме и написать сопроводительное письмо - шансы сильно повышаются, доказано на моей практике в том числе.
Вводный пост получился заметно больше, чем я хотел (еще и без картинок) - простите, увлекся. Если кто-то осилил до этого момент - крайне признателен. Еще более признателен буду вопросам по карьере\профессии\чему угодно связанному со сферой IT - постараюсь ответить на всё.
В следующей части расскажу в целом про команду - какие есть позиции, кто чем занимается и как устроен процесс разработки любой системы или продукта.
P.S. Если заинтересовались - переходите в мой телеграмм-канал , там также делюсь разным про профессию. Если кто-то хочет более хардовой инфы, про интеграцию и прочие сложные штуки - читайте последние посты)
P.P.S: Ну и как принято на пикабу - первый пост, кидайте тапками, подписывайтесь, все дела.
Женщина 34 года
— Мой муж буквально помешался на каких-то странных теориях, - крайне раздраженным голосом заявила клиентка. – Буквально за пару лет он изменился до неузнаваемости и мне начало казаться что я живу с совершенно незнакомым человеком.
— Расскажите подробнее, пожалуйста.
— Все началось несколько лет назад, когда он посмотрел этих проклятых Мстителей, где они там дрались с каким-то мужиком с большой золотой перчаткой. Он там по фильму утверждал что вселенная перенаселена и совершенно необходимо контролировать число живущих. Щелк пальчиками и половина людей исчезла.
— И как это соотносится с вашим мужем? – спросила я, когда женщина внезапно осеклась.
— Как сейчас помню: Рома после фильма заявил что тот злодей в принципе прав, и ничего плохого в его решении нет. Мол, как минимум наша планета стала бы лучше если бы в ней не было половины жителей. Он тогда еще посмеялся, что и сам бы с радостью избавился от обочечников и риэлторов. Тогда я напомнила ему, что тот мужик не выбирал кому жить, а кому нет – он просто уничтожил случайных людей, лишь бы получилась половина от того что имелось сначала. Как бы он заговорил, если бы я бы внезапно обернулась облачком пыли.
— И что он ответил?
— Он промолчал, но видать этот разговор запал ему в душу, что после этого он то и дело начал залипать в интернете. Раньше муж нет-нет да играл в игрушки или смотрел фильмы, то теперь он начал что-то читать. Поначалу я даже обрадовалась – бросил игрушки и слава богу, даже решила подглядеть что он там читает и ничего особо не поняла. Какие-то экономические термины, цифры и расчеты – причем в таких количествах, что я бросила эту затею и на какое-то время забыла о происходящем.
— А потом муж сам сообщил вам о том, над чем работает?
— Я сидела на кухне, красила ногти – готовилась к началу рабочей недели и тут заходит Рома и предлагает попить чаю. Ну я и согласилась, а он как бы невзначай начал рассказывать про умершего несколько веков назад английского ученого по фамилии Мальтус, который разработал теорию о перенаселении нашей планеты. Вы с ней знакомы?
— В общих чертах - она гласит, что человечество прирастает в геометрической прогрессии, а производство необходимых для него ресурсов – в арифметической. Поэтому рано или поздно мы столкнемся с дефицитом и последующими за ним кризисами самого разного типа.
— Замечательно, - кивнула Ирина и немного расслабилась. – Рада что мне не придется объяснить вам ее значение. Короче, Рома заявил что теперь собирается сделать все что может чтобы мы вошли в тот самый пресловутый «Золотой миллиард». Типа теперь мы должны выложиться на максимум чтобы начать зарабатывать большие деньги и, желательно, переехать в Европу или Америку. Я подумала, что это что-то вроде шутки – куда уж нам такое: я - обычный педагог, а он – целыми днями копается в Камазах. Мы не знаем языка, да и не обладаем сколько-нибудь значимой профессией. А он только покачал головой и заявил, что у него есть план…
— Дайте догадаюсь – он решил «вкатиться» в ИТ?
— Хуже, - криво усмехнулась она. – Он решил, что вкатиться должна я, просто потому что у меня мозги лучше работают. Типа года хватит, а он уж как-нибудь прокормит нас за это время.
— И что вы решили?
— Поначалу я приняла эту идею в штыки - ведь все уже налажено: дети меня любят, коллеги ценят, да и работа мне нравится. Плюс к этому мне не особо по душе программирование, и зачем менять любимое занятие на что-то подобное, не особо понятно. Деньги, конечно, там платят хорошие – но какой в них смысл, если я через полтора года выгорю и снова вернусь к тому, с чего начала. Но потом Рома меня уговорил, пообещав золотые горы и цветные небеса. Сдавшись под его напором, я взялась учиться и, к его чести, Рома действительно окружил меня всевозможной заботой: взял на себя домашние дела и заботу о ребенке, причем так, что я даже не слышала и не видела их обоих.
— Но вы все равно не выдержали и бросили?
— Как я уже говорила, это – не мое. Через месяц я прекратила заниматься, извинилась перед мужем, что не оправдала его надежд и предложила вернуть все как было. И знаете, что он мне ответил? Ни за что не догадаетесь… Что у него есть новый план, по которому не нужно становиться программистом – оказывается, в Германии, сейчас жуткая нехватка учителей и людей рабочих специальностей. Дело за малым – выучить язык и вперед. То есть предполагалось, что теперь, я буду вместо программирования учить немецкий, а потом мой педагогический опыт будет использован в качестве возможности для переезда. Я хотела сказать ему что план не очень-то и хорош, но промолчала.
— Почему?
— Да потому что этот чертяка, несмотря на рабочую профессию – крайне языкастый! Он кого угодно уговорит что белое – это черное и наоборот. Вот и я сдалась и пошла учиться. Правда потом началась пандемия и все накрылось медным тазом и мне пришлось выйти на работу, поскольку свою Рома потерял. Но он все равно продолжает создавать все новые и новые варианты как бы нам попасть в число «избранных» и выжить в будущей катастрофе. А меня это уже серьезно бесит! Муж только и делает что говорит об этом: о том, что индусы с двухтысячного года приросли на четыреста миллионов, а в Бангладеше и Египте народу хватит на две России, и так далее и тому подобное… Ужас просто!
— А вам просто хочется спокойно жить и ничего не менять?
— Вот именно.
— Но вы же понимаете, что он делает все это ради вас и ребенка?
— Понимаю, но мы же не всесильны – может хватит уже пытаться?
— Что же, в таком случае могу порекомендовать или откровенно поговорить с ним самостоятельно или привести сюда для того чтобы я могла организовать беседу на троих. Впрочем, есть и еще один способ, довольно быстрый и эффективный, правда последствия могут оказаться ничем не лучше чем то, что есть сейчас.
— О каком способе вы говорите?
— Подарите ему пару книжек Карла Маркса – он там в пух и прах разносит идеи Мальтуса. Я сама читала, поэтому знаю.
— А что за последствия?
— Он вполне может проникнуться новыми идеями и удариться в социализм. В этом нет ничего плохого, но, возможно, конкретно в вашем случае это будет лишним.
— Да я лучше буду жить с человеком, который будет петь Интернационал, нежели с тем, что уговаривает уехать за бугор в неизвестность, - рассмеялась она. - В какой, говорите, книге это все написано…?
