Технологии за взаимодействие с вътрешния клиент. Управление на проекти. Информиране на клиента за технологията за управление на проекта

Искам да се съсредоточа върху създаването на положителен имидж. Въз основа на събраната първоначална информация, ние решаваме на кой от нашите служители може да се довери да представлява нашата фирма при първата среща с клиента. Това е много важен момент. Например, ако изпратим отличен специалист за първи контакт, но той има обица на ухото, „готвач“, напоен с мазнина и т.н., тогава клиентът може да погледне и да каже: „О, хайде!“ Случва се. Или например спретнат, подстриган, с костюм и вратовръзка, но влезе момче на около 20. И клиентът гледа и казва: „Това е момче, какво да говоря с него? Как да работя с тях - изобщо не ме уважават, изпратиха момче при мен! Следователно събирането на тази информация е необходимо, наред с други неща, за да се разбере на кого да се повери първият контакт и как да се държи с контактьора, как да изгради легенда, как да се представи.

Идентифициране на вземащите решения

Следващият много важен въпрос е идентифициране на лицата, които реално вземат решения(т.нар. LPR). Този етап се състои от два елемента:

• Оказва се, който взема решенияпо наш проект.
• И втората точка - са идентифицирани лицата, които влияят върху вземащите решения.
  Какво означава? Известно е например, че решенията в компанията се вземат от изпълнителния директор, а той има още финансов директор и счетоводител. Може да е счетоводител, който прави всичко, което директорът каже и седи тихо в ъгъла, или може би обратното, счетоводител, който казва на директора какво да прави така и директорът му се подчинява. И ако първоначално разкрихме, че този човек има влияние върху своя директор, тогава това е нашият коз, следователно трябва да се опитаме да установим отношения с този счетоводител. Условно казах, че това е счетоводител - може да бъде всеки (например ръководител на отдел продажби или някой заместник, на когото генералният директор или собственикът на компанията има пълно доверие). Необходимо е да се установят взаимоотношения с лицето, което влияе на вземащия решение.

Целта, както виждате, е да се идентифицират лицата, вземащи решения. И резултатът е списък на вземащите решения и лицата, които влияят върху вземащите решения.

Нашият опит го показва опитайте се да се срещнете с лицата, вземащи решения, възможно най-скоро- обикновено те са или топ мениджмънт, или собственик на компанията. Не е задължително да се случи при първия контакт, но ако такава среща не се случи на предварителния етап, тогава по правило нищо добро няма да излезе от нашия проект.

Установяване на партньорства

Следващ етап - установяване на партньорства.

• Първоначално го правим акцент върху двустранната отговорност: дори в договора, ако е възможно, ние предписваме не Клиент-Изпълнител, а „ Първа страна" (това е Клиентът) и " Втора страна” (това е Изпълнителят). Вярно е, че понякога някои големи държавни структури казват, че правният отдел не им позволява да направят това, защото документите се проверяват от Министерството на финансите, Министерството на финансите и др. В този случай ние предписваме стандартната формулировка - "Клиент и Изпълнител". Но ако е възможно, тогава - "Първа" и "Втора страна".
• С всички средства се опитваме да внушим, че това е съвместна работа. Лидери и от двете странидействат като високи договарящи страни - именно те решиха да направят този проект за автоматизация. За този проект те наберете екип откак от състава на първиястрани, тези на служителите втора странае т.нар Съвместна работна група“, което прави проекта. Естествено, всяка страна влага своите ресурси в проекта: материални, технологични, методически, финансови - защото като цяло става дума за доста големи проекти.
• Работата на съвместната работна група се контролира от« Съвместна надзорна комисия"е най-висшият контролен орган, обикновено състоящ се от висшето ръководство на двете страни.
• И подпишете отговорността на всяка странатака че служителите на клиента да разберат, че не само ние, но и те са отговорни за проекта. Прекарваме много време и усилия, за да предадем на клиента, че изпълняваме този проект заедно с неговите служители и че тяхната работа зависи пряко от това с какво качество и най-вече в какъв срок ще бъде завършен проектът.

добре резултаттози етап е фиксация(официално или неофициално) отношенияравноправни партньори:

• Официалното фиксиране е договор.
• И неформални - това могат да бъдат някои официални документи, в които винаги се опитваме да предпишем "Първата и Втората страна" и тяхната връзка.

Информиране на клиента за технологията за управление на проекта

Следващият етап е информиране на клиента за технологията.

