Под моей прошлой статьей про КТЗ – коэффициент токсичности задачи (вот она) – был комментарий, на который я сначала не обратил особого внимания. Смысл такой: все, что вы описываете – это результат некачественной работы аналитика и руководителя. Их работу свалили на программиста и назвали методом.
Неприятнее всего, что человек прав. Фиксируй договоренности, проверяй готовность задачи, не отменяй проработку требований, возвращай сырое заказчику – это азбука ремесла. Этому учат на любом курсе по управлению. Любой аналитик с опытом прочитает и скажет: спасибо, кэп.
Только через пару недель после той статьи у меня случилась история, которая показала кое-что неприятное. Я знаю все эти правила. И задача все равно вернулась трижды, хотя на входе мой собственный фильтр поставил ей низший балл.
Эта статья не про то, какие правила правильные. Их все знают. Она про то, почему правильное не делается, даже когда ты знаешь его наизусть и держишь под рукой метрику.
Третий возврат
Задача выглядела рядовой: доработать отчетную форму. На входе мы прогнали ее через фильтр. Критерий приемки? Есть, обсуждали с заказчиком на встрече. Владелец один? Один. Срок реальный? Вполне. КТЗ – единица, рабочий диапазон. В работу.
Команда сделала, показала. Заказчик вернул: «мы имели в виду другое». Ладно, бывает. Уточнили, переделали, показали снова. Вернул второй раз: «а где выгрузка за период, мы же это обсуждали».
Открываю переписку. Ищу обсуждение выгрузки. Его нет. Ни в письмах, ни в протоколах, нигде. Обсуждали, видимо, в коридоре или по телефону. Третья итерация ушла не на работу, а на археологию: собрать заново, что заказчик имел в виду с самого начала.
Вот что по-настоящему задевает. Ничего не нарушено. КТЗ единица – значит «задача готова». Я фиксирую договоренности – просто эту не зафиксировал, она проскочила в разговоре. Я проверяю готовность – проверил, она ответила «готова». Все правила были при мне, и метрика была при мне. И не сработали.
Потому что знать правило и применить его в нужный момент – не одно и то же. Знание никуда не делось. Не сработало применение ровно тогда, когда было нужно.
Почему правильное не делается
Тут легко скатиться в мораль: будьте дисциплинированнее, ребята. Не всегда помогает. Я и так считал себя дисциплинированным, но все равно проскочило.
Дело не в дисциплине отдельного человека. Дело в том, что у каждого правильного действия есть момент, когда его дешевле не сделать. И таких моментов в обычной рабочей неделе десятки.
Зафиксировать договоренность письменно? Дешевле кивнуть и побежать дальше, все же друг друга поняли. Проверить готовность по-настоящему, а не для галочки? Дешевле поверить на слово, человек ведь сказал «понятно». Защитить встречу проработки, когда горит? Дешевле ее отменить, время сейчас дороже. Вернуть сырую задачу заказчику? Дешевле взять и разобраться по ходу, чем идти на конфликт.
Сделать правильно почти всегда дороже в моменте. Сэкономить – дешевле. А счет приходит потом – через две недели, тремя итерациями правок, когда уже не вспомнить, на какой именно встрече все пошло не так. Связь между сэкономленной минутой сегодня и потерянной неделей потом неочевидна. Поэтому правило знают все, а исполняют единицы и непостоянно.
Значит, бесполезно полагаться на силу воли. Полагаться надо на то, что не требует силы воли в момент, когда дешевле схалтурить. На привычку, которую один раз сделал частью процесса и дальше она работает сама, даже когда ты устал, торопишься и хочешь домой.
Дальше – четыре места, где правильное проигрывает чаще всего. И четыре привычки, которые я встроил, чтобы перестать каждый раз делать выбор заново.
Четыре разлома
За свою трудовую практику я наблюдал процесс требований с разных сторон: в проектном институте, в строительном подрядчике, в корпоративной разработке. Среда разная, люди разные, а ломается все в одних и тех же местах. Проверьте на своей команде. Подозреваю, минимум два узнаете сразу.
Разлом 1. Договоренности живут в воздухе
Встреча прошла отлично. Все друг друга поняли, все закивали, разошлись довольные. Через две недели выясняется: поняли все разное, а кивал каждый своему.
Все знают, что договоренности надо фиксировать. И все равно не фиксируют – потому что в момент встречи кажется, что и так все ясно. Зачем тратить время на очевидное. Устная договоренность – это не договоренность. Это набор индивидуальных воспоминаний, и расходиться они начинают в ту секунду, когда люди выходят из переговорки. Чем выше ставки, тем быстрее они расходятся – память услужливо подстраивается под то, что человеку выгодно помнить. Никто не врет. Просто все помнят по-разному, и каждый при этом искренне.
Самый коварный вариант – фиксация «потом». Протокол, написанный через три дня, фиксирует уже не договоренность, а чье-то воспоминание о ней. И спорить с таким протоколом легко: «я этого не говорил».
Разлом 2. Готовность проверяют по памяти, а не по факту
Мой фильтр многие справедливо назвали рабочим Definition of Ready. По сути, это он и есть. Только тогда возникает честный вопрос: DoR придумали не вчера, почему он у большинства не работает?
А ответ простой: обязательные критерии готовности команда соблюдает, необязательные под давлением сроков пропускает первыми. Вот и весь механизм смерти DoR – он держится, пока есть время, и отваливается ровно тогда, когда времени нет.
Есть и вторая причина, почему DoR мертвый. Он сформулирован через свойства: «требования ясны», «оценка проведена». А свойство проверяется по памяти и на глаз. Требования ясны – кому ясны? Тому, кто ставил задачу? Ему всегда все ясно, он же ее придумал.
Моя история с третьим возвратом показала вторую дыру, которую я раньше недооценивал. Даже хороший вопрос с числовым порогом можно убить, если отвечать на него по памяти. «Критерий приемки есть?» – «да, обсуждали на встрече». Формально готовность подтверждена, КТЗ низкий. Фактически подтверждено воспоминание о встрече, а не документ. Фильтр проверял не задачу. Он проверял, что команда о задаче помнит.
Мертвый DoR, кстати, опаснее отсутствующего. Он создает иллюзию, что фильтр есть. Галочка стоит, а сырая задача прошла – ровно мой случай.
Разлом 3. Проработку требований отменяют первой
Проведите эксперимент: посмотрите, какую встречу команда отменяет первой, когда горит. Я спрашивал об этом многих коллег из разных компаний. Ответ совпадает у всех: проработку требований. Груминг, рефайнмент, уточнение задач – называйте как хотите, отменяют именно ее.
И ведь все знают, что это вредно. Логика все равно простая: некогда обсуждать, там все понятно, надо делать. Ровно эта логика гарантирует, что через месяц будет гореть снова. Команда делает быстрее – и переделывает чаще. Час, сэкономленный на обсуждении, возвращается тремя итерациями правок. Я проверял это на собственных итерациях, когда разбирался, куда утекает время: утекало оно не в разработку, а в переделки задач, взятых без проработки.
Получается парадокс. Проработка требований – единственная встреча, которая экономит время. И единственная, которую регулярно приносят в жертву.
Разлом 4. Сказать «нет» сырой задаче некому
Здесь обычно говорят: наймите хороших аналитиков и дайте им полномочия. С первой половиной согласен полностью. Вся загвоздка во второй – в полномочиях.
Даже сильный аналитик, который видит, что задача сырая, упирается в простой факт: взять ее проще, чем вернуть. Возврат – это разговор с заказчиком, а у заказчика свой начальник, свои сроки и свое любимое «вы же профессионалы, разберетесь, дайте свои предложения». В крупных организациях задачи к тому же прилетают мимо аналитика, напрямую от руководства, уже с дедлайном – аналитик физически не успевает их проработать до планирования. Знание, что задачу надо вернуть, есть. Полномочий и желания идти на конфликт – нет.
Поэтому сырая задача проходит. Команда берет ее «в работу», но в работу на самом деле берется не задача. Берется расследование, что заказчик имел в виду. Расследование под видом разработки, причем с дедлайном, который назначили раньше, чем кто-либо понял объем.
Что я с этим делаю
Дальше – четыре приема, по одному на разлом. Сразу скажу, чем это не является: не методология, не фреймворк, внедрять нечего. И да – ни одного нового правила вы тут не увидите. Новое не в правилах, а в том, как сделать их исполнение дешевле, чем нарушение. Чтобы в тот самый момент, когда обычно халтуришь, схалтурить было сложнее, чем сделать.
Прием 1. Фиксация в день встречи, три строки
Любое устное решение по требованиям записывается в тот же день. Не протокол на две страницы, который никто не прочтет. Три строки: что решили, кто подтвердил, что это меняет в задаче. Текст уходит участникам с одной фразой: «Зафиксировал так, поправьте до завтра, иначе работаем по этому».
Почему три строки, а не нормальный протокол? Потому что нормальный протокол – это работа, а работу под конец дня откладывают. Три строки пишутся за две минуты, и эти две минуты не проигрывают по цене даже уставшему менеджеру вечером. Я специально сделал планку такой низкой, чтобы у меня не было повода ее не взять.
«Иначе работаем по этому» – вторая половина приема. Молчание превращается в согласие. Поправить текст в день встречи легко и не стыдно. Оспаривать его через две недели – уже неловко, и все это понимают.
Эффект я почувствовал в тот день, когда на очередное «мы имели в виду другое» впервые ответил ссылкой на письмо с датой. Разговор занял две минуты. Не две итерации – две минуты.
Прием 2. Ответ о готовности – ссылка, а не «да»
Пять вопросов готовности – это базовая механика КТЗ, повторять ее тут не буду. Здесь – про то единственное, что изменилось после третьего возврата, и изменилось как раз в сторону «исполнять, а не помнить».
Раньше команда отвечала на вопросы по памяти. «Критерий есть?» – «да». И этого хватало, КТЗ выходил низкий. Теперь правило жестче: засчитывается только ссылка. Письмо, протокол, карточка задачи – что угодно с датой и автором. «Обсуждали на встрече» равно «нет».
Звучит мелочью, а закрывает ту самую слепую зону из разлома 2: фильтр перестает оценивать воспоминания и начинает оценивать факты. И заодно убирает спор о субъективности. С формулировкой «требования ясны» спорить можно до хрипоты. Со ссылкой – не о чем: она либо открывается, либо ее нет.
Прием 3. Проработка требований – защищенный слот
Встреча проработки не отменяется. Совсем, ни при каких пожарах. Если горит – сокращается до пятнадцати минут на одну ближайшую задачу. Но из календаря не исчезает.
Я сделал ее неотменяемой именно потому, что на силу воли тут полагаться нельзя – в момент пожара любая встреча выглядит роскошью. Если каждый раз решать заново, оставить ее или убрать, она всегда проиграет горящей задаче. Поэтому решение принято один раз и не обсуждается.
Скажу прямо: правило стоило мне нескольких неприятных разговоров. Когда горит, человек, который защищает встречу, выглядит бюрократом. Спорить про методологию бессмысленно, никто не слушает. Сработал другой аргумент – про время в часах: я взял конкретную итерацию и показал, сколько ушло на переделки задач, взятых без проработки. Против цифр спорить тяжело. Против чужой методологии – легко и приятно.
Прием 4. Возврат с вопросами, а не с вердиктом
Возврат сырой задачи с вопросами – прием не новый. Но дело не в самом возврате, а в том, что делает его дешевым для исполнителя. Возврат-конфликт дорогой, на него надо решиться. Возврат-вопрос почти ничего не стоит.
«Не готова, доработайте» – это конфликт. Вы оцениваете работу заказчика и не даете ему пути вперед. Получите оборону, эскалацию или то самое «вы же профессионалы».
«Чтобы взять задачу, нам нужны два ответа: кто принимает финальное решение по форме отчета, ваш отдел или планирование? и какой период выгрузки обязателен?» – это уже не отказ. Заказчик получает короткий список, с которым идет к своему руководству и выглядит там человеком, который двигает вопрос, а не получил отлуп.
Содержание одно и то же. «Задача сырая, верните» – так сказать тяжело, это диагноз заказчику лично. «Нужны два ответа» – так легко, это просьба о помощи в его же интересах. Меняешь не суть, а цену поступка для того, кто его совершает. И поступок начинает совершаться.
Где все это хранится
Прошлую статью я закончил вопросом: где хранится история изменений требований? Я сам однажды на нем споткнулся – и это, пожалуй, лучшая иллюстрация ко всей теме.
У четырех приемов есть побочный продукт, ценность которого видна не сразу. Зафиксированные решения, ответы заказчика на возвраты, итоги проработок – все это накапливается. Складывается в одну ленту: что решили, когда, кто подтвердил, почему отказались от альтернатив.
Зачем она, кроме споров? Вот зачем. Когда в команду приходит новый человек, он первым делом спрашивает не «что мы делаем». Он спрашивает «почему так». Почему отказались от третьего варианта интеграции. Почему с этим отделом переписываемся только письменно. Почему вот этот срок реальный, а вон тот – ритуальный. Документация отвечает на «что». На «почему» отвечает только история решений. Если она есть.
С прошлого года у этой истории появился второй потребитель – языковые модели. Перед разбором каждого нового документа требований я загружаю в модель файл с историей решений. И модель перестает предлагать варианты, которые мы отклонили полгода назад. Зато начинает находить противоречия с тем, что уже зафиксировано – то, что человек глазами пропустит. Один из практиков дал точную формулировку: ИИ умножает то, что у вас уже есть. Есть порядок в требованиях – модель умножит порядок. Есть хаос – получите хаос, просто быстрее. Но это уже территория контекст-инжиниринга, и она тянет на отдельный разговор.
Вместо вывода
Главное возражение к моей методике КТЗ бьет в точку: все, что я описал – азбука, и хороший аналитик с полномочиями снимает половину этих проблем еще на входе. Спорить не буду.
Но между «знать азбуку» и «исполнять ее в пятницу вечером на третьей горящей задаче» лежит пропасть, и проваливаются в нее все – я в том числе, со своим стажем и собственной метрикой наперевес. КТЗ показал единицу. Задачу вернули трижды. Правила знают все, но работает не знание, а четыре скучные привычки, которые делают исполнение дешевле нарушения. Записывать в день встречи. Требовать ссылку, а не «да». Не отдавать проработку пожарам. Возвращать вопросом, а не вердиктом.
Ни одна не требует фреймворка, бюджета или разрешения сверху. Все можно начать со следующей рабочей недели в одиночку. Я начинал именно так – и первые недели чувствовал себя занудой с тремя строками фиксации. Потом занудой быть перестал. А КТЗ той отчетной формы так и остался единицей. Только теперь это правда.
Шаблон фиксации решений из трех строк и чек-лист готовности из пяти вопросов я собрал в один файл – он лежит в закрепе моего телеграм-канала про контекст-инжиниринг в закрытом корпоративном контуре: t.me/async_mind_it. Там же про то, как из истории требований вырастает контекст для работы с ИИ.