Константин Борисов - Как хорошему разработчику не стать плохим менеджером
- Название:Как хорошему разработчику не стать плохим менеджером
- Автор:
- Жанр:
- Издательство:Array SelfPub.ru
- Год:2020
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Константин Борисов - Как хорошему разработчику не стать плохим менеджером краткое содержание
Как хорошему разработчику не стать плохим менеджером - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Так что не надо рассказывать своему начальству, подчинённым и знакомым, что вы завалили свои задачи из-за трудностей с командой. Лучше поругайте себя за то, что не справились со своей работой.

“Не хочу, не буду!”
Часто нежелание человека делать свою работу представляют как “смертный грех”, который ставит крест на работнике как профессионале, и с которым менеджер ничего не может поделать. Говорят: “Ничего нельзя сделать, если человек просто не хочет работать”. Как и большинство прочих расхожих истин, эта "истина" ложная и часто заводит менеджеров не туда.
Первая причина порочности такого подхода выходит из самого понятия “мотивация”. Менеджеры обязаны мотивировать свою команду, в случае необходимости. А что такое мотивация? Это как раз стимуляция желания делать какие-то действия. То есть команда не хочет делать то, что надо менеджеру, а он её мотивирует, чтобы она таки это делала.
Обычно под мотивацией понимают какие-то высокие свершения, вроде сверхинтенсивной работы без выходных. Но на практике вот такая ежедневная мелкая мотивация на ежедневные, часто рутинные задачи важнее, так как именно от неё зависит средняя производительность команды.
К счастью в IT команды обычно высокомотивированные и они сами хотят работать, как можно лучше. Менеджеру не приходится сталкиваться с ситуацией, что без него никто ничего не делает. Но это не значит, что мотивация нужна редко.
Легко вспомнить ежедневные ситуации, когда человек высказывает своё “не хочу, не буду”. Например, от заказчика приходит очередное изменение давно реализованных требований и надо переписывать код. Или менеджер хочет, чтобы оценка в часах была вписана во все тикеты Jira. Или кто-то сломал билд, а от непричастного к этому разработчика ждут, что он его починит. Или заказчик организовал ежедневные митинг в неудобное время. Или нужно задержаться для исправления мелкого, но неприятного бага.
Во всех перечисленных ситуациях естественной реакцией многих будет: “Не хочу!” Кто-то справится с этой реакцией сам, кто-то пойдёт жаловаться менеджеру и тому придётся заниматься этой самой мотивацией. Но в любом случае в IT командах нежелание что-то делать даже из того, что делать надо обязательно, является нормальным. Это часто удивляет людей, от IT далёких.
Более того, такая “демотивированность” часто является полезной, так как жгучее нежелание что-то делать – это вполне себе движущий фактор. Например, если заказчик принимает непопулярное техническое решение, то разработчики могут очень быстро провести исследование, подготовить обоснование выбора другой технологии и даже реализовать прототип, которые убедит заказчика. Или нежелание ходить на ежедневные митинги в неудобное время может замотивировать вовремя обновлять все тикеты и писать письма с подробным описанием сделанного.
К тому же люди в IT часто бывают высочайшими профессионалами. И даже, если они почему-то чего-то не хотят, то они всё равно могут выдавать очень хороший результат.
Хотя иногда люди наотрез отказываются делать то, без чего работать невозможно, и это нормально. Например, как-то целый проект переводили с Java на .Net. Естественно, некоторые из разработчиков не захотели менять специализацию. А в другой раз запланированная автоматизация тестирования была отменена и многие тестировщики, планировавшие стать автоматизаторами, не захотели продолжать работать в ручном тестировании.
Ситуации бывают разными и следствия из них бывают разными, но надо чётко понимать, что простое нежелание что-то делать, может иметь очень интересные корни, до которых менеджер должен докопаться. И ответ: “Не хочу,” не должен автоматически навешивать какой-то ярлык. Желание и нежелание – это обычный материал любого менеджера, работающего с людьми.

История про способ уволиться
Маша работала не в IT, она была менеджером по продажам. Маша делала “холодный обзвон”, каталась по офисам компаний и заключала новые контракты. И она очень не любила увольняться. Никто не любит, конечно, но она прямо терпеть не могла эти последние разговоры, эти упрёки: “Ну что ж ты так нас подводишь?” от уже бывшего начальника, эти ненужные никому вопросы и ответы и эту бессмысленную двухнедельную отработку. А увольняться ей приходилось часто. Она постоянно меняла места работы.
Поэтому она поступала проще. Она просто не выходила на работу, брала такой самовольный отпуск на пару недель. Телефонные звонки она отклоняла. А потом она просто заходила в отдел кадров, забирала трудовую книжку с записью об увольнении за прогулы и шла устраиваться на новое место. Так как она работала в одиночку, без команды, то она никого не подводила. Ну, кроме своего начальника, но отношения с ним при увольнении, как показывал её опыт, всё равно портились.
Вот и в этот раз она решила “увольняться” старым испытанным методом – просто не вышла на работу. Её начальник, Иван Иваныч, звонил много раз, так что ей даже пришлось добавить его в “чёрный список”. Звонили и из отдела кадров пару раз, но она не брала трубку. Чего тут разговаривать? И так всё понятно.
Но когда она через обычные две недели пришла за своей трудовой, в отделе кадров ей сказали, что она не уволена. “Иваны Иваныч, приказ на тебя не подавал”, – ответили они. А тут и сам Иван Иванович прибежал: “Машенька, ну наконец-то ты вернулась! Что случилось? Я знал, что что-то случилось. Ты так неожиданно пропала, и телефон твой перестал отвечать. На меня начальство давит, чтоб я нашёл тебе замену, но я-то тебя знаю. Я знал, что ты вернёшься и все наладишь. И вот ты вернулась! Ты когда сможешь полностью на работу вернуться?”
В этот раз Машеньке всё-таки пришлось пройти через все эти разговоры, вздохи, взгляды и отработки, которые она так не любила. И в этот раз всё было в разы тяжелее для неё, чем обычно.

Признание ошибок
Ошибки в области разработки ПО – это не какие-то экстренные ситуации, это норма. Иногда разработку сравнивают со строительством дома, но это сравнение очень далеко от реальности. Дома проектируются и строятся точно по плану, план меняется очень редко и крайне незначительно, дома в основном типовые или как минимум состоят из типовых частей.
Разработка скорее похожа на съёмки фильма. Да, есть сценарий, но он не включает в себя все детали и постоянно переделывается. Каждая сцена снимается и переснимается, пока не получится так, как надо. И в процессе случаются многочисленные накладки разной степени ужасности: актёры беременеют, бюджет меняется, меняются законы и т.д. В таких условиях даже сам подход “сделать сразу без ошибок” не имеет смысла. Это как сказать актёрам: “Плёнки на дополнительные дубли нету, играйте сразу нормально”.
Читать дальшеИнтервал:
Закладка: