Делегирование — это не спихивание своих задач на других людей, а передача части функций, когда ответственность за результаты остаётся на делегирующем. А иногда вместе с задачей передаётся и часть полномочий. В этом случае на плечи другого человека ложится ещё и ответственность за результаты. 

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

В процессе передачи задачек другому человеку тебе пригодится чек-лист по делегированию из книги Джоаны Ротман и Эстер Дерби (Johanna Rothman and Esther Derby) «Behind Closed Doors. Secrets of Great Management» (на русский не переводилась). 

Авторы сделали короткий чек-лист для самопроверки перед делегированием задач. 

А вот 14 пунктов чек-листа: 

? Я учитываю все факторы риска при делегировании этой задачи?

? Выбранный сотрудник(и) сумеет распорядиться возложенными полномочиями?

? Продумано, кому будет делегировано дело: отдельному сотруднику или команде/группе сотрудников?

? Хорошо продуман выбор уровня полномочий, который нужен для решения этой задачи? .

? Решено ли, насколько большой пласт работы я собираюсь делегировать?

? У получателя задачи достаточно навыков для выполнения этой работы?

? Созданы все организационные условия для выполнения этой задачи?

? У сотрудника есть все инструменты для выполнения этой задачи?

? Ясно, каким должен быть конечный результат?

? Ясно, каким должен быть результат промежуточных этапов?

? Установлены необходимые ограничения — бюджет, доступные ресурсы, в том числе человеческие, качество?

? Для выполнения задачи установлен чёткий дедлайн?

? Оговорено, как часто и в какой форме я буду получать информацию о ходе выполнения работы и промежуточных этапов?

? Если понадобится помощь — понятно, к кому обратиться, чтобы получить её? 

Как работать с чек-листом

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

Всем привет.

Сегодня перейдем к более прикладной и конкретной теории, без которой нельзя обойтись хоть бизнес-, хоть системному аналитику (к слову, один из самых частых вопросов, который задают на собеседовании начинающего аналитика - какие виды требований ты знаешь? Какими качествами требование должно обладать?).

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

Виды требований.

Общепринято делить требования на следующие категории:

• Функциональные требования, которые включают в себя:

  • Бизнес-требования - что система должна делать с точки зрения бизнеса. Т.е. содержат в себе высокоуровневые задачи и цели заказчика. Как правило их формулируют именно те люди, которые заказывают какой-либо продукт. Они описывают те цели, которые заказчик намеревается достичь с помощью системы (ПО). В 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: Ну и как принято на пикабу - первый пост, кидайте тапками, подписывайтесь, все дела.

Всем привет.

Настала пора наконец закончить с прелюдиями и перейти к рассказу про один из самых важных навыков системного аналитика - REST. Больше важны навыки практического применения\проектирования, но и теория тоже важна. Как минимум для прохождения собеседования, потому что значительная часть вопросов приходится как раз на интеграцию и знание REST в том числе.

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

REST

Representational State Transfer (REST) в переводе — это передача состояния представления.

Сам по себе REST – это архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Архитектурный стиль – это набор согласованных ограничений и принципов проектирования, позволяющий добиться определённых свойств системы.

И у него есть определенные принципы, которые важно понимать и применять при проектировании системы.

1. Client-Server (клиент-серверная архитектура)

В рамках данного принципа самое важное - это отделение клиента и сервера. Клиент - это интерфейсная часть (уровень представления), сервер - это центральное звено системы, на котором реализованы все основные функции системы (наш backend). Более подробно рассмотрено в части 6 этой серии.

2. Stateless. Без состояния

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

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

Поэтому каждый запрос рассматривается индивидуально, как будто бы не было ничего до, и не будет после. Соответственно клиент в этом случае, обязан предоставить все необходимые данные для успешного выполнения запроса. Это, пожалуй, почти единственная логика, которая должна быть на клиенте.

3. Единообразие интерфейса

Принцип гарантирует, что между клиентом и сервером существует общий язык (интерфейс), с помощью которого они будут понимать друг друга. Т.е. клиент посылает понятные серверу запросы, использую конкретные HTTP-методы, сервер посылает ответ в понятном клиенту формате.

Это достигается через несколько субограничений:

1. Идентификация ресурсов

