Из черепа заказчика

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

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

Дичайшее озарение (и проблема) когда-то постигает каждого заказчика ПО — проект делают не те люди, с которыми ты договаривался.

Вот ты менеджеру проекта всё детально объяснил, и про бизнес, и про важность, и про ограничения, и про челленджи, и вообще так душевно помитинговали, что проснулся на окраине города, в вышиванке и не один… А те, кто проект делают — тебя никогда не видели, проект вообще не понимают, и не знают, зачем нужно то и это, и действуют только в рамках ограниченных технологических и ментальных инструкций…

Я знал его, Горацио. Это был человек бесконечного остроумия, неистощимый на выдумки.
Я знал его, Горацио.

И нет у бедного заказчика никакой власти над процессом разработки его собственного ПО, когда/если в обсуждение проекта вовлечены только люди из бизнес-уровня.

Как эту психологическую проблему решает каждый заказчик в отдельности — та еще шнобелевская диссертация…

Как-то в самой крутейшей в Кишиневе студии «Сделаем сайт-визитку для вашего бизнеса, ня!» появился действительно ОПЫТНЫЙ заказчик. Как зашла она в нашу контору, так попросила не чаю, а показать ей того человека, который будет делать ей будущий сайт. ОДНОГО человека, с которым «потом будем разговаривать».

А кого показывать-то? Вот у нас дизайнер вашего сайта. Вот программист (аж два!). Вот руководитель разработки. Вот менеджер по рекламе и привлечению клиентов, с которым вы, собственно, до сих пор разговаривали, и который процесс инициировал, а дальше вообще ничего гарантировать вам не может — ни сроков, ни качества, ни результата. И вот директор фирмы — вы только с ним будете разговарить о деньгах и о том, как важно для вас получить сайт к определенному дню, бо грядет отраслевая выставка. Так с кем именно хотите поговорить?

Кто за всё отвечает? Директор фирмы? Да, но он ничего не программирует. Программист? Да, но без дизайна он ничего не обещает. Дизайнер? Да, но без внятного ТЗ он не понимает, чего от него хотят, и сам сайт он делать не будет, он только картинку нарисует. Руководитель разработки? Кагбэ, да, но он руками в проекте ничего делать и рисовать не будет, поэтому «делать будем все сразу»… Так с кем вы хотите поговорить?

А только директор фирмы говорил с клиентом, и только он вообще знал, насколько важно успеть (полностью закрыть проект) к назначенной дате. И только он знал, как много денег было заплачено за этот заказ. По сравнению с обычными проектами — очень много, бо сроки давят, и для клиента это действительно важно… И только он знал, какие счета его бухгалтерией еще не оплачены, и как важно их покрыть, чтобы фирму не закрыть, и только ему было очевидно, что от данного заказа отказываться нельзя.

А менеджер разработки, глянув на сроки и приблизительное ТЗ, сразу сказал, что «Вообще не надо за этот проект браться, идея сайта слишком невнятная, из сайта-визитки они потом начнут делать какую-то ”всеобщую базу данных о недвижимости по стране”, очень многое нужно обсудить и договориться, мы очевидно не успеем…» Но отказываться нельзя.

А дизайнер, глянув на сроки и приблизительное ТЗ, сразу сказал, что идея — ни к черту, и делать ничего не следует, бо идея сайта совершенно невнятная, и из сайта-визитки потом начнут делать неведому шнягу («Всеобщую базу данных о недвижимости по стране? На каком движке? Боже мой, какой бред…»), и мы явно не успеем… Но отказываться нельзя.

А программисты (оба), глянув на сроки и приблизительное ТЗ, сказали «Однозначно хз…». Бо дизайна нет, и какие ограничения по верстке? На каких мониторах, например? У нас в наличии только 1024х768. И в каких браузерах? И что за, прости господи, идея у сайта такая дебильная? Они что, потом начнут делать из него «всеобщую базу данных о недвижимости по стране»? Быгыгы… На каком движке? Быгыгы… Но отказываться нельзя.

Множество уровней принятия решений. Искажения информации — буквально на каждом уровне. Как это надо делать — у каждого своё мнение. Надо ли объяснять клиенту, что «Мы тут подумали, и считаем, что ваш проект…»?

Что в этой ситуации может делать клиент? Ничего. Ждать, когда ему «всё сделают».

Ну, глорие Замолксис! По-частям все продвигалось нормально. Дизайн — так себе, но аппрувед, демо — аппрувед, контент — предоставлен. По-итогу сайт получился весьма работоспособным «внутри», но каким-то невнятным «снаружи». А тестировать — как всегда, было некогда. И как всегда, в срок не успели. И понятное дело, что демо — это хорошо, но надо бы доделать.

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

И началось…

