Всем привет, мы – Таня и Лиза, системные аналитики в МТС. В этой статье мы поделимся опытом внедрения структурированного шаблона функциональных требований (ФТ) к разработке ПО в нашей команде.

Статья будет полезна тем, кто работает с фронтовым функционалом – системными и бизнес-аналитикам. Неважно, Junior вы или Lead, в большой работаете компании или в стартапе, – наш рассказ вас наверняка заинтересует. Поговорим не только о том, как мы докатились до такой жизни, приняли единый формат ФТ, но и том, какие именно артефакты аналитик готовит в ходе своей работы. А еще мы подробно расскажем про причины поиска подходящего формата, сложности перехода и составляющие наших ФТ. 

Добро пожаловать под кат!

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

Данную статью я написал после того, как сделал собственную библиотеку, генерирующую сообщения протокола Kerberos, а также после того, как я протестировал «стандартный клиент» Kerberos в Windows — набор функций SSPI. Я научился тестировать произвольные конфигурации сервисов при всех возможных видах делегирования. Я нашёл способ, как выполнять пре‑аутентификацию в Windows как с применением имени пользователя и пароля, так и с помощью PKINIT. Я также сделал библиотеку, которая умещает «стандартный» код для запроса к SSPI в 3–5 строк вместо, скажем, 50-ти.

Хотя в названии статьи фигурирует «простыми словами» однако эта статья предполагает, что читатель уже имеет какое‑то представление о Kerberos.

Архитектура предприятия предназначена для самого предприятия, а не для архитекторов.

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

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

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

Этой статьёй я открою серию материалов про управление требованиями на разных этапах проекта.  Уже больше 10 лет я работаю в IT и успела побывать бизнес аналитиком, системным аналитиком и руководителем проектов. Также я выступаю в роли ревьюера на курсе «Системный аналитик». 

Начинающим аналитикам бывает не просто разобраться в разных подходах к документированию  требований и множестве нотаций моделирования. У кого-то даже проскальзывают сомнения, а нужно ли все это знать или можно просто изучить формат описания user story? Я попробую развеять эти сомнения на примере учебного проекта.

В этой статье я дам краткую вводную, что такое Archi и ArchiMate. Расскажу о коллективной работе с Archi используя расширение coArchi, после чего предоставлю контейнер позволяющий автоматизировать работу по созданию HTML и PDF документов с ArchiMate моделями. Завершим же, созданием своего GitHub Action, настроим GitHub и GitLab пайплайн с последующей публикацией модели в GitHub/GitLab Pages.

Введение

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

Введение

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

У меня многолетний опыт удаленной работы из разных локаций мира от привычных фрилансерских островов Юго-Восточной Азии до мировых столиц вроде Лондона. В этой заметке я хочу рассказать о своих наблюдениях. И показать, насколько сильно локация влияет на возможности в go global!

1️⃣ У всех людей, включая потенциальных работодателей, клиентов или кастомеров, есть "географические" стереотипы и предрассудки. Прежде всего о стоимости услуг или зарплате. 

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

Более того, люди могут делать выводы и о квалификации специалиста: очевидно, что среднестатистический продакт из СФ скорее всего квалифицированнее севильского. Поэтому локация может быть в неотором смысле маркером экспертности, что безусловно влияет на глобальную востребованность.

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

2️⃣ Или например на второй год странствий немало талантливых дизайн-агентств мск/спб планирует переезд в Барселону. Про быт нет вопросов: считаю этот город лучшим в мире для жизни. 

Но делать свое агентство барселонским - это значит:

а/ Задать невысокие ожидания по чеку: для американского бизнеса что Барселона, что Верона, что Лиссабона - примерно одно и то же. Читай: "в Европе закажем подешевле". А чеки побольше будут уходить тем, кто переехал в Лондон, Нью-Йорк, Долину или хотя бы в Дублин.

Друзья, всем привет! Так как я новенький тут, в первых нескольких постах буду представляться. А вообще вот ссылка на мою первую статью тут, про мои инсайты от перехода от корпоративной карьеры к стартаперству.

Меня зовут Денис. Я долгое время работал в разных больших компаниях. Продавал рекламу в Google. Строил e-commerce Mars. Развивал Додо Пиццу в России и на других рынках. Большую часть этого пути у меня все получилась. Карьера перла. Были результаты. В итоге мне начало казаться, что я очень умный и талантливый.

В 2022 году я ушел из Додо и начал делать свой стартап Getplace. Получаться стало намного хуже. Все новое, сложное. Ресурсов нет. Большой компании за спиной нет. Начальника за спиной нет. При этом у всех все получается. Стартапы прут. Раунды поднимаются. И вот начинаешь думать: почему все такие умные? Что со мной не так? 

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

Надеюсь, будет интересно. Весь свой путь и переживания описываю в своем телеграмм-канале.

Итак, как мы получили инвестиции от крупного европейского вечурного фонда в 2022 году?

Все получилось случайно. Опыта привлечения инвестиций у меня не было. В Додо я этой темы не касался. Стартапы сам не делал. Я, конечно, что-то слышал, читал, знал истории знакомых - но все это проходило по касательной.

Парадоксально, что у меня брат - стартапер со стажем, со-основатель appfollow. Он занимался в проекте фандрайзингом, привлекал несколько раундов инвестиций. Но пока я сам этим не занялся, его опыт звучал для меня как абракадабра. Как будто он пальцами щелкнул, и деньги сами появились. Да что там сложного, думал я? Пошел, написал, взял деньги. Их же, наверное, направо и налево раздают?

В обновлении Bot API 6.0 телеграм-боты получили много новых функций. Из них для разработчиков самая примечательная - Telegram Web Apps (Веб-приложения внутри телеграм). С этим нововведением разработчики могут подключать к своим ботам web-приложения, которые открываются в дополнительном окне, что сильно расширяет инструментарий, а, следовательно и функционал ботов в телеграм.

Анна Вичугова, CBAP, написала стартовое пособие по тому, как начать моделировать бизнес-процессы в BPMN

1. Назначение BPMN.

2. Уровни моделирования.

3. Алфавит нотации: События, Логические операторы, Артефакты.

4. Правила построения диаграмм.

5. Пример построения диаграммы по тексту.

6. Рекомендуемые инструменты.

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

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

В самом начале моей карьеры мы собеседовали тимлида Г. На собеседовании Г. был хорош, уверен в себе и показал отличные технические знания, и мы его взяли. Но буквально через пару недель человек начал вести себя не очень корректно с моей точки зрения. Я решил посоветоваться со своим непосредственным руководителем:

— Как-то мне не очень комфортно и приятно будет работать с человеком, который такое вот делает. Наверное, надо нам с ним расстаться.

На что мой руководитель резонно мне ответил:

— ${zloy_stas}, таких, как этот Г., в твоей работе будет много; если ты будешь увольнять каждого, кто тебе не понравился лично, ты быстро перестанешь быть руководителем. Твоя задача — не детей с ними крестить, а извлекать из них пользу и уметь с ними работать. Пусть этот Г. будет для тебя таким менеджерским челленджем.

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

Поговорим сегодня о поведении, а точнее о тех психологических проблемах, с которыми мне приходилось сталкиваться на практике. Это будет разговор про ситуации и проблемы, которые не всегда фатальны; про людей, которые ещё могут быть полезны. При этом мы все знаем, что делать с совсем неподходящими людьми ;)

Тараканы Корпоративные (токсичность:☣☣☣)

Казалось бы истина в заголовке, но я слишком часто встречал менеджеров(Project Manager/Product Owner) которые хотели схитрить и обойти это правило. Они приходят к команде разработки и говорят каждый на свой лад:

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