• При големи проекти ние без провал имаме " Курс от лекции и семинари за въведение в технологията на проектиране". В този курс от лекции ние представяме на служителите на клиента как ще протече целият процес на проекта:
  • Как се прави проект с нашата технология?
  • Кой за какво е отговорен?
  • Кой какво прави
  • Защо се предприемат определени действия?
  • Защо е необходим този документ? Какво дава той и на двете страни? (за да стане ясно на служителите, че партньорствата осигуряват ползи не само за нас, но и за клиента).
  • При всяка възможност, ние Ние информираме вземащия решение за всички проблеми, които възникват в процеса на работа. За да направим това, имаме редица специални ежедневни документи - например "Дневник на контактите" или "Отчет за отклонения". И ако не ежедневно, а през няколко дни ръководството на клиента трябва да се запознава с тях. И тъй като по правило веднага се намират извинения: Бях зает, не четох и т.н., тогава, съответно, трябва постоянно да напомняме за това, може би дори да симулираме някои ситуации, които принуждават ръководството да прочете тези документи.

Резултатът от този етап е, че всички отговорни лица на клиента са преминали курс от лекции и най-важното, че ръководството има ясна представа за това как се извършва работата (естествено, ако контролира проекта достатъчно строго).

Организация на отношенията с клиента

Следващият етап е организацията на отношенията с клиента. Тук искам да ви разкажа за един интересен „трик“: имаме такива роли в проекта (това не са позиции, а роли) като „Мениджър на договори“ и „Мениджър на обекти“ (най-често те също могат да бъдат комбинирани и с някои друга отговорност). Както е посочено на слайда тук, тези роли отговарят на дефинициите за „лоши“ и „добри“.

• Мениджър по договориЛошо е". Това може да е физическо лице или един от топ мениджърите. Най-често функцията на ръководителя на договора се изпълнява от ръководителя на проекта (ако, разбира се, той може да направи това). Този човек е „Не“ - той може да дойде при вземащия решение и да каже: „Така е написано в нашия договор, но сега го правите по различен начин и поради това има отклонение. Нека да го разберем." Винаги посочва недостатъци, неспазване на технологията, настоява за спазване на документациятаЗатова винаги е лош.
• НО обектен мениджър- този е добър". Това е човек, който по различни причини е развил добри отношения с вземащия решение от клиента. Може би случайно го хареса. Или, например, имат някакви връзки (родствени, кланови, приятелски - каквито и да е). Основното е, че клиентът е разположен до него.
  Мениджърът всъщност поддържа този обект. Моля, обърнете внимание, че това не е ръководител на проекти, това е специален човек, който какво прави поддържа добри отношения с ръководството на клиента, а когато има някакви остри проблеми ги изглажда.
  Например, след като ръководителят на договора е говорил с клиента за неспазване на някои условия от нашите споразумения (това може да завърши като цяло с някакъв неприятен разговор за нас), ръководителят на обекта идва и започва да успокоява клиента .
  Не напразно казах, че обектът на мениджъра се нарича „добър“. Обикновено се казва, че да си „хубав човек“ не е професия. Но това е нашата професия. Мениджърът на обекта е „хубавото момче“. Може да не е професионален специалист в нищо, но клиентът се чувства добре с него - дойде, поговори с него (може би за политика, футбол и т.н.), и клиентът се почувства добре, отношението му се промени. Преди това клиентът щеше да ни направи забележка за нещо, да ни накаже за нещо, но сега той вече разбира всичко, като цяло му е неудобно да говори лошо с нас.
  Това е функцията на обектния мениджър. Назначава се на всеки доста сериозен клиент.

Разбира се, всичко, за което говоря, изисква определени средства и разходи. И, разбира се, създаването на цялата тази структура в името на малък магазин няма смисъл - всичко това се прави само в името на достатъчно големи обекти.

Резултатът от този етап е назначаването на подходящ договор и управител на обект за този клиент, тъй като е много важно тези хора да бъдат избрани правилно.

Организация на проектните процеси

Следващият етап е организация на проектните процеси. Според мен има само два от тях:

• Мониторинг на напредъка на проекта;
• И вземане на управленски решения въз основа на резултатите от мониторинга.

Най-важното е да убедим клиента да работи по нашата технология. Тази процедура се обяснява на клиента както в лични разговори с вземащите решения, така и когато отговорните служители посещават курс от лекции (обяснява как и какво ще се случи по проекта - служителите на клиента трябва да присъстват на този курс задължително, под подпис).

Понякога може да бъде много трудно да убедим клиент да работи с нашата технология. Например, имахме един клиент - много голяма IT компания. Освен това самата тя се занимаваше с автоматизация на MS Navision, но по определени причини реши да ни се обади, за да можем да ги автоматизираме на 1C. И така, работата с тях беше истински кошмар - всички плачеха, и мениджъри, и програмисти. Защото беше много голяма компания (ние сме малки в сравнение с тях) и те мислеха, че знаят всичко и се опитаха да ни научат. Те постоянно казваха: „Момчета, не правите всичко така, има такава и такава технология, трябва да го правите по този начин.“ Естествено, това се случи само на средно ниво, ръководителят (който беше основен собственик и генерален директор на компанията), разбира се, разбираше всичко перфектно и след неговата намеса всичко беше решено, но беше много трудно да го вземем. А на средно ниво имаше постоянни проблеми, постоянни опити за преподаване.

Ние сме във всеки проект, без грешка, Опитваме се да предадем на клиента идеята, чев бизнеса си той е професионалист (и ние, разбира се, не отиваме там), а по въпросите на автоматизацията сме професионалисти, така че трябва да се доверим, а не да се опитваме да ни казваме какво да правим и как да го правим. Особено ако не просто ни кажат, а се опитат да ни накарат: „нека го направим по друг начин, защото аз искам“. Това са нещата, които се опитваме да спрем в момента. Разбира се, „стоп“ е силна дума, във всеки случай се опитайте да я обясните достатъчно меко. Ако се съгласихме с този проект, решихме, че ни подхожда, включихме се в тази „битка“, сега, разбира се, трябва да работим с него.

Ограничаване на желанията на клиента

Следващият етап е ограничаване на желанията на клиента. Вероятно всеки се е сблъсквал с това (когато започне така нареченият „списък с желания“ - още, още и още). Тук го правим съвсем просто:

• Например, когато клиент каже, че в рамките на определения бюджет и срокове трябва да се направи и това и това, тогава започва доста често, трудно обяснявайки как работи всичко. Напомняме на клиента, че имаме бюджет с него, разпределени са хора (съвместна работна група), всяка страна на проекта инвестира своите ресурси. Следователно, ако възникне допълнителна работа, тогава се изискват допълнителни часове, допълнителни хора. Откъде да ги вземем?
  Или ако клиентът бави проекта, тогава и нашите, и неговите хора бездействат, а им се плащат пари. Къде да вземем тези ресурси? Не говоря за това, че тези хора не само получават заплата, но и носят някаква печалба на компанията. Естествено, компанията не иска да загуби тази печалба. Обяснява се достатъчно подробно на клиента и клиентът обикновено реагира много добре.
• Ние обясняваме даваме подробно цифрово оформление- къде, какво, до стотинка. И ние го казваме ако искате да направим и товатогава моля те ще отнеме толкова много часове и те трябва да бъдат платени. В крайна сметка клиентът се съгласява с нас и или отказва своя „Wishlist“ или заплаща допълнителни часове. Разбира се, това се случва по различни начини - сега малко идеализирам картината.

Тук искам да дам още един пример за взаимоотношения. Работихме с една много голяма компания (те вече бяха на етап поддръжка) и там периодично възникваха задачи за подобрения: например да се направи някакъв труден отчет или нещо друго. И така, главният счетоводител на компанията ни възложи определена работа и ние я свършихме. И когато дойде време да плати, той каза: „Като цяло сбърках, изобщо не ни трябва всичко това.“ Но работата беше свършена, следователно беше необходимо да се плати. И той казва: „Не, няма да платя за това, но не мога да отида при президента на компанията и да му кажа, че съм глупак и съм поръчал грешното нещо.“ Освен това компанията беше много голяма, петролна компания, отношенията бяха добри и с нея, и с този човек. И не сме настоявали – не плаща, не плаща. Въпреки че поради това загубихме доста голяма сума пари за нас по това време (беше 2004 г.). В края на годината имаше деноминация (азербайджанският манат изхвърли нули). И за всички клиенти, които бяха в нашата услуга, направихме това преизчисление в работен ред - без допълнителни пари. Но към този счетоводител (по това време беше изминала буквално по-малко от година от този инцидент) се приближихме и казахме: „Помниш ли, не ни плати? След това отидохме да се срещнем с вас. Сега, деноминация. Нека направим това безплатно?" Без въпроси - издадохме фактура, той плати.

Защо дадох този пример? За важността на добрите взаимоотношения. Ако тогава се бяхме надигнали и поискахме да ни плати тази сума, тогава щяхме да имаме риска да загубим добър клиент. И така поддържахме връзка с него.

Кой е отговорен за обяснението на този бюджет:

• Това в начина на работа; в редовния ход на работае ангажиран Ръководител проект- ръководител на съвместната работна група, която всъщност изпълнява проекта.
• Ако не успее, тогава се свързва ръководител на договора, който обяснява с числа и казва, че това е - нарушение на договора, нарушение на споразумението.
• В най-трудните случаисвързва обектен мениджъркойто се опитва да обясни (вече, разбира се, без никаква твърда рамка) на клиента защо трябва да ограничи желанията си.

Обикновено, ако числата са написани много подробно, тогава това оформление и неговото обяснение е достатъчно.

Доставка на произведения

Доставка на произведения. Тук като цяло обикновено няма големи проблеми, т.к Процедурата за предаване на произведения е много подробно описана в нашиярелевантни документи.

Но на този етап елементът на неформалност ( добра връзка), разбира се също прави живота по-лесен както за нас, така и за клиентасъщо.

