Почему отчёт о ходе работ не отвечает на вопрос «готово ли»
Исполнитель присылает список закрытых задач, проценты выполнения или описание того, что было сделано за неделю. Всё это может быть правдой и всё равно не отвечать на главный для вас вопрос: может ли сотрудник уже сделать в программе свою работу от начала до конца.
Отчёт описывает усилия команды. Готовность видна в другом месте — в законченном действии, которое человек выполняет так же, как будет выполнять его каждый день. Чтобы это увидеть, не нужно читать код. Нужно заранее договориться, какое действие считается проверкой, и посмотреть на него своими глазами.
Ниже — порядок, который подходит для любой разработки программного обеспечения на заказ, где вы можете попросить показать промежуточный результат: от небольшой доработки до первой версии новой системы.
Шаг 1. Попросите показать не экраны, а законченный сценарий
Просьба «покажите, что уже готово» обычно заканчивается обзором экранов: вот форма, вот список, вот кнопка. По такому обзору трудно понять, работает ли всё вместе. Сформулируйте просьбу иначе: «Давайте пройдём одну операцию от начала до конца так, как её будет выполнять наш сотрудник».
Сценарий — это короткое описание одной реальной операции: кто начинает, что делает, что должно получиться в конце и кто это результат увидит. Если программа делается под ваши бизнес-процессы, проверять её разумнее всего на этих процессах, а не на абстрактных функциях. Если вы ещё не описывали свою работу на конкретном примере, начните с этого — тот же пример потом станет проверкой.
Дальше в тексте используется учебный пример. Он вымышлен и нужен только для того, чтобы показать форму записи; подставьте вместо него свою операцию.
Шаг 2. Запишите карточку проверки до показа
Самая полезная часть подготовки занимает полстраницы. До встречи запишите, с чего начинается проверка, что именно человек делает и что должно получиться. Отправьте эту запись исполнителю заранее: так он сможет сказать, что сценарий ещё не готов целиком, а вы не потратите встречу на догадки.
Два последних поля — «что получилось на самом деле» и «решение» — заполняются уже во время показа или сразу после него. Важно, что ожидаемый результат записан раньше, чем вы увидели фактический: иначе легко незаметно подстроить ожидания под то, что показали.
- Исходные условия. В программе есть менеджер Анна и руководитель Борис, бюджет отдела — 100 000 ₽. Заявок пока нет.
- Действие. Анна создаёт заявку на ноутбук за 80 000 ₽ и отправляет её на согласование.
- Ожидаемый результат. Борис видит заявку у себя, согласует её, заявка появляется в списке бухгалтерии, Анна видит новый статус.
- Фактический результат. Заполняется на показе: что именно произошло на каждом шаге, без оценок.
- Решение. Сценарий проходит, проходит с замечаниями или возвращается на доработку; замечания — отдельным списком.
Шаг 3. На показе действуйте сами и проверьте хотя бы одно отклонение
Когда сценарий проводит разработчик, он почти неизбежно идёт по пути, который знает лучше всего. Попросите, чтобы действия выполняли вы или сотрудник, который потом будет работать в программе. Разработчик в это время подсказывает, но не нажимает за вас. Так становится видно, понятен ли путь человеку, который его не строил.
Обычный ход событий — только половина проверки. В учебном примере стоит отдельно посмотреть, что будет, если руководитель отклонит заявку, или если сумма превышает бюджет отдела. Вам не нужно перебирать все варианты: одного-двух отклонений, которые реально случаются в вашей работе, обычно достаточно, чтобы понять, продумано ли поведение программы за пределами удачного случая.
Проверяйте на данных, похожих на настоящие, но не на настоящих клиентских сведениях, если исполнитель не подтвердил, что так можно. Похожие данные — это правдоподобные суммы, длинные названия, несколько заявок одновременно, а не одна запись «тест 1».
Во время показа
- Ожидаемый результат записан до начала показа.
- Действия выполняет человек с вашей стороны, а не разработчик.
- Проверен обычный ход и хотя бы одно отклонение.
- Результат видно там, где его будут искать: у руководителя, у бухгалтерии, в списке заявок.
- Всё замеченное записано сразу, своими словами, без попытки тут же решить, чья это ошибка.
Шаг 4. Запишите расхождения и разделите их по смыслу
После показа у вас будет список того, что получилось не так, как ожидалось. Спор между заказчиком и исполнителем может начаться не из-за самого расхождения, а из-за того, что стороны по-разному понимают, к чему оно относится: это ошибка в оговорённой работе, новое пожелание или вопрос, о котором просто не договорились. В одном из публичных рассказов заказчика конфликт с подрядчиком начался как раз со спора, считать ли исправление ошибок обязательным или отдельной платной работой. По рассказу одной стороны нельзя судить, кто был прав; но он хорошо показывает, почему границу полезно провести заранее.
Поэтому каждую запись стоит не только сформулировать, но и отнести к одной из групп. Сделать это можно вместе с исполнителем: вы описываете, что увидели, он говорит, как это соотносится с договорённостями. Если мнения расходятся, запишите оба — это честнее, чем молча согласиться или молча настаивать.
| Что увидели | К чему относится | Что записать |
|---|---|---|
| Согласованная заявка не появилась у бухгалтерии | Ошибка: результат был записан в карточке заранее | Шаги, при которых это произошло, и ожидаемый результат из карточки |
| Хочется, чтобы бухгалтерия получала письмо о новой заявке | Новое пожелание: в договорённостях этого не было | Пожелание отдельной строкой, чтобы обсудить сроки и стоимость |
| При превышении бюджета заявка просто отправляется дальше | Неясно: о таком случае не договаривались | Вопрос, как должно быть, и кто принимает решение |
Шаг 5. Примите решение и договоритесь о следующей проверке
Решение по сценарию удобно сводить к трём вариантам. Сценарий проходит — его можно считать проверенным. Проходит с замечаниями — работать уже можно, но есть список исправлений с понятным порядком. Возвращается на доработку — основной результат не получен, и проверку нужно повторить по той же карточке.
Сам список расхождений лучше хранить в одном месте, доступном обеим сторонам, и при повторном показе идти по нему же. Так вы видите, что исправлено, что перенесено, и не обсуждаете одно и то же заново. Если сценариев несколько, достаточно короткой таблицы: сценарий, дата проверки, решение, открытые замечания.
Такой порядок одинаково полезен в любой заказной разработке ПО, независимо от того, как исполнитель организует работу внутри команды: вы договариваетесь о проверяемом результате, а не о способе его получения.
Чего такая проверка не заменяет
Просмотр сценария показывает, что программа делает нужное в тех условиях, которые вы проверили. Он не показывает, насколько надёжно она устроена внутри, защищены ли данные, выдержит ли она одновременную работу многих людей, сохраняются ли резервные копии и можно ли будет передать её другому разработчику. Это отдельные вопросы, и ответ на них нельзя получить, глядя на экран.
Не обязательно разбираться в них самостоятельно. Достаточно спросить исполнителя, как он проверяет каждую из этих вещей и что может показать или передать в подтверждение. Если ответ вам непонятен или речь идёт о чувствительных данных и деньгах, разумно попросить независимого специалиста посмотреть именно эту часть. Проверка сценариев не конкурирует с такой экспертизой, а дополняет её: вы отвечаете за то, что программа делает нужное вашему бизнесу, специалист — за то, как она это делает.
С чего начать до следующей встречи
Выберите одну операцию, которую программа должна поддержать в первую очередь, и заполните для неё карточку из шага 2: исходные условия, действие, ожидаемый результат. Отправьте её исполнителю с вопросом, можно ли пройти этот сценарий вместе на ближайшей встрече, и если нет — когда это станет возможно. Уже сам ответ на этот вопрос скажет о готовности больше, чем процент в отчёте.