Наверх ▲

Выбор подрядчика на IT-проекты: мечты заказчика и суровая реальность

Ольга Павлова Ольга Павлова Владелец 80% компании «Собака Павлова»

 

Ольга Павлова: Добрый день! Меня зовут Ольга Павлова! Сразу оговорюсь: мой доклад не имеет никакого отношения к юзабилити.

Типичная формулировка заказчика, которую он, может быть, и не произносит вслух, но в голове все время держит: "Я не знаю, чего хочу, но хочу получить это быстро".

Если немного посмотреть по сторонам и подумать, то нетрудно понять, что подобная формулировка имеет право на существование просто потому, что она довольно часто встречается.

Чего же хочет заказчик?

Он хочет денег, власти, вещей, самореализации, счастья и пр. Заметьте, что здесь нигде не написано, что он хочет сайт, мобильное приложение и т.д. Суть сказанного заключается в том, что непосредственно создаваемое вами, может быть, никакой особой ценности для него не несет.

Следующий вопрос: от кого он этого хочет?

Ответ на данный вопрос прост. Почти у любого заказчика существует начальство. Это важный момент, если вы стоите на позиции потенциального подрядчика. Перед вами - заказчик, который, казалось бы, сам себе голова. Однако почти всегда это не совсем так. Первое одобрение, которое человек хочет получить, - это, как правило, одобрение своего начальника. Явно или неявно к вам пришли за следующим заявлением: "Сделайте так, чтобы я смог отчитаться перед вышестоящими лицами и получить похвалу".

Как ни странно, в продажах из сферы IT-производства это чуть ли не самая важная вещь. Специалист может быть грамотным, проект - перспективным. Просто игнорирование упомянутого фактора (необходимость отчитываться перед вышестоящими) с самого начала срывает многие сделки.

Уже мало кто думает, что заказной IT-проект – это производство вещей. Хотя раньше так думали довольно продолжительное время. Конечно же, любая IT-деятельность – это весьма дорогая психотерапия. Деятельность, связанная с IT-проектом, очень напоминает деятельность по оказанию психологических услуг.

Нижняя часть айсберга обычно не заметна в повседневной работе по созданию сайта, приложения и т.д. Тем не менее, она существует. Именно ее покупают, даже если не говорят о ней вслух.

Покупать психотерапию у программистов – затея довольно странная. Не говоря уже о многочисленных байках, касающихся аутичности программистов и т. д.

Это не совсем, конечно, правда, хотя взаимодействие в плане "человек - машина" накладывает свой отпечаток на программистов. Значит, когда мы говорим о сделке, о том, что заказчик выбирает некую команду, подрядчика, группу IT-специалистов для удовлетворения своих потребностей, то программистов он выбирает в последнюю очередь.

Что он делает?

Конечно же, он выбирает работу менеджеров. Деньги платятся не за профессиональные навыки программистов. Если бы это было так, дешевле было бы этих программистов нанять в штат (пусть даже временно).

Что такое работа менеджеров?

Иногда кажется, что они валяют дурака.

Тем не менее, работа менеджера – это достаточно понятная, с точки зрения заказчика, деятельность. Технические специалисты обладают профессиональными возможностями, которые надо превратить в нечто ценное. Само по себе это не произойдет, поэтому нужен определенный стимул. Происходит постепенное превращение, достаточно большая работа, стоящая достаточно много денег. Именно ее, как ни странно, и покупают.

Понятно, что при расчете стоимости IT-проекта учитывается не она. Выбор подрядчика осуществляется на основе деятельности менеджеров, а не на основе деятельности программистов, как ни странно.

Что же происходит? Во-первых, с точки зрения и заказчика, и руководителя проекта весь проект – одна непрерывная сделка. Когда люди заплатили деньги, это еще не значит, что они получат результат за эти деньги, аванс или даже полную сумму. Все мы знаем, как растут бюджеты, что сделку можно в любой момент расторгнуть, а проект закрыть. Соответственно, процесс "обхаживания" заказчика длится достаточно долгое время, пока не будет завершена значимая часть работ.

Сделка делится на две части: обещание и работу. Соответственно, продажа и производство – относительно независимые вещи.

