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

Question

[Griboks]

Добрый день.

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

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

Comments

[Ankhena]

А оно не говорящее? Или не понимающее человеческих слов?

Т.е. идёте и разговариваете.

[Griboks]

Ankhena, Вы предлагаете пойти и поучить моего руководителя правильно руководить мной? Я боюсь, что это не самый надёжный план.

[Deita]

Griboks, зря вы так обычно такие походы заканчиваются повышением если не будете скромничать и бояться

[mletov]

Griboks

Классика)))

Сам несколько раз получал недоформулированные задачи, а в ответ на уточняющие вопросы слышал, что библиотека/фреймворк/еще какой-нибудь волшебный инструмент сами сделают как надо.

Например, если использовать bootstrap, а не верстать с нуля, то макет не нужен и об адаптивности заботиться и обсуждать поведение на разных разрешениях не нужно - bootstrap автоматом сделает красиво и удобно и т д.

[shurshur]

У проекта/продукта в любом случае должен быть Project Manager и/или Product Owner, который и должен заниматься формированием требований, установкой приоритетов, написанием ТЗ, роудмапов, оценкой ресурсов, контролем исполнения итд итп. Да, он может консультироваться с разработчиками (и вообще не обязан сам уметь программировать), но важные решения по жизненному циклу разработки принимает он самостоятельно.

И у разработчиков в любом случае должен быть Team Lead, который должен принимать фундаментальные решения и иметь последнее слово в случае неопределённых ситуаций.

Если кучка равноправных разработчиков получае задание в форме "сделать хорошо" от директора Департамента Тысяч Очешуительных Решений в Области Импортозамещения, а дальше как-то вынуждена договариваться (или, наоборот, рвёт друг другу волосы в невозможности достичь консенсуса), то это к слову agile не имеет никакого отношения.

[Griboks]

shurshur, у начальства понимание agile другое: пусть ко мне приходят с 1000 гениальных идей, а буду выбирать лучшие.

[Ankhena]

Griboks,

Вы предлагаете пойти и поучить моего руководителя правильно руководить мной?

вы сами и так собираетесь это сделать.

Только вместо конструктива в виде слов и аргументов, хотите использовать какие-то "намеки".

Если вы понимаете, что для повышения эффективности или вообще для выполнения работы нужно что-то (добавить, убрать, изменить), то самое разумное это сказать об этом. Ну либо оставить всё как есть.

Answer 1

[Василий Банников]

1. Agile - это про то что люди должны договариваться. По тому надо не намёки делать, а говорить прямо и предметно.

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

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

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

Comments

[Griboks]

Приведу пример. В моей компании был продукт (назовём его, Y-мессенджер). Мою команду (я рядовой сотрудник) поставили на модернизацию этого продукта до следующей версии.

Через год на демонстрации результатов моя команда не то, что хотя бы MVP новой версии показала, но и каким-то образом умудрилась сломать старую версию (весте с бэком), сделав многомиллионный кирпич.

Лично я думаю, это всё произошло потому, что начальство разговаривает в духе: "Нам нужно превзойти телегу - делайте, у вас полная свобода." Но как бы полная свобода предполагает ещё и остальной управленческий stuff (как полномочия, премии, подчинённые). А карточек сверху как не было, так и нет по сей день.

Как мне корректно выразить мнение, что они некомпетентные дебилы?

[Василий Банников]

Griboks, ну вообще "у вас полная свобода" подразумевает, что как раз вы, как команда разработки, и должны сформировать какой-то roadmap по фичам.

Раз план - "превзойти телегу", то я бы начинал с декомпозиции по фичам, что вообще в телеге есть и как работает, как устроена наша "старая" версия, и как вообще телегу можно превзойти. Далее уже пошёл бы MVP.

[Griboks]

Василий Банников, вы полагаете, что всеми этими вопросами должен заниматься рядовые разработчики? А если они не смогут договорится или решат исключить супер мега важную для бизнеса функцию вроде историй, то кто будет отвечать?

[Василий Банников]

Griboks, я не знаю, какая конкретно у вас ситуация. Возможно руководство не считает вас за простых рядовых разработчиков - по этому и нужно договариваться, чтобы не было разночтений.

[Михаил Ливач]

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

Griboks, это решается элементарно:
Сначала составляете список фич, которые есть в телеграм и отсутствуют в Y-мессенджере. Показываете его руководству и говорите, что его необходимо утвердить, а также выставить приоритеты ( в каком порядке фичи реализовывать).
И далее по аналогии - любая вещь, доступная пониманию руководства (UI, например), утверждается руководством. Это ответственность руководителя. А детали реализации можно не утверждать, если это не требует каких-то затрат. Примеры:
"я решил заменить пакет X на пакет Y, или обновить версию пакета Z" - руководство в этом не смыслит, поэтому не может нести ответственность за такие решения;
"я решил, что нам надо использовать сервис X ( например, отдельная СУБД), это требует закупки серверов" - с этим уже к руководству.

Можете попробовать почитать должностные инструкции, чтобы понять, кто что обязан делать. Я зачастую сам пишу формулировки тасков вместо менеджеров - потому что менеджеры не соображают и не хотят соображать, их KPI от этого не зависят. Не особо кофмортно, но пока ситуацию менять не намерен.

[Панфилий]

Здесь как раз некомпетенстность разработчиков, которые хотят только тикеты закрывать и не нести ответственность за результат. Если непонятна постановка задачи, то это надо обсуждать на старте, а не сетовать на финише.

Answer 2

[Сергей Соловьев]

им всё равно нужно самостоятельно планировать работу и отвечать за неё?

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

Если есть JIRA таски и что-то не понятно, то возвращайте и говорите, чтобы уточнили эти моменты.
Лично я НЕ сторонник подхода, когда разработчику дают полностью готовую задачу и он должен только постучать по клавишам, чтобы это все закодировать. В вашем случае, получается, что разработчик такой же стекхолдер, он тоже участвует в развитии продукта, а не просто маленькая шестеренка.

Comments

[Griboks]

Проблема в том, что jira есть, а задач нет. И совсем не понятно, кто их должен планировать и назначать им исполнителей. Если этим буду заниматься я, то рискую получить по голове за 0 коммитов в месяц. Или как тогда получить от начальство соответствующие полномочия?

[Сергей Соловьев]

Griboks,
1. Иди к начальству с глупым видом и спроси "а что мне делать"
2. Они, как самые умные, начнут распинаться
3. Запиши все дословно и перенеси в джиру
4. Реализуй все так как они хотят
5. Когда получишь по шапке скажи, что сделал все дословно

2 исхода:
- Они поймут, что задачи надо объяснять почетче и исправятся
- Ничего не поймут, сделают тебя крайним.

Второе - это красный флаг плохого начальника. К сожалению, это исправить трудно будет. Что делать дальше - решай сам

[Griboks]

Сергей Соловьев, спасибо за совет.

Я так уже пробовал. Проблема в том, что начальство говорит слишком абстрактно, долго и в формате совещаний.
- Что делать?
- Мессенджер вроде телеги, только лучше.
- Какие функции должны быть? Какие требования?
- Всё, что в телеге, только импортозаместительно.
- С чего начать?
- С сообщений.

В итоге через месяц запрогал голый tcp echo сервер. Всё норм, всех всё устроило. Только вот чувство распила бюджета (без моей доли) осталось сильное...

[Сергей Соловьев]

Griboks, как говорил Джоэл Спольски - "во главе успешных IT компаний стоят сами программисты" (или как-то так). Короче говоря, скоро деньги закончатся и бизнес падет.
Тут 2 варианта:
- Подыскивать новую работы
- Остаться и пилить бюджет

Горбатого могила исправит, как говорится.

[Drno]

Griboks, после вот этого - "импортозаместительно" - должно появится понимание, что никакого конечного продукта в релиз не будет, в 99% случаев...
работа идет ради "работы" и распила))

А вообще - мне понравилась идея с "записать и сделать как сказали". Я бы еще это записал на диктофон. Чтобы потом, когда начнется разбирательство, было что противопоставить.

Нет задач - сидите на ютубе. Либо пишите докладную, что требуются такие то позиции в команде (тех лид, итд итп) и их надо назначить. Тогда уже будет не Ваша проблема продумывать задания..

