Один мой друг, он же отличный программист и формально подчиненный коллега, думал, что он круче всех. Он и сейчас так думает, но стал более осторожен. Но если он что-то сделал, то непременно лучше всех. Если что-то придумал, то никто не догадается и никогда не повторит. Короче говоря, как-то давно он уволился и был несколько обижен на прежнего работодателя (кстати, имел основания). Но поскольку парень он ответственный, то как бы ему не хотелось напакостить, но дела он передал. В несколько ленивой форме по принципу - вы спрашивайте, а я отвечу. Долго он фантазировал о том, насколько тяжело без него, пока в один прекрасный момент не взял последнюю версию продукта и не увидел, что он развивается и что некоторые вещи новая команда сделала лучше, чем придумал он. Провалиться мне на этом месте, если он не пару недель был сам не свой. Это был очень сильный удар по самолюбию. Зато получил урок.
Эту короткую историю я внезапно вспомнил, когда один из моих парней заговорил о возможном увольнении. Первая мысль, возникающая у менеджера проекта заключается в осознании того, что потеряет команда с уходом специалиста. Ну и частенько возникает ощущение, что человек незаменим. Попытаюсь сразу ответить на вопрос о том, бывают ли незаменимые. Сама по себе "незаменимость" во многом присутствует только в нашей голове. Я, например, привязываюсь к людям и стараюсь не терять тех, кому доверяю, а если учесть, что для меня команда является, по сути, второй семьей, то потеря сотрудника воспринимается тяжело. То есть, в моей голове "незаменимость" присутствует. Есть менеджеры, которые к этому относятся значительно проще, если ушел один, то придет другой. И у них основания так считать, ведь если один человек смог это сделать, то найдется и другой, который сможет, вероятно, еще лучше.
Но не все так просто, предлагаю тезисно разобраться в некоторых нюансах.
- Незаменимость повышается с уровнем квалификации и степенью интегрированности специалиста в тот или иной проект.
- Незаменимость определяется единоличным владением ключевой информацией, тот самый фактор автобуса, который, строго говоря, определяет устойчивость проекта к потере разработчиков если их завтра собьет автобус. В случае, когда все тонкости проекта лежат в голове условного одного человека, вы имеете низкий bus-фактор. Если та же информация распределена между несколькими разработчиками, то bus-фактор повышается, то есть, проект более устойчив.
- Следствием предыдущего пункта являются такие факторы как излишняя сложность реализации продукта и отсутствие технической документации. Вообще, чем сложнее реализован продукт, тем сложнее будет жизнь.
- Не стоит убирать в сторону и саботаж. Это штука очень опасная и непредсказуемая, но если о ней не забывать, то можно минимизировать риски.
- Есть и специфичные моменты, например, отставание от рынка труда. Если ваш продукт создавался матерыми специалистами, но после их потери вы не можете себе позволить людей той же квалификации, то у вас наверняка возникнут проблемы.
Чтобы снизить свою зависимость от "незаменимых" необходимо всегда держать руку на пульсе. С одной стороны, не забывайте, что современная разработка не так сложна и уникальна, как это было раньше. С другой, помните, что ваши заказчики не должны пострадать. Качество продукта должно оставаться высоким, а темпы разработки не должны снизиться до неприемлемых показателей. Что же можно предпринять?
- Повышение уровня совместного владения кодом. Это можно делать сами разными способами. Вы можете ротировать задачи по одной подсистеме между разными разработчиками, можете внедрить процедуру code review, проводить собрания, на которых разработчики будут рассказывать о том, как именно они выполнили задачу. В конце концов, даже обычные обсуждения реализации тех или иных функций позволяют всем членам команды быть, как минимум, в курсе.
- Обеспечение документирования архитектуры. Это очень сложная, но нужная задача, хотя бы в минимальном объеме. Почему она сложная? Во-первых, разработчики часто не любят что-либо описывать - это скучно и не всегда по способностям. Описать силами технических писателей или аналитиков далеко не всегда получается хорошо в силу того, что для этого нужна соответствующая квалификация и очень плотное взаимодействие с разработчиками. Идеально, когда вы документируете архитектуру и проектные решения одновременно с разработкой соответствующих компонентов. Но реальность несколько иная. Как правило, проект имеет историю и документировать приходится готовый проект. Это та еще задачка. И не забывайте, что документация носит комплексный характер, описание архитектуры при отсутствии ТЗ - не лучший, хоть и приемлемый вариант. Идеально, когда все же есть полный комплект документации, хотя, в небольших организациях это практически невозможно, особенно в актуальном состоянии.
- Регламентируйте и требуйте соблюдения правил оформления программного кода и выполнения сопутствующих задач (в частности, документирования).
- Внедряйте процедуры тестирования, основанные на планах и с применением средств автоматизации. Это поможет снизить риски снижения качества продукта.
- Поддерживайте адекватные отношения с коллегами, чтобы максимально снизить риски саботажа. Сотрудник может быть обижен на организацию, но не будет гадить своему руководителю.
Кроме того, я недавно стал задумываться о некоторой избыточности. То есть, появилась мысль, что стоит взять еще одного программиста, что позволит иметь некоторый резерв. Если кто-то увольняется, то его замещение не потребует экстренных мер, поскольку присутствует избыточность в специалистах. Единственное, что меня останавливает - издержки. Во-первых, это дополнительное администрирование. Во-вторых, дополнительные финансовые расходы. Тем не менее, я активно продумываю этот вариант.
В общем, посмотрим, как я справлюсь с вероятным увольнением одного из лучших своих парней. Обязательно расскажу о результатах.