Как намекнуть начальству, что agile не избавляет от тз?

Добрый день.

Как дать начальству понять, что они могут хоть 100 jira себе установить, хоть 200 совещаний в день провести, но им всё равно нужно самостоятельно планировать работу и отвечать за неё?

Они почему-то думают, что, когда загоняешь разрабов в тасктрекер, то они сами себе будут ставить задачи и сами их выполнять, магическим образом создавать нужный (но неизвестный и не спланированный) продукт. А чтобы корректировать курс, почему-то проводят кучу совещаний, вместо минимального тз или тупо списка требований.
  • Вопрос задан
  • 4368 просмотров
Пригласить эксперта
Ответы на вопрос 7
vabka
@vabka
Токсичный шарпист
1. Agile - это про то что люди должны договариваться. По тому надо не намёки делать, а говорить прямо и предметно.

2. Вот вы говорите, что вам нужно ТЗ. А зачем вам оно нужно?
Вам не понятна та постановка, которая описывается в карточках?
Есть неоднозначность?
Уже есть примеры, когда от этой неоднозначности пострадал продукт (например из-за необходимости переделывать)?

Или вам нужно не ТЗ, а виденье того, чем в итоге должен стать продукт?
Не понятно, для чего вообще все эти карточки перекладываются?
Если так, то, вероятно, вам нужно не ТЗ, а какие-то OKR-ы, чтобы можно было от них отталкиваться при составлении задач.

Возможно, произошла мискоммуникация между вами и заказчиком. Возможно, заказчик действительно ожидает от вас (команды) самостоятельности при составлении задач - по сути сочетание в себе и менеджера и аналитика.
Это нормально, но нужно этот момент тоже прояснить.
Ответ написан
AshBlade
@AshBlade
Просто хочу быть счастливым
им всё равно нужно самостоятельно планировать работу и отвечать за неё?

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

Если есть JIRA таски и что-то не понятно, то возвращайте и говорите, чтобы уточнили эти моменты.
Лично я НЕ сторонник подхода, когда разработчику дают полностью готовую задачу и он должен только постучать по клавишам, чтобы это все закодировать. В вашем случае, получается, что разработчик такой же стекхолдер, он тоже участвует в развитии продукта, а не просто маленькая шестеренка.
Ответ написан
mayton2019
@mayton2019
Bigdata Engineer
Agile не запрещает вам самим писать и согласовывать ТЗ. Для этого есть процедуры типа Груминг и прочее.

Темпы современной разработки не то чтобы отменяют ТЗ а делают его просто сильно быстро неактуальным
документом в силу того что бизнес очень быстро меняется
. Поэтому пишите User Stories. Это и будет
ваше основание для разработки. Пишите много. Добавляйте линки на Confluence.

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

Тоесть в самом agile нет ничего контр-продуктивного или вредящего. Agile - это про гибкость.
А вот для кого по настоящему agile может быть плох - так это для бесполезного специалиста в команде
которые никакой полезной работы не делает. Он пару спринтов побегает. Посимулирует активность
и потом будет удален из команды т.к. задач для него не будет.
Ответ написан
dapi
@dapi
Добрый день!

27 лет в разработке IT. Исполнял роль разработчика, техлида, архитектора, владельца продукта, техдира, владельца бизнеса. Отвечу из своего опыта.

> Как дать начальству понять, что они могут хоть 100 jira себе установить, хоть 200 совещаний в день провести, но им всё равно нужно самостоятельно планировать работу и отвечать за неё?

1. Подготовить презентацию. Главное сконцентрироваться не на том что "так не пойдет", а на том что вы предлагаете. Покажите проблему и ваше решение. Отсюда будет видно насколько вы понимаете суть проблемы которую начальство пытается решить и поделитесь вашим предложением. Не отчаивайтесь если его не примут сразу или не примут вообще, это нормально. Если вы покажете что понимаете суть проблемы, готовые взяться за ее решение и у вас есть понятный план, то ваши шансы достаточно велики. Под проблемой я имею виду то что "100 jira не приводит к решению задач"
2. Планировать работу самостоятельно, делегировать или не планировать, это руководство решит само. Я как руководитель вполне могу вообще ничего не планировать, а только убедиться в том что моя идея и цель донесена и понята соответствующими лицами и дальше мониторить происходящее. Например если я хочу чтобы мои подчиненные выросли и научились самостоятельно планировать.
3. Начальство в любом случае отвечает за работу и ее результаты. Но у него есть разные рычаги как влиять на результат. Один из рычагов это сменить исполнителей.
4. Если считаете что начальство не выполняет свои функции, скажите ему об этом (пункт 1) если вы считаете что ничего не изменилось эскалируйте вопрос далее (к начальству начальства). Для начала выясните какие функции у вашего начальства. Вполне возможно что в вашей компании составление ТЗ это функция разработчика (и это нормально).

> Они почему-то думают, что, когда загоняешь разрабов в тасктрекер, то они сами себе будут ставить задачи и сами их выполнять, магическим образом создавать нужный (но неизвестный и не спланированный) продукт.

Понимаю вас )

> А чтобы корректировать курс, почему-то проводят кучу совещаний, вместо минимального тз или тупо списка требований.

Возьмите на себя составление ТЗ. Научитесь это делать. Это поможет вам вырости как профессионал. Даже если к вам пришли с готовым ТЗ вам, для начала, нужно его принять. А именно: убедиться что выявлены все заинтересованные лица, пройтись по функциональным и не функциональным требованиям и так далее.

Это беспроигрышный шаг которые вас поднимает на ступеньку выше в профессиональном плане.
Ответ написан
Комментировать
@Zephyroche
Исходя из ваших ответов и комментариев, очевидным выходом будет сменить работу и не пытаться что-то кому-то объяснить или намекнуть
Ответ написан
Комментировать
@mosurov
Вы не пробовали прямо об этом сказать вашему начальству? У меня похожая ситуация на протяжении года бился за новый тех процесс и вот вчера вернулся с командировки презентовал разложив по полочка все проблемы принятого подхода к разработки с "бирюзовой командой", в которой бирюзовость не работала из за того что команда в большинстве своем джуны и миддлы, и выполнять работу не только разработчика, а бирюза отлично работает в небольших командах с разработчикам минимум синьор, но это не означает что например разработчик должен выполнять работу бизнес-аналитика или дизайнера. Сейчас все меняется. С понедельника внедряется новый процесс на основе ajile. Если кратко - процесс разбит на 4 группы - бизнес задачи, дизайн задачи, технические задачи( шаблоны и компоненты), прикладные задачи. Каждая группа имеет свою иерархию и контроль, закрепленный за конкретным человеком(есть планы перейти с Жира на Кайтен). Каждому участнику команды расписаны конкретный перечень задач.
Если руководство не услышит я бы на вашем месте последовал рекомендации Zephyroche полностью с ним согласен
Ответ написан
apavlyut
@apavlyut
www.apavlyut.ru
Never complain, never explain!
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы