Привет Хабр! Мы в SSP SOFT разрабатываем заказное ПО для ведущих российских банков и финтех-проектов. Системный аналитик (СА) — одна из ключевых фигур в проектных командах, и такие вакансии с грейдами сеньор, мидл и джун регулярно появляются в компании. Для технического интервью мы привлекаем внешних экспертов с компетенциями, которые максимально близки к предметной области проекта. Эта статья — наша версия на тему проверки опыта и навыков СА на собеседовании. Читайте и комментируйте ✍️.

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

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

В работе solution архитектора или системного аналитика есть задачи на проектирование интеграции. Иногда заказчик приносит задачу с требованиями на один абзац.

С чего же начать, если перед вами такие минимальные бизнес требования?

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

А теперь представьте, что вы создаёте цифровой продукт в роли PO, CPO или CTO. Тогда вы столкнетесь не только с несогласованным дизайном, но также с неуправляемым бэклогом (план против реальности), задержками выпуска версий и постоянными переделками функционала после выхода в продакшн.

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

• Почему менеджеров проектов надо пересаживать в отдельное здание
• Что делать, когда ваш заказчик не пользуется вашей системой отчетов
• Как раскачать low-performer’а

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

Привет, друзья! Знаете ли вы, что за большинством привычных вам услуг стоит ИИ? Он уже везде, не побоюсь этого слова, даже в образовательных продуктах, включая разнообразные курсы. 

Наша команда в ЛАНИТ последнее время работает над продуктами, которые используют такое чудо техники, как нейросети, в частности GPT. В процессе нашей работы мы столкнулись с кучей интересных сервисов, которые используют ИИ и могут быть полезны для решения задач в учебе. И я с удовольствием поделюсь самыми крутыми из них. Так что сделайте себе чашечку кофе и удобно устройтесь, впереди десять минут полезностей. Начинаем!

Меня зовут Саша Шульгин, я руковожу агентством Purrweb. За последние пару лет наша команда сделала 5 проектов с арабским интерфейсом. Это, конечно, не 50, но какой-то опыт уже есть. Пока делали проекты, собрали базу знаний. Я решил, что такое нельзя держать только у нас в Notion, поэтому делюсь с вами, как адаптировать приложения для Ближнего Востока.

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

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

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

Привет! Меня зовут Женя Голева, я занимаюсь developer relations с 2016 года, и постоянно вижу профессиональных чатах холивары о нашей работе. Люди спорят, кто такие деврелы, кто занимается не деврелом, а какие виды деврелов наоборот имеют право на существование и очень нужны в команде. 

Ответы на многие похожие вопросы уже есть — в книге Мэри Тенгвал “The Business Value of Developer Relations”.  Я заручилась поддержкой автора и издательства-правообладателя и перевела главу “Building a Developer Relations Team / What’s in a name?” для русскоязычного сообщества. У вас впереди 10 коротких и ёмких разделов про цели и задачи всей команды Developer Relations на старте и в процессе развития, про то, какие роли и специализации могут быть востребованы на разных этапах, что кандидатам необходимо знать и уметь на входе, а что — вовсе не обязательно и можно добрать в процессе работы.

Эта статья будет полезна в первую очередь тем, кто хочет разобраться в специфике направления developer relations: если вы СТО или СЕО, то вам скорее будут полезны первые несколько разделов и последний, если вы уже занимаетесь деврелом или очень хотите начать, здесь будут ответы на вопросы, как войти в профессию или куда в ней развиваться дальше.

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

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

Статья о том как установить себе "macOS Monterey" в виртуальной машине на обычном PC без покупки для этой цели макбука или айМака.

По идее это просто туториал как получить у себя на обычном PC систему macOS и Xcode, но так как я тут нахожусь в состоянии "Отхабренный" я могу отправлять статьи только в "Профильные хабы". По этой статье больше бы подошло "Tutorial", но такого хаба я не нашёл и поэтому выбрал наиболее близкие хабы по теме статьи: "Настройка Linux" и "Разработка под iOS". И КДПВ тоже я выбрал идиотскую -- просто сделал скриншот со своего компа где продемонстировал версию macOS и версию установленного у меня Xcode.

Всем привет! Меня зовут Анна Мозер, я работаю тимлидом системных аналитиков в X5 Tech. Мне удалось поработать и в корпорации, и в стартапе, и в качестве фриланс Delivery Manager на этапе запуска стартап команды. 

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

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

Хотя многие менеджеры объясняют это стремлением к гибкости и следованием Agile-философии, чаще всего такие признаки указывают на неправильное понимание и применение гибких методологий. Цель моей статьи – подсветить типичные ошибки менеджмента команды и рассказать об индикаторах того самого "недопонятого" Agile (я насчитала таких 10 штук). 

Привет, меня зовут Лера Коряковцева. Я — Customer Journey Owner, больше 10 лет занимаюсь product management, сейчас создаю и развиваю продукты для юридических лиц  в Альфа-Банке.

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

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

Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.

Обычное дело: в команду приходит заказчик, приносит суперзадачу — киллер-фичу, которая по приблизительным оценкам будет приносить не меньше N денег в секунду. Очень важная и нужная штука. Потом проходит 3 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала. 

Почему? 

– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;

– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;

– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;

– задача потерялась в недрах бэклога — продакт проглядел.

Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.

Привет! Я Юля, менеджер продукта в Тинькофф Кассе. Мы делаем интернет-эквайринг для бизнеса, и в разработке продукта участвуют 30 команд. При создании новой фичи какие-то команды могут действовать обособленно, но это редкость. В большинстве случаев командам при разработке нужна помощь друг друга. Расскажу, как у нас получилось сделать так, чтобы не было очередей из команд.

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

В этом проекты мы попытались запараллелить все, что можно, чтобы сократить срок разработки и максимально быстро получить первый трафик из органики.

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