+38 (093) 580-29-22 info@lokhnin.com

pafneio1j0e

Думаю, что каждый РМ сталкивался с ситуацией, когда заказчик не хочет принимать работы (даже если ТЗ было подписано кровью), начинает генерировать дополнительные требования, рассказывать что «это же и так очевидно», что продукт недостаточно качественный или его не устраивает качество выполненной работы?

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

Верификация подтверждает, что «вы создали продукт согласно требованиям»

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

Далеко не всегда программные решения, которые мы разрабатываем, действительно нужны клиенту или решают его задачи. Например, когда клиент ошибочно полагает что «достаточно сделать сайт, и клиенты повалят», не понимая при этом важность маркетинга и продаж, то и начинаются постоянные переделки сайта. Почему так происходит? Как решить проблему со сдачей работ?

Кто обычно отвечает за качество разрабатываемых решений:

Верификацию (подтверждение соответствия продукта утверждённым требованиям) обычно выполняют QA инженеры или тестировщики.

Валидацию (это подтверждение, что заказчик получил необходимую ценность от продукта и/или его «боль» устранена) обычно никто не делает, хотя по-хорошему должен сделать РМ или ВА.

Как я уже говорил в статье Как повысить скорость разработки ПО, самый простой способ повысить скорость разработки и сократить проблемы при сдаче работ — уделять больше времени сбору и анализу требований. При этом под требованиями я понимаю далеко не User story или Use Cases. В первую очередь нужно определить бизнес требования заказчика: какую проблему он хочет решить и почему это важно. Только после этого можно думать какие информационные технологии можно применить для решения поставленной задачи.

Вместо выводов:

  • Не стоит надеятся, что клиент знает что хочет. Если бы клиент действительно знал что хочет и какое программное решение нужно разработать, что он пришёл бы с уже готовым полноценным ТЗ.
  • Важно накапливать полученный отраслевой опыт. Заказчики обычно ожидают что аутсорсер (не важно, внешняя компания или внутренняя служба) подскажет им решение проблемы, а не будет тупо разрабатывать софт согласно утверждённых требований.
  • РМ в первую очередь хорошо разбирался не применяемых технологиях, а в бизнес сфере заказчика.
  • Качественные требования — залог успеха.

Кстати, более подробно про то, должен ли РМ разбираться в технологиях, можно посмотреть в этом видео: