При сотрудничестве с программистами важно договориться «на берегу» о правилах взаимодействия. Предлагаю вам свод таких правил, накопленных за годы руководства проектами. Какие-то пункты вам могут показаться очевидными, какие-то вызовут интерес или отторжение, некоторые – удивление, но все они, так или иначе, отработаны на практике и проверены в боях. Так что можете смело адаптировать их под себя и пользоваться.

Соглашение о сотрудничестве

Данное соглашение призвано установить доверительно-деловой климат при совместной работе над проектами и решением сопутствующих задач.

1. Если специалист понимает, что задача поставлена некорректно, то он ее уточняет до степени взаимно-однозначного соответствия с заказчиком.

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

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

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

5. Специалист предпочитает максимально использовать типовые возможности системы вместо программных доработок.

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

7. Использование платных библиотек и иного встраиваемого кода, защищенного правами третьих лиц, должно быть согласованно с заказчиком.

8. Специалист назначает окончательную стоимость этапа работ или всего решения до начала работ над этапом (проектом).

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

10. Специалист регулярно выходит на связь с заказчиком, демонстрирует ему промежуточные результаты работы и, по необходимости, корректирует направление разработки.

11. Специалист отвечает на вопросы заказчика своевременно и по существу. Если ответ на вопрос требует времени, то специалист уведомляет заказчика о временных рамках, необходимых ему для ответа.

12. Специалист выбирает сотрудничество и диалог вместо критики и поучений.

13. Специалист самостоятельно тестирует свои решения и вносит в них коррективы, в случае обнаружения багов.

14. Специалист документирует разработку и комментирует программный код.

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

16. Специалист сохраняет работоспособность ранее внесенных в продукт изменений (если иное не следует из задачи). Проверяет исправность имеющихся механизмов в случае пересечения функционала.

17. После внедрения изменений в промышленную эксплуатацию, специалист готов к оперативному устранению выявленных недостатков, связанных с потерей работоспособности механизмов, вызванных изменениями.

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

19. За нарушение пунктов настоящего соглашения или их игнорирование специалист может получить предупреждение от заказчика. При повторных систематических нарушениях специалист отстраняется от проекта.

Как работать с соглашением?

Я использую его в нескольких форматах. Ни один из них я не считаю приоритетным. Все зависит от масштабов проекта, опыта и квалификации программиста, а также от степени обоюдного доверия между PM-ом и специалистом.

1. Можно сделать это соглашение приложением к договору.

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

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

Можно использовать все три пункта в желаемых комбинациях по ситуации.

Преимущества такого соглашения очевидны:

1. Специалист сразу понимает объем ответственности и, если внутренне он согласен с ним, то в дальнейшем какие-либо эксцессы легко разрешаются. Если же какие-то пункты требуют разъяснений, то это тоже легко решается в беседе. Таким образом, все вопросы, при достижении консенсуса по соглашению, будут закрыты на берегу.

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

Важно! Мои наблюдения показывают, что hard-skill программисты, не обладающие развитыми социально-ориентированными навыками, чаще других пропадают после ознакомления со столь «обременяющими» условиями.

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

Удачи вам в использовании соглашения и прорывных идей!