Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Effective Communications

1,048 views

Published on

  • Be the first to comment

  • Be the first to like this

Effective Communications

  1. 1. Эффективная коммуникация в небольших аутсорсинговых проектах для зарубежных заказчиков Effective communications for small outsourcing software-engineering projects Калугин Александр Mercury Development Russia alexklg@mercurydevelopment.com
  2. 2. 2 Какие проекты • небольшой аутсорсинговый проект • зарубежный заказчик • основные затраты –разработка • нет вспомогательного анализа и/или документирования • процесс разработки - гибкий, но установившийся
  3. 3. 3 Как это бывает? Вася, ты будешь менеджером! Поздравляю!!! ☺ ☺
  4. 4. 4 Что дальше? Вася и Пропасть Заказчик В пространстве, команда во времени, в привычках etc. ☺☺☺☺
  5. 5. 5 Ошибки А что не так-то? ?
  6. 6. 6 Проблемы • Формальное-правильное понимание целей не приводит к удовлетворенности заказчика • Менеджер идентифицирует себя как члена команды • Заказчиком тоже надо руководить • Неэффективно используются средства коммуникации • Дезинформация заказчика и др.
  7. 7. 7 Потребности заказчика 1. Быть уверенным, что «эти русские» понимают, что ему надо. 2. Быть уверенным в том, что «эти русские» способны сделать то, что ему надо. 3. Быть уверенным в том, что «эти русские» сделают то, что ему надо в срок и с должным качеством. 4. Держать руку на пульсе: регулярно получать информацию о состоянии проекта и прогрессе. 5. Иметь возможность проверить, что сообщаемая информация соответствует реальному состоянию проекта. Иметь возможность проверить, что проект движется в правильном направлении. 6. Понимать процесс разработки, что, когда и зачем делается по проекту. 7. Ощущать, что именно он принимает решения по всем важным вопросам, касающимся продукта, что его мнение является решающим. 8. Быть уверенным, что его запросы на изменения будут рассмотрены подрядчиком в кратчайшие возможные сроки и исполнитель сделает все возможное для решения его проблемы. 9. Быть уверенным, что, несмотря на удаленность, разработчики доступны и в проблемной ситуации смогут оказать ему помощь достаточно быстро. 10. Быть уверенным, что развитие проекта предсказуемо, чтобы в середине проекта не возникнет сюрпризов и/или проблем, которые подрядчик не сможет решить самостоятельно. 11. Не быть излишне вовлеченным в процесс принятия технических решений, не быть вынужденным решать проблемы, которые ставит разработчик. 12. Для T&M контрактов, иметь возможность проверить, что участники проекта эффективно используют рабочее время.
  8. 8. 8 Задачи менеджера 1. (Задача-минимум). Завершить проект в рамках бюджета, сроков и запланированной функциональности. 2. (Задача-максимум). Обеспечить удовлетворенность заказчика и заложить основу для долгосрочных отношений. 3. Обеспечивать уровень доступности команды-разработки (response time, turnaround), гибко реагировать на запросы заказчика и учитывать его мнение. Управлять ожиданиями заказчика, говорить с ним на его языке, обеспечивать комфортность работы заказчика с организацией- подрядчиком. 4. Помогать заказчику в своевременном предоставлении материалов, необходимых команде разработки (например, текстовок, элементов графического дизайна и пр.) 5. Формировать общее видение продукта командой разработки и заказчиком, планомерно обеспечивать сужение конуса неопределенности, обеспечить согласование деталей работы продукта с заказчиком. 6. Обеспечивать полную информированность клиента о состоянии проекта, регулярно предоставляя информацию о прогрессе проекта и демонстрируя промежуточные версии. 7. «Продавать» команду разработчиков: формировать положительный образ компании-подрядчика в глазах клиента, демонстрировать уровень технической квалификации команды, зрелости производственных процессов. 8. В случае возникновения проблем или конфликтов, конструктивно их решать.
  9. 9. 9 Объективные сложности 1.Удаленность заказчика, значительная сложность или невозможность личного общения. 2.Разница в часовом поясе и календаре. 3.Языковой барьер. 4.Культурные различия. 5.Высокая коммуникативная нагрузка. 6.Шаблон коммуникации.
  10. 10. 10 Рекомендации. 1. Организация коммуникации 1. Проводите с заказчиком как минимум один чат или телефонный разговор в неделю. 2. Помните, что большинство зарубежных заказчиков привыкли ценить свое и чужое время. Опоздание на встречу всего на 5-10 минут будет означать лишь одно: вы украли у заказчика эти 5-10 минут. 3. Эффективно используйте области пересечения рабочего времени в часовом поясе заказчика и своем часовом поясе для проведения телефонных звонков, видео- конференций или чатов. 4. Своевременно информируйте заказчика о различиях в календаре праздников. 5. При переговорах о времени встречи используйте часовой пояс заказчика.. Поставьте себе в календарь напоминание о смене времени на летнее и зимнее. Помните, что эти переходы для заказчиков могут происходить в другой день. А кто- то вообще не переходит на летнее время. 6. Разумно используйте доступные средства коммуникации. Если предвидите, что в ходе обсуждения потребуется большое количество вопросов, чтобы выяснить все детали – использовать электронную почту может быть не лучшей идеей. Если обсуждается сложный вопрос, то использование электронной почты позволит вам более четко сформулировать свою мысль и преодолеть языковой барьер. 7. Старайтесь ответить на электронные письма заказчика в тот же день, когда пришло письмо или на следующий день. Если не можете быстро ответить на вопрос заказчика, уведомите его об этом и сообщите дату, когда будет готов ответ. 8. Раз в неделю информируйте заказчика о прогрессе проекта и текущем статусе.
  11. 11. 11 Рекомендации. 2. Общие принципы 9. Вы – представитель заказчика внутри вашей организации, интересы заказчика – ваши интересы. 10. Вы – представитель своей команды перед заказчиком. Интересы компании – ваши интересы. 11. Будьте конструктивны: нет -- это да, которое очень дорого стоит заказчику. 12. Помните, что общаясь с вами, заказчик тратит свое время. Благодарите его за это. 13. Подтверждайте свои слова делами. Обещание того, что вы не можете выполнить – хуже, чем никаких обещаний. 14. Вы - тоже человек, и можете что-то не знать. Лучше взять паузу и обдумать свой ответ, чем вводить заказчика в заблуждение. 15. Используйте разницу во времени в свою пользу: у вас есть целый день на то, чтобы обдумать как ответить на письмо заказчика. Не торопитесь понапрасну! 16. Предлагайте решение возникающих проблем, а не просто осведомляйте о них заказчика, даже если эти проблемы вызваны неправильными действиями заказчика. 17. Старайтесь не допускать технических ошибок. Никакие хорошие отношения с заказчиком не помогут вам исправить сложившееся впечатление о вашей профессиональной некомпетентности. 18. Технически грамотные ответы требуют времени на подготовку. Лучше потратить это время, чем второпях допустить ошибку. Если общение происходит в реальном времени, привлекайте к нему специалистов в областях, в которых вы чувствуете себя не очень уверенно. 19. Попытайтесь понять стиль общения заказчика и общайтесь с ним «на его языке».
  12. 12. 12 Рекомендации. 3. Управляйте ожиданиями 20. Информируйте клиента о своем рабочем графике и графике работы команды и подтверждайте свои слова делами: отвечайте заказчику в нерабочее время только в случае крайней необходимости. 21. Разъясните заказчику преимущества разницы во времени. Например, заказчик из США, послав вопрос или просьбу разработчикам в России вечером предыдущего дня, может получить результат уже на утро следующего дня. 22. Объясняйте заказчику, как устроен процесс разработки; что, как и почему происходит. 23. Даже если все идет плохо, например, по техническим причинам вы не можете исправить какой-то очень сложный дефект или проблему с производительностью, как можно чаще информируйте заказчика о ваших действиях и о состоянии проекта. Не оставляйте заказчика в одиночестве и неизвестности. 24. Объясняйте заказчику, что вы сделали для решения проблемы, если она требует значительного времени для решения. Объясняйте, почему вы сделали тот или иной шаг, когда вы ожидаете результатов следующего шага. 25. Регулярно сообщайте заказчику информацию по статусу проекта, используя различные средства. Выясните, какой из способов коммуникации является наиболее эффективным для вашего заказчика, и придерживайтесь этого способа.
  13. 13. 13 Рекомендации. 4. Управляйте заказчиком 26. Заказчик - такой же участник команды, как и другие. Менеджер проекта должен управлять заказчиком, помогая ему эффективно участвовать в проекте. 27. Если заказчик должен вам что-то предоставить, что необходимо для эффективного продолжения работы, напомните ему об этом заранее. Если не получили, напомните еще раз. И еще раз. 28. Как можно раньше составьте для заказчика план, показывающий, что и когда вы от него ждете. Согласуйте даты предоставления тех или иных материалов с заказчиком. Заказчик - тоже человек, и ему требуется время, чтобы подготовить эти материалы. 29. Если формат материалов, которые вы ждете от заказчика – сложный, включите в план предоставление промежуточных версий, в которых вы сможете проверить, что заказчик правильно понимает, что вы от него ждете. Обсудите с заказчиком, зачем нужна эта промежуточная версия.
  14. 14. 14 Рекомендации. 5. Демонстрируйте компетенцию 30. На начальном этапе проекта, задавая заказчику дополнительные вопросы о функциональности приложения – покажите свою неформальную заинтересованность. Это поможет Вам не только доработать спецификацию требований к приложению, но также понять приоритеты заказчика и его стиль общения. 31. Если через несколько дней после начала проекта, или после обсуждения с заказчиком той или иной группы требований, вы продемонстрируете обсужденную функциональность в виде работающего приложения – нет ничего, что более надежно может убедить заказчика как в ваших способностях, так и в способностях команды. Заказчик сможет увидеть свои идеи, воплощенные в рабочем приложении. 32. Если вы не можете быстро сделать работающий функциональный прототип – сделайте прототип пользовательских форм приложения. 33. Если прототип сделать нельзя в силу специфики проекта, задавайте вопросы заказчику, чтобы выявить поведение приложения в важных сложных случаях, - покажите что вы способны предотвращать проблемы, до их возникновения.
  15. 15. 15 Рекомендации. 6. Общее видение 34. Ваша личная цель как менеджера проекта -- выработать у себя видение продукта, такое же как у клиента. Это поможет вам быстрее отвечать на вопросы команды разработчиков и повысить общую эффективность работы. 35. Обсуждая свое видение продукта с заказчиком, вы можете скорректировать его видение и более эффективно завершить проект. 36. Важно не только сформировать общее видение, но и убедить заказчика, что ваше видение совпадает с его видением. Если есть детальная спецификация требований, выделите несколько ситуаций, которые требуют уточнения, и опишите ваше понимание того, как должен работать продукт. Сообщите это заказчику. 37. Если проектом предусмотрена разработка спецификации в начале, создавайте вовлеченность заказчика - регулярно общайтесь с заказчиком по поводу требований. Создавайте у заказчика ощущение вовлеченности в процесс. 38. Помните, что общение с заказчиком, направленное на уточнение функциональности продукта, также позволит вам достичь дополнительных целей: определить степень вовлеченности, на которую готов заказчик, скорость ответа, его технический уровень и язык, на котором ему удобнее общаться.
  16. 16. 16 Рекомендации. 7. Демонстрируйте прогресс 39.Ничто так эффективно не демонстрирует ваш прогресс, как промежуточная версия. 40.По возможности составьте план проекта таким образом, чтобы демонстрировать 2-3 предварительных версии заказчику на промежуточных стадиях. 41.В T&M проекте, организуйте короткую итерацию разработки с предоставлением промежуточных версий заказчику раз в 2 недели или неделю. 42.Помните, что демонстрация промежуточных версий продукта поможет вам раньше обсудить вопросы с заказчиком и выявить потенциальное недопонимание, которое иначе было бы выявлено на более поздней стадии, где было бы гораздо меньше пространства для маневра. 43.Обсудите с заказчиком промежуточную версию. В случае если это не противоречит изначальному видению проекта, учтите некоторые из его замечаний и исправьте их в следующей промежуточной версии.
  17. 17. 17 Спасибо за внимание Ваши вопросы? Калугин Александр Mercury Development Russia alexklg@mercurydevelopment.com

×