Здесь могло быть долгое вступление о том, почему круто смотреть сериалы в оригинале. Но вы и так всё знаете. Давайте сразу к делу.
Если ваш английский - Intermediate и выше, но вы всё ещё не смотрели “Кремниевую долину” в оригинале, расскажу, кому и почему этот сериал - must-have:
Все годы существования YouGile на вопрос «нужно ли делать CRM?» мы отвечали однозначно: конечно, нет! Это погубило десятки таск-трекеров, превратив их в перегруженных монстров. И вот мы подумали и решили делать… собственную CRM. Рассказываем, почему мы считаем, что рынку нужна простая CRM, и показываем первые прототипы.
Привет, Хабр!
Если вы не разработчик и не понимаете, каким способом разработка определяет приоритет вашей задачи (спойлер: лунный календарь или ретроградный Меркурий к этому не имеют отношения), то эта статья будет вам полезна.
Если вы продакт-менеджер, который видел все в этой жизни, и отчаялся настолько, что уже готов приоритизировать бэклог по картам таро, то эта статья будет вам полезна.
Если вы разработчик и устали гореть от того, что задачи в бэклоге выстраиваются по пирамиде Маслоу или рандомайзеру, то эта статья будет вам полезна (как минимум, разбавите рутину на следующем стендапе).
В общем, в новом посте рассказываем про популярные способы для приоритизации бэклога команды разработки и почему мы запилили свой.
Цель этой статьи — показать, в каких случаях Agile не принесет ожидаемого эффекта, рассмотреть наиболее распространенные случаи его некорректного применения и обозначить ключевые моменты, на которые важно обратить внимание перед началом Agile-трансформации.
В разработке мы говорим о ценностях команды, фидбэке, прозрачности, доверии, фазах зрелости и продуктовой гипотезе. Мы умеем строить сложные продукты, управлять рисками, преодолевать фрустрацию, масштабировать решения. Но при этом многие из нас — и мужчины, и женщины — испытывают трудности в построении личных отношений. Всё чаще одиночество становится новой нормой в айти-среде: вместо партнёрства — автономность и самодостаточность, вместо диалога — выгорание от попыток «понять друг друга» и как итог проще пойти по разным дорогам. Но ведь навыки у нас уже есть — просто мы не используем их в этой области личной жизни.. Но стоит заговорить об отношениях — и взрослые люди с синьорным опытом вдруг возвращаются к паттернам: «она/он обязан/а», «он/она не помогает», «мне просто не повезло». А ведь всё можно иначе.
Предлагаю подойти к теме как продакты. Представим, что отношения — это продукт. Долгосрочный, совместный, со своими пользователями, целями и метриками. И взглянем на него с позиции командной зрелости, известных каждому в IT.
Мы сейчас становимся свидетелями удивительных событий в мире, и мир бизнеса тому не исключение.
Одним из таких удивительных и очень поучительных для бизнеса событий является поведение Илона Маска и ситуация с Tesla, продажи которой рухнули менее чем за месяц на 45% в мире, а в отдельных странах и на все 70%.
Чем интересен для руководителей этот кейс?
Тем, что на его примере мы в реальном времени можем наблюдать, какая ответственность лежит на лидере, и к чему может привести отрыв лидера от реальности и, главное, как разрушительно может быть это поведение для компаний. Особенно, если весь этот бизнес и его успех был завязан на личности лидера.
Илон Маск в основу успеха бизнес-модели своей компании положил ценностные критерии развития и прогресса, таким образом расположив к себе аудиторию именно с такими же ценностями. И когда он изменил этим ценностям, то его бизнес лишился очень лояльной, к тому же еще и финансово обеспеченной аудитории.
С ценностями нельзя играть, такое не прощается людьми. Люди не очень любят, когда их обманывают, и особенно не любят, если этот обман касается ценностей. Особая роль ценностей в жизни человека связана с тем, что они воспринимаются людьми как неотъемлемая часть их личности, и поэтому даже словесная критика ценностных моментов вызывает в мозге реакцию сопоставимую с прямой физической агрессией.
Есть еще один важный и уникальный аспект кейса Маск/Tesla, что мы видим разрушение стратегии Голубого океана. Очевидно, что невероятный успех Tesla как раз связан с тем, что это как раз компания стратегии Голубого океана. Только абсолютная лояльность клиентов по отношению к такой компании обеспечивала неоправданную стоимость Tesla, чья капитализация на пике была больше других автомобильных компаний вместе взятых.
Как мы превратили Sales‑Led в Product‑Led и кратно увеличили eNPS и MRR за 3 месяца
Продажи жалуются, что продукт непродаваемый, а продакты отвечают, что продукт несет ценность, просто продажи не умеют его продавать?
В нашей статье мы разбираем, как мы отстроили единый фреймворк целей, внедрили WSJF‑приоритизацию и OKR, чтобы превратить Sales‑Led в Product‑Led и получить +18% MRR всего за 3 месяца. Узнайте, какие шаги сработали и какие метрики изменили правила игры!
Вся жизнь IT-команды в одной статье.
Последние полгода у меня зрела мысль поделиться накопленным опытом нашей ИТ-команды, но подходящего повода не находилось, пока я не попал на мероприятие по «практикам прозрачных процессов». Там я снова услышал знакомую проблему — одни и те же абстрактные ответы без примеров и конкретных решений на вопросы коллег. Хотя я всего лишь рядовой участник воркшопов, а не спикер, регулярно замечаю эту тенденцию.
Поэтому ничего другого не остаётся, как описать реальные практики, которые наша команда успешно использует уже несколько лет. Это не теория из учебников, а проверенные решения, которые действительно работают в наших условиях.
Статья подойдёт:
— Новичкам в IT — тем, кто только начинает разбираться в Agile и хочет увидеть реальные процессы «изнутри».
— Коллегам из других сфер — если ваш опыт работы отличается, здесь вы найдёте конкретные примеры и, возможно, идеи для своих проектов.
— Критикам и экспертам — если вы замечаете спорные моменты или хотите поделиться альтернативным подходом, добро пожаловать в комментарии!
— Моей команде — как напоминание о наших договорённостях и повод для дальнейшего улучшения процессов.
Это моя первая статья поэтому я буду рад вашим комментариям и ценным советам.
Привет! Меня зовут Артем, я технический лидер в крупной it компании РФ. Расскажу как использовал nexus framework для масштабирования команд разработки.
Мне нравится наблюдать за менторами, которые учат быть независимыми в тестировании и слать всех нафиг т.к. тестирование это не поиск багов, а сравнение ожидаемого результата с фактическим, и если нет требований, то и сравнивать нечего!
Прекрасно, вам должны платить просто так! Ведь мы работаем только так как написано в ISTQB, а там много чего написано) И на заборе тоже написано...
Вам задают простой вопрос, почему вы пропустили баг на прод? Это обычный разбор полетов после релиза и нужно учится на своих ошибках, прежде чем стартанет следующий горящий релиз! И нам необходимо объяснить причину, которая скрывается не только в процессах тестирование, но и в процессах всей команды.
Сегодня хочу поговорить с вами про такую животрепещущую тему, как интеграция новых процессов в команду. Неважно, идёт ли речь о канбане, скраме, каких-то ритуалах которые вы проводите с утра - как только вы приносите что-то новое, начинается сопротивление. Даже если оно пассивное, даже если люди говорят «да-да, окей» - это ещё не значит, что процесс будет принят и заработает как надо.
Важно: мы сейчас не обсуждаем, стоит ли вообще что-то вводить. Предположим, вы уже всё проверили: провели анализ, посмотрели на команду, сравнили с метриками и точно уверены что изменения нужны. Тогда начинается настоящая работа: как это донести до людей и внедрить так, чтобы не вызвать саботаж.
Собрали вдохновляющие истории от IT-специалистов, чтобы узнать, как им удается совмещать спорт с напряженной рабочей рутиной и не терять мотивацию (и как и когда они эту мотивацию нашли).
Привет, читатели Хабра!
Кому из нас не знакома ситуация, когда «горит» вообще всё и сразу? Кажется, что каждая задача кричит: «Сделай меня первой!» И вот тут‑то и возникает ступор: за что хвататься, с чего начать? Методик приоритизации существует великое множество — от простой и понятной матрицы Эйзенхауэра до запутанных фреймворков вроде WSJF. Но как во всем этом разобраться и не утонуть в бесконечных таблицах и формулах?
Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT‑отделом 8. Я работаю в компании Софтонит. В этой статье я постараюсь простым языком рассказать о самых популярных подходах к приоритизации задач. Мы разберем их плюсы и минусы, посмотрим на реальные примеры и, надеюсь, вы найдете тот инструмент, который будет вам полезным и поможет навести порядок в бэклоге, а также сделать процесс приоритизации четким и понятным.
В digital-разработке, как и в любом другом деле, ошибки неизбежны. Но именно они часто становятся катализатором полезных изменений. Мы собрали несколько честных примеров из нашей практики, когда факапы привели к появлению новых рабочих процессов, фич и регламентов, которые теперь помогают нам избегать проблем и работать эффективнее.
SP создали, чтобы уйти от тирании часовых оценок, но в итоге без понимания принципов превратились в бессмысленный ритуал. Команды тратят рабочее время на пересчет баллов в дни, менеджеры требуют «увеличить velocity на 20%», а разработчики — тихо ненавидят планирование.
Разбираемся, что такое Story Points, как их считают, в чем их проблема и как их используют разные команды.
Вот вам страшная правда: проблемы в проектах происходят не из-за того, что люди делают плохо, а из-за того, что никто не проверяет, что они делают. И как же быть, если задачи считаются выполненными, а на самом деле не проверены, не согласованы и не готовы?
Перевод статьи подготовлен редакцией итеративно-функционального метода, новейшей альтернативы Agile и Kanban. Дисклеймер: эта специализированная статья подходит для продуктовых менеджеров и энтузиастов продуктовых методологий и продуктового тулинга.
Джейсон Фрайд (Jason Fried), CEO компании 37signals — создателей Basecamp и HEY — недавно опубликовал в своих запрещенных в России соцсетях два демо видео нового продукта Fizzy, который представляет собой новый взгляд на трекер идей, задач и багов. Представление задач реализовано в виде коллекции (аналог доски в Канбане) с двумя колонками — «В рассмотрении» (“Considering”) и «В работе» (“Doing”). Карточки в обеих колонках содержат заголовок, имя автора карточки и исполнителя, а также информацию о дате создания и последнего обновления. В колонке «В работе» есть переключатель стадий («Изучение», «В процессе», «Блокировано»). Последовательность стадий определяется одним из выбранных рабочих процессов (workflow), который настраивается в параметрах коллекции. В зависимости от выбранной стадии меняется цветовая схема карточки. Завершённые карточки отправляются в подвал страницы, где каждая карточка проштампована большой печатью с причиной закрытия.
Прежде всего хочу подчеркнуть, что с большим уважением отношусь к Джейсону Фрайду и СТО 37signals Дэвиду Хайнемайеру Ханссону (DHH) и к их работе. В эпоху бездушных аджилистских монстров вроде Jira, ClickUp, Asana и десятков их безликих клонов, Джейсон и Давид создали оригинальный подход под названием Shape Up, который во многих аспектах лучше адаптирован под современную разработку для мобильных и веб-платформ, чем Agile, Scrum, SAFe и иже с ними.
В мире успешного успеха, в который мы погрузились, где продакты рапортуют о новых достижениях в метриках, а топ-менеджеры, перечисляют какие преимущества дают их бизнес-функции. Мнение конечного пользователя, кажется, статистически ничтожным.
Я помню времена, когда требования были — понятнее, бюджеты на реализацию — жирнее, а команды — меньше/больше, что позволяло фокусироваться на действительно важных вещах, которые запоминались и западали в душу пользователям.
Их копировали, пересматривали и вводили как эталон.
Это статья не про тех менеджеров, кто таски в джире двигает и статусы собирает. И не про тех, кто просто ретранслирует запросы сверху вниз и держит в поле только календарь. Здесь пойдёт речь о людях, которые по-настоящему держат на себе команду, бизнес и продукт. О тех, кто в небольших компаниях или стартапах становится точкой сборки: принимает решения, управляет продуктом, координирует разработку, тащит финансы и договаривается со стейкхолдерами. И всё это одновременно.
Если ты был в такой роли - ты знаешь, о чём речь. Если нет - добро пожаловать в экскурсию по состоянию, где выгорание не приходит по расписанию, а подкрадывается тихо и исподтишка. Здесь нет оценки сверху, нет зрелых коллег, которые скажут «ты молодец» или «пора свернуть». Ты - сам себе барометр. Ты - точка принятия решений. Ты - ресурс, который должен работать без сбоев. А потом внезапно ловишь себя в состоянии, когда больше не можешь.
И вот эта статья - не гайд. Это скорее проживание. Разговор. Попытка систематизировать опыт, ощущения, тупики и возможные выходы. Без универсальных решений, но с попыткой назвать то, что обычно замалчивается.
Бро, если ты хоть раз руководил командой — ты это проходил. На стендапе всё звучит красиво: «делаю задачу, осталось чуть‑чуть», «почти готово», «просто баг странный». А потом проходит неделя, ты заглядываешь в код — и там либо ничего, либо половина сделано, либо вообще не туда копали.
Нет, это не обязательно саботаж. Иногда это банальная прокрастинация, страх ошибиться, потеря мотивации, или просто неумение сказать: «я застрял». Но проблема‑то реальная. Если не ловить и не разруливать — команда тонет в самообмане, а ты — в вечных переносах.
Разберёмся, почему разработчики врут (осознанно и не очень), какие признаки надо замечать раньше, и как перевести разговор из «всё нормально» в «честно, я залип». С кейсами, приёмами и без розовых очков.
