Взаимодействуйте правильно, или Что предложить клиенту

Ввиду долгих лет моего прозябания в различных сервисных (аутсорсинговых) компаниях, накопился некий опыт так называемых Kick-off процедур для различных проектов. Этим я и хотел бы поделиться.


© mediastone

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

Типы проектов

Советую попытаться ответить на простой вопрос: зачем мы (команда компании А) нужны им (клиенту или команде компании Б)?

Варианты ответа:

a) У них (компании Б) есть деньги и руки (своя команда), но нет времени для реализации;
b) у них есть идеи и время, но нет денег (достаточных, чтобы нанять команду on site);
c) у них есть деньги, идеи и время, но нет рук (специалистов).

Рассмотрим эти варианты подробней:

a) Это типичный пример так называемого Team Extension (в других источниках — Fixed Team). Здесь важно построить доверие между всеми членами команд. Обе команды должны чуствовать себя в одной лодке.

Необходимо избегать любых непубличных коммуникаций. Никто не должен думать, что кто-то забирает у него работу.

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

b) Как правило это тип взаимодействия Time&Material. Он предполагает четкий контроль расходов. Задачи — Время (стоимость каждой задачи).

В данном случае желательно иметь одного человека, способного в любое время суток ответить на вопрос «Почему задача Setup development environment заняла у Васи Пупкина 40 часов?»

Схема коммуникации — все на одного (то есть, на PM или TL со стороны исполнителя).

c) Ну и наконец — «любимый» всеми исполнителями тип Fixed Price Project. Когда клиента не интересует вообще ничего (даже время работы Васи Пупкина), кроме того, чтобы ко времени сдачи проекта, абсолютно все «рюшечки» были на месте в объеме «чем больше от оговоренного — тем лучше». Как и в предыдущей схеме — все шишки на PM.

Смог уговорить клиента, что с него уже хватит, — герой. Не смог — иди уговаривай дальше.

Здесь схема коммуникации — один представитель клиента (тот, кто «скоп» подписывал) на одного PM.

Для исполнителя, конечно, самый луший вариант — Fixed Team, но для этого необходимо добиться полного доверия клиента на всех уровнях (начиная от их девелоперов и до их V- и С-level). Поэтому хорошая практика — предлагать Fixed Price проект на небольшой (чем меньше, тем лучше), четко ограниченный кусок функционала, который команда исполнителя уверенно сможет выполнить в срок и с необходимым качеством. После успешного завершения этого пилотного проекта клиенту будет гораздо легче обсуждать другие варианты взаимодействия.

Как узнать, есть ли у клиента деньги?

Гуглить, гуглить и еще раз гуглить! Я обычно начинаю с пристального изучения сайта предполагаемого клиента. Здесь я оцениваю не только популярность, но и качество самого сайта. Качественные, продуманные сайты — признак внимания, а значит и затраченных усилий и времени.

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

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

Можно еще проанализировать количество скачанных продуктов и/или абонентов вместе со средней стоимостью продукта и/или услуги.

Наконец, если после оглашения ваших рейтов они все еще хотят продолжать разговор о взаимодействии — значит, ваши рейты их устраивают. Ну, или вам следует подумать об увеличении рейтов. :-)

Как узнать, есть ли у клиента руки?

Кроме самого простого — спросить его самого, — можно еще поискать вакансии этого клиента на популярных в его стране и в мире сайтах. Также можно проверить вакансии на сайте самого клиента. Как правило, если ищут Associate Java Developer, это значит что у них уже есть Senior Java Developer, как минимум один. Также люди любят отмечать информацию о работодателе на LinkedIn, это тоже хороший источник информации.

Как узнать, есть ли у клиента время?

Это самый сложный вопрос, так как время — штука относительная (если верить Энштейну), поэтому для каких-то проектов люди готовы выделить вечность, а для каких-то — вчера уже было поздно. Здесь я бы посоветовал замерять расстояния между контактами (Skype, e-mail или звонками) со стороны клиента. Довольно редко люди откладывают в долгий ящик то, что они считают критичным по времени.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті

  • Про побудову продуктів в аутсорсинговій компаніїПро побудову продуктів в аутсорсинговій компанії

    Victor Haydin

    Розглянемо типовий шлях, який долають аутсорсингові компанії, коли починають писати власні продукти. Я не пропоную тут чеклістів чи рецептів успіху — в мене їх немає. 30

  • Вплив віз H-1B та аутсорсингу на економіку СШАВплив віз H-1B та аутсорсингу на економіку США

    Vasyl Soloshchuk

    Віза H-1B призначена для висококваліфікованих та талановитих іноземців. Я дивлюсь на цю проблему з точки зору нашої IT галузі. В статті я проаналізував працевлаштування спеціалістів за візою H-1B порівняно зі стаффінгом через аутсорсингові компанії. 164

  • Тестування вимог — перший крок в роботі над проектомТестування вимог — перший крок в роботі над проектом

    Igor Luzhanskiy

    Хочеться, щоб ми поглянули на питання роботи з вимогами з висоти пташиного польоту й водночас заглибились у деякі конкретні приклади того, яким чином тестуються вимоги, які є інструменти тестування, які є, передусім, категорії, за якими вимірюється якість вимог.... 12




