BACKLOG НА 3 ГОДА: КАК 90% ЗАДАЧ ОТСЕЯЛИСЬ ДО РАЗРАБОТКИ

[bromium]

Не понял, описана просто база, то, что было «до» — это просто разгильдяйство.

Это стандратная практика — имитировать бурную деятельность, говорить «мы завалены задачами», хотя по факту это было не так. Зато удобно чуть что свалить на «много задач» , «не хватает рук».

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

Прилетала задача от CEO - все бросали всё.

Ну да, и скорее всего сел не говорил бросать все. Он хотел, чтобы задачу взяли в работу — запланировали, дали бы оценки, назвали срок выполнения. Но в хаосе лучше лебезить перед тем кто выше и потом при люблм удобном случае, когда директора рангом ниже спрашивали «ну как там моя задача» многозначительно говорить «нам САМ поставли задачу, делаем его, потом вернемся к твои»

Считать capacity, акутализировать бэклог, планировать спринт — это БАЗА процесса разработки, которая просто не делалась, а имитировалась бурная деятельность.

пиэма не было, а потом, видимо, его наняли. Видимо, судя по статье, автора, который сделал необходимый минимум базовых вещей.

но по статье есть вопросы все же:

Каждую задачу оценивали в часах в три этапа: сначала аналитик, потом разработчик, потом архитектор.

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

После релиза считали, сколько оценочных часов реально дошло до пользователей - это и была фактическая ёмкость

Что такое «оценочные часы дошли до пользователей»? Сделали задач на 40 часов, задеплоили — но юзеры стали пользоваться только доработками на 20 часов, так что ли? Не понятно, нужны пояснения

Отдельно смотрели точность плана: какой процент обещанного вышел в срок. Первое нужно для расчёта backlog, второе - для оценки предсказуемости команды.

Что значит процент общеанного в срок? Есть три задачи, выполнили 2 (одна на 3 часа, другая на 2 часа, а не выполненная на 30 часов) — каков процент обещанного? И как это используется для бэклога и оценки предсказуемости? Несделанное возвращаете в бэклог а оттуда в новый спринт — дык, это тоже база.

Для каждой системы определили одного человека: не "кто использует", а "кто отвечает за то, как система работает". Это дало точку ответственности для каждого входящего запроса.

Звучит красиво на словах, а на деле — прилетело три запроса от разных директоров депратаментов, все они, например, в ранге вице-перзидента или зама гендира — кого первым возьмете, кого в последнюю очередь, если все трое просят срочно и сразу?

Далее на схеме:

Если нет оценки и владельца вернуть инициатору

Не понял, как инициатор может дать оценку? Оценку дает разработка.

Далее:

Зафиксировали правило: 50% рабочего времени разработчик тратит на создание нового. Остальное - исправление ошибок, технический долг, переключения.

Это все здорово, но что если выяснилось, что в стсьеме накопилось куча багов, многие из них коитические и на их фикс нужно…. А фиг знает сколько нужно, но часов 300 точно — что будете дедать со своим правилом?

Да, и добавлю: это прекрасно, когда делаешь типовые задачи и можно давать оценку, особенно багам — баг на то и есть баг, что пока не понятно, как его испавлять и сколько времени на это нужно. Как будете планировать загрузку клманды тогда? Заплагировали что 160 часов на разработку остальное на три бага — но неделя прошла а еще даже один не пофиксили?

Привыкли к тому, что сроки - разговор ни о чём.

Ну да, потому что был бардак, потому что ИБД — все пипец как заняты, только никто не может сказать чем и плчему это важно

Три месяца. Не три года.

Ха-ха. Видимо скоро придет сео и скажет, что команду надо бы прдсократить. Зачем кормить лишние рты.

Изменилось другое: компания начала выбирать, что делать, и прекратила делать то, что не нужно

То ли плакать, то ли смеяться. А зачем деалли то, что не нужно? Ибд? Прям как в госконторах. Кто то сильно ездил сео по ушам

Нет культуры отказа. Если руководители не готовы говорить "нет" на запросы сверху, BP-фильтр перегружается исключениями. Всё "срочное" попадает в обход правил.

Не понял, а азчем отказывать? Если есть что то срочное, то инициатор срочного должен определить или согласовать, что выбрасываем из спринта / ближайшего плана. Если это сам сео — пусть и скажет, определится с другими постановщиками задач, если не сео — то пусть с другими департаментами договорится, чья задача «срочнее». это уже не проблема отдела разработки.

Просто руководитель разработки был либо тюфяк либо, скорее всего, прожженный конъюнктурщик («а семь шапок сможешь? — да не вопрос!»)

Одно исключение от CEO - и модель начинает разрушаться.

Значит хреновая у вас модель. И чуть что всегда можно свалить на сео. Дескать, он не знал текущих приоритетов.

я же убежден, нормадьная модель не разрушится от такого, а как надо действовать — написал выше. И не стесняться сообщать сео текущую ситуацию а не подобострастно поддакивать(«а то вдруг скажу нет и уволят нафиг»)

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

Это вы переоткрыли заново основы теории менеджмента, проектный треугольник и иже с ним.

Методика была простой, но требовала дисциплины.

Дык, это и есть ключевое. Это то, чем должен заниматься ПМ. Но они привыкли просиживать штаны на дейликах, «коммуницировать» (сиречь балаболить не по делу) и чуть что — спихивать все на команду разработки. А как попросишь capacity посчитать — тут же садятся в лужу. От какой «высшей математике» как риск-менеджмент вообще умолчу.

В общем, статья хорошая, показательная. Жаль, что такие вещи, что должно быть само собой разумеющимся, часто не делаются — лень, некомпетентность, отсутствие дисциплины.

[jWarlon]

bromium, конструктивный разбор - отвечу по существу.

“База, которая не делалась” - согласен и не спорю. Именно это и есть кейс. Если бы база делалась - статьи не было бы. Но такое вижу почти везде, где ИТ прикладное.

По методике.

Оценка аналитиком и архитектором - не трудоёмкость разработчика, а два дополнительных угла: полнота задачи и архитектурные зависимости. Расхождение в оценке = стороны по-разному понимают задачу. Сначала договариваются, потом считают часы. Это снимало переделки.

“Оценочные часы дошли до пользователей” - суммарная оценка задач, закрытых в релиз. Velocity по плановым часам, не по факту потраченного времени.

Три вице-президента “срочно” - ИТ не арбитр. По принятым правилам - комитет. С записью: вот что вытесняет вот что и почему.

300 часов багов - capacity под новое пересчитывается, заказчиков не просто уведомляют о сроках, а фактически согласовывают их с ними. Прозрачность лучше, чем тихий перенос.

По директору разработки - 50 на 50 с “гнать в шею”. Система без правил воспроизводит ровно такое поведение у компетентных людей. Это адаптация к стимулам, не к несуществующим правилам. Персональный вердикт здесь неточный. Да и не все умеют объяснить ситуацию на языке бизнеса.

По CEO - вы правы в основном. Нормальная модель не “защищается” от CEO, а даёт ему прозрачность. В статье сформулировал неточно. Разрушает не исключение само по себе, а ситуация, когда CEO ставит задачу в обход системы и не видит, что вытесняет. Если видит и сознательно выбирает - это приоритет, не поломка.