В терминологии REST что угодно может быть ресурсом — HTML-документ, изображение, информация о конкретном пользователе - то, чему можно дать имя. Каждый ресурс должен быть уникально обозначен постоянным идентификатором. «Постоянный» означает, что идентификатор не изменится за время обмена данными, и даже когда изменится состояние ресурса. Если ресурсу присваивается другой идентификатор, сервер должен сообщить клиенту, что запрос был неудачным и дать ссылку на новый адрес.

Тут важно понимать, что в REST (в идеале, по крайней мере), ресурс может быть только существительным, а не глаголом. Потому что за "глагол", т.е. действие - отвечает конкретный метод.

2. Управление ресурсами через представления

Второе субограничение «унифицированного интерфейса» говорит, что клиент управляет ресурсами, направляя серверу представления, обычно в виде JSON-объекта, содержащего контент, который он хотел бы добавить, удалить или изменить. В REST у сервера полный контроль над ресурсами, и он отвечает за любые изменения.

Когда клиент хочет внести изменения в ресурсы, он посылает серверу представление того, каким он видит итоговый ресурс (а для этого, сервер сначала должен предоставить эту информацию клиенту). Сервер принимает запрос как предложение, но за ним всё так же остаётся полный контроль.

3. Самодостаточные сообщения

Самодостаточные сообщения — это ещё одно ограничение, которое гарантирует унифицированность интерфейса у клиентов и серверов. Только самодостаточное сообщение содержит всю информацию, которая необходима для понимания его получателем. В отдельной документации или другом сообщении не должно быть дополнительной информации.

4. Кэширование

В данных запроса должно быть указано, нужно ли кэшировать данные (сохранять в специальном буфере для частых запросов). Если такое указание есть, клиент получит право обращаться к этому буферу при необходимости.

Это нужно для того, что максимально ускорить обработку запроса от клиента. Для примера, если нам нужно часто получать информацию о пользователе (а сама информация о пользователе меняется достаточно редко, что важно), то мы можем закэшировать эту информацию.

Т.е. стандартный запрос выглядит условно так: Фронт -> микросервис адаптер к фронту -> какой-нибудь микросервис MDM системы пользователей -> база где лежат пользователи и потом обратный путь. Это не прям мгновенно всё происходит. Что мы делаем - например, наш фронт прислал запрос GET /user/121, мы проделали этот путь, описанный выше, но еще и сохранили эти данные в кэше на уровне микросервиса-адаптера. В следующий раз, когда фронт вызовет метод GET /user/121, наш путь будет намного короче и быстрее - всего лишь от фронта к нашему же микросервису в кэш и сразу обратно.

Тут есть множество нюансов, которые нужно учесть - но в целом полезный инструмент.

5. Система слоев

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

Но что самое замечательное, при добавлении новых слоев между клиентом и сервером - их не нужно дорабатывать. Т.е. не важно, если у нас архитектура выглядит как просто "Клиент" -> "Сервер", или "Клиент" -> "Прокси" -> "Балансировщик" -> "Несколько серверов" - их логика не меняется (тут разработчики могут меня поправить или дополнить, буду благодарен).

Что-то вроде того:

Еще есть отдельный принцип "Код по требованию", который подразумевает то, что клиент может получить с сервера прям "кусок кода" (условно), который ему необходимо выполнить у себя.

Звучит интересно, но честно, ни разу не сталкивался, поэтому не могу что-то детальное рассказать.

P.S.: В следующих постах расскажу про best practices, связанных с именованием эндпоинтов и прочими полезными штуками для проектирования своих апишек.

По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

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

Еще небольшое предисловие - судя по комментариям к предыдущему посту, не все понимают, что не обязательно, что ВСЕ эти вопросы попадутся вам одновременно. Это наиболее вероятные вопросы, которые вам зададут ( по крайней мере актуально для ФинТех сферы). Ну и опять же, всё очень зависит от интервьюера, его опыта и тех целей, которые ему поставило руководство компании\проекта, на интервью.

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

Более техническая часть собеса:

