admin / 13.02.2018
Содержание
Проекты запускаются с полным убеждением, что новый продукт сделает мир для кого-то лучше и обеспечит прибыль. Бизнес-требования описывают основные преимущества, которые новая система даст ее заказчикам, покупателям и пользователям. Бизнес-требования непосредственно влияют на то, какие пользовательские требования будут реализованы и в какой последовательности.
Они суммируют обоснование и содержание нового продукта или изменения, которые нужно внести в существующий продукт.
Здесь помещают общее описание предыстории или ситуации, в результате чего было принято решение о создании продукта.
Для корпоративной информационной системы описывают бизнес-задачу, которая решается посредством этого продукта, или бизнес-процессы, для улучшения которых требуется продукт, а также среду, в которой система будет использоваться.
Для коммерческого продукта описывают существующие рыночные возможности и рынок, на котором продукту придется конкурировать с другими продуктами. Этот раздел может содержать сравнительную оценку существующих продуктов и возможных решений, указывая, в чем заключается привлекательность продукта и его преимущества. Опишите задачи, которые не удается разрешить без предлагаемого решения. Покажите, насколько оно соответствует тенденциям рынка, развитию технологий или корпоративной стратегии. Кратко опишите другие технологии, процессы или ресурсы, необходимые для удовлетворения клиента.
Опишите потребности типичных клиентов или целевого рынка. Представьте задачи клиента, которые будет решать новый продукт. Предоставьте примеры того, как клиенты будут использовать продукт. Укажите все известные критичные требования к качеству или интерфейсам, но не упоминайте особенности реализации и дизайна.
Суммирует важные преимущества бизнеса, предоставляемые продуктом, в количественном и измеряемом виде. Банальности («стать компанией мирового класса») и нечетко сформулированные улучшения («обеспечить высокий уровень сервиса для клиентов») нельзя считать ни полезными, ни поддающимися проверке. В табл. 5-1 приведены примеры и финансовых и нефинансовых целей (Wiegers, 2007).
Табл. 5-1. Примеры финансовых и нефинансовых бизнес-целей
Финансовые цели | Нефинансовые цели |
---|---|
Освоить X% рынка за Y месяцев | Достигнуть показателя удовлетворения покупателей, равного по крайней мере X, в течение Y месяцев со времени выпуска продукта |
Увеличить долю рынка в стране W с X% до Y% за Z месяцев | Увеличить производительность обработки транзакций на X% и снизить уровень ошибок данных до величины не более Y% |
Достигнуть объема продаж X единиц или дохода в Y долларов за Z месяцев | Разработать надежную платформу для семейства связанных продуктов |
Получить X% прибыли по инвестициям в течение Y месяцев | Разработать специальную базовую технологическую основу для организации |
Достигнуть положительного потока денежных средств по этому продукту в течение Y месяцев | Добиться признания продукта лучшим по на- дежности в опубликованных обзорах продуктов к определенной дате |
Сэкономить X долларов в год, которые в настоящий момент расходуются на обслуживание унаследованной системы | Обеспечение выполнения определенных нормативов регулирующих органов |
Уменьшить затраты на поддержку с X до Y долларов за Z месяцев | Получить не более X звонков в службу обслуживания по каждой единице товара и Y звонков по гарантии каждой единице товара в течение Z месяцев после выпуска продукта |
Увеличить валовую маржу для существующего бизнеса с X до Y% в течение одного года | Уменьшить время выполнения заявки до X часов на Y% звонков в службу поддержки |
Организации обычно предпринимают проект для решения задачи или использования имеющейся возможности. Модель бизнес-целей отображает иерархию связанных бизнес-проблем и измеряемых бизнес-целей (Beatty и Chen, 2012). Проблемы описывают, что не позволяет организации достичь требуемых ориентиров в настоящее время, тогда как бизнес-цели определяют способы измерения достижения этих ориентиров. Задачи и цели взаимосвязаны: понимание одной раскрывают суть второй.
Имея набор бизнес-целей, задайтесь вопросом: «Что мешает нам достичь этот ориентир?», чтобы определить более подробную бизнес-задачу. Или можно вернуться назад, задав вопрос: «Почему нам вообще важен этот ориентир?», чтобы лучше понять бизнес-задачу или возможность верхнего уровня. При наличии бизнес-задачи спросите себя: «Как определить, что задача решена?», чтобы определить измеряемую цель. Процесс выполняется итеративно путем передвижения по иерархии задач и целей, пока не получится список функций, которые позволят решить задачи для достижения целей.
Разговор между бизнес-аналитиком и куратором, одним из топ-менеджеров компании, с целью определить бизнес-задачи и цели может выглядеть, как показано на рис. 5-4. Это иллюстрация к проекту системы Chemical Tracking System в компании Contoso Pharmaceuticals, описанной в главе 2. На основе ответов топ-менеджера компании бизнес-аналитик может сформулировать бизнес-цели для Chemical Tracking System, как показано на рис. 5-5.
Рис. 5-4. Пример разговора между аналитиком и куратором проекта
Определите, как заинтересованные лица будут определять и измерять успех проекта. Установите факторы, которые максимально влияют на успех проекта — те, которые организация может контролировать, и те, которые находятся вне сферы ее влияния.
Рис. 5-5. Пример модели бизнес-целей для системы контроля химикатов
Бизнес-цели иногда невозможно измерить, пока не завершиться проект. В других случаях достижение бизнес-целей может зависеть от других проектов. Но все равно важно оценить успех конкретного проекта. Критерии успеха указывают, находится ли проект на пути достижения бизнес-целей. Эти критерии могут определяться во время тестирования или сразу после выпуска продукта. Для системы контроля химикатов одним из критериев может быть Бизнес-цель 3 на рис. 5-5:
«Сократить время заказа химикатов до 10 минут в 80% заказов», потому что среднее время заказа можно измерить во время тестирования или после выпуска. Другой критерий успеха может быть связан с Бизнес-целью 2 с временем, намного более ранним, чем год после выпуска, например: «Отслеживать 60% контейнеров промышленных химикатов и 50% специализированных химикатов через четыре месяца».
Внимание! Внимательно выбирайте критерии успеха. Убедитесь, что они оценивают то, что важно для бизнеса, а не просто то, что легко оценить. Критерий «Сократить затраты на производство продукта на 20%» легко оценить. Его также легко реализовать путем увольнения сотрудников или сокращения инвестиций в инновации. Но это могут быть не те результаты, которые подразумевались в целях.
Составьте сжатое положение о концепции проекта, обобщающее долгосрочные цели и назначение нового продукта. В этом документе следует отразить сбалансированную концепцию, удовлетворяющую различных заинтересованных лиц. Она может быть несколько идеалистичной, но должна основываться на существующих или предполагаемых рыночных факторах, архитектуре предприятия, стратегическом направлении развития корпорации или ограничениях ресурсов. Далее показан шаблон, состоящий из ключевых слов, которые прекрасно подходят для документа о концепции продукта (Moore, 1991):
Вот как выглядит положение о концепции системы контроля химикатов Chemical Tracking System в Contoso Pharmaceuticals, о которой говорилось в главе 2; ключевые слова выделены полужирным:
Для ученых, которым нужно запрашивать контейнеры с химикатом, данная система Chemical Tracking System является информационной системой, которая обеспечит единую точку доступа к складу химикатов и к поставщикам. Система будет знать местоположение каждого контейнера с химикатом в компании, количество химиката в контейнерах и полную историю перемещения и использования каждого контейнера. Эта система сэкономит компании 25% затрат на химикаты в первый год работы, позволив полностью использовать уже полученные химикаты, утилизировать меньшее количество частично израсходованных или просроченных химикатов и применять единую стандартную систему приобретения химикатов. В отличие от действующих сейчас ручных механизмов заказов химикатов наш продукт будет генерировать все отчеты, необходимые для регулирующих органов, в которых требуются сведения об использовании, хранении и утилизации химикатов.
Как консультант я использую положение о концепции в своей работе. Мы давно работаем с одним клиентом по имени Билл, который время от времени просит нас заняться очередным новым проектом, который обычно имеет свои особенности. Если мы не понимаем, чего именно он хочет, я прошу его написать документ о концепции. Билл всегда немного ворчит, потому что знает, что это заставит его хорошо подумать о том, какой конкретно результат он ожидает получить. Но созданный Биллом документ концепции всегда дает четкое понимание, что нужно сделать, и мы можем эффективно сотрудничать. Это стоит потраченного времени.
Можно попросить несколько заинтересованных лиц написать свое положение раздельно, а не в группе. Сравнение этих положений о концепции будет хорошим способом обнаружить различия в понимании целей проекта. К тому же писать положение о концепции никогда не поздно. Даже если проект уже в работе, разработка положения о концепции обеспечит правильное направление оставшейся части проекта. Положение о концепции создается быстро, но создание правильного положения и согласование его со всеми заинтересованными лицами займет больше времени.
Обобщает важнейшие бизнес-риски, связанные с разработкой — или не с разработкой — этого продукта. В категорию рисков входят рыночная конкуренция, временные факторы, приемлемость для пользователей, проблемы, связанные с реализацией, и возможные негативные факторы, влияющие на бизнес. Бизнес-риски отличаются от рисков проекта, которые обычно связаны с доступностью ресурсов и особенностями технологий. Оцените возможные потери от каждого фактора риска, вероятность его возникновения, вашу способность контролировать его, а также определите все возможные действия по смягчению ситуации.
Предположение (assumption) — это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного.
Бизнес-предположения тесно связаны с бизнес-требованиями. Неверные предположения могут не позволить достичь поставленных бизнес-целей. Например, куратор из руководства компании может поставить бизнес-цель увеличить доход на 100 тыс. долларов в месяц. Определяя такую цифру, куратор сделал определенные предположения, например что новый сайт будет привлекать 200 дополнительных уникальных посетителей в день и что каждый посетитель в среднем будет тратить 17 долларов. Если новый сайт не привлечет достаточно посетителей, тратящих достаточное количество денег, проект может не достичь своей бизнес-цели. Если окажется, что те или иные предположения не оправ дались, можете изменить границы или график проекта или запустить другие проекты, чтобы достичь другие цели.
Задокументируйте все предположения, сделанные заинтересованными лицами, когда они обдумывали проект и создавали данный документ о концепции и границах. Часто предположения одних лиц не разделяют другие стороны. Если вы запишите их и просмотрите позже, то избежите возможной путаницы и ухудшения ситуации в будущем.
Задокументируйте важнейшие зависимости проекта от внешних факторов — изменения отраслевых стандартов или предписаний регулирующих органов, других проектов, сторонних поставщиков или партнеров по разработке. Предположения и зависимости бизнеса могут превратиться в риски, которые должен регулярно отслеживать менеджер проекта. Нарушение зависимостей — популярная причина задержек проекта. Опишите возможные последствия того, что предположения окажутся ошибочными или зависимости нарушены, чтобы заинтересованные лица могли понять, почему это так важно.
⇐ Предыдущая16171819202122232425Следующая ⇒
Анализ требований — это процесс сбора требований к программному обеспечению (ПО), их систематизации, документирования, анализа, выявления противоречий, неполноты, разрешения конфликтов в процессе разработки программного обеспечения. В англоязычной среде также говорят о дисциплине «инженерия требований» (англ. Requirements Engineering). В процессе сбора требований важно принимать во внимание возможные противоречия требований различных заинтересованных лиц, таких как заказчики, разработчики или пользователи.
Полнота и качество анализа требований играют ключевую роль в успехе всего проекта. Требования к ПО должны быть документируемые, выполнимые, тестируемые, с уровнем детализации достаточным для проектирования системы. Требования могут быть функциональными и нефункциональными.
Анализ требований включает три типа деятельности:
Сбор требований: общение с клиентами и пользователями, чтобы определить, каковы их требования.
Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.
Документирование требований: Требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.
Выделяют следующие типы требований:
· Требования клиентов(эксплутационные);
Эксплуатационные требования определяют характеристики разрабатываемого программного обеспечения, проявляемые в процессе его использования. К таким характеристикам относят:
• правильность
• универсальность
• надежность (помехозащищенность)
• проверяемость
• точность результатов
• защищенность
• программная совместимость
• аппаратная совместимость
• эффективность
• адаптируемость
• повторная входимость
• реентерабельность
· Функциональные требования;
Функциональные требования описывают сервисы, предоставляемые программной системой, ее поведение в определенных ситуациях, реакцию на те или иные входные данные и действия, которые система позволит выполнять пользователям. Иногда сюда добавляются сведения о том, чего система делать не должна.
Функциональные требования документируются в спецификации требований к программному обеспечению, где описывается как можно более полно ожидаемое поведение системы.
Необходимо, чтобы функциональная спецификация программного средства была математически точной. Желательно даже, чтобы при ее разработке применялись математические методы и формализованные языки. Она должна базироваться на четких понятиях и утверждениях, однозначно понимаемых разработчиками и заказчиками программного продукта.
Функциональная спецификация состоит из трех частей:
1. Описание внешней информационной среды, с которой будет взаимодействовать разрабатываемое программное обеспечение. Должны быть определены все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами.
2. Определение функций программного обеспечения, определенных на множестве состояний этой информационной среды.
Вводятся обозначения всех определяемых функций, специфицируются их входные данные и результаты выполнения, с указанием типов данных и заданий всех ограничений, которым должны удовлетворять эти данные и результаты. Определяется содержание каждой из этих функций.
3. Описание исключительных ситуаций, если таковые могут возникнуть при выполнении программ, и реакций на эти ситуации, которые должны обеспечить соответствующие программы. Должны быть перечислены все существенные случаи, когда программное обеспечение не сможет нормально выполнить ту или иную свою функцию. Для каждого такого случая должна быть определена реакция программы.
· Нефункциональные требования;
· Требования производительности;
· Производные требования.
⇐ Предыдущая16171819202122232425Следующая ⇒
Дата добавления: 2016-10-06; просмотров: 1846 | Нарушение авторских прав
Похожая информация:
Поиск на сайте:
Поймете, что цель документов, содержащих бизнес требования, состоит в том, чтобы обеспечить, в первую очередь, то, что группа проектирования и группа разработчиков имеют четкое представление о задачах, которые необходимо автоматизировать, как эти задачи приспособлены к организационной структуре, кто играет ведущую роль.
Убедитесь, что аналитик по техническим требованиям встречается с главными заинтересованными в проекте сторонами для того, чтобы конкретизировать требования системы. Последующие встречи могут включать все остальные стороны и даже пользователей. Это для того, чтобы убедиться, что все относящиеся к проекту лица охвачены, и их мнение должным образом задокументированно.
Этап сбора бизнес условий проекта состоит из следующих трёх шагов:
1.
Проведение встречи с заинтересованными сторонами и основными игроками;
2. Переработки и оценка информации, которая была получена на собрании;
3. Создание документа.
Этапы проведения собрания. Советы по составлению хороших бизнес требований:
— Главный аналитик собрания должен составить список вопросов, которые будут заданы каждой заинтересованной стороне и таким образом каждый пользователь будет вовлечён в процесс аккумуляции бизнес требований.
— Аналитик должен записать ответы на вопросы и выделить новые мнения, которые до этого не были известны.
Этапы проведения собрания:
— Аналитик должен суммировать информацию, полученную на собрании, приготовить доклад, и затем собрать новые вопросы и формы ответов преследующих цель, уточнить новые идеи, появившиеся на прошлом собрании.
— Этот процесс должен продолжиться до того момента, когда аналитик сможет подготовить итоговый доклад, с которым согласятся все.
После сбора бизнес требований:
— Аналитик подготавливает официальный документ и представляет его всем заинтересованным сторонам для одобрения и подписания.
— Если контроль завершен, работа бизнес аналитика не будет закончена до тех пор, пока не будут определены позже в цикле программирования дополнительные требования.
— Если завершение контроля не завершено, тогда желательно, чтобы проект начался заново с первого этапа для дополнительного сбора бизнес требований и из анализа.
Документы бизнес требований – один из основных компонентов, так как успех проекта зависит от удовлетворения желаний клиентов. Этот этап проекта никогда не надо недооценивать и пропускать даже для того, чтобы ускорить цикл развития.
Небрежное отношение к определению и документированию всех бизнес требований создаёт для проекта ненужный риск, который будет очень трудно преодолеть позже в жизненном цикле проекта разработки программы.
Традиционный способ документировать требования — это создание списков требований. В сложной системе такие списки требований могут занимать сотни страниц.
Соответствующей метафорой может быть чрезвычайно длинный список покупок в магазине. Такие списки крайне неэффективны в современном анализе, хотя используются и по сей день.
Недостатки
Разработчики могут использовать новые требования для пересмотра сроков и условий в их пользу.
Альтернативами большим, предопределенным спискам требований могут служить пользовательские истории, которые определяют требования обычным языком.
Лучшие методы рассматривают составленный список требований просто как подсказки и постоянно спрашивают «почему?», пока не будут выявлены истинные деловые цели. После этого заинтересованные лица и разработчики могут разработать тесты, измеряющие, какой уровень каждой цели был достигнут. Такие цели изменяются медленнее, чем длинный список определённых, но неизмеримых требований. Как только маленький набор критических, измеримых целей установлен, быстрое прототипирование и короткие этапы разработки могут дать заинтересованным лицам реальную ценность ещё до окончания проекта.
Подробней
⇐ Предыдущая1234Следующая ⇒
Что такое требование? За долгие годы уже появилось множество определений требований к программному обеспечению, вполне приемлемым является следующее определение, предложенное специалистами в области разработки требований Дорфманом (Dorfman) и Тэйером (Thayer).
• Некое свойство программного обеспечения, необходимое пользователю для решения проблемы при достижении поставленной цели.
• Некое свойство программного обеспечения, которым должна обладать система или ее компонент, чтобы удовлетворить требования контракта, стандарта, спецификации либо иной формальной документации.
Многие наиболее часто встречающиеся серьезные проблемы при разработке программного обеспечения связаны именно с требованиями. Результат опроса организации ESPITI (European Software Process Improvement Training Initiative— Европейская инициатива по обучению совершенствованию процесса программирования) показал, что двумя самыми главными проблемами, упоминавшимися почти в половине ответов, оказались следующие:
· спецификации требований
· управление требованиями клиента
К тому же наиболее дорогостоящим является исправление ошибок, допущенных на этапе формирования требований.
Проблемы сбора требований
Процесс сбора требований весьма сложен по следующим причинам:
1.Пользователи часто не знают конкретно, чего они хотят от ИС, за исключением наиболее общих положений, им трудно сформулировать свои пожелания, они могут предъявлять нереальные требования, так как не подозревают, какова стоимость их реализации.
2.Пользователи и разработчики, как правило, принадлежат к различным мирам, говорят на разных языках и имеют различный опыт, мотивацию и цели. Поэтому разработчики могут просто не понимать или понимать неадекватно требования пользователей.
3. Для корректного формирования требований необходимо знать методы их сбора и иметь средства их описания, понятные и пользователям и разработчикам.
Методы сбора требований
Для достижения лучшего понимания потребностей пользователя надо хорошо изучить предметную область.
Для этого используются:
· Интервьюирование и анкетирование
· Мозговой штурм и отбор идей
· Сценарии (прецеденты)
· Прототипирование
· Обыгрывание ролей
Выбор конкретного метода будет зависеть от типа ИС, опыта и уровня подготовки команды разработчиков, заказчика, масштаба проблемы, используемой технологии и уникальности ИС.
Интервьюирование и анкетирование
При применении этого метода сначала надо выявить всех лиц, заинтересованных в проекте. Например, в процессе формировании требований для системы банкоматов участвуют следующие лица:
1)Обычные клиенты банка, пользующихся услугами банкоматов.
2)Представители других банков, имеющих взаимные соглашения с данным банком о совместном использовании банкоматов.
3)Руководители филиалов банка, получающих информацию из системы управления банкоматами.
4)Сотрудники филиалов банка, вовлеченные в повседневную работу системы банкоматов, обрабатывающие рекламации клиентов и т.д.
5)Администраторы баз данных, ответственные за связь банкоматов с базой данных клиентов.
6)Руководители службы безопасности банка, обеспечивающей защиту системы банкоматов.
7)Отдел маркетинга банка, использующий систему банкоматов как средство маркетинга.
8)Разработчики аппаратных и программных средств, ответственные за сопровождение и модернизацию аппаратных и программных средств.
Сценарии
Сценарии описывают последовательность работы пользователя с системой.
Сценарий начинается с общего описания, затем постепенно детализируется для создания полного описания взаимодействия пользователя с системой. В большинстве случаев сценарий включает следующее.
1. Описание состояния системы в начале сценария.
2. Описание нормального протекания событий.
3. Описание исключительных ситуаций и способов их обработки.
4. Информацию относительно других действий, которые можно осуществлять во время выполнения сценария.
5. Описание состояния системы после завершения сценария.
Пример сценария событий
Каждое событие, например вставку карточки в банкомат или выбор сервиса, можно документально подтвердить отдельным сценарием. Сценарии включают описание потоков данных, системных операций и исключительных ситуаций, которые могут возникнуть рис. 3.
Рис. 3 Сценарий обработки банкоматом PIN- кода.
Прототипирование
Прототип это начальной версией ИС или ранее созданная ИС с похожими функциями. Прототип используется для демонстрации концепций, заложенных в ИС, проверки вариантов требований, а также поиска проблем, которые могут возникнуть в ходе разработки, и при эксплуатации системы, а также возможных вариантов их решения.
Очень важна быстрая разработка прототипа системы, чтобы пользователи могли начать экспериментировать с ним как можно раньше. Прототип ПО помогает как при сборе, так и при проверке требований.
Для уменьшения затрат на создание прототипа можно исключить некоторые системные функции. Например, ослабить временные характеристики и требования к использованию памяти.
⇐ Предыдущая1234Следующая ⇒
Дата добавления: 2016-12-17; просмотров: 105 | Нарушение авторских прав
Похожая информация:
Поиск на сайте:
Многие исполнители стараются не работать с заказчиками, которые не могут четко сформулировать требования к проекту. В этой статье я расскажу, как можно работать с такими клиентами, что нужно учитывать и как выстраивать рабочий процесс.
Если клиент «плавает», не может четко поставить задачу и сформулировать требования к проекту, то с ним можно сотрудничать при выполнении следующих условий:
Клиент понимает, что ответственность за принимаемые им решения лежит на нем. Есть клиенты, которые говорят: «Я вам полностью доверяю. Делайте, как считаете нужным, а я все оплачу. Разбираться в вашей работе я не имею времени или возможности». Это опасная ситуация, которая может обернуться против вас. Во-первых, в процессе выполнения работы клиент может не принять предлагаемые вами решения, т.е. нарушить договоренности. Во-вторых, проект может сорваться не по вашей вине, но именно вы будете ответственным за все ошибки.
Есть отлаженный алгоритм, который позволяет успешно выполнять подобные проекты:
В процессе переговоров необходимо рассказать клиенту:
Убедитесь, что клиент все понял, а не сделал вид, что ему все ясно!
После проведения ликбеза необходимо уточнить цели и задачи проекта совместно с клиентом. Сформулировать их будет проще, если заказчик уже немного «в теме».
Ни в коем случае не навязывайте клиенту свои цели или те цели, которые вы считаете нужными. Ваша задача – чтобы сам клиент определился, что ему требуется сделать.
Сделать это помогают уточняющие вопросы, например:
Опишите, как вы планируете пользоваться сайтом, баннером, приложением и т.д., когда оно будет сделано?
Ваша задача – не придумать за клиента цели и задачи, а помочь заказчику разобраться в себе и сформулировать свои цели.
Для клиентов, которые не знают, чего хотят, полезно иметь подробный опросник, в котором заказчик сможет увидеть все возможные «опции» продукта и отметить то, что ему нужно. Например, при создании сайта можно дать клиенту список наиболее популярных функций, которые могут быть реализованы на проекте. Заказчику будет проще отметить то, что нужно. Это снизит риски, что клиент что-то забудет сказать.
Когда вы определились с функциями будущего продукта, совместно составьте техническое задание.
Добейтесь того, чтобы клиент внимательно прочитал ТЗ и уточнил все вопросы, которые у него возникнут.
После согласования ТЗ можно приступать к работе.
Разбейте проект на мелкие этапы и договоритесь с клиентом, что:
В случае нарушения со стороны клиента п. 1 или 2 дальнейшая оплата проекта ведется на почасовой основе, т.е. заказчик будет оплачивать фактически затраченное на работу время по заранее согласованной ставке.
Следование такому алгоритму обычно позволяет работать с клиентами, которые изначально испытывали сложности при формулировании своих задач. Главное при работе с клиентами – не торопиться, последовательно переходить от одного этапа к следующему и добиваться соблюдения договоренностей со стороны заказчика.
Полезные статьи по теме:
Автор: Сергей Антропов(KadrofID: 5)
Добавлено: 20.12.2017 в 18:24
Рекомендуем
Как правильно разговаривать с клиентами по телефону?
В данной статье изложены основные правила общения с клиентами по телефону или Скайпу. Используйте советы из статьи, чтобы сделать телефонные …
Когда с заказчиком надо прощаться?
Новички заказчиков не выбирают. Однако в жизни любого фрилансера наступает момент, когда надо определенным клиентам говорить «Нет». И хотя трудно …
FILED UNDER : IT