В связи с этим имеет место внутренний конфликт, который каждому из вас знаком в определенной степени. "Продажники" заключили сделку, а нам нужно что-то производить.

Операции продаж и производства должны быть тесно переплетены и взаимозависимы. Один человек занимается этим очень редко (разве что в маленьких командах).

Довольно часто создается ситуация, когда специалисты работают отлично, а продать продукт никак не получается. Обсудим  один вопрос: может быть, причина в том, что процесс продажи организован не слишком хорошо, «на сдачу»?

Подрядчикам очень часто кажется, что самое главное в работе – сделать. Это далеко не так.

Кто создает тот самый ад?

Мы с вами. Дело в том, что мы ведем себя не так, как ждет заказчик. Из этого проистекают разнообразные конфликты, чисто человеческие и проектные проблемы.

Что это за странное поведение? Удивительное рядом: никто из нас не умеет читать мысли. Многие пытаются, но, в общем, эффективность пока не доказана.

Экономить время и считать деньги – подобные идеи в среде программистов не модны. Заказчик почему-то думает по-другому. Почему-то он не готов отдать все свои деньги и время на качественную разработку.

Также типична ситуация, когда разработчики проекта не стремятся поддерживать коммуникацию с заказчиком, полностью погружаясь в работу. Я не говорю о том, чтобы менять подобное положение вещей. Речь идет о том, чтобы на этапе предпродажи некоторым образом смягчить печальную перспективу.

Слушать и слышать – тоже очень затруднительно для IT-специалистов. Тем не менее, это проблема. Проблема для заказчика, потому что даже среди заведомо неконструктивных идей он всегда скажет нечто важное и потребует от вас отчета.

Еще одна трудность заключается в учете различных факторов. Реальность такова, что она не хочет раскладываться по полочкам. Если она не вписывается в ваши рамки, это ваша личная проблема, чему заказчик, разумеется, не будет рад.

Кроме того, разработчик может заявить: «Я читаю письма только с 10-ти до 11-ти. Вы на два часа опоздали с присланным материалом и не сказали, что здесь должна быть запятая. Я буду работать и общаться так, как будет удобно мне». Это психологически трудно для заказчика и неизбежно в любом IT-проекте, каким бы он ни был благородным и человеколюбивым.

Добавим к этому, что довольно редко команда разработчиков хорошо знакома заказчику, даже если мы говорим о внутренних проектах. Это — следствие минимизации коммуникации.

Плюс мы с вами всегда норовим "выкатить" более-менее конечный результат. Работа с точки зрения заказчика всегда более-менее черный ящик. Даже если кто-то практикует agile и прочие чудеса, это ожидаемая проблема. Она снижается разными техниками, конечно, но от нее никто не застрахован. Это то, чего боится заказчик, когда выходит на вас как на потенциального подрядчика.

Кроме того, разработчики проекта, как правило, показывают только результат, близкий к конечному. Сам процесс работы для заказчика - черный ящик. Даже если кто-то использует agile, это остается проблемой. 

Навязывание «хороших» решений – любимое дело разработчиков. Хорошо никогда не бывает, поскольку заказчик ограничен в средствах, но последнее, как правило, редко волнует разработчиков.

А IT-специалист, который умеет признавать свои ошибки, – это вообще очень ценный кадр на рынке труда. Частное лицо (программист или дизайнер, или верстальщик), которое прямо на собеседовании продемонстрирует, что умеет признать свою ошибку и быстро ее исправить, так или иначе не будет иметь проблем с трудоустройством.

Также разработчики имеют свойство навязывать другим системное мышление, которое не слишком распространено за пределами этого зала. Мы и так все это знаем.

С точки зрения потенциального заказчика, кажется, что мы — довольно странные люди, с которыми довольно сложно иметь дело. Не дай Бог вмешаться – получишь отпор и останешься без денег, что довольно болезненно. Да ещё и нагрубят. Подобные страхи тоже присутствуют.

Когда начинается разговор заказчика с потенциальным подрядчиком, то он выглядит следующим образом: "Мне очень надо, но я боюсь. Успокой меня, расскажи, что это все не так страшно. Покажи мне, что ты не такой страшный, как остальные, и тогда я захочу иметь с тобой дело".

Как надо продавать?

