Ага, доверие, говорите? Звучит как что-то из серии "единороги и радуга". Вот только откуда оно берется-то? Прозрачность, это, конечно, хорошо. Но как насчет реальных кейсов, а не просто слов?

Ну, лично я считаю, что доверие строится на выполнении обещаний. Обещал фичу к среде, сделай к среде. Не можешь? Предупреди заранее, объясни почему. А не когда уже сроки горят, и все сидят с квадратными глазами. Вот это, кмк, укда важнее любой "максимальной открытости".

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

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

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

Вот тут Ланна прям в точку попала. Технически, построить доверие с заказчиком, который сам не понимает, чего хочет, это тот еще квест. Я как-то работал над проектом, где ТЗ менялось примерно каждые полчаса. Сначала вроде бы все четко, а потом, бац!, новый функционал, который полностью перечеркивает предыдущие договоренности.

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

Кмк, это помогает лучше, чем просто переписывать ТЗ по сто раз. Потому что ты видишь реакцию вживую, а не через поток писем. )

Ланна, вот интересно, ты пишешь, что "никакая прозрачность не спасет, если ты сам...". А что именно ты имеешь в виду под "сам"? Ты про конкретные ситуации, когда разработчик не справляется, или про какие-то более тонкие моменты? Просто на практике бывает, что заказчик требует невозможного, и даже самая подробная отчетность не меняет сути. Были у меня случаи, когда клиент упирался рогом хотя объективно задача была сверхсложной, и прямо сказать ему об этом было непросто. Ну, как-то так.