Заказчик и Исполнитель – взаимоотношения как основа успеха проекта. Взаимодействие клиента с аутсорсинговой компанией Взаимодействие с заказчиками включает в себя
Мне нравится
21В разных источниках литературы по продажам можно найти разное количество этапов продажи . Каждый автор рассматривает их со своей точки зрения.
Предлагаю рассмотреть ключевые этапы в работе с Клиентом>:
1 этап «Вступление в контакт» или «Установление контакта»
С этого этапа начинается любая продажа .
Цель данного этапа : расположить к себе Клиента и заинтересовать его в дальнейшем контакте.
При установлении контакта с Клиентом важно поприветствовать его и представиться
«Добрый день. Меня зовут Михаил, я менеджер компании «Окна плюс».
Прежде чем начать разговор о потребностях Клиента, рекомендуется пообщаться с ним на отвлеченную тему (техника «Малого разговора»), либо предложить чай, кофе, можно сделать комплимент либо использовать ряд других техник этапа установления контакта.
«Что вы знаете о нашей компании? Почему выбрали именно нас? Что планируете приобретать?»
Важно, чтобы менеджер своим невербальным поведением демонстрировал заинтересованность в контакте с Клиентом, желание ему помочь, доброжелательность. Невербальное поведение включает в себя – открытые жесты, поза, улыбка, наклон корпуса в сторону Клиента, открытый взгляд.
Определить установлен контакт с Клиентом или нет можно по поведению Клиента. Если он позитивно реагирует на слова менеджера, чувствует себя расслабленно, сам задает вопросы, можно предположить, что контакт установлен. Если Клиент не поддерживает зрительный контакт с менеджером, напряжен, не отвечает на вопросы или отвечает неохотно, то имеет смысл больше времени уделить этапу установления контакта.
2 этап «Выявление потребностей»
Цель данного этапа : определить потребности Клиента.
Чем точнее менеджер определит потребности Клиента, тем эффективнее проведет презентацию товаров и услуг, что в последствии приведет к сделке.
При выявлении потребностей менеджеру важно уметь задавать вопросы и слушать Клиента.
При взаимодействии с Клиентом важно, чтобы больше говорил он, а не менеджер, для этого менеджеру рекомендуется задавать больше открытых вопросов .
«Какое окно вы планируете приобрести? Где будете менять окно? Какой климат в квартире зимой и летом? Кто еще проживает в квартире? По каким признакам Вы выбираете окно?»
Закрытые вопросы менеджера позволяют конкретизировать потребности Клиента.
«Вы часто проветриваете помещение? У Вас есть животные? Вам удобно если наш замерщик приедет завтра в 9 утра?»
Альтернативные вопросы предлагают клиенту выбор вариантов.
«Вам удобно чтобы замерщик приехал с утра или после обеда? Установку новых окон планируем на этой неделе или на следующей?»
В течение всей встречи с Клиентом полезно его внимательно слушать, так как зачастую Клиенты сами открыто говорят о своих потребностях. Если какие – то слова Клиента непонятны менеджеру или он их прослушал, желательно задать Клиенту уточняющие вопросы:
«Правильно ли я понял, что Вам нужно окно с повышенной шумоизоляцией? Насколько я понял, Вы хотите, что одна створка окна была поворотной, а другая – поворотно-откидной?»
Желательно подводить промежуточный итог после каждого обсуждаемого вопроса. Особенно если менеджер обсуждает с Клиентом несколько продуктов или услуг.
«Таким образом, мы с Вами договорились, что замер произведем завтра, а устанавливать окна будем на следующей неделе в пятницу. Итак, Вы планируете ставить два новых окна: в кухне двустворчатое с поворотно-откидными створками, а в комнате трехстворчатое, в котором две створки поворотно-откидные и одна «глухая»».
Важно точно выявить потребности клиента и только потом проводить презентацию товаров и услуг.
3 этап «Презентация»
Цель: предложить продукт или услугу максимально удовлетворяющие потребности Клиента.
В презентации продуктов и услуг содержится описание характеристик товаров и услуг, преимуществ от их использования клиентом и выгод, которые получает потребитель.
Полезно начинать презентацию с ключевых выгод Клиента, которые вытекают из потребностей покупателя, выявленных менеджером на предыдущем этапе.
Важно различать, чем преимущество продукта и услуги отличается от выгоды.
Преимущество – это польза, которую получает любой Клиент, используя данный продукт или услугу.
«С помощью данной услуги Вы сможете сэкономить время и сократить расходы на 10%». «Данная фурнитура позволяет сократить количество регулировок».
Выгода – это характеристика или преимущество, которые позволяют удовлетворить конкретную потребность Клиента.
Таким образом, любая характеристика или преимущество могут стать выгодой, при условии, что у Клиента в этом есть потребность.
«Вы хотели, чтобы окно легко открывалось и закрывалось, фурнитура европейского качества сможет это обеспечить». «Вы говорили, что квартира находится на первом этаже и Вы опасаетесь за безопасность квартиры, предлагаю Вам установить на новые окна противовзломную фурнитуру».
В процессе презентации менеджеру необходимо включать Клиента в активный диалог, используя вопросы.
«Как Вы относитесь к моему предложению?», «Что Вы думаете по этому поводу?», «Как Вам мое предложение?»
4 этап «Работа с возражениями»
Цель: развеять сомнения Клиента относительно покупки и снять негатив в отношении продукта или услуги.
Для того, чтобы сократить количество возражений Клиента, менеджеру полезно больше времени уделять предыдущим этапам. Часто возражения Клиентов связаны с тем, что плохо установлен контакт с ним, частично выявлены его потребности, либо презентация товаров и услуг была не интересна Клиенту, слишком длинная и не удовлетворяющая его потребности.
Важно, воспринимать возражения Клиента как сигнал о том, что менеджеру нужно скорректировать свое поведение (особенно если возражений очень много).
Возражения у Клиента могут возникнуть и на предыдущих этапах продажи. Как же работать с возникающими возражениями?
Эффективно придерживаться схемы работы с возражениями:
1. выслушать Клиента;
2. нейтрализовать его эмоции, используя фразы понимания;
«Я вас понимаю», « Да, соглашусь, что неприятно…»
3. уточнить при необходимости информацию с помощью вопросов;
4. предложить конструктивные варианты решения или сделать альтернативное предложение.
Возражения Клиента бывают 4 видов:
1. возражения, связанные с изменениями.
«Зачем мне это нужно», «Я не вижу в этом смысла»
В работе с таким возражением менеджер должен объяснить Клиенту, что риски исключены, показать последствия, если ситуация сохранится, привести примеры, положительного опыта использования чего – либо впервые.
«Приобретая окно с европейской фурнитурой, Вы гарантированно защищены от сквозняков, дополнительных регулировок прижима створок, заедания механизма закрывания».
2. возражения, связанные с ценой.
«Это дорого для меня».
В аргументации менеджеру следует обратить внимание на дополнительную пользу, которую получает Клиент, можно сравнить стоимость товара со стоимостью любой другой не особо нужной вещи или разделить стоимость на какой-либо промежуток времени.
«Приобретая окно в нашей компании, Вы получаете в подарок набор по уходу за окнами, а также возможность воспользоваться бесплатной регулировкой фурнитуры», «Новое красивое окно в кухне будет Вам стоить всего 300 руб. в день».
3. возражения, связанные с негативным опытом.
«Я слышал у Вас плохой профиль».
Менеджеру полезно уточнить информацию, задав вопросы Клиенту, показать Клиенту, что Вы его понимаете и признаете факты неприятных событий (в случае они были в действительности) и затем предложить альтернативный вариант решения.
«Да действительно, у нас была партия бракованного профиля, который мы вернули поставщику. На данный момент мы получили новую партию, уже изготовили и установили более 30 окон, все Клиенты довольны».
4. возражения, связанные с принятием решения.
«Мне надо подумать», «Нужно посоветоваться с женой».
В работе с такими возражениями менеджеру можно еще раз уточнить, с чем связано такое решение, убедиться, что клиент воспринял и понял всю информацию, а также воспользоваться методами завершения сделки.
«Если мы с Вами подпишем договор сейчас, то уже в конце недели Вы сможете любоваться новым окном на кухне». «Только до конца месяца у нас действует скидка на данный товар».
5 этап «Завершение сделки»
Цель: подтолкнуть Клиента к сделке и подтвердить правильность принятого им решения.
Прежде чем завершать сделку (подписывать договор) менеджеру необходимо убедиться, что Клиент готов заключить сделку.
Это можно увидеть по сигналам, которые он показывает:
- положительные отзывы о продукте или услуге;
- Клиент выражает одобрение словам менеджера (поддакивает, кивает головой и тд.);
- прямо говорит, что он согласен;
- задает уточняющие вопросы.
Методы завершения сделки:
1. метод ограничения условий и времени.
«Если Вы подписываете договор сегодня, то мы даем Вам скидку на окно 20%».
2. метод комплимента.
«Вы действительно сделали правильный выбор».
3. беспроигрышная альтернатива.
«Вас записать на замер во вторник или в среду?»
В завершении хочется сказать, что эффективность продаж зависит от мастерства менеджеров. Чем большим количеством методов, техник продажи владеет менеджер , тем он гибче и успешнее при взаимодействии с Клиентом. Профессия менеджера по продажам требует постоянного развития и самосовершенствования навыков. Желаем вам успехов на пути профессионального роста и повышения продаж.
Эффективное управление проектом - необходимое условие для осуществления качественного и своевременного выполнения всего комплекса проектных работ. Работы по любому проекту в НТФ Трисофт управляются и выполняются в соответствии с международными стандартами ведения проектов PMI американского Института Управления Проектами (Project Management Institute, USA). Использование стандартов PMI является одним из ключевых факторов успешной реализации наших проектов - качественно и в строгом соответствии с требованиями заказчика, согласованным бюджетом календарным планом.
Взаимоотношения с заказчиками
НТФ Трисофт ориентирована на выполнение своей миссии и достижение долгосрочного успеха своей деятельности путем удовлетворения требований своих клиентов, в отношениях с которыми мы строго придерживаемся принципов бизнес-этики и взаимовыгодного сотрудничества.
Этические принципы взаимодействия с заказчиками:
соблюдение строгой конфиденциальности и коммерческой тайны;
качественное выполнение работ, отказ от проекта в случае невозможности выполнить работы качественно (например, в случае существенных ограничений по срокам или ресурсам);
предложение заказчику решения реальных, существующих проблем;
Принципы сотрудничества в отношениях с заказчиками:
Обеспечение открытости, прозрачности структуры и процессов, гибкость процессов производства и управления взаимоотношениями:
тесное взаимодействие с заказчиком на всех этапах выполнения проекта, включение ответственных представителей заказчика в рабочие группы;
обеспечение информационного обмена в реальном времени (единое информационное пространство со средствами доступа через Интернет);
адаптация процессов выполнения проекта к стандартам, принятым у заказчика;
разделение рисков и гибкий подход к формированию бюджета проекта;
Долгосрочное сотрудничество является взаимовыгодным и дает следующие преимущества по сравнению с разовыми проектами:
сокращение ресурсных затрат на поиск партнера и установление взаимоотношений;
сокращение сроков и стоимости разработки проектов за счет глубокого понимания бизнес-задач заказчика.
Обеспечение качества:
Возможность изменения требований в ходе проекта. Часто исходное задание на проект не полностью отражает потребности заказчика и появляется необходимость уточнить или изменить требования к системе уже в ходе разработки. Средства управления требованиями и итерационность разработки позволяют корректировать систему в соответствии с изменяющимися требованиями. Контроль соответствия требованиям на всех этапах проекта является частью системы качества.
Разработка прототипов бизнес-логики, функционала и стилистики пользовательского интерфейса дает заказчику возможность "примерить на себя" еще не законченную систему и на ранних стадиях проекта обнаружить и устранить несоответствие требованиям, что сокращает сроки и стоимость разработки системы.
Визуальное моделирования (UML). Разработка диаграмм, иллюстрирующих функционирование системы, позволяет участникам проекта говорить "на одном языке" на всех этапах разработки системы.
Обратная связь. Для сокращения периода "обкатки" системы на этапе опытной эксплуатации, а также в период гарантийного обслуживания разработчику важно вовремя получать информацию об обнаруженных ошибках. Имея доступ через Интернет к хранилищу проекта, заказчик регистрирует в базе данных управления изменениями все замечания по работе системы и имеет возможность отслеживать их дальнейший статус.
Функциональное и нагрузочное тестирование ведется с использованием специально разработанных планов и сценариев тестирования, которые позволяют учесть все аспекты работы системы и проверить систему в условиях, близких к реальным, до передачи в опытную эксплуатацию.
Снижение рисков:
Для снижения рисков, связанных с реализацией проекта, наряду с опытом разработки и достаточными ресурсами, необходимо наличие внедренной методологии, которая обеспечивает прогнозируемый результат и прозрачность процесса разработки для Заказчика.
Взаимодействие с заказчиком. Представители заказчика являются активными участниками процесса разработки и включаются в состав рабочей группы проекта.
Итерационность разработки - сокращение рисков, связанных с изменением требований. Заказчику предоставляются промежуточные версии системы, что исключает ситуацию, когда финальная система не удовлетворяет важным требованиям, не учтенным в исходном задании.
Управление проектными рисками. Проектные риски - это различного рода "непредвиденные ситуации", связанные, например, с несовместимостью платформ разработки. Список возможных рисков и план мероприятий по их устранению составляется до начала реализации проекта и корректируется в ходе проекта.
Прозрачность процесса разработки для заказчика. Имея доступ через Интернет к рабочим материалам проекта, заказчик может отслеживать степень завершенности отдельных задач и проекта в целом.
Проектная организация:
Качественное выполнение проектов и снижение рисков реализуется за счет отлаженной проектной организации работ, которая складывается из инфраструктуры разработки и регламентированной системы качества. Промышленные средства разработки и проектирования используются на всех стадиях проекта и включают специализированные средства проектирования, управления проектами, управления требованиями, автоматизированного тестирования и др., что позволяет нам реализовывать проекты любой сложности.
Хранилище проекта. Для организации эффективного взаимодействия между членами команды создается единое хранилище проекта, доступное как локальным, так и внешним участникам проекта через Интернет. Хранилище включает техническое задание и план проекта, модель требований к системе, базу данных обнаруженных ошибок и замечаний к системе, базу данных версий.
Основные этапы типового проекта
Предварительное обследование. На этом этапе специалисты НТФ Трисофт изучают объект автоматизации и анализируют особенности бизнеса клиента. При необходимости, по согласованию с клиентом могут быть проведены оптимизация или реинжиниринг бизнес-процессов. Анализ позволяет определить те изменения в сложившихся бизнес-схемах клиента, которые необходимы для достижения максимальных преимуществ от внедрения проекта. Этап анализа завершается формированием "Отчета об обследовании" (описывающем текущее положение), "Рекомендаций по изменению бизнес-процессов", подготовкой и согласованием технического задания на проведение следующего этапа работ. Техническое задание разрабатывается в соответствии с действующими стандартами и включает формализованные требования клиента к системе. Для описания бизнес-процессов по согласованию с клиентом могут быть использованы различные методики и нотации - UML,IDEF, ARIS и др.
Проектирование. На данном этапе осуществляется разработка проекта системы. Проект включает в себя описание модулей системы, структуры баз данных, модель базовых классов, сценарии работы пользователя и пользовательские интерфейсы. Проект представляется клиенту для окончательного согласования требований. Проект является основным документом для создания плана разработки.
Разработка. В рамках этого этапа производятся работы в строгом соответствии с утвержденным планом разработки. В зависимости от содержания проекта и требований клиента, разработка может быть разделена на этапы. Результатом каждого этапа является программный продукт с определенным составом функций. Данный подход позволяет тестировать и представлять продукт клиенту поэтапно. При необходимости, поэтапная разработка делает возможным поэтапное внедрение системы.
Внедрение. Внедрение включает в себя миграцию данных из прежних систем, подготовку пользователей и развертывание системы на аппаратных средствах клиента. Уделяя большое внимание внедрению, как итоговому этапу проекта, НТФ Трисофт выделяет в отдельную задачу разработку плана внедрения и его согласование с клиентом. Это позволяет снизить издержки и риски на этапе внедрения.
Поддержка и развитие. Характер поддержки во многом зависит от масштаба системы и согласованного с клиентом плана внедрения: от стандартной "горячей линии" и до постоянного присутствия специалистов НТФ Трисофт в офисе клиента в течение оговоренного времени. В целях снижения издержек клиента мы предоставляем полное описание системы и исчерпывающую документацию. Разработка документации осуществляется в строгом соответствии со стандартами, и в то же время преследует цель ясного изложения материала и быстрого самообучения сотрудников клиента.
Всем доброго времени суток! Сегодня хотел бы поговорить о путях взаимодействия клиента 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 недели- оптимальное время для контроля проекта.
- В разработке предпочтение отдается известным фреймворкам, также для более простой адаптации в случае какой-либо ситуации, когда необходимо передать проект другим разработчикам.
- Качественное тестирование на стороне разработчика - прямая обязанность. При передаче клиенту проекта или какой-то его части, всё должно быть проверено досконально.
- Поддерживать разные браузеры - прямая задача разработчика
Вывод : главное придерживаться партнерских/взаимовыгодных и доверительных отношений с пониманием того, что разработчики такие же люди и усложняя им жизнь усложняешь жизнь и себе! Каждый должен отвечать за свою часть работы, клиент-за предоставление внятного ТЗ и отвечать оперативно на возникающие вопросы, не забывая оплачивать работу, а разработчик - за качество, сроки, скорость. Идеал, конечно, не достигнут, но мы на верном пути.
Рассмотрим полную схему взаимодействия с заказчиком на примере разработки сайта. Графически этапы взаимодействия можно представить в виде следующего рисунка:
Первичными является звонок или e-mail , которые попадают на обработку к менеджеру по работе с клиентами. Менеджер рассказывает об услугах компании "Бихайв", дает ответы на все интересующие вопросы и объясняет дальнейший процесс взаимодействия заказчику.
* Стоит заметить, что заказчику выделяется персональный менеджер на весь период ведения его проекта, который готов ответить на все вопросы и помочь в решении всех задач.
Далее менеджер помогает заполнить анкету-бриф на разработку сайта, которая содержит необходимые уточняющие вопросы по предмету сотрудничества и добавляет контакт во внутреннюю систему CRM (Система управления взаимоотношениями с клиентами).
Данные заносятся в систему для надежного сохранения всех необходимых данных заказчика и качественной разработки сайта в целом.
На основе заполненного брифа, специалисты компании "Бихайв" подготавливают индивидуальное коммерческое предложение с описанием сроков и стоимости работ и менеджер пересылает его на рассмотрение заказчику.
Далее идет процесс согласования условий сотрудничества, результатом которого является договор . Для ускорения начала работ договор подписывается обеими сторонами и стороны обмениваются сканированными копиями договора. Оригиналы договора высылаются по почте заказным письмом (здесь и далее весь обмен бумажными копиями идет по почте или курьером). После получения стороной оригинала в бумажном виде один экземпляр высылается почтовым отправлением обратно.
*Процесс от звонка до подписания договора обычно занимает не более 1-2 дней.
После подписания договора и обмена электронными сканированными копиями заказчик оплачивает аванс, сумма которого обычно составляет 50% от общей суммы договора.
После получения аванса и проведения анализа предметной области начинается этап разработки и согласования технического задания (ТЗ) , где прописываются все требования к разрабатываемому сайту, даются схемы и создается детальный прототип всего сайта. ТЗ является обязательным приложением к договору, утверждается обеими сторонами и подписывается аналогично договору.
* Стоит понимать, что техническое задание является очень важным документом одновременно и для исполнителя, и для заказчика. Оно позволяет спроектировать и выполнить интернет-проект качественно и в срок.
После того как все требования утверждены заказчику высылается список необходимых текстовых и графических материалов , которые должен предоставить заказчик до момента начала этапа разработки (т.е. во время разработки исполнителем макета дизайна заказчик собирает и предоставляет все необходимые материалы). В этот перечень может входить: описание компании, с кем сотрудничают, какие награды и сертификаты имеют, цены и прайс-листы, каталог продукции и описание товаров, описание услуг, контактные данные публикуемые на сайте и т.п.
Иногда заказчику трудно описать свои услуги самому или на это просто нет времени. В этом случае исполнитель готов выполнить работы по написанию недостающего контента на сайт (картинки, тексты, видео и т.п).
* Предоставление заказчиком необходимых материалов критически важен, так как:
- необходимо грамотно вписать весь предоставленный заказчиком контент в сверстанный макет сайта сразу (лишние работы выполнять бессмысленно);
- технологический процесс исполнителя расписан буквально "по минутам" и нарушать его и нести дополнительны затраты мы не хотим;
- наполнение интернет-проекта тестовой информацией также лишен смысла (во-первых, опять же увеличивается объем ненужной работы; во-вторых, поисковые системы могут пессимизировать опубликованный на хостинге сайт с тестовым контентом; в-третьих, ваши потенциальные клиенты могут негативно отнестись к сайту, который содержит заведомо бесполезную информацию);
- и вам, и нам важно выполнить проект профессионально и точно в срок.
* Уважаемые заказчики, не задерживайте пожалуйста разработку собственного же сайта и получение прибыли с него. Предоставляйте контент вовремя! В противном случае, проект будет заморожен до момент получения от вас информации и, соответственно, перенесен срок сдачи сайта. Если нет времени на сбор и написание информации, закажите написание текстов и обработку фотографий нам, это недорого.
Параллельно создается рабочая группа по проекту и стартует этап разработки макета дизайна
будущего сайта.
После готовности макета дизайна, он отправляется на утверждение заказчику. После утверждения макет становится действующим дизайном.
* В зависимости от сложности проекта заказчику может быть предоставлен доступ к системе ведения проекта (например, Redmine), где можно выкладывать необходимые ресурсы проекта, следить за этапами разработки и публиковать замечания.
Для дальнейшего продолжения работ обязательным является получение от заказчика всех необходимых материалов, перечень которых отправлялся заказчику ранее.
Как только недостающие материалы получены. Начинается важный этап разработки сайта
в соответствии с утвержденным ТЗ.
Данный этап включает большое количество типов работ: это кроссбраузерная верстка макетов сайта, разработка необходимых шаблонов дизайна для выбранной системы управления контентом (CMS), установка и настройка самой CMS, установка необходимых модулей и компонентов, разработка недостающих модулей, комплексная проработка алгоритмов функционирования веб-сайта, наполнение сайта контентом, разворачивание проекта на техническом домене и переход к тестированию.
Тестирование интернет-проекта проводят специалисты исполнителя, все ошибки и замечания устраняются, сайт тонко настраивается на работу.
Как только работы закончены и выполнено тестирование сайта на техническом домене начинается этап сдачи-приемки работ
. Здесь со стороны заказчика проверяется выполнение требований ТЗ и весь процесс функционирования интернет-проекта.
После принятия заказчиком решения о полном соответствии сайта требованиям ТЗ происходит передача сайта заказчику и публикация проекта на хостинге.
Результатом и подтверждением сдачи-приемки работ является работоспособный сайт и акт сдачи-приемки, который подписывается обеими сторонами. Подписанный акт вместе со всем комплектом документов для бухгалтерии отправляется почтой.
После подписания акта сдачи-приемки, заказчик в соответствии с договором оплачивает оставшуюся стоимость работ.
После проведения окончательного расчета вместе с документами и сайтом заказчик получает руководство пользователя, копию сайта на DVD и бесплатную техническую поддержку в течение 2-4 недель с момент сдачи-приемки сайта.
В данной схеме мы постарались отразить полностью все аспекты взаимодействий от первичного звонка до сдачи проекта. Для простых проектов часть шагов может объединяться или опускаться. Но в любом случае все отражается в договоре.
Схема работ по услугам "Комплексное развитие сайта", а также "Продвижение сайта" структурно повторяет описанный выше процесс взаимодействия заказчика и исполнителя и поэтому подробного описания не требует.
Надеемся, что описанная схема взаимодействия прозрачна и понятна. Если еще остались вопросы, то просим
Проекты бывают разные, и управлять ими нужно по-разному. В крупных проектах, где занято большое количество разработчиков, не говоря уже о бизнес-аналитиках, тестировщиках и собственно заказчиках проекта, вопрос координации действий встает на первый план, заслоняя собой все другие задачи.
Именно для этого случая была придумана методология управления проектами Agile.
4 ее основных постулата звучат так:
- личности и их взаимодействия важнее, чем процессы и инструменты,
- работающее программное обеспечение важнее, чем полная документация,
- сотрудничество с заказчиком важнее, чем контрактные обязательства,
- реакция на изменения важнее, чем следование плану.
Концентрация усилий на коммуникациях и конечном результате вместо следования плану и полному документированию дает больше гибкости и позволяет не бюрократизировать процедуру кодирования. Обратной стороной столь демократичного подхода является отсутствие четкого планирования, необходимость постоянно переделывать уже написанные части кода и связанные с этим регулярные авралы.
Несмотря на целый ряд недостатков, во многих случаях методология agile незаменима. Поэтому быть знакомым с ней должен любой руководитель отдела разработки.
Должностные обязанности руководителя отдела разработки
Разработка стандартов и политик в области разработки программного обеспечения в соответствии с общей IT-политикой компании;
- планирование и координация работы отдела разработки;
- разработка и контроль соблюдения календарных планов-графиков проектов;
- оценка трудоемкости проектов и распределение задач на разработку среди программистов / разработчиков;
- управление процессом разработки;
- разработка технических заданий на модули программного обеспечения;
- планирование и контроль исполнения бюджета отдела;
- управление внешними ресурсами, привлекаемыми для разработки программного обеспечения;
- разработка нормативной документации, регламентирующей работу отдела и порядок взаимодействия с функциональными подразделениями;
- участие в разработке стратегии развития компании.
Зарплатные предложения и требования работодателей
Среднее зарплатное предложение для руководителя отдела разработки в Москве составляет 150 000 руб., в Санкт-Петербурге - 117 000 руб., в Волгограде - 66 000 руб., в Воронеже - 75 000 руб., в Екатеринбурге - 100 000 руб., в Казани - 75 000 руб., в Красноярске - 90 000 руб., в Нижнем Новгороде - 70 000 руб., в Новосибирске - 85 000 руб., в Омске - 75 000 руб., в Перми - 85 000 руб., в Ростове-на-Дону - 75 000 руб., в Самаре 75 000 руб., в Уфе - 75 000 руб., в Челябинске - 84 000 руб.
Соискатели, впервые претендующие на должность руководителя отдела разработки, должны иметь высшее образование (профильное или техническое), опыт создания программного обеспечения не менее 3 лет. Обязательно знание принципов объектно-ориентированного программирования и методологии разработки ПО (RUP, MSF), необходимы навыки работы с СУБД. Работодателями приветствуется знание нескольких языков программирования. Стартовый оклад начинающих руководителей отделов разработки в Москве составляет от 70 000 до 110 000 руб., в Санкт-Петербурге – от 55 000 до 86 000 руб., в Воронеже и Перми – от 35 000 до 55 000 руб.
| Город | Уровень дохода, руб.
(без опыта работы на данной позиции) |
|
| Москва | 70 000 - 110 000 |
- Высшее образование (техническое / IT) - Знание одного или нескольких языков программирования - Понимание принципов объектно-ориентированного программирования - Знание методологии разработки ПО (RUP, MSF) - Знание английского языка на уровне чтения технической документации - Опыт работы с СУБД - Опыт работы в области разработки ПО от 3 лет Портрет соискателя в 1 диапазоне |
| Санкт-Петербург | 55 000 - 86 000 | |
| Волгоград | 30 000 - 48 000 | |
| Воронеж | 35 000 - 55 000 | |
| Екатеринбург | 47 000 - 74 000 | |
| Казань | 35 000 - 55 000 | |
| Красноярск | 42 000 - 66 000 | |
| Нижний Новгород | 33 000 - 52 000 | |
| Новосибирск | 39 000 - 62 000 | |
| Пермь | 35 000 - 55 000 | |
| Омск | 40 000 - 63 000 | |
| Ростов-на-Дону | 35 000 - 55 000 | |
| Самара | 35 000 - 55 000 | |
| Уфа | 37 000 - 55 000 | |
| Челябинск | 40 000 - 62 000 |
От кандидатов с опытом управления отделом разработки более 1 года работодатели ждут прежде всего развитых организаторских и руководящих навыков. Требования вакансий касаются наличия опыта планирования, организации и реализации проектов, разработки технической документации, а также навыков использования инструментальных средств управления проектами. Претенденты на соответствующие вакансии в столице могут рассчитывать на зарплату до 140 000 руб., в городе на Неве – до 109 000 руб., в Воронеже и Перми – до 70 000 руб.
| Город | Уровень дохода, руб.
(с опытом работы от 1 года) |
Требования и пожелания к профессиональным навыкам |
| Москва | 110 000 - 140 000 | - Развитые организаторские и управленческие навыки - Навыки по планированию, организации и реализации проектов - Навыки использования инструментальных средств управления проектами - Навыки разработки технической документации Портрет соискателя во 2 диапазоне |
| Санкт-Петербург | 86 000 - 109 000 | |
| Волгоград | 48 000 - 62 000 | |
| Воронеж | 55 000 - 70 000 | |
| Екатеринбург | 74 000 - 94 000 | |
| Казань | 55 000 - 70 000 | |
| Красноярск | 66 000 - 84 000 | |
| Нижний Новгород | 52 000 - 66 000 | |
| Новосибирск | 62 000 - 78 000 | |
| Пермь | 55 000 - 70 000 | |
| Омск | 63 000 - 80 000 | |
| Ростов-на-Дону | 55 000 - 70 000 | Самара | 55 000 - 70 000 | Уфа | 55 000 - 70 000 | Челябинск | 62 000 - 78 000 |
Дополнительное образование в сфере IT и опыт постановки полного цикла разработки – таковы наиболее типичные требования к соискателям со стажем управления разработками более 2 лет. Заработок, на который могут рассчитывать такие специалисты, в компаниях столицы достигает 175 000 руб., Санкт-Петербурга – 137 000 руб., Воронежа и Перми – 88 000 руб.
| Город | Уровень дохода, руб.
(с опытом работы от 2 лет) |
Требования и пожелания к профессиональным навыкам |
| Москва | 140 000 - 175 000 | - Дополнительное образование в сфере IT - Опыт постановки полного цикла разработки (от ТЗ до сдачи проекта в эксплуатацию) Портрет соискателя в 3 диапазоне |
| Санкт-Петербург | 109 000 - 137 000 | |
| Волгоград | 62 000 - 77 000 | |
| Воронеж | 70 000 - 88 000 | |
| Екатеринбург | 94 000 - 117 000 | |
| Казань | 70 000 - 88 000 | |
| Красноярск | 84 000 - 105 000 | |
| Нижний Новгород | 66 000 - 82 000 | |
| Новосибирск | 78 000 - 98 000 | |
| Пермь | 70 000 - 88 000 | |
| Омск | 80 000 - 100 000 | |
| Ростов-на-Дону | 70 000 - 88 000 | |
| Самара | 70 000 - 90 000 | |
| Уфа | 70 000 - 88 000 | |
| Челябинск | 78 000 - 100 000 |
Наиболее высокие зарплаты предлагают руководителям отделов разработки крупные предприятия. Такие работодатели требуют от кандидатов опыта работы в организациях сходного размера не менее 3 лет. Компании, имеющие зарубежных партнеров, отдают предпочтение специалистам, свободно владеющим английским языком. Зарплатный максимум в Москве достигает 300 000 руб., в Санкт-Петербурге – 235 000 руб., в Воронеже и Перми – 150 000 руб.
| Город | Уровень дохода, руб.
(с опытом работы от 3 лет) |
Требования и пожелания к профессиональным навыкам |
| Москва | 175 000 - 300 000 | - Опыт управления разработками в структуре крупной компании от 3 лет Возможное пожелание: знание английского языка на разговорном или свободном уровне Портрет соискателя в 4 диапазоне |
| Санкт-Петербург | 137 000 - 235 000 | |
| Волгоград | 77 000 - 130 000 | |
| Воронеж | 88 000 - 150 000 | |
| Екатеринбург | 117 000 - 200 000 | |
| Казань | 88 000 - 150 000 | |
| Красноярск | 105 000 - 180 000 | |
| Нижний Новгород | 82 000 - 140 000 | |
| Новосибирск | 98 000 - 170 000 | |
| Пермь | 88 000 - 150 000 | |
| Омск | 100 000 - 170 000 | |
| Ростов-на-Дону | 88 000 - 150 000 | |
| Самара | 90 000 - 150 000 | |
| Уфа | 88 000 - 150 000 | |
| Челябинск | 100 000 - 170 000 |
Портрет соискателя
Среди соискателей должности руководителя отдела разработки большинство составляют мужчины средних лет с высшим образованием. Представительниц слабого пола среди претендентов всего 5%, что является типичным для IT-сферы. 58% соискателей – специалисты в возрасте от 30 до 39 лет. 96% руководителей отделов разработки имеют высшее образование. Каждый третий соискатель свободно владеет английским языком.
Код для вставки в блог
Руководитель отдела разработки
Навыки управления проектами – такое требование часто встречается в вакансиях для руководителей отдела разработки. На деле за этими словами может скрываться намного больше, чем кажется на первый взгляд.