Если здесь присутствуют сотрудники отдела продаж, то они наверняка знают, как это делать. Но как быть ИТ-специалистам? Рассказывать о достижениях в техническом плане, показывать портфолио или нечто другое?

В большинстве случаев вести себя прилично — это более чем достаточно, чтобы продать товар или услугу. "Прилично" — это по меркам заказчика.

"Я тебя слышу и понимаю. Ты сказал фразу, а я ее услышал". Проговаривать надо постоянно. "А вот еще прикрепить сюда бантик, а туда рюшечку". – "Хорошо. Вы хотите сюда бантик, а туда рюшечку". Заказчик будет счастлив: вы его услышали. Все!

"Мне что-то жмет. Ты же великий IT-специалист. Что мне жмет? Расскажи!" Очень трудно угадывать проблемы заказчика, но делать это приходится. Причем, угадывая, надо не заострять внимание на негативе, а предлагать конструктивные меры.

Даже если вы будете заниматься другим делом, вам следует поступать аналогичным образом. Вы показываете свою готовность решать задачи, но не на своем языке (нажимать на клавиши и программировать), а на языке заказчика.

Считать деньги и время — мучительное занятие. Редко у кого это получается точно с первого раза. Но в первую очередь важно продемонстрировать готовность оценить стоимость задуманного, даже если четкое представление на первых порах отсутствует.

Дла решения подобной задачи существует достаточно понятный способ. Надо договариваться не о том, что вы будете делать, а о том, как будет достигнут желаемый результат. "Мы с вами договоримся о том, что проект будет реализовываться в соответствии с определенной методикой", - говорите вы, показывая диаграмму Ганта. "Это займет 800 часов рабочего времени. 800 часов дробим на мелкие задачи по 4 – 8 часов. Подписываем?" – "Подписываем!"

Да, конечно, надо учитывать не только саму работу, но и многочисленные согласования, а также исправления. Раза с восьмого обычно начинает получаться.

Кроме того, человек чувствует себя комфортно на своей территории. Поэтому продавать удаленно – дело довольно сомнительное. Приезжайте к заказчику и разговаривайте с ним на месте. Можете считать это магией.

Конечно, не очень хочется знакомиться со всеми потенциальными заказчиками. Во-первых, поток желающих познакомиться может оказаться довольно большим. Во-вторых, далеко не все они станут заказчиками. Зачем, казалось бы, тратить свою жизненную энергию? Лучше я останусь в офисе и буду писать код. Это не правильно. Покажите заказчику людей. Чем больше людей вы покажете с выгодной стороны, тем большее доверие вы сможете вызвать и тем меньше вероятность, что вы получите отказ.

Заказчику лучше представить живой (не на бумаге) рассказ о том, что вы собираетесь делать. Предлагайте свой вариант. Если он его не устроит, предложите другой. Разговаривая об этом, вы демонстрируете свою компетентность.

Работая с заказчиком, бумагами надо пользоваться довольно редко. Лучше рассказать, что у нас не просто портфолио с 20 крутыми проектами, а мы еще обладаем компетенцией, чтобы сделать 21-й.

Если есть возможность «ошибиться», не задевая личность заказчика, обязательно «ошибитесь» — это такой прием. После этого признайте «ошибку» и с лихвой компенсируйте допущенный промах. 

Про инкрементальную разработку, наверное, многие знают и так лучше меня. Заказчик ждёт вполне ожидаемый результат. Не обязательно разбивать всю работу на равномерные процедуры вроде agile-релизов. Важно, вы всегда стремились к маленькому промежуточному результату на ограниченном временном промежутке.

На одном этапе мы стремимся нарисовать эскизы, на втором – провести юзабилити-тестирование, на третьем - получить одобрение большого начальника и т.д. Т.е. целый процесс распадается на маленькие, достаточно понятные кусочки.

Какой товар нужно показывать лицом?

Мы поговорили о процессе продаж. Теперь перейдём к объекту продаж. Как ни странно, речь идёт не о вашем поведении, а всего о трех пунктах. Заинтересованных лиц отсылаю к методологической литературе, которая последние 20 лет сводится к трем вещам: коммуникации, итерации и лидерам. Если ваша команда обладает ими, то у проекта есть хорошие шансы.