1. Архитектурно-интеграционные вопросы:

   1. Что такое клиент-серверная архитектура? Что такое тонкий и толстый клиент, чем они отличаются? (Тут никто не ждет прям уверенных технических знаний и деталей реализации того или иного подхода, но в общих чертах знать нужно).

   2. Что такое HTTP? Какие основные методы HTTP вы знаете? Какие функции они выполняют? Расскажите про структуру HTTP-сообщений. (Если вы перечислите основные методы и скажете, что у сообщения есть заголовок, строка и тело - это уже, в целом, неплохо. Если знаете больше этого, вообще замечательно).

   3. Что такое REST? Какие основные принципы у него есть? Какие методы есть в REST? В чем разница между GET и POST запросом?

   4. В каких местах (четырех) мы можем передать атрибуты в запросе? (Path, Body, Query, Header).

   5. Что вы знаете про концепцию CRUD?

   6. Что такое идемпотентность? Какие методы являются идемпотентными?

   7. Что такое синхронные и асинхронные интеграции? В чем между ними разницы? С помощью чего можно их реализовать?

   8. Можно ли реализовать асинхронную интеграцию через REST? (Вряд ли этот вопрос будут задавать, если вы не ответите на предыдущие. Это скорее со звездочкой и не обязательный)

   9. Что такое очередь сообщений? Как передаются сообщения через очередь? Какие очереди сообщений есть и в чем между ними разница? (Если расскажете про PUSH/PULL-стратегии - плюсик в карму обеспечен)

   10. Что такое гарантированная доставка сообщений и какими механизмами ее можно обеспечить?

   11. Какие вообще способы интеграции существуют? С какими из них приходилось работать? В чем их преимущества и недостатки? (Интеграция через обмен файлами, через общую БД, через веб-сервисы и обмен сообщениями)

2. Базы данных:

   1. Что такое базы данных? Какими они бывают? С каким БД приходилось работать?

   2. Что такое ER-диаграммы? Приходилось ли их проектировать?

   3. На какой уровень оцениваете свой уровень владения SQL? С какими инструментами по работе с БД знакомы?

   4. Ну тут могут конечно и про формы нормализации спросить, но уже лишнее, как по мне. Я обычно спрашиваю больше про опыт проектирования БД в целом. Приходилось ли проектировать базу в целом и под конкретные задачи в частности, каким образом это было сделано.

3. Различные задачки:

   1. Тут вообще кто во что горазд в плане придумывания задач. В среднем, вам дадут умозрительное задание на проектирование какой-либо системы и попросят выделить основные классы этой системы (возможно, предварительно нужно будет собрать требования с интервьюера), спроектировать интеграцию между частями этой системы/интеграцию с внешними системами (плюс объяснить выбор технологии интеграции). Основной упор на ваши размышления, в основном именно в подобных вопросах можно понять уровень соискателя, потому что все остальные можно заучить. А тут проверяется именно понимание того, о чем вы рассказывали предыдущую часть собеседования.

4. Небольшие оффтопные вопросы:

   1. Расскажите, что такое авторизация, аутентификация и идентификация? Чем они отличаются друг от друга? (почему-то один из самых любимых вопросов некоторых людей)

   2. Чем верификация отличается от валидации?

   3. Приходилось ли работать с JIRA\Confluence?

Конечно, так получается, что если вы знаете ответы на все эти вопросы, или больше 80-90%, то как будто бы вы уже не джун. Но чем лучше вы отвечаете, чем лучше вы соответственно подготовились - тем больше вам зададут вопросов (в нормальном интервью, а не шаблонном). Что очень сильно повысит ваши шансы получить оффер и выделиться среди других кандидатов.

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть огромное количество постов на тему софт-,хард-скиллов и про карьеру в целом - см. закрепленный дайджест.

❕Сегодня хочу поговорить на очень спорную тему, я бы даже сказал философскую. Отчасти из-за нее, возникает очень много непонимания между коллегами, работающими в одном и том же (казалось бы) "АйТи", но почему-то имеющих очень разное представление о процессах разработки и о том, что каждая роль команды должна выполнять. Особенно это часто всплывает в моих постах на этом ресурсе, в комментариях - это такой хороший срез из разных уголков нашего отечественного IT.

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

Давайте поговорим о том, какие есть подходы к написанию ТЗ и степени его проработки на примере описания тех же микросервисов\их методов.

❕Представим, что мы является системным аналитиком в команде и нам поставили задачу - реализовать личный кабинет пользователя.

