Книга Как хорошему разработчику не стать плохим менеджером - Константин Борисов
Шрифт:
Интервал:
Закладка:
Во всех перечисленных ситуациях естественной реакцией многих будет: “Не хочу!” Кто-то справится с этой реакцией сам, кто-то пойдёт жаловаться менеджеру и тому придётся заниматься этой самой мотивацией. Но в любом случае в IT командах нежелание что-то делать даже из того, что делать надо обязательно, является нормальным. Это часто удивляет людей, от IT далёких.
Более того, такая “демотивированность” часто является полезной, так как жгучее нежелание что-то делать – это вполне себе движущий фактор. Например, если заказчик принимает непопулярное техническое решение, то разработчики могут очень быстро провести исследование, подготовить обоснование выбора другой технологии и даже реализовать прототип, которые убедит заказчика. Или нежелание ходить на ежедневные митинги в неудобное время может замотивировать вовремя обновлять все тикеты и писать письма с подробным описанием сделанного.
К тому же люди в IT часто бывают высочайшими профессионалами. И даже, если они почему-то чего-то не хотят, то они всё равно могут выдавать очень хороший результат.
Хотя иногда люди наотрез отказываются делать то, без чего работать невозможно, и это нормально. Например, как-то целый проект переводили с Java на .Net. Естественно, некоторые из разработчиков не захотели менять специализацию. А в другой раз запланированная автоматизация тестирования была отменена и многие тестировщики, планировавшие стать автоматизаторами, не захотели продолжать работать в ручном тестировании.
Ситуации бывают разными и следствия из них бывают разными, но надо чётко понимать, что простое нежелание что-то делать, может иметь очень интересные корни, до которых менеджер должен докопаться. И ответ: “Не хочу,” не должен автоматически навешивать какой-то ярлык. Желание и нежелание – это обычный материал любого менеджера, работающего с людьми.
Маша работала не в IT, она была менеджером по продажам. Маша делала “холодный обзвон”, каталась по офисам компаний и заключала новые контракты. И она очень не любила увольняться. Никто не любит, конечно, но она прямо терпеть не могла эти последние разговоры, эти упрёки: “Ну что ж ты так нас подводишь?” от уже бывшего начальника, эти ненужные никому вопросы и ответы и эту бессмысленную двухнедельную отработку. А увольняться ей приходилось часто. Она постоянно меняла места работы.
Поэтому она поступала проще. Она просто не выходила на работу, брала такой самовольный отпуск на пару недель. Телефонные звонки она отклоняла. А потом она просто заходила в отдел кадров, забирала трудовую книжку с записью об увольнении за прогулы и шла устраиваться на новое место. Так как она работала в одиночку, без команды, то она никого не подводила. Ну, кроме своего начальника, но отношения с ним при увольнении, как показывал её опыт, всё равно портились.
Вот и в этот раз она решила “увольняться” старым испытанным методом – просто не вышла на работу. Её начальник, Иван Иваныч, звонил много раз, так что ей даже пришлось добавить его в “чёрный список”. Звонили и из отдела кадров пару раз, но она не брала трубку. Чего тут разговаривать? И так всё понятно.
Но когда она через обычные две недели пришла за своей трудовой, в отделе кадров ей сказали, что она не уволена. “Иваны Иваныч, приказ на тебя не подавал”, – ответили они. А тут и сам Иван Иванович прибежал: “Машенька, ну наконец-то ты вернулась! Что случилось? Я знал, что что-то случилось. Ты так неожиданно пропала, и телефон твой перестал отвечать. На меня начальство давит, чтоб я нашёл тебе замену, но я-то тебя знаю. Я знал, что ты вернёшься и все наладишь. И вот ты вернулась! Ты когда сможешь полностью на работу вернуться?”
В этот раз Машеньке всё-таки пришлось пройти через все эти разговоры, вздохи, взгляды и отработки, которые она так не любила. И в этот раз всё было в разы тяжелее для неё, чем обычно.
Ошибки в области разработки ПО – это не какие-то экстренные ситуации, это норма. Иногда разработку сравнивают со строительством дома, но это сравнение очень далеко от реальности. Дома проектируются и строятся точно по плану, план меняется очень редко и крайне незначительно, дома в основном типовые или как минимум состоят из типовых частей.
Разработка скорее похожа на съёмки фильма. Да, есть сценарий, но он не включает в себя все детали и постоянно переделывается. Каждая сцена снимается и переснимается, пока не получится так, как надо. И в процессе случаются многочисленные накладки разной степени ужасности: актёры беременеют, бюджет меняется, меняются законы и т.д. В таких условиях даже сам подход “сделать сразу без ошибок” не имеет смысла. Это как сказать актёрам: “Плёнки на дополнительные дубли нету, играйте сразу нормально”.
Для людей из многих других областей неизбежность ошибок кажется ненормальной. Особенно странным им кажется то, что разработчик не несёт никакой ответственности за сделанные им баги. Для нас, работающих в IT, такое положение дел логично и понятно.
Одно время я вёл примерный учёт заведённых на меня багов. Для разработчика каждый баг можно считать официальной регистрацией сделанной им ошибки. Вести счёт я прекратил, когда багов стало больше 3000. Менеджер делает свою работу в тех же условиях неопределённости, что и разработчик, поэтому в IT проекте будут менеджерские ошибки. И их будет много.
Иногда бывает, что разработчик, которому сказали, что по его функционалу нашли 20 багов, удивляется и начинает их разбирать: “Ну, этот баг – это не я виноват, это там у нас дизайн кода такой кривоватый. А эти два бага надо в один объединить, и вообще это, скорее, в требованиях ошибка. А эти баги я уже исправил, это у вас просто код старый в тестирование ушёл. А эти баги очень мелкие, они не считаются. В общем, я реализовал всё без ошибок!”
Очень странно слушать такие речи от разработчика, но совсем недопустимо, когда подобное говорит менеджер. Вместо оправданий менеджеру нужно брать на себя ответственность. Любая ошибка, сделанная командой – это ошибка менеджера. Менеджеру полезно это не только знать, но и признавать публично.
Кажется, что этот подход только мешает, но он наоборот, очень продуктивен сразу по нескольким причинам. Во-первых, “поиск виноватого” не является необходимым для решения конкретной проблемы, а занимает он ужасно много времени. К тому же часто проблема является следствием цепи ошибок разных людей: заказчик дал не совсем корректные требования, аналитик не обратил внимания на краевые ситуации, разработчик реализовал, не вникая, тестировщик не продумал полноту сценариев тестирования и т.д.
Во-вторых, проблема не может быть решена на том уровне, на котором она возникла (© Альберт Эйнштейн). Если некоторый Вася обрушил продакшн, неправильно реализовав какой-то кусок кода, то очень хочется в виде решения поругать Васю и сказать ему, чтобы он так не делал. Но обычно такие ситуации означают, что процесс построен неверно, и надо менять его, а не Васю. Юнит-тесты, код-ревью, автоматизация, Continuous Integration и прочие плотно вошедшие в индустрию практики как раз позволяют избегать тех ситуаций, в возникновении которых пару десятков лет назад обвиняли “нерадивых разработчиков”.
