Уже много раз убеждался в том, что при разработке ПО, обязательно нужно планировать этап «Тестирование». Помимо Подготовки (где делаем дизайн будущего продукта) и самого Исполнения.

Этот этап должен занимать минимум 20% того, что планируется на разработку.

Другими словами, если вы решили, что стоимость разработки 100 000 руб. Значит нужно сверху добавить 20 000 р.

И тут вопрос конечно же размера.

Если разработка продукта рассчитана на 2-3 месяца, то стоит запланировать порядка 7 подэтапов тестирования. Две альфа-версии, 3 бета-версии и 2 релиз кандидата. За пример можно взять циклы разработки WordPress. Там около 200 разработчиков, каждый релиз занимает 2-3 месяца и каждый раз мы видим 3 беты и примерно 2 RC, иногда три.

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

А как быть с маленькими разработками по заказу? Ну скажем простенький модуль написать к WordPress для заказчика? Внешний заказчик или внутренний — особой разницы нет.

Пусть это будет какой-то механизм интеграции сайта и платежной системы.

Удивитесь, но и тут стоит планировать те же 20% на тестирование.

Только тут чуть другие особенности:

1. Этап тестирования как правило не делится. А он один и все тут. Просто этап тестирования. Но те же 20%.

2. В этот этап стоит закладывать не столько ошибки кода, сколько ошибки в формулировки требований.

С ошибками кода думаю все понятно. Это просто.

Ошибка формулировки требований — это стоит разобрать подробней. Именно эти ошибки сбивают качество. А не ошибки ПО, как можно подумать.

Засада в том, что выполнение самого ТЗ — еще не означает качественный продукт.

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

Зачем нам ТЗ и вообще какова цель услуги разработки ПО

Вот это ключ. Многие программисты думаю что ТЗ нужно чтобы понять задачу, а заказчику нужна разработка ПО.

Мол сделаем ТЗ, разработаем ПО по ТЗ и будем нам счастье. Цель выполнена.

Это глубокое заблуждение. Все чуть иначе.

Цель — соответствовать и превосходить ожидания заказчика.

ТЗ нужно не столько для понимания задачи, сколько для фиксации ожиданий.

Фиксировать ожидания нужно, чтобы иметь возможность им соответствовать и превзойти.

В идеале получить такую ситуацию, когда в большинстве случаев удается превосходить ожидания.

Иногда им просто соответствовать.

И совсем редко — нарушать их.

Сейчас в абсолютном большинстве случаев получается иначе:

1. Соответствуем редко когда

2. В большинстве случаев нарушаем ожидания

Нам за последний год удалось сильно переломить число в пользу соответствий. За счет хитрой методики разработки ТЗ.

Но до идеала еще стоит дойти…

Ряд простых допущений

Чтобы понять суть проблемы, стоит принять ряд допущений:

1. Заказчик может не разбираться в том что вы делаете. Зачастую это основная причина почему он готов платить вам деньги за услуги.

2. Важно не формальное выполнение условий ТЗ, а соответствие ожиданиям и их превосходство. (соответствие и превосходство — это ключевые понятия, о них далее)

3. Вы можете не выполнить ТЗ, но превзойти ожидания заказчика и ваши отношения пойдут в гору. Вы можете выполнить и перевыполнить ТЗ, но нарушить ожидания — и вы потеряете отношения, а мб еще и скандал заработаете. Потому соответствие ожиданиям — первично, а вот формальное выполнение ТЗ — вторично.

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

Как правильно составить ТЗ?

ТЗ составляется не столько для понимания задачи, сколько для фиксации ожиданий. Чтобы затем была возможность им соответствовать и превосходить. Если ожидания не зафиксированы и все на словах — вам нечему соответствовать и ничего превосходить. Вероятность нарушения ожиданий стремится к 100% и вы потеряете отношения. Какой бы крутой разработчик вы не были. Это лишь вопрос времени.

1. В ТЗ должны быть четко выделены секция задачи и секция требований. Они не должны путаться. Все остальные секции — по желанию.

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

3. Можно часть требований упустить, если они не важны. Фокусироваться только на ключевых. Иначе ТЗ может стать слишком большим. А это опять же приведет к не пониманию и как следствие к нарушению ожиданий.

Как правильно использовать правильное ТЗ?

Составить правильно ТЗ — еще не конец на пути к качеству 🙂

Правильно ТЗ — это лишь инструмент. Его еще нужно уметь применять.

Если у вас просто ТЗ — то считайте что у вас нет инструменты и вам нечего применять. Стоит пожелать только удачи.

Но и имея на руках правильно ТЗ, без умения его использовать — толку не будет.

А методика его применения проста:

1. Вы делаете разработку по списку Требований. Зачеркивая по мере выполнения.

2. Подходите к этапу Тестирования.

3. Тут появляются ошибки кода. Которые мы конечно же исправляем. Это мелочи.

4. И вот тут появляются ошибки формулировок. Вот это реальная засада!

Заказчик говорит что то типа «Ну вот тут я имел ввиду совсем не то что вы сделали!».

Поздравляю! Вы нарушили ожидание! Бесполезно прикрываться ТЗ и верищать что вы все сделали как там написано!

