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