Момент истины для любого заказчика — когда разработчик пишет «всё готово, принимайте» и присылает ссылку или доступ. Заказчик открывает, видит, что программа вроде работает, нажимает на пару кнопок, всё отзывается, и думает: «Ну, нормально, вроде сделали». Переводит оплату. А через неделю выясняется, что половина функций работает не так, на пустую форму программа падает, а одна из заявленных возможностей вообще не реализована. Деньги уплачены, разработчик уже не так отзывчив, и приходится либо мириться, либо платить за исправление.
Вся эта печальная история разворачивается из одной ошибки — приёмки «на глаз», по общему ощущению «вроде работает», вместо проверки по конкретным критериям. А качество разработки живёт именно там, куда при беглом взгляде не смотрят: в нестандартных сценариях, в поведении при ошибках, в том, все ли заявленное реально сделано. Хорошая новость в том, что большую часть этих проверок заказчик может сделать сам, не разбираясь в программировании. Нужен лишь понятный порядок приёмки и привычка не оплачивать до проверки. Его и разберём.
Эта статья — опорная в разделе про разработку. Смежные темы: как составить ТЗ, из каких этапов состоит работа, из чего складывается цена.
Что вы узнаете из статьи
- Почему приёмка «на глаз» подводит чаще всего
- Как проверить соответствие результата тому, что заказывали
- Как протестировать поведение программы при ошибках
- Почему нельзя оплачивать сразу после слова «готово»
- Что делать, если работа не прошла приёмку
Проверка по ТЗ: главное — соответствие договорённостям
Первое и главное в приёмке — сверить результат с тем, что было записано в техническом задании. Если ТЗ составлялось грамотно, в нём есть список функций и критерии в ТЗ готовности по каждой. Приёмка тогда превращается в простую процедуру: идёте по списку и проверяете каждый пункт. Эта функция заявлена — она есть? Работает так, как договаривались? Отмечаете и двигаетесь дальше.
Именно здесь видна цена внятного ТЗ на старте. Когда есть с чем сверять, приёмка становится механической проверкой по списку, а не спором на ощущениях «мне кажется, должно быть иначе» — «а мне кажется, так и договаривались». Если же ТЗ не было, приёмка превращается в выяснение, кто что имел в виду, и тут заказчик обычно проигрывает, потому что доказывать нечем.
Проверяйте именно соответствие, а не общее впечатление. Красивая работающая программа, в которой нет одной из заявленных функций, — это невыполненная работа, как бы хорошо ни смотрелось остальное. И наоборот, не придирайтесь к тому, чего в ТЗ не было: если функцию не заказывали, её отсутствие — не недочёт. Приёмка по договорённостям честна для обеих сторон.
Тестирование: проверяем не только то, что работает
Типичная ловушка приёмки: заказчик проверяет только нормальные сценарии. Ввёл правильные данные — работает, отлично. Но качество программы проявляется не в том, как она ведёт себя, когда всё хорошо, а в том, что происходит, когда что-то идёт не так. Именно нестандартные ситуации чаще всего сделаны кое-как или не сделаны вовсе.
Поэтому при приёмке намеренно пробуйте ломать. Оставьте поле пустым и попробуйте отправить — программа выдаст понятную ошибку или сломается? Введите явно неверные данные — что произойдёт? Нажмите кнопку дважды быстро, попробуйте сделать то, что обычно не делают. Этот «вредительский» тест ловит огромную долю недоработок, потому что разработчик, проверяя своими глазами, обычно идёт по правильному пути и углы не трогает.
Проверьте и базовые вещи, не требующие технических знаний. Быстро ли всё работает или приходится ждать. Открывается ли нормально на телефоне, если это предполагалось. Передан ли результат в оговорённом виде — доступ, файлы, исходный код, если он входил в договорённости. Глубокую оценку качества кода стоит доверить специалисту, особенно если продукт будут развивать, — но большинство проблем заказчик ловит сам, просто проверяя по сценариям, а не на глаз.
Почему нельзя платить сразу после «готово»
Здесь кроется тонкий, но решающий момент. «Готово» со стороны разработчика и «принято» со стороны заказчика — это два разных события, и между ними обязательно должна стоять проверка. Слово «готово» означает лишь, что разработчик считает работу завершённой. Соответствует ли она договорённостям на самом деле, выясняется только при приёмке.
Оплата до проверки лишает заказчика единственного рычага. Пока деньги не уплачены, исполнитель кровно заинтересован довести работу до приёмки, исправить замеченное, ответить на вопросы. После оплаты эта заинтересованность резко падает — не из злого умысла, а по простой человеческой логике: дело сделано, деньги получены, впереди другие задачи. Недоделки, которые до оплаты исправили бы за день, после неё повисают неделями.
Поэтому здоровый порядок только один: сначала приёмка по критериям, потом оплата. Это не недоверие к исполнителю, а нормальная деловая практика, к которой адекватный разработчик относится спокойно, потому что сам в ней заинтересован — она защищает и его репутацию. Настораживать должен как раз тот, кто настойчиво просит оплатить до проверки.
Что делать, если работа не прошла приёмку
Не принимайте работу из вежливости и не оплачивайте, чтобы «не обижать человека». Грамотная приёмка — нормальная часть работы, и адекватный исполнитель к ней готов. Если нашли проблему, главное — описать её конкретно. Расплывчатое «всё плохо, переделывайте» — не задача, на неё невозможно реагировать. А «при отправке пустой формы программа не выдаёт ошибку, а перестаёт отвечать» — чёткая задача, которую можно взять и исправить.
По каждой найденной проблеме фиксируйте: что именно не так, в каком сценарии воспроизводится, и по возможности прикладывайте скриншот. Чем точнее описание, тем быстрее и без споров идёт исправление. Затем работа возвращается на доработку — до оплаты. Если критерии и договорённости были зафиксированы заранее, исправление недочётов входит в обязательства исполнителя, а не превращается в спор «это уже доплата».
Самая надёжная защита, как обычно, выстраивается в начале, а не в конце. Когда требования и критерии прописаны в ТЗ, а работа идёт по этапам разработки с приёмкой и оплатой каждого через площадку, проблемы всплывают рано и на маленьких кусках, а не в самом финале на всём объёме сразу. Тогда приёмка перестаёт быть рискованным моментом «оплатил и надеюсь» и помогает не платить дважды — за разработку и потом за переделку.
Как зафиксировать приёмку документально
Приёмка, проведённая устно «вроде всё нормально, принимаю», почти ничего не стоит, если позже всплывёт проблема. Поэтому важно не только проверить работу, но и зафиксировать сам факт и результат проверки — это защищает обе стороны и снимает почву для будущих споров.
Самое простое и важное — письменно подтвердить, что именно принято. Не обязательно оформлять толстые акты: достаточно сообщения, где перечислено, какие функции проверены, что они работают, и что результат принимается. Так у обеих сторон остаётся общая точка отсчёта. Если через месяц что-то сломается, будет ясно, работало ли это на момент приёмки или проблема возникла позже, — а это меняет, чья зона ответственности.
Если приёмка выявила недочёты, фиксируйте и их, и договорённость об исправлении. Запишите конкретный список: что не так и что должно быть исправлено. Тогда доработка идёт по понятному перечню, а не по памяти, и не превращается в «я думал, вы и это поправите» против «про это речи не было». Закрытый список правок — это и план для исполнителя, и гарантия для заказчика, что ничего не потеряется.
Отдельно зафиксируйте передачу результата в полном виде: получены ли все доступы, файлы, исходный код, если он входил в договорённости. Частая беда — принять работу, оплатить, а потом обнаружить, что нет доступа к чему-то важному или не передан исходный код, без которого другой разработчик не сможет продолжить. Проверка и фиксация передачи всего оговорённого закрывает этот риск.
Когда работа идёт через площадку с оплатой по этапам, многое из этого происходит само собой: приёмка каждого этапа и его оплата уже служат документальным следом того, что и когда было принято. Это удобнее, чем восстанавливать историю по разрозненной переписке, и надёжнее защищает обе стороны.
Как платформа помогает принять работу без риска
На Где.Эксперт исполнителей выбирают по реальным отзывам и истории заказов — видно, кто привык сдавать работу по критериям и спокойно относится к приёмке, а у кого в прошлом были истории с недоделками и спорами при сдаче. Это отсекает тех, кто торопит с оплатой до проверки.
Работу удобно разбить на этапы и принимать каждый отдельно, с оплатой по факту выполнения: проверили результат шага по критериям — приняли — оплатили — идём дальше. Так заказчик не платит вперёд за непроверенное, а недочёты всплывают рано. Отзывы прошлых заказчиков работают страховкой от главного риска приёмки — оплатить «готово», которое на деле ещё не готово.
Часто задаваемые вопросы
Что проверять при приёмке?
Соответствие ТЗ: все ли функции есть и работают как договаривались. Поведение при ошибках. Передан ли результат в оговорённом виде. Базовые вещи вроде скорости и работы на устройствах. По критериям, а не на глаз.
Можно ли принять, не разбираясь в программировании?
Большую часть — да. Соответствие функций, поведение при ошибках, удобство, скорость проверяются без кода. Глубокую оценку кода лучше доверить специалисту, но большинство проблем заказчик ловит сам.
Почему нельзя платить сразу после «готово»?
«Готово» от разработчика и «принято» заказчиком — разные вещи. Оплата до проверки лишает рычага: после неё исполнитель уже не так заинтересован исправлять. Сначала приёмка, потом оплата.
Что делать, если работа не прошла приёмку?
Зафиксировать проблемы конкретно: что не так, в каком сценарии, со скриншотом. Вернуть на доработку до оплаты. При зафиксированных критериях исправление входит в работу, а не в доплату.
Как упростить себе приёмку заранее?
Прописать чёткие критерии готовности в ТЗ и вести работу по этапам с оплатой каждого. Тогда приёмка — проверка по списку, а проблемы всплывают рано, а не в финале на всём объёме.
Заключение
Приёмка — не формальность в конце проекта, а момент, который определяет, получите вы заказанное или будете платить за переделку. Главная ошибка здесь — принимать «на глаз», по ощущению «вроде работает», вместо проверки по конкретным критериям. Качество разработки прячется в нестандартных сценариях и поведении при ошибках, а заявленная функция, которой по факту нет, остаётся невыполненной работой, как бы красиво ни смотрелось остальное.
Грамотный заказчик сверяет результат с ТЗ по списку, намеренно пробует ломать программу нестандартными действиями, проверяет, что всё передано в оговорённом виде, и принципиально не оплачивает до приёмки, потому что после оплаты рычаг исчезает. А самую надёжную защиту он закладывает в начале: чёткие критерии в ТЗ и работа по этапам с приёмкой каждого превращают финал из рискованного «оплатил и надеюсь» в спокойную проверку по списку. Когда же хочется работать с тем, кто сдаёт по критериям и не торопит с оплатой, проще выбирать по отзывам и истории сданных проектов.
Найдите исполнителя на Где.Эксперт — принимайте работу по критериям и платите по факту выполнения.