Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий. Владимир Завертайлов
не удивляться, если программисты считают менеджеров обслуживающим персоналом. Причем, назойливым, глупым, мешающим работать и думать об архитектуре, ставящим неадекватные задачи и вечно лезущим со всякой несущественной фигней.
Таким образом, в поле власти может возникнуть красная зона, где люди по-разному понимают круг своих обязанностей, свою зону ответственности и свои права.
Плохо, если сотрудники в компании не знают, как именно власть распределена; плохо, если знают по-разному. Такая мышиная возня отнимает у компании много энергии. В таких случаях вопрос решается повышением компетенций руководителей (нужны энергичные живчики), введением хороших корпоративных правил и наказаний (вплоть до замены нелояльных сотрудников). То есть, долго и дорого.
Вариантов потерять власть – много. Например, самозахват.
Допустим, у вас есть правило: «Получил задачу – оцени». Программист может сначала, как бы случайно, не оценивать задачи (типа, забыл). Если на это не отреагируют (ну сделал, и ладно) – не оценивать специально. Если попросят оценки – сказать: «Не знаю, не могу». А потом и вовсе поскандалить и отказаться оценивать задачи: «Вы, менеджеры, ни черта не понимаете в природе программирования, никаких оценок там дать нельзя…» Если менеджер не отреагирует – сформируется право обычая «Васе можно». И все: власть менеджера уменьшилась, а программист отвоевал себе свободу не думать перед началом работы и не отвечать за сроки.
Другой пример: одна моя сотрудница отвечала за организацию пятничного дизайн-баттла. Каждую пятницу ей нужно было придумать какую-то тему, собрать вечером дизайнеров на 1 час, в рабочее время. Дизайнеры ровно час рисовали по макету. Дальше нужно было организовать публичную презентацию (каждый дизайнер защищал свою работу), и можно было проголосовать за какой-то из макетов, выбрав победителя.
С одной стороны, это прокачивало навыки презентации, ускоряло дизайнеров и просто было весело. С другой, за долгое время проведения таких баттлов пошла профанация: часто работы не имели художественной ценности, а выигрывала самая укуренная. И вот в одну из пятниц я узнаю, что баттла не будет. «Как так?» – спрашиваю я. Ответ был таким: «А они отказались сегодня. Говорят, каждую неделю – слишком часто, давайте через неделю хотя бы». Тут много чего было нарушено, но острее всего – самозахват: дизайнеры захватили право решать, будет баттл или нет, а также, чем они будут заниматься в рабочее время по пятницам.
За самозахват бьют, и больно.
Чаще всего менеджеров продавливают, лишая прав:
▶ получать оценку оставшейся работы – от этого и программисты, и дизайнеры будут увиливать под любым соусом: мол, я не гадалка и не знаю, сколько времени это займет;
▶ выбирать инструменты и методы работы – проще говоря, технологии;
▶ выбирать, использовать ли готовые модули или писать с нуля;
▶ оценивать выполненную работу.
2.3.3. Как бы шутка
Допустим, я программист и сделал какую-то