Целта на този етап е да се постигне доставка на работите в пълно съответствие с правилата, установени в съответните документи, които са приложение към договора, подписан както от клиента, така и от нас. Съответно винаги може да се покаже, че има такива правила.

Връзки след проекта

И накрая, отношенията след проекта. Това също е много важна част. Към какво трябва да се стремим в края на проекта? До сключването на договор за услуга, разбира се. Но това не винаги е така. Защото има понятието „резултат“ и има понятието „резултат“ – и това са малко по-различни неща.

Ще ви дам пример. Имахме проект с една много сериозна фирма и резултатът от този проект беше блестящ за нас - това беше един от онези редки случаи, когато напълно спазихме и бюджета, и срока, точно както беше планирано. Това беше резултатът. И резултатът от проекта беше, че договорът за услуга не беше подписан. Освен това клиентът каза, че никога повече няма да работи с нас. Ето и резултата. С други думи, резултатът е блестящ, но резултатът е много тъжен.

Защо се случи това? Защото не е имало неофициални отношения. По това време току-що бяхме разработили нашата технология за проектна документация и това беше клиентът, на който беше демонстрирана цялата тази технология в пълния й блясък. И когато попитахме клиента: „Е, няма да работите с нас - но има ли претенции към нас?“ И през стиснати зъби от гняв ни казаха: „Това е проблемът, че не можем да предявяваме претенции – каквото и да кажете, за всичко имате лист хартия, а ние нищо не можем. Не сме доволни от това и няма да работим повече с вас. Други фирми могат да бъдат помолени да направят нещо допълнително, но вие отказвате - ето ви бюджета, ето ви го както трябва, ето ви срока. Отдръпнете се - и веднага ни показвате лист хартия с нашия подпис.

Така че резултатът е тъжен. Но още веднъж подчертавам, че такъв резултат се дължи на факта, че не е имало неофициални отношения.

Тази статия се основава на доклад, прочетен от автора на конференцията IE Infostart 2014 на 29-31 октомври 2014 г.

Каним ви на нова конференция.

Добър ден! Днес бих искал да говоря за начините, по които един клиент взаимодейства с аутсорсинг компания, както и да получа коментари от вас за това как взаимодействате с вашите клиенти/разработчици на софтуер. Тази статия е написана въз основа на опит и в по-голямата си част е предназначена за клиенти на софтуер. Целта е да се открият "тесните места" в отношенията между клиента и компанията, предлагаща услуги за разработка на софтуер.

Позволете ми да се представя: аз съм Юрий Корхов и тази статия е първата в моето Хабре. Завършил Беларуския национален технически университет (инженер по сигурността), Беларуския държавен университет (инвестиционен мениджър). Трудов опит - повече от 6 години в ИТ на почти всички позиции: уебмастър, дизайнер на оформление, уеб дизайнер, програмист, ръководител на проекти и UI разработчик на непълно работно време, ръководител на отдел ... Общо през това време повече от 80 проекта са реализирани: от малки сайтове, игри за мобилни телефони до големи интернет портали... Основният профил е управлението на развитието на проекти в IT сферата. Той работеше както от страна на клиента, така и от страна на разработчика, както на руския пазар, така и на чуждестранния.

Предистория за създаването на публикацията или Благодаря ви Wargaming.

Заобикалянето на историята на създаването на тази публикация не би било добре, т.к. Четох habr от много дълго време, но ръцете ми не успяха да напиша статия, но тук е въпрос на „случайност“ и сега статията е готова.

От няколко месеца си давам почивка от работа, защото ми писна от аутсорсинг, реших да намеря смисъла на живота и лека-полека да подготвям проекта си за стартиране и един прекрасен ден телефонът звънна. Работник на Wargaming (основателите на „tanchiki“ и, по мое мнение, една от най-добрите фирми в Минск) ми се обади с предложение за интервю за вакантно място за мениджър на доставчици (тук трябва да се каже, че не търсех работа , и, съдейки по свободната им позиция, не им паснах добре). "Това е интересно!" – Помислих и реших да изпълня тестовата задача, още повече че ми беше доста интересна. Рекрутерът каза, че има всички условия за приятна, здравословна (фитнес, застраховка и др.) и добре платена работа и не на последно място ще ми отнеме около 3 часа, за да изпълня тестовата задача. Съмнявам се, че някой щеше да се справи с цялата тестова задача в определеното време, както при мен - общо около 6 часа.

За мое съжаление обратната връзка от компанията беше в телефонен разговор и беше изразена в сухата фраза „всичко е наред, всички го харесаха“ (не помня дословно, но същността е такава) и без никакви конкретики. Съмнявам се, че успях да посоча всички основни "тесни места"; не е добре да губите работа, реших да публикувам отговорите на тестовата задача (с малки промени, за удобство) на обществеността и ще бъда благодарен на аудиторията на habra за допълнения и здрави коментари към статията.

Схема на взаимодействие между клиента и разработчика на софтуера от първата среща до края на връзката.

1. Разработчикът на софтуер е в състояние да завърши проекта.
2. Преди това не е сключен договор с разработчика на софтуера и няма проекти.
3. TK е готов.
4. Условията за плащане се уреждат в договора.
5. Използват се системи за управление на проекти и методологии за разработка на софтуер (XP, Scrum, Lean, Kanban, ScrumBut и др.).
6. Попълването на приложението със съдържание (при необходимост) се извършва от клиента.

Аспектите на договора между доставчика на разработка на софтуер и клиента е изгодно за продавача да се избягват (опростете, премахнете напълно от договора).

1. Отговорността за спазване на крайните срокове е на разработчика и ако сроковете са пропуснати в последния момент (т.е. разработчикът не е уведомил предварително, че няма време преди затварянето), трябва да се налагат санкции (има голям избор от опции).
   Причина: неспазването на сроковете е един от най-големите проблеми и споменаването му в договора не е много интересно, т.к. В по-голямата си част неспазването на сроковете е на страната на разработчика. Тук е необходимо да се има предвид, че е трудно да се изчисли точно, но е необходимо да се предупреди предварително, че разработчикът няма време да завърши етапа на разработка в рамките на определен период от време и това трябва да бъде предписано в договора .
2. Гаранционни условия за коригиране на "бъгове" по вина на разработчика, които не са открити навреме. Обичайният гаранционен срок е 3 месеца.
   Причина: често се случва някои „бъгове“ да не са коригирани или вече са се появили в процеса на работа, така че този елемент често се опитва да не посочи или намали гаранционното време. Моето мнение е, че по-малко от 3 месеца не е достатъчно.
3. Права върху разработен софтуер, модули, блокове и др. принадлежат на клиента и не могат да бъдат използвани за последваща препродажба.
   Причина: За разработчика е полезно да има права върху интелектуална собственост или да може да продава/използва разработки за други клиенти, което от своя страна може да постави клиента в неудобна ситуация на пазара.
4. При разработване на нов модул в системата, който засяга работата на други модули или на цялата система, разработчикът трябва да осигури функционирането на цялата система.
   Причина: често разработването на един модул може да навреди на работата на друг модул или на цялата система като цяло и по-нататъшните подобрения могат да паднат върху „раменете“ (финансово) на клиента. Разработчикът е длъжен да вземе предвид структурата на цялата система и в случай на „бъгове“, открити от клиента, да я коригира безплатно.
5. Техническата документация за разработката трябва да бъде изготвена, като се вземат предвид изискванията на клиента.
   Причина: за разработчиците е полезно да се обвържат напълно с клиента и често се случва документацията да не се поддържа.
6. В случай на изработка на уеб сайт, изпълнителят трябва да вземе предвид SEO оптимизацията на сайта, а именно: описание на изображения, страници…
   Причина: спестяване на време за „малки неща“, което в зависимост от условията на договора може да доведе до финансови загуби за клиента (разработчикът на софтуер спестява време / финанси).
7. Тестването на системата трябва да бъде осигурено от разработчика на системата.
   Приемането от клиента на готовия модул не трябва да се превръща в тестване на системата, т.е. разработчикът се задължава да поеме отстраняването на идентифицираните „бъгове“ от клиента за своя сметка. Това е необходимо, за да се гарантира качествено тестване на продукта от разработчика. Докато разработчикът каже „готово“ и започне тестването от страна на клиента, „бъговете“ се коригират безплатно.
8. Отговорността за хостване на проекта от страна на клиента се поема от разработчика. В този случай клиентът е длъжен да осигури спазването на техническите изисквания към обекта.
   Причина: хостването на проект от страна на клиента понякога може да причини определени затруднения, което може да доведе до „хетване“, така че отговорността за хостинг и конфигуриране на сървъра трябва да бъде на страната на разработчика на софтуера.
9. Ако разработчикът на софтуер е принуден да прибегне до помощта на специалисти извън неговия екип, той е длъжен да поеме всички свързани рискове от изтичане, загуба на данни или всякакви други щети, които външен служител може да причини със своето действие или бездействие.
   Причина: случва се разработчикът да се разболее, да напусне и т.н. един от служителите. В този случай клиентът трябва да бъде застрахован.
10. Резервни копия на проекта трябва да се предоставят от страна на програмиста поне веднъж на ден. Всички проблеми със загубата на данни по проекта трябва да се поемат от разработчика.
    Причина: тук трябва да посочите кой е отговорен за безопасността на проекта в случай на повреди.
11. Разработчикът трябва да изхожда от популярността на използването на технологиите, които използва при избора.
    Причина: обвързване със собствените си технологии, което ще усложни живота, ако клиентът се премести при друг разработчик.