Нет, ну если хотите уронить качество и потерять клиента не жалко — пожалуйста. Ваше право!

Но если вы хотите делать качественные продукты и клиенты вам дороги — прикрываться ТЗ бесполезно. Ошибка уже допущена. Она была в ТЗ. А не в коде. И вы либо исправите ошибку, либо уроните качество. Других вариантов нет. А если вы уроните качество — готовьтесь к потере клиента.

Так как можно исправить этот тип ошибок? Залазить в код и делать все что просит заказчик? Тоже не лучший путь 🙂 Времени и денег может попросту не хватить на все что может появиться…

Ругаться с заказчиком? Ну это уже надеюсь понятно.

Нет, нет и еще раз нет! Все это ошибочные пути разрешения ситуации.

Есть очень простой и проверенный путь.

Мы берем его дополнительные требования (уточнения или изменения), и пишем в отдельный список «Дополнения».

Говорим так: Слушай, вот это все у нас не было прописано в ТЗ. По ТЗ мы все требования выполнили.

Давай мы закончим тестирование над ошибками и выпишем все дополнения в отдельный список.

Мы попробуем реализовать часть из них, если это не сильно сложно.

В чем фишка?

Фишка в том что мы убиваем сразу кучу зайцев.

Смотрите сами:

1. Мы запланировали подушку в 20% на этап тестирования. Об этом этапе клиент может и не знать. Да и не нужно ему про него знать. Если вы правильно ведете схему ценообразования.

2. Мы делаем тестирование. Понимая что у нас есть 20%.

3. У клиента возникают ожидания. Но у нас на руках ТЗ и список требований. Потому эти ожидания мягко и справедливо возвращаем до уровня ТЗ.

4. Затем мы составляем список допов. И часть из них делаем. Может быть даже все, если их мало и они реально простые. А может быть только те что можно сделать просто и в рамках той подушки в 20%.

5. Все допы делать нет смысл. Их может быть много или они могут быть большие. Потому часть допов легко конвертируются в новые заказы. Клиент как правило тут понимает что это действительно допы, в ТЗ их нет, а ему они нужны. Он видит что вы сделали то что от вас требовалось (секция Требования в ТЗ) и даже больше (часть Допов вы закрыли). Значит его ожидания выполнены и даже превышены. Это автоматически вызывает ощущение высокого качества продукта. А раз так — есть все основания этот новый заказ поручить вам же.

Эпилог

Первично соответствие и превосходство ожиданий.

Исполнение ТЗ -вторично.

Если вы нарушили ожидание клиента — стоит их исправить. Даже если это идет в ущерб условиям ТЗ.

Чтобы не разориться на исправлениях и сверх высоких ожиданиях, стоит правильно писать ТЗ, а затем правильно использовать правильное ТЗ.

Только правильное ТЗ и правильное использование правильного ТЗ, позволят с наименьшими потерями выходить из ситуации, когда возникла ошибка формулировки требований.

Ошибки формулировки требований — возникают постоянно. Их нельзя избежать или обойти. Их можно только уменьшить и научиться правильно их проходить.

С другой стороны, ошибки формулировок, это отличный механизм превосходства ожиданий.

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

И здесь, метод правильного ТЗ и правильного использования правильного ТЗ — отлично выручает. Заказчик сам говорит что ему хотелось бы, помимо того что есть в ТЗ. При правильном возврате ожиданий к уровню ТЗ, и затем частичному закрытию допов, вы по сути автоматом превосходите ожидания.

Профит!

Для Заказчиков

Может показаться, что тут описываются какие то манипулятивные техники. Нет. Все эти техники описаны в ИСО 9000 (международный стандарт менеджмента качества). Другой вопрос, что понятие ожиданий и их превосходства — достаточно сложная штука. Мне понадобилось около года, чтобы глубже понять особенность этого понятия.

И да, правильная поставленная задача — это на половину решенная задача. Другой вопрос что для правильной постановки задачи, у заказчика могут отсутствовать нужные знания. Это нормально. Потому секция Задача — она всегда идет от Заказчика, а секция Требования — пишется совместно. Нужно понимать что постановка задачи это совместное действие. И если по какой-то причине, одно и то же требование может быть понято и выполнено двояко, то это в т.ч. вина Заказчика. Конечно же тут можно сделать исполнителя крайним. Это легко. Но грамотных исполнителей сложно найти и стоит подумать, готовы ли вы потерять отношения? Вы скованы одной цепью. Успех отношений должен быть важен и нести выигрыш обоим сторонам. Потому будьте готовы смириться с тем, что как сформулировали требование, так и получили результат. Хотите более точные результаты, постарайтесь дать максимально четкие формулировки. Допустили ошибку — будьте готовы отвечать за нее и платить за переформулировки. Изменение формулировки требования в одно слово иногда может изменить решение и стоимость разработки в несколько раз.

Хороший исполнитель такие формулировки старается отслеживать и детализировать.

Но даже лучший из лучших не сможет отловить все мутные формулировки, т.к. он не телепат и не может увидеть то, что видите вы.

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

Если этого нет, не стоит вообще начинать отношения.