Сдача проекта заказчику — логичный этап любой разработки. Даже не так — самый важный этап, поскольку именно на нем определяется, хорошо ли вы сделали свою работу, и вообще закончили ее или будете еще долго фиксить баги (возможно за свой счет). Тем не менее, часто на старте проекта продумыванию его сдачи уделяется минимум времени — главное начать, а там видно будет. Видно в таких ситуациях бывает не всегда, поэтому хочу поделиться недавним опытом сдачи одного крупного проекта для промышленного заказчика.
Для начала представлюсь — меня зовут Роман, я аналитик и проджект разработки информационных систем, в основном с веб‑интерфейсом. Занимаюсь этим делом давно, и понятно что сдавать проекты различной крупности приходилось неоднократно. Но рассказать хочется об одной недавней разработке, когда на этапе сдачи выплыло особенно много незапланированных изначально вещей, что сделало ее (сдачу) особенно длинной и болезненной. Надеюсь, что пытливый читатель возьмет этот опыт на вооружение и хотя бы продумает пути завершения проекта заранее :-)
Разработка представляла собой многоступенчатую систему регистрации и учета лабораторных проб, которые во‑первых имеют несколько маршрутов прохождения и фиксации, а во‑вторых отдельные пакеты расчетов по формулам для каждого маршрута. Аналитика для проекта была прописана хорошо — и функциональные требования, и пользовательские сценарии, модели данных, интеграции, схемы процессов, действия API и даже руководства пользователей — любо‑дорого посмотреть. Но перечень критериев приемки и описание ПМИ оставили на потом, с расчетом на то, что в процессе многое может поменяться. За что в итоге и поплатились.
Стоит сказать, что в проекте участвовали три стороны — наша команда делала основную разработку и тестирование, команда генподрядчика — тестирование и внедрение у конечного заказчика, и собственно заказчик принимал систему в эксплуатацию. Через полгода после старта наша команда бодро отрапортовала генподрядчику об окончании запланированных работ и началась приемка. И тут же объявилась первая нестыковка — поскольку критерии приемки в процессе работы так и не были прописаны, наша команда и специалисты генподрядчика проверяли функционал системы по‑разному. Тестировщики разработки опирались на собственные тесткейсы, написанные во время проверки текущих задач. Аналитики генподрядчика проверяли прямо по пользовательским инструкциям, которые были подготовлены еще в начале работы и не учитывали некоторых изменений, сделанных в процессе. Огонька добавили специалисты по внедрению, которые пошли с готовым интерфейсом к конечным пользователям и принялись собирать обратную связь, которая, конечно, принесла много сюрпризов.
Когда рост замечаний стал сильно смахивать на снежный ком, было решено привести их обработку в порядок. Для начала все поступившие недочеты были описаны и внесены в задачницу. Расставили приоритеты, распределили по исполнителям, договорились с генподрядчиком сосредоточиться только на тикетах с критичным и блокирующим приоритетом. Для командной коммуникации стали проводить общие созвоны по проекту каждый день, поначалу утром и вечером, потом только утром.
Взяли пользовательские сценарии из исходного ТЗ и сделали из каждого таблицу в экселе, где каждая ячейка соответствовала шагу в прохождении сценария. Чекнули их с пользовательскими сценариями, чтобы не было расхождений. Проверяли и красили каждый пройденный шаг в зеленый или красный цвет, в зависимости от прохождения. Если не получалось пройти — создавали новую задачу, указывали ее в таблице и ставили в работу.
Система предусматривала расчеты, и для их проверки нужны были тестовые данные. Однако на этапе сдачи выяснилось, что данные должны быть не абы какими — просто вбить в поля произвольные 1,2,3 и посмотреть как отрабатывают формулы расчетов нельзя. Большинство вводимых параметров должны быть в строго определенных пределах — например не ниже 100 и не выше 225,5. И результат на выходе тоже должен быть определенным — если на входе указали 2 и 5, то на выходе должно получиться ровно 10, в противном случае формула отрабатывает неверно. Часть этих пределов и ограничений не были отражены в системной аналитике и не попало в алгоритмы расчетов. Поэтому для проверки потребовалось получить от заказчика реальные данные, которые тоже были включены в таблицы со сценариями.
После проверок каждого шага и многочисленных правок результаты расчетов стали сходиться, и на наших сценарных таблицах заливка стала преимущественно зеленой. Для проверки мы прогнали сценарии расчетов еще раз, на этот раз с реальными данными, полученными через интеграцию из внешних систем. Это тоже принесло несколько доработок, но они были уже не критичными. Меж тем с начала приемки системы прошло 2,5 месяца.
Да, самой больной темой для нашей команды стали переработки, за которые заказчик отказывался платить, считая их исправлением допущенных ошибок. В качестве минимизации потерь удалось договориться с генподрядчиком выделить в отдельный скоуп работы по расчетам, данные для которых отсутствовали в исходном ТЗ. Их пометили в Jira специальным признаком Доработка, как и все те дополнительные идеи, которые пришли в процессе сдачи от конечных пользователей. Поскольку такие фичи не были предусмотрены в исходной оценке, они должны были оплачиваться отдельно.
Выводы, которые можно извлечь из всей этой истории
Всегда прописывайте в описании работ критерии приемки — какие признаки должны быть у системы, чтобы заказчик считал ее принятой. Можно это делать даже на этапе КП, чтобы обе стороны понимали, что говорят об одном и том же.
Если у вашего проекта есть техзадание, прописывайте в нем ПМИ (программу и методику испытаний). Это сильно упростит как понимание целей проекта обеими сторонами, так и финальную сдачу работ. Хорошо, когда ПМИ не просто повторяет описанное в пользовательских сценариях, но и включает конкретные данные — когда система подразумевает какие‑то расчеты и формулы.
Конечно, если вы работаете над проектом по agile, у вас не будет ТЗ и конечной цели, только путь. Но фиксировать испытания для приемки результатов каждого спринта тоже может стать полезной практикой.При финальных испытаниях оформите сценарии ПМИ как инфографику или диаграммы, где каждый шаг можно прописать отдельно и покрасить в зеленый или красный цвет. Это сделает приемку нагляднее и для вас и для заказчика. В качестве инструмента подойдет обычная таблица или доска в Miro. Туда же можно добавлять ссылку на тикет для исправления ошибочного шага.
При работе с расчетами и формулами всегда просите у заказчика реальные данные для их проверки
Когда работаете с водопадом и имеете согласованную оценку работ, всегда фиксируйте доработки, не описанные в аналитике, как дополнительные работы. И просите за них дополнительные деньги.