Т.е. когда пользователь нажимает на какую-нибудь иконку профиля в приложении или там на кнопку "Профиль" - ему должна открываться экранная форма, в которой ему отрисовывается определенный набор полей и эти поля заполняются информацией. Также допустим, что у нас сам объект "Пользователь" уже есть в системе, атрибутивный состав понятен и нужно только реализовать процесс получения данных о пользователе на фронт по его идентификатору (ТЗ на фронт, на экранную форму и на интеграцию его с бэком опустим).

Какие есть варианты написания ТЗ для данной задачи?

1️⃣Самый минимальный уровень детализации. Это когда системный аналитик просто ставит задачу на разработку Джире (ну или в рамках небольшой страничке в конфлю\ворде, в зависимости от того, как принято) и в постановке этой задачи пишет что-то вроде "Требуется реализовать процесс получения данных о пользователе и передачу ее с бэка на фронт по REST-запросу. Со стороны фронта требуется создать новую экранную форму приложения - "Личный кабинет" или "Профиль пользователя". Со стороны бэка требуется реализовать новый метод, который будет использовать фронт для запроса информацию по пользователю (и, скорее всего, перечисляет набор полей, которые должны передаваться на фронт в формате "Фамилия", "Имя" и т.д.)". Усё

Я не утрирую - это один из вариантов реального "ТЗ" на эту задачу. Плюсом к этому может быть описан пользовательский сценарий в вольном формате или в формате UC (и то это будет в лучшем случае). Т.е. по сути в рамках такого процесса разработчик получает из полезной информации - только состав полей, передачу которых ему нужно реализовать по запросу с фронта, и то только их наименования.

2️⃣Вариант с немного лучшей детализацией. В этом формате системный аналитик уже пишет ТЗ в каком-либо формате, в рамках которого указывает, что: "Требуется реализовать новый метод GET /users/, указывает полноценно параметры, которые данный метод должен потреблять на вход и параметры, которые он должен отдавать на выходе." Плюс может описать, также как в предыдущем пункте, верхнеуровневый сценарий взаимодействия с этим методом.

Уже чуть лучше и чуть больше полезной информации для разработчика, правда?

3️⃣Вариант с достойной реализацией. Этот вариант обычно используется на большинстве проектов ФинТеховских и я считаю его достаточным для того, чтобы написать хорошее, качественное ТЗ и разгрузить разработчика так, чтобы он не думал о деталях реализации, хотя бы алгоритмических и системных (то, к чему нужно стремиться со стороны СА, имхо).

В рамках этого варианта будет всё из предыдущих + будет полностью описана логика работы данного метода, как бизнесовая, так и техническая. Будут описаны все корнер-кейсы, правила обработки ошибок, варианты того, что может вернуться в ответе (кроме успешного ответа, еще и все варианты негативных). Логика может быть описана или на уровне псевдокода или просто словами - конкретно это уже не имеет значимой роли, главное то - что эта логика пошагово и подробно описана.

Пример подобного описания я приводил ранее в своих постах. Я топлю всегда как минимум за этот вариант описания любых задач - что бэковых, что фронтовых, любых. Избавить разработчиков от лишней работы с точки зрения проработки алгоритмов и логики, если мы вполне это можем сделать сами - у них хватает работы и так, можете поверить.

4️⃣Более полноценный вариант придумать не могу =)

Плюсом к 3 пункту дополнительно описывается еще и swagger-спецификация микросервиса в целом и конкретных эндпоинтов в частности. Кроме того, что это просто удобно, наглядно и очень детально - эту спецификацию разработчики могут использовать, чтобы сконвертировать ее напрямую в готовый код с расписанными классами и эндпоинтами, останется "только" докрутить бизнес-логику и метод готов (Тут просьба поправить меня коллегам, которые более глубоко погружены в разработку - так ли это или есть еще какие-то бенефиты для разработчиков. Могу в этом предложении быть не прав, пишу исходя из того, как мне это объясняли).

Кроме этого, такой подход хорошо использовать в парадигме swagger-first, особенно когда у вас есть насыщенный и активный процесс кросс-командной разработки. Отдать другой команде сваггер аналитику куда проще и быстрее, чем отдать полноценное ТЗ на сервис - хотя бы просто по времени. А большего им и не нужно (потому что им пофиг на то, как работает ваш сервис внутри, главное понять, как вас вызывать и что вы вернете в ответе).

