Это история о том, как попытка починить маленький раздражитель в Claude Code неожиданно привела меня к полноценному сетапу для разработки фич совместно с AI-ассистентом. Приложил немного музыки для атмосферы.
Я больше 10 лет работаю в продуктовом дизайне и дизайн‑менеджменте. Обычно — на стыке дизайна, процессов и продукта. Помогаю компаниям решать проблемы деградации интерфейсов, несистемности и слабой синхронизации между дизайном и разработкой.
В арт-аутсорсе часто возникает парадоксальная ситуация: проект формально растёт, показатели выглядят хорошо, команда справляется, но непонятно, насколько система устойчива и как долго выдержит текущий темп.
Когда я впервые столкнулась с этим, стало ясно: нам не хватает не процессов, а измеримости. Казалось бы - изучай, внедряй, пользуйся. Но в арт-аутсорсе ААА-тайтлов мы работаем с художниками, которые приходят делать качество, а не количество. А сами проекты зависят от клиента, арт-видения и постоянно меняющихся приоритетов.
На старте это выглядит так:
В какой-то момент почти каждая продуктовая IT-команда приходит к одной и той же мысли: «Нам нужно навести порядок в процессах».
Это обычно происходит не из-за моды на менеджмент, а из-за вполне конкретных ощущений:
задач много и все срочные
задачи делаются дольше, чем хотелось бы
ожидания у команды и бизнеса не совпадают
обсуждений много, а ясности нет.
В такие моменты «описание процессов» начинает казаться логичным решением. Если всё расписать, разложить по шагам, назначить роли и ответственных - вот тогда заживем!
Привет! Меня зовут Инесса. Я — аналитик в компании fuse8. Предлагаю сегодня поговорить о том, как встроиться в уже сработавшуюся команду. По моему опыту, это всегда испытание. Почти как игра в русскую рулетку: не знаешь, как команда примет новичка и как быстро он подстроится под общий ритм. Новому человеку нужно время на адаптацию, обучение и погружение в процессы. И только потом можно по-настоящему оценить его вклад.
Фичи в мобильной разработке — головная боль аналитиков и продактов: детали вроде есть, цвета красивые, но что из этого должно получиться — загадка. Особенно если вы — аналитик или продакт, которому нужно превратить абстрактное «надо бы сделать круто» в чёткие требования. В этой статье расскажу, как выстроить работу с фичами так, чтобы команда не страдала, пользователи радовались, а вы — чувствовали себя гением.
Представьте, что вы - руководитель команды разработки в IT-компании. Живете себе спокойно, никого не трогаете, делаете с командой проекты, закрываете задачи. И вот в какой-то момент к вам приходит ваш непосредственный руководитель и спрашивает вас:
Слушай, а твоя команда вообще производительна?
И тут вы понимаете, что вопрос застал вас врасплох. В вашей голове запускается мыслительный процесс:
В последнее время на Twitter чуть ли не из каждого утюга льется критика по поводу оверинжиниринга. Даже некоторые вполне технически подкованные люди заявляют, что Твиттер можно было бы поддерживать вообще одному - мол, "подумаешь, твиты хостить, 80% всех микросервисов ему не нужны".
Всем привет! Это снова Иван Антипин, заместитель технического директора AGIMA. Весной я рассказывал здесь о матрице компетенций — удобном инструменте менеджмента. И поскольку статья вызвала интерес, я подготовил еще одну. В этот раз речь пойдет о слабом звене — том самом участке работы, из-за которого рушится весь процесс. Разберемся, как его найти, с помощью чего устранить и что потом делать. Пишу по материалам доклада Ивана Михеева.
В этой статье я не буду рассказывать про успешные внедрения, лучшие практики и общеполезные методики. Я вообще не буду давать какие-либо советы. Наоборот, попытаюсь на основании своего опыта рассказать, как бывает плохо, какие практики быстро становятся ужасными и чего нужно опасаться.
