Срок уже обещан. Что теперь оценивать?

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

Такой подход к оценке работы предлагает Шон Гёдеке: обсуждать несколько планов вместе с их рисками. Разберу его на учебном случае, в котором заказчику обещали запуск импорта каталога через две недели, ещё не определив состав работы. Объёмы и договорённости ниже придуманы для примера.

Что означает «начинать работать»

Компания собирает каталог из выгрузок пяти поставщиков. Сейчас в них около 400 тысяч позиций. У каждого поставщика свой формат, а ещё есть архивы цен за несколько лет. Сотрудники хотят искать товары в одной системе и обновлять цены повторной загрузкой файлов.

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

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

Поэтому первым вопросом будет: «Что заказчик должен суметь сделать через две недели?» Допустим, ответ такой: найти текущую позицию любого поставщика и получить её актуальную цену. Историю пока согласны смотреть в прежней системе. Это ещё нужно подтвердить с самим заказчиком: согласие руководителя разработки не меняет уже сделанного внешнего обещания.

Появилась граница, которую можно исследовать. Полный перенос истории остаётся отдельной работой. Текущий каталог нельзя молча сократить до одного поставщика, потому что в ответе прозвучало «любого». И загрузка, которую один раз выполнил разработчик из консоли, ещё не даёт сотрудникам возможности обновлять цены самостоятельно.

До оценки нужно увидеть, что загружаем

Я бы попросил свежие выгрузки всех поставщиков и несколько предыдущих. Одного красивого примера мало: в нём может не оказаться товаров без категории или строк с пустой ценой. Заодно понадобятся правила, по которым поставщик связывает товар с его идентификатором.

Для повторной загрузки это особенно важно. Если идентификатор постоянный, можно обновить известную позицию. Если после удаления товара его номер выдают другому, программа может принять старую и новую позицию за одну. Совпадение номеров в двух присланных файлах ещё не доказывает, что их никогда не переиспользуют. Нужен ответ владельца данных, а при отсутствии такой гарантии потребуется другой способ сопоставления.

Нужно выяснить и то, содержит ли файл весь текущий каталог или только изменения. В нашем примере договоримся о полной выгрузке каждого поставщика: после её успешной загрузки исчезнувшие позиции больше не показываются в текущем каталоге. Иначе старая цена снятого товара может выглядеть актуальной. Для файла только с изменениями такое правило не подойдёт.

В нашем примере каждый поставщик остаётся отдельным источником. Два одинаково названных товара из разных выгрузок не объединяются автоматически. Иначе к загрузке добавится ещё одна задача: определить, действительно ли это один товар, и договориться, какую цену показывать. Её нельзя спрятать внутри слова «нормализация».

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

Несколько вариантов одной функции

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

Полный перенос нельзя уверенно обещать за две недели на основании того, что удалось прочитать свежий файл. В истории может оказаться другая модель данных. Например, раньше одна строка описывала товар целиком, а теперь размеры хранятся отдельными позициями. Код для текущей выгрузки не решает вопрос, как связать их с прежней ценой.

Для ограниченного варианта есть более узкая проверка. За день можно попробовать загрузить два последовательных состояния каждого источника и посмотреть, что произошло с уже существующими позициями. В этом учебном плане команда выделяет на такую проверку первый день. К его концу нужно либо подтвердить подход и назвать оставшуюся работу, либо объяснить, какое условие не выполнено. Проверка может показать и то, что выбранный вариант не подходит.

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

У каждого варианта есть собственный результат. Иногда пилот заказчику совершенно не нужен: он уже знает, как хочет работать, и ждёт полный набор данных. Тогда третья строка отпадает. Объявить её первым этапом проекта мы можем, но подходящим ответом на запрос заказчика она от этого не станет.

Что нельзя убрать вместе с историей

После выбора текущего каталога может прозвучать: «Тогда пока без обработки ошибок, главное загрузить». Я бы разобрал, что за этим стоит. Отдельный экран с подробной статистикой можно отложить. А незаметно пропустить часть файла и сообщить «Загружено» нельзя: сотрудники начнут пользоваться неполным каталогом как полным.

В ограниченном варианте тоже нужно понять, какие данные будут заменены. Сначала файл проверяется и готовится к применению. Если в нём недопустимая цена или неизвестный формат строки, прежние данные остаются. Сотрудник, загрузивший файл, видит причину отказа и знает, что каталог не обновлён. После применения можно сверить количество принятых позиций и проверить несколько известных товаров.

Повторная загрузка того же файла не должна создавать дубли. Сбой посреди применения не должен оставлять каталог в состоянии, о котором интерфейс ничего не знает. Способ обеспечить это зависит от приложения, и его реализация тоже занимает время. Если команда не успевает сделать рабочее обновление, можно обсуждать разовую подготовку каталога с участием разработчика. Но это уже новое ограничение для заказчика, а не невидимое сокращение объёма.

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

Как договорённость меняет работу

Допустим, руководителю подходит текущий каталог. Разговор на этом не заканчивается.

«Если оставляем историю в прежней системе, можно запускать через две недели?»

«Сначала проверим повторное обновление. Завтра к 16:00 я покажу результат по всем пяти источникам и оставшийся план. Если у кого-то нельзя надёжно сопоставить позиции, отдельно решим, исключаем ли этот источник из первого запуска. Сам я этого из обещания не уберу».

«Заказчику нужны все пять. Я уточню, подходит ли ему текущий каталог без истории, и попрошу поставщиков подтвердить правила идентификаторов».

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

Предположим, на следующий день условия подтвердились. Повторная загрузка обновляет нужные позиции, а владельцы источников подтвердили правила идентификаторов. Теперь можно оценить оставшуюся работу. В нашем примере для неё выделен один разработчик, и после исследования у него остаётся девять рабочих дней. Другие обязательства на эти дни уже сняты; само появление нового проекта их не отменило бы.

Это прикидка для конкретного учебного случая, после знакомства с кодом и данными. Последние дни оставлены на исправления, а не распределены заранее между дополнительными возможностями. Если применение выгрузок займёт пять дней вместо трёх, на проверку останется меньше времени. Такое изменение уже повод вернуться к обещанию, даже если первая неделя ещё не закончилась.

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

После этого договорённость можно записать без сокращения «делаем импорт»:

К согласованной дате сотрудники смогут искать текущие позиции всех пяти поставщиков и обновлять цены из их выгрузок. История остаётся в прежней системе. Заказчик подтвердил, что это подходит для первого запуска. Команда завершает загрузку и проверяет её вместе с сотрудниками до этой даты. Если меняются правила входных данных, возвращаемся к составу первого запуска до продолжения реализации.

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

Когда ни один вариант не подходит

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

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

Я бы прямо сообщил руководителю: «С тем результатом, который подтвердил заказчик, дату сейчас не подтверждаю. У нас нет проверенного способа перенести историю за оставшееся время. Можно обсудить более позднее отключение прежней системы. Если это невозможно, нужно заново согласовать дату перехода».

Здесь полезно показать, что именно ещё неизвестно: связь архивных строк с нынешними товарами пока не проверена. Если принятый ключ не подойдёт, владельцу данных придётся объяснить соответствие или предоставить другую выгрузку. Дополнительный разработчик может помочь с исследованием, но само его участие ещё не даёт основания обещать более ранний запуск.

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

Разработчик может разобрать технические варианты, но не может сам отменить внешнее обязательство. Руководителю придётся вернуться к заказчику с изменением обещания. До этого команда может исследовать перенос истории и показать результат этой работы в оговорённый день. Такой срок исследования не следует выдавать за новую дату запуска: он пока обещает только сведения, которых не хватало для выбора.

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