Известни начини за надценяване на цената на аутсорсинг работата спрямо реалността.Предполагам, че има повече от тях.

• Повърхностна оценка на разходите за разработване на проекта като цяло, без разделянето му на етапи, което може да доведе до 2x-3x надвишаване на цената на проекта.
• Непредоставяне на отчети за извършената работа в срока, определен от договора или невъзможност за контрол на хода на разработката от страна на клиента
• Неправилният избор на технология при изпълнението на техническата част може значително да оскъпи разработката.
• Липсата на правилните специалисти в развойния екип, което увеличава времето и цената на разработката.
• Фиксирана цена за разработване на проект или модул и допълнително увеличение на цената за всяко малко нещо, което двете страни са разбрали по различен начин.
• Фиксирана настройка на разходите за разработка на проекта - по-високият риск налага включването им в цената на проекта.
• При разработването на дизайн не се използва прототипиране, а разработването на дизайн се извършва въз основа на текстово TOR, което в крайна сметка води до голям брой подобрения / корекции и съответно увеличение на цената на проекта.
• Добавяне/усложняване на функционалност. Можете да го направите по-лесно - направете го по-трудно.
• „Красиви“, където не са необходими (можете да кажете за административната част на сайта, ако можете да използвате css рамки за бързо персонализиране на административните части - те започват да се развиват от нулата).

Моделът на връзката „клиент – доставчик на разработка на софтуер“, който според мен е най-близо до практическото приложение.

Много аутсорсинг компании предпочитат да не предоставят достъп до своите системи за управление на проекти, без да предоставят подробна информация, аз лично смятам, че достъпът трябва да се предоставя при поискване от страна на клиента. Клиентът е отговорен за изпълнението на проекта и е важно да виждате напредъка на разработката в реално време!
Освен това смятам, че разработването на софтуер, като се вземе предвид изчисляването на общата цена на проекта, е загуба на пари и нерви, подобно развитие обикновено води до конфликтни ситуации.

1. Заплащане за работа въз основа на почасово заплащане за работата на служителите или средната цена на работата на специалист от целия екип за разработка. Необходима е оценка на етапите на развитие. Защо смятам, че тази форма на ценообразуване е оптимална:
   • Не изисква много скрупулен подход при оценката на проекта, което е почти невъзможно да се направи 100% точна. Ако оценката е направена неправилно и разработчикът на софтуера започне да разбира това, тогава функционалността е „нарушена“, когато е възможно, което в крайна сметка ще се отрази на използваемостта.
   • Подобрява взаимното разбирателство между разработчика на софтуера и клиента, т.к основната задача се свежда до принципа - „направи го ефективно и бързо“, а не „инвестирайте в ограничен бюджет и как ще работи добре“.
   • Клиентът, въз основа на ежедневни отчети за прекарани часове, може да види колко време отделят служителите за различни блокове по време на разработката, което дава представа за скоростта и качеството на работа на служителите на разработчиците на софтуер.
   • Взаимодействието между клиента и ръководителя на проекта се осъществява възможно най-директно, т.е. при използване на скайп, телефони и др.
2. По пощата трябва да се изпращат само 2-седмични отчети и планове (за контрол).
3. Клиентът предоставя прототип на приложението или то се разработва от екипа за разработка на софтуер, ако е необходимо:
   • Опростява разбирането на основната функционалност на проекта.
   • Увеличава общата скорост на развитие на проекта.
   • Ясни изисквания към функционалността както на клиента, така и на разработчика.
   • Ясно разбиране накъде ще се движи проектът.
4. Система за управление на проекти за следене на напредъка на проекта и възможност за наблюдение на процеса, времето за разработка, изразходвано за всяка задача поотделно. За съжаление, разработчиците рядко предоставят достъп.
5. Желателно е целият проект да се изпълнява от един екип, т.е. не бива единият етап да се прави от една фирма, другият от друга и т.н.
6. Контролните точки („изпълнение“) на всеки 2 седмици е оптималното време за контрол на проекта.
7. При разработката се предпочитат добре познати рамки, също и за по-лесно адаптиране в случай на всяка ситуация, когато е необходимо да се прехвърли проектът на други разработчици.
8. Тестването на качеството от страна на разработчика е пряка отговорност. Когато прехвърляте проект или част от него на клиент, всичко трябва да се провери щателно.
9. Поддръжката на различни браузъри е пряка задача на разработчика

Заключение: основното е да се придържате към партньорство / взаимно изгодни и доверителни отношения с разбирането, че разработчиците са едни и същи хора и усложняването на живота им усложнява живота за вас самите! Всеки трябва да носи отговорност за своята част от работата, клиентът трябва да отговаря за предоставянето на ясна техническа спецификация и да реагира своевременно на възникнали въпроси, като не забравя да заплати за работата, а разработчикът - за качество, срокове, бързина. Идеалът, разбира се, не е постигнат, но сме на прав път.

