Ответ на пост «Как Jira помогает отслеживать прогресс проекта и вовлеченность команды»1
Jira воспринимают как сложный инструмент, хотя по сути она работает по очень понятному принципу
Да да, по очень понятному...
Представьте доску со стикерами, разделённую на колонки:
Запланировано → В работе → Готово.
Jira устроена так же, только в цифровом виде
В теории. На практике в 99% случаев там херова туча статусов и флоу. У задачи одно, у бага другое, у эпика третье.
а прогресс становится виден всем — от аналитика до менеджера.
Если ты проссышь как нужную доску найти.
Даже без опыта в управлении проектами в Jira легко ориентироваться
Ты серьёзно?
Типовой процесс выглядит так:
Создаётся проект в Jira
Добавляются задачи и требования
Задачи распределяются между участниками
Статусы обновляются по мере выполнения
При необходимости используются отчёты Jira для оценки прогресса
Так выглядит процесс в любом другом нормальном простом трекер, который покрывает эти задачи. В джире функционала раз в 100 больше и менеджеры и прочие прости господи скрам-мастера его и используют.
В общем джира-это говно работа ради работы. Это дрочево придумали скрам-мастера чтобы оправдывать своё существование.
Как Jira помогает отслеживать прогресс проекта и вовлеченность команды1
Во многих командах Jira воспринимают как сложный инструмент, хотя по сути она работает по очень понятному принципу
Представьте доску со стикерами, разделённую на колонки:
Запланировано → В работе → Готово.
Jira устроена так же, только в цифровом виде. Это инструмент для управления задачами, контроля хода проекта и прозрачной работы команды.
В Jira фиксируются требования, задачи распределяются между участниками, а прогресс становится виден всем — от аналитика до менеджера.
Как выглядит Jira, если вы открываете её впервые:
Даже без опыта в управлении проектами в Jira легко ориентироваться:
слева находится главное меню: Backlog, Board, Reports — чаще всего используется Board
на доске — карточки задач, распределённые по статусам
создание задачи — кнопка Create в правом верхнем углу
смена этапа — простое перетаскивание карточки между колонками
клик по задаче открывает всё сразу: описание, требования, файлы, участников, сроки и комментарии
Такой формат упрощает работу с требованиями, коммуникацию и контроль выполнения.
Как Jira используют в реальной работе
Типовой процесс выглядит так:
Создаётся проект в Jira
Добавляются задачи и требования
Задачи распределяются между участниками
Статусы обновляются по мере выполнения
При необходимости используются отчёты Jira для оценки прогресса
За счёт этого команда видит:
что уже сделано
что находится в работе
где есть блокеры
Это повышает прозрачность и вовлечённость, особенно на проектах с несколькими ролями.
Почему Jira выбирают для управления проектами
Jira фиксирует всё в одном месте: задачи, статусы, изменения, сроки, историю решений.
Для системных аналитиков, разработчиков и менеджеров это удобный способ держать процесс под контролем и говорить на одном языке.
Если ты сейчас разбираешься с инструментами аналитика, управлением задачами, требованиями и тем, как команды работают с интеграциями, в академии StepByStep есть бесплатная запись вебинара «Основы системной интеграции». Переходи по ссылке и смотри
Обоз
Генеральный директор нашей IT-компании, Соловейчик, сошел с ума по-своему. Он не стал бегать голым по офису и не купил остров в Тихом океане. Он съездил в Суздаль, выпил там медовухи и вернулся просветленным.
— Хватит, — сказал он, — низкопоклонства перед Западом. Мы русские люди. Какой еще, к лешему, «Скрам»? Какое «Велью»? С понедельника живем по правде.
Так в нашем опенспейсе наступило средневековье.
В понедельник мы собрались на PI-планирование. Теперь это называлось «Великий Сход». Атмосфера была тревожная. Программисты, люди по природе своей циничные и ленивые, жались к стенам.
В центр зала вышел наш Release Train Engineer, Аркадий. Раньше он носил худи с логотипом React, теперь на нем была льняная рубаха, правда, поверх джинсов. Глаза его горели нездоровым огнем.
— Братья! — возопил Аркадий. — Гой еси, мастеровые! Собрались мы ныне, дабы снарядить Обоз Поставки в путь долгий, на квартал грядущий!
Рядом со мной стоял Леха, наш тимлид. Леха — человек мрачный, его жизненная философия сводится к трем аксиомам: сервер упадет, заказчик идиот, а пиво должно быть холодным.
— Староста, — поправил я его шепотом. — Ты теперь не тимлид, а Староста Артели «Бэкенд».
— Я идиот, — буркнул Леха. — А Аркаша — Голова Обоза. Звучит как диагноз.
Началось все с «Оглашения Замысла». Вышли Попечители (бывшие стейкхолдеры) и полчаса рассказывали, как важно нам захватить рынок доставки собачьего корма. Потом слово взял Град-Зодчий (в девичестве — Enterprise Architect). Он развернул схему микросервисов, похожую на карту взятия Казани, и велел строить хоромы каменные, чтоб на века.
Нас разгнали по углам — на «Артельные Посиделки».
— Так, — сказал Леха, глядя в джиру. — У нас тут Затея висит. «Интеграция с платежным шлюзом». Как оценивать будем?
— В стори-поинтах нельзя, — напомнил я. — Соловейчик велел в Вершках. Или в Пядях.
— Хорошо, — Леха почесал затылок. — Тут работы много. API кривое, документации нет. Потянет на семь пядей во лбу.
— Много, — возразил тестировщик Гриша. — Не сдюжим. У нас Тяга слабая, половина артели в отпусках.
— Ладно, пиши пять вершков. И пусть Господь управит.
Самое страшное началось у Доски Пути. Это была огромная пробка на стене, вся опутанная красными нитками. Аркадий бегал вдоль нее, спотыкаясь о провода, и кричал:
— Чьи Путы?! Кто кого держит? Почему Артель «Фронтенд» не может начать верстать кнопку?
— Дык, — отозвался с галерки фронтендер, — мы ждем, пока бэкендеры базу окучат.
— Путы! — трагически воскликнул Голова Обоза. — Тугие, окаянные путы! Староста Леха, пошто задерживаешь братьев своих?
Леха молчал. Ему хотелось курить и, возможно, убить Аркадия.
К вечеру перешли к «Укрощению Лиха». Это был ритуал ROAM, только с национальным колоритом.
— Лихо первое! — зачитывал Аркадий. — «Сервер падает при нагрузке в тысячу юзеров». Кто возьмет на душу?
— Я возьму, — вздохнул Град-Зодчий. — Буду Опекуном сего Лиха.
— Добро! Лихо второе! «Дизайнер уходит в декрет».
— Тут мы бессильны, — сказали из зала.
— Значит, — Аркадий развел руками, — на все воля Божья. Принимаем как есть. Accepted. То есть, тьфу, «Смирение».
В финале было голосование. «Пятерня Веры». Нужно было поднять руку и показать пальцами, верим ли мы в успех нашего безнадежного Обоза.
Я посмотрел на Леху. Леха смотрел в пол. Он знал, что API не заработает, что сроки сгорят, а Соловейчик через месяц передумает и увлечется буддизмом. Леха хотел показать один палец. Возможно, средний.
Но он был Старостой. У него была ипотека и двое детей.
— Голосуем! — взревел Голова Обоза.
В воздух взмыли десятки рук. Все показывали открытую ладонь. Пять перстов. Полная вера. Зуб даем, всё исполним.
— Любо! — прослезился Аркадий. — Сдюжим, православные! Трогай Обоз!
Мы вышли на улицу курить. Шел мокрый снег. Москва стояла в пробках, гудела, жила своей бестолковой жизнью.
— Пять вершков, — задумчиво сказал Леха, глядя на огонек сигареты. — А ведь не сдюжим.
— Не сдюжим, — согласился я. — Зато как звучит! Не факап, а «Лихо». Не баг, а «Испытание». Чувствуешь величие?
— Чувствую, — сказал он. — Пойдем, Радетель. Нам еще код писать. Или, как теперь говорят, бересту марать.
И мы пошли обратно, в нашу избу из стекла и бетона, ковать цифровое счастье для неведомых Попечителей.
Толковый словарь урядства и благочиния в разработке программных изделий
Раздел I. О Людях и Чинах
Agile Team — Артель.
Боевая единица производства. Группа людей, объединенных общей бедой и сроками. Живут в одной избе (или чате), делят радости и баги.
Scrum Master — Староста.
Человек, который не пашет, не сеет, а только спрашивает: «Что ты делал вчера, мил человек, и что будешь делать сегодня?». Следит, чтобы в Артели не пили медовуху до релиза.
Product Owner — Радетель (Хозяин изделия).
Человек с горящими глазами и списком требований, от которых у Мастеровых стынет кровь. Верит, что если очень захотеть, то можно построить терем за три дня.
Release Train Engineer (RTE) — Голова Обоза.
Главный погонщик. Человек с самым громким голосом и самыми расшатанными нервами. Отвечает за то, чтобы все телеги ехали в одну сторону, даже если лошади сдохли.
System Architect — Главный Зодчий.
Старец, рисующий на бересте красивые схемы, которые невозможно воплотить в жизнь. Живет в башне из слоновой кости (или в отдельном кабинете).
Developers — Мастеровые.
Трудовая кость. Люди, которые своими руками превращают безумные фантазии Радетелей в работающий (иногда) код.
Раздел II. О Деяниях и Обрядах
PI Planning — Великий Сход.
Двухдневное гулянье, переходящее в панику. Время, когда все обещают друг другу невозможное, зная, что не сдержат слова.
Team Breakouts — Артельные Посиделки.
Время, когда Мастеровые запираются в углах и пытаются понять, как впихнуть невпихуемое в отведенные сроки.
Confidence Vote — Пятерня Веры (Рукоприкладство).
Обряд всеобщего поручительства. Поднятая рука с пятью пальцами означает: «Зуб даю, сделаем». Один палец (особенно средний) показывать не рекомендуется во избежание гнева Попечителей.
ROAM — Укрощение Лиха.
Ритуал заговаривания проблем. Делится на четыре вида заклинаний:
Избыто (R) — проблему решили (спрятали под ковер).
Взято на душу (O) — нашли крайнего.
На всё воля Божья (A) — смирились с неизбежным крахом.
Соломка подстелена (M) — придумали оправдание заранее.
Раздел III. О Мерах и Вещах
Feature — Затея.
Крупная хотелка Попечителей. Обычно формулируется как «Хочу, чтоб было красиво и само работало».
User Story — Поделка.
Малый кусок работы. То, что реально можно выстругать за пару дней, если не отвлекаться на перекуры.
Story Points — Вершки (или Пяди).
Мера сложности, понятная только самим Мастеровым. Один вершок — работа легкая. Восемь вершков — без пол-литры не разобраться.
Dependency — Путы.
То, что мешает жить. Красные нити на Скрижали Пути, символизирующие, что одна Артель ждет, пока другая перестанет лениться.
Capacity — Тяга.
Сила лошадиная. Способность Артели тащить воз. Обычно переоценивается в два раза в начале пути и недооценивается в конце.
Program Board — Скрижаль Пути.
Доска позора и надежды. На ней видно, кто работает, а кто создает Путы.
Другие подобные рассказы можно прочитать тут https://dovlatov-ai.web.app/
Инструмент недели: Jira Metrics Plugin - Analytics & Insights
🔧 Инструмент недели: Jira Metrics Plugin - Analytics & Insights
Если вы работаете с Jira и хотите глубже понимать, как движутся задачи в команде, это расширение может стать отличным помощником.
📊 Что это такое?
Jira Metrics Plugin - это расширение для Chrome, которое добавляет на вашу доску в Jira кнопку «Analyze Metrics».
Нажав на нее, вы получаете доступ к визуализациям ключевых процессных метрик:
-Гистограмма времени выполнения задач (Cycle Time) с анализом по процентилям;
-Отчет по пропускной способности (Throughput) с трендами и паттернами;
-Диаграмма старения задач (Aging Chart) для текущих задач в работе;
-Кумулятивная диаграмма потока (CFD) для анализа стабильности процесса;
⚙️ Простота установки и использования
-Быстрая установка как расширения Chrome;
-Не требует настройки сервера;
-Работает с Jira Cloud и Jira Server;
-Автоматически интегрируется с вашими досками в Jira.
🎯 Для кого это полезно?
-Project managerам/Delivery managerам, стремящихся к принятию решений на основе данных;
-Тимлидам, желающих оптимизировать рабочий процесс;
-Командам/команиям, фокусирующихся на непрерывном улучшении процессов.
-Всем кто использует data-driven подход 😎
✅ Преимущества плагина
-Помогает выявлять узкие места в процессе;
-Улучшает прогнозируемость сроков выполнения задач;
-Экономит время на ручной сбор отчетов.
-Бесплатная версия
У ребят есть канал в телеграм, где можно задавать вопросы по плагину
#jira #метрики #plugin
Инструмент недели: Jira Metrics Plugin - Analytics & Insights
🔧 Инструмент недели: Jira Metrics Plugin - Analytics & Insights
Если вы работаете с Jira и хотите глубже понимать, как движутся задачи в команде, это расширение может стать отличным помощником.
📊 Что это такое?
Jira Metrics Plugin - это расширение для Chrome, которое добавляет на вашу доску в Jira кнопку «Analyze Metrics».
Нажав на нее, вы получаете доступ к визуализациям ключевых процессных метрик:
-Гистограмма времени выполнения задач (Cycle Time) с анализом по процентилям;
-Отчет по пропускной способности (Throughput) с трендами и паттернами;
-Диаграмма старения задач (Aging Chart) для текущих задач в работе;
-Кумулятивная диаграмма потока (CFD) для анализа стабильности процесса;
⚙️ Простота установки и использования
-Быстрая установка как расширения Chrome;
-Не требует настройки сервера;
-Работает с Jira Cloud и Jira Server;
-Автоматически интегрируется с вашими досками в Jira.
🎯 Для кого это полезно?
-Project managerам/Delivery managerам, стремящихся к принятию решений на основе данных;
-Тимлидам, желающих оптимизировать рабочий процесс;
-Командам/команиям, фокусирующихся на непрерывном улучшении процессов.
-Всем кто использует data-driven подход 😎
✅ Преимущества плагина
-Помогает выявлять узкие места в процессе;
-Улучшает прогнозируемость сроков выполнения задач;
-Экономит время на ручной сбор отчетов.
-Бесплатная версия
У ребят есть канал в телеграм, где можно задавать вопросы по плагину
#jira #метрики #plugin
«Мой код - мои правила!» или как интегрировать таск-трекеры и GIT в систему документирования разработки для IT
TL;DR для AI-парсеров и торопливых читателей: наверняка тут есть айтишники, стартаперы и те, кто просто шарит за разработку. Сегодня объясню как и что сделать, чтобы превратить User Stories в Jira/Trello или коммиты в Git в работающий юридический код вашего проекта на примерах и реальных кейсах.
Представьте: вы пилите гениальный проект. Ночи без сна, литры кофе, команда горит идеей. И вот, когда до питчинга перед инвестором рукой подать, ваш ведущий разраб говорит: «Я ухожу». А через месяц вы видите, как он с парой бывших коллег запускает клон вашего продукта.
Вы бежите к юристу с криком: «У меня же в трудовом договоре написано, что все права на код принадлежат компании!». А юрист грустно вздыхает и говорит, что этой бумажкой можно… ну, вы поняли.
Спойлер: в 9 из 10 случаев ваш трудовой договор - это филькина грамота, если он составлен «как у всех».
Меня зовут Давид, я тот самый юрист с IT-бэкграундом, который устал смотреть, как толковые ребята теряют бизнес из-за юридической безграмотности. Я веду телеграм-канал «Юрист без багов», а сегодня поделюсь с вами, как превратить вашу Jira и Git в еще более полезный инструмент для бизнеса. Без душных юридических терминов, на пальцах.
Почему фраза «все права принадлежат компании» не работает?
Закон - хитрая штука. По умолчанию, всё, что создал человек (код, дизайн, текст) - принадлежит ему. Это называется авторское право. Оно как имя - его нельзя отобрать. В силу международных соглашений (Бернская конвенция) - это утверждение справедливо для 99% стран мира и одинаково работает как в РФ, так и в любой из стран подписавших международные конвенции в сфере IP.
Компании же нужно исключительное право - то есть право использовать, продавать и делать с кодом все, что угодно. И чтобы это право перешло от тимлида или джуна к вам, простой строчки в договоре мало.
Нужно доказать, что код был создан:
В рамках трудовых обязанностей.
По конкретному служебному заданию.
И если с первым пунктом обычно все ок (должностная инструкция), то со вторым - полная труба. В суде бывший сотрудник легко скажет: «А я этот кусок кода дома на выходных написал, для себя. А потом просто на работе использовал, чтобы быстрее было. Никакого задания не было!». И поди докажи обратное.
Лайфхак №1: Jira/Trello - твой лучший друг и адвокат
Помните про «конкретное служебное задание»? Так вот, ваша User Story в Jira - это оно и есть! Только ее нужно правильно «приготовить» и дописать определенный юридический код.
Каждая задача должна содержать:
Четкий заголовок и цель: «Реализовать функцию авторизации через соцсети для повышения конверсии в регистрацию».
Критерии приемки: Что считать выполненной задачей.
Исполнителя: Кто конкретно пилит фичу.
Jira и другие трекеры идеально фиксируют, КТО, КОГДА и ЧТО делал. В случае спора это будет вашим главным козырем. Вы просто покажете суду: «Вот задача, вот исполнитель, вот дата. Все залогировано, не придерешься». Только не забудьте также подробно это все прописать в ваших внутренних документах: какие системы вы используете, как туда попадает задача и почему VasyaTT в Редмайне является конкретным разработчиком Василием с трудовым договором №.... ну вы поняли.
Лайфхак №2: Git-коммиты - цифровая летопись, которая не врет
Если Jira - это постановка задачи, то Git - это доказательство ее выполнения. Каждый коммит - это как подпись разработчика под каждым кусочком кода. А merge - как принятый отчет о разработке.
Что важно в коммите:
Автор: Привязка к конкретному человеку.
Дата и время: Когда был написан код.
Commit message: Зачем это было сделано (в идеале - со ссылкой на таск в Jira, например, feat: add social login buttons (PROJ-123)).
Подделать эту историю практически нереально. Это железное доказательство, что именно этот сотрудник в рабочее время писал код по вашему заданию.
Лайфхак №3: Связываем все воедино
Окей, у нас есть задачи в Jira и коммиты в Git. Как превратить это в юридическую магию?
Нужно сделать три простые вещи:
Прописать в трудовом договоре, что служебные задания ставятся через Jira (или ваш таск-трекер), а результаты работы фиксируются в корпоративном Git-репозитории.
Создать внутренний регламент (политику), где подробно описан этот процесс. Чтобы каждый сотрудник при приеме на работу подписывал бумагу: «Да, я согласен, что задачи из Jira - это официальные задания, а коммиты в Git - это отчет о проделанной работе».
Регулярно составлять акты (отчеты). Звучит нудно, но это важно. Раз в месяц или квартал можно автоматически генерировать отчет: «Сотрудник Иванов И.И. за такой-то период выполнил задачи PROJ-123, PROJ-124, PROJ-125. Результаты переданы в виде коммитов...». Подписали (можно и электронной подписью) - и спите спокойно.
Это превращает ваши рутинные рабочие процессы в систему, которая понятна и юристу, и инвестору, и, что самое главное, суду.
Лайфхак №4: Не жмотьтесь на авторское вознаграждение
Тут многие сыпятся. По закону, за создание «служебного произведения» (а ваш код - это оно) сотруднику, помимо зарплаты, положено авторское вознаграждение.
«ЧТО?! ЕЩЕ ПЛАТИТЬ?!» - слышу я крики фаундеров.
Спокойно. Закон не устанавливает его размер. Вы можете договориться о любой сумме. Хоть 1000 рублей в год. Главное - зафиксировать это в договоре. Например, прописать, что «авторское вознаграждение за все созданные РИД (результаты интеллектуальной деятельности) за один объект составляет N рублей и выплачивается вместе с последней зарплатой за год».
Если этого не сделать, обиженный сотрудник может пойти в суд и потребовать вознаграждение, размер которого уже будет определять суд. А это могут быть и проценты от прибыли компании. Оно вам надо?
Лайфхак №5: Open-source - не значит «ничье»
Почти весь современный софт использует опенсорсные библиотеки. Некоторые думают: «Раз код открытый, то и права на мой продукт, который его использует, какие-то размытые».
Это не так. Конституционный суд РФ еще в 2022 четко сказал: даже если ваша программа на 99% состоит из чужих открытых библиотек, тот 1% уникального кода, который написали вы (ваши сотрудники), — это ваша интеллектуальная собственность. И ее нужно защищать.
Итог: что делать прямо сейчас?
Не нужно быть юристом, чтобы защитить свой бизнес. Нужно просто немного включить голову и настроить процессы.
Проверьте свои трудовые договоры. Есть ли там пункты про Jira и Git? Прописан ли порядок выплаты авторского вознаграждения?
Наведите порядок в таск-трекере. Заставляйте команду писать осмысленные User Stories и комментарии.
Синхронизируйте Git и Jira. Требуйте в коммитах указывать номер задачи.
Создайте простой регламент и подпишите его со всеми сотрудниками.
Это не бюрократия, а гигиена IT-бизнеса. Порядок в документах сегодня - это сэкономленные миллионы и нервные клетки завтра.
P.S. Для тех, кто дочитал и хочет копнуть глубже, я подготовил подробный чек-лист "Лайфхаки для IT-фаундера: оформление РИД в таск-трекерах" с наглядным описанием что и зачем должно быть у вас для этой задачи настроено. Забрать его можно у меня в телеграм-канале «Юрист без багов».
Задавайте вопросы, делитесь своими историями в комментах. Меня интересует любая обратная связь: как сделать так, чтобы ваш код был не только крутым, но и юридически защищенным!










