Первая встреча с Заказчиком, выжимаем максимум.

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

    Я сумел найти для себя оптимальный вариант.

    При первых встречах я всегда мечтал улавливать мысли, ведь согласитесь, не всякий человек может излагать мысли последовательно и структурировано. Чаще всего у заказчика в голове легкий хаос с калейдоскопом прекрасных видов будущей системы, а также прекрасных картин того как мгновенно идет в гору его бизнес сразу после внедрения. А если задавать вопросы без четкого плана, встречи могут затянуться надолго.

    Сейчас я действую по плану и это позволяет мне сразу выигрывать по многим направлениям:
    • Я экономлю свое и чужое время, сокращая количество встреч. Особенно это становится актуальным в связи с повальным увлечением личностной эффективностью.
    • Я сразу показываю себя профессионалом с определенным подходом в работе. Это дает мне дополнительные очки и отбирает их у потенциальных конкурентов.
    • Я глубоко погружаюсь в систему и уже могу написать предварительное ТЗ для исполнителей по ней или по ее отдельной части (в случае, если система большая).

    В чем же состоит мой план?

    Подготовка к встрече


    Принадлежности для письма


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

    Диктофон


    Поможет вспомнить какие-то важные моменты из встречи, если Вы их забудете потом, при анализе результатов. Да и в любом случае, освежить память никогда не помешает. Только не забудьте предупредить человека, что Ваша встреча записывается, может быть он будет против этого, хотя вероятность этого небольшая.

    Место


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

    Ноутбук


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

    Встреча


    С чего начать?


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

    Как фиксировать?


    Я лично стараюсь использовать списки действий и UML нотацию. Это удобно, сразу структурирует информацию, ее легко анализировать и делать выводы, а также предугадывать узкие места, на которые сразу же стоит обратить внимание.

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

    Вот небольшой пример, записанный со слов заказчика:

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

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

    Структурная композитная диаграмма

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

    Как закончить?


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

    Результаты в виде таких диаграмм, а также возможно кратких историй (userstories), в случае размытых требований, легко можно послать заказчику, никакими особыми знаниями, чтобы их прочитать обладать не нужно.

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

    Интересных Вам проектов и удачных обсуждений!

    Оригинал: http://www.steinzeig.ru/2007/12/09/rabota-s-zakazchikom-pervaya-vstrecha/
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      0
      Да, хорошо так дисциплинировать и себя и заказчика.
      Даже на самых мелких заказах.
        +1
        Хех, с утра искал нечто подобное, как-раз из встречи вернулся и вот оно :)
          0
          Рад, что сумел Вам помочь :)
            0
            как раз наоборот :) - судя по всему - на этот раз вы друг друга не нашли :))) точнее нашли слишком позно :)
              0
              именно так, но ничего, пригодится на следующий раз
            0
            +1, такая же история
            0
            а как на счет временных ограничений? сколько по времени должна длиться такая встреча? и стоит ли предупреждать заказчика, что данная встреча отнимет у него ххх времени!
              0
              я обычно выделяю для первой встречи часа 1,5-2 минимум. Обычно заказчики готовы к такому исходу, однако можно и предупредить на всякий случай. Людям нравится, когда о них заботятся и уважают их время.
                0
                хм.. да больше чем 2 часа в состоянии внимания находится и невозможно... а делать первую встречу с перерывом на обед - это мягко говоря не кошерно :)
                  0
                  Вы можете иногда делать короткие перерывы на отвлеченные темы. Я люблю поговорить с заказчиком о "его делах", эта тема всегда актуальна :)
              0
              Очень хотелось бы еще статью о том, что должен к первой встрече подготовить заказчик. Бывало приедет человек, который даже и понятия зеленого не имеет о чем говорить, мол "...ответственный занят...", "...наша компания лидер в области..." и т.д. =)
                0
                хорошо, попробую написать в ближайшее время. спасибо за комментарий.
                +2
                В большинстве случаев Заказчик попросту не готов к проведению длительной и содержательной встречи до начала проекта. Поэтому в своей практике я использую интеллектуальные карты памяти (Mind Maps) для фиксации основных обсуждавшихся моментов.
                Исходные вопросы к Заказчику и все интересующие меня моменты предварительно фиксируются в карте памяти. Во время встречи (в идеале) достаточно лишь добавлять информацию к существующему, заранее подготовленному шаблону карты памяти.

                На моей памяти не было ещё ни одного случая, когда в ходе предварительной встречи с Заказчиком у меня было бы достаточно времени для рисования полноценных диаграмм UML, хотя бы на уровне вариантов использования, не говоря уже о диаграммах классов.
                  0
                  Mind map - это не во всех случаях удобно и хорошо. А если у Вас нет компьютера под рукой, к тому же? Рисовать древовидные mind maps на бумаге, это не так просто, как диаграммы, которые просто спускаются сверху вниз.
                  К тому же, если заказчик искренне заинтересован в проекте - время найдется, благо его не так много нужно - на одном листе сразу ведете список всех сущностей, а на других рисуете диаграммы прямо во время рассказа. Главное, донести до него что от хорошего обсуждения все только выигрывают, ведь ему больше всех интересно, чтобы его проект был выполнен качественно и быстро.
                    +1
                    Вероятность того, что я не смогу взять свой крошечный VAIO на встречу с заказчиком, пренебрежимо мала:-)

                    Как правило, Заказчик искренне заинтересован в проекте, но т.к. вы этот проект ещё не получили, он скорее примеривается к Вам, как к потенциальному исполнителю, нежели горит желанием рассказать о сущностях, взаимосвязях, атрибутах, версионности, графическом интерфейсе пользователя и т.п.
                    По собственному опыту, в первую очередь Заказчика интересует, насколько точно и полно вы с ним описали требования и пожелания к системе, предложили ли вы ему своё видение бизнес-сценариев работы пользователя с приложением и т.п.
                    Для этого идеально подходят карты памяти; каким образом их использовать - описано в первом комментарии.
                      +1
                      А кто говорит, что Вы должны грузить заказчика сущностями? Вы же для себя рисуете...
                      Опять же эти диаграммы предельно понятны даже заказчику и легко можно посмотреть не упустили ли Вы чего. Даже объяснить что такое 1---* не сложно. И предлагать Вам тоже никто не запрещает.

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

                        Как правило, после первой встречи я обязательно подготавливаю диаграмму сущность-связь, где фиксирую свое видение предметной области. Эту диаграмму можно обсудить со специалистом со стороны Заказчика.

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

                        Ваш подход к спецификации требований тоже работает, но, на мой взгляд, на первой встрече малоприменим. В том числе и потому, что если Вы зададите Заказчику слишком много вопросов по предметной области, на которые он не сможет ответить, то тем самым можете выявить его некомпетентность и оставить в итоге у него неприятный осадок. Чисто психологически неприятный. Никаких объективных преград для обсуждения сущностей "с места в карьер" не существует.
                          0
                          По разному бывает. С случае больших и сложных проектов часто бывают и технические специалисты, особенно если Вы приходите не с улицы, а по рекомендации.

                          Но опять же, я могу дать некоторые советы исходя из своего опыта, а действовать все равно всегда приходится исходя из особенностей ситуации и отвечать за результат самому :)

                          Кстати профессионализм, если Вы не просто тупо грузите заказчика техническими терминами и адскими диаграммами, а просто действуете четко и логично оставляет исключительно приятное впечатление.
                  0
                  Полезная статья, как программисту, мне было бы удобно и приятно работать с таким менеджером проекта. А то регулярные быстрые объяснения на словах функциональных частей сайта, зачастую, приводят к "легкому" недопониманию, что вытекает в дополнительные доработки и скольжению по лезвию в отношении сроков.
                    0
                    Это не для программистов, это для оценки скопа проекта. Вам было бы удобнее работать с системным аналитиком.
                      0
                      Не понял, при чем здесь системный аналитик? Или так правильно называются люди, которые быстро и качественно превращают расплывчатые желания заказчиков в полноценное ТЗ?
                        0
                        Так точно, это они переводят бизнес-требования в ТЗ
                    +1
                    Статью в избранное.

                    Однако есть другая грань.
                    В своей работе придерживаюсь правила: первое знакомство - это тест на человеческую совместимость.
                    Бывает, что и я готов, и клиент конкретен, а контакта нет, и желания нет работать и зарабатывать.
                    По всем показателям - я лучший. А заказ уходит еще кому-то.
                    На каждого продавца есть свой покупатель.
                      +2
                      Скажу по личному опыту, что UML в этих делах не помощник для первой встречи, скорее для последующих, которые будут носить более предметный характер. Для первой встречи очень даже подходит описание бизнес-логики и бизнес-процессов (EPC) по методологии ARIS. Люди, знакомые с ARIS'ом подтвердят, что его концепция и графическое представление максимально ориентированы на определение первичных потребностей заказчика.
                        0
                        Спасибо за совет, обязательно посмотрю в сторону ARIS.
                        +1
                        Статья отличная! Но вот я - заказчик - женщина, соответственно с порушенным мозгом и нестандартной логикой ;)
                        Через 5 минут - с Вами рассталась бы!
                        Терплю непрофессионалов, именно по причине того, что они не жрут мое время, а - напрмер, отсылают куда-нить ещё, а понимая, что там - не лучше, соглашаюсь на все не глядя, но быстро..., надо решать мульон новых текущих проблем...
                        Возможно, теряю на качестве, но лень переходить на новых людей...
                        Вывод: многих устроит 30 минут воды, непиара, типа реально будет нормалек, но не круть, и тд и тп...
                        Но статью учту)))))
                          0
                          ну я, да и все остальные - это же не роботы, которые действуют по одной программе :)
                          если человеку тяжело, а это обычно видно, то надо осторожно и не спеша задавать вопросы в щадящем режиме

                          а непрофессионалов я нигде не терплю. просто, не люблю некачественную работу.
                            0
                            Непрофессионалов и некачественную работу и я не люблю, вот может посидев на habrahabr зарегившись (а читаю оч давно постоянно), начну разбираться кто есть кто сразу, однако, уже привыкла, что о результате говорят все одинаково обнадеживающе, а по факту - редко получаю желаемое... Оттого и здесь, оттого и саморазвиваюсь)))
                            0
                            тут уже от требуемого результата зависит :) В статье говорится о профессиональном подходе к проектированию, а не "за 30 минут, но побыстрее". Я однажды с заказчиком просидел порядка четырех часов (на первой встрече(!), но сразу после неё мы приступили, и сейчас успешно делаем проект.
                              0
                              Я может не очень понимаю суть требований, но как показывает опыт - результат один - что 30 мин сиди, что 4 часа, если повезло - профессионал - сделает отлично, а нет - так хоть 2 месяца поясняй - воз и ныне там...
                              *это мой горький опыт, не догма*
                                0
                                На самом деле нет. За 30 минут просто физически не успеваешь спроектировать даже начальную структуру и механику проекта. Обычно встречи длятся у меня порядка 1,5-2х часов. Но есть немаловажный момент - особенности рынка. В нашем городе без плясок с выяснениями требований не обойтись, поэтому так долго. Возможно у вас по другому. А этот проект за 4 часа - продумывали всё до деталей, вплоть до того, как будет выглядеть ЧПУ, и всё равно по мелочам переделываем структуру. Главное, что "ПО МЕЛОЧАМ", а не кусками. Это уже большущая выгода от потраченных 4х часов, тем более, что они оплачивались как "консультация".
                            0
                            карандаши с точилкой - это жесть :)) 21 век, казалось бы..
                              0
                              хм, но похоже для того, чтобы можно было легко стереть, только такой вариант подходит (не считая доски).. наверное, это специфично для обсуждения тз. забавно. в остальной жизни они как-то совсем не нужны )
                              0
                              Скорее, тянет на конец встречи для уточнения частностей, чем брать за основной процесс по составлению ТЗ проекта. И не только по сайтостроению ;)
                                0
                                Если говорить о серьезном проекте, то первая встреча никак не должна длиться 2 часа. Для начала заказчику необходимо объяснить как, вообще, с Вами работать. Как будет вестись работа, что будет от него требоваться и, естественно, из чего будет формироваться стоимость. А для этого Вы сами должны четко знать как это должно быть. Потому что заказчик всегда спрашивает: И если заказчика это устраивает, то можно продолжать с ним встречаться и работать.

                                "Я экономлю свое и чужое время, сокращая количество встреч." А это, по-моему, зря. В процессе работы очень важна коммуникация с заказчиком. Иначе появятся проблемы с тем, что выполненная работа не соотвествует требованиям заказчика. ()
                                  0
                                  Насчет карандашей- правда, в руках смотрится все таки как инструмент художника, а не тупая офисная ручка. Насчет ЦВЕТНЫХ крандашей, это конечно интереснее.

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

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