При сотрудничестве с программистами важно договориться «на берегу» о правилах взаимодействия. Предлагаю вам свод таких правил, накопленных за годы руководства проектами. Какие-то пункты вам могут показаться очевидными, какие-то вызовут интерес или отторжение, некоторые – удивление, но все они, так или иначе, отработаны на практике и проверены в боях. Так что можете смело адаптировать их под себя и пользоваться. Данное соглашение призвано установить доверительно-деловой климат при совместной работе над проектами и решением сопутствующих задач. Если специалист понимает, что задача поставлена некорректно, то он ее уточняет до степени взаимно-однозначного соответствия с заказчиком. Специалист предлагает возможные варианты решения, которые могут быть полезны для проекта, но упущены из поля видимости заказчиком. Специалист соблюдает рекомендуемые методики проектирования, уделяет внимание чистоте и эргономике интерфейсов, придерживается стандартов разработки, в принятой на проекте среде реализации. Если задача может быть решена разными способами (влияющими на стоимость решения), то специалист должен согласовать вариант реализации с заказчиком до начала работ. Специалист предпочитает максимально использовать типовые возможности системы вместо программных доработок. Вносить изменения в типовые конфигурации вендора (в случае необходимости) следует в максимально щадящем режиме. В качестве основы для изменений предпочтительно использовать широко-известные свободно-распространяемые готовые библиотеки. Использование платных библиотек и иного встраиваемого кода, защищенного правами третьих лиц, должно быть согласованно с заказчиком. Специалист назначает окончательную стоимость этапа работ или всего решения до начала работ над этапом (проектом). Специалист укладывается в сроки, которые озвучивает, и самостоятельно уведомляет заказчика о готовности работы. Специалист регулярно выходит на связь с заказчиком, демонстрирует ему промежуточные результаты работы и, по необходимости, корректирует направление разработки. Специалист отвечает на вопросы заказчика своевременно и по существу. Если ответ на вопрос требует времени, то специалист уведомляет заказчика о временных рамках, необходимых ему для ответа. Специалист выбирает сотрудничество и диалог вместо критики и поучений. Специалист самостоятельно тестирует свои решения и вносит в них коррективы, в случае обнаружения багов. Специалист документирует разработку и комментирует программный код. Если в процессе работы над проектом специалист видит «неоптимальности» или явные ошибки в уже реализованном функционале, то он сообщает об этом заказчику и, при его согласии, устраняет их за доп. плату. Специалист сохраняет работоспособность ранее внесенных в продукт изменений (если иное не следует из задачи). Проверяет исправность имеющихся механизмов в случае пересечения функционала. После внедрения изменений в промышленную эксплуатацию, специалист готов к оперативному устранению выявленных недостатков, связанных с потерей работоспособности механизмов, вызванных изменениями. Специалист не ограничивает доступ заказчика к ПО, программному коду, базам данных, файлам и сервисам, используемым для функционирования ПО или интегрируемым с ним, не шифрует данные, а также не устанавливает пароли и прочие ограничения. За нарушение пунктов настоящего соглашения или их игнорирование специалист может получить предупреждение от заказчика. При повторных систематических нарушениях специалист отстраняется от проекта. Я использую его в нескольких форматах. Ни один из них я не считаю приоритетным. Все зависит от масштабов проекта, опыта и квалификации программиста, а также от степени обоюдного доверия между PM-ом и специалистом. Можно сделать это соглашение приложением к договору. Можно открыть его и совместно обсудить каждый пункт с последующей подписью. Можно выложить в общий доступ для всех участников проекта, сделав документ рекомендуемым к изучению. Можно использовать все три пункта в желаемых комбинациях по ситуации. Преимущества такого соглашения очевидны: Специалист сразу понимает объем ответственности и, если внутренне он согласен с ним, то в дальнейшем какие-либо эксцессы легко разрешаются. Если же какие-то пункты требуют разъяснений, то это тоже легко решается в беседе. Таким образом, все вопросы, при достижении консенсуса по соглашению, будут закрыты на берегу.  Неопытные специалисты могут испугаться каких-либо положений из списка. В качестве одного из эффектов соглашение может выполнять функцию своеобразного фильтра при найме. Важно! Мои наблюдения показывают, что hard-skill программисты, не обладающие развитыми социально-ориентированными навыками, чаще других пропадают после ознакомления со столь «обременяющими» условиями. Так что, если стиль вашей работы в качестве менеджера проекта позволяет иметь в команде таких людей, то будьте аккуратнее с этим соглашением – вы можете упустить молчаливых гениев. Удачи вам в использовании соглашения и прорывных идей!