харесвам

В различни източници на литература за продажбите можете да намерите различен брой етапи на продажбата. Всеки автор ги разглежда от своя гледна точка.

Предлагам да разгледаме основните етапи в работата с клиента>:

Етап 1 "Осъществяване на контакт" или "Установяване на контакт"

Всяка продажба започва от този етап.

Целта на този етап: спечелете клиента и го заинтересувайте за по-нататъшен контакт.

При установяване на контакт с Клиента е важно да го поздравите и да му се представите.

"Добър ден. Казвам се Михаил, управител съм на фирма "Windows Plus".

Преди да започнете разговор за нуждите на клиента, се препоръчва да говорите с него по абстрактна тема (техниката „Small Talk“) или да предложите чай, кафе, можете да направите комплимент или да използвате редица други техники на етапа на установяване на контакт.

„Какво знаете за нашата компания? Защо да изберете нас? Какво планирате да купите?

Важно е мениджърът с невербалното си поведение да демонстрира интерес към контакт с клиента, желание да му помогне, добронамереност. Невербалното поведение включва открити жестове, поза, усмивка, наклон на тялото към клиента, открит поглед.

По поведението на Клиента е възможно да се определи дали е установен контакт с Клиента или не. Ако той реагира положително на думите на мениджъра, чувства се спокоен, сам задава въпроси, можем да приемем, че контактът е установен. Ако Клиентът не поддържа зрителен контакт с мениджъра, напрегнат е, не отговаря на въпроси или отговаря неохотно, тогава има смисъл да отделите повече време на етапа на установяване на контакт.

Етап 2 "Идентифициране на нуждите"

Целта на този етап: за определяне на нуждите на клиента.

Колкото по-точно мениджърът определя нуждите на клиента, толкова по-ефективно ще направи презентация на стоки и услуги, което в последствие ще доведе до сделка.

При идентифициране на нуждите е важно мениджърът да може да задава въпроси и да изслушва клиента.

При взаимодействие с клиента е важно той да говори повече, а не мениджърът, за това се препоръчва мениджърът да зададе повече отворени въпроси.

Какъв прозорец планирате да закупите? Къде ще сменяш дограмата? Какъв е климатът в апартамента през зимата и лятото? Кой друг живее в апартамента? На какво основание избирате прозорец?

Затворени въпросимениджър позволяват да се конкретизират нуждите на клиента.

„Често ли проветрявате стаята? Имате ли животни? Удобно ли ви е, ако нашият измерител пристигне утре в 9 сутринта?“

Алтернативни въпросипредлага на клиента избор от опции.

„Удобно ли ви е измерващият да дойде сутрин или следобед? Планираме ли да инсталираме нови прозорци тази или следващата седмица?“

По време на цялата среща с Клиента е полезно да го изслушвате внимателно, тъй като Клиентите често сами говорят открито за своите нужди. Ако някои думи на Клиента не са ясни на мениджъра или той ги е слушал, препоръчително е да зададете на Клиента изясняващи въпроси:

„Правилно ли разбрах, че имате нужда от прозорец с повишена звукоизолация? Доколкото разбрах, искате едното крило на прозореца да е въртящо се, а другото да е въртящо се?“

Желателно е междинният резултат да се обобщава след всеки обсъждан въпрос. Особено ако мениджърът обсъжда няколко продукта или услуги с клиента.

„Така се разбрахме утре да замерим, а дограмата да монтираме другата седмица в петък. И така, вие планирате да инсталирате два нови прозореца: в кухнята - двукрил прозорец с въртящи се крила и в една стая - трикрилен прозорец, в който две крила са въртящи се и единият е „глух“.

Важно е точно да се идентифицират нуждите на клиента и едва след това да се извърши представяне на стоки и услуги.

Етап 3 "Представяне"

Цел:предложи продукт или услуга, които най-добре отговарят на нуждите на Клиента.

Представянето на продуктите и услугите съдържа описание на характеристиките на стоките и услугите, ползите от използването им от клиента и ползите, които потребителят получава.

Полезно е да започнете презентацията с основните предимства на клиента, които следват от нуждите на купувача, идентифицирани от мениджъра на предишния етап.

Важно е да се разграничи как ползата от даден продукт или услуга се различава от ползата.

Предимствое ползата, която всеки клиент получава, като използва този продукт или услуга.

„С тази услуга можете да спестите време и да намалите разходите с 10%.“ „Този ​​монтаж ви позволява да намалите броя на настройките.“

ползае характеристика или предимство, което Ви позволява да посрещнете конкретна нужда на Клиента.

Така всяка характеристика или предимство може да се превърне в полза, при условие че Клиентът има нужда от това.