Совершенно не удивительно, что для заказчика подобные ориентиры важны. Как будет устроена внешняя и внутренняя коммуникация команды? Как будут устроены итерации, упомянутые выше? Есть ли среди разработчиков лидеры или нет? Эти темы необходимо постоянно затрагивать в разных формах. Это три контрольные точки любого проекта, которые настолько просты, что невозможно поверить в их реальную работоспособность. Кажется, что все должно быть гораздо сложнее. Нет.

Зачем это нужно заказчику?

Какие конкретные результаты он получит от подобного стиля предварительных переговоров?

Самое важное — коммуникацию. Затеваемое вами заказчику может показаться черным ящиком. Вы предлагаете ему инструменты контроля, некие рычаги управления. Вы не можете точно предугадать, какие именно рычаги ему понадобятся, но вы всегда можете предложить некоторые варианты, из которых он сумеет выбрать нужные.

Также заказчик будет лучше ориентироваться во временных и денежных затратах. Все мы знаем, что производить подсчет финансовых и временных затрат довольно сложно. Это стоит научиться делать в первую очередь. Плюс-минус Нарвские ворота. Это возможно. Боюсь давать какие-либо советы «в лоб».

Деньги – сроки, деньги – сроки. Да, все мы знаем, что это трудно, некоторые знают, что это возможно. Если вы стараетесь развиться в этом направлении, наверное (боюсь советовать что-то в лоб), первым делом надо научиться считать эти "деньги – сроки". 

Отчет перед начальством – важная процедура для заказчика. Вы можете о ней даже не знать. Попытайтесь надавить на эту точку, и вы увидите, как человек отреагирует. Для него это очевидная вещь, хотя вам она может показаться малоинтересной.

Кроме того, чувство собственного достоинства никто не отменял. Только в нормальном человеческом состоянии можно принять осознанное решение. Образно говоря, под дулом пистолета человек будет ощущать, что он сделал не лучший «выбор». Поэтому заказчику нужно давать почувствовать себя человеком, и тогда он захочет работать с вами.

Некоторые особенно счастливые команды сразу получают готовых заказчиков, которые стоят в очереди. Но не стоит обманываться: была проделана значительная работа по выстраиванию этой очереди. С нами (конкретно с брендом, командой и так далее) не рвутся работать. А надо, чтобы захотели.

Обидно делать бесплатно большой объем работы. С другой стороны, если у нас помраченный рассудок и мы по-прежнему думаем, что работают только программисты, то можно вас обрадовать: работы программистов тут нет.

Нужно ли это вам (и вам лично, и вашей команде)?

Зачем нужен геморрой на ровном месте? Кто хочет, вроде, те и так заказывают.

Мало кто хочет иметь дело с машинами, системами. Ключевое слово - "хотеть". Желание взаимодействовать возникает только тогда, когда ты видишь живых людей на другой стороне.

Кстати, отказаться от работы с живыми людьми гораздо сложнее. Обычно этого вообще не происходит. Как правило, говорят: "Мы через годик к вам зайдем", – и довольно часто заходят. Важно вызвать это желание и показать, что вы люди, а не просто мегакоманда с хорошим портфолио. Люди готовы платить за то, чтобы общаться и работать с людьми.

Схема предварительной продажи «в лоб» помогает «задрать» ценник. Иначе говоря, мы настолько хороши и понимаем это, что считаем себя вправе увеличить стоимость своих услуг. Никто не будет возражать.

Если ваш заказчик – частное лицо, разговор должен быть построен по-другому. В бизнесе нет понятия "дорого". В бизнесе есть понятие "цена не соответствует предложению". Соответственно, предлагайте что-то действительно хорошее, и вы продадите его дорого. Улучшение процесса продаж позволит поднять планку.

Конечно, с первого раза выполнить наши рекомендации довольно сложно. Я понимаю тех, кто думает: "Какая ерунда! Я не хочу этим заниматься. Это все бла-бла-бла". В общем, они правы. Наверное, это "бла-бла-бла" до тех пор, пока вы не столкнетесь с задачей "продать или умереть с голоду". Вот тогда эти знания станут очень важными, нужными и полезными.

Спасибо за внимание! 

 

Вопросы и ответы

