Мне нравится
21В разных источниках литературы по продажам можно найти разное количество этапов продажи . Каждый автор рассматривает их со своей точки зрения.
Предлагаю рассмотреть ключевые этапы в работе с Клиентом>:
1 этап «Вступление в контакт» или «Установление контакта»
С этого этапа начинается любая продажа .
Цель данного этапа : расположить к себе Клиента и заинтересовать его в дальнейшем контакте.
При установлении контакта с Клиентом важно поприветствовать его и представиться
«Добрый день. Меня зовут Михаил, я менеджер компании «Окна плюс».
Прежде чем начать разговор о потребностях Клиента, рекомендуется пообщаться с ним на отвлеченную тему (техника «Малого разговора»), либо предложить чай, кофе, можно сделать комплимент либо использовать ряд других техник этапа установления контакта.
«Что вы знаете о нашей компании? Почему выбрали именно нас? Что планируете приобретать?»
Важно, чтобы менеджер своим невербальным поведением демонстрировал заинтересованность в контакте с Клиентом, желание ему помочь, доброжелательность. Невербальное поведение включает в себя – открытые жесты, поза, улыбка, наклон корпуса в сторону Клиента, открытый взгляд.
Определить установлен контакт с Клиентом или нет можно по поведению Клиента. Если он позитивно реагирует на слова менеджера, чувствует себя расслабленно, сам задает вопросы, можно предположить, что контакт установлен. Если Клиент не поддерживает зрительный контакт с менеджером, напряжен, не отвечает на вопросы или отвечает неохотно, то имеет смысл больше времени уделить этапу установления контакта.
2 этап «Выявление потребностей»
Цель данного этапа : определить потребности Клиента.
Чем точнее менеджер определит потребности Клиента, тем эффективнее проведет презентацию товаров и услуг, что в последствии приведет к сделке.
При выявлении потребностей менеджеру важно уметь задавать вопросы и слушать Клиента.
При взаимодействии с Клиентом важно, чтобы больше говорил он, а не менеджер, для этого менеджеру рекомендуется задавать больше открытых вопросов .
«Какое окно вы планируете приобрести? Где будете менять окно? Какой климат в квартире зимой и летом? Кто еще проживает в квартире? По каким признакам Вы выбираете окно?»
Закрытые вопросы менеджера позволяют конкретизировать потребности Клиента.
«Вы часто проветриваете помещение? У Вас есть животные? Вам удобно если наш замерщик приедет завтра в 9 утра?»
Альтернативные вопросы предлагают клиенту выбор вариантов.
«Вам удобно чтобы замерщик приехал с утра или после обеда? Установку новых окон планируем на этой неделе или на следующей?»
В течение всей встречи с Клиентом полезно его внимательно слушать, так как зачастую Клиенты сами открыто говорят о своих потребностях. Если какие – то слова Клиента непонятны менеджеру или он их прослушал, желательно задать Клиенту уточняющие вопросы:
«Правильно ли я понял, что Вам нужно окно с повышенной шумоизоляцией? Насколько я понял, Вы хотите, что одна створка окна была поворотной, а другая – поворотно-откидной?»
Желательно подводить промежуточный итог после каждого обсуждаемого вопроса. Особенно если менеджер обсуждает с Клиентом несколько продуктов или услуг.
«Таким образом, мы с Вами договорились, что замер произведем завтра, а устанавливать окна будем на следующей неделе в пятницу. Итак, Вы планируете ставить два новых окна: в кухне двустворчатое с поворотно-откидными створками, а в комнате трехстворчатое, в котором две створки поворотно-откидные и одна «глухая»».
Важно точно выявить потребности клиента и только потом проводить презентацию товаров и услуг.
3 этап «Презентация»
Цель: предложить продукт или услугу максимально удовлетворяющие потребности Клиента.
В презентации продуктов и услуг содержится описание характеристик товаров и услуг, преимуществ от их использования клиентом и выгод, которые получает потребитель.
Полезно начинать презентацию с ключевых выгод Клиента, которые вытекают из потребностей покупателя, выявленных менеджером на предыдущем этапе.
Важно различать, чем преимущество продукта и услуги отличается от выгоды.
Преимущество – это польза, которую получает любой Клиент, используя данный продукт или услугу.
«С помощью данной услуги Вы сможете сэкономить время и сократить расходы на 10%». «Данная фурнитура позволяет сократить количество регулировок».
Выгода – это характеристика или преимущество, которые позволяют удовлетворить конкретную потребность Клиента.
Таким образом, любая характеристика или преимущество могут стать выгодой, при условии, что у Клиента в этом есть потребность.
«Вы хотели, чтобы окно легко открывалось и закрывалось, фурнитура европейского качества сможет это обеспечить». «Вы говорили, что квартира находится на первом этаже и Вы опасаетесь за безопасность квартиры, предлагаю Вам установить на новые окна противовзломную фурнитуру».
В процессе презентации менеджеру необходимо включать Клиента в активный диалог, используя вопросы.
«Как Вы относитесь к моему предложению?», «Что Вы думаете по этому поводу?», «Как Вам мое предложение?»
4 этап «Работа с возражениями»
Цель: развеять сомнения Клиента относительно покупки и снять негатив в отношении продукта или услуги.
Для того, чтобы сократить количество возражений Клиента, менеджеру полезно больше времени уделять предыдущим этапам. Часто возражения Клиентов связаны с тем, что плохо установлен контакт с ним, частично выявлены его потребности, либо презентация товаров и услуг была не интересна Клиенту, слишком длинная и не удовлетворяющая его потребности.
Важно, воспринимать возражения Клиента как сигнал о том, что менеджеру нужно скорректировать свое поведение (особенно если возражений очень много).
Возражения у Клиента могут возникнуть и на предыдущих этапах продажи. Как же работать с возникающими возражениями?
Эффективно придерживаться схемы работы с возражениями:
1. выслушать Клиента;
2. нейтрализовать его эмоции, используя фразы понимания;
«Я вас понимаю», « Да, соглашусь, что неприятно…»
3. уточнить при необходимости информацию с помощью вопросов;
4. предложить конструктивные варианты решения или сделать альтернативное предложение.
Возражения Клиента бывают 4 видов:
1. возражения, связанные с изменениями.
«Зачем мне это нужно», «Я не вижу в этом смысла»
В работе с таким возражением менеджер должен объяснить Клиенту, что риски исключены, показать последствия, если ситуация сохранится, привести примеры, положительного опыта использования чего – либо впервые.
«Приобретая окно с европейской фурнитурой, Вы гарантированно защищены от сквозняков, дополнительных регулировок прижима створок, заедания механизма закрывания».
2. возражения, связанные с ценой.
«Это дорого для меня».
В аргументации менеджеру следует обратить внимание на дополнительную пользу, которую получает Клиент, можно сравнить стоимость товара со стоимостью любой другой не особо нужной вещи или разделить стоимость на какой-либо промежуток времени.
«Приобретая окно в нашей компании, Вы получаете в подарок набор по уходу за окнами, а также возможность воспользоваться бесплатной регулировкой фурнитуры», «Новое красивое окно в кухне будет Вам стоить всего 300 руб. в день».
3. возражения, связанные с негативным опытом.
«Я слышал у Вас плохой профиль».
Менеджеру полезно уточнить информацию, задав вопросы Клиенту, показать Клиенту, что Вы его понимаете и признаете факты неприятных событий (в случае они были в действительности) и затем предложить альтернативный вариант решения.
«Да действительно, у нас была партия бракованного профиля, который мы вернули поставщику. На данный момент мы получили новую партию, уже изготовили и установили более 30 окон, все Клиенты довольны».
4. возражения, связанные с принятием решения.
«Мне надо подумать», «Нужно посоветоваться с женой».
В работе с такими возражениями менеджеру можно еще раз уточнить, с чем связано такое решение, убедиться, что клиент воспринял и понял всю информацию, а также воспользоваться методами завершения сделки.
«Если мы с Вами подпишем договор сейчас, то уже в конце недели Вы сможете любоваться новым окном на кухне». «Только до конца месяца у нас действует скидка на данный товар».
5 этап «Завершение сделки»
Цель: подтолкнуть Клиента к сделке и подтвердить правильность принятого им решения.
Прежде чем завершать сделку (подписывать договор) менеджеру необходимо убедиться, что Клиент готов заключить сделку.
Это можно увидеть по сигналам, которые он показывает:
- положительные отзывы о продукте или услуге;
- Клиент выражает одобрение словам менеджера (поддакивает, кивает головой и тд.);
- прямо говорит, что он согласен;
- задает уточняющие вопросы.
Методы завершения сделки:
1. метод ограничения условий и времени.
«Если Вы подписываете договор сегодня, то мы даем Вам скидку на окно 20%».
2. метод комплимента.
«Вы действительно сделали правильный выбор».
3. беспроигрышная альтернатива.
«Вас записать на замер во вторник или в среду?»
В завершении хочется сказать, что эффективность продаж зависит от мастерства менеджеров. Чем большим количеством методов, техник продажи владеет менеджер , тем он гибче и успешнее при взаимодействии с Клиентом. Профессия менеджера по продажам требует постоянного развития и самосовершенствования навыков. Желаем вам успехов на пути профессионального роста и повышения продаж.
Всем доброго времени суток! Сегодня хотел бы поговорить о путях взаимодействия клиента c аутсорсинговой компании, а также получить от Вас комментарии того, как Вы взаимодействуете со своими клиентами/разработчиками ПО. Данная статья написана на основании опыта работы и, по большей части, предназначена для заказчиков ПО. Целью является найти «узкие» места в вопросах отношений между заказчиком и компанией, которая предлагает услуги по разработке ПО.
Разрешите представиться: Я – Корхов Юрий и эта статья у меня на хабре первая. Закончил Белорусский Национальный Технический Университет (инженер по безопасности), Белорусский Государственный Университет (инвестиционный менеджер). Стаж работы - более 6 лет в IT на практически всех должностях: webmaster, верстальщик, web-дизайнер, программист, менеджер-проекта и по совместительству разработчик UI, руководитель отдела… В общей сложности, за это время, реализовано более 80 проектов: от маленьких сайтов, игр для мобильных телефонов до крупных интернет-порталов… Основной профиль - управление ходом разработки проектов в IT сфере. Работал как на стороне заказчика так и на стороне разработчика, как на Российский рынок так и на зарубежный.
Предыстория создания поста или Спасибо Wargaming.
Обойти историю создания данного поста было бы не хорошо, т.к. хабр я читаю уже очень давно, а вот написать статью руки никак не доходили, а здесь дело “случая” и вот статья готова.
Уже пару месяцев я отдыхаю от работы, потому что устал от аутсорсинга, решил найти смысл жизни и неторопливо подготовить к запуску свой проект, и в один прекрасный день раздался звонок. Рекрутер Wargaming (основатели “танчиков” и, по-моему мнению, одной из лучших фирм в Минске) позвонил мне с предложением пройти собеседование на вакансию Vendor Manager (здесь следует сказать, что работу я не искал, и, судя по их вакансии, я не очень подходил им). “Это же интересно!” - подумал я и решил выполнить тестовое задание, тем более, что оно было достаточно интересным для меня. Рекрутер сообщил, что у них созданы все условия для приятной, здоровой (фитнес, страховка и т.д) и высокооплачиваемой работы а также, что не маловажно, для выполнения тестового задания мне потребовалось бы около 3х часов. Я сомневаюсь, что у кого-то получилось бы сделать все тестовое задание в течение указанного срока, что касается меня – в общей сложности ушло около 6 часов.
К моему сожалению, feedback от компании был в телефонном разговоре и выражался сухой фразой “всё хорошо, всем понравилось” (дословно не помню, но суть такая) и без какой-то конкретики. Я сомневаюсь, что мне удалось указать все основные «узкие» места, а т.к. не хорошо пропадать труду, решил разместить ответы на тестовое задание (с небольшими изменениями, для удобства) на суд общественности и буду признателен аудитории habra за дополнения и здоровые комментарии к статье.
Схема взаимодействия заказчик – разработчик программного обеспечения от первого знакомства до окончания взаимоотношений.
При разработке схемы я подразумеваю:- Разработчик ПО способен выполнить проект.
- С разработчиком ПО до этого договор не подписывался и никаких проектов не было.
- ТЗ уже готово.
- Условия оплаты регулируются договором.
- Системы управления проектами и методологии разработки ПО (XP, Scrum, Lean, Kanban, ScrumBut и т.д.) используются.
- Наполнение контентом приложения (если это необходимо) делается средствами клиента.
Аспекты контракта между software development вендором и заказчиком вендору выгодно избежать (упростить, вообще убрать из контракта).
- Ответственность за соблюдение сроков лежит на стороне разработчика и в случае, если срыв сроков происходит в последний момент (т.е. разработчик заранее не уведомил о том, что не успевает до закрытия) должны накладываться штрафные санкции (здесь большой выбор вариантов).
Причина: срыв сроков - одна из самых больших проблем и упоминать это в договоре не очень интересно, т.к. в большинстве своем срыв сроков лежит на стороне разработчика. Здесь нужно учитывать, что точно рассчитать сложно, но заранее предупредить о том, что разработчик не успевает выполнить этап разработки в определенный срок - обязан и это нужно прописывать в договоре. - Условия гарантий исправлений «багов» по вине разработчика, которые не были вовремя выявлены. Обычный срок гарантии 3 месяца.
Причина: часто бывает, что некоторые “баги” не были устранены или появились уже в процессе работы, поэтому этот пункт часто пытаются не указывать или уменьшать время гарантии. Мое мнение, что меньше 3х месяцев мало. - Права на разработанное ПО, модули, блоки и т.д. принадлежат заказчику и не могут применяться для последующей перепродажи.
Причина: разработчику выгодно обладать правами на интеллектуальную собственность или иметь возможность продавать/использовать наработки для других клиентов, что в свою очередь может поставить заказчика в неудобную ситуацию на рынке. - При разработка нового модуля в системе, который влияет на работу других модулей или всей системы, разработчик должен обеспечеить функционирование всей системы.
Причина: часто разработка одного модуля может навредить работе другого модуля или вообще всей системе и дальнейшие доработки могут лечь на “плечи”(финансово) клиента. Разработчик обязан учитывать структуру всей системы и в случае “багов”, найденных клиентом, править бесплатно. - Техническая документация на разработку должна составляться с учетом требований заказчика.
Причина: разработчикам выгодно полностью привязать себя к заказчику и часто бывает, что документация не ведется. - В случае разработки веб-сайта, исполнитель обязан учитывать SEO оптимизацию для сайта, а именно: описание изображений, страниц…
Причина: экономия времени на “мелочи”, что в зависимости от условий договора может привести к финансовым потерям заказчика (разработчик ПО экономит время/финансы). - Тестирование системы должен обеспечивать разработчик системы.
Приемка заказчиком готового модуля не должна превращаться в тестирование системы, т.е. разработчик обязан взять на себя устранение выявленных “багов” клиентом за свой счет. Это нужно для того, чтобы обеспечить качественное тестирование продукта со стороны разработчика. К моменту, когда разработчик говорит “сделано” и начинается тестирование на стороне клиента - “баги” правятся бесплатно. - Ответственность за размещение проекта на стороне заказчика берет на себя разработчик. При этом заказчик обязан обеспечить выполнение технических требований для площадки.
Причина: размещение проекта на стороне заказчика иногда может вызвать определенные трудности, что может привести к “шапкозакидательству”, поэтому ответственность по размещению и настройке сервера должна быть на стороне разработчика ПО. - В случае если разработчик ПО вынужден прибегнуть к помощи специалистов вне своей команды он обязан взять на себя все сопутствующие риски за утечку, потерю данных или любой другой ущерб, который может нанести своим действием или бездействием сотрудник со стороны.
Причина: бывает, что у разработчика может заболеть, уволиться и т.д. кто-нибудь из сотрудников. В этом случае заказчик должен быть застрахован. - Резервные копии проекта должны обеспечиваться на стороне разработчика не реже 1 раза в сутки. Любые проблемы с потерей данных по проекту должен брать на себя разработчик.
Причина: здесь нужно обозначить кто несет ответственность за сохранность проекта в случае каких-либо сбоев. - Разработчик должен исходить из популярности использования применяемых им технологий при выборе.
Причина: привязка к собственным технологиям, которые усложнят жизнь в случае перехода заказчика к другому разработчику.
Известные способы завышения стоимости аутсорсинговых работ относительно реальности.Полагаю их больше.
- Поверхностная оценка стоимости разработки проекта целиком, без разбиения на этапы, что может привести к 2х-3х кратному превышению стоимости проекта.
- Не предоставление отчетов о проделанной работе в определенный по договору срок или не возможность контролировать ход разработки со стороны клиента
- Неправильный выбор технологии при реализации технической части, может значительно увеличить стоимость разработки.
- Отсутствие в команде разработчика нужных специалистов, что увеличивает время и стоимость разработки.
- Фиксированная установка стоимости разработки проекта или модуля и дальнейшее увеличение стоимости за каждую мелочь, которую обе стороны понимали по разному.
- Фиксированная установка стоимости разработки проекта - более высокий риск заставляет закладывать в стоимость проекта.
- При разработке дизайна не используется прототипирование, а разработка дизайна ведется на основе текстового ТЗ, что в итоге приводит к большому количеству доработок/исправлений и соответственно увеличению стоимости проекта.
- Добавление/усложнение функционала. Можно сделать проще - делают сложней.
- “Красивости” там где они не нужны (можно сказать про админ. часть сайта, если можно использовать css фреймворки для быстрой кастомизации админ. части - начинают разрабатывать с нуля).
Шаблон взаимоотношений ‘заказчик - software development vendor’, который, как мне кажется, наиболее близок к практическому использованию.
Многие аутсорсинговые компании предпочитает не предоставлять доступ к своим системам управления проектами, не предоставляя подробную информацию, лично считаю, что доступ должен предоставляться по желанию заказчика. Клиент является ответственным за реализацию проекта и видеть ход разработки в реальном времени - важно!Основные моменты при взаимодействии разработчика ПО и клиента, которые считаю оптимальными:
Также, считаю, что разрабатывать ПО с учетом расчета полной стоимости проекта - трата средств и нерв, такая разработка обычно приводит к конфликтным ситуациям.
- Оплата работы исходя из почасовой оплаты работы сотрудников или усредненной стоимости работы специалиста всей команды разработчика. Оценку этапов разработки делать необходимо. Почему считаю эту форму расчета цены оптимальной:
- Не требует очень щепетильного подхода в оценке проекта, которую сделать на 100% точной практически нереально. В случае если оценка сделана неверно и разработчик ПО это начинает понимать, то происходит “ущемление” функционала везде где только можно, что в итоге будет сказываться на удобстве использования.
- Улучшает взаимопонимание между разработчиком ПО и клиентом, т.к. основная задача сводится к принципу - “сделай качественно и быстро”, а не “вложись в жесткий бюджет и как будет работать так и хорошо”.
- Клиент, на основе ежедневных отчетов о затраченных часах, может видеть какое время тратят сотрудники на разные блоки при разработке, что дает понимание скорости и качества работы сотрудников разработчика ПО.
- Взаимодействие между заказчиком и менеджером-проекта ведется максимально на прямую, т.е. при использовании skype, телефонов и т.д.
- Только 2х недельные отчеты и планы должны пересылаться в обязательном порядке по почте (для контроля).
- Клиент предоставляет прототип приложения или его разрабатывает команда разработчика ПО, если это необходимо:
- Упрощает понимание основного функционала проекта.
- Увеличивает общую скорость разработки проекта.
- Понятные требования к функционалу как у заказчика так и у разработчика.
- Ясное понимание куда будет двигаться проект.
- Система управления проектами для ведения хода реализации проекта и возможности мониторинга процесса, времени разработки, потраченной на каждую задачу в отдельности. К сожалению, доступ редко предоставляют разработчики.
- Желательно, чтобы весь проект делала одна команда, т.е. не должно быть такого, что один этап делает одна компания, другой - другая и т.д.
- Контрольные точки (“забег”) каждые 2 недели- оптимальное время для контроля проекта.
- В разработке предпочтение отдается известным фреймворкам, также для более простой адаптации в случае какой-либо ситуации, когда необходимо передать проект другим разработчикам.
- Качественное тестирование на стороне разработчика - прямая обязанность. При передаче клиенту проекта или какой-то его части, всё должно быть проверено досконально.
- Поддерживать разные браузеры - прямая задача разработчика
Вывод : главное придерживаться партнерских/взаимовыгодных и доверительных отношений с пониманием того, что разработчики такие же люди и усложняя им жизнь усложняешь жизнь и себе! Каждый должен отвечать за свою часть работы, клиент-за предоставление внятного ТЗ и отвечать оперативно на возникающие вопросы, не забывая оплачивать работу, а разработчик - за качество, сроки, скорость. Идеал, конечно, не достигнут, но мы на верном пути.
Семь шагов для создания эффективного ИТ-подразделения Гредников Сергей
5. Взаимодействие с Заказчиком
Ранее рассматривался вопрос формирования плана по ИТ-подразделению на основе поступивших Заявок от пользователей ИТ-сервисов. Возникает вопрос: как сделать процесс сбора Заявок эффективным? Это один из вопросов, который необходимо решить руководителю ИТ-подразделения в целях оптимизации времени на реагирование ИТ-подразделения на текущую потребность пользователя. Другими словами, завтра «раки по пять рублей» уже не нужны – они нужны сегодня и по «три рубля», а может и наоборот: завтра «раки даже по три рубля» не нужны, они нужны сегодня пусть и по пять.
Наиболее подходящее решение – это применение аппаратно программного комплекса (далее по тексту – АПК), позволяющего обрабатывать Заявки пользователей и накапливать статистику по выполненным Заявкам в различных разрезах. Применение АПК существенно сокращает время прохождения запроса от момента его инициации до принятия в работу конкретным ИТ-специалистом. Также при применении АПК наблюдается экономия расходных материалов таких как: офисная бумага, картриджи и/ или тонер, при условии заправки картриджей силами ИТ-подразделения. При появлении истории обработки (выполнения) Заявок, появляются возможности проведения аналитических исследований и формирования базы знаний предприятия. Отдельным плюсом необходимо отметить перераспределение нагрузки на ИТ-персонал, например: программист должен программировать, а не «срочно» отвечать на вопрос пользователя, который пришел к нему и ждет очереди (из других таких же пользователей), когда тот освободится! Для подобных вопросов организована первая линия поддержки и, в случае, если оператор HelpDesk или группа внедрения и сопровождения не смогла предоставить ответ пользователю, вот тогда идет обращение на второй и третий уровни поддержки (согласно принципов методологии ITIL (IT Infrastructure Library, библиотека инфраструктуры информационных технологий)). Стоит отметить, что и пользователь не тратит свое время в пустую, зная, что на его запрос поступит ответ в заранее обговоренное и согласованное время.
Таким образом применение АПК позволит не только построить эффективное взаимодействие с Заказчиком – конечным потребителей ИТ-услуг, но и будет способствовать повышению качества предоставляемых ИТ-сервисов пользователям. В общем случае, схема взаимодействия потребителей ИТ-услуг (пользователей ИТ-сервисов) и ИТ-подразделения представлена на. Стоит отметить, что внедрение АПК, на уровне зрелости ИТ-подразделения от нулевого до второго (согласно методики оценки уровня зрелости ИТ по CobiT), является Стратегической целью развития ИТ на предприятии.
Вариантов программного обеспечения на рынке достаточно и каждое предприятие может выбрать решение, которое удовлетворяет всем его запросам и потребностям. Также никто не запрещает разработать и внедрить собственное решение, но всегда нужно помнить об эффективности и трезво оценивать окупаемость инвестиций.
На представленной ниже схеме взаимодействия, приведено логическое разделение на первую, вторую и третью линии поддержки пользователей; организационно каждое направление (функция ИТ) может быть выделено в самостоятельную группу, так например: в рассмотренном примере ранее служба технической поддержки или техподдержка (Technical support, Helpdesk, Service desk) – сервисная структура отдела поддержки пользователей, разрешающая проблемы пользователей с компьютерами (как аппаратным, так и программным обеспечением) и периферийным оборудованием. Данная служба является единым центром приема Заявок пользователей и их дальнейшей обработки (назначение ответственных, сроков выполнения и т. п.).
Рисунок 4. Схема взаимодействия структурных подразделений предприятия и ИТ-подразделения
В последующем разделе рассмотрим общую схему взаимодействия более подробно.
Из книги Продвижение бизнеса в Интернет. Все о PR и рекламе в сети автора Гуров Филипп Из книги Говори на языке диаграмм: пособие по визуальным коммуникациям автора Желязны ДжинВзаимодействие
Из книги Эра Facebook. Как использовать возможности социальных сетей для развития вашего бизнеса автора Ших КлараВзаимодействие в Facebook После того как вы завели себе аккаунт в Facebook, возьмите за правило заходить на сайт хотя бы раз в неделю, чтобы поддерживать свой профиль в актуальном состоянии и накапливать свой социальный капитал. Время от времени у вас будут возникать возможности
Из книги Конкретный PR автора Масленников Роман МихайловичПриемы оптимизации отношений с государством как заказчиком + Генеральный директор и другие высшие лица (заместители директора) подрядчика решают вопросы намного быстрее рядовых специалистов. Обозначьте вашу высокую должность на визитках, и технические вопросы
Из книги Верьте мне – я лгу! автора Холидей Райан Из книги Ctrl Alt Delete. Перезагрузите свой бизнес и карьеру, пока еще не поздно автора Джоэл Митч Из книги Разговор по существу: искусство общения для тех, кто хочет добиваться своего автора Скотт Сьюзан Из книги Как из хобби сделать бизнес. Монетизация творчества автора Тюхменёва АннаЛичное взаимодействие На всех собранных вами визитках пишите, где именно вы встретили этого человека и о чем говорили. Это повод позвонить ему и сказать: «Мы встречались там-то и говорили о том-то. Я помню, что вы интересовались мастер-классами. Хочу вас обрадовать –
Из книги Бизнес-тренинг: как это делается автора Григорьев Дмитрий А.6.4.3. Механизмы оценки тренинга, предполагающие взаимодействие с заказчиком Оценить реальное изменение способов действия участников в их профессиональной деятельности и тем более эффект от тренинга невозможно без взаимодействия с заказчиком. Основные механизмы такой
Из книги Продвижение порталов и интернет-магазинов автора Гроховский Леонид О. Из книги Бизнес-тренер. Профессия №1 автора Сергеев Алексей ВикторовичГлава 3 Танцы с «волками», или Игры, в которые играют с заказчиком Как писать программы и предложения так, чтобы их купилиКак продать первый тренинг? Преодоление парадокса первой продажиКак понять заказчика, как ориентировать программу под заказчикаКак измерить
Из книги Управление проектами от А до Я автора Ньютон Ричард Из книги Карьера для интровертов. Как завоевать авторитет и получить заслуженное повышение автора Энковиц Нэнси Из книги Дизайн интерьера автора Митина НаталияСегодня процесс создания сложных программных приложений невозможно представить без разделения на этапы жизненного цикла. Под жизненным циклом программы будем понимать совокупность этапов:
- Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)
- Проектирование структуры программы
- Кодирование (набор программного кода согласно проектной документации)
- Тестирование и отладка
- Внедрение программы
- Сопровождение программы
- Утилизация
UML - является графическим языком для визуализации, описания параметров, конструирования и документирования различных систем (программ в частности). Диаграммы создаются с помощью специальных CASE средств, например Rational Rose (http://www-01.ibm.com/software/rational/) и Enterprise Architect (http://www.sparxsystems.com.au/). На основе технологии UML строится единая информационная модель. Приведенные выше CASE средства способны генерировать код на различных объектно-ориентированных языках, а так же обладают очень полезной функцией реверсивного инжиниринга. (Реверсивный инжиниринг позволяет создать графическую модель из имеющегося программного кода и комментариев к нему.)
Рассмотрим типы диаграмм для визуализации модели (это must have, хотя типов гораздо больше):
Диаграмма вариантов использования (use case diagram)
Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью, так называемых прецедентов. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.Диаграмма классов (class diagram)
Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру (поля, методы…) и типы отношений (наследование, реализация интерфейсов …). На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. На этом этапе принципиально знание ООП подхода и паттернов проектирования.
Диаграмма состояний (statechart diagram)
Главное предназначение этой диаграммы - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.
Диаграмма последовательности (sequence diagram)
Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя.
Диаграмма кооперации (collaboration diagram)
На диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации.В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определенные роли во взаимодействии.
Диаграмма компонентов (component diagram)
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Диаграмма развертывания (deployment diagram)
Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются.Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели.
На этом закончим обзорный экскурс по диаграммам в частности и проектированию в общем. Стоит отметить, что процесс проектирования уже давно стал стандартом разработки ПО, но часто приходится сталкиваться с великолепно написанной программой, которая из за отсутствия нормальной документации обрастает ненужным побочным функционалом, костылями, становится громоздкой и теряет былое качество. =(
Я убежден, что программист в первую очередь это кодер – он НЕ должен общаться с заказчиком, НЕ должен задумываться об архитектуре системы, не должен изобретать интерфейс к программе, он только должен кодировать – реализовывать алгоритмы, функционал, внешний вид, юзабилити, но не более…. Проектировщик же должен начиная от абстрактных диаграмм (описывающих предметную область) до диаграмм представляющих структуру данных, классов и процессов их взаимодействия, детально шаг за шагом все расписать. То есть сложность работы и зарплата проектировщика должна быть на порядок выше чем у программиста == кодера. Простите за крамолу....
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Подобные документы
Аналитический обзор целевой аудитории. Создание и заполнение базы данных с помощью Microsoft Access. Разработка интерфейса и функций рабочей области. Построение форм. Функциональные требования к приложению. Его тестирование по методике чёрного ящика.
дипломная работа , добавлен 09.11.2016
Описание структуры обучающего блока. Проектирование его алгоритма и лингвистического и информационного обеспечения. Организация его взаимодействия с базой данных. Разработка графического интерфейса. Программная реализация основных функций приложения.
дипломная работа , добавлен 20.12.2015
Характеристика деятельности, структуры и функций агентства. Анализ текущей структуры сайта заказа наружной рекламы. Описание функциональной архитектуры и архитектуры данных проектируемого автоматизированного модуля. Проектирование интерфейса пользователя.
дипломная работа , добавлен 22.07.2015
Системы управления контентом. Проектирование сайта агентства недвижимости. Информационное обеспечение системы. Построение логической модели данных. Разработка интерфейса сайта: программные средства, структура сценария, его компьютерная реализация.
дипломная работа , добавлен 27.10.2017
Разработка архитектуры, отдельных модулей и сайта Интернет–системы электронной торговли отопительными приборами. Проектирование интерфейса; программная реализация, создание базы данных. Раскрутка сайта: подбор ключевых слов, анализ конкурентных запросов.
курсовая работа , добавлен 20.04.2012
Физическая модель данных. Разработка структуры системы, описание алгоритмов. Разработка интерфейса взаимодействия пользователя. Макет сайта туристического агентства, способы доступа к данным. Требования к программе, стадии и этапы разработки, листинг.
дипломная работа , добавлен 03.05.2012
Разработка архитектуры сайта, структуры данных и необходимых программных модулей. Учет фирменного стиля компании при создании дизайна. Внедрение интерфейса административного редактирования сайта. Проведение экспериментального тестирования и отладки.
дипломная работа , добавлен 19.01.2017
