Прозрачность — ключ к успешному сотрудничеству

Анна Шапошникова
December 30, 2015

I believe in teamwork, based on passion, trust and respect…

Начиная каждый проект, хорошая команда должна верить в его успех. Рассматривая этот тезис в обратном порядке, можно сказать что для успеха проекта нужна хорошая команда. Но как команде стать "хорошей" или командой вообще?

Мы знаем, что в разработке ПО, заказчик\бизнес сами выбирают команду по разным критериям, руководствуясь подсказками sales-менеджеров, опираясь на резюме и рейтинг её участников. В этом плане стороне бизнеса несколько проще, т. к. делая свой выбор, они так или иначе знакомятся с командой. Команде же предстоит любить заказчика таким, какой он есть, изучать его и вместе с ним строить гармоничные партнёрские отношения. Прописной истиной является то, что невзирая на тип отношений, все они будут благополучны, если построены на доверии.

Доверие же не рождается с появлением команды, а достигается в процессе. Очень эффективным средством в развитии доверия является прозрачность.

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

Давайте рассмотрим схематично взаимосвязь между прозрачностью и доверием:

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

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

Если провести параллель с романтическими отношениями, то это своего рода "конфетно-букетный период" в рабочем процессе. Таким образом, мы плавно двигаемся к точке В. Здесь заказчик всё ещё испытывает некие сомнения, но уже начинает доверять команде, т.к. на данном этапе он уже является её частью. Он знает участников, понимает уровень и возможности каждого члена команды, видит кто за что отвечает и первые результаты совместного труда.

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

Так как работа над проектом - чаще всего долгосрочное сотрудничество, возникают случаи, когда заказчик отстраняется от дел, перенимая на себя другие обязанности, как, например, продвижение продукта на рынке. В такие моменты у команды часто появляется желание отказаться от "рутинных" средств достижения прозрачности, так как заказчик и сам особо не настаивает на этом. И вот уже мы не пишем дневной отчет, не созваниваемся для планирования итераций, не выписываем истории вместе. Доверие заказчика всё также остаётся на высоком уровне и он особо не беспокоится о качестве коммуникации в последнее время, учитывая, что у него теперь есть отдельная миссия. Теперь мы в точке D. В таком режиме можно проработать какое-то время, но теперь цена любой ошибки будет слишком высока для команды и мы с легкостью можем вернуться в точку А, почти полностью утратив доверие заказчика.

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

Кроме доверия мы также получаем дополнительные бонусы:

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

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

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.