Реплика из зала: Как лучше подходить к заказчику: лично или все-таки сначала e-mail?

Ольга Павлова: Любой ценой назначайте встречу.

Реплика из зала: Именно личная встреча лучше всего?

Ольга Павлова: Да.

Реплика из зала: Если проект уже находится на некой стадии разработки, то как стоит поступить? Лучше показать, что существует довольно много перспектив, но требуется доработать проект за счет заказчика? Или целесообразнее рассказать, что уже есть что-то стабильное, пускай и не столь прибыльное, но зато это можно будет впоследствии доработать?

Ольга Павлова: При прочих равных условиях надо делать упор на стабильности. Но заказчики бывают очень разными – некоторые всегда хотят мечту. А что заказчик хочет видеть, то и стоит показывать.

Реплика из зала: Есть ли принципиальное отличие между внешним и внутренним заказчиком? Я, например, работаю в крупной конторе. Мой заказчик довольна часто является именно внутренним. Вся эта петрушка имеет отношение только к внешним заказчикам или к внутренним тоже? Спасибо.

Ольга Павлова: Очень хороший вопрос, я очень рада, что вы его задали. Внутренний заказчик отличается от внешнего только одним – обычно он меньше считает деньги и учитывает трудозатраты не так дотошно. Кроме того, к внутреннему заказчику у вас всегда есть доступ. Вы всегда сможете отследить момент, когда у него возникнет новое желание, что очень важно.

Реплика из зала: В докладе тема программистов раскрыта не была, хотя основную работу выполняют они. Какой уровень взаимодействия должен быть между заказчиком и программистом?

Ольга Павлова: Программисты – это очень ценные люди. Я ни в коем случае не хочу сказать, что программисты –  шлак. Я говорю только об одном: покупают не программистов, а нечто совершенно другое. Это вообще другая область жизни. Работа между программистами и заказчиками находится в сфере ответственности менеджера. Моей целью было показать, зачем необходимы менеджеры отдела продаж.

Реплика из зала: Прямое взаимодействие между заказчиком и программистом должно иметь место или нет?

Ольга Павлова: Под контролем менеджера - да. Напрямую – нет.

Реплика из зала: Ни в коем случае?

Ольга Павлова: Это очень рискованная ситуация для обеих сторон.

Реплика из зала: Продолжение предыдущего вопроса. Стоит ли пускать к заказчику менеджера, лидера команды, который только-только вышел из среды программистов?

Ольга Павлова: Сначала надо выяснить, как он себя позиционирует. Если он позиционирует себя, грубо говоря, главным программистом, то не надо. А если он понял, что заказчики тоже чего-то хотят, а его работа состоит в ориентации на их желания, то да, можно.

Реплика из зала: Если кратко, как оценивается работа менеджера, коммуникации в денежном выражении?

Ольга Павлова: Кратко – это 15 % стоимости. Если не кратко, то в плане всегда указана только работа менеджера.

Реплика из зала: Стоимость труда программистов не заложена?

Ольга Павлова: Они указаны в норма-час.

Реплика из зала: Спасибо.

Реплика из зала: Хорошо. Допустим, программист вырос до менеджера, и у него это первый серьезный проект. Как определить, что бывший программист (а ныне - менеджер) уже готов к общению с заказчиком и он не будет его "грузить" технической ерундой?

Ольга Павлова: Пусть он продаст вам тот проект, который сейчас ведёт.

Реплика из зала: Вам – это кому?

Ольга Павлова: Человеку, который озабочен данным вопросом. Пусть он просто сыграет роль заказчика.

Реплика из зала: Вроде тренинга?

Ольга Павлова: Да. Нечто в этом роде.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Павел Уваров

Павел Уваров

Работает в команде Google SRE в Дублине (Ирландия).

Доклад от Google о принципах и процессах, полезных при создании программных систем.

Доклад от компании "Рамблер" о том, почему почтовые веб-приложения лучше старых добрых веб-сайтов.

Дмитрий Сатин

Дмитрий Сатин

Советник министра в Министерстве связи и массовых коммуникаций Российской Федерации, евангелист юзабилити

Довольно интимный, интроспективный доклад о самомотивации не для всех. Дмитрий Сатин объясняет, "как не стереться в пыль".