„Искахте прозорецът да се отваря и затваря лесно, обковът с европейско качество може да го осигури.“ „Казахте, че апартаментът се намира на първия етаж и се страхувате за сигурността на апартамента, предлагам да поставите противовзломна арматура на новата дограма.“

По време на презентацията мениджърът трябва да включи клиента в активен диалог с помощта на въпроси.

„Как се чувствате относно предложението ми?“, „Какво мислите за това?“, „Как ви харесва предложението ми?“

Етап 4 "Работа с възражения"

Цел:за разсейване на съмненията на Клиента относно покупката и премахване на негатива във връзка с продукта или услугата.

За да се намали броят на възраженията на клиента, е полезно мениджърът да отдели повече време на предишните етапи. Често възраженията на Клиентите са свързани с това, че контактът с него не е бил добре установен, нуждите му са били частично идентифицирани или представянето на стоките и услугите не е било интересно за Клиента, твърде дълго и не е задоволявало нуждите му.

Важно е да се възприемат възраженията на Клиента като сигнал, че мениджърът трябва да коригира поведението си (особено ако има много възражения).

Възражения от страна на Клиента могат да възникнат и на предишните етапи на продажбата. Как да се справим с възникващите възражения?

Ефективно се придържайте към схемата за обработка на възражения:

1. изслушване на Клиента;

2. неутрализира емоциите си с помощта на фрази за разбиране;

„Разбирам те“, „Да, съгласен съм, че е неприятно ...“

3. изяснявайте, ако е необходимо, информация чрез въпроси;

4. предлага конструктивни решения или прави алтернативно предложение.

Възраженията на клиентите са 4 вида:

1. възражения, свързани с промени.

„Защо имам нужда от това“, „Не виждам смисъл в това“

При разглеждане на такова възражение мениджърът трябва да обясни на Клиента, че рисковете са изключени, да покаже последствията, ако ситуацията продължи, да даде примери за положителен опит при използване на нещо за първи път.

„Закупувайки прозорец с европейски фитинги, гарантирано ще бъдете защитени от течения, допълнителни настройки на натиска на крилото, задръстване на механизма за затваряне.“

2. възражения, свързани с цената.

„Твърде скъпо е за мен“.

В аргументацията мениджърът трябва да обърне внимание на допълнителната полза, която клиентът получава, можете да сравните цената на стоките с цената на всяко друго не особено необходимо нещо или да разделите цената на определен период от време.

„Когато купувате прозорец от нашата компания, получавате подарък комплект за грижа за прозорци, както и възможност да използвате безплатно регулиране на фитинги“, „Красив нов прозорец в кухнята ще ви струва само 300 рубли. за един ден".

3. възражения, свързани с негативни преживявания.

— Чух, че имаш лош профил.

Полезно е мениджърът да изясни информацията, като задава въпроси на Клиента, за да покаже на Клиента, че го разбира и признава фактите за неприятни събития (ако са били в действителност) и след това да предложи алтернативно решение.

„Да, наистина, имахме партида дефектен профил, който върнахме на доставчика. Към момента сме получили нова партида, вече сме произвели и монтирали над 30 дограма, всички клиенти са доволни.”

4. възражения по решението.

„Трябва да помисля“, „Трябва да се посъветвам с жена си“.

При разглеждане на такива възражения мениджърът може още веднъж да изясни с какво е свързано такова решение, да се увери, че клиентът е приел и разбрал цялата информация, както и да използва методите за извършване на сделката.

„Ако подпишем споразумение с вас сега, тогава в края на седмицата ще можете да се любувате на новия прозорец в кухнята.“ "Само до края на месеца имаме намаление на този продукт."

Етап 5 „Приключване на сделката“

Цел:подтикнете Клиента към сделката и потвърдете правилността на взетото от него решение.

Преди извършване на сделката (подписване на договора), мениджърът трябва да се увери, че Клиентът е готов да сключи сделката.

Това се вижда от сигналите, които показва:

• положителна обратна връзка за продукт или услуга;
• Клиентът изразява одобрение към думите на мениджъра (съгласява се, кима с глава и т.н.);
• директно казва, че е съгласен;
• задава уточняващи въпроси.

Методи за приключване на сделката:

1. метод за ограничаване на условията и времето.

„Ако подпишете договора днес, ние ви даваме 20% отстъпка от прозореца.“

2. метод на комплимент.

— Наистина направи правилния избор.

3. печеливша алтернатива.

„Ще бъдете ли записани за измерване във вторник или сряда?“

В заключение бих искал да кажа, че ефективността на продажбите зависи от уменията на мениджърите. Колкото повече методи и техники за продажба притежава един мениджър, толкова по-гъвкав и успешен е той при взаимодействие с клиента. Професията на мениджър продажби изисква постоянно развитие и самоусъвършенстване на уменията. Желаем ви успех по пътя на професионалното израстване и увеличаване на продажбите.