21 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Грубо говоря, деление такое:
1) База. Качество максимум, функционал — основной.

3) Мелкие довороты, которые делает максимум 1 человек. Не путать с улучшениями, это именно изменения. Либо/либо. И в тех местах, которые не были согласованы. К примеру где находится кнопка «Выход» на интерфейсе — не будете же Вы по этому поводу переговоры делать, проще положить в любое место и потом спросить о пожеланиях.

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

Суть подхода: пункт 2 — не более чем договор о намерениях, пока не готов пункт 1. Вы — не рискуете, клиент — не рискует. Но он часть продажи, лакомый кусочек. Пункт 1 позволяет сделать качество, и с минимальными рисками: если клиент окажется недоволен чем-то, то проще переделать малую часть и одну проблему, чем доказывать на обширном функционале что 1000+1 жалоба вызваны только одной маленькой проблемой. Ведь когда вы о проблеме узнали — уже слишком поздно, решение об отказе могли уже принять (особенно если внутри клиента есть люди, для которых ПО в принципе нежелательно или просто боятся).

Выгода: ядро может исполняться по fixed-price, то есть заказчик риск берёт на себя. Суть фокуса, что максимальная выгода клиента в пункте 2, потому отказ клиента в пункте 1 не может быть вызван желанием кинуть (съэкономить) — останется с тем самым разбитым корытом. Что продавцы сумеют доказать, продав продукт «с нуля». Не забываем, что ядро — качественное, продавать — легко.

Выгода № 2: На качественном ядре легко тестировать функицонал, и изменения одной функции не влияют на остальные. Это значит резкое понижение стоимости разработки, функционал отходит другой (дешёвой) команде. А ведь это основной объём кода!!!

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

Спасибо, отличная статья. Теперь как-то в кучу собралось все то, что обычно делаешь на подсознательном уровне.

Следует иметь ввиду, что наши клиенты оценивают нас примерно по тем же параметрам (not limited to, как говорится). Так что не стОит пренебрегать сайтом, культурой коммуникаций и быть осторожными с публикацией информации о компании.

s/подуманные сайты/продуманные сайты/

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

ну и замечание про пункт а) — вас будут по-любому подсиживать, и иногда лучше некоторую информацию ( равно как и сорсы ) от ихней команды попридержать. Короче тут начинается политика, а в политике всё зависит от ситуации и личных контактов.

а) — вас будут по-любому подсиживать, и иногда лучше некоторую информацию ( равно как и сорсы ) от ихней команды попридержать.

Спустимся на уровень простых разработчиком (не тех-директоров).

Вы советуете мне документировать код, не писать в вики и тд (не распространять навыки среди команды)? Ведь быть единственным узкоспециализированным работником — круто: меньше вероятность что тебя уволят, доп аргументы при пересмотре ЗП...

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

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

Я не спец в теме, поэтому можна пример «богатой» конторы с отстойным сайтом.

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

на счёт второго — не имею возможности делится такой информацией

на счёт первого — я ничего не говорил про разработчика

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

на счёт второго — не имею возможности делится такой информацией

Проблемы с DNA? ... То есть NDA? :)

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

Проблемы с DNA? ... То есть NDA? :)

у вас чего тут хамство это признак хорошего тона ?

у вас чего тут хамство это признак хорошего тона ?

Просто не люблю когда люди «съезжают на дурачка».

на «той» стороны сидят пацаны которые ближе к его телу и могут рассказать ему разное.

Вы наверное решите что это так же хамство, но:

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

Просто не люблю когда люди «съезжают на дурачка».

менеджер разглашающий конфиденциальную информацию подлежит немедленной дезинтеграции вместе с креслом и компъютером :)

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

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

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

Ну и ещё немного про программистов: вовлечение их в «политику» проекта черевато несколькими проблемами:
1. программист скажет себе «блин, какой плохой кастомер, долбанная политика, я хочу просто программировать, пойду поищу себе другого»
2. если команда на той стороне сделает замечание программисту (при чём оно действительно может быть неадекватным) он может сказать себе «ха, так мне сказали что они плохие ребята ,пошлю ка я их на ...», после чего ребята на той стороне демонстрируют письмо главному заказчику и до свидание проект
3. не имея полной информации про коммуникацию с заказчиком и его ребятами ( иногда такой информации нет даже у менеджера ) будет каждое своё письмо согласовывать с менеджером, в результате чего последний сильно отвлекается

