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

Из всех сетей генерации изображений мне больше всего понравился Midjourney - оптимальное качество на потраченное время. Я понимаю в самом Midjourney (не говоря про Stabble Diffusion) можно углубиться в детали - но я не дизайнер или AI artist, мои задачи прикладные.

У меня уже сгенерированно более 4000 изображений и я выделил 10 методов, которые позволяют достаточно быстро и качественно получить нужный мне контент.  Они могут использоваться как обложка к посту или лонгриду, или я чаще использую в презентации.
Надеюсь, эта статья сэкономит вам несколько часов!

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

— работа с проектами и задачами;

— разного рода планирование; 

— процесс интеграционного тестирования; 

— визуализация и сжигание технического долга; 

— сокращение time-to-market;

— проработка бизнес-идей и многое другое.

В декабре прошел очередной IT's Tinkoff Process Improvement #2 — митап, посвященный управлению изменениями. Вместе с коллегами из других компаний мы обсуждали, как проводить изменения и какие инструменты применять. Римма Денисовец из and Change выступила с докладом «Пять этапов для успешных изменений ADKAR», а Денис Тучин из Agile Collage раскрыл тему «3 основных ошибки агента изменений». Я же подготовил доклад «Как не навредить себе и коллегам? Стратегия проведения изменений».

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

Всем привет! Я Евгений Степченко, деливери-менеджер в Тинькофф. Расскажу про подход к анализу и улучшению процессов, который называется STATIK, System Thinking Approach To Introducing Kanban — применение системного мышления при анализе и проектировании канбан-систем. Поговорим о том, как устроен этот подход и как он помогает запускать эволюционные изменения.

Статья будет полезна тем, кто вовлечен в управление процессами и изменениями на основе канбан-метода. Если вы плохо знакомы с методом, советую сначала изучить официальное руководство. В конце статьи я поделюсь другими полезными ссылками по теме.

Привет, Хабр! Я Денис Бартоломе, Agile-коуч Сбера.

Вся эта статья ― обсуждение последней, седьмой, версии руководства к Project Management Body of Knowledge (PMBoK) и её влияния на прекрасный мир проектного управления. PMBoK ― свод знаний, максимально полное изложение информации по управлению проектами. Этими «священными скрижалями» современных управленцев ведает Институт управления проектами (Project Management Institute, или сокращённо PMI).

В 2021 году свод знаний кардинально изменился. Ну, например, в последней версии популярного стандарта основным объектом управления стал не проект, а производственная система организации. В этой статье я рассказываю о влиянии этих изменений на мир проектного управления, а также о том, какую во всём этом роль играют Agile и Kanban. Если тема интересна, приглашаю под кат.

Главная сложность в разработке приложения – накодить его функционал. Например, сделать редактирование текста для приложения-блокнота. Так я полагал, когда был моложе и наивнее.

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

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

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

Сколько открытых багов у вас в бэклоге? 100? 1000?
А сколько времени они там лежат? Неделю? Месяц? Годы?
А почему так происходит? Нет времени? Надо делать более приоритетные задачи? «Вот сейчас все срочные фичи реализуем, а потом точно будет время на разгребание багов»?

… Некоторые используют Zero Bug Policy, у кого-то хорошо развита культура работы с багами (своевременно актуализируют бэклог, пересматривают ошибки при изменении функциональности и т.д.), а кто-то выращивает волшебников, которые пишут вообще без багов (маловероятно, но, может, и такое бывает).

Сегодня я расскажу вам про наше решение по чистке бэклога багов — проект «Багодельня».

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

Думаю, ни для кого не секрет, что Scrum сегодня – одна из самых популярных Agile-методологий. В сети можно найти много позитивных отзывов от людей, которые его попробовали. Но очевидно, что положительных результатов удается добиться не всем, поэтому есть и немалое количество критических статей. Вот, например, недавно тут же – на Хабре – был опубликован перевод подобной статьи  «Почему оценка задач сломала Agile».

У меня есть хороший опыт использования этого самого Scrum`а и оценки задач в нем, поэтому возникла мысль написать разбор приведенных тезисов и ответить на критику (что-то  в стиле «Антипаттерны Scrum»). Но в итоге, я решил, что будет честнее (по крайней мере для моей первой публикации), если я начну с позитива, и сначала попытаюсь сам разъяснить главное на мой взгляд заблуждение в статье – что же такое Story Points, и что такое оценка в Scrum.

При этом я не хочу писать новую инструкцию. Если вам нужны формальное описание и детали, то можете обратиться к первоисточникам, например к книге Джеффа Сазерленда «Scrum. Революционный метод управления проектами» (МИФ, 2015) – там все подробно описано с обоснованиями и прочим. Я же, в свою очередь, хочу предложить более короткий путь: «с использованием местных идиоматических выражений».

Привет всем, кто интересуется Канбан‑методом, и кто хочет познакомиться поближе с одним из его инструментов — S.T.A.T.I.K.

Задумка этой статьи появилась тогда, когда в очередной раз ко мне кто‑то подошел с вопросом: «Мы собираемся делать СТАТИК, где про это можно почитать?»

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

Привет, Хабр! Меня зовут Артур Темиров, я delivery‑менеджер в одном из продуктов X5 (о нём дальше в тексте). Над его созданием у нас трудятся 5 технических команд — в общей сложности это более 60 человек. В статье рассказываю о том, как визуализация является отправной точкой для эволюционного развития процессов, а также об ошибках, которые могут допускаться на этом пути.

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

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

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

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

Привет! Я Саша Пургина, руководитель отдела развития data-продуктов в Lamoda. В этой статье хочу рассказать, как мы использовали экспертизу разных команд для генерации 200+ новых гипотез и сплотили весь отдел вокруг решения пользовательских проблем.

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

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

Статья о том, как я в 15 лет облегчил работу с электронным дневником, представленным Кировской области в 2022 году.

Что получилось сделать и как это было реализовано.

Привет, Хабр! Меня зовут Екатерина Батырская, я занимаюсь карьерным консультированием, HR в сфере IT, а сейчас — продакт карьерного трека в Практикуме. В прошлом — Head of HR международной IT-компании. И сегодня хочу рассказать об обратной связи — зачем она нужна, как её запрашивать, получать, и что нам мешает делать это правильно. 

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

Всем привет! Меня зовут Дмитрий, я релиз-инженер в команде CI/CD Speed Авито. Вот уже несколько лет мы с коллегами отвечаем за всё, что связано с релизами наших мобильных приложений и не только. В прошлый раз я рассказывал о нашей системе релизов мобильных приложений на основе контракта. Сегодня речь пойдет о том, как мы автоматизировали сбор информации из Firebase о новых фатальных ошибках в мобильных приложениях.

Lua — это, пожалуй, мой любимый "маленький язык", с низкой когнитивной нагрузкой и простотой в изучении и использовании. Он встроен во многое ПО, такое как Redis, NGINX через OpenResty и Wireshark (прим. перевод.: и многое другое). Он также используется в качестве скриптового языка в таких играх, как World of Warcraft и Roblox через Luau (прим. перевод.: и многих других). Этот пост — краткое признание в любви языку с некоторыми примерами того, почему он мне так нравится.