А если это все еще и использовать в связке с asciidoc-документацией, выкладывании ее в git- ммм, сказка просто. Как вспоминаю об этих процессах, наворачивается скупая слеза ностальгии - как же это было здорово! Жаль, что я встретил это ровно в одном проекте, а во всех последующих так и не смог продавить внедрение чего-то похожего.

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

А с какими процессами и подходами работаете вы?

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть огромное количество постов на тему софт-, хард-скиллов и про карьеру в целом - см. закрепленный дайджест.

Недавно завирусилась история о том, как кандидат вписал себе в резюме фиктивных два года опыта и прошел интервью на позицию в ИТ-компанию. Правда потом об этом узнали, и его вроде как уволили. Я не придал этому значения, пока мне не рассказали, что в одной онлайн-школе этому прям учат студентов, такая вот "гарантия трудоустройства". А на днях в одном из hr-чатов выложили фейковое резюме тестировщицы с 2 годами опыта, которая не смогла ответить ни на один технический вопрос.

В общем, весь этот треш оказался ближе, чем кажется. Не буду рассказывать, что обманывать нехорошо. Но я обратился за рекомендациями  к Оле - HR в ИТ, карьерному консультанту и автору канала про карьеру, с которой мы трудоустроили уже ни один поток моих учеников.

Далее от ее лица.

Итак, последствия таких обманов могут быть разными:

(1) резюме могут закинуть по разным чатам и потом, чтобы найти работу, придется менять еще и фамилию (внутри одной сферы обычно тесно общаются и репутация дорога)

(2) в крупных компаниях есть службы безопасности, которые проверяют биографию еще до трудоустройства.

(у меня, кстати, был случай, когда клиентке отказали на последнем этапе из-за того, что данные из анкеты не совпали с реальностью)

(3) даже если все получилось, но в процессе работы информация вскрылась, могут и скорее всего уволят.

!(4) и что-то новенькое: hh.ru, на котором размещаются резюме, начал проверять точность информации и связываться с работодателями.

Поэтому поговорим о том, как можно привлечь внимание к себе, чтобы потом не уволили, как в этом случае:

(1) Начинать искать как можно раньше (когда изучена уже какая-то база), потому что то, что дают на курсах не всегда равно требованиям компаний. Чем больше смотрите вакансии и общаетесь, тем лучше понимаете, что нужно рынку.

(2) Использовать нетворкинг - знакомиться с людьми, которые работают в тех компаниях, куда вы хотите. Даже просто написать и попросить зарефералить. Теория с рукопожатиями тоже работает (у меня так много клиентов и знакомых нашли работу)

*кстати, консультант тут тоже обычно помогает и закидывает резюме по своим каналам (это, конечно, не гарантия успеха, но повышает конверсию)

(3) Резюме должно быть продумано до мелочей, из самого базового:

➡️ название должности должно соответствовать названиям вакансий, т.е не "специалист", а максимально конкретно;

➡️на первом месте должен быть опыт по той вакансии, на которую вы хотите, даже если это учебный опыт;

➡️ расписать подробно навыки, которые вы получили на обучении, лучше сразу с примерами из практики.

(4) Брать из предыдущего опыта все навыки, которые могут быть полезны. Смена направления — это не начинать с нуля, всегда есть переносимые навыки. Например, опыт ведения коммуникации и работа в команде, который есть у всех, и другие soft skills. Успех поиска 50/50 зависит от hard и soft skills.

(5) Использовать сопроводительные письма и писать вдумчивые отклики на позиции (спам-рассылка скорее всего не даст результата). А вот резюме + нормальное сопроводительное можно отправлять не только на hh, но и напрямую в компании, даже если вакансии нет, вас могут добавить в базу и написать позже.

*я всегда читаю, когда вижу, что человек постарался, а иногда даже даю обратную связь и помогаю скорректировать.

(6) Использовать разные источники поиска, в том числе рассматривать стажировки, после которых можно трудоустроиться (иногда это быстрее, чем искать вакансии).

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

