Заметки с тегом «Проекты»

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

«Ты сделал говно» — это же самая обычная обратная связь. Когда коллектив видит говно, но не кричит о нём, его участники как бы соглашаются: да, у нас можно делать говно, и мы никого не будем учить делать неговно, пусть сами разбираются.

Представьте, если первоклассник принёс учителю решение, что 2 x 2 = 3, а учитель в ответ выражает просто мягкое неодобрение, но не говорит, что правильно будет 4? Математика никогда не откроется ребёнку как точная наука, скорее ощущение будет «ну, я что-то делаю, что-то, наверное, получается».

Когда я нанимаю людей, при первом же удобном случае провожу их через ситуацию «ты сделал говно»: ловлю на ошибке и подробно и спокойно разбираю её. Если новый сотрудник воспринимает такой разбор с благодарностью, значит, наши ценности совпадают и мы, скорее всего, сработаемся. Если злится, закрывается или доказывает мне, что никакой ошибки на самом деле не было, — вряд ли.

Важно — именно «ты сделал говно», а не «ты — мудак». Критиковать можно только работу, но не личность.

Всю активность менеджера можно условно разделить на два вида: реагирование и инициирование. Реагирование — это работа с внешними раздражителями: телефонными звонками, письмами, коллегами, которые подошли с вопросом.

Инициирование — это действия, направленные на то, чтобы результаты достигались, а раздражителей было поменьше: планирование встреч, отчеты, постановка задач.

Плохой менеджер всегда больше реагирует, чем инициирует. Вместо того, чтобы тратить по 10 минут в неделю на регулярное отчетное письмо команде, он предпочитает лично в слаке рассказывать каждому новости, и потом ещё решать проблемы вызванные дискоммуникацией, когда левая рука не знает, что делает правая.

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

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

Хороший менеджер задаёт этот вопрос во время каждой своей активности.

• Какую ценность я добавил, когда сходил на встречу? Был ли полезен, принёс что-то новое или тупил в фейсбук?
• Какую ценность я добавил, когда ответил на письмо? Легче ли стало совершить следующий шаг по проекту?
• Какую ценность я добавил, когда поговорил с программистом? Стало ли ему понятнее, что и как делать на проекте?
• Какую ценность я добавил за неделю руководства отделом? А за месяц?

Если нечего ответить, значит пора переставать заниматься деятельностью, которая не приносит ценности: отказаться от встреч с командой, которой ты не нужен, не слать пустые отписки на письма, не отвлекать программистов. Или просто отдохнуть.

Это — тупое правило, которое здорово помогает во всех спорных ситуациях.

Программист не сдал задачу вовремя, потому что не знал? Покажи, где это было написано. Если не нашёл — значит, дедлайна не было.

На встрече договорились что-то сделать и не записали? Значит, никому не надо.

Правило «не написано, значит, не было» здорово мотивирует писать минутки ко всем встречам и поддерживать актуальность задачников. Если тебе что-то от кого-то нужно, значит, ты сядешь и напишешь задачу с дедлайном — иначе тебя пошлют нафиг и будут правы.

Неопытные менеджеры часто строят разговоры с программистами на давлении. Начиная от банального «5 дней, говоришь? А может, давай за 4, но без тестов?» и заканчивая манипулятивными просьбами расписать подробную смету по часам на каждое требование.

Это — ошибка: даже если программист под давлением пообещает срок меньше, результат от этого не приблизится. Во-первых, программист будет помнить, что срок назвал не он сам, а менеджер, а значит, если этот срок проебать, то уже не так и стыдно. Во-вторых, количество работы всё равно не уменьшается — если сделать пятидневную задачу за три дня, то оставшиеся два (а может, и больше) попадут в техдолг и выстрелят через пару месяцев.

Ну и, конечно, такие менеджеры не ценят своё время: гораздо проще получить предсказуемый результат через 5 дней, чем непредсказуемый через 3, но с риском потратить ещё 5 на исправление последствий техдолга или отношений с заказчиком.

Единственный нормальный способ уменьшить названный программистом срок — это спросить у него совета, какое требование из задачи выкинуть, чтобы стало легче работать. Все остальные — манипуляции, которые не приведут ни к чему, кроме сорванных дедлайнов.