Завтракать в одиночестве вредно, поэтому дождливое утро 21 октября мы провели за интересной дискуссией в Киеве. Специально для обмена опытом приехали команды из Кировограда и Запорожья.
Участники настроились на рабочий лад еще на этапе знакомства. Каждый рассказал о своей команде и важной проблеме. Как оказалось, 90% сложностей — это срывы сроков. Анастасия даже провела голосование, в результате которого выяснили, что каждый из присутствующих когда-нибудь, хоть раз, но пропускал дедлайн.
Так что же это: менталитет нации или навык, приобретенный в работе?
С этого вопроса и начали дискуссию.
Кейс #1. Cрыв сроков
Участники выделили 2 основные причины, по которым команды срывали сроки:
- некомпетентные менеджеры;
- сотрудник не может адекватно оценить свои силы: «говорят, что сделают за n часов, а выполняют за 2n часов».
В ходе обсуждения сошлись, что самое важное — это коммуникация с клиентом.
Александр (участник) рассказал кейс, когда клиент потерял $20 млн., то есть группу в 100 человек. Если бы менеджер проговорил все детали с клиентом заранее, такого бы не случилось. Гости завтрака уверены, что любой вопрос или сложность можно исправить, если с клиентом налажен мост доверия.
Представляйте себя на месте клиента, ведь он может не всё понимать в вашей работе. Стоит пояснять, почему увеличивается время. Лучше перед стартом клиенту детально описать и показать на примерах, что «работа займет не 20 часов, как вам кажется, а 60 — и вот почему…»
Анастасия рассказала, как в западных странах детей учат планировать подготовку к экзамену, к контрольной и т. д. Навык планирования надо встраивать в себя и прививать своим коллегам, сотрудникам. Это поможет правильно определять время загрузки и выставлять адекватные дедлайны.
В теории все знают о правильной коммуникации и планировании, но когда Евгений спросил: «У кого менеджеры проектов факапят? Например, обещают выслать завтра письмо и не отправляют», — каждый участник завтрака поднял руку.
Этот вопрос привел обсуждение к проблемам управления, которые есть в каждой компании, но называют их все по-разному. Как и решают: кто жестко, а кто не очень.
Далее обсуждали, какой проект лучше брать в работу: Fixed Price или Time&Material; и почему.
Кейс #2. Увеличение бюджета после того, как подписали контракт
Участница Анна (Business Development Manager) рассказала про проблему коммуникации на недавнем проекте. Клиент после подписания договора сказал, что исполнители неправильно его поняли, и он вообще не это имел в виду. В глазах клиента провайдеры остаются «непонимающими» даже после нового договора.
Вопросы (выяснение требований) и индивидуальный подход — вот что будет важно на этом этапе.
Если вы в лодке с клиентом, то делите с ним все риски поровну.
Кейс #3. «Готово», когда не готово
Несколько участников описали курьезные ситуации во время презентаций “готового” продукта клиенту: «бывало, говоришь, что работает так, нажимаешь, ждешь, а кнопка не работает». Смешно и горько.
— Что надо для сдачи реально готового продукта?
— Тестировать, — услышали со всех сторон от гостей.
Теоретически, конечно, верно. Как эффективно реализовать это на практике? Своими наработками поделилась Анастасия:
- Варианты презентации проекта. Как справиться с форс-мажорами во время общения с клиентом?
- Кто должен выполнять тестирование: тестер/дизайнер/проектный менеджер?
- Кто несет убытки из-за недоделок?
Во время мозгового штурма решили, что тестировать должны все, кто вовлечен в проект. Стоит также предугадывать поведение клиента и проверять на новых устройствах или браузерах.
Кейс #4. Скрытое непонимание задачи
Эта тема оказалась индивидуальной. Выяснили, что зависит от особенностей профессии и характера разработчиков. Анастасия подытожила, что важно:
- учить задавать вопросы каждого члена команды;
- составлять регламенты на выполнение задач;
- разговаривать с разработчиком часто и детально;
- развивать навыки у project-менеджера, который будет общаться с командой и предотвращать факапы.
Кейс #5. Несвоевременный upsell
Анастасия привела пример распространенной ошибки, когда предлагают второй и третий продукт, когда ещё никто и на первый не согласился.
— Мне нужно iOS приложение.
— А Android хотите? Мы можем.
Все посетители завтрака согласились, что это нужно делать на этапе «клиент доволен», а не в первом-втором разговоре.
Вывод
Основной посыл от менеджеров, программистов, руководителей и основателей компаний на бизнес-завтраке: нужно выстраивать доверительные отношения с клиентом. Для этого развивайте коммуникативные навыки у себя и своих сотрудников.
Участница Анна рассказала кейс, когда зашел проект на исправление чужого кода, а программист отказывался его брать в работу вплоть до увольнения. Стоял выбор: работа с клиентом или замена программиста.
«Надо смотреть выше ситуации», — вот что должен делать менеджер. В тот раз сотруднику Анны удалось разрешить проблему: сохранили и сотрудника, и клиента. Коммуникация и желание выяснить истину сыграли ключевую роль.
Не всегда слова клиента — его личное мнение. Могут быть скрытые смыслы. Надо общаться и слушать.
Как вы решали проблемные вопросы на проекте? Делитесь кейсами и будем обсуждать.
Регистрация на следующий бизнес-завтрак уже открыта
Мы едем во Львов, чтобы обменяться опытом и узнать мнение специалистов по актуальной во все времена теме «Сбор требований по проекту. Кто крайний?».
Регистрируйтесь тут, советуйте друзьям.
До встречи на обсуждении.