Вообщем всем спокойней если программист просто программирует, включая на самом деле самого программиста.

По пунктам:
1) Абсолютно правильно, поэтому и не должно быть ни какой политики :)
2) А если Марс будет с 7 доме Юпитера? Вывод набираем адекватных сотрудников, тогда отношение с заказчиком зависят больше от астрологии, а не от психических отклонений сотрудника.
3)

иногда такой информации нет даже у менеджера

будет каждое своё письмо согласовывать с менеджером

А менеджер с кем согласует? Решение: Пытаемся набирать адекватный и квалифицированный персонал.

Вообщем всем спокойней если программист просто программирует, включая на самом деле самого программиста.

А если алгоритмы и модели спускать кодерам, то это еще спокойнее :)

в своих утверждениях я говорил про сокрытие информации не от клиента а от его «ребят»

Клиент это компания. Но общаетесь вы с одним из «ребят» этой компании — менеджером. Так что вы в любом случае открываете инфу «тем ребятам», и если вы будете открывать инфу по разному (если уж заказчик решил что его «ребята», а не только менеджер, должны быть вовлечены в проект), больше шанс что в вас заподозрят жулика.

По личному опыту — если у клиента мало денег, то он как раз пытается сделать проект по методу Fixed Cost с как-можно менее точным ТЗ.

В этом случае он за фиксированные деньги будет стараться выбить как можно больше функционала (даже такого, о котором в ТЗ сказано лишь пол-слова)

На T&M такая штука не пройдет — все равно прийдется оплачивать дополнительное время специалистов.

Спасибо за интересный анализ

работал в том, что автор называет Team Extension. Не знаю, в каких отношениях между собой был менеджмент, но их полкоманды относилась к нашей как к людям, отбирающим у них работу. со всеми вытекающими. особенно это проявлялось в момент принятия каких-то технологических решений. из всех возможных решений всегда выбиралось самое комплексное, проблемное (in further perspective) и ненадежное, и всегда это решение было не нашим. вопщем, геноцид был тот еще.

Отличная статья. Наконец-то что-то на DOU интересное и для CEO ;)

Мой опыт правда подсказывает что T&M не всегда от отсутствия денег. Иногда он от желания контролировать каждого работника напрямую, включая его присутствие (so called hyper controlling behavior). А иногда он используется вместо тестового/пилотного проекта.

по поводу с) также замечание — бывает «руки» обладают такими скиллами, что их клиенты предпочитают нанимать на dedicated basis и «рулить» ими самостоятельно.

И хочется также подчеркнуть вопрос времени. Если вам не отвечают быстро — то да, то, что на вас «сгрузили» на данный момент не самое важное. Но, как показывает опыт, это только на данный момент. И поэтому надо делать качественный delivery — on-time and on-budget. А то потом поздно будет доказывать что-то.

1.статья написана как-то по-программерски, мне показалось))
нет лишних переменных, структурировано.
2. про

долгих лет моего прозябания в различных сервисных (аутсорсинговых) компаниях

плз поподробнее, что Вы для себя решили в отношении отсорсинга vs продуктовая_разработка. (и отдельной статьёй, если накипело много)
3. про взаимодействие с клиентом.
есть простой но неочевидный моментик: «клиенту надо дать то что_он_хочет».
— не самое лучшее, и не самое рулёзное.
— понять и дать. иначе он «frustrated».
----------------
теперь лирика (можно не читать)
этот моментик дошёл до меня на берегу Азовского моря (я его не особо так люблю, но не суть). Меня поразило количество не бедных россиян на хороших машинах.
Они педалировали за тридевять земель к этому болоту.
Рисковали на узких разбитых дорогах, где «не ты — так тебя».... брр-р.
Почти рядом — Чёрное море, там всё намного приятнее.

Есть Болгария итп.

Но...
1. детям полезнее таки Азовское.
2. у них самих с детства есть сентимент к Азовскому.
3. ещё что-то, — у каждого — своё.

т.е. они готовы потратить те же ресурсы на то_что_они_хотят, а не на самое_лучшее.

Согласен что замечания правильные и нет абсолютно черного или белого. Признаюсь — специально утрировал и сгущал краски для лаконичности статьи :-) Основное все же — это доверие между клиентом и исполнителем. А доверие строиться долго и сложно. Ну конечно же — качественный деливери в любом случае обязан быть в не зависимости от схемы сотрудничества. Без него вообще ничего не построить.

Підписатись на коментарі