[mayton2019]

Из недостатков - я-бы отметил - микроменеджмент тасок в JIRA. Бывают такие бизнес-владельцы которые
любят влезть тректинг часов и минут и могут очень долго долбать специалистов отчетами вроде
что было сделано за вторую половину пятницы и т.п.

Это конечно сильно стрессит. Но с другой стороны можно и бизнесу забить баки созданием
Spikes, Investigations e.t.c. и прочими задачами которые все равно никто не знает как оценивать
а вы будете это время тратить просто на чтение интернета. И честно логгировать типа - искал
как согласовать два разных протокола на базе имеющейся платформы и библиотек.

[Панфилий]

Drno, разработчик не в состоянии завести тикет в джире?
в команде нет аналитиков (бизнес и системных), чтобы подготовить описание ?
где продакт/проджект в конце концов с его видением и описанием продукта?

Answer 3

[mayton2019]

Agile не запрещает вам самим писать и согласовывать ТЗ. Для этого есть процедуры типа Груминг и прочее.

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

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

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

Comments

[Griboks]

Как намекнуть начальству, что они должны писать user story?

[mayton2019]

Увы. Дружище Грибокс. Здесь я не помошник. Это уже не инженерный вопрос.
А обще-человеческий. Я-бы сказал - слишком человеческий.

Ну распей с ним бутылку коньяка что-ли.

[Saboteur]

Griboks, намекните начальству, что вам нужен архитектор и бизнес аналитик, которые будут расписывать задачи в джирах

[Артем Воронов]

Не намекать надо, а напрямую говорить что конкретно необходимо.
А дальше все упрется в осознанность самого руководителя. Если оне не валенок, то переработает процессы постановки задач, hands-off сессии, refinements и прочии сессии. Если же задачи спускается именно в духе "сделайте аналоги телеги, а остальнео не волнует", то стоит просто искать другую работу, ловить в этом проекте нечего.

Answer 4

[dapi]

Добрый день!

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

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

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

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

Понимаю вас )

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

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

Это беспроигрышный шаг которые вас поднимает на ступеньку выше в профессиональном плане.

Answer 5

[Zephyroche]

Исходя из ваших ответов и комментариев, очевидным выходом будет сменить работу и не пытаться что-то кому-то объяснить или намекнуть

Answer 6

[mosurov]

Вы не пробовали прямо об этом сказать вашему начальству? У меня похожая ситуация на протяжении года бился за новый тех процесс и вот вчера вернулся с командировки презентовал разложив по полочка все проблемы принятого подхода к разработки с "бирюзовой командой", в которой бирюзовость не работала из за того что команда в большинстве своем джуны и миддлы, и выполнять работу не только разработчика, а бирюза отлично работает в небольших командах с разработчикам минимум синьор, но это не означает что например разработчик должен выполнять работу бизнес-аналитика или дизайнера. Сейчас все меняется. С понедельника внедряется новый процесс на основе ajile. Если кратко - процесс разбит на 4 группы - бизнес задачи, дизайн задачи, технические задачи( шаблоны и компоненты), прикладные задачи. Каждая группа имеет свою иерархию и контроль, закрепленный за конкретным человеком(есть планы перейти с Жира на Кайтен). Каждому участнику команды расписаны конкретный перечень задач.
Если руководство не услышит я бы на вашем месте последовал рекомендации Zephyroche полностью с ним согласен

Comments

[Griboks]

Интересная история. Не могли бы вы поделиться презентацией или выжимкой? Проблема не в том, что начальство не хочет менять процессы. Проблема в том, что начальство не хочет выполнять дополнительную работу, если и так всё (плохо) работает.

Answer 7

[Саня Технадзор]

Never complain, never explain!

Answer 8

[MisterBirkin]

Первы раз слышу, что agile исключает ТЗ. Да всмылсе. Поставновка задачи должна быть формализована обязательно иначе "мы друг дуга не верно поняли". Мы работаем c agile в WEEEK, там же храним шаблоны ТЗ и инструкции, как поставить задачу разработчикам. Есть менеджер и техлид, коорыйе этот процесс модерируюти начинают декомпозицию только после корректно поставленой задачи с ТЗ