«Виртуальная модель» или как нежно и аккуратно снять требования к проекту

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

    Бывают такие проекты, когда нет возможности заниматься анализом и исследованиями так, как это принято в цивилизованном обществе. Это происходит по разным причинам: отпуска сотрудников, маленький бюджет, сжатые сроки, а иногда встречаются даже противники предварительного обследования. Практически как в известном анекдоте: «чего тут думать — трясти надо». Поэтому приходится собирать и формализовывать требования за очень короткий срок и одну-две встречи с заказчиком, который не всегда может рассказать о решаемых задачах в силу отсутствия опыта работы с сайтами.

    Хлебнув несколько раз проблем с нехваткой данных для дальнейшей работы, я выработал для себя ряд мер, которые гордо назвал «виртуальной моделью» =)

    Что я делаю. Сначала готовлюсь к встрече: изучаю предметную область, возможных конкурентов, их продукты, способы сбыта и любую другую информацию, которую можно найти. Выхожу развеяться и уложить полученные знания в голове, набрасывая при необходимости важные моменты в блокноте. Возвращаюсь с прочищенным мозгом и начинаю конструировать в голове виртуальную систему. Глубоко детализировать не обязательно, главное — не забыть ключевые функциональные части, характерные для компаний этой отрасли.

    Например, у управляющих компаний такими атрибутами являются графики суточных колебаний индексов, котировки паев, инвестиционные портфели и другие. Далее накидываю возможный список сервисов — функциональных частей сайта: «новости», «личный кабинет», «импорт котировок с ММВБ» и так далее. После этого перехожу к структуре, и в самом примитивном виде расписываю разделы сайтов. Это все будет использоваться в качестве шпаргалки, при помощи которой я буду на встрече вести клиента по проекту.

    Итак, приезжаем, знакомимся, просим кофе и фирменную ручку. Извиняемся за забытые в офисе визитки, собираемся с мыслями, ослепительно улыбаемся и вещаем:

    — Я вам сейчас расскажу, как проект будет жить дальше.

    Заказчик, поборов удивление (как же так, я этих людей вижу второй раз, а они мне уже что-то рассказывают), начинает слушать. Тут, главное, не выпускать инициативу. Чуть позже он и сам активно включится в процесс.

    А дальше общение сводится к ролевым диалогам. Сначала я немного рассказываю о том, что мне удалось узнать про рынок, на котором он зарабатывает, и начинаю выдвигать кусочек за кусочком из «виртуальной модели» проекта:

    — Продукты мы свяжем с отраслевыми решениями, чтобы была возможность выйти на страницу конкретного продукта из этой отрасли.

    И так далее. Заказчик, в свою очередь, стремится его опровергнуть или дополнить:

    — Хорошо, но некоторые наши клиенты подбирают решения не только по отраслям, а еще и по платформе, на которой реализовано решение.

    О'кей, делаем пометку в блокноте и для себя понимаем, что у сущности «продукт» появляется дополнительный признак «платформа», который позволит в дальнейшем фильтровать продукты по платформе.

    Проходит некоторое время и мы замечаем, что «виртуальная модель» обросла вполне реальными требованиями, антитребованиями, сценариями использования сервисов и данными — это замечательно и очень сильно пригодится нам в процессе проектирования.

    Однако тут есть тонкий момент. Нужно донести до клиента, что это всего лишь беседа и мы не проектируем систему, а вырабатываем требования к ней. Чтобы потом не было удивленных лиц и вопросов: «ну мы же уже обсуждали это?!».

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

    Как правило, одной-двух встреч вполне достаточно, чтобы покрыть дефицит информации. Детали уже можно продумывать на следующих этапах.

    Попутно было замечено, что в игры «я придумал, а ты сломай» заказчики играют с большей охотой, чем самостоятельно формулируют проблемы и описывают свои бизнес-процессы.

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

    Конечно, большие проекты таким образом не вытянуть, лучше честно сообщить, что получится кака и увеличить сроки/бюджет, чем увлекаться «игрой», а потом поисками «слабого звена».

    Успехов в разработке!

    Комментарии 31

      +1
      Понравилась мысль.
        +2
        Просто и со вкусом.
        Стоит добавить, что очень много зависит и от самого заказчика.
        Бывали случаи например, когда подготовив проект заказчику и детально всё объяснив — он «улетает на крылышках» обещая под всё это найти денег сверх бюджета. А потом начинается — «а вот у нас не хватает на это, на это, на это», «как бы нам вот это урезать». Поэтому приходится заранее очень четко узнавать у клиента сколько он реально готов потратить на проект, чтобы не делать лишней работы.
          0
          Спасибо!

          Вы правы. Но у нас модель продаж несколько другая: мы сначала продаем фазу (как правило, первая — это анализ), а потом начинаем работать. Потому что сначала же непонятно какой объем у проекта, что нужно сделать и сколько это будет стоить. Анализ как раз дает такое представление и нам и самому клиенту, но детальные выводы можно сделать только на концепции, когда уже есть задача на проектирование функционала. Вот с этого момента и можно разговаривать про урезание объема или поиска более дешевых решений.
          +2
          мда, нужно иметь талант однозначно, — ничего нового не сказали но как красиво предподнесли.
          Именно по такой схеме техникал-врайтеры обычно составляют ТЗ, именно по такой схеме адекватный фрилансер его уточняет и т.п… но вы красиво рассказали, спасибо
            +1
            аааааа… я помотрел на Ваш ник, это не Вы на днях написали статью как можно писать на абсурдеы темы тома текста? это была практика и демонстрация? :)
              +2
              Вы меня раскусили! :)

              На самом деле, поработав в нескольких компаниях, я часто наблюдал довольно унылую картину: приходит менеджер к клиенту, садится в кресло и включает режим диктофона, поддакивая в нужных местах. Потом уезжает в офис, пишет не менее унылое ТЗ и отдает разработчикам, которые, в свою очередь, погружаются в эротические грезы о будущем функционале.

              Этот текст скорее для менеджеров компаний, которые не очень хорошо понимают, что клиент тяжело расстается с информацией. Он попросту не умеет этого делать. Главная мысль примерно такая: перед тем как поехать — подготовьтесь. Риск, что вы сделаете лажу, будет гораздо ниже, чем если просто приехать с отформатированным мозгом.

              Ну а то, что я размазал мысль на несколько абзацев… Считайте демонстрацией :)
                0
                плохие менеджеры… вообще ИМХО самая правильная практика когда на встречи ходят вдвоем (менеджер и тим-лидер который будет заниматься проектом) при условии конечно адекватности этого самого лидера, в том смысле что должен понимать кесарю-кесарево и подключаться к диалогу в необходимые моменты и не рассказывать заказчику что эту маркетинговую кнопку пыщь «мне сделать — как два пальца...»
                  0
                  Поддержу мысль о том, что сам менеджер на встрече ничего не сделает. У нас в агенстве на подобное мероприятие с кофе и трофейными ручками отправляется манагер и арт-дир (собственно, последний и знает, какие вопросы задавать, и что именно означают ответы на них).

                  P.S. Как можно уважать подрядчика, который забыл визитки?
                    +1
                    Менеджер менеджеру менеджер рознь. У нас на такие встречи ездит специально обученный человек и менеджер. Роль менеджера — сугубо административная: зафиксировать договоренности и обновить план. А вот человек уже разбирается с бизнесом клиента и снимает требования.

                    > Как можно уважать подрядчика, который забыл визитки?
                    Это не продажи, так что ничего страшного. Главное — не забыть голову.
                      –1
                      Все начинается с малого :-) Сначала не забываем визитки, потом не забываем голову :)
            0
            Перенесите в профильный блог, вроде как кармы уже хватает…
              0
              Перенес, спасибо.
              +1
              Спасибо за статью, хочется отметить, что вы безусловно правы, «разболтать» клиента порой просто не удаётся. И всё как вы описали со скудными сведениями и унылым ТЗ менеджер едет назад. Иногда, по принципу развития того сценария который Вы описали, появляются следующие прелести жизни: манагер (новичок, не грамотный, не до конца понимающий) наобещал клиенту кучу всего, что это чуть-ли не веб-ос будет, а разработчики потом сидят сутками с выпученными глазками как у дикой собачки и пишут этот ужасный код :) Всё должно зависеть как и от менеджера студии, так и от заказчика, особенно, если он заказывает сайт не «шоп был» а для дела (продвижение бренда, продажа товаров/услуг и т.д.). Ещё раз спасибо за статью.
                0
                Хороший дополнительный продукт — помощь заказчику в составлении концепци сайта (назавем это так, например). Требует дополнительной оплаты)
                  0
                  думается что тут прямые инвестиции, разработка концепции позволяет проще реализовать проект для исполнителя
                  0
                  Я занимался судейством футбола, и перед игрой моделировал предстоящие событя по такому же принципу. Узнать кто играет, в чем особенности, какую модель судейства применить и т.д. Очень помагало. А теперь эта наработка вошла и в остальные сферы деятельности.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Развернутый пост написать не получится, можно провалиться в конкретную область и там завязнуть. Либо не вдаваясь в подробности пройтись и получится как в этой записи.

                      Под ТЗ я понимаю именно Техническое задание на разработку проекта. Это как раз не бриф. Если попытаться провести аналогии, то бриф это скорее концепция проекта. А ТЗ — это его детализация. У нас под ТЗ понимается группа документов, содержащий постановку задачи на: разработку, дизайн, контент, верстку… и других.

                      > И клиенты все-таки не до такой степени идиоты. Бывают будь здоров разбираются, что аж бежать хочется прочь. )))
                      Это хороший клиент ;) Можно получить дополнительные знания, если он лучше разбирается.
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          Я тоже бывший рекламщик :)
                            0
                            Правда очень давно это было.
                            • НЛО прилетело и опубликовало эту надпись здесь
                        –1
                        «Нужно донести до клиента, что это всего лишь беседа и мы не проектируем систему, а вырабатываем требования к ней.»

                        Громкий смех в зале, местами переходящий в истерику.
                          0
                          Один из интересных моментов — аппетит приходит во время еды, и после того как заказчик получает продукт он всегда хочет что-то дополнить и изменить, даже в процессе разработки, когда он наблюдает промежуточные результаты у него есть свои пожелания к изменениям. Как быть?

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

                          Однако время когда заказчик смотрит на тебя влюблёнными глазами после того, как ты ему расписал во всей красе будущий проект прошло.

                          Сейчас он, заказчик, после всех твоих «росказней» и ТЗ добавит ещё вагон «мелких требований» и в процессе разработки будет добавлять по «маленькой тележке» требований в день.

                          Как грамотно тут применять итеративный подход? У меня пока получается только интуитивно — но это же не выход. Кто подскажет?
                            +1
                            > Один из интересных моментов — аппетит приходит во время еды, и после того как заказчик получает
                            > продукт он всегда хочет что-то дополнить и изменить, даже в процессе разработки, когда он наблюдает
                            > промежуточные результаты у него есть свои пожелания к изменениям. Как быть?

                            Не могу сказать про итеративный подход (как я понимаю, вы рассматриваете методики типа Agile, Scrum...), лично мне нравится RUP с его четкими этапами и принципом «договариваться на берегу, а потом плыть». Но это тема отдельной дискуссии и я не готов сейчас в нее вступать.

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

                            Есть другой, более мягкий вариант. Нужно объяснить заказчику, что текущий этап работы нужно доделать до конца и закрыть актом, иначе обязательства сторон не будут считаться выполненными. А для всех новых хотелок выделить отдельную очередь и работать с ней как с обычным проектом. То есть вы просто копите хотелки и как только их собралось много — оформляете в отдельную очередь.
                              –2
                              Ни о каком Agile речь не шла. А составлять акты — это идиллия разработки — которая прокатит только в юриспурденции и максимум в рекламе — редко в айти.
                              0
                              Нужно сразу договариваться след. образом:
                              1) вот мы зафиксировали требования к проекту, все они будут реализованы в версии 1.0
                              2) во время подготовки версии 1.0 набираем доп. требования, которые будут реализованы в версии 2.0, за которую Вы нам дадите энное кол-во бабла.

                              Если клиент не хочет так, то приводите ему след. доводы:
                              1) Мы договорились на какую-то сумму за определенный функционал
                              2) Если до начала работ, надобность в каком-либо функционале отпадает, то мы его не делаем, и соотв. не берем за него денег
                              3) В противоположность п.2 если возникает потребность в новом функционале, то по вашему мы должны его делать и ни чего не иметь за это?
                              4) Мы не отказываемся вводить доп. функционал за дополнительную плату, но делать это нужно упорядоченно, для чего нужна версионность, и Вы (заказчики) будете понимать за что платите дополнительные суммы

                              Как правило заказчики ни чего не могут противопоставить этому аргументу и соглашаются с ним. Если не соглашаются, то я бы не стал связываться с такими заказчиками. Ну и еще, конечно, ни в коем случае не связывайтесь с заказчиками, которые предлагают отменить п.2 и п.3 вместе, т.е. фиксируем цену проекта, и при отмене или добавлении функционала стоимость проекта не меняется. Вроде как Вы в в равных условиях, но как правило функционал будет только добавлятся. И еще на встречах не принимайте решений, т.к. на вас там давят ваши оппоненты, запишите их требования в блокнот, а потом спокойно, НА СЛЕДУЮЩИЙ ДЕНЬ все обдумайте и примите решение.
                              0
                              Это срабатывает, если предметная область не слишком специфична и проект достаточно велик, чтобы можно было найти конкурентов, добраться до их продуктов, придумать типовое решение и не сесть с ним в лужу. :)
                                0
                                Сам примерно также работаю, приносит свои результаты )
                                  0
                                  ты себе противоречишь

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

                                  скорее, ты не исследуешь, как организована деятельность у данного конкретного заказчика (что создаёт тонну риска, как ты это сам понимаешь), а изучаешь отраслевые практики, устроойство отрасли, типовые решения, понятия, и, если удаётся — куски процессов конкурентов

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

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое