Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 30
Люди уходят не от сложных задач, а от задач, в которых нельзя победить.
Меня такие задачи не очень беспокоят. Уже нарастил и чуйку и толстокожесть.
Единственное что меня взбесило из недавнего: большое кол-во недокументированных шрамов (понравился мне термин - особых случаев, патчей где их причина утеряна), что потребовало длительной отладки и стабилизации после рефакторинга. Получается, какой-то непрофессионализм с моей стороны, хотя задача действительно сложная, но все капканы хорошо скрыты.
Те же яйца что в статье, вид сбоку. Но к таким проблемами я был не готов.
Кстати, в оценку можете добавить мой чек-лист (у меня более абстрактный, видимо)
То есть вы в итоге смогли сформировать рабочий DoR. Это здорово когда скрам начинает действительно работать, а не просто отнимать время на ритуалы никому ненужные.
Не совсем так. DoR говорит да или нет, прошла ли задача чеклист. КТЗ дает число, с которым можно работать - сравнивать задачи между собой, считать среднее по спринту, находить паттерны по источникам. Когда у тебя есть данные, которые показывают что задачи от одного заказчика стабильно набирают 4-5 - разговор с ним строится на цифрах, а не на ощущениях.
Ещё для полноты картины коэффициент токсичности клиента нужен.
За пол года на 10%
Нигде не упомянуто количество сотрудников. Надо было и это придумать для достоверности.
Например из полгода из 1000 человек ушло за пол года 500, а за прошлые пол года 600 (10% же). Или за пол года из отдела из 5 человек ушло 2.5 человека, что на 10% меньше чем ранее.
Без относительно текста статьи. Хотя и текст как то очень… LLM писала 100%В общем, сдается мне что все высосано из пальца (того промта для LLM).
Просто статья - реклама т канала.
Средняя численность команды по внедрению систем - 15 человек. Раньше текучка составляла 4-5 человек за полгода, сейчас 1-2. Черновик готовился с помощью ИИ, ситуации и цифры из реального опыта.
фига у вас текучка
Средняя численность команды по внедрению систем - 15 человек. Раньше текучка составляла 4-5 человек за полгода, сейчас 1-2.
50% за пол года!!! Я просто не представляю что за работа тогда. Но, сваливать все на то что “вот тут стали оценивать задачи” - это как то странно.
А раньше, без вопросов к LLM что не понятно было что “эта задача так себе”, а это норм?
В заказной разработке никуда не деться от “так себе задач”. Рутина
Ровно вчера ругался, что достал принцип заказчика “мы ТЗ особо не смотрели, вы сделайте, а мы посмотрим на результат и скажем устраивает или нет”.
А по поводу текучки… (у меня так часто не уходят) Пол года назад искал нового сотрудника. Так вот ситуация на рынке труда (по собеседования) - полная стагнация. Все на собеседовании, как причина поиска работы: “я уже не работаю” или “там где работаю контора загибается”
Если 2 года назад на собеседованиях (искал сотрудника) было “я хочу попробовать что то новое”, то сейчас все держатся за работу.
Раньше текучка составляла 4-5 человек за полгода, сейчас 1-2.
Скорее всего не “мы тут LMM привлекли к оценке задач”, а объективная ситуация на рынке труда.
Черновик готовился с помощью ИИ
Очень бросается в глаза и вызывает протест вида “я тут это читаю 5 минут, что LLM нарисовала за 5 сек”.
Про рынок труда - справедливое замечание, фактор есть и его нельзя игнорировать. Но у нас изменения начались раньше чем рынок просел, так что списать только на это не получается.
Про то что «эта задача так себе» - интуитивно да, было понятно и раньше. Но когда задач много и сроки сжатые, не всегда есть время остановиться и оценить каждую. КТЗ делает это быстро и дает язык для разговора с заказчиком - конкретные цифры и вопросы.
Принцип "вы сделайте, мы посмотрим" который вы описываете - это туманность требований и конфликт владельцев в одном флаконе, КТЗ = 3 минимум. Очень узнаваемо.
Интересно, что КТЗ решает именно ту проблему, которую NASA-TLX не закрывает — оценку до, а не после. Но есть ещё один угол: NASA-TLX измеряет субъективное ощущение нагрузки конкретного человека, а КТЗ — объективные свойства задачи. Это значит, что одна и та же задача с КТЗ=4 у джуна и у сеньора даст разный NASA-TLX. КТЗ не учитывает исполнителя — и это одновременно его сила (метрика не зависит от личности) и слабость (не учитывает, что одинаково токсичная задача выжигает разных людей по-разному). Короче, странная вся эта система.
Верно подмечено. КТЗ намеренно не учитывает исполнителя, это сделано чтобы метрика работала на уровне процесса. Но ваше замечание про разное выгорание справедливое. КТЗ говорит, что задача токсична, но не говорит насколько токсична для конкретного исполнителя. Это следующий уровень, но я над этим еще не работал.
Прикольный подход. Спасибо.
Спасибо!!!
Уже сегодня пригодилось. Даже раньше, чем дочитал. С пелёночного детства не помню такого.
ИМХО, как бизнес/системный аналитик -
если задача сформулирована туманна - задача не сформулирована, делаем другие задачи.
если есть два бизнес требователя, идем ко одному, потому к другому, потом говорим с обоими в одной переговорке , пока не договорится - задачи нет, делаем другие задачи.
если не договариваются а дерутся, задачи нет, делаем другие задачи.
на уровне перехода задачи от меня к тех лиду - возможно обсуждение бизнес причуд, на уровне перехода к программисту - задача идущая в работу - один требователь однозначная формулировка.
Нанимайте хороших бизнес/системных аналитиков, и дайте им полномочия.
это не задачи у тебя плохие а аналитика хорошего не было.
Согласен, хороший аналитик снимает эти проблемы до старта. КТЗ не замена качественной аналитике, это страховка там где процесс не идеален. В крупных организациях аналитик часто есть, но полномочий у него недостаточно. Или задачи прилетают мимо него напрямую от стейкхолдеров высокого уровня.
А аналитик в спринт не вхож? Или вы планируете только команду разработки без аналитика, а аналитик работает без спринта и поэтому у него есть возможность брать задачи из общего бэклога?
П.с. интересный кейс, прогоню завтра свои задачи)
Аналитик в спринте есть. Но в крупных организациях, с которыми мы работаем, задачи часто прилетают уже с дедлайном, аналитик физически не успевает проработать их до планирования. КТЗ как раз помогает быстро отсечь то, что в текущем виде брать не стоит. Дальше уже переговоры с заказчиком на основе фактуры, а не ощущений.
Удачи с прогоном - пишите что получилось.
То, что описано в статье - результат некачественной работы бизнес-аналитика, системного аналитика и руководящего разработкой.
Они за свою работу получают зарплату, но мы им оставим роль генераторов бутафории, свалим их работу на программиста и повысим степень его ублажения. Гениальное организационное решение (нет).
Задачи от одного конкретного заказчика стабильно набирали 4–5. Не потому что он плохой, а потому что у него не было этапа проработки требований.
А проработка требований это точно обязанности заказчика?
КТЗ штука прикольная, но не решает проблему непонятных контактных требований. Там дедлайн никуда не подвинуть, даже если ничего не понятно, часто надо самому придумать решение, обычно это делают лиды, аналитики и немного архитектор).
Непонятен ваш флоу. У нас одного взгляда не такую задачу достаточно, чтобы разработчик престо перекинул на аналитику. Понятно, что все аналитики на входе проработать и вникнуть не успевают, но если нужна аналитика - не нужно считать ктз, надо отправить задачу БА/СА.
Повторюсь, КТЗ не решает проблему непонятных требований, он помогает ее увидеть системно. Когда разработчик перекидывает задачу аналитику, это разовое решение. Но если задачи от одного источника стабильно набирают 4-5, это уже сигнал не про конкретную задачу, а про системный процесс на стороне заказчика. Вот тут КТЗ дает фактуру для разговора на уровень выше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Коэффициент токсичности задачи: как одна метрика снизила текучку в команде до 10%