Я уже несколько лет занимаюсь управлением проектов по заказной разработке ПО и часто в начале моей работы, меня беспокоил вопрос о том, как именно я могу извлечь максимальное количество полезной и структурированной информации о будущей системе. Ведь чаще всего, даже для коммерческого предложения необходимо представлять и технологии и примерные способы реализации, а это все может сильно менять цену. Да и про сроки неплохо бы рассказать.
Я сумел найти для себя оптимальный вариант.
При первых встречах я всегда мечтал улавливать мысли, ведь согласитесь, не всякий человек может излагать мысли последовательно и структурировано. Чаще всего у заказчика в голове легкий хаос с калейдоскопом прекрасных видов будущей системы, а также прекрасных картин того как мгновенно идет в гору его бизнес сразу после внедрения. А если задавать вопросы без четкого плана, встречи могут затянуться надолго.
Сейчас я действую по плану и это позволяет мне сразу выигрывать по многим направлениям:
В чем же состоит мой план?
Я запасаюсь обычным и цветными карандашами, точилкой, ластиком и альбомом для рисования. Это гораздо удобнее, чем набор листов, да и бумага плотнее, что позволяет ей не комкаться при стирании.
Поможет вспомнить какие-то важные моменты из встречи, если Вы их забудете потом, при анализе результатов. Да и в любом случае, освежить память никогда не помешает. Только не забудьте предупредить человека, что Ваша встреча записывается, может быть он будет против этого, хотя вероятность этого небольшая.
Можно встречаться в офисах, хотя лично мне больше нравится в кафе. Все таки наши офисы обычно представляют собой абсолютно неуютные места, а для встречи и хорошего разговора место нужно уютное, лучше бы еще и со вкусным кофе или чаем. Только конечно кафе должно быть без громкой назойливой музыки, а то встреча будет испорчена.
Может быть Вам пригодится компьютер, чтобы показывать клиенту какие-то предыдущие результаты или, допустим, оценивать работу тех или иных элементов интерфейса в действии. Однако, старайтесь меньше времени уделять компьютеру, а то рискуете завязнуть и отдалиться от конструктивной, четкой беседы. Используйте компьютер только в режиме вопрос-ответ.
Получите общее представление о системе. Что будет делать, для кого предназначена. Попросите заказчика четко дать описание системы в двух абзацах, опишите всех пользователей и ролей. Вот совет, который поможет Вам: представьте, что система абсолютно чиста. Кто первый будет вносить туда информацию? Что это будет за информация? Как ее будут туда вносить?
Я лично стараюсь использовать списки действий и UML нотацию. Это удобно, сразу структурирует информацию, ее легко анализировать и делать выводы, а также предугадывать узкие места, на которые сразу же стоит обратить внимание.
Я рисую диаграммы двух типов: диаграммы действий и структурную композитную диаграмму. Так же, если мы обсуждаем интерфейс, я стараюсь делать наброски интерфейса и важные места помечать цветными карандашами.
Вот небольшой пример, записанный со слов заказчика:
Есть работники производственного отдела. Они составляют перечни оборудования, заполняют их свойства и позиции перечня. А, кстати, к позициям перечня они прикрепляют файлы, ну можно сделать их во всплывающем окне.
В итоге получаем две диаграммы. Одна показывает действия работников производственного отдела, другая отношения между сущностями.
Диаграммы не претендуют на полноту описания, они служат только лишь примером документации. В дополнение можно накидать интерфейс блоками и прикинуть делать ли файлы во всплывающем окне или нет.
Если Вы будете продолжать работать с проектом, то после встречи хорошей идеей будет перенести все с бумаги в электронный вид, заодно освежить и дополнить.
Результаты в виде таких диаграмм, а также возможно кратких историй (userstories), в случае размытых требований, легко можно послать заказчику, никакими особыми знаниями, чтобы их прочитать обладать не нужно.
По сути, Вы уже сэкономили немало времени, потому как заложили фундамент будущей достойной и полной документации по проекту. За такое подробное и иллюстрированное техническое задание Вам скажут спасибо не только заказчик, но и будущие программисты.
Интересных Вам проектов и удачных обсуждений!
Оригинал: http://www.steinzeig.ru/2007/12/09/rabota-s-zakazchikom-pervaya-vstrecha/
Я сумел найти для себя оптимальный вариант.
При первых встречах я всегда мечтал улавливать мысли, ведь согласитесь, не всякий человек может излагать мысли последовательно и структурировано. Чаще всего у заказчика в голове легкий хаос с калейдоскопом прекрасных видов будущей системы, а также прекрасных картин того как мгновенно идет в гору его бизнес сразу после внедрения. А если задавать вопросы без четкого плана, встречи могут затянуться надолго.
Сейчас я действую по плану и это позволяет мне сразу выигрывать по многим направлениям:
- Я экономлю свое и чужое время, сокращая количество встреч. Особенно это становится актуальным в связи с повальным увлечением личностной эффективностью.
- Я сразу показываю себя профессионалом с определенным подходом в работе. Это дает мне дополнительные очки и отбирает их у потенциальных конкурентов.
- Я глубоко погружаюсь в систему и уже могу написать предварительное ТЗ для исполнителей по ней или по ее отдельной части (в случае, если система большая).
В чем же состоит мой план?
Подготовка к встрече
Принадлежности для письма
Я запасаюсь обычным и цветными карандашами, точилкой, ластиком и альбомом для рисования. Это гораздо удобнее, чем набор листов, да и бумага плотнее, что позволяет ей не комкаться при стирании.
Диктофон
Поможет вспомнить какие-то важные моменты из встречи, если Вы их забудете потом, при анализе результатов. Да и в любом случае, освежить память никогда не помешает. Только не забудьте предупредить человека, что Ваша встреча записывается, может быть он будет против этого, хотя вероятность этого небольшая.
Место
Можно встречаться в офисах, хотя лично мне больше нравится в кафе. Все таки наши офисы обычно представляют собой абсолютно неуютные места, а для встречи и хорошего разговора место нужно уютное, лучше бы еще и со вкусным кофе или чаем. Только конечно кафе должно быть без громкой назойливой музыки, а то встреча будет испорчена.
Ноутбук
Может быть Вам пригодится компьютер, чтобы показывать клиенту какие-то предыдущие результаты или, допустим, оценивать работу тех или иных элементов интерфейса в действии. Однако, старайтесь меньше времени уделять компьютеру, а то рискуете завязнуть и отдалиться от конструктивной, четкой беседы. Используйте компьютер только в режиме вопрос-ответ.
Встреча
С чего начать?
Получите общее представление о системе. Что будет делать, для кого предназначена. Попросите заказчика четко дать описание системы в двух абзацах, опишите всех пользователей и ролей. Вот совет, который поможет Вам: представьте, что система абсолютно чиста. Кто первый будет вносить туда информацию? Что это будет за информация? Как ее будут туда вносить?
Как фиксировать?
Я лично стараюсь использовать списки действий и UML нотацию. Это удобно, сразу структурирует информацию, ее легко анализировать и делать выводы, а также предугадывать узкие места, на которые сразу же стоит обратить внимание.
Я рисую диаграммы двух типов: диаграммы действий и структурную композитную диаграмму. Так же, если мы обсуждаем интерфейс, я стараюсь делать наброски интерфейса и важные места помечать цветными карандашами.
Вот небольшой пример, записанный со слов заказчика:
Есть работники производственного отдела. Они составляют перечни оборудования, заполняют их свойства и позиции перечня. А, кстати, к позициям перечня они прикрепляют файлы, ну можно сделать их во всплывающем окне.
В итоге получаем две диаграммы. Одна показывает действия работников производственного отдела, другая отношения между сущностями.
Диаграммы не претендуют на полноту описания, они служат только лишь примером документации. В дополнение можно накидать интерфейс блоками и прикинуть делать ли файлы во всплывающем окне или нет.
Как закончить?
Если Вы будете продолжать работать с проектом, то после встречи хорошей идеей будет перенести все с бумаги в электронный вид, заодно освежить и дополнить.
Результаты в виде таких диаграмм, а также возможно кратких историй (userstories), в случае размытых требований, легко можно послать заказчику, никакими особыми знаниями, чтобы их прочитать обладать не нужно.
По сути, Вы уже сэкономили немало времени, потому как заложили фундамент будущей достойной и полной документации по проекту. За такое подробное и иллюстрированное техническое задание Вам скажут спасибо не только заказчик, но и будущие программисты.
Интересных Вам проектов и удачных обсуждений!
Оригинал: http://www.steinzeig.ru/2007/12/09/rabota-s-zakazchikom-pervaya-vstrecha/
