В процессе создания программного обеспечения участвует множество ролей, каждая из которых имеет свою систему ценностей, приоритетов и целей. Эти различия часто приводят к противоречиям в требованиях. Для структурированного анализа таких конфликтов используется модель «Гексапараллакс», которая рассматривает шесть ключевых точек зрения:
Много JavaScript‑фреймворков назад, в 2009 году, Джеффри Дин, будучи инженером в Google, представил знаменитые «числа, которые должен знать каждый программист».
Много лет в разных компаниях я была перегружена. Делала слишком много ― и всегда было мало. Решение оказалось проще, чем казалось. Поделюсь, как без навороченных инструментов и с помощью всего одной канбан-доски бустануть эффективность.
Последние годы в управлении проектами активно распространилась идеология Agile. Многие работодатели указывают знание Agile как обязательное требование к кандидату. Появились целые школы, которые обучают Agile, выдают сертификаты и т.п. Я считаю, что эти люди( и работодатели, я уж не говорю про HR) просто не имеют опыта управления, а Agile - модное слово, наверно что-то продвинутое, современное. В общем я знаю, как образовалась Agile, с точки зрения программиста она достаточно привлекательна. Но распространять идеологию Agile на все проекты в ИТ - мягко выражаясь некорректно. Предлагаю вашему вниманию другую идеологию управления проектами и продажами.
За семь лет проведения воркшопов по Story Points я наблюдаю одну и ту же картину: команды изучают технику, применяют её несколько спринтов, а затем постепенно возвращаются к старым паттернам. И если на маленьких масштабах работы с одной командой или тремя кажется что Story Points прекрасный подход, на текущем масштабе — около 50 команд в IT — 60% используют Story Points, 40% не используют - я вижу совершенно иную картину. И вот что интересно: те 60%, которые используют, делают это крайне по-разному.
Причем конверсия в правильное использование Story Points 3 месяца после тренингов составляет дай бог 20%. Проблема не в самом инструменте, а в том, как мы его используем и для каких целей.
Чем дольше я работаю в разных системах управления проектами — тем лучше понимаю, насколько разные у команды и руководителей приоритеты.
— Сотрудникам важно легко разобраться в интерфейсе, держать под рукой свои задачи и красивый фон для доски с задачами выбрать 😌
— Руководителям важно знать, кто чем занят, контролировать работу команды и видеть полную картину по проектам 😎
Этот обзор я решила посвятить руководителям, так как сама пару лет назад начала управлять отделом. И теперь мои требования к системе управления проектами сильно возросли. В нем будут обзор возможностей для руководителей в разных сервисах, примеры использования и комментарии из личного опыта. Сотрудником тоже будет полезно о них узнать.
Переименование Scrum Master в Agile Delivery Manager — не просто смена названия на бейдже. Это отражение глубинных изменений в понимании роли, сфокусированной не на фреймворке, а на реальной ценности, которую команда приносит бизнесу. В эпоху потокового мышления и зрелых инженерных практик, где CI/CD — уже норма, лидерство в поставке перестаёт быть вспомогательной функцией. Эта статья — о том, как меняется суть роли, почему Scrum становится слишком узким, и почему переход к модели ADM может стать следующим логичным шагом для тех, кто давно перерос рамки agile 101.
Никто не любит очереди и ожидания. Мы не любим стоять в очередях и ещё больше не любим лезущих вне очереди. Сверхэффективный ад порой представляют как бесконечную, зацикленную саму на себе очередь... В конце концов, что есть символ неизбывной печали и тоски, как не Хатико.
Знаете, кто ещё больше не любит ожидания? Бизнес. Бизнес очень не любит, когда ожидания копят важные проекты и инициативы. Согласно исследованиям средняя эффективность потока в Delivery составляет 35%, а всё остальное время - задачи ждут. (Данные на основе опросов специалистов — ссылка. Метаанализ тысяч workflow от Nave - ссылка ) Справедливо, что ключевая точка роста для ускорения поставки — уменьшение ожиданий.
Именно об этих "фантастических" ожиданиях и пойдёт речь в статье. Я расскажу о системной работе с блокировками и зависимостями, которые повинны в значительном количестве задержек. Мы погрузимся в необходимую теорию, рассмотрим наш успешный практический кейс в hh.ru и, что особенно ценно, я поделюсь конкретными пошаговыми инструкциями по настройке Jira & n8n, а также способами работать с визуализацией блокеров в удобных плагинах, чтобы вы могли применить этот подход у себя.
Этот материал будет полезен IT-менеджерам, тимлидам, руководителям проектов, delivery менеджерам и руководителям функций — всем, кто стремится более осознанно и эффективно распоряжаться временем и ресурсами.
Я провел небольшое исследование и выявил основные проблемы основные проблемы с которыми сталкиваются Джуны (новички) в 1С.
Основные проблемы джунов (новичков) в 1С.
Технические сложности
Начинающие пользователи 1С сталкиваются с широким спектром технических проблем, которые могут серьезно затруднить процесс обучения. Одной из самых распространенных является сама сложность изучения и понимания специфики 1С, поскольку это уникальная платформа разработки с собственной логикой и особенностями.
Пользователи часто сталкиваются с ошибками информационных баз, когда база не открывается ни в пользовательском режиме, ни в конфигураторе. Это может быть вызвано проблемами с временными файлами или физической целостностью базы данных.
Также распространены ошибки формата потока, недостаточности памяти и проблемы с доступом к системе.
Концептуальные трудности
Как показывает практика, неверное понимание структуры данных является одной из основных ошибок начинающих программистов 1С. Каждая система 1С имеет свою структуру данных, которая является основой для всей работы программы, и недопонимание этой архитектуры приводит к серьезным проблемам в разработке.
Джуны (Новички) часто делают запросы в циклах и обращения через точку, что является грубой ошибкой с точки зрения производительности.
Рассмотрим на примере:
Конструкция типа “Пока Выборка.Следующий() Цикл А = Выборка.Ссылка.Договор;” создает неявные запросы в каждой итерации цикла.
Бизнес-процессы и контекст
Привет, Хабр! Меня зовут Алексей Панаэтов, я технический лидер Центра геосервисов в МТС Web Services. Каждый руководитель рано или поздно задается вопросом о количественной оценке эффективности команды. Метрики помогают принимать решения объективно, но их очень сложно строить, когда в работе активно используются множества разных инструментов: трекеры задач, системы контроля версии, корпоративный мессенджер и другие. К ним нужно сначала получить доступ, затем выгрузить и обработать нужные данные. Ad-hoc-методы вроде csv-файлов и таблиц Excel подходят для разового анализа, но их тяжело поддерживать.
Я тоже столкнулся с этой проблемой и для ее решения создал и выложил в открытый доступ код CaptainBridge — инструмент, который помогает собирать и строить метрики эффективности команды.
Казалось бы, сторипоинты это уже старая тема и все уже давно разобрались что это такое и как это работает. Так я думала, но сейчас регулярно сталкиваюсь с тем что сторипоинты понимают некорректно и используют себе во вред.
Так что решилась написать максимально прикладную (приложу все усилия) статью про то что это такое, какие есть недостатки, ошибки в использовании, и как же это всё внедрить (если они реально вам подходят).
Всем привет) Я - Саша Зебелева, налаживаю процессы в IT командах.
Регулярно пишу в свой канал про жизнь и работу. Заходите на огонек 🔥
Здесь могло быть долгое вступление о том, почему круто смотреть сериалы в оригинале. Но вы и так всё знаете. Давайте сразу к делу.
Если ваш английский - 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 для масштабирования команд разработки.