Приветствую, дорогие Пикабушники! Придумал сам, но на оригинальность идеи не претендую. Случилось так, что вчера, придя домой после работы с практически полностью разряженным телефоном я понял, что электричества дома нет. Повербанк тоже разрядился, в самое время когда он нужен. Перспектива сидеть неизвестно сколько без компа и без телефона удручала и тут взгляд мой наткнулся на планшет, вот только симки там нет, а следовательно и интернета. Симка с телефона другого формата и не подходит для планшета по размеру. Но вот рядышком с ним лежал OTG переходник и тут меня осенило!

OTG переходник превращает кабель из USB-A  в micro-USB, а следовательно, я могу подключить разряженный телефон как флешку к заряженному планшету и питание телефон будет получать от планшета, то есть будет заряжаться!

Подопытный huawei жены, так как на свой телефон фотографировал.

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

Коллега на работе сваял из подручного материала.

А если песику нажать на нос

то он делвет так:

Коллега откопал в огороде рогатину времен Ивана Грозного.

На работе почистил и покрасил.

Фото мои, поэтому тег "мое"

О, воспоминания о ненавистной "художке"...

Упоёролась мать, что раз ей родители запретили идти в художественный техникум, то надо обязательно научить художествам меня. Ещё масла в огонь подлила ИЗОшница из школы, которая про всех детей могла часами говорить какие они талантливые, просто забивая на реальность (я до сих пор уверен, что она дула между уроками - уж очень укуренной была всё время, плюс вся такая хиппарка седая). Пофиг, что не то что таланта, склонности даже не было и близко, в приказном порядке был отбуксирован в 4 классе туда, на 4 же года каторги по 5 дней в неделю (в первый класс художки брали с 3 по 6 классы школоло). И повезло мне оказаться в классе, где преподавала мразь, каких ещё поискать...

1) Она не учила нас. Вообще. Просто ставила натюрморт, и такая "рисуйте". У кого-то в классе старший брат учился там же у другого препода, и этот парнишка нам и говорил, что вот надо эскиз сперва, карандашом, потом гуашью, и так далее. То же самое с рисунком, композицией (было 5 предметов в художке - "натюрморт" рисовать в краске что-то, "рисунок" то же самое только карандашом, "композиция" рисовать не с натуры, а по заданной теме из головы, лепка и история).

Лепка, которую вели сразу у нескольких классов по субботам, и вели наотыбись - из 3х часов занятия (да-да, вы представляете 3 часа непрерывного урока у четвероклассников?) преподша могла на 2 часа просто свалить по делам. Я в итоге половину занятий сидел в раздевалке с ещё парой мелких, потому что старшие (а там были в основном 9ти- и 10тиклассники) давали нам пизды просто так. Заставлять жрать глину для лепки, пока не начнёт тошнить - одна из их любимых забав. Жалобы? "Они таланты, а вы бездари, придумываете всякую хрень про действительно стоящих людей, вы просто мусор!!!". Потом стал тупо прогуливать.

2) Старая сука преподша умела кое-как в акварель, считалась художником, муж её был кем-то в районном образовании и пристроил её учить детей. Он же делал ей персональные выставки на любой чих, на которых народ был только на открытии (кого согнали по работе).

И поэтому она всегда уничижительно отзывалась о гуаши, которой предписывалось рисовать на 1-3 классах художки (до туши/акварели/масла/акрила учеников допускали только в 4 классе обучения - типо гуашь хоть жри, она не токсичная, а остальное всё вредное).

И все 3 года она чмырила нас, что мы настолько тупые, что с нормальными материалами работать нам рано, только переводить будем. О какой самооценке, обучении и самосовершенствовании может идти речь в таком случае?

3) Этот блядина заставляла нас делать наброски один день в неделю. Потому что так написано в учебном плане у других преподов. То есть по очереди все в классе вставали в центр, позу принял, тебя 10 минут быстро рисуют кто что успел, потом следующий. В классе 30 человек было поначалу, это реально занимало время с начала занятий до закрытия художки вечером. А так как ей было скучно сидеть с нами, она уходила куда-нибудь - на улицу книжку читать, домой дела делать. Могла от скуки взять и ёбнуть стоящего по спине, или дунуть в ухо из горна (мне так попало, я этим ухом не слышал потом пару дней).

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

4) Летом нам надо было отбыть месяц "пленееров". Когда выезжали с преподом на природу и типо рисовали. Стоит ли говорить, что там было то же самое? Она загорала, мы делали вид, что рисуем. Кто постарше, просто бухал в тихую.

