Пользователь
Архитектор из крупного российского банка, предлагает простое представление, что делает архитектор решений, какими навыками он должен обладать, и как обычно устроен его день.
Кому-то статья поможет развеять основные заблуждения о профессии, кому-то составить карту развития в специальности, а кому-то наконец принять решение, хочет ли он/она быть архитектором решений.
Привет! Меня зовут Яков, я системный аналитик в Friflex, я работаю над созданием наших высоконагруженных заказных проектов. А еще активно участвую в онбординге джунов и менторю стажеров.
Профессий со словом «аналитик» много: системный аналитик, бизнес-аналитик, продуктовый аналитик, аналитик данных, аналитик в IT. В этой статье разберемся в видах аналитиков, узнаем, какие требования предъявляются к джунам при устройстве на работу и о том, где эту работу найти.
Всем привет, меня зовут Алексей - я руководитель отдела интеграции EvaTeam. Это статья о том, как реализована настройка автоматизаций в EvaProject - российском аналоге Jira. В ней рассказывается о том, с чем пришлось столкнуться при переезде с Jira, и как мы реализовали функционал в нашей системе.
В 2001 году Джордж Акерлоф получил Нобелевскую премию по экономике за анализ рынков с несимметричной информацией. Его научная работа с запоминающимся названием «Рынок „лимонов“» доказывает, что если покупатели не владеют информацией о качестве товара в той же мере, что и продавцы, то плохие товары вытесняют хорошие вплоть до полного исчезновения рынка.
Бум коммерческого Edtech в России подходит к концу. Он дал положительные результаты — он дал возможность многим начать профессию в тестировании. Но дал и отрицательные.
Во‑первых, он утвердил в головах, что тестирование — это настолько легко, что «каждый может стать».
Во‑вторых, превратил образовательный рынок в рынок «лимонов». Не разбирающиеся в смысле будущей профессии студенты выбирали курсы, где «побольше тулов» и где пожирнее скидки. Теперь от результатов работы этих «лимонов» морщатся HR, пытаясь сделать так, чтобы позже не морщилась команда.
Если с репутацией тестирования уже решительно ничего не сделать, то в плане подхода к IT‑образованию вообще и QA‑образованию в частности можно попробовать спрогнозировать дальнейшее развитие событий. И предсказать его возвращение к истокам.
В 17 лет я работал и учился около 20 часов в сутки: ходил в школу, домашние задания делал на переменах, а по ночам руководил некоммерческой организацией. Тогда это дало мне возможность получить много маркетинговых кампаний, работать с лучшими организациями и начать успешную карьеру. Став старше, я понял, что много работать — это не всегда единственно правильный путь к успеху.
В тексте речь идёт о маркетологах, однако материал будет полезен всем, кто работает с информацией, чей главный инструмент на работе — это мозг.
Привет, хабр! Меня зовут Алексей, я работаю аналитиком данных в компании "Мегапьютер", но я не сразу стал им. Чтобы понять, кем я действительно хочу работать, потребовалось время.
В 2017 я закончил ЧГУ (Чебоксарский Государственный Университет) по специальности защита информации, но и начал свой трудовой путь в телекоммуникационной компании специалистом по защите информации.
И пошло-поехало первое, что я делал, приходя на работу изо дня в день - проверял свой почтовый ящик на наличие уведомлений о событиях информационной безопасности (ИБ). Данные уведомления поступали из различных источников, включая системы обнаружения вторжений, брандмауэры и антивирусное программное обеспечение. Специалист по ИТ-безопасности, то есть я, должен знать эти предупреждения, чтобы определить, представляют ли они реальную угрозу или ложное срабатывание.
Привет, это Максим Павлов, управляющий партнер KTS.
Типовая ситуация — разработка проекта шла хорошо, а потом тебе либо увеличили команду, либо накинули работы, либо дали дополнительный проект, либо появился ещё один заказчик, интересы которого надо учитывать. И постепенно радость от работы сменяется на грусть от того, что всё начинает ухудшаться.
В статье я расписал, какие маркеры могут указать, что в команду нужно звать аналитика.
Что стоит почитать Product Manager'у в 2023 году? Составил подборку из 10 полезных книг, которые должны быть в библиотеке как начинающего, так и опытного продакта. Для тех у кого совсем мало времени по каждой книге прикрепил ссылку на краткое содержание.
Всем привет! Я достаточно давно в разработке и мне приходилось видеть разные вариации гибких методологий управления проектами. Чаще всего я встречал такую картину: вроде есть спринты, дейли, иногда даже демо, отчеты, но все равно, получив набор фичей от бизнеса, команда не могла сказать достаточно быстро (где-то в течение недели), сколько времени ей потребуется на реализацию. Со временем я пришел к своей спринтовой модели, которая позволяет моей команде довольно точно и быстро давать оценку трудозатрат, что в итоге приводит к успешному попаданию в дату релиза.
В сети вы можете найти множество статей на тему «UML мертв», «Почему системным аналитикам не нужен UML» и множество подобного. Работая на протяжении последних 15 лет в совершенно разных компаниях, с совершенно разным жизненным циклом приложений и систем, с различной структурой и методологиями разработки я вижу одно и тоже — попытки ускорения time‑to‑market за счет отказа от процесса управления требованиями, подаваемые под разными прекрасными аргументами, приводят 100% компаний к необходимости переписывать приложения не потому, что оно не отвечает требованиям, а потому что «никто не знает как или почему оно так работает».
Важной проблемой отказа от нормального процесса управления требованиями является то, что разрабатываемые без этого процесса приложения и системы получаются абсолютно не гибкими и даже элементарнейшие, с точки зрения заказчиков, изменения приводят к запуску полного цикла разработки.
Можно перечислить еще огромное количество проблем, к которым приводит разработка без модели требований.
«Если из человеческого мозга вынуть доброту и любовь, не останется ничего, кроме воли к победе», — Джон Ронсон.
Этой цитатой проще всего описать психопата. У многих людей этот термин ассоциируется с маньяками, спасибо Голливуду за это. Но психопат не равно преступник. В окружении каждого человека множество психопатов. И далеко не все совершают преступления.
Если мы построим распределение людей по уровню эмпатии, то его крайний правый конец займут суперэмпаты. Люди, способные остро чувствовать эмоции и переживания других людей. На крайнем левом конце распределения окажутся психопаты. Люди, не способные понять, что чувствует другой человек. О них и пойдёт речь.
Меня зовут Кеша. Я IT-предприниматель и автор книги «Просто о мозге». В этой статье я опираюсь на свои знания, жизненный опыт и данные из книги Джона Ронсона «Самовлюблённые, бессовестные и неутомимые. Захватывающие путешествия в мир психопатов». Редактирует эту статью Маша Осетрова, нейроучёный, научный журналист, редактор научно-популярных книг.
Вначале я расскажу о психопатии как явлении, а потом поделюсь своим опытом.
Всем привет!
Меня зовут Игорь Гулькин, и я Unity разработчик. За свои 5 лет накопилось много опыта, поэтому в этой статье хотел бы поделиться принципами и подходами, с помощью которых можно реализовать архитектуру игры просто и гибко без фреймворка. Цель доклада, дать не просто готовое решение, а показать ход мыслей, как она выстраивается. Если вы не читали первую часть, то рекомендую сначала прочитать ее :).
Roadmap, который поможет вам научиться работать с SQL. Чтобы стать настоящим экспертом в SQL, нужно много практиковаться и изучать различные аспекты языка на протяжении многих лет. Мой Roadmap предлагает отличный старт для начала изучения SQL, поэтому я рекомендую вам приступить к обучению согласно плану.
Довольно часто слышу вопросы про реализацию этого паттерна, поэтому здесь я постараюсь показать рабочий вариант исполнения.
P. S. спасибо автору этой статьи за взятую без спроса картинку.
Интро
В статье разбираются когнитивные искажения в разрезе влияния на исследователя, она будет полезна как исследователям (особенно джунам и мидлам), так и заказчикам исследований, чтобы понимать какие опасности подстерегают нас всех в увлекательном путешествии под названием UX-исследования.
Естественно, читаю не все (сорри, но темы, которые уже знакомы, проходят только поверхностный фильтр адекватности), однако часто встречается и то, что привлекает внимание и заставляет прочитать полностью и делать для себя заметки. Еще реже появляются статьи, которые прямо хочется прокомментировать или тем более перевести. В этот раз мне попалась отличная, но платная, статья The dark side of User Research: How cognitive biases taint results, которую не только захотелось перевести, но и дополнить собственными комментариями и ссылками.
Получившийся лонгрид сложно охватить за чашечкой кофе или по пути на работу. Рекомендую делать заметки для лучшего запоминания и возвращаться к материалу, когда возникает такая потребность.
Чтение ФТ — занятие непростое. Восприятие новой информации и её анализ требуют продолжительной концентрации и расходуют главный ресурс IT‑шника — внимание.
Если текст сложный, читатель спотыкается в нём и увязает, перечитывает по несколько раз, тратя время и ресурс внимания.
В статье расскажу про простые приёмы для начинающих писателей требований, которые помогут сделать их легче для чтения и ориентирования.
Цель данной статьи - рассказать о GraphQL и Hasura человеку, который вообще ничего не слышал об этих инструментах. И, например, его карьерный путь сложился так, что ему необходимо иметь общее представление об этих инструментах и даже с ними взаимодействовать, например, для проведения тестирования. Или же ситуация иная: человек постоянно развивается, изучая новые архитектурные подходы, следит за популярными и новыми инструментами и сейчас в своем обучении дошел до GraphQL и Hasura.
Я аналитик, который сам недавно оказался в ситуации первого типа (вообще не слышал ничего о GraphQL и Hasura, каюсь), поэтому статья не претендует на глубокое погружение в тему и нацелена скорее на аналитиков и тестировщиков, которые не работали с упомянутыми инструментами.
Теперь всё, переходим к контенту с чистой совестью.
В IT-проектах код пишут все. Инженеры с помощью нескольких строк управляют Kubernetes кластерами, разгоняют облака Terraform'ом и ворочают тонны конфигураций на Ansible, Chef и Puppet. QA пишут понятные бизнесу тестовые сценарии на Spock и Cucumber. Аналитики свободно, часто лучше разработчиков, разговаривают на SQL. Проектная документация в форматах Markdown, AsciiDoc или LaTEX "компилируются" в нужный формат на билд-сервере. Ну а сами разработчики, эти укротители кода, владеют сразу россыпью языков на каждый жизненный случай — клиентский, серверный, скриптовый, функциональный и пр.
Код уже давно перестал быть загадочной тарабарщиной и теперь в том или ином виде доступен и понятен многим, даже премьер-министрам. И весь этот код участвует в стандартном жизненном цикле — находится под управлением VCS, подвергается code review, автоматизированному тестированию, CI, CD. Используются общие инструменты и подходы, метрики производительности и качества. А все вместе это носит гордое название — "Everything as code".
Однако мир БД традиционно стоит особняком вдалеке от этой феерии прогресса и технологий. Процесс разработки и сопровождения БД не меняется годами и продолжает вселять ужас и страх в разработчиков, администраторов и пользователей по всему миру. Но возможно ли представить БД в виде обычного кода? Приблизиться к основному процессу разработки, использовать общие инструменты и подходы? Об этом под катом.
Привет, я Вика Строгонова, руководитель проектного офиса в KTS. Я веду проекты с 2017 года и прошла путь от младшего менеджера до руководителя проектного офиса. Сейчас в моем портфеле более 20 проектов, в подчинении — 42 человека, среди них разработчики, аналитики и менеджеры.
Текст написан на собственном опыте, поэтому уверена, что есть и другие ошибки, которые я не учла в статье. Буду рада, если поделитесь ошибками джунов, с которыми вы чаще всего сталкиваетесь, в комментариях.
Все типовые проблемы, о которых пойдет речь ниже, касаются менеджеров-джунов или вчерашних стажеров. Это не тайные знания, которые открываются только тем, кто несколько лет отработал на проектах или прошел специальные курсы: это достаточно базовые вещи, которые начинающие менеджеры почему-то упускают.