Comments 36
Да, хорошо так дисциплинировать и себя и заказчика.
Даже на самых мелких заказах.
Даже на самых мелких заказах.
Хех, с утра искал нечто подобное, как-раз из встречи вернулся и вот оно :)
а как на счет временных ограничений? сколько по времени должна длиться такая встреча? и стоит ли предупреждать заказчика, что данная встреча отнимет у него ххх времени!
Очень хотелось бы еще статью о том, что должен к первой встрече подготовить заказчик. Бывало приедет человек, который даже и понятия зеленого не имеет о чем говорить, мол "...ответственный занят...", "...наша компания лидер в области..." и т.д. =)
В большинстве случаев Заказчик попросту не готов к проведению длительной и содержательной встречи до начала проекта. Поэтому в своей практике я использую интеллектуальные карты памяти (Mind Maps) для фиксации основных обсуждавшихся моментов.
Исходные вопросы к Заказчику и все интересующие меня моменты предварительно фиксируются в карте памяти. Во время встречи (в идеале) достаточно лишь добавлять информацию к существующему, заранее подготовленному шаблону карты памяти.
На моей памяти не было ещё ни одного случая, когда в ходе предварительной встречи с Заказчиком у меня было бы достаточно времени для рисования полноценных диаграмм UML, хотя бы на уровне вариантов использования, не говоря уже о диаграммах классов.
Исходные вопросы к Заказчику и все интересующие меня моменты предварительно фиксируются в карте памяти. Во время встречи (в идеале) достаточно лишь добавлять информацию к существующему, заранее подготовленному шаблону карты памяти.
На моей памяти не было ещё ни одного случая, когда в ходе предварительной встречи с Заказчиком у меня было бы достаточно времени для рисования полноценных диаграмм UML, хотя бы на уровне вариантов использования, не говоря уже о диаграммах классов.
Mind map - это не во всех случаях удобно и хорошо. А если у Вас нет компьютера под рукой, к тому же? Рисовать древовидные mind maps на бумаге, это не так просто, как диаграммы, которые просто спускаются сверху вниз.
К тому же, если заказчик искренне заинтересован в проекте - время найдется, благо его не так много нужно - на одном листе сразу ведете список всех сущностей, а на других рисуете диаграммы прямо во время рассказа. Главное, донести до него что от хорошего обсуждения все только выигрывают, ведь ему больше всех интересно, чтобы его проект был выполнен качественно и быстро.
К тому же, если заказчик искренне заинтересован в проекте - время найдется, благо его не так много нужно - на одном листе сразу ведете список всех сущностей, а на других рисуете диаграммы прямо во время рассказа. Главное, донести до него что от хорошего обсуждения все только выигрывают, ведь ему больше всех интересно, чтобы его проект был выполнен качественно и быстро.
Вероятность того, что я не смогу взять свой крошечный VAIO на встречу с заказчиком, пренебрежимо мала:-)
Как правило, Заказчик искренне заинтересован в проекте, но т.к. вы этот проект ещё не получили, он скорее примеривается к Вам, как к потенциальному исполнителю, нежели горит желанием рассказать о сущностях, взаимосвязях, атрибутах, версионности, графическом интерфейсе пользователя и т.п.
По собственному опыту, в первую очередь Заказчика интересует, насколько точно и полно вы с ним описали требования и пожелания к системе, предложили ли вы ему своё видение бизнес-сценариев работы пользователя с приложением и т.п.
Для этого идеально подходят карты памяти; каким образом их использовать - описано в первом комментарии.
Как правило, Заказчик искренне заинтересован в проекте, но т.к. вы этот проект ещё не получили, он скорее примеривается к Вам, как к потенциальному исполнителю, нежели горит желанием рассказать о сущностях, взаимосвязях, атрибутах, версионности, графическом интерфейсе пользователя и т.п.
По собственному опыту, в первую очередь Заказчика интересует, насколько точно и полно вы с ним описали требования и пожелания к системе, предложили ли вы ему своё видение бизнес-сценариев работы пользователя с приложением и т.п.
Для этого идеально подходят карты памяти; каким образом их использовать - описано в первом комментарии.
А кто говорит, что Вы должны грузить заказчика сущностями? Вы же для себя рисуете...
Опять же эти диаграммы предельно понятны даже заказчику и легко можно посмотреть не упустили ли Вы чего. Даже объяснить что такое 1---* не сложно. И предлагать Вам тоже никто не запрещает.
Но Ваш подход тоже работает, тут я не спорю. Тут кто к чему привык, главное, чтобы было эффективно и удобно.
Опять же эти диаграммы предельно понятны даже заказчику и легко можно посмотреть не упустили ли Вы чего. Даже объяснить что такое 1---* не сложно. И предлагать Вам тоже никто не запрещает.
Но Ваш подход тоже работает, тут я не спорю. Тут кто к чему привык, главное, чтобы было эффективно и удобно.
С этим полностью согласен, просто речь шла о первой встрече. Тут бы с предметной областью разобраться и попросту зафиксировать понятия, не вдаваясь в детали, об атрибуте или взаимосвязанной сущности идет речь.
Как правило, после первой встречи я обязательно подготавливаю диаграмму сущность-связь, где фиксирую свое видение предметной области. Эту диаграмму можно обсудить со специалистом со стороны Заказчика.
Как показывает практика, лицо, принимающее решение, обычно слабо разбирается в предметной области. Приходится самому анализировать, докапываться, додумывать, а потом предварительный артефакт - составленную диаграмму - выкатывать Заказчику для обсуждения. В этом случае Заказчик гораздо охотнее организует вторую встречу (с участием специалистов предметной области), а там уже и до проекта недалеко:-)
Ваш подход к спецификации требований тоже работает, но, на мой взгляд, на первой встрече малоприменим. В том числе и потому, что если Вы зададите Заказчику слишком много вопросов по предметной области, на которые он не сможет ответить, то тем самым можете выявить его некомпетентность и оставить в итоге у него неприятный осадок. Чисто психологически неприятный. Никаких объективных преград для обсуждения сущностей "с места в карьер" не существует.
Как правило, после первой встречи я обязательно подготавливаю диаграмму сущность-связь, где фиксирую свое видение предметной области. Эту диаграмму можно обсудить со специалистом со стороны Заказчика.
Как показывает практика, лицо, принимающее решение, обычно слабо разбирается в предметной области. Приходится самому анализировать, докапываться, додумывать, а потом предварительный артефакт - составленную диаграмму - выкатывать Заказчику для обсуждения. В этом случае Заказчик гораздо охотнее организует вторую встречу (с участием специалистов предметной области), а там уже и до проекта недалеко:-)
Ваш подход к спецификации требований тоже работает, но, на мой взгляд, на первой встрече малоприменим. В том числе и потому, что если Вы зададите Заказчику слишком много вопросов по предметной области, на которые он не сможет ответить, то тем самым можете выявить его некомпетентность и оставить в итоге у него неприятный осадок. Чисто психологически неприятный. Никаких объективных преград для обсуждения сущностей "с места в карьер" не существует.
По разному бывает. С случае больших и сложных проектов часто бывают и технические специалисты, особенно если Вы приходите не с улицы, а по рекомендации.
Но опять же, я могу дать некоторые советы исходя из своего опыта, а действовать все равно всегда приходится исходя из особенностей ситуации и отвечать за результат самому :)
Кстати профессионализм, если Вы не просто тупо грузите заказчика техническими терминами и адскими диаграммами, а просто действуете четко и логично оставляет исключительно приятное впечатление.
Но опять же, я могу дать некоторые советы исходя из своего опыта, а действовать все равно всегда приходится исходя из особенностей ситуации и отвечать за результат самому :)
Кстати профессионализм, если Вы не просто тупо грузите заказчика техническими терминами и адскими диаграммами, а просто действуете четко и логично оставляет исключительно приятное впечатление.
Полезная статья, как программисту, мне было бы удобно и приятно работать с таким менеджером проекта. А то регулярные быстрые объяснения на словах функциональных частей сайта, зачастую, приводят к "легкому" недопониманию, что вытекает в дополнительные доработки и скольжению по лезвию в отношении сроков.
Статью в избранное.
Однако есть другая грань.
В своей работе придерживаюсь правила: первое знакомство - это тест на человеческую совместимость.
Бывает, что и я готов, и клиент конкретен, а контакта нет, и желания нет работать и зарабатывать.
По всем показателям - я лучший. А заказ уходит еще кому-то.
На каждого продавца есть свой покупатель.
Однако есть другая грань.
В своей работе придерживаюсь правила: первое знакомство - это тест на человеческую совместимость.
Бывает, что и я готов, и клиент конкретен, а контакта нет, и желания нет работать и зарабатывать.
По всем показателям - я лучший. А заказ уходит еще кому-то.
На каждого продавца есть свой покупатель.
Скажу по личному опыту, что UML в этих делах не помощник для первой встречи, скорее для последующих, которые будут носить более предметный характер. Для первой встречи очень даже подходит описание бизнес-логики и бизнес-процессов (EPC) по методологии ARIS. Люди, знакомые с ARIS'ом подтвердят, что его концепция и графическое представление максимально ориентированы на определение первичных потребностей заказчика.
Статья отличная! Но вот я - заказчик - женщина, соответственно с порушенным мозгом и нестандартной логикой ;)
Через 5 минут - с Вами рассталась бы!
Терплю непрофессионалов, именно по причине того, что они не жрут мое время, а - напрмер, отсылают куда-нить ещё, а понимая, что там - не лучше, соглашаюсь на все не глядя, но быстро..., надо решать мульон новых текущих проблем...
Возможно, теряю на качестве, но лень переходить на новых людей...
Вывод: многих устроит 30 минут воды, непиара, типа реально будет нормалек, но не круть, и тд и тп...
Но статью учту)))))
Через 5 минут - с Вами рассталась бы!
Терплю непрофессионалов, именно по причине того, что они не жрут мое время, а - напрмер, отсылают куда-нить ещё, а понимая, что там - не лучше, соглашаюсь на все не глядя, но быстро..., надо решать мульон новых текущих проблем...
Возможно, теряю на качестве, но лень переходить на новых людей...
Вывод: многих устроит 30 минут воды, непиара, типа реально будет нормалек, но не круть, и тд и тп...
Но статью учту)))))
ну я, да и все остальные - это же не роботы, которые действуют по одной программе :)
если человеку тяжело, а это обычно видно, то надо осторожно и не спеша задавать вопросы в щадящем режиме
а непрофессионалов я нигде не терплю. просто, не люблю некачественную работу.
если человеку тяжело, а это обычно видно, то надо осторожно и не спеша задавать вопросы в щадящем режиме
а непрофессионалов я нигде не терплю. просто, не люблю некачественную работу.
Непрофессионалов и некачественную работу и я не люблю, вот может посидев на habrahabr зарегившись (а читаю оч давно постоянно), начну разбираться кто есть кто сразу, однако, уже привыкла, что о результате говорят все одинаково обнадеживающе, а по факту - редко получаю желаемое... Оттого и здесь, оттого и саморазвиваюсь)))
тут уже от требуемого результата зависит :) В статье говорится о профессиональном подходе к проектированию, а не "за 30 минут, но побыстрее". Я однажды с заказчиком просидел порядка четырех часов (на первой встрече(!), но сразу после неё мы приступили, и сейчас успешно делаем проект.
Я может не очень понимаю суть требований, но как показывает опыт - результат один - что 30 мин сиди, что 4 часа, если повезло - профессионал - сделает отлично, а нет - так хоть 2 месяца поясняй - воз и ныне там...
*это мой горький опыт, не догма*
*это мой горький опыт, не догма*
На самом деле нет. За 30 минут просто физически не успеваешь спроектировать даже начальную структуру и механику проекта. Обычно встречи длятся у меня порядка 1,5-2х часов. Но есть немаловажный момент - особенности рынка. В нашем городе без плясок с выяснениями требований не обойтись, поэтому так долго. Возможно у вас по другому. А этот проект за 4 часа - продумывали всё до деталей, вплоть до того, как будет выглядеть ЧПУ, и всё равно по мелочам переделываем структуру. Главное, что "ПО МЕЛОЧАМ", а не кусками. Это уже большущая выгода от потраченных 4х часов, тем более, что они оплачивались как "консультация".
карандаши с точилкой - это жесть :)) 21 век, казалось бы..
Скорее, тянет на конец встречи для уточнения частностей, чем брать за основной процесс по составлению ТЗ проекта. И не только по сайтостроению ;)
Если говорить о серьезном проекте, то первая встреча никак не должна длиться 2 часа. Для начала заказчику необходимо объяснить как, вообще, с Вами работать. Как будет вестись работа, что будет от него требоваться и, естественно, из чего будет формироваться стоимость. А для этого Вы сами должны четко знать как это должно быть. Потому что заказчик всегда спрашивает: И если заказчика это устраивает, то можно продолжать с ним встречаться и работать.
"Я экономлю свое и чужое время, сокращая количество встреч." А это, по-моему, зря. В процессе работы очень важна коммуникация с заказчиком. Иначе появятся проблемы с тем, что выполненная работа не соотвествует требованиям заказчика. ()
"Я экономлю свое и чужое время, сокращая количество встреч." А это, по-моему, зря. В процессе работы очень важна коммуникация с заказчиком. Иначе появятся проблемы с тем, что выполненная работа не соотвествует требованиям заказчика. ()
Насчет карандашей- правда, в руках смотрится все таки как инструмент художника, а не тупая офисная ручка. Насчет ЦВЕТНЫХ крандашей, это конечно интереснее.
Sign up to leave a comment.
Первая встреча с Заказчиком, выжимаем максимум.