5) Год заканчивался "просмотром". Когда все работы каждого ученика выкладывались, комиссия из директора, завуча, преподши класса, и преподши истории (да-да, будет позже, у нас была история отдельно в художке О_о). Среди кучи накаляканного нами говна выбиралось пара любимчиков, которых будут облизывать весь год (впаривая кучу занятий дополнительно, пророча поступление в художественный вуз итд), и несколько тех, кого будут чмырить активнее остальных. Уже потом, через десяток лет, я узнал, что в любимчиках были те, у кого богатые родители, а гнобили только детей из бедных семей, даже если они объективно хорошо рисовали.

6) На 4й год обучения эта пизда слегла в больницу на операцию... И наш класс тупо расформировали. "Ничо не знаем, преподавать некому, у других всё занято, нам похуй что с вашими дитятами дальше будет, нам похуй что вы оплатили обучение". Моя мать была в ахуе. Я хз как, но она умудрилась пропихнуть меня к другому преподу, она так и не рассказала, но по намёкам я понял, что за немалую взятку директору. И вот тогда я понял, что такое "обучение в художке". Это был мировой мужик. Он умудрился расположить к себе с первого дня. Он (о чудо!!!) обучал!!!!!!! Как рисовать, с чего начинать, про перспективу (не только что это ,а как использовать, как влияет на цвета итд), про взаимосвязь цветов, цветовой круг, отражения и рефлексы, принципы набросков и зачем они вообще нужны для художника (да, у него мы наброски делали только дома, 10 штук в неделю всего!), как собирать сцену для придуманного рисунка и многое другое... Чёрт, если бы учился у него все эти годы, то быть может, был бы сейчас именно художником. Я у него научился рисовать за полгода лучше, чем за 3 года у старой суки до этого!

Но увы, этого было не просто "недостаточно", этого было ничтожно мало. Потому что те, кто с ним занимался 4й год, могли уже сдавать практические экзамены в топовые вузы художников на высший бал. И меня мягко попросили не особо отнимать время преподавателя - мне всё равно ничего не светит на этом попроще, а им через год поступать надо было уже, а там конкурс 50 человек на место считался "чот мало в этом году". И как бы не было обидно, пришлось согласиться, так как самому надо было начинать готовиться к вузу (а я тогда точно определился, что пойду "программистом").

И при всём при этом не было никакого "чмырения" в новом классе, я за этот год сдружился с ними так, что со многими до сих пор общаюсь.

7) Да, напоследок - уроки истории. Точнее, "истории древнего мира", "истории возрождения", "общей истории искусств". Аж 3 предмета, в разные годы. 3 блядских предмета, заключавшихся в показе нам слайдов с картинами великих художников/архитекторов/скульпторов, краткой справке о их жизни, и ТУПО ЗАУЧИВАНИИ НАЗВАНИЯ КАРТИН. По этому недоразумению был даже экзамен... который заключался в тупо произнести названия 10 показанных картин. Всё. Эта параша тратила по 40 минут нашего времени раз в неделю все 4 года. Зачем - до сих пор не понятно. Может, так "сверху" сказали, а может, надо было пристроить кого-то из "своих" (как в бухгалтерии этого прекрасного учреждения было 5 человек бухгалтерш на окладе, например...)

Стоит ли говорить, что рисовать я так нормально и не научился, зато получил прекрасную прививку против этого дела, чуть-чуть смягчённую настоящим Художником и Учителем?..

Я к нему заходил потом, через несколько лет. Он сильно поседел и сдал, ему было лет 70 тогда. Не ожидал, но он вспомнил меня, и пару моих работ, которые ему понравились. Невероятно. Очень жаль, но этого прекрасного человека не стало в 2020 году, ковид.

Прошло 17 лет, как закончил там учиться, но до сих пор вспоминаю те дни то с ненавистью к рисовке, то с нежностью к последнему году...

П.С. Вроде выговорился, стало полегче. Надеюсь, никто не узнает себя в этом описании.

Был недавно на полуострове Рыбачий. Немного дико для жителя средней полосы видеть как тут растут грибы. Несколько грибов даже запечатлел на память.

10 августа 2023г.