«Ну, объявление добавить в базу можно, а почему шрифт такой некрасивый? Вы что, не умеете сделать нормальный шрифт? А почему, когда мы смотрим наш сайт на мониторе в 22 дюйма, снизу выползает оранжевая полоса…» Боже, да где вы такой монитор нашли? «А у нас друг в Израиле, он посмотрел, и сказал, что дизайн вообще ни к черту…» В ТЗ было указано, что максимально разрешение экрана… «Зачем вы мне говорите про эти разрешения? Я же вас о другом спрашиваю!»

«А почему, когда вот здесь сделать клямц, то вот там делает пимпц?» Это такая технология, это интернет, он так работает. «Нет, нам не нравится, как работает интернет. Можно же сделать по-другому?! Почему бы вам не сделать по-другому?» Ну, в принципе можно, но это новый проект затевать надо, это к директору. «Нет-нет, никакого нового проекта, сделайте тут! Почему вы нас постоянно посылаете? Ну и что, что только к директору… Почему он не хочет возвращать нам деньги? Аллё, где ваш дурацкий менеджер по рекламе? Почему он никак не может сказать конкретно, когда вы доделаете наш сайт?»

Наконец, в офис пришел не заказчик, а настоящий ”product owner”, серьезный и злой дядька, который встал за спинами программистов, посмотрел в их мониторы, и начал сильно тыкать им в плечи, приказывая «Давай быстро сделай сайт нормально, нах! Ну!?»

Нет, это были не девяностые. Какие могли быть сайты в девяностых?

Итого: проект с радостью передали другой студии «Сделаем сайт-визитку для вашего бизнеса, ня!», и чем оно там закончилось…

Всё, что заказчик может сделать «на входе» — самостоятельно расписать ТЗ, бо работу будут делать вообще неведомые ему люди, с которыми всё не обсудить. Да и если со всем перезнакомиться — менеджеры разработки (и особенно рекламные менеджеры, которые проекты инициируют) весьма нередко меняются прям на ходу проекта… Всякое бывает. Пусть мы будем считать их неучами. Пусть делают строго по ТЗ.

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

Всё, что заказчик может сделать «по-итогу» — тестировать, тестировать, тестировать. Самостоятельно.

Задача тестировщика в начале проекта — понимать, что случится с психикой заказчика, когда упадет занавес. И начинать готовить финальное тестирование.

Собственно, для этого тестировщиков как можно раньше надо в проект привлекать — чтобы было время и возможность подготовиться к проведению тестирования, а не для того, чтобы «находить баги как можно раньше»… прекратите уже эту муть тиражировать. Нет клиенту никакого счастья от того, что мы баги находим «как можно раньше».

Без доступа к телу заказчика, конечно, натестируешь всякого… Например, программисты намутили возможность оплаты через очередной пэй-пал, и много всяких сложностей в процессе сего порешали, а тестировщики об этом вообще хз, и тестируют оформление «страницы товара», находя там баг на баге в верстке, и совсем чуть-чуть в функционале «Send to a friend»… Ну как тут не пожелать бить морды на комплексе?

Поэтому вторая задача тестировщика — поселиться в футболке программиста (Ближе к телу ©), и постоянно понимать, что в проекте становится важным, а что — вообще ерунда. Бо всё течёт, всё изменяется, и приоритеты тоже.

Третья задача тестировщика — взрослеть и перестать тупить над тест-кейсами. Бо успешность ПО не в строгом соответствии ТЗ.

PS Не будем ковырять разницу между «требованиями» и «ТЗ». Не в терминах собака зарыта.

2 ответа на “Из черепа заказчика”

  1. Класс!
    Но вот по: «а не для того, чтобы «находить баги как можно раньше»… прекратите уже эту муть тиражировать. Нет клиенту никакого счастья от того, что мы баги находим «как можно раньше».» очень даже хочется подискутировать.
    Со стороны заказчика согласен: у заказчика есть подписанный сторонами документ, в котором есть (в идеале 🙂 ) что будет, на когда и за сколько денег. И таки да, ему глубоко параллельно когда был найден баг.
    А вот со стороны организации-разработчика очень даже не фиолетово когда найден баг. Представим: есть бага производительности (требования производительности оговорены, задокументированы и заэпрувлены), найдена на позднем этапе тестирования, модуль однозначно переделывать, что тянет расходы. Теперь подобных багов допустим 20, что однозначно срывает нам сроки и/или бюджет. Так чем плохо минимизировать риски ранним нахождением багов?

    • Баги о производительности как раз на поздних стадиях и выявляются… Поэтому пример специфичный. Да и 146% времени у нас уходит на тестирование функционала, а не всего остального, вроде масштабируемости под нагрузкой. Да, если это вылезет из подпола, то оно станет важнее работоспособного функционала, но…

Добавить комментарий для Аноним Отменить ответ