The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Большинство наших клиентов довольно удивляются, когда мы объясняем им, что с первого дня проекта они получат полный доступ к исходному коду. Мы позволяем им видеть все, что происходит в проекте, включая репозиторий Git, отчеты об ошибках, обсуждения между программистами, сбои в непрерывной интеграции и т.д. Они часто говорят мне, что другие команды по разработке программного обеспечения, занимающиеся аутсорсингом, хранят эту информацию внутри компании и предоставляют только окончательные версии, редко вместе с исходным кодом.
Я понимаю, почему другие разработчики стараются скрыть как можно больше. Дать спонсору проекта полный доступ к разработочной среде не так просто. Вот краткое изложение проблем, с которыми мы сталкивались, и наших решений. Я надеюсь, что они помогут вам честно показать вашим клиентам все внутренние детали проекта и при этом сохранить их поддержку.
Это самая популярная проблема, с которой мы сталкиваемся с нашими новыми клиентами. Как только они получают доступ к среде разработки, они пытаются давать инструкции напрямую программистам, обходя наш существующий процесс. “Я плачу этим ребятам; почему я не могу им сказать, что делать?” - очень типичное мышление. Вместо того, чтобы представлять запросы через наш механизм стандартного управления изменениями, такой клиент обращается напрямую к одному из программистов и говорит ему, что нужно исправить, как и когда. Это микроуправление в своей худшей форме. Мы видим это очень часто. Что мы делаем?
Сначала мы пытаемся понять, почему это происходит. Самый простой ответ - клиент - идиот. Иногда это именно так, но это редкий случай. Гораздо чаще наши клиенты не такие плохие. Что же это? Почему они не могут следовать процессу и соблюдать правила? Есть несколько возможных причин.
Возможно, правила не объяснены хорошо. Это самая популярная основная причина - правила работы недостаточно ясны для клиента. Он просто не знает, что он должен сделать, чтобы представить запрос и получить его реализацию. Чтобы предотвратить это, мы пытаемся образовывать наших клиентов в начале нового проекта. Мы даже пишем руководства для клиентов. Большинство из них с радостью читают их и учатся, как мы работаем, потому что они понимают, что это лучший способ достичь успеха, работая с нами.
Возможно, наше управление хаотично, и клиент пытается “организовать” нас, давая ясные указания по наиболее важным задачам. Мы видели это раньше, и всегда стараемся учиться на этом. Как только мы видим, что клиент пытается микроуправлять нами, мы задаем себе вопрос: “Достаточно ли наш процесс прозрачен? Мы даем достаточно информации клиенту о вехах, рисках, планах, затратах и т. д.?” В большинстве случаев это наша ошибка, и мы стараемся учиться и улучшаться. Если так, важно быстро реагировать, пока клиент не станет слишком агрессивным в своих указаниях и приказах. Будет очень трудно вернуть его к нормальному процессу, когда он окажется “заражен” микроуправлением.
Возможно, клиент не очень занят и имеет много свободного времени, которое он с радостью проводит, отдавая приказы и отвлекая вашу команду. Я видел это много раз. Решение? Занять его. Превратить его в члена команды и поручить ему некоторые задачи, связанные с документацией и исследованиями. По моему опыту, большинство клиентов будут рады выполнить эту работу и помочь проекту.
Технически грамотный клиент может превратить жизнь архитектора в кошмар, постоянно требуя объяснить каждое техническое решение, от “Почему PostgreSQL, а не MySQL?” до “Почему этот метод не вызывает проверяемое исключение?” Постоянное отвечание на такие вопросы может превратить проект в программную школу. Но, хотя он платит за наше время, это не означает, что мы должны учить его разрабатывать программное обеспечение, верно? С другой стороны, его интересует, как разрабатывается и работает его программное обеспечение. Это справедливая просьба, не так ли?
Я считаю, что есть выгодное решение этой проблемы. Вот как мы справляемся с ней. Во-первых, мы просим клиента оформить все его запросы официально. Мы просим клиента создать новый тикет для каждого запроса, правильно объяснив, что не ясно и какой уровень детализации ожидается в объяснении.
Во-вторых, мы рассматриваем такие запросы положительно - это хорошие показатели определенных несоответствий в программном обеспечении. Если клиенту не ясно, почему используется PostgreSQL, а не MySQL, это ошибка нашего архитектора. Он не задокументировал свое решение и не объяснил, как оно было принято, какие другие варианты рассматривались, какие критерии выбора применялись и т. д. Таким образом, запрос от клиента - это баг, который мы получаем бесплатно. Поэтому мы смотрим на это положительно.
Наконец, мы взимаем плату за предоставленные ответы. Каждый вопрос, оформленный в виде тикета, проходит полный процесс обработки и выставляется счет, как и для любого другого тикета. Такой подход предотвращает клиента от чрезмерного обращения. Он понимает, что мы готовы объяснить все, что он хочет, но он заплатит за это.
Эта проблема даже больше, чем предыдущая. Некоторые клиенты считают себя настолько опытными, что спорят с нашим архитектором и программистами о том, как должно разрабатываться программное обеспечение. Они не только спрашивают, почему мы используем PostgreSQL, но и говорят нам, что мы должны использовать MySQL, потому что “я знаю, что это отличная база данных; мой друг ее использует, и его бизнес растет!” Иногда становится еще хуже, когда предложения направляются на каждый класс или даже метод, например, “Здесь вам следует использовать шаблон Одиночка!”
Наш первый выбор - согласиться и сделать то, что он хочет. Но это дорога в никуда. После того, как вы это сделаете, ваш проект будет разрушен, и вам придется задуматься о разрыве контракта с этим клиентом. Ваша команда быстро превратится в группу кодирующих обезьян, управляемых кем-то с деньгами. Это очень неправильное направление; даже не думайте о том, чтобы идти туда.
Второй выбор - сказать клиенту заниматься своим делом и дать нам заниматься своим. Он нанял нас потому, что мы достаточно профессиональны, чтобы разрабатывать программное обеспечение в соответствии с его требованиями. Если он сомневается в наших возможностях, то свободен сменить подрядчика. Но до тех пор он должен доверять нашим решениям. Работает ли это? Сомневаюсь. Это то же самое, что показать ему средний палец. Он обидится, а вы ничего не получите.
Решение здесь - превратить требования клиента в требования проекта. Большинство из них пропадет в процессе, потому что они не будут достаточно осмысленными, чтобы стать хорошим требованием. Другие будут задокументированы, оценены и отклонены самим клиентом, потому что он поймет, что они бессмысленны или слишком дороги. Выживут только некоторые из них, так как они будут достаточно разумными. И они помогут проекту. Так что это также выгодное решение.
Например, он говорит, что “вы должны использовать MySQL, потому что это отлично”. Вы говорите ему, что документ требований проекта не ограничивает вас в выборе любой базы данных, которую вы предпочитаете. Должен ли он? Он говорит да, конечно! Хорошо, давайте попробуем задокументировать такое требование. Как оно будет звучать? Как насчет “Мы должны использовать только отличные базы данных?” Звучит правильно? Если да, то PostgreSQL удовлетворяет этому требованию. Проблема решена; продолжим нашу работу. Ему будет трудно придумать требование таким образом, чтобы запретить PostgreSQL, но разрешить MySQL. Это просто невозможно в большинстве случаев.
Иногда, однако, это будет иметь смысл; например, “Мы должны использовать сервер баз данных, который понимает наши унаследованные данные в формате MySQL”. Это вполне разумное требование, и единственный способ его удовлетворить - использовать MySQL.
Таким образом, мое рекомендация состоит в том, чтобы никогда не выполнять требования клиента напрямую, а вместо этого использовать их для изменения документации по требованиям. Даже если у вас нет такой документации, создайте простой одностраничный документ. Согласитесь с клиентом, что вы работаете на основе этого документа, и когда кто-то захочет что-то изменить, вы должны сначала изменить документ, а затем заставить свою команду убедиться, что программное обеспечение ему соответствует. Такая дисциплина будет принята любым клиентом и защитит вас от внезапных и отвлекающих исправлений.
Когда исходный код открыт для клиента, и он технически способен его прочитать, очень вероятно, что однажды он скажет нам, что наш код отстой и нам нужно научиться программировать лучше. Это не происходило в наших проектах уже много лет, но раньше это случалось, когда мы не использовали статический анализ как обязательный шаг в нашей системе непрерывной интеграции.
Еще одна забавная возможность - когда клиент показывает исходный код “другу”, и он высказывает “профессиональное” мнение, которое звучит так: “Они не знают, что делают”. Как только такое мнение доходит до вашего клиента, проект оказывается в значительной опасности закрытия. Будет очень сложно, почти невозможно убедить клиента не слушать “друга” и продолжать работать с вами. Поэтому большинство аутсорсеров предпочитают держать свои исходники в тайне до самого конца проекта, когда оплачивается последний счет.
Я считаю, что случайное появление “друга” с отрицательным мнением невозможно предотвратить. Если это произойдет, так и будет. Нельзя избежать этого. С другой стороны, если вы считаете, что ваш код идеален, и ваша команда состоит только из талантливых программистов, пишущих красивое программное обеспечение, это тоже не защитит вас. Мнение, высказанное “другом”, не будет объективным; оно просто будет очень личным, и вот почему оно очень убедительно. Он - друг клиента, и он не присылает ему счета каждую неделю. Зачем ему лгать? Конечно, он говорит от души! (Я говорю это иронично.) Так что, несмотря на то, насколько красива ваша архитектура и ваш исходный код, “друг” всегда будет прав.
По моему мнению, единственный способ предотвратить такую ситуацию или минимизировать ее последствия - организовать регулярные и систематические независимые технические обзоры. Они дадут уверенность клиенту в том, что команда не обманывает его относительно качества продукта и ключевых технических решений, принятых внутри.
В заключение, я настоятельно считаю, что важно быть честным и открытым перед каждым клиентом, несмотря на то, насколько это сложно. Старайтесь учиться на каждом конфликте с каждым клиентом и улучшать свой процесс управления и принципы работы. Скрытие исходного кода является непрофессиональным и делает вас плохим в глазах ваших клиентов и всей отрасли.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:52