Хорошего дня вам, уважаемые господа и дамы!

Сегодня я хочу вам рассказать про знакомца своего, сержанта Петрова.

Служит он пожарным в самой главной части не самого главного на Руси города.

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

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

Оторвав бренное своё тело от жены ненаглядной и ребятёнка любимого, не спав после суточного дежурства помчался он в на склад вещевой, дабы форму получить и хоть как-то постараться на службе среди товарищей выглядеть подобающе.

Прилетел как назначено было, к двум. А они чай пьют, кладовщики эти, попы свои плющат на стульях любимых. Более двух часов он ждал когда же они уж допьют этот чай окаянный. И ведь отойти нельзя ни в туалет ни покурить. Забудут о нём горемычном сразу и на учет какой-нибудь закроются. Недели на три. Проходили уже, знаем. Да и обидно и неловко бедному Пертрову за то, что не один он в коридоре томится, а рядом с ним сержантом два лейтенанта стоят да майор, ещё капитан был, да он психанул и ущёл. В служебное время, на трамваях, оплаченое время тратя, целые офицеры стоят и ждут попу, которая чай пьёт. Но это начало истории, которую поведал мне грустный сержант Петров за рюмочкой чая у меня на кухне.

Начали выдавать, возликовали господа офицеры, лейтенанты даже в эйфории первыми полезли в зласчастный кабинет в ведомостях расписываться. Вывели всех из здания, повели на какой-то другой склад где стали выдавать летнюю форму одежды. За месяц до зимы... далеко не в полном объеме... Назвал Петров свой рост да размер в обхвате и дали ему форму ненужную с циферками подходящими. Померил. Велика на два размера. Попросил. Послали, сказали больше есть, на бегемота средней упитанности, а вот меньше уж увольте. В комсомолке пишут, что вы едите очень хорошо, так что мы только на бегемотов форму и заказываем. Ботинки правда дали, но ни берцев ни сапогов нет уж давно, выдали всё. Босиком будешь ты пожары тушить. Возник у сержанта вопрос, за каким мужским и половым они списки с размерами да количеством людей собирают коли формы покупают меньше да и размера не того, да обхамили его в ответ.

Бушлат, фурнитура, свитер, в конце концов. Обувь погоны, лычки, шевроны, носки да и трусы. Нательник, сухпаёк, брюки, китель, рубашки, петлицы, кокарды, шапки. Воровать их чтоли? Ибо нету этих денег, ребёнка только что в школу собрал, ненаглядную одел чтоб осенью не мёрзла и не болела, с ребятёнком занималась.

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

С дежурства домой Петров пришёл усталый, два повышенных номера не шутки, часть-то боевая. Да и настроения как-то нет, осень, промозглый ветер, листочки там опадают... Встретила его жена с глазами красными и сказала, не волнуйся ты уж так, муж мой любимый, купи мне иголочек да перешью я тебе эту форму, хоть и сделана она отвратительно но я смогу привести её в человеческий вид. И будешь ты не хуже, а даже лучше многих. Вот она поддержка, любовь и понимание. Забота и единство.

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

(С)Эмиль Маратович. AKA Amil

Специально искал свечки и покупал торт, чтобы отметить аптайм ).

Приветствую вас, уважаемые Пикабушники!

Заметил интересную тенденцию. Обычно мошенники из "службы безопасности всех банков" звонят не так чтобы уж очень часто, один два раза в неделю. Но! Сегодня пришла зарплата на карту уважаемого мной банка ВТБ. И понеслось. Звонки от разводил полились рекой. Причём они представляются именно сотрудниками банка ВТБ, хотя у меня карты есть и других банков, но деньги то упали на эту. Конечно я воспитанный мальчик и потому отвечаю каждому, каждому желаю гореть в аду, а они обижаются и трубку бросают.

В связи с вышеизложенным возникает вопрос, даже не знаю кому задать, попробую вот так: @vtb24, @VTBbank, разъясните, пожалуйста, как это так, что мошенники активизировались сразу же как деньги на карту поступили?

Не знаю почему скрин такой огромный получился. Простите криворукого.

И ещё вот, на тему не очень сообразительных людей, вот что, правда люди верят, что им звонят с каких-то сотовых номеров через вайбер именно сотрудники ВТБ?