User
Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.
Кирилл Алексеев работает в VK, руководит несколькими командами разработки бэкенда в Почте Mail.ru. Далее, рассказ будет от его имени. Он расскажет, как они в RuStore сделали свои пуш-уведомления, а конкретно транспорт на замену Google Firebase для Android, чтобы посылать пуш-уведомления в обход инфраструктуры Google. Сделает обзор публичной части сервиса, погрузит в детали архитектуры бэкенда сервиса пушей. Пояснит, как устроены их мобильные SDK, как они интегрировали пуши RuStore в Почту Mail.ru и почему не лягут надолго. Покажет, что у них получилось и как этим можно пользоваться.
«Не понимаю нашего будущего» — если вы слышите такое внутри вашей компании, то, возможно, вам просто необходима стратегическая сессия.
По крайней мере такое решение я, как scrum master и Agile coach определила внутри нашего коллектива, когда столкнулась с такими высказываниями во время обсуждений на ретроспективах и других встречах. Коллектив, на примере которого я предлагаю вам сегодня разобрать опыт ведения стратегической сессии, – gamedev паблишер, где работают продюсеры, маркетологи, аналитики, копирайтеры и другие специалисты.
Стратегическая сессия, которую я решила провести, как-раз таки должна была дать ответ на вопросы о будущем; а также сформировать прозрачное видение целей и сориентировать команду на результаты, а не на процессы; настроить на совместную работу, которая поможет двигаться в сторону этих целей.
Я обозвал их изобретением дьявола потому что они обладают специфическими свойствами, которые легко вводят в заблуждение неокрепшие умы. В этой статье я бы хотел немного рассказать про них и развеять несколько мифов.
Диагональный буфер — это часть решения по управлению проектами в Теории Ограничений Голдратта (ТОС). Это только часть решения, части проблем. Решения не бывают хорошими или плохими вне контекста. В предыдущей заметке я описала проблему, которую решает диагональный буфер, время прочтения — 4 минуты. Посыл — срок задачи в проекте не работает как хотелось бы.
Решение ТОС для проектного управления называется метод Критической цепи. Отличается от метода Критического пути тем, что мы уходим от срока задачи.
Диагональный буфер — это инструмент приоритизации. Если у нас не будет сроков задач, то непонятно как в каждый момент времени ответить на вопросы: мы успеваем, или пора торопиться, или уже пора разговаривать с заказчиком о переносе срока? А если я могу приступить к выполнению нескольких задач из одного, или даже разных проектов, как выбрать, с какой начать?
Пишем подробный план
Мы начинаем с того, что строим обычную диаграмму Ганта. Выписываем задачи и распределяем их в порядке выполнения. Чем подробнее будет ваш план, тем лучше. Что такое подробный план? Если, например, нам нужно написать ТЗ, то нельзя отделаться одной задачей: «Написать ТЗ«. И даже если вы добавите «Согласовать ТЗ», этого тоже будет недостаточно. Подробный: написать ТЗ, показать, доработать, показать, доработать и т. д. Чем лучше такой план? Тем что задача «написать ТЗ» будет оценена мной в 2 недели. А набор из 6 мелких задач будет оценён мной в 3.5 дня. Это не значит, что я оставлю себе на это 3.5 дня, но это значит, что дальнейшие мои расчёты будут реалистичнее.
Это моя первая статья но надеюсь вам понравится! Почему я решил создать эту статью, когда скорее всего есть уже много других подобных? Дело в том что официальное API компании OpenAI(компании которая создала ChatGPT) - платное(пробный период быстро заканчивается), но недавно я нашел метод, которым сам пользуюсь, через который можно создавать приложения с использованием ChatGPT - бесплатно, покажу на примере просто Telegram-чатбота.
Привет, Хабр! Вы уже пользуетесь нейросетями в своей ежедневной работе?
Меня зовут Дмитрий, я — руководитель команды в департаменте проектирования и разработки. Как и любой человек с ограниченным временем и неограниченным количеством задач и фантазией, я постоянно ищу способы оптимизировать любые процессы. В статье я расскажу вам о своём опыте внедрения ChatGPT-4 в разработку программного продукта — от аналитики до кода, на конкретных примерах.
“Сможет ли ChatGPT заменить меня на работе?”. Вопрос ведь далеко не новый. Статья дает на него ответ в контексте профессии архитектора ПО. На реальном примере взаимодействия с "чатом" предлагается разбор преимуществ и недостатков использования для решения рабочих задач.
Привет, Хабр! Мы — ИТ-команда департамента «Сеть продаж» — отвечаем за физическую сеть Сбера: банковские отделения, пункты выдачи заказов, банкоматы, работу выездных сотрудников и многое другое. Делимся своим опытом проведения бесед один на один HR-партнёра с сотрудниками команд. Наши советы и варианты вопросов с подробной инструкций помогут вам лучше управлять настроением в командах, развивать и обучать сотрудников, влиять на найм и удержание.
Привет! Меня зовут Наташа Калачева. Я Frontend-разработчик в компании AGIMA. Vue — один из самых популярных фреймворков JS, его используют для разработки SPA и PWA. А его главные плюсы — это понятная, четкая документация, готовая структура и низкий порог входа.
Тем не менее, Frontend сегодня — это сложные приложения, которые содержат не только красивые элементы интерфейса, но и большую часть логики и функциональности всего продукта. Это требует от нас тщательного планирования и организации проекта, чтобы сделать его масштабируемым и простым.
В этой статье поделюсь правилами, которых придерживаюсь в работе и которые помогают упростить поддержку и расширение приложения. Мы рассмотрим, как организовать хранение компонентов, стилей и плагинов, когда использовать стор и полезные функции Vue.
Следуя этим рекомендациям, вы сможете создавать более эффективные проекты.
Когда разработчик недостаточно осторожен, дела могут пойти весьма плохо. Например, классические упущения разработчика — использование новой версии API, которая не совместима со старым кодом, выполнение действий, которые требуют специальных пользовательских разрешений, пробелы в локализации приложения. И это только некоторые из них.
Кроме того, в Java и Kotlin, как и в любых других языках программирования, есть свои собственные конструкции, которые могут привести к снижению производительности.
Мы используем инструмент под названием Lint (или Linter) для избежания таких проблем. Lint — это инструмент для статического анализа кода, который помогает разработчикам изловить потенциальные проблемы ещё до того, как код скомпилируется.
Бытует мнение, что ретроспектива это скучная встреча без явной пользы. Если ставить цель, фиксировать прогресс и подбирать интересный формат ретроспективы, то польза от этой командной встречи не заставит себя ждать. В статье вы найдете 3 варианта эффективных ретроспектив, проводимых в командах разработки Ozon.
Многие ответят - конечно! Другие, возможно, скажут: "Ты что, чувак! Что вообще за вопрос? И кто ты такой?"
Классический подход РМbok подразумевает наличие объекта, субъекта и методов - такой набор, по мнению PMbok, делает любой проект управляемым.
Но я думаю, слово "управлять" мало применимо к проектной работе. Да и сама работа называется проектной только потому, что ее результатом должен стать набор уникальных характеристик конечного продукта - процессный подход здесь как бы не подходит, т.к. заточен под унификацию продукта.
Я размышляю об этом потому, что последние 12 лет работаю руководителем проектов в промышленном строительстве и пытаюсь понять, правильно ли делаю свою работу. Вам может показаться, что стройка – это что-то далекое и вообще про мужчин в спецовках и касках, но на самом деле наши подходы становятся все более сходными с Ай-Ти. Прежде всего потому, что строительство стремительно цифровизуется.
Привет, мир!
Поскольку это моя первая статья, я просто обязан начать ее именно с этой фразы.
В ходе работы над проектом появилась задача связать форму обратной связи на странице с гугл таблицами. Суть проекта в отслеживании конверсии команды. В русскоязычном интернете мало информации на эту тему, поэтому предлагаю свое решение.
Для реализации задачи потребуется google apps script и форма обратной связи.
Перейду сразу к делу.
Всем привет! Давайте знакомиться ;) Я Аня, и я php разработчик. Основной стек - Magento. С недавних пор начала посматривать налево на Symfony и писать свои Pet Projects на этом фреймворке.
Мне всегда нравилось писать решения которые легко бы расширялись / адаптировались под требования бизнеса (заказчика). И мне всегда хотелось сделать это более 'правильно' и красиво. Так я и познакомилась с понятиями чистой архитектурой.
Мой пост ни в коем случае не претендует на самый правильный. Но позвольте мне здесь донести свои идеи. В комментариях буду рада услышать конструктивную критику к данному посту.
Для нетерпеливых, вот прямая ссылка на гитхаб
Все, кто слышал про Scrum, скорее всего слышали про его основные мероприятия: планирование, пятиминутка (stand-up), обзор спринта и ретроспектива. Многие слышали, инструментов для проведения ретроспектив много, "обучающих" материалов ещё больше, но всё как-то не выходит. Или вроде как выходит, но почему-то команда не хочет в этом участвовать. В этой статье я представлю свой рецепт проведения ретроспектив, не только представив конкретные и детальные шаги, но и попробовав объяснить, почему шаги именно такие и в такой формулировке.
Привет! Меня зовут Артур Карапетян, я Product Owner в Starfish24. Мы помогаем российским ретейлерам управлять жизненным циклом заказа, выстраивать и контролировать логику обработки с помощью OMS-системы. В общем, сложные омниканальные заказы — это про нас.
В конце 2018 года я пришел в тогда еще сырой стартап из 15 человек на должность Frontend-разработчика и не подозревал, с чем мне придется столкнуться в следующие три года. Я видел, как один человек выполнял роли сразу трех специалистов, как быстро выгорали новички, и как два человека обрабатывали по 1 000+ инцидентов после релиза.
Каждый ретейлер хочет непрерывного развития своего бизнеса: добавление новых модулей в систему, автоматизацию процессов, интеграцию с новыми каналами продаж. Мы тоже за развитие, но когда клиентов и задач становится много, все костыльные процессы, которые хоть как-то держались на маленьких объемах, начинают с грохотом падать, а люди — выгорать.
Сейчас, уже в роли Product Owner, я слежу за тем, чтобы наш продукт шел туда, куда нужно, а все доработки только развивали продукт, а не мешали ему. Весь 2022 год я с коллегами внедрял новые регламенты по процессам и хочу поделиться с другими продуктовыми командами нашим опытом. Расскажу, как мы за год трижды пересмотрели подход к развитию продукта и клиентским задачам. И покажу, почему к самым очевидным вещам приходишь только спустя время.
Внутри — много-много бордов из Miro, погнали.